导读 代码大模型作为一种成熟的技术产品，在多个行业中已实现了广泛应用。本文将分享基于代码大模型的通义灵码相关的最新研究成果。

主要内容包括以下四大部分：

1. AIGC 对软件研发的根本性影响

2. 打造最佳的 Copilot 人机协同模式

3. 未来的软件研发 Agent 产品演进

4. 问答环节

分享嘉宾｜ 陈鑫 阿里云 通义灵码技术负责人

编辑整理｜马慧

内容校对｜李瑶

出品社区｜ DataFun

---

01

AIGC 对软件研发的根本性影响

1. AIGC 对企业研发效能核心因素的影响

制约企业研发效能的核心因素包括人员技能、协同消耗和成本控制三个方面。AIGC 对这三方面的影响可以总结如下：

（1）人员技能

对于多数企业而言，尽管拥有大量的初级和中级工程师，但难以像 Google 那样拥有众多高效能工程师。因此，提升人员技能是持续努力的方向。AIGC 能够助力能力提升，并弥补能力短板。

（2）协同消耗

由于难以依赖超强个体，企业需要进行角色细分，包括产品经理、需求管理、测试、开发运维等。这导致研发过程中存在大量的协同消耗，与软件架构和组织复杂度紧密相关，制约了效能的提升。AIGC 有助于流程规范，打造超级个体。

（3）成本控制

在当前环境下，企业需要控制成本，希望 AIGC 能够帮助解决研发效能的瓶颈。

大模型为我们带来了前所未有的机遇，突破了传统软件工程和研发效能工具的局限。通过智能程序员（如 Copilot Agent）等技术，未来的功能开发和缺陷修复等事务性工作可能都将由 AI程序员承担，可使成本大幅降低。

综上所述，AIGC 在软件研发领域具有巨大的潜力和价值。

2. 企业软件研发的智能化机会与挑战

综合评估来看，企业软件研发的智能化所蕴含的机会与挑战主要体现于以下四个方面：

（1）个体效率提升

通过采用先进的 Copilot 人机交互模式，能够显著提升研发人员的个体效率。这种交互模式能够辅助研发人员高效完成单元测试、代码注释编写等大量事务性工作，从而提升研发的整体效率。

（2）协作效率优化

在协同效率方面，借助 LLM Agent 等技术，对协作流程进行简化。引入智能化协作机制，可以降低协作过程中的沟通成本，提高团队整体的工作效率。

（3）研发体验革新

在传统软件研发流程中，由于工具链的复杂性和开源工具的多样性，开发人员往往需要频繁切换上下文，面临操作不统一、数据结构差异等问题。利用大模型技术可以改善这一状况，通过对话的方式统一研发入口，构建一站式研发项目工具，极大地简化工作流程，提升研发体验。

（4）数字资产管理与利用

在数字资产管理方面，面临着大量优质代码和资产被忽视的问题。为了充分利用这些资产，通过基于 LLM 的 SFT、RAG 增强等方式将隐性知识显性化，可以让更多人享受到知识红利，促进企业的知识共享和创新发展。

3. 人工智能带来的新的人机协同模式

探讨 AIGC 对软件研发的影响，首要任务是理解新的人机交互方式的变化。在过去，人们扮演着理解需求、编写需求实现，实现真实世界与数字化世界之间转换的角色。

大模型介入后，将承担三个角色：

（1）Copilot 角色

目前最为成熟，类似于副驾驶，协助完成单点的事务性工作，人类依然占据主导地位。在此过程中，流程并未发生实质性变化。

（2）Agent 模式

定位于多领域专家，能够自主协同工作。许多简单的事务性工作可以由 AI 自主完成，显示出 AI 的自主能力。在此情境下，人类只需提供上下文并确保知识对齐，人机交互方式进一步发生变化。

（3）Facilitator 角色

LLM（大型语言模型）将具备信息的整合分析和决策能力，人类则更多地负责创意和纠偏工作。

4. 研发知识传递形态的改变

研发中知识传递的形式发生了显著变化。过去，公司企业内容主要通过口口相传、培训和老带新等传统方式进行，以快速培养数据员工。现在可以将大部分工作聚焦于知识的梳理和实时增强大模型。结合一系列智能化研发工具，这些资产和经验能够迅速为企业的一线开发者提供帮助。

例如，在 DevOps 工具链中沉淀了大量的资产和文档。在企业中需要有人承担识别关键资产的角色，并将其梳理清晰以满足大模型的输入要求。随后通过RAG、SFT 等方法与大模型结合，强化智能大脑。智能大脑又反过来强化 DevOps 工具链，形成正向的循环，从而提升企业的效能。

