AI Coding 的下一步不是写得更快，而是可验收：蚂蚁数科 Harness 工程实践

嘉宾 | 魏长征

编辑 | 李忠良

随着大模型能力增强，AI Coding 正从代码补全走向由 Agent 独立执行完整任务。研发团队面对的问题也随之改变：当代码产出速度成倍提升，原有的需求约束、Code Review 和测试验收机制还能否跟上？如果验证能力没有同步升级，AI 带来的可能不只是效率，还有更集中、更难控制的质量风险。
在 AICon 全球人工智能开发与应用大会上，蚂蚁数字科技资深技术专家魏长征结合两个真实项目，分享了团队对这一问题的探索：在一个 40 多万行的 Rust 新项目中，从第一天开始将 Harness 内建进研发流程；在一个超过 60 万行的 C++ 存量项目中，先重建事实源和质量门禁，再让 Agent 参与仓库升级。经过改造，后者的代码缺陷率从 20% 以上降至个位数。
在魏长征看来，AI Coding 并没有创造全新的软件工程问题，而是以更高的产能，将需求模糊、目标漂移、事实冲突和验证不足等旧问题集中放大。Harness 也不是某一种具体技术，而是一套围绕约束、验证和验收建立研发闭环的思路。本文将沿着演讲的逻辑，呈现这套体系如何从实际问题中逐步形成，以及它在新项目和存量工程中的具体落地过程。

AI Coding 最近被频繁提起，但使用大模型辅助编程并不是刚刚发生的事情。

大模型出现不久后，很多团队已经开始尝试让模型写代码。那时还没有成熟的 Agent 工具，大家主要在对话框里提问、粘贴代码，让模型帮忙编写脚本、处理繁杂任务或者分析错误，确实可以节省不少力气。

随后，Cline 等工具开始以插件的方式嵌入 VS Code，大家逐渐在 IDE 中使用 AI。再往后，我们集中采购了 Cursor 一类的 AI IDE，开发者的使用方式从“在 IDE 中安装插件”，变成使用一整套内嵌 Agent 的开发环境。那一阶段，大家使用最多的能力还是 Tab 补全。

到了后来，Claude Code 等终端形态的工具出现，Cursor 的产品形态也发生变化。我们逐渐发现，IDE 可能已经不再是主要战场，对话框反而成为人与 Agent 协作的主要入口。

随着模型越来越强、工具可以完成的工作越来越多，我们交给它的任务也越来越完整。最初只是让 AI 写几行代码，后来则希望它独立完成一项任务，最后由人来验收。

因此，检验标准也在变化。过去，我们关心的是代码写得好不好；后来，需要判断功能是否正确；当 Agent 开始处理工程级任务时，仅仅判断某个模块能不能运行已经不够，还要看它放进整个项目以后，能不能在完整链路中稳定工作。

AI Coding 的产能提升得非常快，但研发团队的验证标准、验证方法和验证工具是否同步跟上了，这是目前最核心的矛盾。

一旦验证能力没有跟上代码生产能力，项目就很容易失控。Harness 工程之所以受到关注，正是因为大家开始意识到，只让 Agent 高速生产代码是不够的，还必须围绕它建立完整的验证闭环。

从早期的 Prompt 工程，到上下文工程、Harness 工程，再到最近讨论较多的 Loop 工程，不同概念反映的是同一个趋势：AI Coding 在研发工作中承担的角色越来越重要，处理的任务也越来越复杂。我们希望 Agent 做更多事情，同时又希望它把这些事情做好。

1 AI Coding 新范式挑战：从传统研发范式到 AI Coding Loop

AI Coding 经常被称为一种新的工作范式。它的新，首先体现在开发者角色的变化上。

原来我们自己写代码，是代码的生产者；现在代码越来越多地由 AI 完成，我们逐渐变成代码和结果的评判者。再从更大的范围看，有了 AI 工具以后，一个人能够处理的任务跨度、涉及的知识面以及跨角色协作的范围，都会明显扩大。

但我也一直在思考：AI Coding 到底带来了哪些过去从未见过的挑战？

仔细想一想，很多问题并不是 AI 带来的，它们过去一直存在于软件研发过程中。

