代码大模型与软件工程的产品标品之路 | 新程序员

【导读】随着人工智能的快速发展，代码大模型逐渐成为软件工程领域的研究热点。代码大模型利用大量数据进行训练，可以在很大程度上提高开发人员的工作效率，降低开发成本。本文作者对代码大模型在软件工程领域的应用前景进行了深入探索，并带来了落地及产品的标品化建设经验。

本文出自 2024 全球软件研发技术大会中的演讲，同时收录于《新程序员 008》。《新程序员 008》聚焦于大模型对软件开发的全面支撑，囊括 Daniel Jackson 和 Daniel Povey 等研发专家的真知灼见与“AGI 技术 50 人”栏目的深度访谈内容，欢迎大家点击订阅年卡。

作者 | 汪晟杰

责编 | 唐小引

出品丨新程序员编辑部

软件开发中以编码辅助、代码沟通为最高频的使用需求，有超过一半的开发者期望 AI 帮助写单测的需求强烈。我们需要 AI 不仅能够进行代码补全，还能帮我们解决问题、丝滑接手祖传“屎山”代码。归根结底都是 AI 究竟是否能够理解我们的工程，这就对大模型提出了挑战。

在本文中，我将重点围绕以下几个方面和大家探讨我们对于代码大模型和软件工程的探索。

第一，软件工程在 AISE 上碰到的坑，以及未来可能带来的价值点。

第二，怎么让 AI 代码助手类的产品去理解代码工程。

第三，AI 是如何做到针对工程项目不同的场景和不同的角色。它不仅仅是理解我们的工程，还想要能感知到这个工程下现在、接下来要做什么，能不能帮我做一下重构或者一些其他方面的事情，来帮助缩短 DevOps 生命周期，我们称之为 SDLC 的优化。

最后，我们将讨论老板们关心的研发效率问题。研效可能有很多的工具在做，但毕竟还是工具，在管理者的层面上需要定义研效。那么研效有没有可能对 AI 辅助类工具落地并标准化指标，并建设出一系列的 AI 辅助类工具带来的新的研效提升点。

软件工程+AI 助手的挑战

首先，我们需要明确什么是 AISE？AISE（AI Software Engineering）可以理解为“软件工程 3.0”，即基于大模型时代下的软件工程。事实上，AISE 本质上是以 AI 为心脏的一套链路，它需要解决 DevOps 复杂度的问题。DevOps 的链路非常长，通过 AI 是否能够优化升级敏捷，甚至未来抛弃敏捷？是否能以多智能体的方式，让 DevOps 收获全新的体验？这就是对于 AISE 的定义。

当前，AISE 总体仍处在起步期，但我们可以看到越来越多的 AI 工具开始涉足到软件开发的不同阶段。从编写代码、测试到运维等 SDLC 软件研发全生命周期中，越来越多的产品正在以 AI 为中心去重塑它的产品形态，其中尤以开发环节为甚。据信通院调查显示，超过 70%的企业在软件开发阶段应用了大量的大模型等 AI 技术，其次是软件测试、运维。我从产品角度认为，这几项都是未来我们可以攻破的方向。

国内外主流的开闭源代码大模型都在不断提升其规模、参数，其实是想要让代码获得更大的 Token、窗口，在有限的算力条件下能够推出更多的内容、有更好的意图识别。由于代码大模型的入局，AISE 的应用场景正是百花齐放时。那么，代码大模型究竟有什么特点？首先是具有秩序性，和人类阅读不同；二是逻辑性，它必须有强大的推理能力，这本质上是有一套语法的前后逻辑调用链；第三是上下文的感知度，在当前代码的类里是否能感知到别的类的存在、别的类的函数定义等。基于此，我们可以结合工程方式辅助来让大模型更好地懂工程。

在智能编码方面，我们很早就开始和企业客户进行沟通，基于国内行业客户的普遍诉求，我们总结出了企业智能编码的“SMAFe”原则，即：

• Security（代码安全）：保证基础模型里用于训练的代码是安全的，保障补全出来的代码是安全的。

• MaaS（多模能力）：由于各部门的业务特性不同，可能需要多个个性化的行业模型。并且，根据不同业务特性，需要进行二次训练，补全模型。

