【导读】
随着人工智能的快速发展，代码大模型逐渐成为软件工程领域的研究热点。代码大模型利用大量数据进行训练，可以在很大程度上提高开发人员的工作效率，降低开发成本。本文作者对代码大模型在软件工程领域的应用前景进行了深入探索，并带来了落地及产品的标品化建设经验。
本文出自
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 进行持续收集，继而反哺系统并进行有效性验证，从而打磨迭代出新模型；成本/算力；质量/安全。
总体来看，成本和体验会极限拉扯，准度评测保证模型质量，安全保护资产，这是代码大模型不会消停的挑战。对此，如何确保代码大模型实现“好、快、准”？这就涉及到了三大要素：
基于大模型成本与体验的极限拉扯，我们在深入思考怎样才能让 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 为驱动力，与各个环节发生协同、推理、反思。
