前几周我写过一篇 Matt Pocock Skills 教程，安装、命令、流程都讲了，还放了两个实战案例。文章发完后有人问我：你这个演示项目，真的让 Subagent 跑过吗？
我回头看了一遍，确实有点心虚。
那篇文章里的流程没有错，但两个案例还是我设计出来的“理想用法”。我写了应该怎么 Grill、怎么拆 Ticket、怎么诊断 Bug，却没有真的让 Agent 从头跑到尾。说白了，还是教程，不是实测。
所以这次我重新来了一遍。
我在当前目录单独建了一个退款项目，用 Python 3.13、SQLite 和 Fake Gateway。第一个 Subagent 从空项目开始做完整功能，第二个 Subagent 换成全新上下文，只拿到 Bug 症状，不知道我在哪里动了手脚。对话、生成文件、Git 提交、代码 diff、红绿测试和 Review 原始输出，我全部留了下来。
先说我现在的结论：这套 Skills 我会继续用，但不会再把它说成“装完就能让 Agent 按工程流程干活”。
它确实能管住 Agent 的一部分坏习惯，也真的帮我抓到了几处会影响退款资金的竞态。但它没有让 TDD 自动变严格，也没有保证 Bug 诊断的每一步都执行到位。最后还是要我回来验收。
我先选了一个不能靠“看起来没问题”过关的功能
我没有拿 Todo List 做演示，而是做了一条退款审核链路。
用户先提交退款申请，审核人决定通过还是拒绝；通过后，Worker 在数据库事务外调用支付渠道；如果渠道超时或者结果不确定，退款进入 UNKNOWN，再交给 Reconciliation 查询最终结果。
这类功能很适合测试 Agent。权限、金额、幂等、并发、审计，少一块都可能出问题。最重要的规则只有一条：订单实付 100 元，渠道最后就不能退掉 101 元。
我给项目加了几个硬限制：只能使用文件 SQLite 和 InProcessFakeRefundGateway，不能访问真实支付渠道，不能添加 Git remote，也不能 push。每一步还要保留执行命令、退出码和原始测试输出，不能只在最后告诉我“已完成”。
功能 Subagent 和后面的 Bug Subagent 也不共享推理。第二个 Agent 如果提前看过第一个 Agent 的思路，所谓“诊断”很容易变成照答案改代码，那就没什么意思了。
25 个问题问完后，我才看到这套流程真正落地
我先让第一个 Subagent 运行 setup-matt-pocock-skills，并选择 Local markdown。它没有一上来就写文件，而是先检查仓库，再告诉我准备修改 AGENTS.md 和 docs/agents。等我确认后，它才继续。
接着我只给了它退款审核的原始目标，然后运行 grill-with-docs。
它一共问了 25 个问题。申请人能不能审核自己的退款，部分退款怎么占额度，幂等键什么时候生成，支付调用能不能放在事务里，第三次安全失败怎么处理，UNKNOWN 到底由谁结束，这些都被问到了。
25 个问题不算少，但这次没有问到让我想关窗口。大多数问题都会改变状态机、权限或者验收标准，我回答完以后，确实比一开始更清楚自己要做什么。
Grill 最后生成了 18 个领域术语和 10 个 ADR。不过这里第一次出现了我不满意的地方：Agent 曾经把实现细节写进 CONTEXT.md，慢慢把一份领域词汇表写成了半份 PRD。
我检查后让它重新清理，术语留在 CONTEXT.md，设计决定放回 ADR 和对话记录。这个小插曲很有代表性。domain-modeling 写得再清楚，Agent 还是可能写偏，不能因为文件名对了就默认内容也对。
Grill 结束后，我让它继续跑 to-spec。最终生成了 55 条 User Story，前面确认的 25 个决定全部找到了对应位置。再往后，to-tickets 把它拆成 9 张纵向 Ticket，一共有 74 条验收标准。
这几个数字本身没什么值得炫耀的。我真正看重的是可追溯：第 12 个问题确认了什么，进了 Spec 的哪一段，最后由哪张 Ticket 和哪条测试负责，我能一路查回去。
GitHub Issue #341 讨论的正是这个问题。Grill 里谈得很细，到了 Spec 和 Tickets 里却只剩一句模糊总结。我的做法很笨，就是在每个阶段停一下，对一遍 25 个决定有没有丢。这次没有发现缺项，但这是我检查出来的，不是 Skill 自动保证的。
Review 抓到的东西，比我预想得严重
需求和 Ticket 确认后，功能 Subagent 开始逐张实现，并运行 implement、tdd 和 code-review。
code-review 会从一个固定 commit 开始，把检查分给两个 Subagent。一个只看项目规范和代码味道，另一个只看实现有没有偏离 Spec。这个设计我原来只是觉得“比较完整”，真正跑起来后，我才发现它是这套流程里最值钱的一步。
Review 前后抓到了不少真问题。
AuthenticationContext 可以被伪造，审计表可以更新和删除，普通查询会把 claim token 暴露出去。更麻烦的是退款执行里的几个时间窗口：渠道已经动了钱，系统还可能把它当成安全失败；渠道调用仍在进行，Reconciliation 却可能查到 NOT_FOUND；渠道返回到数据库提交之间，同一个 claim 还有机会再次调用。
这些不是代码格式问题。放到真实支付里，任何一条都够我追一晚上日志。
全功能 Review 最后跑了四轮。当前行为修完后，我重新执行了 51 个测试，全部通过，Spec Review 也没有再找到功能缺口。
但我没有把结果写成“全绿收工”，因为 TDD 这边留下了两个历史问题。
有几张 Ticket 的第一个验收测试一运行就是绿的。原因是前面的 Ticket 已经顺手把后面的行为做了，Ticket 03 和 Ticket 04 的边界重叠最明显。Ticket 06 更直接，它最开始用一个大测试同时推进重试、耗尽、资金状态、审计和终态，没有做到一个失败测试只驱动一小段实现。
后面把测试补细，不能证明前面严格做过 red-before-green。我让 Review 把这两个问题继续留着，没有为了得到一份漂亮报告去改历史。
这也改掉了我对 tdd Skill 的一个想当然：它能提醒 Agent 先写测试，但它不是强制执行器。任务一长，Ticket 一重叠，Agent 还是会走捷径。测试通过只能说明当前用例通过了，不能反推开发过程一定规范。
还有一个使用前必须知道的细节。当前 implement Skill 最后一行会要求提交当前分支。本次演示本来就需要保留提交记录，所以我允许它 commit。换到真实项目，我只会在独立分支或者 worktree 里运行，并提前改掉自动提交要求。什么时候提交，我还是想自己决定。
第二个 Subagent，我只给它一条会红的命令
功能基线冻结后，我开始准备 Bug 实测。
我先在正确代码上加了一条测试：订单实付 100 元，第一笔退款 40 元，渠道调用刚进入就暂停；这时租约恢复把任务转成 UNKNOWN，Reconciliation 同时查询；接着系统再尝试审批一笔 70 元退款。
正确代码下，这条测试连续跑了 3 次都通过，完整测试一共 52 个，也全部通过。先做这一步，是为了确认测试本身不是一个无论代码对错都会失败的假信号。
然后我故意移动了 Fake Gateway 里的状态登记顺序。
prepared 标记已经被删掉，in-flight 标记却要等到 hook 返回后才写入。就在这个很短的空窗里，原来的渠道调用还可能继续动钱，但 Reconciliation 看不到它正在执行，于是把第一笔退款当成 NOT_FOUND，记成 FAILED，并把 40 元额度放了回来。
第二笔 70 元因此能通过审批。等第一笔调用继续执行，渠道实际退款变成 110 元，订单实付只有 100 元。
我没有把根因告诉第二个 Subagent，只给了它 Bug 描述和一条测试命令：
python -m unittest tests.test_refund_reconciliation.RefundReconciliationTests.test_recovery_race_never_refunds_more_than_the_order_paid -v
它第一次运行只用了大约 0.08 秒，结果直接是 11000 > 10000。随后又重复了 3 次，每次都能复现，不需要 sleep，也不用碰运气。
接下来它没有马上改代码，而是先列了 5 个可以验证的猜测。可能是 prepared 到 in-flight 之间有空窗，也可能是恢复流程取消错了调用、lookup 漏查了某种状态、恢复提前释放了额度，或者查询结果在提交前已经过期。
它给临时探针统一加了 [DEBUG-rf91] 标记，一个个看状态。最后第一条成立：渠道调用暂停时，这个幂等键既不在 prepared，也不在 in-flight，Reconciliation 当然会以为渠道里什么都没有。其余四条都有实际输出把它们排除掉。
最后的修复很小。消费 prepared token 时，就在同一个锁里把幂等键登记成 in-flight，不再等 hook 执行完。
我没有让它改测试，也没有让它放宽 100 元的断言。修完后，原来的 110 元用例通过，最小回归通过，21 个相关并发测试通过，完整 52 个测试也全部通过。临时 DEBUG 标记最后全部清掉了。
到这里，diagnosing-bugs 的价值已经很明显。它不是帮模型猜得更快，而是逼模型先做出一个稳定反馈，再拿证据排除错误猜测。第一条猜测这次刚好就是根因，但如果没有后面的探针，我仍然只能说它“猜中了”，不能说它“查清了”。
Bug 修好了，诊断流程却没有满分
我重新看 Bug Agent 的完整记录时，又发现一个不够严谨的地方。
diagnosing-bugs 要求最小化场景时一次只删一个因素，删一次就重新运行，直到剩下的每一项都不可缺。第二个 Subagent 第一次做最小化时，一口气删掉了 6 个后续步骤，直接跳到更小的现有测试。
这个小测试确实能更早暴露 FAILED 不该出现，但它没有证明那 6 个步骤是怎么一个个被排除的。
Review 把这个问题指出来后，Agent 又补跑了单变量控制。可它跑完后删掉了临时 probe 文件，只保留测试名称和输出。第二轮 Review 仍然不认可这段证据，因为别人已经没办法独立检查当时的探针到底写了什么。
代码修复没有因此失效，52 个测试也是真的通过。但这段诊断过程不能算满分，我把它原样留在了最终报告里。
这反而让我更确定一件事：Skill 最大的作用不是让 Agent 永远按规矩做，而是让我有一套标准去发现它哪里没按规矩做。如果最后只保留一句“Bug 已修复”，这个问题根本不会被看见。
网上那些争议，我这次基本都碰到了
截至 2026 年 7 月 16 日，mattpocock/skills 在 GitHub 上是 172,283 Star，最新正式 Release 还是 v1.1.0。仓库 main 更新很快，所以涉及安装方式和 Skill 行为，我还是会打开当前文件重新看，不会拿几天前的记忆直接写。
Issue #44 里有人被 Codex 连问 200 个问题，还有人跑了 4.5 小时。我的这次 Grill 停在 25 轮，问题也基本有用，但这只能说明我这次控制住了，不能说明所有模型都会自己收尾。
Issue #130 说 CONTEXT.md 容易被写成 PRD，我的功能 Agent 就短暂犯过。Issue #240 说模型问完直接进入实现，我这次没有碰到，因为 Setup 和 Grill 都停下来等了确认。Issue #341 担心决定在 Spec、Tickets 和实现之间丢失，我靠 25/25 的人工映射才把这个风险压下去。
Codex 兼容性也还在变化。Issue #163 已经完成，上游给需要手动调用的 Skills 增加了 agents/openai.yaml；Issue #360 关于 frontmatter 校验差异还开着。当前 README 里，Codex 仍然通过 skills.sh 安装，Claude Code 已经有托管 plugin，原生 Codex plugin 还在路线图里。
这些讨论看完，再对照我自己的两轮实测，我不会说这套 Skills 特别神，也不会说它只是多写几份文档。它的效果很依赖模型、任务大小、项目约束，以及使用者愿不愿意中途检查。
现在让我再选一次，我会按风险调用
从零安装，我还是会先用上游 README 的 Quickstart：
npx skills@latest add mattpocock/skills
安装时我不会全选，只装当前需要的 Skills，并确保包含 setup-matt-pocock-skills。第一次练习我会选 Project 和 Local markdown，避免 Agent 直接创建远程 Issue。真要接 GitHub 或 GitLab，再单独检查登录账号、remote 和写权限。
中型功能，我会跑下面这条链：
$setup-matt-pocock-skills
$grill-with-docs
$to-spec
$to-tickets
$implement <ticket>
$code-review <fixed-point>
每一步我都会停下来检查一次。Grill 后看 CONTEXT.md 和 ADR，Spec 后对决策，Tickets 后看边界和依赖，Review 时固定比较起点。不是让 Agent 一口气跑完，然后等它给我总结。
难复现 Bug，我只调用 diagnosing-bugs。第一件事不是看它分析得像不像，而是要一条快速、确定、能捕获准确症状的失败命令。没有红色反馈，我不会让它改业务代码。
如果只是改一处文案、补一个已有模式的字段，或者修一个已经稳定复现的简单报错，我不会搬出整条流程。任务本身只值十分钟，就没必要先生成半小时过程材料。
最后我的判断
跑完两个 Subagent 后，我对 Matt Pocock Skills 的评价比之前更高，也比之前更保守。
更高，是因为它真的帮我把一个中型退款功能从模糊需求推进到了 9 张 Ticket 和可运行代码，Review 还抓到了几处会影响真实资金的竞态。diagnosing-bugs 也不是纸上谈兵，它确实把 110 元退款事故从失败测试一路查到了状态空窗。
更保守，是因为 TDD 仍然会翻车，最小化步骤也会被 Agent 偷懒跳过。流程写在 SKILL.md 里，不等于流程已经发生。
所以我会继续用，但不会把它设成每个任务的默认流水线。需求不清时用 Grill，中型功能用 Spec 和 Tickets，高风险逻辑补 TDD 和独立 Review，难复现 Bug 先跑诊断循环。小改动就直接改、直接测。
这次实测后，我最愿意转述的一句话是：Matt Pocock Skills 不能替我负责，但它能让我更容易看见 Agent 在哪里没有负责。
发表于 前天 21:39
|
查看: 0|
回复: 0
