8 部软件工程经典，如何炼成 Matt Pocock 的 AI Skill 工作流

多数人用 AI 编码，是「边画图纸边砌墙」。需求没想清楚就动手，写到一半发现方向错了。Matt Pocock 的工作流不一样。他先深度访谈，达成共识；再拆成可并行的垂直切片；最后让 AI 在干净的上下文窗口里自主实现。整套流程由一组 Skill 驱动，形成一套可以重复执行的系统。

这套工作流的理论支柱，不是「AI 原生」的东西，而是八本老书。它们都写在 AI 诞生之前，是软件工程的经典。Matt 在两场演讲里反复引用：

• 《设计原本》
  ：设计树 / 设计概念，/grill-with-docs 的核心概念
• 《软件设计的哲学（第2版）》
  ：深模块 vs 浅模块、复杂度的定义，/codebase-design 的理论基础
• 《程序员修炼之道：通向务实的最高境界（第2版）》
  ：曳光弹、软件熵、"跑得比大灯快"，推动 /to-tickets 的垂直切片策略
• 《领域驱动设计：软件核心复杂性应对之道》
  ：统一语言（Ubiquitous Language），/domain-modeling 的理论基础
• 《重构：改善既有代码的设计（第2版）》
  ：小步改动、代码坏味道，/code-review 的内核
• 《修改代码的艺术》
  ：seam（接缝），/codebase-design 的核心概念
• 《测试驱动开发》
  ：红-绿-重构循环，/tdd 与 /implement 的内核
• 《解析极限编程》
  ：持续反馈、小步发布、拥抱变化，贯穿日班/夜班工作模式

Matt 在演讲结尾引用了 Kent Beck 的话："每天投资于系统的设计。"

我已经将这些书整理好了书单和资料，关注点赞收藏加留言，我将私你。

一、LLM 的两个硬约束

Matt Pocock 在 workshop 开场做了个调研。在场所有人都在用 AI 编码，大部分每天都用。但几乎每个人都有过「被 AI 气到想摔键盘」的时刻。

问题出在哪？出在 LLM 的两个底层约束上。

Smart Zone（聪明区）与 Dumb Zone（愚蠢区）。 这是 Dex Horthy（HumanLayer 创始人）提出的概念。LLM 的注意力机制，复杂度是 O(n²)。什么意思？上下文里的每个 token，都要关注其他所有 token。token 一多，关系数量就按平方增长。

Matt 用足球联赛打了个比方。多加一支球队，比赛场数不是线性增加。而是每个队都要跟其他所有队打一轮。注意力预算固定，context 越长，每个 token 分到的注意力就越薄。模型推理质量会随上下文填充率，分三档下降：

• Smart Zone（聪明区，0–40% 上下文占用，约前 100K token）：
   注意力还不紧张。推理、编码、设计，都在最佳工作区。
• Warm Zone（温暖区，40–70%）：
   质量开始下降。指令遵循变弱，模型开始依赖预训练模式，而不是你的实际输入。
• Dumb Zone（愚蠢区，70%+）：
   注意力严重稀释，幻觉率飙升，约 40%。模型开始「拍马屁」：它说「你说得完全对」，这反而是危险信号。

LLM 像《记忆碎片》的主角。 Matt 反复用这个类比。电影里 Leonard 每过几分钟就重置记忆，只能靠纹身和便签维持线索。LLM 也一样：对话每推进一轮，它就离初始状态更远一步。compacting（压缩上下文）不如 clearing（清空重来）。因为压缩过的上下文是「残影」，关键信息已经丢了。

两个约束指向同一个结论：LLM 在长对话窗口里持续工作，质量会稳步下降。解法不是指望更好的 prompt，而是一套系统化流程：把工作拆成多个独立的「聪明区窗口」。

二、工作流总览：一条主流程 + 三条匝道

Matt 当前的工作流结构，比视频里展示的更丰富。核心是一条主流程，三条「匝道」汇入，两个「词汇层」在底下运转。

主流程：idea → ship（从想法到交付）

 grill-with-docs → [可选 prototype 分支] → to-spec → to-tickets → implement

每个 /implement 内部驱动 /tdd 循环。完成后自动运行 /code-review，做两轴审查：编码标准 + spec 一致性。

三条匝道（On-ramps）

• 有 bug 报告/需求涌入
   → /triage，把原始 issue 变成 agent 可直接执行的 tickets
