多数人用 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 HorthyHumanLayer 创始人提出的概念。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会根据你的情况告诉你走哪条路径。如果你仔细看会发现这套工作流的每个环节背后都站着一位软件工程前辈grilling 阶段的「设计树」— Brooks《The Design of Design》《设计原本》TDD 循环的红-绿-重构内核— Beck《Test-Driven Development》《测试驱动开发》垂直切片策略「曳光弹」— Hunt Thomas《The Pragmatic Programmer》《程序员修炼之道通向务实的最高境界第2版》code-review 的十二条坏味道— Fowler《Refactoring》《重构改善既有代码的设计第2版》深模块 / 浅模块理念— Osterhout《A Philosophy of Software Design》《软件设计的哲学第2版》统一语言Ubiquitous Language— Evans《Domain-Driven Design》《领域驱动设计软件核心复杂性应对之道》seam在不修改代码的前提下创造可测点— Feathers《Working Effectively with Legacy Code》《修改代码的艺术》日班 / 夜班分工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和 ADRArchitecture 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 一个明确的「别问我」的规则。v1.2 更新2026 年 8 月grilling skill 升级到 v1.2引入了几项新机制-Frontier前沿不再从头到尾线性提问而是动态计算「当前前端」只有前置决策已解决的问题才会进入本轮。不靠猜测跳过还没答案的环节。-分轮Rounds每轮把整个 frontier 一次性抛出。你逐一回答后重新计算前端再进入下一轮。-推荐答案Recommended每个问题附带 AI 的推荐选项。你可以接受也可以推翻减少无效讨论。-SubAgent 事实探索不阻塞需要查代码才能回答的问题派 SubAgent 去查。同时本轮其他问题照常推进只有依赖该探索结果的下游问题等待。-终止条件frontier 为空时设计树的每一个分支都被遍历完毕不留下任何默认假设。四、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接缝测试在哪里切入。取最高层的已有接缝理想情况下一个变更只需要一个 seam问题陈述要解决什么问题解决方案概述怎么解决概要即可用户故事来自敏捷方法论描述用户视角的行为实现决策关键技术选择不过度规定测试决策什么需要测、在哪一层测Out-of-Scope明确不做什么。拒绝过的东西往往是整份 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」标注写清楚它被谁阻塞。在线 trackerGitHub / 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 HygieneMatt 新增了一个关键约束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》《测试驱动开发》。但他加了一个前置步骤先确认接口变更。原因在于他对代码库形态的核心判断。两种代码库形态浅模块散落深模块 薄接口样子大量小文件关系不清少量大模块暴露少数函数AI 体验理解一个概念跨五个文件跳转导航困难清晰知道从哪里下手测试边界模糊不知道该测哪里只需覆盖接口边界这个概念来自 John Osterhout 的《A Philosophy of Software Design》《软件设计的哲学第2版》。Matt 把它直接搬到了 AI 编码场景模块是灰盒人设计接口决定模块的 shapeAI 实现内部。你不用一行一行看实现只看接口对不对。TDD 四步循环1. 确认接口变更 → 2. 写失败测试 → 3. 写最少代码通过 → 4. 重构接口设计被提到了最高优先级后续/code-review也围绕这个约定好的接口来审查。Matt 展示的真实运行中整个项目有 284 个测试。code-review两轴审查/implement在提交前自动调用/code-review。它用两个独立的 SubAgent分别从两个维度审查 diff。两个 SubAgent 互不知晓对方的推理防止一个维度的结论污染另一个维度问题数据来源Standards编码标准「代码写对了吗」项目的CODING_STANDARDS.md/CONTRIBUTING.md没有则回退到内置底线Fowler《重构改善既有代码的设计第2版》第 3 章的十二种代码坏味道神秘命名、重复代码、依恋情结、数据泥团、基本类型偏执、重复 Switch、霰弹式修改、发散式变化、夸夸其谈通用性、消息链、中间人、被拒绝的遗赠Spec规格一致性「做的是对的东西吗」前置 skill/to-spec产出的 spec从 commit message 里的 issue 引用、docs//specs//.scratch/下的 spec 文件中读取两个维度的结论永不合并、永不重排。一份代码可以完美遵循规范却做错了功能过 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执行。两个筛选条件保证报告不变成「泛泛的代码整洁建议」删除测试去掉这个模块后复杂度是被更小的接口收敛了还是散落到了所有调用方只有「收敛」的才进报告。热点偏向除非你指定了范围否则优先扫描最近活跃变更的路径。没人碰的代码里做深化是你永远不会兑现的重构。三步流程探索混乱点。让 AI 用自己的方式逛一遍代码库。理解一个概念要跨五个小文件跳转纯函数被抽出来只为测试但真正的 bug 藏在调用方式里紧耦合模块之间的「接缝」有集成风险列出深化候选。每张候选卡片包含涉及的文件、摩擦点、用大白话写的解决方案、收益以locality和leverage表述、before/after 示意图、以及一个强度评级评级含义Strong删除测试明确通过摩擦真实存在。认真对待。Worth exploring可行的深化但收益取决于代码的下一步走向。Speculative为完整性列出大多可以忽略。如果整份报告全是这个说明代码库其实没什么大问题。多方案并行设计。你选一个候选派 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-modelingskill。当「账户」一个词做了三件事、某个术语在不同模块含义不同时它出面澄清、记录 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 的「设计树」每个决策分出更多子决策每个分支走到底。/wizardAI 做不到的事你来做基础设施配置、CI 密钥、不熟悉的第三方后台这些只能人类操作。/wizard生成一个交互式脚本告诉你「打开这个 URL把拿到的值填进去」然后写入.env和 GitHub secrets。AI 碰到自己过不去的墙会自动伸手要这个。/handoff把当前工作打包搬到别处继续/handoff把当前对话压缩成一份可携带的交接文件存到系统临时目录。它解决的问题不是「怎么总结得更好」而是「怎么把工作搬走」。四种场景才用它换工具比如从 Claude 换到 Codex。换目录或仓库最常见的是原型分支。交给同事他们需要一份能读懂上下文的东西。分叉子任务你继续干主线另一个 Agent 拿交接文件并行做分叉任务。大多数情况你不需要它。同一个工具、同一个目录、同一条任务链用/compact就行。二者的区别不是谁总结得好而是/handoff产出的是一份可以带走的文件。交接文件写了什么当前在做什么、为什么、下一步干什么外加一份推荐 skill 清单。已经写死的东西spec、issue、commit只引用路径不复制内容。密钥自动去除。重要提醒交接文件是「二手信息」每压缩一次就丢一点细节。下一个 Agent 会把这份文件当合同执行不会二次验证。所以你在交出之前要自己看一遍把「我推测的」和「确认过的」分清楚。phase boundaries阶段之间的五个选择每完成一个阶段聊完了、写完了 spec、跑完了实现、审完了代码你站在一个「边界」上。Matt 给了五个选择继续— 不动。零成本不丢任何信息。/clear— 清空。后面的工作跟前面的无关。/handoff— 写一份交接文件。只在换工具、换目录、交同事、分叉任务时用。SubAgent— 拆一个小任务派出去拿结果回来。/compact— 压缩上下文开新会话。默认选项到了边界就用这个。十、小结软件工程的基本原则没有变Matt 在结尾给了一个建议去买那些老书。书名作者解决的核心问题《The Design of Design》《设计原本》Frederick P. Brooks设计树、设计概念的共享对应/grill-with-docs/wayfinder《A Philosophy of Software Design》《软件设计的哲学第2版》John Osterhout深模块 vs 浅模块接口即契约对应/codebase-design/improve-codebase-architecture《The Pragmatic Programmer》《程序员修炼之道通向务实的最高境界第2版》Hunt ThomasTracer Bullet、反馈速度限速对应/to-tickets/diagnosing-bugs《Domain-Driven Design》《领域驱动设计软件核心复杂性应对之道》Eric Evans统一语言Ubiquitous Language对应/domain-modeling《Refactoring》《重构改善既有代码的设计第2版》Martin Fowler小步改动、十二种代码坏味道对应/code-review《Working Effectively with Legacy Code》《修改代码的艺术》Michael Feathersseam接缝不需要编辑那行代码就能改变它的行为对应/codebase-design《Test-Driven Development》《测试驱动开发》Kent Beck红-绿-重构循环先写测试再写代码对应/tdd/implement《Extreme Programming Explained》《解析极限编程》Kent Beck持续反馈、小步发布、拥抱变化贯穿日班/夜班工作模式这些写于 AI 诞生前的经典恰好命中了 AI 编码的核心难题。如果把整个工作流整理成一本流程手册不会觉得它是「写给 AI 看的」AI 工作流等价的人类工程实践/grill-with-docs需求澄清会议/to-spec设计文档/to-ticketsSprint 规划Sprint Planning冲刺规划/implementCI/CD 管道QA Review代码审查/improve-codebase-architecture架构评审区别只有一个人类的 SOP 靠自驱力执行AI 的 SOP 靠 Skill 强制执行。你必须记住的 7 条指南别急着写代码先把事聊透。很多人一上来就让 AI 开干结果写到一半发现方向歪了。正确的做法用/grill-with-docs让 AI 反过来问你「这个功能谁用频率多高数据从哪来失败了呢」把你脑子里的模糊想法逼成清晰的设计。每个分支都走到底再动手。一个 ticket 从头打到尾别分「N层」做。「这周写数据库、下周写 API、下下周写前端」这是最坑的做法。AI 直到最后一步才见到完整反馈早走歪了。正确的做法每个 ticket 都是一个「曳光弹」从 UI 一路贯穿到数据库。第一个 ticket 不对后面全不对。所以优先做你最没把握的那个。Spec 是「钉死目标的桩」不是拿来欣赏的。你不应该花时间逐字打磨 spec 文案。Matt 自己都不读 spec因为真正的共识在之前/grill-with-docs的对话里已经达成了。Spec 只是把结论记下来。省下打磨文字的时间去跑跑测试、点点页面。写代码的时候不用盯review 的时候必须换「干净的脑袋」。AI 对自己刚写完的代码会本能地护短「我写的没问题」。所以/implement跑的时候你去喝水。等它产出 commit 了换一个没看过它写代码的窗口或者直接让/code-reviewagent来审。同样的代码换个视角问题就出来了。你管「外面长什么样」AI 管「里面怎么搞」。每个模块留一层薄薄的接口几个函数名、入参、出参这就是你和 AI 之间的契约。接口里面怎么实现让 AI 自己决定。你 review 的时候只看接口对不对不用一行一行钻进去看这叫「灰盒」省心又不失控。那些二十年前的老书放在今天就是「AI 编程说明书」。设计树、曳光弹、深模块、看板Brooks 和 Osterhout 在 AI 诞生前写的东西恰好对症了 AI 编码最头疼的问题上下文怎么管反馈怎么建模块怎么拆技术会过时思路不会。一个窗口干一个阶段的事别硬撑。把「聊清楚 → 写 spec → 拆 ticket」放在一个对话里一口气跑完这三个阶段共享同一段上下文需要「一起想」的感觉。但到了实现阶段每个 ticket 单独开一个干净窗口上一个 ticket 写歪了不影响下一个。窗口快满了别硬撑果断清掉重来。这比撑着高 token 位置让 AI 在「愚蠢区」里干活强得多。关键概念术语表英文术语中文翻译说明Smart Zone / Warm Zone / Dumb Zone聪明区 / 温暖区 / 愚蠢区Dex HorthyHumanLayer提出的三档上下文质量分区~100K 为聪明区上沿Design Tree设计树Brooks设计决策的树状分支结构Shared Understanding共同理解区别于「文档」人与 AI 对齐的认知状态Spec规格说明「目的地」文档不过度规定实现细节旧称 PRDTracer Bullet曳光弹贯穿全栈的薄垂直切片Vertical Slice / Horizontal Slice垂直切片 / 水平切片前者贯穿所有层后者只做一层Kanban Board看板带阻塞关系的任务板形成 DAGAFK (Away From Keyboard)离键任务不需要人在场的自主任务Ralph LoopRalph 循环自主代理循环模式名「选任务→做改动→反馈→重复」Deep Module / Shallow Module深模块 / 浅模块Osterhout接口小功能多 vs 接口多功能少Gray Box灰盒知道接口和行为不关心里面实现的模块Push vs Pull推送 vs 拉取编码标准的两种注入方式Phase Boundary阶段边界会话中工作区块之间的决策点Context Hygiene上下文纯净度保持关键阶段在同一窗口中完成实现阶段用干净窗口ADR (Architecture Decision Record)架构决策记录grill-with-docs 产出的不可逆决策文档CONTEXT.md上下文文件grill-with-docs 在项目根维护的共享词汇和决策记录Sandcastle专有名词Matt 自建的 TypeScript 并行 agent 运行库*本文基于 Matt Pocock 的 YouTube 视频 Full Walkthrough: Workflow for AI Coding