意图与实现之间

我们要的从来不是代码，是意图的达成。当「做出来」的成本一路走低，真正稀缺的，是说清楚要什么，和证明真的做对了。

从一个普遍的现象说起

过去一年，用 AI 干活的方式换了好几档：从逐行 review，到定规则、定架构、让多个 agent 互相挑错，人只守几道关。

但有个现象越来越普遍——agent 越强，人反而越忙。 忙的不是敲键盘，是派活、补背景、判断「这算不算过」、在十几个会话之间来回对齐。问问身边重度使用 agent 的人，几乎没有例外。

既然是集体现象，就不是谁的工作流没调好。往下拆，其实是两个不对称叠在一起。

第一个：生成快过验证。 agent 一下午能产出过去一周的量，但「确认这些东西真的对」的速度并没有跟着涨。产出越快，排队等确认的东西堆得越高。

第二个更要命：这场竞赛的两侧根本不对等。 机器那侧可以水平扩展——多开会话、多起 agent、堆算力就行；人脑这侧是常数，工作记忆就那么几个槽位，每切换一个会话，都得把那个任务的背景、进度、判断标准重新装载一遍。开十个 agent 不是十倍产出，是十份排着队等装进同一颗脑子的上下文。可扩展的一侧在涨，不可扩展的一侧成了整个系统的单点——那个单点是你。

所以「越强越忙」不是错觉，是算术。它同时暴露了一件事：我们把力气花错了地方。整个行业还在拼命优化「更快地写出代码」，可瓶颈早就不在那了。

成本从来不在打字

要看清瓶颈挪到了哪里，得先承认一个老事实：软件的成本，从来就不在打字。

Jack Reeves 三十多年前在 What Is Software Design? 里就把这一点说透了：别的工程里，设计和制造是两道工序，制造往往更贵；软件不一样，源代码本身就是设计图，「制造」只是编译，几乎免费。所以软件的成本一直压在设计判断里——架构怎么搭、新问题第一次怎么解开、哪些债现在不还。

过去这个结构被掩盖着，因为打字也贵，我们习惯用产出行数把两种劳动混在一起计价。AI 把打字的价格打到近零，两种劳动就被迫分开了：可流水线化的实现在飞速贬值，设计判断没有。继续拿行数当尺子，只会越量越歪。

拉长时间尺度看，这件事甚至不新鲜。写软件的历史，就是人读写的那一层不断上移的历史：机器码交给汇编器，汇编交给编译器，内存管理交给运行时，样板交给框架——每上移一级，下面那层就从「人人都读」变成「出事才看」的生成物。没有人为汇编的失宠哀悼，因为大家意识到自己真正在写的从来不是那些指令，是指令背后的逻辑。代码正在排进同一个队列，成为下一个「汇编」——你一天里真正在写的，已经是 prompt、需求描述、验收标准这些东西了。

但这次有个关键差别，后面的一切讨论都从这里长出来：我们敢不看汇编，是因为编译器是确定的——同样的输入永远给同样的输出，「翻译是否忠实」这个问题被一次性解决了，信任一次建立，终身有效。而从意图到代码的这台新「编译器」是概率性的：同一句话，两次产出不一样，错起来还错得很有说服力。上一次抽象层上移，对翻译的信任是顺手附赠的；这一次，验证恰恰是被留下来的问题。

顺着这个类比，还有一个更扎心的推论。如果代码是新的汇编，那新的源码是什么？OpenAI 的 Sean Grove 给过一个回答：意图和规格才是，代码只是它的一次有损投影。而我们的习惯是留下代码、删掉 prompt 和讨论——相当于把源码粉碎了，然后小心翼翼地给二进制做版本管理。

压力落在两头

把意图变成能用的软件，拆到底就三件事：说清楚要什么、做出来、对照现实检验。AI 吃掉的是中间那件。

剩下的两头，恰好是机器最弱的，而且这个弱不太像是「模型再强一点就好了」的问题。

