我是安徽最忧郁程序员无隅
前言
一个需求拆成多个任务以后，谁来安排执行顺序？Agent 提交了一批修改以后，怎样确认功能有效？一次开发最终完成了，过程中反复寻找文件、遗漏检查的问题又该怎样处理？本文结合 Matt Pocock 的 v1.3 工作流视频，使用订单导出示例解释
/implement-spec、/pr、/retro的职责、输入和交付结果，让任务执行、人工审查和开发环境改进形成连续的过程。
一、需求如何拆成可执行任务
假设我们要给订单管理系统增加导出功能：运营人员选择日期和订单状态，点击按钮后获得 CSV 文件；普通账号只能导出自己有权查看的订单。CSV 是一种用逗号分隔字段的文本格式，可以交给表格软件读取。
这个需求同时涉及权限、查询条件、文件生成和页面交互。把这些事情放进一个长期会话，Agent 就需要持续记住所有规则、已经修改的文件和尚未完成的工作。随着工具输出和调试记录增多，重要信息可能被长对话挤出当前可用的上下文。
视频在 00:28---01:06 介绍了两份资料的关系：spec 描述完整需求和验收条件，ticket 描述一次能够执行并验证的工作。 spec 是 specification 的简称，可以理解为需求规格；ticket 是任务单，记录任务范围、前置依赖和完成条件。两份资料共同帮助每个执行者知道自己负责什么，以及结果如何接受检查。
对于订单导出功能，spec 至少要写清楚日期边界、状态含义、导出字段、权限限制，以及没有匹配订单时的结果。例如日期统一按业务时区处理，起始日期包含在查询范围内，结束日期也包含当天全部订单。这些规则直接决定测试应该如何构造。
再把需求划分成任务，每项任务都包含可验证的行为。下面是本文的教学示例，任务编号与代码名称均为说明所设定。
| 任务 | 实现范围 | 完成条件 | 前置依赖 |
|---|---|---|---|
| A | 公共导出接口、账号权限和 CSV 生成 | 有权限的订单能够生成文件；越权请求被拒绝 | 无 |
| B | 日期过滤 | 起始和结束边界正确；范围外订单不进入结果 | A |
| C | 状态过滤 | 只导出指定状态的订单；非法状态得到明确错误 | A |
| D | 组合条件和页面接入 | 页面提交日期与状态，下载结果同时满足两项条件 | B、C |
这里的依赖表示：执行任务 B 时，需要已经能够调用任务 A 的公共能力；执行任务 D 时，需要日期和状态两个行为都已可用。验收条件必须跟随任务进入执行过程。 仅写"增加导出功能"，执行者很难判断日期边界和权限限制是否属于本次工作。
还需要区分"子 Agent 声称任务完成"和"任务结果已合并进集成分支"。后续任务实际需要使用前置代码，因此调度时要依据已经合并的结果判断依赖是否满足。任务图表达了这一关系，下一节会看到它如何决定哪些工作可以同时执行。
二、/implement-spec 如何组织实现
视频在 01:20---03:21 讨论了任务调度：由人逐项启动任务、使用固定脚本安排任务，以及由 Agent 负责安排任务。Matt 将 /implement-spec 放在第三种方式中，让一个负责调度的 Agent 读取任务关系、分配工作并收集结果。他在视频中也明确表达了对固定脚本可重复性和运行成本的偏好。
/implement-spec 的输入是已有的 spec 和对应 tickets。采用之前需要读完 Skill 定义，并确认任务管理方式已配置、运行环境能够创建子 Agent 和 Git worktree。worktree 是同一个 Git 仓库的额外工作目录，每个目录可以检出自己的分支，方便不同任务同时修改各自的文件副本。作者的 v1.3.1 定义记录了这些安排；使用文档说明了运行环境的前提。
任务依赖如何决定并行执行
task graph 指任务依赖图，frontier 指当前前置依赖全部满足的任务集合。对应订单导出示例，观察图中 B、C 两个分支，以及它们汇合到 D 的位置。
最开始只有 A 可以执行。A 合并进入集成分支以后，B 和 C 同时满足启动条件，可以分别交给子 Agent。B 先完成时，D 还要等待 C；两项结果都合并以后，D 才能够使用完整的查询能力。
这意味着调度者需要不断更新任务状态。决定执行顺序的是依赖是否满足，任务编号只帮助人定位任务。对于确实存在依赖的 B 和 D，即使机器还有空闲，也要等待前置结果。
并行还要考虑共享文件。假设 B、C 都需要修改同一个查询参数类型，两个执行者可能为同一个字段选择不同名称。worktree 可以隔离编辑过程，合并时仍然需要处理代码和语义的一致性。公共字段名、接口结构和文件职责应该在 spec、ticket 或共享探索笔记中确定；有实际先后关系的工作要记录依赖。
执行者怎样获得资料并汇集结果
负责调度的 Agent 可以先安排探索工作，查看相关代码和文档，把发现保存为各执行者能够读取的资料。传递任务时提供 spec、ticket、探索笔记和前置提交的位置，让子 Agent 直接读取权威内容。这样能够减少转述遗漏，也避免在每个提示词里重复整份需求。
集成分支负责汇集全部任务。每个执行者确认自己的 worktree 基于集成分支，实施指定 ticket，再把集成分支的最新修改合并到自己的任务分支。合并执行者随后将完成的工作汇入集成分支，调度者据此启动新任务。
作者要求每个实现者调用 tdd。TDD 是 Test-Driven Development，即测试驱动开发：针对一个明确行为编写测试，确认测试因该行为尚未实现而失败，实现代码以后再次执行，确认测试通过。以日期过滤为例，测试要能够辨认起始日期、结束日期和范围外订单，失败原因也要确实对应日期过滤行为。
各任务检查成功以后，还需要在合并结果上验证完整流程。B、C 分别通过测试，只能证明各自检查的行为；D 的组合条件测试才能检查日期和状态一起提交时的结果。全部任务完成后，/implement-spec 会对集成分支调用 code-review，集中处理发现的问题，并清理任务 worktree。
v1.3.1 的交付目标是完整实现需求的集成分支。 当任务管理系统通过 PR 关闭任务，或者用户要求创建 PR 时，流程会在第一次合并之后创建草稿 PR，结束时将其标记为可审查。使用本地 Markdown 管理任务时，也可以按照该管理方式关闭任务并报告集成分支。版本发布记录明确列出了这个交付条件。
视频中使用 AFK 描述这种减少持续人工操作的工作方式。AFK 是 Away From Keyboard，表示暂时离开键盘。能持续执行任务的前提，仍然是输入规则完整、任务依赖可靠、运行检查能够证明需求行为；最终结果也需要人工审查。
三、/pr 如何帮助人工审查
任务完成后，审查者需要知道改动涉及哪些行为、已经执行了哪些验证，以及出错以后会影响什么。视频在 04:54---08:09 介绍了 /pr 的三段模板：Summary、Evidence、Merge Danger。
/pr 为 PR 正文提供结构。PR 是 Pull Request，即请求将分支修改合并到目标分支的审查入口。模板把审查者需要的信息放在清晰的位置，具体字段见 v1.3.1 Skill 定义。图中的三块信息是正文的组成部分。
Summary：让审查者看见关键改动
Summary 需要选择能够解释改动的视图，例如关键交互的 Mermaid 图、算法伪代码或简短的差异片段。订单导出可以展示"页面提交条件、接口检查权限、查询匹配订单、生成文件"的关系，再用短文指出修改涉及哪几个边界。
审查者随后能够带着具体问题查看代码：权限在哪里判断？日期与状态如何组合？文件内容由哪一部分负责？视图的价值来自这些问题能够被定位，图中保留的对象和连线也应该服务于它们。
Evidence：把需求行为与运行结果连接起来
Evidence 要提供修改前后的证据。视觉改动适合展示截图，查询逻辑适合展示对应测试和输出。订单导出示例可以采用以下证据结构；表格描述的是需要采集的证据，具体结果应由真实运行填入。
| 验收行为 | 修改前要观察什么 | 修改后要观察什么 |
|---|---|---|
| 日期边界 | 边界订单遗漏或范围外订单被错误导出 | 输出订单集合符合明确的边界规则 |
| 组合条件 | 日期或状态条件没有同时生效 | 每条导出订单同时满足两个条件 |
| 导出权限 | 无权限账号能获得受限数据 | 请求被拒绝，受限数据没有进入文件 |
证据需要保留输入条件、实际执行的检查以及结果。命令退出成功，还要确认测试没有被跳过，并且断言确实检查了本次需求。只有"全部测试通过"这一句，审查者无法知道权限和组合条件是否已经接受验证。
要求 Agent 提供证据，会促使它获取能够支撑结论的运行信息。截图和测试输出的可信程度取决于采集方式与覆盖范围，最终需要把证据对应到 spec 中的验收条件。
Merge Danger：说明可恢复性和影响范围
Merge Danger 包含两个判断。Door 表示修改产生的结果是否容易恢复，作者用 two-way door 与 one-way door 作比喻；Blast Radius 表示修改出错时受影响的范围。
调整导出按钮的提示文字，通常容易恢复，影响主要在该页面。修改所有订单查询共用的权限判断，可能影响页面、导出接口以及其他调用者。删除数据库字段或者向客户发送消息，还会产生需要单独处理的外部结果。恢复源码以后，已经删除的数据和已经发送的消息仍然需要相应处理。
在订单导出 PR 中，影响范围应具体写到调用者、数据和操作，例如"影响导出接口与共用查询参数的页面；日期规则调整会改变边界订单集合"。Agent 作出的风险判断供审查者核对，判断时需要同时读取需求和差异内容。
这份模板负责 PR 正文的内容结构。推送分支、创建 PR 和合并操作，依照实际开发流程及授权执行。作者的 /pr 文档说明了正文模板与这些操作的关系。
四、/retro 如何改善后续开发
一次开发完成以后，结果里可能看不出过程中的问题。Agent 花了很多次搜索才找到查询模块，反复修正日期字段名，或者直到人工提醒才运行检查，最后仍然可以交付功能。会话记录保留了这些过程，因此适合作为改善开发环境的依据。
retro 来自 retrospective，表示复盘。视频在 09:38---13:58 演示了它如何读取会话记录，发现资料导航、自动检查和工具使用中的问题。输入可以是当前会话，也可以指定其他会话的真实记录；输出是按严重程度排列的改进建议，人工选择以后再安排修改。
七类检查如何对应具体问题
作者在 v1.3.1 定义中列出了七个检查方向。结合订单导出示例，可以判断每个方向关注什么。
| 检查方向 | 会话中可能出现的依据 | 可以提出的改进 |
|---|---|---|
| 代码导航 | 反复搜索订单查询和权限模块 | 在常读文档中补充模块入口与职责 |
| 自动检查 | 遗漏日期边界，现有检查没有执行 | 检查已有测试和命令，补充必要验证并接入自动执行 |
| 编码规范 | 跨模块日期语义不一致，审查遗漏 | 为审查者提供具体的判断规则 |
| 全局 AGENTS.md | 每次会话都加载大量无关说明 | 按资料用途整理内容，保留清楚的入口 |
| 工具开销 | 命令返回大量内容，目标信息很少 | 改进工具筛选与输出方式 |
| 无效指令 | 指令表述笼统，无法指导具体操作 | 删除无效内容或明确可执行要求 |
| 信息访问 | Agent 读取不到服务日志和接口错误 | 提供需要的日志入口或只读资料 |
提出建议之前，需要检查仓库中已经存在的命令和规则。假设项目已经有验证日期边界的测试，问题是自动流程没有运行它，改进应围绕运行入口展开。这样能够让建议对应本次会话暴露的缺口。
能够机械判断的错误适合用自动检查约束。例如禁止某个 API、限制导入方式、检查文件位置，都可以考虑通过检查工具捕获。需要结合多个文件和业务意义判断的规则，则适合供审查者阅读。CODING_STANDARDS.md 可以承载这类审查规范，并提供进一步资料的入口。
人工选择怎样影响改进结果
视频约 11:16 展示了一个发现：Agent 在用户选择修复方案之前执行了公开发布操作。Matt 同时说明，他对该事件严重程度的判断与复盘给出的排序存在差异。这个例子说明建议需要结合真实影响作判断，排序本身只能提供处理线索。
观察图中的人工判断节点：读取记录和提出建议之后，采纳决定影响是否进入修改过程。图中后半段的实施与验证，是采纳建议后安排的工作。
假设记录显示日期边界错误两次被人工指出，仓库中也缺少覆盖该行为的测试，人工可以选择补充边界测试并接入持续集成检查。持续集成通常简称 CI，指提交修改后由自动流程运行检查。改进完成后，需要实际运行对应检查，确认它确实覆盖日期边界行为，后续开发才能获得持续反馈。
复盘建议的采纳需要人工判断。 Matt 在视频中提醒，持续自动寻找问题并自动修复，可能把误报也当成必须处理的缺陷，让仓库偏离实际需要。选择出现异常、反复纠正或明显低效的会话，通常更容易获得有依据的改进建议。
五、GLOSSARY.md 如何统一术语
订单导出涉及的日期究竟表示下单日期、支付日期，还是发货日期？"已完成订单"包含哪些状态？这些词如果只有口头约定，不同执行者可能采用不同解释，最后得到接口字段一致、业务含义各异的结果。
GLOSSARY.md 是术语表，用来保存领域概念的定义。按照本文设定的示例，术语可以这样记录：
| 术语 | 明确定义 |
|---|---|
| 订单日期 | 订单创建时间，按业务约定的时区解释 |
| 日期范围 | 从起始日期当天开始，到结束日期当天结束 |
| 可导出订单 | 当前账号有权查看，且同时满足所选过滤条件的订单 |
| 导出结果 | 固定字段顺序的 CSV 文件，每条记录对应一笔可导出订单 |
术语表帮助 spec、ticket、代码审查和 PR 描述使用同一套业务语言。例如 spec 使用"订单日期"时，执行者能够读取它的明确定义；审查者也能据此检查代码是否误用了支付时间。任务单中仍需提供具体输入和验收条件，使概念定义能够对应实际行为。
视频在 08:11---09:36 介绍了文件名称调整。作者将 CONTEXT.md 改为 GLOSSARY.md，对应的 CONTEXT-MAP.md 改为 GLOSSARY-MAP.md。新名称更直接表达术语表的职责，相关 Skill 按新名称读取文件。迁移时需要处理文档引用，并让团队获取同一次文件调整，避免同时维护内容不同的两份术语表。v1.3 版本说明记录了这个变化。
例如公共导出任务 A 开始前，术语表中的"订单日期"和 spec 中的接口字段就应具备明确关系。后续 B、C 读取同一份定义，D 组合查询条件时也按这份定义验证结果。领域概念能够沿着需求、实现、审查和复盘持续使用。
资料来源
本文依据原视频英文自动字幕整理，并使用作者 v1.3.1 的 Skill 定义核对流程。订单导出、任务编号和验收表格为本文教学示例。字幕中的文件名称等标识已结合作者资料核对；视频画面的具体代码与示例输出未进行视觉核验。