• 遇到难缠的 bug
   → /diagnosing-bugs，不靠猜测，先建立能复现的反馈循环再修
• 巨大的、不知从何下手的项目
   → /wayfinder，通过「决策 tickets」逐步理出头绪，产出的是决策，不是交付物

两个词汇层（Vocabulary）

• /domain-modeling
   — 打磨领域语言，把模糊术语变成精确定义，记录 ADR。源自 Eric Evans《Domain-Driven Design》（《领域驱动设计：软件核心复杂性应对之道》）的「统一语言」（Ubiquitous Language）概念
• /codebase-design
   — 深模块词汇（模块、接口、深度、接缝、适配器），被 /tdd 和 /improve-codebase-architecture 共用

路由入口

不知道用哪个？输入 ask-matt。它是一个路由 skill，会根据你的情况，告诉你走哪条路径。

如果你仔细看，会发现这套工作流的每个环节，背后都站着一位软件工程前辈：

1. grilling 阶段的「设计树」
    — Brooks《The Design of Design》（《设计原本》）
2. TDD 循环的红-绿-重构内核
    — Beck《Test-Driven Development》（《测试驱动开发》）
3. 垂直切片策略：「曳光弹」
    — Hunt & Thomas《The Pragmatic Programmer》（《程序员修炼之道：通向务实的最高境界（第2版）》）
4. code-review 的十二条坏味道
    — Fowler《Refactoring》（《重构：改善既有代码的设计（第2版）》）
5. 深模块 / 浅模块理念
    — Osterhout《A Philosophy of Software Design》（《软件设计的哲学（第2版）》）
6. 统一语言（Ubiquitous Language）
    — Evans《Domain-Driven Design》（《领域驱动设计：软件核心复杂性应对之道》）
7. seam：在不修改代码的前提下创造可测点
    — Feathers《Working Effectively with Legacy Code》（《修改代码的艺术》）
8. 日班 / 夜班分工
   ：Matt 自己的操作模型，底层思想是 Beck《Extreme Programming Explained》（《解析极限编程》）的持续反馈与小步交付

八部经典的核心概念，被 Matt 逐一翻译成了 AI 可执行的 Skill。不是生搬硬套，而是让几十年前写在纸上的工程智慧，真正活在了 AI 编码的工作流里。

三、grill-me → grill-with-docs：三句话，五十个问题

grill-me 是 Matt 最早也最核心的 Skill。全文如下：

"Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one. And finally, if a question can be answered by exploring the code base, explore the code base instead."（「就本计划的每一个方面对我进行持续追问，直至达成共同理解。沿设计树的每一个分支遍历到底，逐一消解决策间的依赖关系。凡可通过探索代码库回答的问题，则直接探索代码库，无需询问。」）

就三句话。Matt 用它做过最长的一次访谈：45 分钟，50 个问题。

grill-me vs grill-with-docs

当前版本分裂成两个入口。底层跑的是同一个 /grilling 原语：

• grill-me
   — 无状态版。不在工作目录里时用。打磨一个想法、一段设计、一篇文章，不留本地文件。
• /grill-with-docs
   — 有状态版。在项目目录里用。它把访谈结果写入 CONTEXT.md 和 ADR（Architecture Decision Records），后续 skill 可以读取。只要在项目里，就优先用这个。

设计树：源自《设计原本》

grilling 的核心概念叫「设计树」（Design Tree），来自 Frederick P. Brooks 的《The Design of Design》（《设计原本》，2010）。面对一个设计决策，每选一个分支，下面又分叉出更多子决策。比如搜索功能：用简单搜索框还是高级搜索？选了高级搜索，过滤器有哪些？排序方式呢？每个分支必须走到底，才算把设计想清楚。

Claude Code 的默认行为，是进入 Plan Mode 后立刻吐一份计划文档。grill-me 强制打断了这个节奏：先别写文档，先问到我无话可问为止。

Matt 展示了一次真实对话。他给 Claude 一段 Markdown 格式的研究笔记，输入 grill-me。Claude 先探索了相关代码库，然后开始连续提问：文档存在哪里、UI 布局、哪些模式会用到文档面板、编辑工具长什么样……涉及积分经济、streak、回填、等级阈值。AI 自己说，这还是一次「短的」访谈。

SubAgent探索：不消耗主上下文

