AI 编程的七条铁律：Matt Pocock 为什么说老派软件工程是驾驭新 AI 的钥匙

2026 年 4 月，AI Engineer 峰会的讲台上站着一个奇怪的人。

他曾经是声乐教练，拿过 Guilford School of Acting 的硕士学位。2017 年开始写 JavaScript，2018 年转全职开发。在 Vercel 和 Stately 干过，教 TypeScript 为生，GitHub 简介写着"TypeScript wizard"。

这个人叫 Matt Pocock。他的 Claude Code 技能仓库 mattpocock/skills 在 2026 年 2 月冲上 GitHub Trending 第一，24 小时内收获 22,000 颗 star，总 star 数超过 50,000。

但在这次 AI Engineer 峰会上，他讲的不是技能怎么写。他讲的是一个更底层的问题：当 LLM 已经聪明到能写复杂应用时，20 年历史的软件工程教科书该扔了吗？

他的答案响亮且反直觉：千万别扔。真正让你驾驭最前沿 AI 的，恰恰是最老派的编程铁律。

一、聪明区与愚蠢区：10 万 Token 红线

Pocock 在演讲中抛出了一个关键数字：约 100,000 tokens。

这是 LLM 的"聪明区"（Smart Zone）上限。在这个范围内，模型的注意力关系仍可计算，输出质量保持在高水平。超过这个阈值，模型进入"愚蠢区"（Dumb Zone）——注意力机制超载，输出质量断崖式下跌。

这个限制源于注意力机制的数学本质：二次方成本。每新增一个 token，它需要与所有已有 token 建立关系。n 个 token 的关系数是 O(n²)。就像往体育联赛里加球队——新增的球队要和所有现有球队打比赛，总比赛场次增长的速度远快于球队数量。

这意味着，上下文窗口不是越大越好。广告里宣传的"200K tokens"、"1M tokens"是理论容量，实际有效工作区间只有约 100K。超过这个范围，你面对的是一个换了人格的模型——它会忘记前面说过什么，会自相矛盾，会生成" technically correct but practically useless"的代码。

清空上下文（Clearing Context）比压缩摘要（Compacting）更有效。

压缩摘要的问题在于：它创建了一个不一致的状态表示。模型被塞进一段被篡改过的历史，但它不知道哪些细节被丢掉了。这会导致不可预测的行为。相比之下，清空上下文让模型回到系统提示的基态——可预测、可重复，虽然损失了对话历史，但至少你知道它从哪开始。

Pocock 的类比很精准：LLM 就像一个患有严重顺行性遗忘症的人。它不断遗忘并重置。在这种条件下，与其维持一段被压缩过的、质量已下降的记忆，不如定期清空，让每次交互都在清醒状态下进行。

这个判断直接决定了整个工作流的设计：任务必须被切割到能在聪明区内完成的粒度。

二、考问我：让 AI 当你的严苛面试官

"Vibe Coding"——凭感觉让 AI 写代码——是 Pocock 明确反对的做法。

他的替代方案叫 Grill Me。不是你去追问 AI，而是让 AI 像产品经理一样追着你问。40 到 100 个问题，覆盖实现计划的每一个分支、每一个依赖、每一个边界条件。

grilling 的过程有几个特点：

第一，它是系统性的。 AI 会沿着设计树的每个分支走下去，不遗漏任何路径。人类容易被自己的假设蒙蔽——"这个功能显然应该这样"——但 AI 没有这种"显然"，它会追问"为什么这样"。

第二，它生成的是共享理解（shared understanding），而非静态文档。 Frederick P. Brooks 在《The Design of Design》里强调"设计概念"（design concept）——所有参与者对系统的一致理解。Grill Me 的目的不是产出一份 PRD 然后丢给另一个实体，而是确保参与实现的 AI 和人类拥有相同的概念基础。

第三， grilling 后的产物是可重用的对话资产。 这段 40-100 个问题的对话历史本身就是一份动态文档，在实现阶段可以被引用和回溯。

Pocock 把这种做法和"氛围式编程"做了对比。Vibe Coding 的陷阱在于：你以为你和 AI 达成了共识，但实际上你们的理解可能有微妙偏差。这些偏差在简单任务中不明显，在复杂任务中会累积成灾难。

grilling 的本质是用"前置痛苦"避免"后置灾难"。花 30 分钟被 AI 拷问，比花 3 小时调试因为需求理解偏差而产生的 bug 更划算。

三、PRD 作为终点，而非起点

grilling 的产物是一份 PRD（Product Requirements Document）。但 Pocock 对 PRD 的定位和常规做法不同：

PRD 是终点，不是起点。

在传统流程中，PRD 是项目启动时的规划文档，之后被束之高阁，直到验收时才重新翻开。Pocock 的做法是： grilling 完成后生成 PRD，然后整个后续工作流都围绕这份 PRD 展开——它是目的地，所有实现步骤都在朝它逼近。

这种定位的变化看似细微，但影响深远。当 PRD 是"起点"时，它容易被遗忘和侵蚀（Doc Rot）。当 PRD 是"终点"时，它持续被引用和校验，保持鲜活。

