我以前做 AI web UI 自动化 harness 工程时，主要用 superpowers 往前推。后来发现，从 0 到 1 的探索项目如果还没想清楚第一版做什么、不做什么、怎么验收，就很容易靠后续补丁反复修方向，浪费时间和 token。本文想讲清楚：什么时候该用 superpowers，什么时候该先用 mattpocock/skills。

AI Coding · 工作流选型 · superpowers · mattpocock/skills

先给结论

这两个工具不是谁替代谁，而是适合不同阶段。

superpowers 官方把自己定义为一套完整的软件开发方法论：从 brainstorming、spec、plan，到 TDD、review 和 branch 收尾，都是同一条纪律的一部分。

mattpocock/skills 更像一组可组合的工程技能：需求不清楚就 grill，讨论需要落文档就 to-prd，任务太大就 to-issues，反馈不足就用 tdd、debug、review。

换成白话就是：如果你已经知道要做什么、怎么拆、怎么验收，只是让 AI 按规矩把功能做出来，可以用 superpowers。

如果你还在想清楚 “到底做什么、第一版不做什么、怎么验收”，先用 mattpocock/skills。

Claude Code 官方最佳实践和 Simon Willison 的文章也都在强调同一件事：AI Coding 不是让 agent 自由发挥，而是给它明确上下文、验证信号和责任边界。

一次踩坑经历

我以前做过一个 AI web UI 自动化 harness 工程。

这个项目本质上是从 0 到 1 的探索：怎么描述页面能力、怎么把 UI 操作变成稳定的 harness、怎么组织用例、怎么让 agent 生成和验证代码，很多东西一开始都不清楚。

但当时我主要按 superpowers 的方式往前推进。它确实能让 agent 更有纪律，也能把一条开发链路跑起来。

问题是，探索项目最缺的不是执行力，而是前面的判断。

需求边界没问清楚，后面的每一步都可能是在错误方向上变得更 “自动化”。

后来就出现了一个很典型的问题：方案做着做着发现边界不对，再补一层规则；用例生成不稳定，再补一层约束；页面抽象不够清楚，再调整一次模型。

这些修改单次看都不大，但累积起来就是大量返工。更麻烦的是，每次返工都要消耗新的上下文、时间和 token。

这里容易有个疑问：superpowers 不是也有 brainstorming 吗？为什么它没有把需求澄清到位？

我的理解是，superpowers 的 brainstorming 更像整条开发流水线的入口：它会帮助 agent 进入 spec、plan、TDD、review 这套链路。

但 grill-with-docs 的重点不是 “帮你启动开发”，而是反复追问模糊点，并把术语、边界和决策沉淀到 CONTEXT.md、ADR 或 PRD 里。

从 0 到 1 的探索项目，最缺的往往不是一个开发入口，而是有人把 “你以为已经清楚” 的地方继续问下去。

这件事给我的教训是：从 0 到 1 的项目，不要一上来就把自己交给执行流程。

先把问题问清楚，再让工具提高执行效率。

快速判断

当前状态	更适合	原因
还不知道第一版到底做什么、不做什么、怎么验收	mattpocock/skills	先用 grill、to-prd、to-issues 把问题问清楚
项目很复杂，需要从 0 到 1 慢慢拆清楚	mattpocock/skills	它不是只能补小任务，而是可以分阶段组织复杂项目
已有 spec 模板、任务切片方式和验收命令	superpowers	说明项目已经进入 “按规格开发” 的阶段
明确要交付一个 issue	implement	围绕 PRD 或 issue 做完整交付闭环
测试失败、构建失败、bug 明确	diagnosing-bugs / ralph	用明确失败信号驱动修复

什么时候先用 mattpocock/skills

只要你还在定义问题、流程资产和任务粒度，就先用 mattpocock/skills。

这里不是说它只能做小任务。恰恰相反，复杂的从 0 到 1 项目更应该用它。

原因是复杂项目不能一次性交给 agent “全做完”。你要先澄清需求，再沉淀 PRD，再拆 issue，再一段一段实现和验证。

mattpocock/skills 的优势，是把这些阶段拆开，让每一步都有产物，而不是把复杂项目压成一个大 prompt。

1. 需求还没问清楚：grill-with-docs

当你只知道 “我要做一个 AI web UI 自动化 harness”，但还不知道第一版边界、核心场景、非目标和验收标准时，不要急着让 agent 开始实现。

这时更应该先用：

$grill-with-docs
我想做一个 AI web UI 自动化 harness，
目标是让 agent 能理解页面能力、生成操作步骤、执行验证。
请结合当前仓库帮我澄清第一版边界和验收标准。

它的价值不是给你一个漂亮答案，而是逼你把模糊想法变成可以执行的边界。

如果项目里已经有代码和文档，它还会帮你沉淀 CONTEXT.md 和 ADR，减少后续反复解释同一件事。

遇到它问得太细，也不要急着嫌烦。

很多时候，正是那些 “为什么第一版不做这个”“谁会用这个能力”“怎么验收才算完成” 的问题，能帮你少返工几轮。

grill 示例：解释澄清问题

2. 讨论清楚后：to-prd

需求澄清完，不要马上开工。

先把讨论结果整理成 PRD。

$to-prd
请基于刚才的讨论、CONTEXT.md 和 ADR，
整理 AI web UI 自动化 harness v0 的 PRD。

PRD 的价值不是形式主义。

它是把 “我以为你知道” 变成 “后续每个 agent 都能读懂”。

好的 PRD 至少要写清楚目标、非目标、用户路径、约束、验收标准和风险。

