Matt Pocock v1.3 工作流实战：implement-spec、PR 与 retro 三大技能解析

AI 编程工作流正在从「手动盯着 AI 干活」演进为「让 AI 自己管理 AI」。Matt Pocock 近期发布了其 skills 仓库的 v1.3 版本，带来了三个被他视为核心的新技能：implement-spec、PR 和 retro。其中 retro 在社交媒体上引发大量讨论，被不少开发者称为「游戏规则改变者」。本文梳理这三项技能的设计思路与实战价值，帮你理解它们各自解决的痛点。

implement-spec：从规格到自动化落地

Matt 处理大块工作的核心方法建立在两个实体之上：spec（规格）和 tickets（工单）。spec 定义「要去哪里」，而 tickets 把这个目标拆解成一系列可以交给单个编码 agent 执行的会话。

他特别强调不要试图在一个 agent 里实现整个 spec——那样很容易进入 agent 的「变笨区（dumb zone）」，甚至触发 auto-compact（上下文自动压缩）。把工作拆成独立工单，再逐个交给干净上下文的 agent，是更可靠的做法。

问题在于如何编排这些工单。Matt 梳理了三种方式：

• 手动循环：用户亲自充当「for 循环」，实现一个工单、清空上下文、再实现下一个。繁琐且不实用。
• 确定性循环（deterministic loop）：写脚本读取每个工单并自动调用实现流程。这是他最推荐的方式——可靠、可复现、成本低，因为既不消耗 agent 也不消耗人力。缺点是搭建复杂，不适合新手。
• 子 agent 编排：由一个 agent 充当「保姆」，调度多个 sub-agent 去实现各个工单。

implement-spec 走的正是第三条路。它之所以现在才可行，是因为 sub-agent 已经能够自己再派生 sub-agent，不再像过去那样被「阉割」，而是和编排型 agent 一样强大。

这个技能的流程有九步，关键在于它会尽可能并行化。Matt 指出：工单不是一串步骤，而是一张带有阻塞关系的「任务图（task graph）」，因此总存在一批「就绪可抓取」的工单前沿。具体流程包括：读取 spec 和工单、用 sub-agent 做探索、创建集成分支、用 implementer sub-agent 结合 TDD 和 work tree 实现每个工单、合并到集成分支、全部完成后对集成分支做代码审查、清理工作并准备好可供审查的 PR。最终你从一个庞大的 spec 得到一个完整的 PR。

Matt 坦言 implement-spec 不如确定性脚本可靠，但它是进入 AFK（away from keyboard，离开键盘）工作流的绝佳起点——你可以起身离开，让它自动实现整个 spec。对于尚未搭好「软件工厂」脚本的系统，这个技能格外有用。

「变笨区（dumb zone）」和 auto-compact 是理解为何要拆分工单的关键背景。大型语言模型的上下文窗口有容量上限，当一次会话积累的内容过多时，模型的推理质量会明显下降——这就是 Matt 所说的「变笨区」。auto-compact 则是 Claude 等工具在上下文接近上限时自动压缩历史对话的机制，压缩后模型可能丢失关键的中间状态和决策依据，导致后续输出不可预测。Work tree（Git 工作树）是 Git 的一项功能，允许同一仓库同时检出多个分支到不同目录，这使多个 sub-agent 能够并行在各自独立的工作目录中开发不同工单，互不干扰。TDD（测试驱动开发）则要求 agent 先写测试、再写实现，是确保每个工单产出可验证的核心手段。

PR 技能：把人工审查变得尽可能轻松

PR 仍然是代码进入主分支的主要瓶颈。Matt 的 PR 技能目标很明确：让人工审查尽可能轻松。这一灵感来自 Dex Horthy 的 ShowMe 技能——用简洁的图示和伪代码帮助理解当前主题，在 PR 语境下让审查变得容易得多。

该技能本质上提供了一个 PR 正文模板，包含几个关键部分：

摘要：基于 ShowMe 风格的模板。

证据（evidence）：提供前后对比。Matt 强调这是「学会信任 agent 输出」的关键一环。要求 agent 提供硬证据，往往会促使它多跑一次测试、多截一张图，从而给出运行时信息来证明改动确实达到了预期效果。他直言，不要求硬证据时，agent 很容易只凭「我读了代码，应该没问题」就下结论——而验证正是他近期越来越执着的事情。

合并危险性（merge danger）：这个 PR 合并后有多危险？Matt 喜欢用「单向门 vs 双向门」的比喻——双向门可以轻松回退，单向门则会在真实世界产生后果（删除数据、回滚代价高昂）。

影响半径（blast radius）：改动的潜在波及范围。如果一个 PR 是双向门且影响半径很小，那就几乎不需要认真审查。