grill-me 的一个关键设计，是事实归 AI，决策归人。grilling 把访谈中的问题分成两类。需要查代码库才能回答的，是「事实」：派 SubAgent 去读代码，不问你。需要你做判断的，是「决策」：必须等你来选。

SubAgent 消耗的 token，不计入主对话的上下文窗口。而且不阻塞：只有依赖该项探索结果的下游问题才会等待，本轮其他问题照常推进。Matt 展示的一次真实运行里，SubAgent 消耗了 93.7K tokens（在 Opus 上），但主对话窗口保持干净。

grill-me 的力量不在长度，在选词：relentlessly（持续追问的力度）、design tree（源自 Brooks《设计原本》的成熟框架）、explore the codebase instead（给 AI 一个明确的「别问我」的规则）。

四、to-spec：把对话变成规格说明

grill-with-docs 让人与 AI 达成共同理解，在 CONTEXT.md 和 ADR 里留下了记录。下一步，需要一份「目的地」的描述：这在旧版叫 write-PRD，现在升级为 /to-spec。

工作流是这样的：grill-with-docs 的对话历史 → AI 提取关键决策 → 生成结构化的 spec 文档 → 发布到 GitHub Issue（或保存为本地 .scratch/ 下的 markdown 文件，开箱即用）。

Matt 展示了一份真实 spec 的结构，由七个部分组成：

Seam（接缝）这个概念，来自 Feathers《Working Effectively with Legacy Code》（《修改代码的艺术》）：一个不用改代码、就能改变程序行为的位置。Matt 把它放在了 spec 的第一行。任何变更，先把接缝找对。

Seam 在写任何正文之前，会先跟你确认。因为后续 /tdd 只在约定好的 seam 处写测试，/code-review 拿着 spec 对 diff：没约定过的 seam，会被作为 review 问题揪出来。

一个反直觉的设计选择：

Spec 主要是写给下一个 AI skill 看的，不是给你审的。

Spec 只是 grilling 对话的摘要。真正重要的是访谈达成的共同理解。逐字通读 spec，等于在测试 LLM 的摘要能力：浪费时间。

人只需要扫两个地方：

• Seam（接缝）
  ：测试在哪里切入。这个地方错了，整个 TDD 循环跑偏。
• Out-of-Scope
  ：明确不做什么。这个地方错了，AI 在不需要的工作上浪费 token。

省下打磨 spec 措辞的精力，拿去实际测一测。

Spec 的另一个原则，是「保持耐久」：不过度规定实现细节。代码变了，spec 不能变成废纸。Spec 描述「到哪里去」，不规定「怎么走过去」。

五、to-tickets：垂直切片与曳光弹

有了目的地，需要规划路线。/to-tickets 把 spec 拆成一个 Kanban 看板。这一步本质上就是 Sprint 规划（Sprint Planning，冲刺规划）的 AI 版：从 backlog 挑任务、拆成可执行的 ticket。只是不搞固定周期的 Sprint，每个 ticket 就是一个独立的交付单元。

Ticket 存哪？有两种方式。本地模式：存成 .scratch/<feature-slug>/issues/<NN>-<slug>.md，按依赖顺序从 01 编号。每个文件带「Blocked by」标注，写清楚它被谁阻塞。在线 tracker（GitHub / Linear）：直接发布成 issue，打上 ready-for-agent 标签。也按依赖顺序发：阻塞的 ticket 先发，后面的 ticket 引用真实 issue ID。

Matt 反复强调一个原则：垂直切片，拒绝水平切片。水平切片是「这周做数据库层，下周做 API 层，下下周做前端层」：AI 直到最后阶段才得到反馈。方向错了，前面的工作全部作废。垂直切片要求每个 ticket 从 UI 贯穿到数据层，第一个 ticket 就验证整个弹道。

Matt 引用了《程序员修炼之道：通向务实的最高境界（第2版）》里的 Tracer Bullet（曳光弹）类比。黑暗中开枪看不见弹道，曳光弹发光，显示子弹飞向哪里。第一个垂直切片就是那发曳光弹：它告诉你整个技术栈是否通路。

先把不确定的摊出来。拆分 ticket 时，优先安排「不知道能不能行」的任务。比如集成一个新服务：这个工作先做。它最早反馈「这条路走不走得通」。

阻塞关系等于并行化基础。每个 ticket 之间建立阻塞关系：哪些必须等前面的完成，哪些可以并行。阻塞关系形成的，是一个 DAG（有向无环图），不是线性的顺序计划。线性的顺序计划只能一个 agent 跑。DAG 可以多个 agent 并行推进。

