代码变快以后，工程师开始设计反馈

Matt Pocock 的这场 AI coding workshop，表面上讲的是一套工具流：Grill Me、PRD、Kanban、TDD、Sandcastle、并行 agent。真正有价值的地方不在工具名，而在它重新划定了工程师的工作边界。

以前，软件开发里最贵的环节通常是实现。一个功能从想法到代码，要经过讨论、拆分、编码、联调、测试、评审，很多团队自然会把注意力放在“怎么写得更快”。

AI 进入之后，写代码本身开始变便宜。一个 agent 可以探索代码库，可以生成 migration，可以写 service，可以补测试，也可以在 Docker sandbox 里跑一轮又一轮。于是问题变了：当实现速度上来以后，真正限制质量的东西变成了任务边界、反馈速度、架构形状、测试质量和人工品味。

这也是 Pocock 这场 workshop 的核心信号：AI 编码不是把工程师从代码里解放出来，而是把工程师推到更靠前、更靠后的两个位置。靠前的位置是定义问题、拆任务、设计接口；靠后的位置是验证行为、评审代码、施加品味。中间那段实现，可以越来越多地交给 agent。

任务要待在模型的清醒区

Pocock 一开始用了 “smart zone / dumb zone” 来解释 LLM 的限制。他认为，当上下文不断膨胀，模型会逐渐变差；他给出的经验线大约是 100k tokens。更大的上下文窗口当然有用，尤其适合检索，但对编码来说，塞进更多材料并不会自动带来更好的判断。

这件事对工程实践的影响很直接：不要把大项目一次性丢给 AI。大任务需要被拆成模型可以理解、可以完成、可以验证的小任务。

这听起来像老生常谈。Martin Fowler、《The Pragmatic Programmer》这类传统工程建议早就说过，不要一口吃太多。但 AI 让这条建议变得更硬了。人类在大任务里会焦虑、混乱、丢细节；模型在大上下文里会失焦、串线、做出奇怪决定。

所以，AI coding 的第一条纪律不是“写一个更强的 prompt”，而是控制任务尺寸。prompt 再聪明，也救不了一个没有边界的任务。

Pocock 还用了另一个比喻：LLM 像《Memento》里的主角，会不断回到基础状态。很多开发者喜欢 compact，把长对话压缩成摘要继续做。他更偏向清空上下文，让 agent 每次回到一个稳定起点。

这背后的判断很实用：与其期待模型保留一个越来越浑浊的历史，不如把重要状态沉淀成明确资产，再让下一轮 agent 从干净上下文出发。模型会忘，所以工程师要决定什么值得被写下来，什么应该丢掉。

对齐先于计划

这场 workshop 里最值得借鉴的环节，是 Pocock 的 “Grill Me” 技术。

当他拿到一个模糊需求，比如“给课程平台加 gamification，提高留存”，他没有立刻让 AI 写计划，而是让 AI 反过来盘问自己。积分从哪些行为来？看视频算不算？历史进度要不要回填？等级曲线怎么设？UI 放在哪里？哪些东西暂时不做？

这一步的目标不是产出文档，而是建立 shared design concept，也就是人和 agent 对同一个问题形成共同理解。

这点很关键。很多团队使用 AI 的失败路径，是从“模糊想法”直接跳到“生成代码”。中间缺少对齐，于是后面所有速度都会放大偏差。代码写得越快，返工也越快。

Grill Me 的价值在于，它把需求里的沉默假设暴露出来。用户说“加游戏化”，真正的问题可能是留存，也可能是激励，也可能是课程进度反馈不足。积分、 streak、等级、排行榜听起来都合理，但它们会带来不同的产品后果和工程后果。

在 AI 时代，计划本身没有那么稀缺。真正稀缺的是人和 agent 对“为什么做、做到什么程度、哪些东西不做”的共同判断。

PRD 是目的地，不是施工图

对齐之后，Pocock 会把讨论总结成 PRD。他把 PRD 称为 destination document，目的地文档。它描述问题、方案、用户故事、实现决策、测试决策，以及范围外事项。

有意思的是，他说自己通常不会仔细读这份 PRD。原因也很直接：如果前面的 Grill Me 已经建立了共同理解，PRD 主要是在考验模型的总结能力，而模型很擅长总结。工程师真正要投入判断的地方，不是把每个句子润色到完美，而是确认任务是否已经足够清楚，可以进入下一阶段。

这对很多团队是个提醒。AI 工作流里的文档不应该自动膨胀成新的官僚系统。PRD 的价值是把对齐结果变成可传递的目的地，让后面的任务拆分和实现有参照。它不需要成为一份永久神圣的说明书。

Pocock 对文档腐烂也很警惕。他提到，如果一个旧 PRD 留在仓库里，一个月后 agent 可能把它当成当前事实；但实际代码结构、命名、需求都已经变化。于是旧文档开始误导新 agent。

所以，AI coding 需要更严格地区分两类材料：当前事实和历史记录。历史可以保留在 issue 系统、关闭状态、审计记录里；仓库里的长期文档必须非常克制。文档一旦过期，它就不再是知识，而是噪音。

任务拆分要让反馈尽早出现

有了 PRD，下一步不是生成传统的多阶段计划，而是拆成 Kanban 上可以独立领取的 issue。

这里 Pocock 强调 vertical slice，也就是 tracer bullet。AI 很容易横向开发：第一阶段做数据库，第二阶段做 API，第三阶段做前端。这个顺序看起来整齐，但危险在于，系统到最后才有端到端反馈。等你发现数据库、服务层、UI 之间没有真正接起来，已经堆了太多代码。