Matt 展示了仓库中一个实例：合并两个几乎相同的算法，PR 清晰呈现了删除/新增的文件、调用栈结构，以及最关键的前后证据——合并危险性标为双向门（纯重构加一处刻意的行为变更），影响半径小。他表示这个技能已成为流程中不可或缺的部分，而且在 Opus 5.5 上几乎每次都会被自动调用，用户无需操心。

一个重要变更：context.md 改为 glossary.md

在介绍 retro 之前，Matt 提到一个影响面较大的改动：领域建模（domain modeling）技能现在写入 glossary.md 而非 context.md。

这个技能的灵感源自 Eric Evans 的《领域驱动设计（DDD）》，原先采用 DDD 中「限界上下文（bounded context）」概念命名为 context.md。但 Matt 发现 context.md 这个名字太模糊，既不能在恰当时机触发 agent 引入它，对用户也造成困惑。加之他把文件内容精简到只剩一个术语表，于是干脆改名为 glossary.md。这纯粹是文件名变更，没有其他行为改动，但由于大量技能依赖识别 glossary.md 来正确运作，用户务必更新。

retro：让另一个 agent 揭露会话中的难堪真相

retro 是本次最受关注的技能，是「retrospective（回顾）」的缩写。Matt 的出发点是：他过去对用户要求太多——要管理 agents.md、管理技能、保证仓库 token 高效、维护良好的 lint 规则和导航结构。他意识到自己为优化仓库做了大量工作，于是把这些打包成了一个技能。

你在某个编码 agent 会话上运行 retro（当前会话或之前的会话），它会给出下次改进的建议。它的强大之处在于能真正读取真实会话，看到 agent 实际遇到的、甚至对你隐藏的低效问题。

Matt 引用了用户 Andre 的反馈：「Retro 是游戏规则改变者。我的 agent 撞上了各种此前未被发现的问题，但由于它的执着，功能最终还是以某种方式被做出来了。」换句话说，agent 往往不会像它应该的那样抱怨，也不会主动修复自己的错误——你需要另一个 agent 回看这些会话，找出哪里出了错以及如何改进。

在 Matt 的实际演示中，retro 发现了多个问题：agent 在用户选定修复方案前就运行了不可逆的公开操作（直接发布了 release 却没询问，这正是为什么仓库里只有 1.3.1 而没有 1.3.0 release）；仓库有 PNPM check 脚本却没有任何东西去运行它，建议加 CI 流水线；长会话压缩之间存在上下文丢失，建议把重复指令抽成专门的 skill；甚至连自定义 CLI 浪费 token、工具不在 PATH 等细节都被揪了出来。Matt 形容 retro「毫不留情」，几乎总能找到可改进之处。

关于使用方式，Matt 给出两点重要建议：

保持人在回路（human in the loop）。retro 列出的问题需要人工判断——比如它认为最严重的 release 问题其实无关紧要。几乎每个看到演示的人都想自动化它，但 Matt 明确反对：自动化会让 agent 陷入不断发现误报、不断尝试修复的循环，把仓库和 agent 带向奇怪的方向。

在会话样本上抽查运行。不必每次都跑，而是在有空闲、或某个会话明显出错、agent 行为诡异时运行 retro，它通常能找到修复方案。

retro 内置了若干改进检查维度：代码库是否易于导航、能否增加自动化检查、能否为自动审查器添加编码规范、全局 agents.md 是否健康、工具经济（tool economy）是否合理、steering 文件里是否有空操作指令、agent 是否能获取所需的全部信息。

Matt 表示，通过定期运行 retro，他的 token 效率和产出质量都大幅提升。

retro 能「读取真实会话」依赖于 Claude 等工具将完整的 agent 交互历史（包括工具调用、中间推理步骤和错误重试记录）以结构化形式保存的机制。普通用户在界面上看到的往往只是最终输出，而 agent 在达成目标过程中经历的失败尝试、绕道修复和重复操作则被隐藏。retro 作为独立 agent 读取这些原始记录时，能够识别出诸如「工具调用失败后静默重试了七次」「同一文件被读取了十五遍」等人工难以察觉的低效模式。「工具经济（tool economy）」是 Matt 仓库中的一个衡量维度，指 agent 完成任务所消耗的工具调用次数与实际产出价值之间的比率——调用次数越少、产出越准确，工具经济效率越高，直接影响 token 消耗成本。

小结

v1.3 这三个技能分别对应 AI 编程工作流的三个阶段：implement-spec 负责「把活干完」，让新手也能体验自动化的 AFK 工作流；PR 负责「让人放心合并」，通过证据、危险性和影响半径三要素降低审查成本；retro 负责「持续改进」，用一个 agent 复盘另一个 agent 的真实会话，揭露那些被执着掩盖的低效。核心理念贯穿始终：验证优先、人在回路、持续迭代。