上下文纯净度（Context Hygiene）

Matt 新增了一个关键约束：grill-with-docs → to-spec → to-tickets 三个阶段，必须在同一个不中断的上下文窗口中完成。 不 compact、不 clear：让Grilling、spec 和 tickets 都基于同一段思考。之后再按 ticket 拆分，每个 /implement 从干净的上下文开始。

六、两种工作模式：人对齐，AI 实现

Matt 用「日班」和「夜班」这个比喻，区分工作流里两种截然不同的模式。它们不能互相替代。

• 人对齐模式（日班）。
   人在电脑前，和 AI 一起做决策。grill-with-docs → to-spec → to-tickets → QA/Review。这是人施加「品味」（taste）的环节：代码结构优不优雅、六个月后会不会变成屎山、这个设计是不是过度工程：这些判断靠人的经验和审美，AI 目前做不到。Matt 的原话：「自动化 QA 产不出有品味的软件」。
• AI 自主模式（夜班）。
   人离开键盘。一旦 tickets 拆分完毕、阻塞关系清晰，AI 就按 /implement 自主运行：取一个 ticket → TDD 循环 → 跑测试 → code-review → 提交 → 下一个。每个 ticket 在全新的「聪明区窗口」中完成，完成后清空上下文。

这种轮班节奏的底层思想，来自 Beck《Extreme Programming Explained》（《解析极限编程》）：短迭代、持续反馈、可持续的开发节奏。Matt 把 Beck 的原则，翻译成了更直觉的操作模型。日班决定「做什么、为什么做」，夜班执行「怎么做」。同一个人，白天和 AI 对话做决策，晚上让 AI 自己写代码。第二天早上回来，看 commit。

夜班的加速器：Sandcastle

夜班的最小单位，就是手动跑 /implement：人离开，AI 取一个 ticket、TDD、review、提交，逐个串行。ticket 数量多了，手动逐个跑效率不够。Matt 自建了 TypeScript 开源库 Sandcastle 来做并行编排。它的架构是四个角色分工协作：

 planner → implementer → reviewer → merger （选 ticket）  （Docker sandbox）  （审查）   （合并）

• Planner：
   扫描 Kanban 看板，找出所有「阻塞已解除」的 ticket。
• Implementer：
   为每个就绪 ticket 启动一个独立的 Docker sandbox，在沙箱里运行 /implement（内嵌 TDD + code-review）。各沙箱互不污染。
• Reviewer：
   审查每个沙箱产出的 commit，两轴审查（Standards + Spec）。
• Merger：
   审查通过后自动合并到主分支，更新 Kanban 状态，解除下游 ticket 的阻塞。

Sandcastle 的核心价值，是让 /implement 从「串行」变成「并行」。Kanban 上的阻塞关系已经是 DAG，多个不受阻塞的 ticket，可以同时派多个 agent 各自在沙箱里跑。Matt 已将 Sandcastle 开源，仓库地址：github.com/mattpocock/sandcastle。

实现和 review，必须在两个不同的上下文窗口里做。

/implement 每次开一个新窗口写代码：窗口干净，LLM 注意力最好。写完、提交之前，自动调 /code-review 来审查。但 /code-review 不能在这个窗口里跑。因为 LLM 刚写完代码，上下文里全是它自己的思路：它会护短，不愿意指出自己写的问题。

所以 /implement 把审查交给另一个独立 agent。它没见过写代码的过程，只看到最终 diff，审起来客观得多。

七、TDD + code-review：实现的内核

/implement 的内部引擎是两个 skill：/tdd 和 /code-review。

TDD：接口决定一切

Matt 认为，TDD 是提高 Agent 输出质量最稳定的方式：这一理念直接来自 Kent Beck《Test-Driven Development》（《测试驱动开发》）。但他加了一个前置步骤：先确认接口变更。 原因在于他对代码库形态的核心判断。

两种代码库形态：

这个概念来自 John Osterhout 的《A Philosophy of Software Design》（《软件设计的哲学（第2版）》）。Matt 把它直接搬到了 AI 编码场景：

模块是灰盒：人设计接口（决定模块的 shape），AI 实现内部。你不用一行一行看实现，只看接口对不对。

TDD 四步循环：

 1. 确认接口变更 → 2. 写失败测试 → 3. 写最少代码通过 → 4. 重构

