从“AI 赋能”到“赋能 AI”：ICPC 时刻之后，研发管理者最应该关注的转型指标

本文转写自思码逸创始人兼 CEO 任晶磊在 QECon 大会的演讲，扫描文末二维码即可获取本场 PDF 材料。

大家好，我是任晶磊。今天想和大家聊聊 AI 对软件工程，以及我们自身工作带来的改变。

过去这些年里，我们一直在软件度量领域深耕，处于国内领先地位。大概两年前，AI 的浪潮开始显现，起初我们只是把它视为一个市场机会，公司作为“赚钱机器”去拥抱它理所应当。但从今年开始，我的心态发生了彻底转变。下面我将从四个角度展开聊聊：

1. 软件开发本质的改变

2. 研发团队如何推动转型

3. 研发赋能 AI 的切入点

4. 如何度量 AI 提效

软件开发本质的改变

我曾像高中生读政治课本一样，喊着“软件工程 3.0”的口号，更多地像是一种“政治正确”。但当我看到 ICPC（国际大学生程序设计竞赛）最近的结果，我才无法再拒绝一个事实：软件工程的本质已然改变。

很多人可能不了解 ICPC。这个比赛 3 个人一组，解答 12 道难题，在 5 个小时内完成。参赛队伍每过一道题，桌边就会升起一支气球。

让我们代入赛场。比赛开始，“大神”们开始对着键盘一顿狂敲。可能只要十分钟，第一个气球就会升起来。我不是说在座的各位都是“垃圾”，包括我自己，能够做出一道 ICPC 难题就算是赢。我以前清华大学实验室最好的队伍，3 个人做了 6 道题，而今天 OpenAI 的模型做出了全部 12 道题。

所以，“AI 拥有人类无法企及的代码生产力”这句话已经变成了现实。今天我们人与 AI 比写代码，就像与汽车赛跑。没有打过 ICPC 的人，可能无法体会这种冲击。大家也不要再自我安慰，认为业务逻辑非常复杂所以 AI 无法胜任了。

研发团队如何推动转型？

那么，为什么我们在现实中用到的 AI 却表现得有些“智障”呢？我认为关键在于缺失良好的问题定义。

ICPC 题目之所以能让 AI 发挥出强大能力，是因为它们是定义极其良好的问题。这些题目出自人类最顶尖程序员，描述非常详细、没有歧义，且配有完整充分的测试用例。当这些条件凑齐后，AI 的能力就体现出来了。

进一步推论，既然 AI 拥有这样的能力，那就意味着我们人需要做的事情，正在发生根本性的转变。未来软件工程中留给我们人类唯一重要的事情，就是定义软件，将一个个 well-defined 问题交给 AI 去完成。未来，不再是“AI 赋能”我们去干活，而是我们想办法“赋能 AI”让它更好地干活。这是软件工程本质的改变。

有了这个共识，我们就必须行动起来积极转型。那如何起步呢？

从“渗透”到“定义”

将定义好的问题，一块一块地交付给软件。这说起来容易做起来难，要想在团队中推行这种做法，通常有两种方式：第一种是训练学习定义 spec，第二种是在 chat 中逐渐“渗透”。

后者让我想起杨振宁老先生的“渗透”型学法。他曾提过：“和我共事的西方学者有一个共同特点，他们在讨论的时候没有把问题想得很清楚的习惯，但这不妨碍他们做出非常重要的工作。这一现象值得反思。”

西方学者在讨论过程中或许会缺乏清晰的结构化定义，但最终往往却可以得出较为完整的问题定义，并进一步产出解决方案。所以，在实践“spec-driven development”时，我们不一定要在一开始就定义好所有要素，而是可以让大家在 chat 过程中，逐渐将 spec 渗透出来。这对于大多数团队来说都是一个更现实的做法，思码逸正在尝试用一些基本的工具来实现。

当大量信息蕴含在 chat 中，我们希望将这些 chat 作为研发资产进行存储和管理，同时又不想引入新的工具平台，所以我们想把这些 chat 存储到 Git 代码库中。所以，我们开发了开源工具 Tigs，可以直接将 chat 存到 Git notes 中。这样所有的 chat 都可以作为研发资产得到保存，最终可以借助这些 chat 生成一些 spec 的定义。

