夜雨聆风
别急着让AI写代码——一个＂审讯式＂工作流,正在重塑程序员的思维方式
一条反直觉的定律：AI 越强，你越需要软件工程基本功
2026 年，几乎所有程序员都在用 AI 写代码。但如果你问 Matt Pocock——TypeScript 领域最具影响力的教育者之一，现在是 AI 开发者教育者——他会告诉你一个反直觉的结论：
“当我们谈论 AI 是一个新范式时，我们忘了一件事——软件工程的基本法则，那些与人协作时至关重要的东西，在 AI 身上同样好使，甚至更好使。“
这句话来自他在 React Advanced London 大会上的两小时工作坊。整场演讲的核心不是教你用什么 AI 工具，而是要重新激活你对软件工程经典理论的记忆。
他引用了四本”老书”：
-
Frederick P. Brooks 的《设计的设计》 -
Martin Fowler 的《重构》 -
《程序员修炼之道》（The Pragmatic Programmer） -
John Ousterhout 的《软件设计的哲学》
每一本都是 AI 时代之前的经典。但 Pocock 用它们构建了一套完整的 AI 编码工作流——这套工作流的核心不是”让 AI 写更多代码”，而是让人类和 AI 先对齐，再动手。
而这一切的起点，是一个叫 “Grill Me” 的技能。
二、AI 有一个”聪明区”和一个”愚蠢区”
在讲 Grill Me 之前，你需要先理解一个关键概念。
一位叫 Dex Hy 的人提出了一个比喻：LLM 有一个聪明区和一个愚蠢区。
当你打开一个全新的对话窗口，从零开始，这时候 AI 处于聪明区。它的注意力机制最灵活，回答质量最高。但随着你不断往上下文里塞内容，每添加一个 token，就像往足球联赛里加一支球队——token 之间的关系数量呈二次方增长，注意力机制越来越吃力。
Pocock 的经验法则是：不管模型的上下文窗口号称多大（200K 还是 1M），真正的聪明区大约只有前 100K tokens。超过这个阈值，AI 就开始犯蠢。
“Context window 从 200K 扩展到 1M，本质上不是给你更多的聪明区——而是给你更多的愚蠢区。”
这意味着什么？
你必须把任务拆得足够小，让每次 AI 操作都留在聪明区内。
这其实就是 Martin Fowler 在《重构》和《程序员修炼之道》里反复强调的：不要贪多嚼不烂。 只不过这句话的对象，从人类开发者变成了 AI。
但问题来了：当你面对一个大型需求——比如给整个系统加一套游戏化功能——你怎么把它拆成足够小的任务？
这里就引出了整个工作流中最反直觉的环节。
三、别用 Plan Mode，用 “Grill Me”
大多数人收到一个新需求时的第一反应是：进入 Plan Mode，让 AI 直接出方案。
Pocock 说：不要。
AI 在你还没对齐的时候就会急不可耐地出计划。这个计划往往方向跑偏，因为 AI 根本不知道你脑子里在想什么。
Pocock 用的是另一个方法：他清空 AI 的上下文，然后调用一个叫 “Grill Me”（审讯我）的技能。
这个技能的核心指令只有一句话：
“一个一个地审问我关于这个计划的每一个方面，直到我们达成共识。”
然后 AI 开始提问。不是出方案，是问问题。
一个一个地问。每次只问一个。
“积分怎么获取？””要不要追溯性补发历史积分？””连续打卡算不算？””UI 放哪里？””等级曲线怎么设计？”
Pocock 说他经历过一次 Grill Me 环节，AI 问了他 80 个问题。他花了将近一个小时，就坐在那里和 AI 对话。
为什么这么做？
因为他引用了 Frederick P. Brooks 在《设计的设计》中提出的”设计概念”（Design Concept）：
当一群人共同创造一个新东西时，所有参与者之间必须存在一个共享的心智模型——这就是设计概念。
Pocock 意识到，你和 AI 之间也需要这个设计概念。不是一份文档，不是一份 PRD——而是你们俩真正”在同一频道上”。
Grill Me 环节的产物不是任何文件，而是一段对话历史——这就是你们共享的设计概念的载体。
这是一个关键区分：
|
|
|
|---|---|
|
|
|
|
|
|
前者是”AI 告诉你它想做什么”。后者是”你们一起想明白了要做什么”。
区别巨大。
四、PRD 只是路标，不是蓝图
Grill Me 完成后，Pocock 让 AI 生成一份 PRD（产品需求文档）。但接下来他说了一句最反直觉的话：
“我不看这个文档。”
为什么？因为你们已经通过 Grill Me 达成了对齐。PRD 本质上只是 AI 在做一件它最擅长的事——总结。你去看它，只是在检验 AI 的总结能力，而不是在做任何有价值的事。
Pocock 甚至不建议你在 PRD 上花太多时间优化：
“PRD 只是一个关于你想去哪里的提示。真正需要投入工作的地方是 QA。”
但他强调了 PRD 中的两个关键部分：
- 目标文档
（Destination）：用户故事、验收标准、功能边界——你到底要做什么 - 路径文档
（Journey）：你打算怎么拆分任务来达到目标
PRD 还有一个重要组成部分：模块映射。Pocock 会在 PRD 中明确列出这次需求涉及哪些模块、是新建还是修改、每个模块的接口是什么。
这不是多余的文档工作——这是为后续的关键决策做准备。
五、AI 天生喜欢”横着写”，你必须逼它”竖着切”
拿到 PRD 后，下一步是把需求拆成可执行的任务。
大多数人会这样做：让 AI 生成一个多阶段计划——Phase 1 做数据库，Phase 2 做 API，Phase 3 做前端。
Pocock 说这是最危险的模式。
他引用了《程序员修炼之道》中的”曳光弹”（Tracer Bullet）概念：
夜间防空作战时，普通子弹打出去你看不到轨迹，根本不知道瞄没瞄准。曳光弹在弹头装了磷光物质，每打一发你都能看到一条发光的弹道——你立刻获得了反馈。
AI 默认的工作方式是”横向分层”——先把一整层做完再做下一层。这就像盲射：你直到 Phase 3 才能看到整个系统是否真的能跑通。
Pocock 要求的是”纵向切片”——每一个任务都是一个完整的曳光弹，从数据库到 API 到前端，薄薄地贯穿所有层级。
这样在 Phase 1 结束时，你已经有一个可以点击、可以测试的最小可用功能。AI 也获得了即时的反馈——它知道自己写的代码是否真的能跑。
这就是为什么 Pocock 用看板（Kanban Board）而不是线性计划：
-
每个任务是一个独立 issue -
任务之间有阻塞关系（A 完成才能做 B） -
但没有阻塞关系的任务可以并行执行
他还会亲自审查 AI 提出的任务拆分，确保它们是纵向切片而不是横向分层。如果 AI 说”第一个任务是创建 gamification 服务”，他会纠正：”不，第一个任务要同时包含 schema 变更、新服务创建和前端的最小展示。”
这一步，人类必须在场。
六、人类上”白班”，AI 上”夜班”
整个工作流中最优雅的区分，是 Pocock 对”人在环中”（Human-in-the-Loop）和”离开键盘”（AFK）任务的划分：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
简单来说：白天你和 AI 对齐，晚上 AI 自己写代码。
Pocock 甚至为”夜班”构建了一套自动化系统，叫 Sand Castle——一个 TypeScript 库，能够：
-
从看板中选取可以并行执行的 issue -
为每个 issue 创建隔离的 Docker 沙箱 -
在沙箱中运行独立的编码 agent -
用更强的模型（如 Opus）做自动代码审查 -
用 merger agent 合并分支
编码 agent 用的是 TDD（测试驱动开发）——先写失败测试，再写实现代码，再运行反馈循环自我修正。整个过程中人类不需要在场。
而代码审查阶段有一个关键设计：审查 agent 在全新的上下文中启动，永远处于”聪明区”。它不会继承编码 agent 的漫长对话历史——那个上下文早已进入愚蠢区。
这就是 Pocock 在开头说的《记忆碎片》类比：AI 就像那个不断失忆的主角。与其让它在失忆状态下勉强工作，不如每次都让它从头开始。
拥抱遗忘，而不是对抗遗忘。
七、”深模块”：对抗 AI 代码腐烂的终极武器
Pocock 工作流的底层架构理念来自 John Ousterhout 的《软件设计的哲学》——深模块 vs 浅模块。
- 浅模块
：大量小文件，复杂接口，错综复杂的依赖图。AI 在其中迷失方向。 - 深模块
：大量功能隐藏在简单接口背后。AI 只需要理解接口就能正确使用。
为什么这对 AI 编码至关重要？
因为 AI 写代码的唯一安全保障是高质量的自动化测试。而浅模块几乎无法写测试——边界太碎、mock 太多、依赖太乱。深模块则允许你用一个简单的接口包装大量的内部逻辑，用一个测试覆盖整块功能。
Pocock 还提出了一个更深层的问题：
“有多少人觉得自己在用 AI 之后，反而对代码库更陌生了？”
这是一个真实的现象。当你把大量代码委托给 AI，你对系统的理解会逐渐退化。最终你变成了一个只会给 AI 下指令的人——你对代码库失去了掌控。
Pocock 的解法是”灰盒子”策略：
- 手动设计
深模块的接口——你掌控系统的”形状” - 委托 AI 实现
模块的内部逻辑——你不需要逐行审查 -
你只需要知道每个模块”做什么”和”行为是什么”，不需要知道它”怎么做”
这让人类开发者能在保持对系统整体架构的理解的同时，充分利用 AI 的速度。
你不是在放弃控制，你是在选择性地控制。
八、Push 还是 Pull：编码标准的新博弈
当你的团队有编码规范时，怎么让 AI 遵守？
Pocock 区分了两种方式：
- Push（推）
：把编码标准强制塞进 AI 的上下文。比如写进 CLAUDE.md 或 system prompt。 - Pull（拉）
：把编码标准放在仓库里，让 AI 在需要时自己获取。比如 Skills。
他的策略是分阶段组合使用：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
实现时用拉——给 AI 空间，让它专注于写代码。审查时用推——用更强的模型，严格地把代码和标准做对比。不通过就打回去。
这再次体现了 Pocock 的哲学：人类负责设计约束，AI 在约束内自由发挥。
九、核心洞见：_specs-to-code 是最大的陷阱
整场演讲中，Pocock 最明确反对的东西是”specs-to-code”运动：
他们的逻辑是：写一份规格文档 → 交给 AI → AI 生成代码 → 代码有问题不要看代码，回去改文档 → 循环。
他称之为”Vibe Coding 的另一种形式”。
他的反驳很直接：
“代码是你的战场。你必须理解它、塑造它、掌控它。”
specs-to-code 的问题不是 AI 不够强——而是你失去了对代码库的理解。当文档和代码产生偏差时（而且一定会产生），你无法判断该信哪一个。
这也是他不保留过期 PRD 的原因——他称之为”文档腐烂”（Doc Rot）。过期的文档躺在仓库里，被 AI agent 找到后当作真理，反而会误导后续开发。
所以他选择：用完即删，用 GitHub Issue 的 closed 状态标记为已完成。需要时可以找回，但不会主动污染上下文。
十、回到开头：为什么老书比新书更有用？
Pocock 在工作坊的最后说了一段让人印象深刻的话：
“如果今天你只带走一件事，那就是回去买一堆老书。我在每一页上都发现了有用的东西。”
这背后的逻辑是：AI 编码不是一种全新的技能——它是一种需要你把旧技能重新理解、重新组合的新场景。
Brooks 教你”设计概念”——Pocock 把它变成了 Grill Me。 程序员修炼之道教你”曳光弹”——Pocock 把它变成了纵向切片。 Ousterhout 教你”深模块”——Pocock 把它变成了 AI 友好的代码架构。 Fowler 教你”小步重构”——Pocock 把它变成了聪明区管理。
这些理论在 AI 时代不是过时了，而是变得更重要了。
因为当你把大量工作委托给 AI，你能掌控的东西只剩两样：
- 你能不能和 AI 对齐？
（Grill Me） - 你能不能设计好约束？
（深模块、纵向切片、编码标准）
这两样东西，恰好是软件工程几十年来一直在研究的核心问题。
AI 没有改变编程的本质——它只是放大了”理解”和”约束”的价值。而你越早意识到这一点，就越不会沦为 AI 的操作员，而是成为真正意义上的AI 时代的设计师。
本文基于 Matt Pocock 在 React Advanced London 2025 上的工作坊演讲”Full Walkthrough: Workflow for AI Coding”深度整理。