• Analysis（数据看板）：保障二次训练以及行业代码的训练效果，同时有哪些效能指标可以帮助管理者观察工具对开发工作的提升。

• Full（丰富场景）：代码补全是高频场景，优先度最高。在此之外，还有代码扫描、评审以及 DevOps 上下游规划。

• extension（扩展机制）：在对话平台之上构建自定义的 Agent 能力；能够自定义开发，通过自定义提示词和 Function call 等接入业务系统（注：e 是特别小写的能力，如大写则为企业在已有的标品上进行扩展）。

代码大模型有很强的推理能力，可能会使用 C++、C#、Rust 等各种语言，但如果让它去做企业级的工程，还是需要学习工程结构、研发规范等。如何让代码大模型“理解工程”？这就需要从三个维度来着手，分别是：准度/评测：让模型做红蓝对抗，比如赞踩、打分的反馈系统。将 Bad Case 进行持续收集，继而反哺系统并进行有效性验证，从而打磨迭代出新模型；成本/算力；质量/安全。

总体来看，成本和体验会极限拉扯，准度评测保证模型质量，安全保护资产，这是代码大模型不会消停的挑战。对此，如何确保代码大模型实现“好、快、准”？这就涉及到了三大要素：

• “数据安全 = 好”：可以用大模型对抗大模型，用大模型来感知生成的代码是安全的，其次可以用大模型进行监督。比如开源的大模型安全工具包 LLM Guard，通过提供开箱即用的所有必要工具来简化公司安全采用 LLM 的过程。

• “IDE + 编码效能 = 快”：天下武功唯快不破，我们内部的代码补全平均耗时在 500 毫秒左右。

• “对话 + 工程理解 = 准”。

基于大模型成本与体验的极限拉扯，我们在深入思考怎样才能让 AI 代码助手能够达成高用户价值，如图 1 的框架。我们通过代码模型精调训练，在代码补全、技术对话上给开发者提高效率。这点也已在内部进行了多次论证：当产品处于非常好的体验时，会获得非常高的用户留存率。这里提到的代码生成的体验，更关注在补全性能、产品交互、以及用户开发习惯等方面。

图 1  大模型成本与体验的极限拉扯

在高留存率目标驱动的同时，还必须控制优化好成本，防止高频访问导致速度下降与成本上升而劣化产品体验。需要重视 Bad Case 反馈与处理闭环、针对性专题性能调优、采取批量计算等策略；通过用户看板观察总结模型版本升级带来的能力增益。最终通过一系列平衡手段，实现 AI 代码助手在补全场景下的产品价值。

懂工程的 AI 辅助工具的最佳路径

那么对于一个懂工程的 AI 代码助手，怎样才能做到最佳使用范式？用好 Coding Copilot 有几个关键的点：

• 首先是 IDE 的深度体验，我们的代码助手在起步之初便定位要做 GitHub Copilot 的平替，因为这能够让开发门槛大幅降低，对于开发者而言，切换成本很低。

• 通过 Agent 扩展实现 Prompt as Code，灵活地在工程、仓库、版本管理、流水线等都进行 Agent 扩展。

• Life of a Completion 是 GitHub Copilot 定义的一套范式，它并不关心你的代码是什么样子，会通过一种策略感知持续性地从源码中提取有用的提示词，并组装给模型最终产生想要的效果。

• 程序员的编程习惯——Tab 与 Backspace 之争由来已久，我们也对智能编码习惯进行了定义，希望能够实现 3TNB 的目标，即“Tab Tab Tab No Backspace”，根据注释生成代码，根据函数定义生成函数体实现，根据上文生成下文代码，根据当前代码行输入，补全整行代码。

接着是大家熟知的提示词工程，提示工程的基本原理，可以总结为 3 个 S，核心规则是创建有效提示的基础。

• 单个 Single：始终将提示集中在单个、定义明确的任务或问题上。

• 具体 Specific：确保说明明确且详细，最好能附带一个示例或者模拟信息结构。具体且具象带来理解会带来更精确的代码建议。