「要什么」没有标准答案。哪个指标重要、什么算好、愿意为此赌多少——这些没有推导，只有判断。机器能把「给定目标之后怎么做」优化到极致，但目标本身，它给不出来。

「真的对了吗」则贵在验证。Jason Wei 有条 Verifier’s Law：一个任务多容易被 AI 攻克，正比于它多容易被验证。反过来读就有点冷——验证便宜的会先被吃掉，剩给人的恰恰是验证最贵的部分，而「这个软件是否真的达成了目标」，就在最贵的那一头。

个人快，团队未必跟得上

以上算的还是一个人的账。放到团队里，一切都会被放大：每个人都在用 agent 拉产量，可若验收标准和上下文没有共享，可维护性、可理解性、一致性会悄悄失控。

测试绿了，但没人敢动那块老逻辑；每人只记得自己的 prompt，仓库却在集体变陌生。有人大规模分析过多 agent 系统的失败案例，结论是：失败大多源自组织设计，而不是单个 agent 的能力上限——这句话对人类团队同样成立。个人还能靠手感兜底；团队必须靠共享的验收、可追溯的背景、以及失败时能拉回来的机制。

什么叫「真的对了」

很多人把「对」当成一个开关：能跑、能合并，就算对。其实它是一架往下的梯子——能跑，测试过，符合意图，意图达成了目标。越往下，越慢，也越贵。

如今的 coding agent 几乎都会自我验证了：跑测试、自己修 CI、agent 审 agent。但仔细看，它们验证的对象清一色停在梯子的前两级——能跑、测试绿。「这个改动符不符合原始意图」「意图有没有达成目标」，梯子的下半截，基本还空着。

只跑前半截，最贵

最近踩过一个坑：平台前端大改，方向我觉得没问题，用户却很不适应。当时没时间做 A/B，也没来得及埋点。代码全对，产品错了——只跑了梯子的前半截。事后看，真正的错误不在方向判断，在于赌注一次下满：没有小步观察，也没有便宜的退路。

个人如此，团队更是如此：合并门槛若还停在「能跑」，后面的理解成本会集体买单。

错了要能便宜地撤回

测试全绿不等于万事大吉，而且产量还会继续涨。在这种量级上，「尽量别出错」不是一个可行的策略——你穷举不完。更现实的方向是换一个指标：从「多久坏一次」，换成「坏了多快能回来、影响面有多大」。让出错变得便宜、可控、可逆：尝试待在分支和沙箱里，git 是橡皮擦。敢往前，不是因为不会错，是因为错被关在了笼子里。

意图是收敛出来的，不是定义出来的

验证需要参照物：得先有一个说得清的「对」，才谈得上对照。麻烦在于，这恰恰是最靠不住的一环——没有人能一次把「要什么」说清楚。

Brooks 几十年前就写过，软件最难的部分是决定要造什么，而人往往并不知道自己想要什么。指望先写一份完整规格再开工，每一代方法论都这么承诺过，又都失败在同一个地方。

所以别再追求「精确定义意图」了，那是个伪目标。现实一点的目标是让意图低成本地、快速地收敛：规格不是冻结的前置文档，是一个被持续修订的对象。这改变不了需求的不完整——没有任何办法能——它改变的是，不完整多快变得可见。

这里有个值得较真的细节。人和人之间，一句话没说全，对方会察觉、会追问——这条随时校准的通道，是人类协作能保持便宜的原因。而 agent 面对含糊的需求，默认是不问的：自信地选一种解读，高置信地跑完全程，输出还相当完整，差点就能合并。有人把任务需求刻意抹掉一部分，量过这件事：给 agent 加一条「先问再做」的通道，解决率从 61.2% 升到 69.4%，几乎追平拿到完整需求的水平。更有意思的是，后续研究发现模型其实能识别歧义，只是这份觉察保持沉默，除非被显式问到。

也就是说，病灶不是 AI 读不懂人话，是协作协议里缺了那条校准通道。什么都猜和什么都问都是烂路；要的是让系统在填不平的地方，精准地开口。