综上所述，AIGC 大模型对当前软件工程的主要影响在于人机协同方式和知识协同方式的转变。

02

打造最佳的 Copilot 人机协同模式

通义灵码目前的主要工作方向是如何在软件研发领域充分发挥大模型的潜力，打造最佳的 Copilot 人机协同模式。

1. 代码开发人机协同的 Copilot 模式

代码开发人机协同 Copilot 模式之所以能成为首批落地的场景，根本原因在于其精准把握了当前大模型技术的核心现状。短期内人们可能高估了大模型的潜力，而长期又可能低估其影响，大模型技术目前仍有许多限制。

Copilot 模式的成功主要基于以下四点：

（1）解决小任务的能力

大模型在处理上下文宽度方面存在局限，它更擅长处理小任务，如根据界面交互图生成代码、根据圈选的代码生成单元测试等。

（2）人工确认采纳以解决模型幻觉问题

由于模型本身存在大量幻觉问题，需要人工确认来保证其输出的准确性。在这种模式下，人机交互过程实质上是不断的人工确认与 AI 生成之间的循环，以此抵消模型幻觉问题，确保输出的实用性。

（3）高频次使用

鉴于当前模型的准确率有限，高频次使用成为了一种有效的弥补方式。通过频繁的交互，即使每次只生成少量代码，累积起来也能显著提高开发效率。

（4）短输出特性

考虑到当前推理成本和性能的限制，短输出模式确保了代码生成的快速和高效。

2. 什么是开发者最喜爱的 Copilot

开发者最喜爱的 Copilot 模式要满足以下四点：

• 高频刚需

解决开发者最常遇到且最为重要的问题。高频是关键，如果频率低且不准确，那么只能被视为一个玩具。

• 触手可及

它应当随时可用，易于切换，且使用体验流畅。

• 知我所想

需要持续提升其准确率，以满足开发者的期望。

• 唯我专属

开发工具应能适应各种企业的特点，包括自研框架和企业内部的私有数据。

（1）解决开发者最高频刚需场景

JetBrains 的 2023 年开发者生态报告显示，开发者最耗时的活动包括编写代码、理解代码、互联网搜索调试、编写注释和编写代码文档等。这些正是当前代码助手所擅长并已经实现的功能。工具可以帮助开发者自动补全代码、生成注释，并提供互联网搜索窗口。对于金融机构而言，由于网络隔离，开发者难以直接搜索。通过大模型预置知识，他们能够迅速获得答案。此外，一键 debug 功能可以帮助开发者快速定位代码缺陷，无需逐行调试。

编写注释和单元测试同样是痛点，尤其在金融行业，对代码质量和单元测试的要求极高。从公共云上的数据看，写单元测试的频率极低，仅为个位数。反映了写单元测试的代价高昂，现有工具仍有很大的改进空间。提高开发者写单元测试的频率是金融行业各大企业的共同目标。

公共云数据显示在代码补全、代码问答（类似 Copilot 问答框）方面，代码补全的采纳比例高达 70%，显示出其在提升开发者效能方面的重要作用。

在问答功能中，研发问答占比七成，表明开发者对于通用知识问答的需求很高。

（2）打造沉浸式编程体验

编码助手旨在打造沉浸式的编程体验，确保所有必要的知识在编程环境中即可迅速获取，减少开发者离开编程环境去互联网搜索信息的需要，避免注意力分散和效率损失。开发者能够在编码助手中即时提问并获得解答，随后快速生成并插入代码，高效完成编码任务。

为实现这一目标，采取的模型策略如下：

• 代码补全任务 Codeqwen2 模型

专注于提升代码补全任务的性能，采用小参数代码模型。例如 Codeqwen 1.5（内部称为二代模型）是通义实验室为通义灵码定制的 Code 模型，目前已在同类 7B 参数量代码大模型中排名第一。该模型的引入使采纳率同比提升了 20% 以上。

• 代码专项技能 Qwen-plus 模型

为完善各种代码技能，基于通义基座模型进行了专项训练。由专家团队构造的大量数据（如单元测试数据），对模型进行微调，使其能够胜任下游任务。目前已涵盖注释生成、单元测试、代码优化、错误排查、提交信息生成、重构建议等七项专项任务，并将继续扩展。

• 研发自由问答 Qwen-max 模型

