写了 1.7 万行代码，只复现 36% 的功能：编码代理为什么提前收工

Sat, 29 Aug 2026 09:00:00 +0800

你给 Codex 丢了一个大任务，然后转身去开别的会。几个小时后它回来了，PR 干净利落，测试全绿，还礼貌地告诉你「完成了」。你点开一看，发现它写了一大堆代码，可你要的核心功能，只落地了不到四成。

它不是超时了，也不是预算花光了。它就是，真的觉得自己做完了。

这不是我编的场景。AI 编程公司 Factory 最近做了一组实验，把这个现象拆得明明白白。

一个反直觉的实验：重建 gdal

gdal 是 GDAL 项目的命令行工具，地理空间数据处理的扛把子。它从 1998 年就开始开发，藏在 QGIS、ArcGIS、PostGIS 这些软件下面，能读两百多种栅格和矢量格式。上游 C/C++ 代码约两百万行，通过命令行能触达的大概六十万行。

Factory 让他们的代理 Droid 从零重建 gdal。规则很严格：可以无限次运行参考程序，但不能读它的源码、测试，也不能联网。也就是说，只能把 gdal 当黑盒，靠观察输入输出来猜它该怎么实现。

单代理模式下，Droid 自己写代码、自己检查、自己决定什么时候收工。最后它交出了 1.7 万行 C++，复现了 gdal 36% 的行为。代码质量不错，常见路径都能跑，但大部分功能压根没建。它停下来，纯粹是因为它「觉得自己做完了」。

然后他们把 Droid 拆成多个角色。动手之前，先由一个角色写一份「可执行的完成标准」：这次重写到底要实现什么，用什么证据来证明实现了。实现环节再被拿来逐项对照这份标准。这一轮，代码涨到 11.5 万行，行为复现率冲到 90%。

有意思的是，系统跑出来的程序跟原版长得完全不一样，代码量只有原版零头，组织方式也截然不同。它复现的是「行为」，不是「结构」。

这不是孤例。在 24 个最难的任务里，7-Zip 从 54% 提到 95%，DuckDB 从 34% 提到 80%，好几个冲到了九成以上。底层模型没换，只是加了一层「完成标准」，复现率就翻了好几倍。

为什么代理会提前收工

答案藏在它工作的方式里。编码代理习惯边做边验收：实现一块，写几个检查，看看输出，再决定继不继续。

小改动这套没问题，任务、实现、证据一眼就能看完。但大任务必须拆成功能、子系统、一轮又一轮的活。代理每完成一块，就顺便决定「什么证据算数、这些证据够不够」。问题在于，这些检查继承了「产生它们的那块工作」的视野。它能证明「自己想到要建的东西」都建好了，却漏掉了那些它从未想到的功能、交互和约束。

于是代理一路稳稳地局部正确，最后带着缺失的一大半宣布收工。问题往往不在于它「没能力实现剩下的」，而在于它从头到尾都没列出一份「还剩下什么」的完整账本。

解法：动手之前，先把验收定义好

要覆盖一个完整的目标，光有一张需求清单不够。系统得先搞清楚三件事：要建立哪些东西，怎么逐项验证，以及这些验证当前是否通过。

这份标准应该在实现把任务收窄之前，就从需求和事实源里推导出来。它不必冻结，可以随着系统学习而增补、替换、细化。但有一条底线不能破：完成标准绝不能悄悄缩水成「已经建好的那部分」。

为什么人也很少这么做

把需求和证据分开，本身不是新鲜事。安全关键项目有需求追溯和独立验证，标准组织会发布一致性测试套件，让众多实现共享成本，产品团队也会写验收测试。

真正难的是：为每个项目单独推导并维护一份全面的标准。一致性套件可以把成本摊到很多实现上，产品团队却得为每次应用、重写、迁移重新付一遍这笔账。所以大多数团队选择增量验证，靠评审、用户反馈和人的连续性来兜住整体。

代理把天平的两头都改变了。一方面，它产出代码的速度超过了人能审查的速度，人工监督成了瓶颈；另一方面，同样这份能力，也可以反过来用来制造标准本身：清点目标、构造检查、在产物变化时反复重跑。

代价与权衡