进而从度量的角度，我们可以关注的一个指标是 chat 覆盖率，也就是有多少 commit 是通过 chat 生成的并存储了当时的交流过程。这可以作为一个转型指标。

研发赋能 AI 的切入点

我们认为，well-defined 的问题包含两个要素：良好的问题描述和相应的测试集。前面谈了 spec，现在我们从测试切入。在座的各位可能都有测试背景，我认为我们正踩在时代的脉搏上。因为这是定义问题的一部分，也是衡量软件是否满足业务需求的关键。

而这其中以 API 为中心的测试集最重要。为什么这么讲？这要提到 10 月份 Claude 发布 Sonnect 4.5 的一个细节。除了发布新模型，它还发布了一个在线套件“Imagine”。通过视频演示可以看到，你可以与它交流，它能动态地、实时地生成前端。这预示着，未来我们与应用交互时，前端部分很可能会被大模型“吃掉”。

（插入视频号短视频）

因此，我们认为在 API 层面，做好测试，定义好问题，是符合未来长期发展趋势的。我们自己也在尝试在这方面做一些事情，包括我们在产品研发中，也在思考如何利用 AI 进行 API 测试。

警惕“Garbage in, garbage out.”

接下来，我将从智能 API 测试的角度拆解几个关键步骤和我们目前看到的一些产品层面的选择。首先，肯定要给 AI “投喂”更好的数据源，否则就会出现“垃圾进、废品出”的局面。我们当时考虑了各种可能的数据源，并从几个维度对它们进行了对比，大致排序如下：

总的来说：“API 文档”排在首位，“人工输入”次之，“调用日志”总体表现更平均。第四位是代码理解，因为代码理解中间问题很多，而测试很多时候是验证结果，不能只测试代码行为。最后才是需求和产品文档，因为这里面噪音较多。

可用的前提：清晰的 API 关系

API 文档要真正可用，还需要做不少清理和分析的工作。我们知道，写测试不能只针对一个接口，而是要针对一个场景来组合多个 API。那么，就需要梳理 API 之间的关系。这种关系最可能抽象成两类：

• refers_to：比如调用这个接口时，它的一个参数是另一个 API 的产出。这是一种很直接的 refer 关系。我们需要构建出来，这样在组合场景时，就知道该如何使用 API。

• related_to：这更通用一些，各种情况都有。比如所有涉及用户的行为都是相关的。平时测试的 API，不一定有强依赖关系，而要完成某个场景就需要把它们组合起来使用。

大家有时讨论使用向量数据库做 RAG 还是图谱。我认为实际中并不是非此即彼的选择，我们两者都会用到。实际中还有一类问题，就是跨文件关系的抽取。因为很多时候 API 并不局限在单一文件，这也需要处理。另外，整个 API 文件处理一遍，很耗 token，也很耗时间。所以，需要处理增量构建的问题。

这些具体实现里面没有秘密，没有复杂的算法，换句话说，未来这些事情都是可以让大模型干的。我们不用关心这些细节，我们只需要知道有这个问题，然后让大模型去写相应的算法就可以了。这说白了就是纯工程问题，这也是为什么我认为现在有些技术细节真的已经不那么重要了。

让 API 真正“跑起来”

我们现在产品做的很多事情，其实是在给人类“擦屁股”。比如我们会把文档中分析出来的错误反馈给用户，也就是文档可能在某些方面需要改进。因为文档和代码总会有差异，所以这里的核心是要把代码在测试环境中跑起来。只有让 AI 观察 API 真正执行的行为，才能发现一些实际中的“知识”，并在此基础上进行知识存储。这是很重要的一环。

选择怎样的人机交互？

关于人机交互，最早我们的思路比较偏向 Meta 做单元测试的思路。他们提出的理论是，如果用 AI 写一个半成品，然后让人去干预（也就是所谓的 copilot 模式），反而会浪费人的时间。毕竟 AI 现在还是经常犯错，让人检查必然会浪费一些时间。所以他们的做法是，只保留最终能跑通的代码，其他的都废弃掉。可能生成了 100 个测试，只有很少一部分是通过的。但这没关系，那就只把这很小的一部分保留下来交给人，这时候用户看到的是一个相对价值明确的结果。

