从 API 测试看企业系统性落地 AI 的鸿沟

本文转写自思码逸创始人兼 CEO 任晶磊在 6 月 14 日 GTLC 大会的现场演讲——《研发效能基准数据洞察与跨越自然-编程语言鸿沟》，扫码添加小助手可获取本场 PPT，以及预约即将发布的《DevData 2025 研发效能基准报告》。

大家好，我是任晶磊。

每次和技术圈的朋友们聊天，AI 总是绕不开的话题。有人兴奋，觉得“十倍效能”的奇点时刻就在眼前；也有人焦虑，担心自己的工作会被替代。身处一个由大模型驱动的跃迁时代，这确实是我们这代技术人未曾预料到的幸运。但喧嚣过后，我们更需要一些冷静的审视和务实的思考。

AI 到底为我们的研发工作带来了什么？它不是一个虚无缥缈的概念，而是已经开始为我们“打工”的真实存在。今天，我想和大家分享一些我们基于真实数据和一线实践得到的观察与思考。我将从三个层面展开：

1. 昨天：最近两年，AI 在研发领域的真实表现究竟如何？我将用客观数据戳破一些泡沫。

2. 今天：当下我们该如何系统性地落地 AI？我将分享一个从客户实践中总结出的闭环框架，并以 API 测试为例展开讲解。

3. 明天： 最后，我们不妨站得更高一些，去畅想软件开发的终极未来——我们能否真正跨越自然语言与编程语言之间的鸿沟？

先看数据：AI 应用的真实成绩单

思码逸从去年发起了每年一度、以客观数据为基础的研发效能基准调研，这份调研最大的特点，就是所有数据都直接从企业的研发工具里来，而不是靠大家填问卷凭“印象”说话。这样做出来的报告，少了一些戏剧性，多了一份客观和准确。

2025 年的报告覆盖了 200 多家企业，分析了 18 个经典的研发效能指标。在我们的度量体系里，有一个核心概念叫代码当量。简单来说，我们不再简单地数代码行数，而是通过分析代码的抽象语法树（AST），更科学地度量一次代码变更的复杂度和规模。这让我们的指标更加客观，能够穿透不同编程语言和代码风格的噪音。

那么在这份真实的成绩单上，AI 的表现如何呢？

首先，AI 用在哪？——测试和运维还有很大潜力

我们的数据显示，高达 37%的 AI 应用都发生在编码阶段。这并不意外，毕竟像 Cursor、Copilot 这样的工具已经非常普及，大家用得也很顺手。反而是大家在各种技术大会上听得最多的测试、运维这些阶段，因为涉及到复杂的系统依赖，落地的门槛和阻力都比较大，目前的使用比例偏低。当然，这也说明了这些领域是未来 AI 应用的巨大蓝海。

图 1：AI 在不同研发阶段的应用分布

其次，效率提升了多少？——大约 17%，远非神话

关于 AI 提升效率，各种“翻倍”、“十倍”的说法不绝于耳。但我们的客观数据给出了一个更冷静的答案：已经应用 AI 的企业，其中位代码生产率相较于尚未应用的企业，提升了大约 17%。这个基于代码当量统计的数字和我们收集到的主观反馈高度一致——超过三分之一的企业都认为 AI 带来的效率提升在 20%以下。

这或许与老板们的美好想象大相径庭，传说中的“效率翻倍、人员减半”仍然遥不可及。与代码真实打交道的研发管理者们已经意识到，只有抛弃幻想，才能展开有效、务实的实践，DevData 的调研数据为此提供了可靠的背书。

图 2：LLM 应用对研发效率的实际影响

最后，质量提升了吗？——挑战很大，任重道远。

如果说效率的提升还算乐观，那质量方面的表现就略显“悲观”了。有高达 40%的企业反馈，应用 AI 后，软件质量的提升效果并不明显。

为什么会这样？我认为，这背后是 AI 的能力和研发的真实需求之间还存在一道鸿沟。比如，你让 AI 帮你做代码审查，它可能会滔滔不绝地给你提一大堆建议，但其中很多都是你不太需要的“噪音”。

我们可以画两个圈来理解这件事：一个圈代表 AI 目前的能力、确定性和可能性；另一个圈代表我们对研发的真实需求和想象。今天，这两个圈的交集部分其实还很小。而思码逸的工作，就是努力在这个交集里找到并做深那些真正有价值的场景。

图 3：LLM 在质量提升方面的挑战与机遇

如何在企业里系统性落地 AI？

