AI 写代码，人退到了两头

有个概念我最近一直在用，叫”聪明区”和”笨蛋区”。提出它的是 Human Layer 的 Dex Hardy：一个大模型刚开始一段新对话时最聪明，因为这时注意力关系最松弛；你每往上下文里塞一个 token，它就笨一点，塞到某个量级之后开始做蠢决定。Matt Pocock 在 AI Engineer 大会的这场两小时工作坊，整套 AI 编程工作流，骨子里就是围着这两个区在打转，想方设法让任务一直待在聪明区里。

我看完最大的感受是，这套流程看着花里胡哨，真正的骨架其实很朴素。代码这件事被压成了夜班流水线，可以批量交给 agent 去产；但人没法退场，只是退到了两头：前面负责跟 AI 对齐，后面负责把品味塞回去。中间那段能不能放心交出去，全看一个地基——你的代码库测不测得动。

原视频：https://www.youtube.com/watch?v=-QFHIoCo-Ko

大模型的两个怪癖，决定了流程长什么样

Matt 一上来先讲约束，没急着讲技巧。我觉得这个顺序是对的。你不懂模型为什么会笨，后面所有动作都像玄学。

第一个约束就是聪明区和笨蛋区。他给了个很形象的类比：上下文里每加一个 token，就像往足球联赛里加一支球队，要新增的比赛场次是按平方涨的，因为每个 token 都得跟其他所有 token 建立注意力关系。所以上下文一长，模型不是线性变慢，而是注意力被稀释到开始做蠢事。

他给的标记是大约 10 万 token。这个数得翻译一下：10 万 token 差不多是一本十几万字的中篇小说塞进去的量；关键是这个临界点跟你买的上下文窗口多大没关系，你用 20 万还是 100 万的窗口，聪明区都在 10 万附近。所以别迷信大窗口。Claude Code 上线 100 万窗口那天，Matt 的原话是，他们”只是给你运来了更多笨蛋区”。大窗口适合检索，你塞五本《战争与和平》进去让它找东西没问题；但写代码，聪明区还是那 10 万。

第二个约束，他说大模型像电影《记忆碎片》里那个失忆的主角，每次清空都退回最初状态。这里藏着一个反直觉的取舍。大多数人爱用 compact，把长对话压缩成摘要再接着聊，Matt 偏偏讨厌 compact。他的理由是 compact 会留下”沉积物”，每次压缩出来的状态都不一样，不可控；而直接清空回到原点，状态永远恒定，恒定的东西才好优化。他宁可让 AI 当那个失忆的人。

这两个怪癖摆在这，后面整套流程就好懂了：每个任务都得切到能待在聪明区的大小。问题只剩一个，大任务怎么切。

前面这头：稀缺的是对齐，不是计划

切大任务的老办法是多阶段计划，phase 1 到 phase 4。Matt 说任何像样的开发者看一眼就会发现，这不就是个循环吗，那干嘛不直接 phase N，后台挂一个计划，循环往前推到完成。这就接近一种叫 Ralph Wiggum 的做法：只指定终点，也就是一份 PRD，然后反复让 AI 做一个让我们更接近终点的小改动。Ralph 能用，但 Matt 想要更多结构。

结构从哪来？从对齐来。这是全片我觉得第一个值钱的判断。

他明确反对现在很火的”specs to code”，写一份规格丢给 AI 变成代码，代码有问题就回去改规格、不看代码。Matt 说他认真试过，”烂透了”。因为代码才是你的战场，你得始终捏在手里。specs to code 不过是 vibe coding 换了个名字。

那他怎么开局？一个极小的 skill，叫 grill me，拷问我。整个 skill 就几句话：像审讯一样问我这个计划的每个方面，直到我们达成共同理解；沿着决策树一个个解决依赖；每个问题都给出你推荐的答案，一次只问一个。

为什么是”拷问”，而不是”出计划”？Matt 引了 Frederick Brooks 在《设计的设计》里的一个词，design concept，设计概念，指几个人一起造东西时，大家脑子里共享的那个东西。他说他后来意识到，自己跟 Claude 之间需要的不是一份计划文档，而是同一个波长。计划是死的资产，波长是活的对齐。