接口设计被提到了最高优先级：后续 /code-review 也围绕这个约定好的接口来审查。Matt 展示的真实运行中，整个项目有 284 个测试。

code-review：两轴审查

/implement 在提交前自动调用 /code-review。它用两个独立的 SubAgent，分别从两个维度审查 diff。两个 SubAgent 互不知晓对方的推理，防止一个维度的结论污染另一个：

两个维度的结论永不合并、永不重排。一份代码可以完美遵循规范，却做错了功能（过 Standards、挂 Spec）。也可以功能正确，却破坏规范（反之）。分开汇报，不让一个维度掩盖另一个。

编码标准在实现阶段是 Pull 模式（agent 可选读），在 review 阶段是 Push 模式（强制注入、逐条检查）。同一个标准，两种策略。

这套「小步实现 → 立即审查 → 反馈修正」的循环，内核来自 Martin Fowler《Refactoring》（《重构：改善既有代码的设计（第2版）》）：每次改动足够小，每一步都有测试兜底。

八、/improve-codebase-architecture + /codebase-design：持续改善土壤

这是工作流的基础设施层，解决一个底层问题：让代码库从「浅模块散落」，持续变成「深模块 + 薄接口」。

/improve-codebase-architecture：发现深化机会

它做什么？ 扫描整个代码库，找出「浅模块可以深化为深模块」的地方。它只做调查，不改代码：产出一份 HTML 报告放在系统临时目录，然后对你选中的候选启动一次 grilling 访谈。真正的重构在之后另开 session，走标准流程执行。

输入： 整个代码库。你也可以指定方向：比如指向一份 spec，问「这个变更怎么做才容易？」效果最好。

输出： 一份 HTML 报告（含候选卡片、强度评级、before/after 示意图）+ grilling 后产出一个决策。这个决策再进入 /to-spec → /to-tickets → /implement 执行。

两个筛选条件，保证报告不变成「泛泛的代码整洁建议」：

• 删除测试：
   去掉这个模块后，复杂度是被更小的接口收敛了，还是散落到了所有调用方？只有「收敛」的才进报告。
• 热点偏向：
   除非你指定了范围，否则优先扫描最近活跃变更的路径。没人碰的代码里做深化，是你永远不会兑现的重构。

三步流程：

1. 探索混乱点。
    让 AI 用自己的方式逛一遍代码库。理解一个概念要跨五个小文件跳转？纯函数被抽出来只为测试，但真正的 bug 藏在调用方式里？紧耦合模块之间的「接缝」有集成风险？
2. 列出深化候选。
    每张候选卡片包含：涉及的文件、摩擦点、用大白话写的解决方案、收益（以 locality 和 leverage 表述）、before/after 示意图、以及一个强度评级：

1. 多方案并行设计。
    你选一个候选，派 3-5 个 SubAgent 并行，每个独立设计一种接口方案，产出必须截然不同。对比推荐，必要时取各家之长，合成混合方案。最终产出是一个 refactor RFC issue：这就是一份新的 spec，再走 /to-spec → /to-tickets → /implement 执行。

使用节奏： 每几天跑一次，或一次大规模功能开发之后。不是为了重构而重构，是在 AI 开始产出混乱代码之前，主动改善「土壤」。如果接下来的功能很大，指向它的 spec 问「怎么让这个变更变容易」：这是最有效的用法。

/codebase-design：深模块的词汇表

/improve-codebase-architecture 负责发现「哪里需要深化」，而 /codebase-design 提供「怎么深化」的语言：模块、接口、深度、接缝、适配器、杠杆、局部性。它是 /tdd 和 /improve-codebase-architecture 共享的底层词汇。

七个术语精确到禁用了模糊替代词（「component」「service」「API」「boundary」一律不准用）。其中 depth（深度） 来自 John Osterhout《A Philosophy of Software Design》（《软件设计的哲学（第2版）》）：不过 skill 刻意偏离了 Osterhout 的原始定义（「实现行数除以接口行数」），改用「每个接口单元能撬动多少行为」来防止注水。seam（接缝） 来自 Michael Feathers《Working Effectively with Legacy Code》（《修改代码的艺术》）：「一个你可以改变行为却不用编辑那行代码的地方」。

/domain-modeling：打磨领域语言