鉴于开发者的问题中七成属于通用问题，选择了公共云上最大参数的模型——阿里内部代号 Qwen-max 模型，配套了基于通用互联网知识构造的准实时知识库（RAG）技术，使得模型在回答通用研发知识时表现出色。

三个模型共同支撑了代码助手的能力，为用户提供高效、便捷的编程体验。

（3）插件侧跨 IDE 端架构设计

确保服务易于获取，支持 JetBrains、Visual Studio 等系列工具，以及各种系统和编程语言。覆盖广泛的终端，整体架构包括：

• 表现层

与集成开发环境（IDE）的插件 API 对接，实现代码补全等基本功能以及一些高级功能。

• 核心层

位于架构的中心，是一个跨平台的中间件，能够在 MacOS、Windows、Linux 等多种操作系统上运行。

• 服务层

表现层与服务层分离，端侧服务提供一系列功能，包括代码智能补全、问答会话管理、智能体管理、代码分析和本地存储服务。开发者对代码资产非常敏感，更倾向于在端侧运行服务，而非将代码全部上传至云端进行分析。因此在端侧实施了多项技术，包括语法分析技术等。

通过这样的架构，不仅能够快速支持多个终端，还能最大程度地保障用户数据的安全和隐私。

（4）基于语义理解的自适应生成粒度决策

在准确性方面采取的关键措施主要包括：

• 触发时机

代码助手在用户编码过程中的介入时机，如用户敲击回车键、在括号内打字、或在注释中打字时触发等，以及不同操作场景下的触发时机，如代码删除等，大约有 30 到 50 种场景需要细致调整，以确保在开发者需要时提供补全，避免干扰。

• 用户端的自学习机制

根据开发者敲键速度自动调整代码提示出现的延迟，即代码生成的 Debounce 时间，敲键速度较慢时，延迟相应增加；快速敲键时，则减少延迟，避免干扰开发者。

• 生成粒度

确保生成的代码与开发者的意图紧密相关。当开发者编写类注释或格式化 JAVA 代码的 UDF 函数时，期望生成的代码能补全近乎完整的类，对于函数注释，期望生成完整的函数体，让开发者能理解其大致功能，决定是否采纳。

判断生成的逻辑块是否完整。如仅生成 Try 而无 Catch，或 If 语句内无内容，可能导致逻辑不清晰。团队构造了大量数据对模型进行训练，使其能够根据不同场景自适应地决定生成内容的长度，从而提升了各种语言生成粒度和复杂度的处理能力。每种语言的数据结构各异，也是特别需要精心处理的问题。

（5）基于库内感知的代码生成及问答

在改进代码生成工具如代码助手的过程中，面临的核心挑战之一是消除模型幻觉。针对当前文件上下文进行预测时，经常出现编译不通过的情况。通过实施代码的语义分析、引用链追踪以及动态语言推导以及相似代码分析等方法，可以找到当前触发位置所关联的上下文文件。上下文是有限的，当前支持的代码补全模型通常处理8K 的上下文，现已扩展到 32K，但是过长的上下文又也会导致推理时间增加。

为精确选择当前补全位置关联的代码引用，制定了多项策略以提高工具的性能，如代码排序策略。不仅要求工具在端侧具备收集上下文的能力，还要通过预训练教会模型感知这些上下文引用，从而使生成的结果更加准确。团队构造了大量数据覆盖各种语言，以帮助模型理解引用关系和生成关系。

通过库内文件感知策略，成功提升了 3 倍的生成准确率，显著改进了代码生成工具的性能和准确性。

（6）本地库检索增强

本地库内的检索增强功能。用户可以向大模型提出代码任务，如查询库中的特定业务逻辑、完成文件填充、执行增删改查操作或修复简单 bug 等。通过自然语言命令，LLM 可以根据库内的上下文信息做出决策，并生成相应的结果。

整体流程包括：

• 需求细化
• 库内检索
• 向量召回
• 结果重排

在检索过程中，面临的挑战是如何对本地库进行向量化、确定向量存储的位置，本地还是云端。考虑到代码安全性，尤其是金融行业，选择将向量存储全部放在本地，进行本地检索，远程服务限制为 Embedding 服务。

检索过程优化，包括向量检索和相似性检索，以确保找到足够多且准确的上下文信息，大模型能够根据人类的意图做出相应的判断。实现本地库内的检索增强，提高代码生成的准确性和效率。

（7）企业数据个性化场景

针对企业数据个性化场景，特别是金融领域，企业拥有大量的业务资产积累，如组件库、已完善的业务逻辑。对于新员工而言，如何有效利用这些既有资产编写新的逻辑至关重要。