Pocock 有一个 skill 叫 /prd-to-issues，把 PRD 拆解成带阻塞关系的独立工单（issue）。每个工单切穿所有系统层，留下可见的端到端成果。这些工单构成一个有向无环图（DAG）——没有共享依赖的任务可以被不同 Agent 同时抓取，把看板变成并行化的执行引擎。

四、曳光弹与垂直切片：拒绝横向编程

AI 的默认编码模式是横向的：先做完整的数据库层，再做完整的 API 层，最后做完整的前端层。这种模式的问题是反馈被推迟到第三阶段——你直到最后才知道各层之间是否对齐。

Pocock 的修复方案来自《The Pragmatic Programmer》里的曳光弹（Tracer Bullets）概念：

曳光弹是发光弹药，在飞行中留下可见轨迹，让你立即知道射击方向是否正确。

应用到软件开发：每个功能都做一个垂直切片——从数据库到 API 到前端，切穿所有层，留下一个可见的端到端成果。比如"完成一节课后奖励积分，积分在仪表盘可见"。这个切片可能简陋，但它证明了完整路径是通的。

这和水平分层的对比：

垂直切片和看板结构直接对应：每个切片是一个可独立执行的工单，有明确的阻塞关系。 planner agent 分析工单之间的依赖，确定哪些可以并行；多个实现 agent 各拿一个切片，在各自的沙箱中工作。

五、Ralph 循环：指定终点，小步逼近

Ralph Loop 是 Pocock 工作流中的执行引擎。

它的核心逻辑很简单：在 PRD 中指定终点（"我们要到达这里"），然后反复指示 AI 做小增量改动逼近终点。这个名字来自《辛普森一家》里的 Ralph Wigum——一个看似简单但不断向目标靠近的角色。

Pocock 演示了一个 ralph-once.sh 脚本：读取所有 issue markdown 文件，抓取最近 5 个 commit 作为上下文，然后用 Claude Code 在 permission-mode 下自动执行一次迭代。一次运行产出了一个 gamification service 和 284 个通过的测试。

但 Ralph Loop 本身不如多阶段计划+垂直切片的结构严密。Pocock 的完整工作流是两者的结合：

1. 规划阶段（人类主导）： grilling → PRD → 垂直切片工单
2. 执行阶段（AI 主导）：每个切片进入 Ralph Loop，自动迭代直到完成

执行阶段的优先级排序：先修关键 bug，再处理基础设施问题，再做曳光弹验证路径，最后处理 quick wins。

六、TDD：防止 AI 作弊的唯一手段

测试驱动开发（TDD）在 Pocock 的工作流中不是可选项，是必需项。

原因很残酷：如果没有 TDD，AI 会作弊。当你让 AI 同时写测试和实现时，它会写那些 trivially pass 的测试——测试看似覆盖了功能，但实际上对实现毫无约束力。

Pocock 的 /red-green-refactor skill 强制执行这个顺序：

1. Red：先写一个失败的测试，确认它是红的
2. Green：写最小实现让测试通过
3. Refactor：清理代码，测试保持绿色
4. Commit
5. 打勾：在 PROMPT.md 中标记任务完成

这个循环的妙处在于：测试是 AI 的诚实契约。先写测试意味着 AI 不能事后编造一个凑数的测试；测试先失败再变绿意味着 AI 确实理解了要解决的问题。

更深层的原因：AI 在没有 robust 反馈机制的情况下是"盲写"的。测试、类型检查、linter 这些自动化验证直接决定了 AI 输出的质量天花板。你花在收紧反馈回路上的每一分钟，都省去了手动审查低级错误的时间。

七、深模块：让 AI 能读懂你的代码

John Ousterhout 在《A Philosophy of Software Design》里区分了两种模块：

• 浅模块：很多小文件，导出很多函数，每个函数只做一点点事。依赖纠缠，测试边界模糊。
• 深模块：小接口，大实现。暴露极少，内部封装大量复杂度。一个测试边界就能包裹整个模块。

Pocock 把这套理论直接搬到 AI 编程场景：深模块对 AI 更友好。

原因：浅模块结构要求 AI 手动追踪依赖关系，测试边界不清导致 AI 难以判断改动的影响范围。深模块则让 AI 能在更高抽象层次上推理——"这个模块做什么"比"这 20 个文件各自做什么"更容易被 LLM 理解。

Pocock 的 /improve-codebase-architecture skill 扫描仓库，找出可以被 consolidated 的浅模块集群，建议合并成深模块。一个具体案例：把一个浏览器端视频编辑器的完整流程（前端到后端）包裹进一个单模块，用 discriminated unions 做接口，AI 对这个流程的改动能力显著提升。

这不是为了人类阅读方便——虽然人类也受益——而是为了让 AI 能在正确抽象层次上操作。当 AI 面对一堆细碎文件时，它会迷失在细节里；当 AI 面对几个深模块时，它能像人类架构师一样思考。

八、日夜交替：人类白班，AI 夜班

Pocock 工作流中最具画面感的部分是日夜交替（Day Shift / Night Shift）。