我很多年前在外企做软件工程师时，一个 Feature 可能并不复杂，但从开发到 Release 需要半个月，其中甚至有一周都在和国外同事做 Code Review，反复讨论实现细节。即使经过这么长的流程，软件仍然难免出现 Bug，但整体发布质量相对稳定。

后来，很多业务进入高速发展阶段。产品经理可能今天提出一个需求，要求三天以后上线。研发人员会觉得很多地方没有写清楚，但为了赶上发布时间，只能根据自己的理解补全。等功能上线以后，产品经理却发现，这并不是他想要的功能。

这就是研发过程中常见的目标漂移。

今天，我们把一项 Coding 任务交给 Agent，最后发现它实现的功能与预期不一致，很容易把原因归结为大模型的幻觉。但在责怪模型之前，也需要先问一句：我们自己的需求是不是也存在“幻觉”？目标、边界和验收标准真的说清楚了吗？

类似的问题在由人完成的软件开发中一直存在。AI Coding 带来的巨大变化，并不是创造了这些问题，而是它的速度太快、产能吞吐太高，所以把问题集中暴露了出来。

一个 Agent 可能在一天之内完成过去三个月才能完成的代码量。原本分散在几个月中的问题突然集中爆发，自然会让人觉得项目里到处都是问题。

本质上，AI Coding 放大的是研发流程中原本就存在的需求模糊、认知偏差、事实冲突和质量欠账。

过去，我们站在开发者的角度，可能会抱怨产品需求写得不清楚，需要自己不断脑补。今天，当 Agent 努力理解我们的任务时，我们实际上站到了类似产品经理的位置。

看清这个底层逻辑之后，解决问题的方向也就比较清楚了。Harness 工程要处理的很多挑战，在过去的软件研发流程中都能找到相应的解决办法。传统研发会做需求评审、架构评审、接口定义、Code Review、测试准出和任务拆解。进入新的工作范式后，我们需要思考的是，如何把这些经验迁移到与 Agent 协作的过程中。

AI Coding 的问题首先是“太快”。既然如此，我们也可以用同样快的方式进行验证。Agent 可以生成代码，也可以参与质量检查和 Code Review。

可以理解为“用魔法打败魔法”：当代码生产速度和验证速度能够匹配，再加上相应的 Harness 机制，就有可能形成类似传统研发的质量闭环，并在这个基础上提高整体效率。

2 Harness 架构：来源于真实工程实践

在我们的实践中，Harness 并不是一种具体技术，更像是一套验证闭环的思想。

至于 Harness 架构是不是一定要分成某几层，每个项目是不是都要采用同样的 Reviewer，其实没有那么重要。不同项目面对的问题并不相同，很难把一套做法原封不动地搬过去。

即使在我们自己的项目里，这套体系也不是一开始就完整设计出来的。最初并没有想清楚需要多少个 Reviewer，也没有预先决定每个 Reviewer 应该检查什么。更多时候，是随着项目暴露的问题越来越多，团队不得不寻找新的约束方法，最后才逐渐形成一个体系。

因此，从方法论角度所说的五层，更像是一种“马后炮”式的总结：项目跑了两个月，感觉效果不错，再回过头看，发现这些实践大致可以归为五层。它们背后的逻辑并不陌生，因为基本都能在传统软件开发中找到对应。

传统开发在编码前会进行需求评审和架构评审，也会编写架构设计文档和接口定义文档，提前明确任务目标、软件边界和设计约束。这些工作对应的就是约束层。

对抗验证对应的是 Code Review。在高速迭代中，Code Review 本来就可能流于形式，AI Coding 进入以后，这个问题更加突出。过去，一个 PR 超过 2000 行，人工审查已经很困难；现在，Agent 一次可能提交四五千行代码。如果因此直接放开限制，负责 Review 的人很快就会不堪重负。代码提交者自己都没有完整看过，其他人又怎么可能逐行看完？

但 Code Review 本身非常重要，不能因为代码量变大就放弃。我们需要考虑的是，怎样在 CI 流程中让 Agent 参与 Code Review。

证据层对应的是交付验收和质量准出。一次任务能否交付，需要有相应的报告和测试结论，不能只是 Agent 告诉我们“已经完成”。