现场案例很典型。客户 Sarah Chen（Matt 吐槽 Claude 起名永远是 Sarah Chen）在 Slack 上甩了句话：课程平台留存不好，学生报几节课就流失，想加点游戏化。就这么一句。grill me 跑起来，先派了个子 agent 去探索代码库，然后开始一个个问：积分经济怎么设计、哪些行为得分、要不要追溯历史记录、等级曲线怎么走。其中”要不要把已有的学习记录全部回填”这种问题，Sarah 没想过，Matt 自己也没想过，但这恰恰是不对齐就会翻车的地方。

这里有个细节我特别想记下来。那个探索子 agent 烧了 9 万多 token，可 Matt 的主对话几乎没涨。子 agent 有自己隔离的上下文，脏活累活在里面干完，只把结论滴回主线。等于把”探索”这种最烧 token 的动作外包出去，不污染主对话的聪明区。

一场 grill 能问几十上百个问题，坐着聊一小时是常事。聊完产出的不是别的，就是那段对话历史本身，Matt 把它当成设计概念的资产。你甚至可以把一场跟领域专家的真人会议转录喂进去，让它替你拷问那些你没想到的假设。

最反直觉的来了。对齐完写出 PRD，Matt 不读这份 PRD。他的理由我觉得很硬：我读它是在测什么？我要找的失败模式是什么？大模型最擅长的就是总结，我已经通过 grill 跟它达成了共同理解，这时候读 PRD，无非是在检查它的总结能力而已。对齐发生在拷问环节，PRD 只是对齐的副产品，不是对齐本身。

顺带一提他对工具的态度。有人问试没试过 Spec Kit、OpenSpec、Taskmaster 这些框架。Matt 的回答是：在没有明确赢家、没有唯一正解、一切都在变的阶段，你要尽可能多地拥有自己的规划栈。他见过太多学生过度依赖某个现成框架，一旦卡住，因为不拥有它、对它没有可观测性，只能两手一摊说”这玩意不行”。他给你一套 skill，但他信奉控制反转，栈要攥在你自己手里。

中间这段：实现被压成夜班，但前提是切得对

对齐完有了目的地文档，也就是 PRD，接下来是把它拆成旅程。Matt 不拆成顺序计划，他拆成看板，一堆带阻塞关系的卡片，每张还标上类型：human-in-the-loop，人必须在场，还是 AFK，人可以离开键盘。

拆的方式有讲究，也是我最想说的一点：垂直切片，又叫曳光弹，出处还是那本老书《程序员修炼之道》。

系统是分层的，数据库一层、API 一层、前端一层，服务之间还互相依赖。Matt 发现 AI 特别爱横着写，第一阶段把所有 schema 写完，第二阶段把所有 API 写完，第三阶段才加前端。横着写的毛病是，你要等到第三阶段才第一次拿到反馈，才知道几层到底能不能拼在一起，中间一直在盲写。

正确的切法是竖着切，一条薄薄的功能，从前端一路穿到数据库，哪怕只实现一点点。这样第一个切片做完，整条链路就有反馈了。曳光弹这个比喻挺暴力：防空炮手晚上对着天打，打普通子弹根本不知道飞哪去了；曳光弹每隔几发就有一发带磷光，在夜空里划出一条线，你立刻看到自己瞄哪了。垂直切片就是给 AI 装上这条线，让它别再盲写。

现场他还纠正了 AI 一次。AI 提议第一个切片是”先建游戏化服务”，Matt 说这又是横切，他想看到的第一个垂直切片得包含三样东西：一部分 schema 改动、一个新服务、加上前端上一个最小的呈现。改完之后 AI 给的”课程完成后加积分并显示在仪表盘上”才对，做了一大堆 user story，但最后屏幕上能看见东西，后面往上叠就行。

这些 issue 还有个讲究，叫”可独立抓取”。卡片之间的阻塞关系一画出来，看板就变成一张有向无环图：这张做完，那两张就能被两个 agent 同时抓走。顺序计划只能一个 agent 啃，看板能并行，这是 Matt 偏爱看板的根本原因。