一开始我们也是按照这个路线走的。但实际中，API 测试的挑战比单元测试更大，很多知识还是需要人的补充。所以我们最新的想法是，两者之间不是非黑即白，而是一个过渡。也就是说，可以从 copilot 开始，当知识不断积累，用户就会发现已经不再需要干预了，就给它一个按钮“run all”。不需要人再输入任何东西时，它就自然变成了一个异步的、可批量执行的状态。

总结一下，如果你的团队对以 API 为中心的架构还没有那么重视，是时候向这个方向前进了。我们把自己前面说的这些工作也发布出来了，大家可以直接下载使用，体验用 agent 进行智能 API 测试的效果：https://tester.merico.cn/

如何度量 AI 提效

最后，我们回到度量上。这次大会大家讨论过一些指标，比如采纳率、AI 生成代码占比等。我认为这些指标在短期或当下阶段有价值，但随着 AI 能够完成整块任务，特别细节和过程的指标会变得越来越不重要。

这些指标短期内仍然存在，主要是为了反映大模型在团队中的渗透情况。很多团队还是会通过追这个指标来驱动大家使用大模型，也有些团队会看使用量和其他指标的关系。比如，某些项目大模型的使用量或 AI 代码占比提升后，质量可能会下降，那么可能这类项目就不应强推 AI 使用。通过做这样的分析，能够得到一些有益的观察。

如果你的团队现在已经有了这类指标的基础设施，没有问题。但我个人认为，如果你今天没有办法统计 AI 生成代码占比，不用投入太多精力去建设。我们可以取其他反映 AI 使用量的指标，也能回答管理者提出的一些问题。

比 AI 过程指标更重要的，是结果指标。前面说到以后更多任务都由 AI 完成，那我们必然要度量 AI 提效的最终结果。这方面我认为“传统”度量方法依然有效。下面放了一部分“北极星”指标作为示例。

比如要度量效率，肯定要看代码的产出。今天再用代码行数评判代码产出已经完全不合理了，我上个月飙了一万多行代码。那就要用到一些程序分析的技术，所以我们做了“代码当量”这样的指标，它能尽量抵御各种噪音，抵御 AI 短时间大量新增和删除代码的行为，使得代码产出的度量更加合理。

还要看需求本身的表现，因为这是要交付给业务的结果。我们论证 AI 提效，最终还是要结合对业务本身的影响。“需求交付周期”和“需求吞吐量”是这方面最核心的指标，但有个前提，就是要控制需求颗粒度。现在为了让 AI 更好地处理需求，需求都要拆得更细了，那需求吞吐率自然会提高，需求交付周期自然会减少。所以“需求的颗粒度是多少”是一个很核心的问题。我们可以用需求对应的代码修改复杂度去校准需求颗粒度，比如每个需求对应多少当量，可以看它的分布和均值。在这个基础上再去谈论交付周期缩短了、需求吞吐提升了，这样的数据才能真正说明问题。

当然，我们也有各种质量指标，包括前面说的测试。你的团队有多少自动化覆盖、多高的缺陷率，以前大家习惯于用千行 bug 率，现在分母行数飙得太厉害，也就没意义了，因此也需要一些程序分析技术去做校准。我们一般会用千当量 bug 率，以及其他相关指标。

从看板上来说，我们采用的逻辑大体一致。要么就是对比一个团队在不同时间段的表现，要么就是比较不同团队之间的差异，通过用 AI 和没用 AI 的对比来说明 AI 产生的效果，所以逻辑都差不多，这四张图就是不同指标本身的差异。

在应用上述看板时建议大家把前面说的“大模型使用量”放上去。这样就能观测使用大模型到底有没有带来指标的变化。“总接受行数”可以用，如果你们能取到 AI 生成在代码库中的占比，也可以用。这样通过关联分析，就能回答前面那个问题——大模型使用量增加后，我的指标是不是在变好？

好的，我今天的分享就到这里，感谢大家。