另外两层围绕状态写入和目标对齐展开，与传统研发中的任务拆解和阶段性评审很相似。比如，把一个任务拆成十个 Sprint，明确每个 Sprint 要做什么，再写入 Backlog。即使中间休假一周，回来以后仍然知道任务进行到了哪里。Agent 也面临同样的问题：如果没有持续记录任务状态，它就可能发生漂移，或者因为上下文丢失而忘记之前做过什么。

具体到约束层，一个项目通常需要规定几类文档。

首先是任务目标和非目标：要做什么必须写清楚，不能做什么也要写清楚；其次是事实源，必须明确以哪一份文档或定义为准，不能同时存在多个彼此冲突的数据来源，否则 Agent 也会困惑。

这些内容可以转化成不同形式的文档：有些方便人阅读，有些方便 Agent 获取上下文，还有一些适合机器直接检查。不同文档承担的作用不同，也会影响 Agent 的工作效率。

对抗验证也是一样。人做 Code Review 时，本来就会从不同角度检查代码：命名和格式是否规范，是否重复实现了系统中已有的能力，问题定位是否找到了真正的根因，还是只解决了当前的 Bug Fix Case，却没有覆盖其他同类问题。

因此，在 Agent 参与 Review 时，也需要让不同的 Agent 分别关注不同侧重点。

证据层最重要的是可视化、可验证。在现在这种工作范式下，无论让人直接阅读大量代码，还是阅读大量 Markdown 文档，成本都很高。通过 HTML 验证报告以及架构图、流程图等可视化方式，人可以更快地看清测试过程、测试结果和最终结论。

中间过程同样需要被记录。我们现在有些 Agent 任务会连续运行十五到二十个小时。任务结束后，我们会担心它是否还记得最初的目标，执行过程中有没有跑偏。仅靠上下文压缩和模型自身的记忆，很难完全兜住这种长任务，所以通常会借助外部的工具，阶段性持久化它的工作状态。

任务完成以后，我们还会要求 Agent 重新复述：最初让它完成的到底是什么，任务目标是什么，它采用了什么方案，又是怎样达成目标的。每完成一个阶段都做一次这样的回溯，就能比较清楚地判断这一阶段的实现有没有跑偏。

3 案例一：新项目构建——从第一天把 Harness 内建进研发流程

第一个案例是一个从零建设的 Rust 项目，代码规模超过 40 万行，基本由 Agent 从头参与开发。

项目开始时，我们首先考虑的是怎样建立初始仓库，而这件事也是从设计文档开始的。包括 AGENTS.md 在内的核心文档，首先要明确唯一事实源：哪些文件负责定义设计契约，API 应当以哪份文件为准，都必须说清楚，才能成为 Agent 后续开发时的可靠依据。

在项目级文档之下，每个模块还会有粒度更细的说明。我们不能把一份体量巨大的文档一次性加载进上下文，那样未必能取得理想效果。因此，文档需要分层，让 Agent 根据当前任务读取对应模块的信息。

每次发生变更时，我们还要求同步提交变更文档。从传统软件工程的角度看，这些事情并不新鲜，本来就是日常开发应该完成的工作，只是在实际执行中，人经常会偷懒。

有一个关于程序员的段子：程序员最讨厌别人的代码没有注释，也讨厌给自己的代码写注释。进入 Agent 时代以后，一个好处是 Agent 在这方面通常不会偷懒。只要团队把要求定义清楚，它就能够帮助维护相对完整的文档。

文档还需要与测试用例和代码持续对齐，并在每次变更时通过 CI 检查。只有这样，文档才能真正进入研发闭环，而不是写完以后便失去作用。

这个项目每天的变更很多，基本上每一个 PR，无论大小，都要有相应的变更文档。文档需要说明这次变更的动机和影响。一方面，负责 Code Review 的人可以先通过文档理解变更；另一方面，Agent 后续定位 Bug 时，也可以追溯到当时的变更记录。

项目运行一段时间后，如果出现问题，Agent 可能恰好检索到相关的变更文档，并从中发现当时遗漏的内容，从而更快地定位代码问题。

测试过程也需要可视化。Agent 可以快速生成大量测试，也可以把覆盖率做得很高，但人最终可能并不知道它到底测了什么，也无法判断测试路径是否有效，或者是否使用了大量无效 Mock。

