【导读】当编程成为最高频的 AI 应用场景，代码大模型的技术与产品发展之路该怎么走？本文作者从大模型软件研发的三大阶段和四大技术难点出发，分析了 AI 如何提升编程效率，并预测了未来软件研发工具的形态，终极目标是实现 AI 程序员，通过多智能体协同工作，大幅提升研发效率。
本文整理自阿里云云效、通义灵码产品技术负责人陈鑫在 2024 全球软件研发技术大会中的演讲，同时收录于《新程序员 008》。《新程序员 008》聚焦于大模型对软件开发的全面支撑，囊括 Daniel Jackson 和 Daniel Povey 等研发专家的真知灼见与“AGI 技术 50 人”栏目的深度访谈内容，
大模型带来了前所未有机遇，突破传统软件工程和研发效能工具的局限，让 AI 成为软件研发必选项。
据统计，当前大模型技术近 30 %的应用需求来自于软件研发，在软件研发领域的应用也已经从简单的代码辅助生成，演进到能够实现自主处理和开发，市场上丰富的代码辅助工具也验证了这一点。
这些工具借助大语言模型来提高生成代码的准确性和性能，同时强调数据个性化的重要性，以满足不同企业和个人的编码习惯。我一直在思考，怎么才能进一步挖掘大语言模型的强大推理能力、理解能力和分析能力，给研发提供更强的辅助？代码大模型以及相关产品和技术发展之路该怎么走？
接下来，我将从大模型软件研发的三大阶段，四大难点等角度深入剖析。
自AI技术浪潮再度袭来，大模型在编程领域的普及是个不可忽视的趋势。据统计数据显示，大模型技术近 30 %的应用需求来自于软件研发，编程成为最高频的 AI 应用场景。编程领域代码生成也是大模型擅长的方向，它可显著提升内部工作效率，让开发者协同的方式变得更加优雅、高效、流畅。AI已成为软件开发行业提升效率的关键要素。
据 CSDN、《新程序员》发起的《2024 中国开发者调查报告》显示，专门为开发而打造的 AI 辅助编码工具上，通义灵码使用率位居第一，占比 19 %。生成代码、解释 Bug 并提供修正、生成代码注释或者代码文档是开发者常用 AI 辅助编码工具来实现的事情，分别占比 41 %、29 %和 28 %。而我们正努力通过大模型与软件研发工具链的融合，逐步优化这些任务。
图 1 大模型对软件领域的影响
1、编程事务性工作的普遍替代
开发者的工作中存在大量重复性任务，例如编写胶水代码、框架代码和简单的业务逻辑。这些任务并非开发者核心关注点，如果大模型可以有效替代这些重复性工作，将显著提高个体效率。
此外，编程过程中通常涉及大量角色的协同工作，如产品经理、架构师、开发、测试和运维等。沟通往往耗时费力、协作成本高。如果能引入智能体，打造“超级个体”，将部分编码任务交由 AI 完成，就可以减少复杂的协同工作，提高整体协作效率。
2、知识传递模式的革新
传统的知识传递方式主要依赖于口口相传，如 code review、培训和代码规范的宣导等，这些方式往往滞后且效率低。智能化的研发工具链可以直接赋能一线开发者，提升团队整体水平。未来，每个团队可能会有专门擅长知识沉淀和梳理的成员，通过不断训练和优化大模型，使整个团队受益。
纵观整体趋势，大模型软件研发相关技术将分三步演进：
如 GitHub Copilot、通义灵码这类工具作为 IDE 插件，安装后可以显著提升编码效率，但并没有改变现有的编程习惯和研发工作流。AI 只是生成代码、编写测试或解释问题，最终的校验和确认依然由人完成，这个阶段，依然以人类为主导。
AI 可以通过智能体技术自主校验生成的结果，例如，AI 编写测试用例后，能够自主判断测试是否通过、能否解决程序遇到的问题或发现新的问题。当我们进入智能体阶段，开发者可以减少对 AI 生成结果的人工校验。在此阶段，虽然仍以人类为主导，但AI已展现出独立完成特定任务的能力。此时将出现一条明显的产品分界线。
多个智能体协同工作，并由大模型进行规划，完成复杂任务，如编写测试、写代码、撰写文档和需求分解等，而人类主要负责创意、纠偏和确认。这一阶段，AI 不只是 IDE 插件，而是可以实现功能的自主开发。代表性的产品有 GitHub Workspace 和今年 6 月阿里云刚推出的 AI 程序员，这些都标志着我们正在迎来 AI 自主化编程的时代。
以上前两个阶段，软件效率的提升大约在 10 %至 30 %之间，包括编码效率的提升 和 DevOps 流程的优化。那么，在第三阶段，我们可以通过打破现有的软件研发流程框架，面向 AI 设计新的编码框架和编程模式，效率提升有望突破 30 %，达到 50 %甚至 70 %。
死磕 Copilot 模式四大核心技术难点
接下来，当我们聚焦每个阶段，现有产品、技术发展的现状以及技术细节，就会发现未来还需攻坚的技术难点。以第一阶段最常见的 Copilot 模式为例，它主要分为以下几层：表现层、本地服务端、服务端、模型层、数据处理层、基础设施层。
图 2 Copilot 阶段通义灵码的核心功能架构
当我们聚焦现有代码助手产品技术发展的现状，以及技术细节，就会发现未来需要攻坚的难点主要有四点：
根据内部调研报告显示，准确率才是产品的核心，开发者可以接受慢一点，也可以接受有瑕疵，但准确率才是决定能否应用于生产、会不会持续使用的最关键因素，而过硬的基础模型能力是准确度的基础。我们通常认为模型是产品能力的上限，一个靠谱的基础模型是首要的。
通义灵码补全模型。它专做代码补全，被称为“ CodeQwen2 ”技术模型，是目前世界范围内非常强大的模型，在基础模型中排名第一，主要通过持续训练，提升其跨文件感知能力、生成代码能力及各个语言的细节优化，纠正其基础模型上的一些缺点，最终训练而成。
通义灵码问答模型。要想模型不仅基础能力强，还能很好地处理专项代码任务，就需要构造大量数据用于训练。单元测试、代码解释和代码优化等复杂任务，都需要构造大量数据进行训练，让模型遵循固定范式，从而持续输出稳定的结果。阿里目前基于 Qwen2 模型进行训练，它支持最大 128K 的上下文，不论是处理具体代码任务、Agent 任务，还是 RAG 优化，都表现出色。
除此之外，还需补全信息准确度。开发者在写代码时，不仅关注当前文件，还有查看引用、工程框架及编码习惯等。因此我们在端侧还设置了复杂的代码分析功能，专门构建整个工程的引用链及相关数据，将其转化为全面的上下文传给大模型进行推理。在代码补全方面，我们进行插件与模型的联合优化，每增加一种上下文都需要构造大量数据训练模型，使其能感知到输入上下文与预测结果的关联关系。通过一系列处理，可大幅降低模型生成的幻觉，使其更好地遵循当前工程开发者的习惯，模仿人类编写相应代码，从而提升生成代码的质量。
图 3 通义灵码补全准确度的方式
如何解决代码生成既快又好的问题，还是得在性能方面下功夫。各种代任务通常不是由单一模型完成的，而是多个模型组合完成。因此，在代码补全方面，我们使用了 CodeQwen2 这个 7B 参数的小模型能保证在 500 到 800 毫秒内完成推理，做到快；在代码任务训练方面，使用千亿参数模型成本高且不划算，用中等参数模型训练，性价比高且更擅长；对于问答任务，通过大参数模型 Qwen-Max 和互联网实时检索技术，可以快速且准确地回答这些问题。
通常，采用多个模型组合来保证时延的优化是比较靠谱的做法。大参数的模型，具有广泛的知识面和强大的编程能力，能够获取实时支持；各种加速和缓存技术，包括在端侧使用流式补全也可以降低延时；使用本地缓存、服务端缓存，再加上推理加速等多种技术，可以兼顾实现速度和准确性。这些措施共同作用，能让通义灵码能提供高效、准确的编程辅助。
图 4 通义灵码提升推理性能的方式
数据个性化依然针对两个典型场景：代码补全和研发问答。
图 5 在代码补全、研发问答两方面提升推理性能
在代码补全中，对于相似逻辑的编写，可以用企业已写过的优质逻辑代码来生成，避免重复造轮子。在自研框架的使用中，尤其是在前端开发，每个企业的前端框架往往不尽相同，如果直接使用基于开源数据训练的模型，生成的结果可能会有瑕疵，可以通过 RAG 技术，使员工在代码补全过程中实时获取所需的参考范例，从而生成符合企业规范的代码。
而研发问答这一领域相对成熟，文档问答、API 生成代码规范、代码校验等比较简单就能做到，假设开发者选中一段代码并请求模型根据团队规范进行修正，其背后的原理是通过 RAG 技术，模型能够检索团队当前语言的规范，并据此对代码进行校验和生成，这些都属于数据个性化场景应用。
代码补全场景更加关注时延，力求将检索时间降低到 100 毫秒以内，技术实现有一定难度。而研发问答场景更注重精准度，目标是召回率达到 70 %以上甚至 90 %以上，以提高回答效率。尽管优化目标不同，两者在基础设施上都涉及知识库管理、 RAG 流程、推理引擎和向量服务，这也是通义灵码重点优化的方向。
为解决代码的安全隐私问题，我们设计了全链路安全防护策略，让企业可以以较低的成本享受到 AI 的能力，每月仅需一两杯咖啡钱。
- 加密端侧代码，确保即使请求被拦截也无法复原代码；
- 制定本地向量存储和推理全部在本地完成的策略，除非是主动上传的企业级数据，否则代码不会上传到云端，保证了云端没有代码残留，即使黑客攻破了通义灵码集群，也无法获取用户数据，确保了安全性；
-
设置敏感信息过滤器，确保所有企业上传的代码都合规，能够放心使用公共云的推理服务，实现极高的性价比。
通义灵码在以 Copilot 为代表的代码助手方面已经比较成熟，从满意度调查和替代率两个重要方向来评估它在企业中的满意度。基于 1124 份有效样本，超过 72.5 %的受访者在编码工作效率提高方面给予了四分以上的评分（总分为五分）。针对后端语言，通义灵码生成代码的替代率在 30 %以上，而前端由于存在大量的复制粘贴操作，生成率略低，约为 20 %左右。
那么，在大模型软件研发相关技术演进的第二阶段，我们如何从简单的代码任务逐步走向复杂的代码生成？
2024 年 3 月，Devin 发布，只需一句指令，它可以端到端地进行软件开发和维护。虽然只是一个预览版，但它让我们看到 Multi Agent 方向的可行性。这是从 0 到 1 的突破，Devin 显著提升了 AI 在实际编码任务中的应用能力。同年 4 月，GitHub 发布了 Workspace，它是编码自动化的初步尝试。
以上再次证明了 AI 在代码生成领域的潜力巨大，尽管还有很长的路要走，但这表明我们正在朝着实现更高效、更智能的编程环境迈进。在技术路线上，我认为需要分为四个阶段逐步发展，而非一次性跃迁。
图 7 从单一 Agent，走向多 Agent 架构的四大阶段
第一阶段：单工程问答 Agent
要解决基于单工程的问答需求。典型的功能如代码查询、逻辑查询、工程解释，基于工程上下文的增删改查接口、编写算法，在 MyBatis 文件中增加 SQL 语句等，都属于简单任务，已经充分利用了单库的 RAG 技术以及简单的Agent来实现。这为更复杂的多 Agent 协同系统打下了基础。
第二阶段：编码 Agent
进入能够自主完成编码的阶段。Agent 将具备一定自主任务规划能力，以及使用工具能力，可自主完成单库范围内的编码任务。例如，在集成开发环境（IDE）中遇到编译错误或缺陷报告时，用户可以一键让 AI 生成相应的补丁。
第三阶段：测试 Agent
到达具备自主测试能力的 Agent 阶段，它不仅能够编写单元测试，还能理解任务需求、阅读代码并生成测试。不管是单元测试还是黑盒测试方法。而另一些 Agent 可以用于架构分解、文档编写、辅助阅读等功能。
第四阶段：Multi-Agent
接下来，多 Agent 基于 AI 调度共同完成任务，就可以实现更复杂的任务管理和协作实现，从需求->代码->测试的全流程自主化。我们的终极目标是 AI 程序员的水平，类似于 Devin 项目。这一阶段将涵盖更复杂的编程任务，需要更高级的 AI 调度和协同能力。
Code Agent 落地门槛：问题解决率至少 50 %以上
从整个技术路线图来看，前三步通义灵码已覆盖。它展示了整体工作流，以本地库内检索增强服务为核心，提高了代码和文档的准确检索及重排效率，并结合企业知识库，增强了系统的综合问题解决能力。
这一过程需要不断优化，其过程涉及几个关键点：首先，深入理解需求，这是整个优化流程的基石；其次，提升需求在库内检索的成功率，它直接影响到后续步骤的效率与效果；再者，模型本身的性能提升，将检索到的信息整合并解决问题的能力至关重要，这是 Code Agent 的前身。
接下来要重点攻克的是 Code Agent 技术。SWE-bench-Lite 测试集是业界公认的Code Agent 测试标准，在测试集上，通义灵码 Agent 实现了 33 %的问题解决率，领先业界。然而，要推动这一技术走向实际应用，仍面临诸多挑战。
图 8 灵码 Agent 在 SWE-bench-Lite SOTA 测试集的表现
难点一：当前 Code Agent 的效果高度依赖 GPT-4 等先进基础模型，基础模型的能力可能是整个领域往前走的一大阻碍，这限制了技术的普及与自主可控性。
难点二：上述方案在调优上比较困难，容易牵一发动全身，难以快速迭代；
难点三：长上下文依赖和多轮次复杂 Action 处理仍是技术瓶颈；
难点四：模型调优问题，这是当前的一个重要挑战，即便是使用 GPT-4，我们在SWE-bench-Lite SOTA 测试集上的表现也仅为 30 %以上的问题解决率，这与生产级可落地的标准仍存在较大差距。因为测试集中不仅包含了相对简单的单文件修改任务，还涉及到了更为复杂的多文件和多任务修复场景，这对模型的上下文理解、逻辑推断及代码生成能力提出了更高的要求。要达到生产级可落地的标准，需要至少将问题解决率提升至 50 %以上，继续加大技术研发投入是必要的。
未来的软件研发工具形态
对于通义灵码仍有差距的第四阶段——Multi-Agent 阶段，我们也已经有了清晰的概念架构，其工作流程大概是：用户输入指令后，一个复杂的多 Agent 协同系统随即启动。该系统核心解决三大问题：
-
首先，通过结构化的任务管理，模拟人类团队分解大型任务的行为，实现高效协作；
-
其次，简化工作流程，将复杂任务细化为小任务，并借助 Agent 特性逐一执行；
-
最后，高效执行任务，让每个智能体专注自身任务并协同工作，共同完成复杂任务。
底层为 AI 基建层，为中层的通义灵码与AI程序员等提供基础支持，涵盖运行环境、模型推理服务、模型微调 SFT、检索增强 RAG、企业管理功能及核心模型。在 AI 基建层，工具共享、不同模型各司其职，这进一步验证了我们的技术演进路线。
通义灵码与中层的 AI 程序员之间存在递进的技术演进关系，虽然共享同一 AI 基建，但在产品交互及与开发者的连接方式上，两者差异显著。AI 程序员拥有自主化工作区，采用问答式交互方式，这种非传统 IDE 形态却能无缝连接最上层的 IDE 端、开发者门户及 IM 工具，成为开发者主要入口的延伸。
右侧，与现有 DevOps 工具链紧密链接，在不颠覆现有 DevOps 或 CICD 流程的基础上，极大地简化和优化了这些流程。
AI 程序员边界明确，专注于从任务输入到文档编写、测试用例测试完成的全过程，未涉及 CICD 或复杂运维操作，作为现有工具链的有效补充，它将大幅简化工具链交互，优化流程协作，对组织结构和开发者技能产生深远影响，甚至可能引领未来编程软件向 AI+Serverless 的架构转型。
当前的 Serverless 主要由各类 function 构成，并通过 workflow 紧密相连。AI 擅长独立完成单一的 function，但面对庞大、复杂的代码工程，尤其是质量欠佳的代码时，修复能力尚显不足。未来，Serverless 与 AI 融合的编程架构有望成为主流趋势，这并非无稽之谈。我们坚信，随着技术和基础模型的不断演进，预计在未来 3-6 个月内，将有相应产品推出，并有望在部分生产级场景中实现落地应用。
阿里云内部代码助手落地实况
阿里云已经全员推行 AI 辅助编码，同时充分考虑各部门的差异。面对不同部门的框架差异，主要采取两种策略。一种是通过 RAG 来实现，即根据每个部门自身需求建立知识库，用于补全和问答优化。每个部门都能梳理并优化其常用代码样例、框架示例及 API 示例，尽量保持其独特性。这种方式让一个工具能够灵活覆盖所有部门的需求。
另一种是进行模型微调，已在一些企业中尝试过。利用小规模数据集对模型进行微调，结果显示，这种基于个性化业务代码的微调能够显著提升模型的准确率，虽然有效，但其成本较高且过程复杂。
从采纳率和 AI 代码生成占比来看。目前，阿里云内部的 AI 代码生成占比已达到 31%，后端语言如 Java 的占比更高，达到 30 %以上。这些数字表明，基于开源代码训练的模型已经能够在实际应用中发挥重要作用，未来通过 RAG 的进一步优化，我们有信心进一步提升这些指标。
关于前文提到的通过前端工具将上下文学习与后端大模型结合，以在代码补全方面取得更好效果，我们主要根据不同语言的特性来解析代码的依赖关系，以构建整个工程的依赖树。当我们需要为某个文件进行代码补全时，会找到该文件所处的上下文，类似于人类编写代码时的行为。为确保代码补全的准确性，需要将当前文件的所有依赖项都纳入上下文考虑范围，否则模型可能会产生“幻觉”，即生成与上下文不符的代码。
此外，我们还会寻找与当前编写位置相似的代码片段，帮助模型理解工程内部的编写风格，为代码补全提供有价值的参考。以 Spring Boot 等框架为例，许多内部扩展或“胶水层”代码都具有一定的相似性。通过找到这些相似代码，模型能够生成更贴近实际需求的代码，从而提高采纳率。
同时我们会收集跨页面的相似组件信息，以供模型参考。判断哪些上下文对当前位置的代码生成具有更高的采纳概率，再通过算法调优来确保模型能够优先利用最重要的上下文信息，包括优先级排序、筛选和压缩等一系列操作。
一般情况下业务研发部门无需直接参与前端上下文知识的处理工作，这取决于具体的业务需求和项目复杂度。
为了进一步提升效果，我们还需要收集和处理业务单位的反馈。在实际应用中，开发者们可能会遇到一些“ bad case ”，即插件生成的代码不符合他们的期望或需求。为了优化插件的性能和准确性，我们需要基于具体场景进行调优。我们会不断优化通义灵码并持续发布先进的产品，向着大模型赋能软件开发的终极形态坚定地走下去。