• 项目管理场景

引导大模型生成符合企业特定格式和内容规范的需求文档，以辅助编写需求。

• 开发场景

大模型输出的代码要遵循企业制定的编码规范，能够引用企业内部的二方库和 API、推荐专家编写的成熟业务逻辑。在 SQL 编写场景中，大模型应熟悉业务的表结构，并能生成相应的 SQL 业务逻辑。在前端场景，我们拥有大量自研的组件库和前端框架，大模型应推荐符合内部要求的代码。

• 测试环节

推荐的代码必须满足内部标准，以确保其可用性。

• 运维场景

大模型能够快速响应粘贴的错误信息或故障描述，基于先前的故障处理经验和运维手册，给出相应的解决方案。

① 企业数据个性化流程

目前主要采用 RAG（Retrieval-Augmented Generation）和 SFT（Supervised Fine-Tuning）两种方法。需要特别注意几个方面：

• 数据处理

对代码进行处理，如格式化、清洗以及安全质量评估。筛选出最通用且最可靠的代码，用于模型训练。文档处理也遵循相同的原则。

• 微调训练

考虑开放数据与私有数据的混合比例，需要确定如何通过少量代码实现模型的优化。

• 检索增强

代码补全的检索增强场景与知识库问答的检索增强场景存在差异，需要采取不同的流程和方法。

SFT 可以通过微调训练在平台上直接实施。这里简要介绍 RAG 的应用场景和企业级增强方案的优势。

② 企业级检索增强方案

RAG 是目前实现个性化最容易落地的场景之一，系统架构层次包括：最底层是模型推理服务和向量检索服务；上层是知识库管理服务，左侧进行相应的数据处理，右侧进行向量的召回和排序；最终生成相应的结果。

在这一过程中主要完成代码补全和检索增强。由于代码补全的检索增强与文档处理过程不同，过去几年，我们与复旦大学合作进行了一些学术研究，并发表了相关论文。在测试过程中发现使用 1.8B 的模型结合 RAG，可以产生与 7B 模型相当的代码推荐准确率。

充分利用这一技术，可以显著提高代码补全的采纳率，目前的补全模型 7B 参数量通过 RAG 可能实现相当于 14B 甚至更高参数量模型的生成效果。

03

未来的软件研发 Agent 产品演进

Copilot 类产品，如通义灵码，主要是作为 IDE 插件提供代码辅助功能。未来，软件开发必将转向 Agent 模式，尤其是多 Agent（Multi-Agent）模式。

3 月份 DevIn 的出现加速了整个行业对多篇 Agent 模式的关注。通义实验室的算法工程师发起的 OpenDavin 项目。该项目在短短两周内就获得了 2W Star 的关注，业界普遍认为这一技术可能在半年或一年内具备生产级落地的能力。

1. 研发领域多智能体协同

目前多智能体协同的整体设想、架构及演进路线在业界大致相同。最关键的问题在于如何逐步实现这一设想，使其达到生产级的可用性，而不是仅仅停留在目前 10% 左右的解决方案上。

DevIn 仍存在一些局限性和问题。例如，DevIn 生成的代码可能包含人类工程师通常不会犯的错误。此外，swe-bench 很多的问题实际上可以通过修改单文件中的几行代码来解决，DevIn 只能解决其中一小部分。

尽管 DevIn 的视觉效果令人印象深刻，加之网络的广泛传播，可能会让人们认为这一技术即将到来，但实际上要达到真正的生产级可用性，还有相当长的一段距离。

2. 软件研发领域 Agent 可行性路径

从生产级落地的角度出发，我们计划采取更为务实的方法，分四个阶段实现多智能体协同模式：

• 单库的问答系统

利用单库的 RAG 技术和固定步骤或 AI 能够分解的简单步骤，完成单库范围内的简单编码任务。例如，在一个 MyBatis 文件中实现增删改查功能，或在前端文件中添加一个按钮，这些任务具有明确的上下文要求，步骤也相对简单。我们首先致力于实现这一阶段的目标。

• 编码智能体

具备一定自主任务规划能力和使用工具能力的编码智能体，可以利用编译器检测代码是否能够编译通过，并自主进行修正。这样的智能体能够完成单库范围内的编码任务，而人类开发者则负责编写对这些任务的具体要求。智能体将逐步学习如何根据自然语言的要求自动拆解步骤并完成它们。

• 测试智能体

测试智能体能够理解编码智能体的需求和步骤，阅读其代码并生成测试用例，然后执行测试。

• 多智能体协同