单纯通过 Prompt 要求 Agent “认真测试”并不可靠。我们的做法，是把开发和测试过程做成可视化展示，并在每次发布时生成一套完整的可视化资产。

Reviewer 可以点开具体的测试路径，查看它覆盖了状态机中的哪些状态和跳转。如果一百个测试始终只覆盖两个状态之间的跳转，即使测试数量很多，质量也未必高，这种情况下就需要返工。

测试是否可信，不能只看数量和覆盖率，还要看它实际覆盖了哪些路径。

Code Review 则通过 CI 门禁完成。CI 门禁是项目质量的重要兜底，也是最终的防线。我们把它分为硬门禁和软门禁。

硬门禁通过机器脚本确定性地检查约束。例如，要求提交变更文档却没有提交，脚本可以直接发现并要求补充，这类问题没有必要浪费 Token。

软门禁主要由不同 Agent 执行 Code Review。我们会配置不同模型和 Prompt，让它们从不同侧重点审查变更。

有的 Reviewer 重点检查 Contract，核对变更目标、代码实现和规则是否一致；有的 Reviewer 专门做“减法”，不断追问代码是否多余、能不能简化；还有的 Reviewer 负责检查项目中是否已经存在可以复用的能力。

一个 40 多万行的项目，无论是人还是 Agent，都不可能了解全部代码以后再开始工作。但 Reviewer 可以借助文档和代码检索，发现某条路径是否已经有现成实现。如果重复造轮子，不仅会带来冗余，还可能在系统中造成二义性。

这些不同的 Review 视角，需要在实际暴露问题以后逐步沉淀到门禁中。它们共同构成了新项目中的 Harness：从文档和唯一事实源开始，经过测试证据和多视角 Review，最终形成可验收的研发闭环。

4 案例二：存量项目改造——先补 Harness，再做仓库升级

第二个案例是一个代码规模超过 60 万行的 C++ 存量项目。从一次大规模重构算起，这个项目已经持续开发了四五年，团队有几十人，期间人员也经历过多次变化，维护成本本身就很高。

一开始，团队并没有正式鼓励大家使用 AI Coding。后来我们发现，其实不需要鼓励，很多人已经在私下使用，因为它确实能够节省时间，至少不用手工输入那么多代码。

但开发者使用 AI 生成代码以后，未必会明确说明这部分代码来自 AI。任务完成速度变快了，提交的代码量也变大了。架构师做 Review 时非常痛苦，但发布日期又卡在那里，很难简单拒绝提交。

一旦审查稍有放松，问题很快就会出现。有一段时间，这个项目的代码缺陷率飙升到了20% 以上。

我们开始治理这件事时，首先确认了一点：不能退回到禁止使用 AI 的状态。大家已经用上了这个工具，再要求他们不用，基本不现实。即使强调存量项目风险高，也阻止不了开发者继续寻找使用方式。

唯一可行的办法，是让大家光明正大地使用 AI，同时让团队也能够光明正大地约束和拦截它。因此，我们开始对项目进行 AI 友好化改造，把 Harness 的思路应用到存量工程中。

改造完成后的一个月，项目代码缺陷率从 20% 以上降到了个位数，变化非常明显。

问题背后的原因并不复杂。由于团队人员不断变化，新成员很难完整理解这样一个复杂项目，也很难了解项目历史。更麻烦的是，历史文档和代码本身也可能存在错误。新人基于这些信息编写代码，容易出现问题，负责 Review 的人也未必能够识别所有偏差。AI Coding 提高开发速度以后，问题只会暴露得更多、更快。

这种情况在很多老项目中都很典型：事实源不固定，文档分散、缺失或者内容错误；不同文档之间相互矛盾，文档和代码也可能不一致；项目中还存在大量重复实现，而这些“轮子”之间同样可能互相冲突。

所以，改造的第一步不是让 Agent 修改代码，而是让 AI 扫描整个项目。

这个过程大约持续了一到两周。Agent 从项目整体开始，自顶向下进入各个模块和接口，一层层梳理文档、代码和实际行为，找出其中的不一致。