了解了行业现状，我们自然会问：具体到我们自己的企业和团队，该如何系统性地落地智能研发呢？这绝不是买几个 AI 工具那么简单，它需要一个从战略到执行的闭环框架。

我一直认为，研发组织应该在企业的数智化转型中扮演引领角色。而要做到这一点，首先要实现研发自身的智能化。我们可以把这个目标抽象成一个核心 KPI，那就是 AI 覆盖度——在程序员一天的工作中，有多大比例的任务可以由 AI 来辅助？

为了实现这个目标，我们摸索出了一个由“场景识别、目标设定、流程渗透、效能度量”构成的四步闭环方法论。

图 4：研发应用 AI 的闭环框架

1. 从“程序员的一天”工作坊开始，找到 AI 的发力点。这是我最推荐的第一步。召集项管和一线开发者，大家坐下来，用一个下午的时间，完整地把现有的研发流程梳理一遍，目标是识别出流程中的规范差距点和提效发力点（“两点”）。这本身就是一次宝贵的组织知识沉淀过程，也能让我们清晰地看到，AI 到底应该用在哪个“刀刃”上。

2. 量化 ROI，“以终为始”。找到了“两点”，我们就可以在投入之前，先算一笔账。对于每一个计划引入 AI 的环节，我们可以预估它的投资回报率（ROI）。这个 ROI 其实可以很简单地估算：ROI ≈ 单次价值（节省的时间/成本） × 调用频率。这种“以终为始”的规划，能让我们的决策更有依据，也更容易获得团队的支持。

3. 流程渗透，构建你的“专家”智能体。这是最关键的执行环节。但很快你就会发现一个问题：通用的 AI 模型，似乎并不能很好地解决我们的具体问题。这就引出了一个核心议题：通用模型 vs. 垂直领域“专家”模型。要让 AI 真正产生价值，我更倾向于后者。

4. 效能度量，回归业务价值。AI 落地后，我们需要回到度量，来验证它是否真的达成了我们的目标。这里的度量也分两个层面：一是工程规范的度量，比如代码提交的规范性、自动化测试覆盖率等，这些指标能让我们观察到人与 AI 协作的状态；二是业务影响的度量，这才是最终的价值体现。我们要在控制好需求颗粒度（比如用代码当量来约束）的前提下，去看需求的吞吐量和交付周期有没有实质性的改善。只有当这些核心业务指标变好了，我们才能说，AI 真正为我们创造了价值。

举个例子：看似简单实际复杂的 API 测试

在上面的框架里，我提到了构建“专家”智能体。这听起来可能有点抽象。为了让大家有更具体的感受，我想用 API 测试这个场景作为一个例子。这个例子我们自己实践地比较多，体验也比较充分。它能非常清晰地展示出，为什么通用 AI 通常情况下不够用，以及一个真正的“专家”智能体应该具备哪些能力。

API 测试之所以是一个绝佳的试金石，因为它看起来简单——不就是调用一个接口，看看返回对不对吗？但实际上，要在真实的企业环境中做好，它极其复杂。

图 5：通用 AI 与专家智能体在 API 测试中的能力对比

一个通用的 AI 或许能帮你写出单个 API 的测试用例，但一个 API 测试“专家”智能体需要解决以下六大挑战：

1. 挑战一：超越单点，实现“自动用例覆盖”。真实的测试用例往往不是由单个 API 调用构成的，而是多个 API 的组合。一个“专家”智能体必须能理解这种依赖关系，智能地组合多个 API，从而生成能覆盖各类情况、各种参数组合的全面用例。覆盖的全面性可以通过规则进行补充。

2. 挑战二：理解意图，进行“智能场景编排”。测试不仅仅是测试 API 本身，更是测试它所承载的业务场景。比如“用户将商品加入购物车，然后修改数量，最后清空”这样一个流程。一个“专家”智能体需要能理解这种业务场景描述，模拟真实的用户流程，自动编排出复杂的测试场景，从而把测试人员从繁琐的手工编排中解放出来。

3. 挑战三：连接真实，完成“数据驱动测试（DDT）”。API 的返回结果是否正确，往往需要和数据库里的真实数据进行校验。通用 AI 很难涵盖这种特异性的要求。而一个“专家”智能体可以具备这种能力，支持接入或构造测试数据的快照，在测试时进行精准的数值校验，确保逻辑的正确性。

4. 挑战四：追根溯源，实现“排查规范问题”。在实践中，我们 99%的 API 文档都和实际代码存在或多或少的出入。当 AI 根据不准确的文档生成测试用例时，聪明的“专家”智能体必须有容错的能力，能发现这种不一致，并反过来从源头提出优化建议，比如提示“API 文档中某字段的定义不明确”或“某个参数的有效值范围需要补充说明”，从而推动研发体系的规范化。