to-prd 示例

3. PRD 不能直接实现：to-issues

很多人拿到 PRD 后，会直接让 agent “开始实现”。

这一步也容易出问题。

因为一个 PRD 往往包含多个方向：数据结构、运行时、UI、测试、文档、验证脚本。一次全做，很容易互相牵扯。

所以 PRD 后面应该接：

$to-issues
.scratch/harness/prd-v0.md

拆 issue 的目标，是让每个任务都能独立领取、独立验证、独立交付。

如果 issue 拆得太粗，agent 会自由发挥；如果拆得太细，又会制造协调成本。比较好的粒度，是一个 issue 能在一个明确上下文里完成一个可验证的垂直切片。

4. 不知道下一步：ask-matt

有时你已经有 PRD，也有 issue，但仍然不知道下一步该用 implement、tdd、review 还是 qa。

这时不要靠猜。

$ask-matt
我现在有 PRD 和 5 个 issue，
第一个 issue 涉及 harness 数据模型和最小运行链路。
下一步应该怎么推进？

ask-matt 的价值是流程路由。

它不直接替你写代码，而是帮你选择更合适的工作方式。

ask-matt 示例：需求澄清后的下一步

ask-matt 示例：PRD 和 issue 后的下一步

什么时候用 superpowers

superpowers 官方覆盖很宽，从 brainstorming 一直到 TDD、review 和 branch 收尾。

但普通团队更适合用窄一点的标准：它适合在 “按规格开发” 的阶段做功能开发。

这里的 SpecCoding，可以先简单理解成：先有清楚的规格说明，再按规格拆任务、写代码、跑验证，而不是边想边写。

这里不要用 “目标、边界、验收、执行链路是否清楚” 来判断。

因为这些词太主观。不同人对 “清楚” 的标准不一样，agent 也很容易把一句模糊的确认理解成可以开工。

更可操作的判断，是看项目里有没有这些具体资产：

• 已有固定的 spec 模板或需求描述格式。
• 已有功能开发的目录约定、代码生成约定和命名约定。
• 已有稳定的开发切片方式，比如一个 spec 如何拆成若干可交付任务。
• 已有固定的验证命令、报告产物或人工验收路径。
• 团队已经多次按这套流程交付过功能，而不是第一次边做边定义流程。

如果这些东西还没有，就说明你还没有真正进入 SpecCoding 阶段。

如果这些资产已经存在，superpowers 的价值会很明显。

它可以让 agent 按成熟 SpecCoding 流程执行：读 spec，写计划，小步实现，用 TDD、review 和验证把质量关住。

这类任务通常不是 “我要不要这么设计”，而是 “按已有设计增加一个功能、修一个缺陷、补一个切片”。

它不适合替你从零定义 SpecCoding 流程。

一条更稳的推荐工作流

如果让我重新做当时那个 AI web UI 自动化 harness，我不会一开始就让 agent 直接按执行流程跑。

我会按下面这条链路走：

grill-with-docs
→ CONTEXT.md / ADR
→ to-prd
→ to-issues
→ ask-matt
→ implement / superpowers
→ tdd
→ review / qa
→ ralph（只在有明确失败信号时使用）

这条链路看起来比 “直接开工” 慢，但对于探索项目反而更省。

因为它把最容易返工的部分提前暴露出来：目标、边界、非目标、验收标准、任务粒度。

真正进入实现时，agent 的上下文更稳定，执行也更少跑偏。

这里的 superpowers 不放在开头，而是放在 SpecCoding 资产准备好之后；如果只是交付一个明确 issue，implement 可能更轻。

几个容易混淆的点

implement 和 tdd 不是一回事

implement 面向交付，适合拿着 PRD 或 issue 做完一个任务。

tdd 面向编码，适合在行为边界清楚时用红绿重构推进实现。

implement 是外层交付流程
tdd 是内层编码方法

所以更合理的关系是：

PRD + 单个 issue
→ implement
→ 在适合的行为边界上使用 tdd
→ 编码
→ 单测 / 类型检查 / 全量测试
→ review
→ commit

如果你一开始连行为边界都没想清楚，直接要求 TDD，测试也可能写偏。

ralph 不替代前期思考

ralph 适合有明确失败信号的持续修复。

比如测试失败、构建失败、类型检查过不去，或者一个明确 bug 需要修到验证通过。

如果目标不清楚，让 ralph 一直修，只会把 agent 推进更深的返工循环。

ralph 示例：适合围绕明确失败信号持续修复

最后的判断标准

最后用几句话收束。

探索期，用 mattpocock/skills 多问几轮。

这时最重要的是目标、边界、非目标、验收和任务粒度。

已经有规格、拆分方式和验收命令后，用 superpowers 把纪律跑起来。

这时最重要的是沿着既有 spec、计划、小步实现、TDD、review 和验证流程稳定交付。

更简单一点说：需要补哪个工程环节，就用 mattpocock/skills；已经决定采用整条开发纪律，再用 superpowers。

不要让一个工具承担所有职责。

工具本身不能替你判断项目处在哪个阶段。

真正能减少返工的，是先判断阶段，再选择工具。

我的那次 harness 项目经历，最大的教训就是这句话：从 0 到 1 时，先澄清，再执行。

参考资料

• Superpowers GitHub
• mattpocock/skills GitHub
• skills.sh/mattpocock/skills
• skills.sh/mattpocock/skills/implement
• Claude Code Best Practices
• Claude Code Skills Docs
• Simon Willison: Vibe engineering

---