与你同级的还有一个 /domain-modeling skill。当「账户」一个词做了三件事、某个术语在不同模块含义不同时，它出面澄清、记录 ADR、更新 CONTEXT.md。/grill-with-docs 的访谈过程，就驱动了这个打磨过程。

这个概念直接来自 Eric Evans《Domain-Driven Design》（《领域驱动设计：软件核心复杂性应对之道》，2003）中的「统一语言」（Ubiquitous Language）：开发者和领域专家共用一套术语体系。跟 LLM 高效协作，同样是这个道理。Matt 说他「读到每一页都像在听音乐」。

使用节奏：每周一次，或一次大规模功能开发之后。不是为了重构而重构，是在 AI 开始产出混乱代码之前，主动改善「土壤」。

九、扩展生态：你可能错过的重要 skill

除了主流程，Matt 的仓库里还有几个独立 skill，每个解决一个具体问题。

/prototype：快速验证一个想法

聊到一半，有个设计问题拿不准：「这个状态模型对不对？」「UI 长什么样好？」别在主流程里纠结，分叉出去跑一个 /prototype。

它是一次性实验。代码不用写得好，能跑就行，用完扔掉也不心疼。但原型不会消失：它留在 prototype/<name> 分支上。以后有人问「当初为什么这么设计」，翻出来一目了然。

/research：让 AI 帮你查资料

碰到一个你不了解的问题，/research 派一个后台 Agent 替你查：读文档、翻论文、扫代码。你不用等，继续做你的事。它查完给你一份带引用的 Markdown 文件。你可以拿着这份文件，回到 /grill-with-docs 里接着聊。

/diagnosing-bugs：先复现，再动手

遇到看不透的 bug，人的本能是猜：「可能是这里的问题，改一下试试」。/diagnosing-bugs 禁止这么干。

它的规则是：先给我一个能稳定复现这个 bug 的命令，否则别碰代码。命令跑通了，bug 能稳定复现了，再修。修完补上回归测试。如果事后发现「根本原因是代码结构让这个 bug 难以锁定」，它会甩给 /improve-codebase-architecture 去改善架构。

道理很简单，来自《程序员修炼之道》：反馈速度决定你的上限。没复现就动手，等于关着灯开车。

/triage：把杂乱的需求「翻译」成 AI 能懂的任务

你收到的 bug 报告和需求通常很乱：截图、一句话、语音转文字。/triage 是预处理器：把原始 issue 扔进去，吐出来的是结构化、Agent 能直接执行的 tickets。然后走 /implement 开干。

注意：你自己用 /to-tickets 拆出来的 tickets 已经是干净的，不要再 triage 一遍。

/wayfinder：项目太大，不知道从哪开始

有时候你面对的不是一个功能，是一整片空白。比如「我们要做一个类似 Notion 的协作编辑器」：数据库用什么？实时同步怎么搞？权限模型怎么设计？这些大问题没敲定，写什么代码都是蒙。

/wayfinder 做的事很简单：不写代码，只帮你把大问题拆成小决策。 比如先决定「用 CRDT 还是 OT」，选完再看「冲突处理怎么定」。一个决策接一个决策往下推。每个决策就是一个 GitHub issue，标清楚它依赖前面哪些决策。

等所有大问题都有答案了，/wayfinder 收工，把整串决策交给 /to-spec 走主流程。

一句话：/grill-with-docs 帮你聊清楚一个功能，/wayfinder 帮你聊清楚一整片没人踩过的荒地。两个都在走 Brooks 的「设计树」：每个决策分出更多子决策，每个分支走到底。

/wizard：AI 做不到的事，你来做

基础设施配置、CI 密钥、不熟悉的第三方后台：这些只能人类操作。/wizard 生成一个交互式脚本，告诉你「打开这个 URL，把拿到的值填进去」，然后写入 .env 和 GitHub secrets。AI 碰到自己过不去的墙，会自动伸手要这个。

/handoff：把当前工作打包，搬到别处继续

/handoff 把当前对话压缩成一份可携带的交接文件，存到系统临时目录。它解决的问题不是「怎么总结得更好」，而是「怎么把工作搬走」。

四种场景才用它：

1. 换工具：比如从 Claude 换到 Codex。
2. 换目录或仓库：最常见的是原型分支。
3. 交给同事：他们需要一份能读懂上下文的东西。
4. 分叉子任务：你继续干主线，另一个 Agent 拿交接文件并行做分叉任务。

