编码代理 on Codexer

写了 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%，好几个冲到了九成以上。底层模型没换，只是加了一层「完成标准」，复现率就翻了好几倍。

为什么代理会提前收工

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

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

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

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

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

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

为什么人也很少这么做

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

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

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

代价与权衡

别急着把每个任务都塞进这套流程，它是有成本的。以 gdal 为例，单代理跑了约 15 小时、花了 2.16 亿 credits；多角色系统跑了约 197 小时、花了 30 亿 credits，整整 14 倍。不过拆开看，系统开销里实现占了 97%，验证只占 2%。也就是说，贵的是「实现得更彻底」，不是「多出来的验证」。

代码写得飞快，架构却在悄悄变差：当 AI 代理跑赢你的架构决策

Fri, 28 Aug 2026 09:00:00 +0800

你打开 Codex，丢给它一张 ticket 和一个仓库地址，然后转身去忙别的。半个小时后它回来了：代码能跑，测试全绿，PR 干净利落。单看这份交付，挑不出任何毛病。

但问题恰恰就出在这里。从接到任务到给出那个绿色对勾，Codex 一路上顺手做了十几个架构层面的决定。它不知道这些决定会怎么影响系统的其他部分，不知道你的团队为某条服务边界争论过多少轮，更不知道六个月前有人刚刚定下了一条和它这次改动方向相反的原则。它只是在「让测试通过」这个目标下，选了最短的那条路。

这些决定，每一个单独看都说得过去，合在一起，就是一场缓慢的架构坍塌。

这篇文章的引子，来自 Catio 团队最近发布的一篇工程博客。他们观察了几年企业引入 AI 编程工具的过程，指出了一个被大多数人忽略的裂缝：我们让写代码变快了，却没有让「判断代码对不对」这件事跟着变快。

变快的是写代码，没变快的是做判断

AI 几乎把「写代码」这件事的成本降到了零，吞吐量是真的上去了。但代码之上的东西，战略架构、系统级推理、对一个改动究竟该落在哪个服务里的判断，仍然停留在人的速度上。它们藏在少数几个资深工程师的脑子里，藏在评审意见和茶水间的闲聊里。

于是裂口越拉越大。执行跑在机器速度上，而本该引导并约束执行的决策，还跑在人脑速度上。你每部署一个编码代理，这个裂口就被撑大一点，因为它每小时产出更多决定，而这些决定在进入系统之前没有任何东西在引导，离开系统之后也没有任何东西在把关。

我们在给错误的那半边记分

现在行业里庆祝的数字，几乎全部在衡量「代码生产得有多快、多便宜」：人均产出提升 50%、从信号到生产的周期压到 24 小时以内、自主率 67%（也就是端到端由代理完成、无需人工触碰的合并占比）、单个合并 PR 的成本 20 美元。

没有一个数字在问：这是不是「对的代码」？它有没有尊重系统的边界和约束？它有没有推动这个系统本该服务的目标？

其中「自主率」这个指标尤其吊诡。把它当作头号成绩来宣传，等于在宣称「我们成功地把人的判断力从流程里移除了」。这让我想起外包浪潮的年代：当时大家同样只盯着速度和单位代码成本这两个变量，最终买到的是大量廉价却缺乏系统理解的代码，以及往后很多年的整合债。今天的代理写代码比那个时代好得多，但记分牌在重复同一个错误，而且复利的速度快多了。

代理「看不见」的东西

一个编码代理，永远在任务的尺度上工作。你给它一张 ticket 和一个仓库，它几乎总能给出一个局部最优解，这是它的设计目标，它也完成得很好。

但决定「这个改动对不对」的东西，全都活在任务尺度之外。最顶层是组织的目标函数：业务目标、产品约束、财务政策、架构标准，还有你的资深工程师花了多年才沉淀下来的战略。往下，是系统本身：服务之间的边界、那些悄悄滋生的依赖、六个月前做下的一个即将被这次改动推翻的决定、系统「本该是什么」和「实际变成了什么」之间的漂移。