5. 挑战五：积累知识，进行“私有知识优化”。要让大模型表现好，就必须喂给它精准的上下文。简单的 RAG 在复杂场景下效果并不好，因为它无法理解知识点之间的深层联系。一个真正的“专家”智能体背后，需要有一个高效构建和分析 API 知识图谱。这个图谱能清晰地描绘出 API 之间的依赖、调用关系和业务含义，从而保证 AI 在生成测试时的上下文质量，最终提升生成用例的通过率。

6. 挑战六：打通全局，做到“无缝系统集成”。这是“最后一公里”的问题。AI 生成的测试用例和脚本，如果不能方便地提交入库，并无缝地接入到公司现有的 QA 流水线和 CI/CD 流程中，那它的价值就大打折扣。因此，“专家”智能体必须支持多测试环境、脚本入库，能够与现有的研发基础设施无缝集成。

通过 API 测试这个例子，我想大家可以清晰地看到，从一个看起来很酷的 demo，到一个能在企业里真正落地、产生价值的产品，中间有无数的工程细节和领域知识需要填补。这正是“专家”智能体的价值所在，也是我们未来几年努力的方向。

我们能推倒自然语言与编程之间的那堵墙吗？

聊完了数据和实践，在最后，我想和大家一起做一场思想实验，去展望一个更长远的未来。我们所有技术人，内心深处可能都有一个共同的梦想：有一天，我们能彻底跨越自然语言到编程语言的鸿沟。

为了实现这个梦想，今天行业里主要有两大流派在努力：

• 一派是面向非程序员的。 他们的愿景是，说几句话、甚至截个图，AI 就能帮你把软件做出来。这类工具很酷，但它们很快就会撞上一堵我称之为“完整性与可维护性的墙”。用它生成一个简单的网页没问题，但要生成一个能真正工作、并且能持续迭代维护的软件系统，目前看还遥不可及。

• 另一派是面向我们专业程序员的。 他们的目标是打造一个强大的 AI 智能体。它能理解我们更精确的指令，帮我们完成编码工作。但这类工具同样面临一堵墙，我称之为“需求与设计知识的墙”。它能很好地执行明确的任务，但要它理解高层次、模糊的业务意图，同样非常困难。

图 6：跨越语言鸿沟面临的两堵“高墙”

为什么会这样？因为一个软件的诞生，天然就存在三种不同的“语言”：业务人员讲的是充满歧义的自然语言；架构师画的是半结构化的建模语言；而程序员写的是精确无歧义的编程语言。想让一个大模型直接打通这三者，难度可想而知。

那么，破局点在哪？或许，我们应该换个思路：我们能否让这三方，都说同一种语言？

MIT 的 Daniel Jackson 教授的著作《软件设计的要素》给了我很大的启发。他认为软件设计的核心，应该是围绕“概念”进行的，我们应该努力让用户和程序员能拥有一种共同的语言去交流。

我在想如何能够构建一种能用于描述软件需求、设计和实现的“自然语言”？它虽然是自然语言，但它不是随意、松散的，而是有其严谨的结构。我们可以把它解构为三个核心要素：

• 用语： 定义系统的静态概念，包括实体、状态和行为。

• 语法： 定义行为发生的规则和约束。比如，“用户必须先获得编辑权限，才能添加紧急标签”，这就是一条语法。

• 语义： 定义行为背后的功能意图。

图 7：用精确的自然语言描述软件需求与设计

如果我们可以用这样一套框架，去精确地描述软件，那么一个大胆的设想就可能成立：每一个程序，本质上都是一个定义良好的子语言。

如果这个设想成立，那么从需求到设计再到实现的鸿沟，就可能被彻底填平。我们不再需要三种割裂的语言，而是可以用同一种语言沟通，贯穿整个软件的生命周期。欢迎访问 https://github.com/welldefined-ai/sublang 了解、关注、参与社区。

在这样的未来，我们程序员的角色会发生什么变化？我想，我们可能不再是编码者（coder），而会进化成“软件作者”（writer）。我们不再是被动的翻译者，而是用一种新的语言范式，去定义和创造系统高层意图和架构的作者。

这绝不是对我们要求的降低，恰恰相反，它对我们的抽象能力、逻辑能力和表达能力，都提出了更高的要求。

感谢大家持续关注思码逸，和我们一起继续探索这场静默而深刻的变革。