大多数情况你不需要它。 同一个工具、同一个目录、同一条任务链：用 /compact 就行。二者的区别不是谁总结得好，而是 /handoff 产出的是一份可以带走的文件。

交接文件写了什么：当前在做什么、为什么、下一步干什么，外加一份推荐 skill 清单。已经写死的东西（spec、issue、commit）只引用路径，不复制内容。密钥自动去除。

重要提醒：交接文件是「二手信息」：每压缩一次就丢一点细节。下一个 Agent 会把这份文件当合同执行，不会二次验证。所以你在交出之前，要自己看一遍，把「我推测的」和「确认过的」分清楚。

phase boundaries：阶段之间的五个选择

每完成一个阶段（聊完了、写完了 spec、跑完了实现、审完了代码），你站在一个「边界」上。Matt 给了五个选择：

1. 继续
    — 不动。零成本，不丢任何信息。
2. /clear
    — 清空。后面的工作跟前面的无关。
3. /handoff
    — 写一份交接文件。只在换工具、换目录、交同事、分叉任务时用。
4. SubAgent
    — 拆一个小任务派出去，拿结果回来。
5. /compact
    — 压缩上下文，开新会话。默认选项：到了边界就用这个。

十、小结：软件工程的基本原则没有变

Matt 在结尾给了一个建议：

去买那些老书。

这些写于 AI 诞生前的经典，恰好命中了 AI 编码的核心难题。

如果把整个工作流整理成一本流程手册，不会觉得它是「写给 AI 看的」：

区别只有一个：人类的 SOP 靠自驱力执行，AI 的 SOP 靠 Skill 强制执行。

你必须记住的 7 条指南

1. 别急着写代码，先把事聊透。
    很多人一上来就让 AI 开干，结果写到一半发现方向歪了。正确的做法：用 /grill-with-docs 让 AI 反过来问你：「这个功能谁用？频率多高？数据从哪来？失败了呢？」：把你脑子里的模糊想法，逼成清晰的设计。每个分支都走到底，再动手。
2. 一个 ticket 从头打到尾，别分「N层」做。
    「这周写数据库、下周写 API、下下周写前端」：这是最坑的做法。AI 直到最后一步才见到完整反馈，早走歪了。正确的做法：每个 ticket 都是一个「曳光弹」，从 UI 一路贯穿到数据库。第一个 ticket 不对，后面全不对。所以优先做你最没把握的那个。
3. Spec 是「钉死目标的桩」，不是拿来欣赏的。
    你不应该花时间逐字打磨 spec 文案。Matt 自己都不读 spec：因为真正的共识，在之前 /grill-with-docs 的对话里已经达成了。Spec 只是把结论记下来。省下打磨文字的时间，去跑跑测试、点点页面。
4. 写代码的时候不用盯，review 的时候必须换「干净的脑袋」。
    AI 对自己刚写完的代码，会本能地护短：「我写的，没问题」。所以 /implement 跑的时候你去喝水。等它产出 commit 了，换一个没看过它写代码的窗口（或者直接让 /code-review agent）来审。同样的代码，换个视角，问题就出来了。
5. 你管「外面长什么样」，AI 管「里面怎么搞」。
    每个模块留一层薄薄的接口：几个函数名、入参、出参：这就是你和 AI 之间的契约。接口里面怎么实现，让 AI 自己决定。你 review 的时候只看接口对不对，不用一行一行钻进去看：这叫「灰盒」，省心又不失控。
6. 那些二十年前的老书，放在今天就是「AI 编程说明书」。
    设计树、曳光弹、深模块、看板：Brooks 和 Osterhout 在 AI 诞生前写的东西，恰好对症了 AI 编码最头疼的问题：上下文怎么管？反馈怎么建？模块怎么拆？技术会过时，思路不会。
7. 一个窗口干一个阶段的事，别硬撑。
    把「聊清楚 → 写 spec → 拆 ticket」放在一个对话里一口气跑完：这三个阶段共享同一段上下文，需要「一起想」的感觉。但到了实现阶段，每个 ticket 单独开一个干净窗口：上一个 ticket 写歪了，不影响下一个。窗口快满了别硬撑，果断清掉重来。这比撑着高 token 位置，让 AI 在「愚蠢区」里干活，强得多。

关键概念术语表

*本文基于 Matt Pocock 的 YouTube 视频 Full Walkthrough: Workflow for AI Coding