更好的第一片任务，是“完成课程后获得积分，并在 dashboard 上看到结果”。它可能包含 schema、service、route、UI 的最小改动，但它给了一个可运行、可观察、可验证的完整闭环。

这就是 tracer bullet 的意义：先让一颗带光的子弹飞出去，看方向准不准。

AI agent 最需要这种反馈。没有反馈，它只是持续生成文本；有了端到端反馈，它才在一个工程系统里工作。测试、类型检查、运行页面、人工 QA，都是让 agent 从“写代码”进入“修正行为”的方式。

工程师该怎样分配 AI 任务

下面这张表可以直接用在团队任务拆分会上。它的目的不是判断“要不要用 AI”，而是判断人和 agent 各自该站在哪里。

这张表背后的原则很简单：判断、边界、品味留给人；可验证的实现循环交给 agent。人不需要手写每一行代码，但要牢牢掌握任务如何被定义、如何被观察、如何被合并。

TDD 变成 AI 的天花板

Pocock 对 TDD 的态度很强：想让 agent 写出可靠代码，TDD 非常关键。

原因不只是“测试很重要”。在 AI 工作流里，测试是 agent 的感官。没有测试，agent 就是在黑箱里生成代码；有测试，它才知道自己刚才做的事情有没有推进目标。

他特别提到 red-green-refactor：先写失败测试，再写实现，再重构。这样做可以减少 AI “作弊式测试”的问题。很多 agent 如果先写完整实现，再回头补测试，就容易写出只验证表面、甚至迎合实现细节的测试。先让测试失败，可以迫使它在实现前建立一个行为边界。

这也解释了为什么很多团队觉得 AI 在自家代码库里表现很差。问题可能不在模型，而在反馈系统。类型检查慢、测试缺失、边界不清、前端无法自动验证，都会拉低 agent 的上限。

Pocock 说得很直接：反馈循环的质量，就是 AI 编码能力的天花板。

深模块让人保留系统感

这场 workshop 最有工程含量的部分，是 deep modules。

Pocock 借用了 John Ousterhout 的说法：浅模块暴露很多小接口，内部功能很少；深模块暴露简单接口，内部隐藏大量功能。对 AI 来说，浅模块很难处理，因为依赖图分散、测试边界模糊、调用关系需要一路追踪。它容易在许多小文件之间生成更多胶水，最后让系统更碎。

深模块对 AI 更友好。人可以设计接口，定义这个模块做什么、输入输出是什么、行为如何验证；agent 可以实现内部细节。测试也可以围绕这个深模块建立更有意义的边界。

这对工程师有一个额外好处：保留代码库的 mental model。

AI 让开发速度变快，也让人更容易失去对代码的掌控感。你知道功能做完了，但不再清楚系统长什么样。深模块提供了一种折中：工程师不必记住每行代码，但要记住系统里的大形状。哪些模块存在，它们的接口是什么，它们承担什么责任，它们之间如何连接。

这比“全程手写”更现实，也比“全交给 AI”更可靠。

人的品味变成最后一道质量系统

Pocock 在 demo 里让 agent 做了一个 gamification 功能。它写了 migration、service、测试，也跑了 typecheck。然后手工点页面时，还是遇到了 SQLite table 相关错误。

这很真实。自动反馈能抓住很多问题，但仍然覆盖不了全部。尤其是前端、产品体验、真实用户路径、交互细节，今天的 agent 还很难完全替代人眼。

所以 QA 在这个流程里不只是“验收”。QA 是工程师把品味重新施加到系统上的地方。它会产生新的 issue，回到 Kanban，再让 agent 继续实现。实现可以 AFK，品味不能 AFK。

这也是 AI coding 对工程师最实际的要求：你会做更多 review，而不是更少。你会更少敲重复代码，但会更多判断测试是否有效、接口是否干净、任务是否过大、agent 是否把系统带偏。

代码变快以后，工程师的工作没有消失。它变得更像设计一个高质量反馈系统。

AI 编码的成熟标志

很多人评价 AI coding，还停留在“它能不能一次写对”。这个标准太粗了。真实工程里，人也不会一次写对。成熟的标准应该是：系统能不能让错误尽早暴露，让修正足够便宜，让人始终掌握方向。

Pocock 的整套流程可以压缩成一句话：

先用人类判断建立方向，再用反馈系统释放 agent。

方向包括需求澄清、范围收敛、模块接口、任务依赖。反馈包括 TDD、类型检查、自动 review、手工 QA、Kanban 回流。方向不清，AI 会快速跑偏；反馈不足，AI 会自信地产出垃圾；架构太碎，AI 会把系统搅得更碎；人完全退出，产品会失去味道。

AI coding 对工程师真正的挑战，不是学习某个新工具，而是重新理解自己的职责。

以前，工程师主要靠实现能力证明价值。现在，实现正在变便宜，能把实现变成可靠系统的人更值钱。这个人知道什么时候该问问题，什么时候该写 PRD，什么时候该拆 vertical slice，什么时候该让 agent 跑，什么时候该停下来亲自点一遍页面。

未来优秀的工程师，不只是会用 AI 写代码的人。

他们会设计让 AI 写出好代码的环境。

资料来源

本文基于 Matt Pocock 在 AI Engineer workshop《AI Coding For Real Engineers》中的公开 transcript 和材料摘要整理写作，材料保存时间为 2026-04-26。