到这一步，人就该离开循环了。Matt 把它比作白班和夜班。前面规划、对齐、拆卡片，是人的白班；一旦推给夜班，agent 就 AFK 干活。任务分两类的意义就在这：规划和对齐这种 human-in-the-loop 的活退不掉，实现这种 AFK 的活可以整段交出去。

夜班的实现循环其实很土。一个 bash 脚本，把所有 issue 的 markdown 拼进一个变量，抓最近几个 commit，然后跑 Claude Code，权限给到自动接受改动，信息一股脑塞进去。这是单次版；循环版更复杂点，关键是跑在 Docker 沙箱里。Matt 特意强调，别急着无人值守，先用单次版盯着跑几遍，看 agent 到底怎么干、在哪卡壳，顺手把 prompt 调顺，再放手。

真正的地基：代码库测不测得动，是 AI 编码的天花板

如果说前面都是流程，这一段才是 Matt 反复砸、也是我认为全片最该记住的因果链。

先是 TDD。他说测试驱动开发对 agent 几乎是必需的，做法是红、绿、重构：先写一个会失败的测试，再写实现让它通过。好处有两层。一是这样攒下来的测试质量不错。二是它治得了 AI 作弊。AI 写测试爱作弊，因为它也是分层干，先把实现整个写完，再在底下把测试整个补上，测试就成了给实现背书。而 TDD 逼它先把代码”仪表化”，再写代码，作弊的空间小得多。Matt 说他甚至把整套技术都往”让 TDD 更好用”上去扭。

然后是那句天花板：反馈回路的质量，就是 AI 能写多好的上限。 如果 AI 在你这儿输出很烂，往往不怪模型，是你的反馈回路太弱。再往前一句更狠，烂代码库造就烂 agent，垃圾进垃圾出。

那什么决定反馈回路强不强？代码库测不测得动。什么决定测不测得动？模块的深浅。这里他搬出 John Ousterhout 的《软件设计哲学》，讲深模块和浅模块。

浅模块是一堆小文件，每个都往外抛一堆东西，彼此依赖盘根错节。这种结构 AI 很难导航，它得手动顺着整张依赖图一个个追；也很难测，测试边界画在哪都尴尬。每个小函数单独包一个边界？那模块之间互相调用、顺序搞错了根本测不出来，还得纠结要不要 mock 掉别的模块。Matt 说，你要是不盯着，AI 默认就会产出这种浅模块的代码库。

深模块反过来，对外是一个小而简单的接口，里面藏着大量功能。测的时候一个大边界往这一个模块上一包，就能罩住一大片逻辑；调用方拿到的接口又很简单。于是链路通了：深模块带来好测的代码库，好测的代码库带来强的反馈回路，强反馈回路让 AI 干得好。这是个正反馈闭环。

深模块还附带一个 Matt 特别看重的心理收益。他先问全场，用了 AI 之后，是不是觉得比以前更累、对自己代码库反而更不熟了，一片举手。他说这是真问题：跑得太快、交出去太多，人就丢了对代码库的掌控感，等于把代码库的形状也外包给了 AI。他的解法是，你去设计这些模块的接口，但把内部实现委托出去。模块对你变成一个”灰盒子”，你知道它的形状、它干什么、在什么条件下怎么表现，但不必逐行 review 它肚子里的东西。这样既能放手让 AI 写，又保住了对整体形状的认知。

怎么把一个浅模块的烂代码库改造成深模块？他有个 skill 直接叫 improve codebase architecture，扫一遍代码库，找哪里能把模块加深。现场跑出来，给了一串候选，比如某个评分服务零测试覆盖、是最大的缺口，还附上耦合理由和依赖类别。他举的最狠的例子是自己那个浏览器里的视频编辑器。这东西工程上很硬核，以前 AI 在里面改代码”惨烈”。他用一个判别联合类型，把从前端到后端整条链路包成一个能从外部测试的大模块，AI 一下能看到、能操作、也能测试整条流。他说效果是天壤之别。这也是全片他唯一点名的”如果只带走一件事”：回去在你自己的 repo 上跑一遍这个 skill，看会发生什么。