白班（Day Shift，人类主导）：

• 用 Grill Me 对齐需求
• 生成 PRD
• 拆解垂直切片工单
• 审查昨日 AI 产出的 PR
• 做手动 QA

夜班（Night Shift，AI 主导）：

• 读取 issue markdown
• 进入 Ralph Loop 自动执行
• TDD 驱动，红绿重构
• 提交 commit，通过 CI
• 第二天早上人类来验收

这个分工的核心判断：规划需要人类判断力，实现可以无人值守。

Pocock 用 ralph-once.sh 把夜班自动化。这个脚本本质上是一个 headless Claude Code 运行器：给一份指令，让它在沙箱里自己跑，第二天早上回来收成果。

九、Sandcastle：并行化的基础设施

Night Shift 要真正 scale，需要并行化。一个 agent 跑一个工单太慢，多个 agent 同时跑多个工单才能发挥 AI 的最大效率。

Pocock 为此花了一周时间写了 Sandcastle——一个 TypeScript 库，用于编排沙箱化的 AI 编码 agent。

架构：

1. Planner：分析看板工单和阻塞关系，决定哪些可以并行
2. Implementer（每工单一个）：在独立的 Docker worktree 里运行，用 Sonnet 做实现
3. Reviewer：用 Opus 做代码审查，独立的上下文窗口——不和实现者共享上下文
4. Merger：合并所有分支，解决类型冲突和测试失败

关键点：实现者和审查者绝不共享上下文。Pocock 的理由是——审查者如果在"愚蠢区"（积累了大量实现历史的上下文）工作，它的审查质量会比实现者还低。给审查者一个全新的上下文，让它用新鲜的眼光看代码，才能发现实现者忽略的问题。

Sandcastle 的设计理念很朴素："我想要一个简单的 TypeScript 函数，能让我在沙箱里跑 agent——找不到，就自己写。"

import { run, claudeCode } from "@ai-hero/sandcastle";
import { docker } from "@ai-hero/sandcastle/sandboxes/docker";

await run({
  agent: claudeCode("claude-opus-4-6"),
  sandbox: docker(),
  promptFile: ".sandcastle/prompt.md",
});

十、推与拉：标准怎么注入 AI

Pocock 还区分了两种向 AI 注入编码标准的方式：

推（Push）：把标准写在配置文件里（如 claw.md），每次对话都塞给 AI。适合审查阶段——审查者需要直接拿标准和代码对比。

拉（Pull）：让标准可被按需检索。适合实现阶段——实现者需要时才查，不需要时不吃 token。

不同任务配不同模型：Sonnet 跑实现（快），Opus 跑审查（深）。这是 wshobson/agents 的模型分层策略的另一种表述——用对的模型做对的事。

结语：老派铁律的新生命

Matt Pocock 的工作流给人的第一印象是复杂： grilling → PRD → 垂直切片 → Ralph Loop → TDD → 深模块 → Night Shift → Sandcastle 并行 → 人类审查。

但剥开这些名词，底层的逻辑非常简单：

1. 承认 LLM 的局限性（聪明区 100K，注意力二次方成本）
2. 在局限性内设计任务粒度
3. 用老派软件工程原则做护栏（TDD、垂直切片、深模块、曳光弹）
4. 让人类做只有人类能做的事（判断、品味、架构决策）
5. 让 AI 做 AI 擅长的事（在明确边界内高效执行）

这不是"AI 取代工程师"的叙事，而是"AI 放大工程师"的叙事。Pocock 引用 Boris Cherny（Claude Code 的创造者）的话：

"软件工程师这个头衔会消失，变成'builder'或'product manager'。"

但消失的是"写代码"这个执行动作，不是"判断什么代码值得写"这个决策动作。写代码从来就不是大型项目的瓶颈——理解需求、设计架构、保证质量才是。AI 把前者自动化了，后者的价值反而更凸显。

Lee Robinson 在三个人用 AI 做了三个生产级项目、没手写一行代码之后说：

"写代码从来不是真正的瓶颈。"

Matt Pocock 用一套从声乐教练转型的工程师视角，把这句话变成了一个可执行的系统。

参考来源：

• Matt Pocock 演讲原视频 — https://www.youtube.com/watch?v=-QFHIoCo-Ko
• Sean Weldon 学术风格分析 — https://www.sean-weldon.com/blog/2026-04-27-workflow-for-ai-coding-matt-pocock
• TalksIntel 逐段笔记 — https://talksintel.ai/talks/full-walkthrough-workflow-for-ai-coding-matt-pocock
• EveryDev.ai Sandcastle 解析 — https://www.everydev.ai/p/blog-typescript-agent-frameworks-in-2026-loop-runtime-sandbox
• Alexop.dev AFK Coding 实践 — https://alexop.dev/posts/how-to-do-afk-coding/
• AI Hero 课程 — https://www.aihero.dev/cohorts/ai-coding-for-real-engineers-m0k0w

#深度研究 #AICoding #MattPocock #Agent工作流 #TDD #垂直切片 #深模块 #AI工程 #小凯