目标本身，也可能立错

就算意图说清了，目标还可能立错。「提升首日留存」听起来天经地义，万一留存低其实是获客渠道的问题呢？

这里有个两难。目标刻成石碑，你会用全部效率精确地达成一个错误的目标。可目标随时能改，尺子跟着结果滑，你会永远觉得「在达成」，其实什么都没验证——球门在偷偷移动。科研界对付这个两难的办法值得抄：预注册。主指标事先声明，中途想改可以，但要留痕、要给理由，而且「进度落后」不算理由，「假设被证伪」才算。

对 AI 协作，这件事还更硬性一点：agent 的目标会漂移，有人实测过，上下文一长，最初的目标就被近期内容盖过去了。所以目标得外置成一个冻结的参照物，不能指望 agent 在上下文里「记住」它。

我自己的做法朴素得多：动手前写两三句「我为什么相信这件事值得做」。做完一轮回头看，这条信念还在不在。改主意不可怕，可怕的是改了却没人记得为什么改。

返工和扯皮，多半是 theory 没对齐

需求做歪、来回返工，拆到底常常是双方脑子里的背景不一样。但「背景」这个词还是太轻了。Naur 在 Programming as Theory Building 里有个更不安的说法：程序真正的样子，是活在写它的人脑子里的一套 theory，部分不可言说；代码只是这套 theory 的有损投影。人走了，程序还在跑，但它已经死了——他的原话是，仅凭文档复活一个程序，严格不可能。

这解释了两件事。第一，没人能看懂、却还在自动运行的系统，是复利的债，不是解放。第二，AI agent 的危险恰在于此：它不参与 theory 的构建，却能基于猜到的投影，产出完整得足以乱真的结果。「对不齐就随时校准」这条通道，得在人和 AI 之间、也在人和人之间，重新建起来。

人还要守什么

写、测、修里能被规则检验的部分，交给机器，大势如此，不必惋惜。难的是剩下的几块——没有标准答案，或者必须有人扛责。

有标准答案的尽量交出去，没有标准答案的得有人守着。 但这句话有个容易被漏掉的层次：单纯「看得准」是守不住的——看得准是一种预测，预测迟早被模型学走。真正留给人的，是在没有共识的地方做判断，并且把自己的名字押上去。判断不是看得准，是当结果会被追问到你头上时，还看得准。机器给不出这个，不是能力不够，是它没有那份可以被押上的社会关系。

判断力会用进废退

自动化研究里有条经典的 Bainbridge 悖论：自动化越彻底，剩给人的部分越难、越关键，而人平时越少上手，真出事时越生疏。最阴险的是，这个过程感觉像效率，不像损失。

所以我不信「全自动、无人工厂」的字面叙事。丰田的 jidoka 常被翻译成「自动化」，原意其实是「带人性的自动化」：任何工人都有权拉下 andon 绳，让整条产线停下来。真正难的从来不是拉绳，是有一套认真响应拉绳的组织。对 agent 也一样——要紧处得留一根随时能拉的绳，而且拉了真的有人管。

把事情递到人面前的方式也有讲究，不是「多汇报」就好。两个反直觉的地方：其一，几个 agent 意见一致，不构成正确的证据——它们会从众、会互相迎合，把对的答案改错；可靠的形态是各自独立判断，再做校准聚合，而不是辩论出一个共识。其二，有实验发现，给人看 AI 的解释，并不会让人判断得更准，反而让人无论对错都更倾向于接受。所以真正该推到人面前的，不是包装好的结论加一段自信的解释，而是证据、选项、还有被摊开的分歧。沉默运行可以，分歧和拿不准的地方必须主动开口。

真正稀缺的是注意力

Herbert Simon 在 1971 年就把账算清楚了：信息消耗的是接收者的注意力，信息的丰裕造成注意力的贫困。他还顺手点了设计者的经典错误——把问题误当成信息稀缺，而它其实是注意力稀缺。