• 简短 Short：在具体的同时，保持提示简明扼要。这种平衡确保了清晰度，而不会使腾讯云 AI 代码助手超载或使交互复杂化。

我们在使用大模型时，在 Prompt 中注入给大模型的 N 个提示样例数据，帮助大模型输出结果。N 指的是样本的数量，根据 N 的个数不同，在代码大模型中就相应地有这样几种说法：Zero-shot：对话总结、下轮对话建议；One-shot：一次新会话，一次当前上下文补全；Few-shot（少量样本）。

AI 对工程项目的探索思路

单元测试是软件工程 3.0 中要解决的“难啃骨头”，更偏向代码重构，测试是个专项领域，而重构这件事是软件的最高峰。单元测试与 AI 的结合面临三个问题：测试方法种类多、框架多；项目本身不具备可单测功能，难以 Mock；生成质量难以运行，无标准最佳实践。

针对单元测试+AI 的挑战，我们有一些可行性的探索，包括：增加示例代码，感知框架；语法树找相关跨文件，依赖文件的调用链；策略感知 Mock 对象，生成完成可执行单测。不同语言、不同框架对应不同的单测模型，是目前模型层面上的可探索之路，同时也需要给大模型更多的提示词来帮助大模型理解。对于软件工程 3.0，智能体也将会发挥巨大的单元，并以 AI 为驱动力，与各个环节发生协同、推理、反思。

研效+AI+标品化建设

本质上来说，AI 辅助类工具与 DevOps 一样，都是研效工具且是强运营产品。但 AI 代码助手这类产品不同于人们已经熟知的 DevOps，它还很新，因此如何让产品变得标品化至关重要。

对于老板们一直关注的指标问题，国外有开发者总结了利用 25 个指标提高开发者的工作效率，其中较为关键的是：

• 编写代码总行数（TLOC）：用于衡量代码行总数，包括手动和 Copilot 生成的贡献。

• 每份贡献的平均代码行数（ALOCC）：用于评估每次开发工作贡献的平均代码行数，展示每次贡献的粒度。

• 使用 Copilot 的代码贡献百分比：量化 Copilot 贡献的代码比例，展示其在开发过程中的集成。

• Copilot 建议后代码更改的百分比：通过追踪开发者修改生成的代码评率来衡量 Copilot 建议的有效性。

• 代码变更：测试一段时间内对代码库所做的更改的频率和程度。

总体而言，所谓标品，就是希望这个软件是一个单纯干净的软件，尤其工具类软件更要做到足够小而美。例如，辅助类工具就只是辅助类工具，无需连通别的系统或把 DevOps 串起来之类的，这样无论在什么环境下它都能运行。对于产品而言，能够实现一键部署、扩展业务能力简单、接入系统简单、企业易于定制、支持信创环境、无其他耦合系统；对于运营而言，还能够赋能老板汇报，为什么要用 AI 代码助手。

结语

AISE 已来，下一个 AI 时代改变了编码习惯和过程，我们需要在代码大模型的极限拉扯下对产品与体验进行权衡。深度探索提示工程（N Shot、3S 等）、代码模型能力和 AI 应用框架是 AI 产品的重要组成部分，它们可以帮助我们更好地定义新的软件模式，而产品开发指标会作为新的研效指标。多智能体的协同战局已经拉开序幕，未来，AI+CDE，即通过多智能体的有机结合，可以在云开发环境中利用 AI 自主完成全套开发流程直至最终上线。

大模型刷新一切，让我们有着诸多的迷茫，AI 这股热潮究竟会推着我们走向何方？面对时不时一夜变天，焦虑感油然而生，开发者怎么能够更快、更系统地拥抱大模型？《新程序员 007》以「大模型时代，开发者的成长指南」为核心，希望拨开层层迷雾，让开发者定下心地看到及拥抱未来。

读过本书的开发者这样感慨道：“让我惊喜的是，中国还有这种高质量、贴近开发者的杂志，我感到非常激动。最吸引我的是里面有很多人对 AI 的看法和经验和一些采访的内容，这些内容既真实又有价值。”

能学习到新知识、产生共鸣，解答久困于心的困惑，这是《新程序员》的核心价值。欢迎扫描下方二维码订阅纸书和电子书。