这些东西，没有一样出现在代理正在编辑的那个文件里。所以代理会做出一件微妙而昂贵的事：一个在文件里正确、在系统里错误，或者对功能正确、对目标错误的改动。它会重新造一个三个服务之外早已存在的轮子，只因为它无从得知。它会跨过一条边界，只因为跨过去是通往绿色测试的最短路径。每一个单独看都站得住脚，合在一起，就是一套干净的架构一步步变成变形虫的过程。

漂移在复利

有人会说，解决办法是让代理慢下来。不是的。决策速度和执行速度之间的差距一直都存在，架构也一直在漂移。AI 做的事情，是把这种漂移放到了复利曲线上。

复利意味着什么？每一个在没有系统上下文的情况下落地的架构决定，都会成为下一个决定的地基。一个稍微偏了一点的决定，会被下一个改动继承，再被下一个继承。人类写代码的速度下，你有几个月的时间去发现、去纠正；代理的速度下，你只有几天。而现在，在途的绝大多数决定，都是代理而不是人做的。

你交付得越快，这些盲目的决定就积累得越快，一个微小的偏差也越快固化成结构性的错位。按照 Catio 的估算，工程时间里有 30% 到 40% 已经花在了这类漂移带来的返工上，而这还是在代理把变更速率成倍放大之前。这也解释了为什么那股「兴奋感」总会按一个可预测的时间表消退：不是工具变差了，是复利终于变得可见了。

首席工程师，成了人肉中间件

这一切的人力成本，最终落在你最承担不起的那批人身上。

当没有任何系统保存架构真相时，少数几个 staff 和 principal 工程师就成了那个系统。他们知道边界为什么在这里，哪些依赖是承重的，动了哪里会炸。他们同时还在承担目标函数：业务目标、产品约束、财务政策，那些真正重要的东西。

AI 倍增了你的开发者，却没有倍增他们。于是同样是那三个人，现在要评审指数级增长的产出，要在大脑里同时装下整个系统和它的目的，还要吸收所有他们没时间去看的东西带来的风险。他们知道自己在放行一些没有充分论证的设计，因为另一个选择是成为扼杀「速度故事」的瓶颈。

这些人恰恰是最热爱这份工作的人。他们不想少交付，他们想在 AI 的速度下做对的事情，只是他们手里的工具，没有任何一个允许他们这么做。

解法在代理之上，不在代理之内

直觉上，大家会去收紧 linter 或者 CI 门槛。这在边缘上有点用，但它仍然停留在「文件」的尺度。问题不在文件里。

真正缺的，是把四样东西连起来的那一层：你的架构真实长什么样、你的组织到底想达成什么、你决定为此做什么、以及最终被构建出来的是什么。有了这一层，架构就不再是一份「想起来才更新」的文档，而是一个系统：它先引导、再治理、最后朝着正确的方向复利。

Catio 把这套打法叫作「先架构，再交付」。落到我自己的理解上，它有两条支线。对常规功能，一份 PRD 能在几分钟内变成一份对齐系统与目标、可直接交付的规格，让机器速度的执行从一开始就是被引导的，而不是盲目的。对战略决策，那些七八位乃至九位数投入的现代化迁移，终于能以它们应有的速度被拍板，在「系统实际是什么样」的基础上做决定，而不是在「某个人记忆里它是什么样」的基础上。

我尤其认同他们提出的一个判断：评审更多的代码从来不是目标。当规格足够清晰、足够对齐、足够落地时，你的资深工程师不再评审所有东西，只评审例外，也就是那些实际交付偏离了本意的部分。判断力才得以以和产出相同的速度扩张。它不是靠克隆你的顶级架构师，而是靠给系统补上上下文、系统级推理、生命周期记忆，还有一根脊梁。