目前我们内部也在投入大量资源来推动这一方向的发展。无法确切预测在接下来的 6 到 12 个月内这项技术能走多远。乐观估计，12 个月后，swe-bench 可能实现 30% 到 50% 的自动化。如果达到这一水平，它将具备一定程度的落地能力，能够完成一些简单的需求或缺陷修复。智能体模式的市场空间以及它带来的效能提升，可能不再是目前的 10% 到 15%，而是可能提升到 30% 以上。这是今年值得期待的一项新技术突破，它将改变人机交互的方式，大幅提升效能。

3. Multi-Agent 概念架构

Multi-Agent 概念的架构如上图所示，其中包括计划中的多智能体协同系统，以及上下文、工具的使用、环境等。

4. 未来智能软件研发工具链形态

未来，智能软件研发产品将向以下方向发展：

在架构底层，无论是当前的代码助手还是未来的智能程序员，其基础架构部分都是相似的，包括引入代码 AI 智能层以及模型核心能力。向上层发展，有两种模式：一种是 Copilot 模式，另一种是 Agent 模式，即 AI Bot。AI Bot 未来将拥有自己的工作区，在该工作区中可以持续运行并使用涉及需求看板、代码托管等工具。

AI Bot 的形式将无处不在，它可以在 IDE 中随时被唤醒，帮助完成编码任务。也可以在研发门户中，即原有的 DevOps 工具链的任何位置被唤醒，帮助完成具体的开发动作。同样，它也可以在即时通讯(IM)工具中被唤醒，帮助完成其他任务。

因此，AI Bot 实际上会是一个智能体，它与 Copilot 模式有显著的不同。期待在今年的云栖大会上能够向大家展示令人满意的产品形态，并提供体验机会。

04

问答环节

Q1 ： 通义灵码是通义千问系列中的一款产品，基于通义大模型构建。您提到，产品的发展既涉及技术层面也涉及产品路线，旨在不断提升产品的易用性。对于您个人而言更侧重于哪一方面？是技术还是产品？如何协调这两者？

A1：产品和技术并不冲突，代码助手是一个技术驱动型产品。以采纳率为例，可以看到技术优化对提升采纳率的重要性。有银行的同事询问采纳率提升的主要来源，无论是产品侧的优化、前端插件侧的优化，还是人机交互的优化，根据后台数据分析，模型优化是最主要的因素。模型优化得益于提取了更高质量的数据，投入了更多的训练资源，并对不同框架和语言进行了调优。因此，技术是产品成功的关键。

对于个人而言，更偏向于技术还是产品？如果必须选择,个人更偏向于技术。随着技术的发展，产品方面的东西将变得越来越简单，人机交互将变得更加直观和便捷。

Q2 ： 您认为 Multi-agent 方向比 Copilot 有更广阔的前景，能否解释一下原因？

A2：智能体具有自主规划能力，这使得它在人机交互方式上不太依赖于人的引导。人们只需给出目标，智能体就会去执行并接受纠错，这与 Copilot 模式完全不同。从宏观角度来看人介入得越少，生产力的释放就越大。

另外，Agent 模式能够更好地发挥大模型的核心能力。例如，目前的代码助手背后的模型参数可能是 720 亿或 300 亿。要做 Agent 可能需要千亿级参数以上才能达到非常好的效果，因此它更能发挥大模型未来的潜力。

另外，Agent 也需要人进行一些高层次的设计，比如，它的工作流程是什么样的，需要执行哪些动作，调用哪些工具。

本质上与 Copilot 的区别，它的标准操作程序可能还是由研发工具的人来设计,但它具有任务的自动分解能力和对人类目标的理解能力，这是 Copilot 模式所不具备的，而这些能力正是影响我们开发效能的一个重要因素。

Q3 ： 通义千问模型在生成代码过程中是在解决从错误到正确的问题，还是在考虑如何从好到更好？例如，有些代码虽然可以运行，但可能存在时间复杂度高或代码冗长等问题。是否考虑让模型生成更精简或更高效的代码？如果考虑这个因素，如何在训练层面实现或解决？

A3： 目前模型主要解决的是生成代码的问题，还没有达到优化代码的阶段。以 CodeQwen 模型目前的规模来看，生成的代码并不一定是最优的。我们经常进行这样的实验：让模型针对一段输入生成代码，然后使用 72B 参数的模型对其进行优化，会发现存在很多问题，甚至可能有一些漏洞或潜在问题。是目前技术的一些局限性。要实现这一点，可能需要更大规模的模型。

以上就是本次分享的内容，谢谢大家。