代码写得飞快，架构却在悄悄变差：当 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 能在几分钟内变成一份对齐系统与目标、可直接交付的规格，让机器速度的执行从一开始就是被引导的，而不是盲目的。对战略决策，那些七八位乃至九位数投入的现代化迁移，终于能以它们应有的速度被拍板，在「系统实际是什么样」的基础上做决定，而不是在「某个人记忆里它是什么样」的基础上。

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