后面这头：稀缺的是品味，自动化不了

实现交给夜班之后，人回到第二头，审查和 QA。

第一个细节又跟聪明区有关：让 AI review 自己的代码之前，先清空上下文。因为实现已经烧掉了一大片聪明区，你接着让它 review，它是在笨蛋区里 review，审查者比实现者还笨。清空之后在聪明区审，才审得动。他的成本分工也有意思，实现用 Sonnet，审查用 Opus，因为审查更需要脑子。

自动审查能抓不少 bug，但 Matt 说 QA 还是得人手动来。现场他登录成一个学生账号，进课程、点完成，啪，SQLite 报错，缺一张积分事件表。他一边修 migration 一边说，我不忍心让你们看我做 QA，太无聊了。但他点出了 QA 真正的意义：这是我把自己的品味、自己的意见塞回代码库的地方。 有些团队想把一切都自动化，想法、研究、原型、QA 全自动，结果做出来的应用没品味、很烂，甚至跑都跑不起来。少了人的手感，产出的就是一堆 slop，垃圾。他说，我们这儿不生产 slop。

QA 还有个我之前没意识到的作用，它在给看板生产新 issue。一边实现一边 QA，发现问题就回头往看板上加阻塞卡片，看板可以这么近乎无限地长下去。这就把”审查”从一个终点变成了循环里的一环。

几个我会留意的点

下面是我自己的补充，把视频里几处和我平时的判断对照一下，标清楚是我的延伸。

该不该留下 PRD，Matt 选择删。 他怕的是文档腐烂。一个月后回来改这个功能，Claude 翻出当初那份 PRD 说”我找到原始文档了”，可代码早就改得面目全非，命名、文件结构、甚至需求都变了，旧文档反而把 agent 带歪。他用 GitHub issue，实现完标记关闭，留个”已完成”的视觉标记，要查还能查到。这点跟”文档即接口”的理念有张力。我的看法是，可执行、能被代码验证的文档（测试、类型、迁移）才值得留，纯描述性的意图文档确实容易烂，Matt 删 PRD 但留数据库迁移，分界正在这里。

push 和 pull 这个框架值得抄。 怎么让 agent 按你的规范写代码？Matt 分两路。推（push）是你主动塞给模型的指令，写在 Claude.md 里的东西每次都发过去；拉（pull）是给 agent 一个机会自己取信息，比如 skill，放在 repo 里带个描述头，agent 需要时自己拉。他的搭配是：实现者让它拉编码规范，有疑问自己查；自动审查者给它推编码规范，把规范连同代码一起塞过去对照。同一份规范，在不同环节用不同的递送方式，这个区分挺清爽。

放进更大的图景看，这套东西印证多过新意。 现在业界一个公开的判断是，经典的软件开发生命周期正在坍缩成一个”意图、构建、观察”的紧循环；Matt 的流程基本就是这个紧循环的现场版，只不过他在两端死死按住了人。从工程师技能的角度看，Ousterhout 的深模块、Matt 的”设计接口、委托实现”，跟”底层实现被自动化之后，高层设计技能反而升值”是同一件事的两种说法。他反对那些想接管整个流程、把控制权拿走的重框架，坚持小而可拼、自己能改的轻 skill。这个立场我是认同的，尤其在工具天天变的当下。

最后是他真正的临别赠言：去买老书。 不是《某某 AI 编程实战》，是《程序员修炼之道》《软件设计哲学》《设计的设计》《重构》这些二十年前的旧书。Matt 说他重读这些书，几乎每一页都有能直接扔进 prompt 的东西，因为这些书早就把软件最佳实践用人话讲清楚了，而我们现在做的，某种程度上正是把这些实践重新讲给 AI 听。

这场工作坊我看下来，最受用的不是哪个具体 skill，是它把”AI 写代码”这件事的重心挪明白了。代码本身越来越像可以批量外包的夜班产出，人的价值被挤到了两头：开头能不能跟 AI 真正对齐，结尾愿不愿意把品味塞回去。而中间那段能不能放心交出去，不取决于你的 prompt 写得多漂亮，取决于你的代码库这块地基测不测得动。