五十年后，这句话精确命中了 AI 协作：agent 把产出信息的成本压到近零，唯一没跟着变便宜的资源，就是人的注意力。社区还在喊「多给上下文」「多开几个 agent」，很多时候是在制造注意力贫困——产出越来越多，人越来越不知道该看哪。

我试着这么分账：机器擅长「过去」——维护、回归、记细节；人擅长「未来」——往哪走、押什么、怎么取舍。团队里若每个人都在追自己的 velocity，谁来看整体、谁来看债、谁来看该不该改方向，很容易变成真空。

动手之后，会长成什么形状

前面这些想法，不动手就只是清谈。但一旦真的动手——想少派活、少对齐、少在十几个会话之间跳，尤其想让团队拉得快的同时别失控——你会发现缺的不是又一个更强的 coding agent，而是一块控制面。

行业里把这套东西叫 Software Factory，名字唬人，拆开就一句话：人表达意图，系统负责组织生产；agent 干具体活，人只在要紧处拍板。 产线本身——写码 agent、沙箱、它们自带的 memory——正在迅速商品化，没必要重造。值得花力气的是梯子空着的下半截：上游，持续校验「做的东西符不符合意图」；下游，校验「意图有没有达成目标」——两个信号喂回同一条产线。

具体到工程上，有几条是我在自己的原型里反复确认过的：

先 dry-run，后 apply。 意图进来，系统先产出一份可审阅的计划——打算分几步、每步谁做、读哪些背景、过哪些验收、哪里必须等人点头——不入队、不碰仓库。需求偷懒不要紧，但不能猜了就跑；计划摊在面前改几个字，比合并之后才发现理解偏了，便宜几个数量级。这就是前面说的那条校准通道的工程形态。

上下文得能审计。 每个工单开工前，把要读的东西编成一份 context pack，每段可追溯到来源；执行时冻结快照——复盘问的是「当时读了什么」，不是「现在仓库里最新那份」。跑完的经验默认不自动进下一轮：共享记忆是会被污染的，错误的结论一旦写进去，会跨任务持续传播，所以写入要有出处、要有人确认。对团队来说，这件事的意义是把「只有某个人懂」慢慢变成「系统里查得到」——而且查得到的不只是结论，还有当初的分歧和被否掉的方案，那往往是最值钱的部分。

验收认证据，不认口供。 run 结束不是听 agent 说「搞定了」，是看 diff、测试记录、浏览器断言。能自动跑的检查，别让眼睛去替。

写入单线程。 Cognition 的经验很干脆：跑得通的多 agent 形态里，写操作保持单线程，额外的 agent 贡献判断而不是动作——动作携带隐含决策，冲突的决策会复合爆炸。并行用在「多份独立判断」上，不用在「多只手改同一处」上。

至于失败，原则还是前面那条：低成本地失败，快速地恢复。出问题有账可查，修复的工单能生成，流程能从断点继续，而不是静默卡死。

说到底，我在意的不是让 AI 写更多代码，是守住两件它替不了的事：说清楚要什么，和证明真的做对了。 有人把上面这套叫软件工厂，本质不过是把这两件事拆成可重复、可审计的工序：意图进来，计划可审，执行可溯，验收有门，失败能退，上下文越积越厚。

工具越强，越要把力气从「做」挪到「想清楚」和「验清楚」上。剩下的时间，留给生活，留给还没有标准答案的那部分未来。

参考

• Jack Reeves, What Is Software Design? (1992)
• Sean Grove, The New Code (OpenAI, 2025)
• Jason Wei, Asymmetry of Verification and Verifier’s Law (2025)
• Peter Naur, Programming as Theory Building (1985)
• Herbert Simon, Designing Organizations for an Information-Rich World (1971)
• Lisanne Bainbridge, Ironies of Automation (1983)
• Cognition, Don’t Build Multi-Agents (2025)
• Why Do Multi-Agent LLM Systems Fail? · Ask or Assume? · Knowing but Not Showing · Goal Drift in LM Agents · Does the Whole Exceed its Parts?