对于已经存在的历史错误，我们不可能立刻全部修改。代码即使有问题，仍然承载着现有业务，不能简单删除或重写。我们能做的是先订正事实，重新编写文档，建立唯一事实源。

以后 Agent 进入项目，无论处理什么需求，都必须先读取这套核心文档。系统再根据任务内容，把它路由到对应的模块文档。

例如，一个任务涉及网络模块，就让 Agent 继续读取网络模块的说明。文档会明确告诉它，旧代码与旧文档在哪些地方存在出入，哪些历史实现虽然暂时保留，但并不是后续开发应该遵循的正确路径。

Agent 可以暂时不修改那些历史错误，但必须知道它们是错误的，也必须知道以后应该沿着哪一条路径开发。

完成文档体系重建以后，我们再把前面提到的 Review 规则和 CI 检查逐步放进门禁。存量项目的 AI 友好化，要先补上 Harness，再让 Agent 进入具体改造。

面对大型存量工程，我们还担心 Agent 一次修改过多代码，把项目影响面扩大。因此，在任务开始之前，团队会先进行功能切片和任务拆分，把边界相对清楚、影响范围比较可控的部分交给 Agent。

最早的试点之一，是 C++20 升级。

这个项目过去经历过从 C++11 到 C++14、再到 C++17 的升级。我记得仅从 C++14 升级到 C++17，就用了大约半年时间。继续升级到 C++20，新的语言特性更多，整体改造也更加复杂。

但这类任务有一个特点：升级过程理论上应该保持语义等价，测试目标和验收标准相对清楚。因此，在完成前面的 AI 友好化改造后，我们选择了一个局部代码模块，让 Agent 按照既定流程进行 C++20 升级和模块化重构。

这次试点取得了不错的效果。局部流程跑通以后，团队才进一步拆分出多个模块和需求，以并发方式推进后续改造。

5 总结：全流程研发闭环，持续并行

前面两个项目中的 Harness 流程，主要关注研发团队内部的技术闭环：从技术需求开始，到完成技术验收结束。

但在完整的研发流程中，闭环还需要继续向前延伸。

当编码速度显著提高以后，产品需求的表达速度可能会成为新的瓶颈。产品人员可能会说，研发编码这么快，自己写 PRD 的速度已经跟不上了。如果跟不上，同样可以与 AI 协作。

产品人员可以让 AI 帮助澄清和复述需求，检查 PRD 中是否存在歧义，并把原本模糊的表达整理清楚。产品和研发还需要逐步形成共同的语言规范，减少模糊沟通和依赖个人脑补的情况。

从需求澄清、技术选型、方案对比，到编码、测试和最终验收，整个流程都可以采用人与 AI 协作的方式，并在每个阶段产生规范化的产出物。

当所有阶段都有迹可循，同时配合规范化文档和渐进式披露，Agent 在协作过程中就能做到相对可控。之所以说“相对可控”，是因为模型本身的能力和行为仍然可能波动。

我们曾经长期使用某个模型。一段时间内，它倾向于尽可能帮助用户补全没有想到的 Case；但后来有一段时间，它又突然变成尽可能少做。

这类变化有时不容易被 Harness 发现。最终功能看起来可能差不多，但人检查具体实现时，会发现实践质量存在明显差异。

因此，从目前的 AI 协作和 Harness 实践，走向真正自治、稳定的开发体系，还有很多路要走，也需要持续探索。

AI Coding 出现以后，很多人讨论它会不会取代工程师。我的判断恰恰相反：AI Coding 对工程师的要求会越来越高。

模型能力越强，我们对它的期望也越高，就越希望它完成更加复杂的事情。任务越复杂，暴露的问题就越多，对工程师定义目标、识别边界、判断架构和验收结果的能力要求也越高。

人与 AI 的协作还会持续下去。我们真正要解决的，不只是如何让 Agent 写出更多代码，而是如何让它交付的任务能够被约束、被验证、被验收。

AI Coding 提升了代码生产速度，而 Harness 要做的，是让验证速度和验收能力与之匹配。只有形成覆盖需求、开发、测试和交付的完整闭环，AI 的高产能才可能真正转化为稳定的软件工程效率。

会议推荐

QCon 全球软件开发大会·2026（上海站）现已正式启动。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。