今天很多人使用 Coding Agent 的方式，仍然像是在使用更聪明的自动补全：给一个需求，让模型直接写代码，然后人工检查哪里不对。这个模式在小任务上很快，但一旦进入真实项目，就会暴露几个反复出现的问题：需求没问清楚就实现，计划只有几句空话，测试事后补，调试靠猜，完成时没有验证证据，多 Agent 协作时上下文互相污染。

Superpowers 试图解决的正是这些问题。它不是一个单独的工具，而是一套面向 Coding Agent 的软件开发方法论：用一组可触发的 skills，把需求澄清、方案设计、实施计划、TDD、调试、代码审查、完成验证这些工程动作固化下来。换句话说，它关注的不是“模型能不能写代码”，而是“模型能不能按工程流程可靠地工作”。

1. 为什么 Coding Agent 需要软件设计类 Skill

模型能力越强，越容易让人忽视流程。因为它可以很快给出一大段看起来合理的实现。但在软件工程里，真正危险的常常不是“写不出来”，而是“写得很快，但方向错了”。

典型问题包括：

• 用户只说“做一个功能”，Agent 就开始改文件，没有确认用户真正的目标。
• 设计里没有边界，后续实现自然开始扩范围。
• 测试只是为了证明代码现在能跑，而不是先定义行为。
• Bug 没有根因分析，改一个地方又引出另一个问题。
• Agent 自己报告“完成了”，但没有跑完整测试、构建或用户路径验证。

软件设计类 skill 的价值，就是把这些本来依赖资深工程师经验的停顿点，变成 Agent 必须遵守的工作步骤。它不只是提醒 Agent “要认真”，而是告诉它：什么时候必须问问题，什么时候必须写 spec，什么时候不能进入实现，什么时候必须回到根因调查。

2. Superpowers 的核心 Skill 工作流

Superpowers 的工作流可以概括成一条链路：

想法
  -> 需求澄清与设计
  -> 隔离工作区
  -> 实施计划
  -> 按任务执行
  -> TDD 与调试
  -> 代码审查
  -> 完成前验证
  -> 分支收尾

它的核心 skill 可以按阶段理解，而不是逐个孤立记忆。

2.1 设计阶段：先确认做什么

using-superpowers 是入口守卫。它要求 Agent 在任何任务开始前先判断是否有相关 skill 适用。只要可能适用，就要加载对应 skill。它解决的是“明明有流程，但 Agent 不用”的问题。

brainstorming 是软件设计阶段的核心。它要求 Agent 先探索项目上下文，再一次只问一个澄清问题，理解目标、约束和成功标准。之后提出 2-3 个方案，说明取舍和推荐理由，分段展示设计，获得用户确认，最后写成 spec。

这个 skill 最重要的门禁是：没有设计批准前，不允许写代码、搭脚手架或进入实现阶段。它把“先想清楚再动手”变成硬规则。

2.2 计划阶段：把设计变成可执行任务

using-git-worktrees 负责创建隔离工作区。它会检查项目是否已有 .worktrees/ 或 worktrees/，确认目录被 Git ignore，再创建新分支和 worktree，并运行基线测试。它的目的很直接：不要在主工作区或脏分支上让 Agent 随意改代码。

writing-plans 把已经批准的 spec 拆成实施计划。它要求任务粒度足够小，每个任务都要有明确文件、测试、实现步骤、验证命令和提交步骤。Superpowers 对计划的要求很高：计划不能写“添加适当错误处理”这类空话，而要写到后续执行者可以直接照做。

这一步的本质是降低后续 Agent 的自由发挥空间。越是让实现者自己猜，越容易偏离设计。

2.3 执行阶段：用子代理拆任务，但不放弃审查

subagent-driven-development 是 Superpowers 最有代表性的执行方式。它不是简单地“多开几个 Agent 并行写代码”，而是每个任务派发一个全新的实现 Agent，并且每个任务完成后做两层审查。

第一层是 spec review：检查实现是否完全符合任务要求，有没有少做、多做或理解错。第二层是 code quality review：检查代码质量、测试质量、边界处理和可维护性。只有两层审查都通过，才进入下一个任务。

executing-plans 是没有子代理能力或选择内联执行时的备用方案。它会按计划逐项执行，但质量门禁比 subagent-driven-development 弱。

2.4 质量阶段：测试、调试、审查都要有证据

test-driven-development 是实现纪律。它的铁律是：没有先失败的测试，就不能写生产代码。流程是 RED-GREEN-REFACTOR：先写失败测试，确认失败原因正确，再写最少代码让测试通过，最后再重构。

systematic-debugging 是调试纪律。它禁止先猜一个修复试试，要求先做根因调查、模式分析、单一假设验证，再实施修复。如果多次修复失败，就要停下来质疑架构，而不是继续堆补丁。

requesting-code-review 和 receiving-code-review 处理代码审查。前者要求在关键阶段主动请求审查，后者要求收到反馈后先理解、验证、评估，再决定是否实现。外部 reviewer 的意见不是命令，必须看它是否符合当前代码库和需求边界。

verification-before-completion 是完成声明前的证据门禁。它要求 Agent 在说“完成了”“修好了”“测试通过”之前，必须运行能证明这个结论的命令，并读取完整输出和退出码。

2.5 收尾与扩展：把工作闭环

finishing-a-development-branch 负责分支收尾。它会先运行测试，测试失败就停止。通过后再给出本地合并、创建 PR、保留分支、丢弃工作四种选项。

dispatching-parallel-agents 用于多个相互独立的问题。例如多个测试文件因不同原因失败，可以一域一 Agent 并发调查，最后统一回收结果并跑完整验证。

writing-skills 是元技能。它把写 skill 本身也当成 TDD：先设计压力场景，观察没有 skill 时 Agent 怎么失败，再写最小 skill，最后反复测试并补上红线和反例。

3. Superpowers 的设计思想与原则

Superpowers 的核心不是某个单点技巧，而是一组一致的工程原则。

3.1 过程即代码

Superpowers 把 Agent 的工作流程当成可维护的代码。SKILL.md 不是普通说明书，而是会影响模型行为的“过程程序”。它通过触发条件、硬门禁、检查表、红线、反例和审查循环，改变模型默认的冲动行为。

这也是为什么它会强调 skill 也要测试。一个没有被压力测试过的 skill，很可能只是在写给人看的文档，而不是能稳定约束 Agent 的工具。

3.2 先减速，后加速

Superpowers 经常让 Agent 停下来：先问清楚，先写设计，先写测试，先调查根因，先跑验证。

表面看这会降低速度，但它真正减少的是返工。Coding Agent 最浪费时间的地方，往往不是写代码慢，而是写错方向、过度实现、误修 bug、误报完成。

3.3 证据优先

Superpowers 在多个阶段都要求证据：

• 设计要有用户确认的 spec。
• 实现要有失败过的测试。
• 调试要有根因证据。
• 审查要看 diff 和代码，不信实现者自报。
• 完成要有新鲜验证输出。

这套原则可以概括为一句话：不要相信感觉，不要相信自报，运行命令，看结果。

3.4 反合理化

Agent 很擅长给自己找理由跳过流程。比如“这个太简单不用测”“我先实现再补测试”“这次只是原型”“我已经手动验证了”。Superpowers 的 skill 文本里有大量这样的合理化清单，并明确要求遇到这些想法时停下来。

这不是啰嗦，而是对模型行为的针对性防御。它承认 Agent 会绕规则，所以把常见绕法提前堵住。

3.5 YAGNI 与边界控制

Superpowers 不鼓励 Agent “看起来更完整”的发挥。brainstorming 先定义范围，writing-plans 只拆 spec，spec reviewer 会检查多做的功能，receiving-code-review 会对“专业但没人用”的功能做 YAGNI 检查。

这对 Coding Agent 很重要。模型经常把“我能做”误判成“用户需要”。

3.6 上下文隔离

subagent-driven-development 的重点不是多 Agent，而是干净上下文。Controller 不把整个会话历史交给子代理，而是提取当前任务需要的信息。这样能减少上下文污染，也更容易审查每个任务的输出。

4. 真实使用体验与评价

公开评价里，Superpowers 的口碑很分裂，但分裂点很清楚：它适合把 Agent 当工程执行者管理，不适合把 Agent 当一次性代码生成器使用。

4.1 正面体验：让 Agent 更像工程师

在 GitHub README、Claude 插件页和目录站介绍中，Superpowers 通常被描述成一套 agentic development methodology，而不是简单工具。正面评价集中在几个点：

• brainstorming 能逼 Agent 先问清楚需求。
• writing-plans 能减少空泛计划和随意实现。
• TDD、debugging、verification 能减少假完成和猜修。
• subagent-driven-development 更适合长任务和复杂改动。

这些反馈背后有一个共同点：用户不是想让 Agent 更快写一段代码，而是想让 Agent 参与真实项目开发。

4.2 负面体验：流程重、token 成本高

负面反馈也很一致：Superpowers 有时显得太重。

小改动也进入 brainstorming，会让人觉得绕远。TDD 规则很硬，对快速原型不友好。子代理和两层审查会增加 token 消耗。对已经非常明确的任务，用户可能只想让 Agent 直接改，而不是先写 spec 和 plan。

这不是偶然缺陷，而是它的设计取舍。Superpowers 明显偏向长期质量和可验证性，不偏向最快产出。

4.3 适合的用户画像

Superpowers 更适合这些人：

• 把 Coding Agent 当 junior engineer 管理的人。
• 需要 Agent 连续工作较长时间的人。
• 重视测试、审查、可维护性的人。
• 正在处理复杂 feature、重构或 bug 的团队。

它不太适合这些场景：

• 一次性脚本。
• 一两行小改。
• 快速原型。
• 没有测试基础，也不准备补测试的项目。
• 用户不想参与 spec 或 plan 审阅。

4.4 参考资料

• Superpowers GitHub README
• Superpowers 发布文章，Jesse Vincent
• Superpowers Claude 插件页
• OpenSpec 文档
• karpathy-guidelines 来源讨论
• Matt Pocock grill-me skill 摘要
• AIHero grill-me 介绍

5. 同类 Skill / 方法论对比

如果只看“让 Agent 更可靠”这个目标，Superpowers 并不是唯一方案。OpenSpec、gstack、karpathy-guidelines 都解决了相邻问题，但边界不同。

5.1 Superpowers、OpenSpec、gstack、karpathy-guidelines 横向对比

维度	Superpowers	OpenSpec	gstack	karpathy-guidelines
核心定位	Agentic software development 方法论	Spec-Driven Development 规格管理流程	产品工程与浏览器 QA 工具链	轻量 LLM 编码行为准则
主要解决的问题	Agent 跳过设计、测试、调试、审查和验证	需求变更缺少 proposal、delta specs、archive	Web 产品缺少真实浏览器 dogfood、截图和部署验证	LLM 写代码过度复杂、范围扩张、不说明假设
最强场景	复杂 feature、重构、长任务、多 Agent 执行	需求演进频繁、需要维护规格源头的项目	Web 应用 QA、设计审查、上线前验证、canary	日常小改、代码审查、控制 Agent 不要过度发挥
短板	流程重，token 成本高，小任务显得繁琐	对实现纪律约束较弱，不覆盖完整 TDD/调试/审查闭环	体系大，状态和配置更多，学习成本高	原则轻，不提供完整 spec、plan、subagent 流程
适合谁用	想把 Agent 当工程执行者管理的团队	想让需求和规格可追踪的团队	做 Web 产品、重视真实用户路径验证的团队	想低成本减少 LLM 编码坏习惯的个人或团队
和 Superpowers 的关系	主体方法论	可补充需求规格管理	可补充浏览器 QA 和发布验证	可作为轻量纪律层或小任务替代方案

这四者不是简单替代关系。OpenSpec 管“需求和规格怎么演进”，gstack 管“产品是否真的可用”，karpathy-guidelines 管“Agent 写代码时别犯常见错”，Superpowers 管“Agent 从设计到交付的完整工程流程”。

如果要组合使用，一个合理顺序是：

1. 用 OpenSpec 管重要需求变更。
2. 用 Superpowers 把需求推进到实现、测试、审查。
3. 用 gstack 做真实浏览器 QA 和发布验证。
4. 用 karpathy-guidelines 作为轻量日常约束。

5.2 Superpowers brainstorming vs GrillMeSkill / grill-me

Superpowers 里和软件设计最直接相关的是 brainstorming。它经常会被拿来和 Matt Pocock 的 grill-me 比较。两者都发生在写代码之前，但解决的问题不同。

brainstorming 是完整的软件设计流程：从粗略想法出发，探索上下文，澄清需求，提出方案，分段确认设计，最后写成 spec，并衔接后续 writing-plans。

grill-me 更像高压设计访谈。它会围绕已有计划或设计，一次只问一个问题，沿着决策树追问隐藏假设、风险、依赖和边界。它的强项不是把流程走完，而是把模糊方案里的弱点逼出来。

维度	Superpowers brainstorming	GrillMeSkill / grill-me
核心目标	从想法推进到可批准的设计 spec	压力测试已有想法、方案或计划
交互方式	上下文探索、澄清问题、方案比较、分段确认	一问一答，持续追问假设、依赖和风险
输出物	正式设计文档，并衔接实施计划	更清晰的决策、风险、开放问题和推荐答案
最强场景	用户只有粗略想法，需要从 0 到设计	用户已有 PRD、技术方案或计划，想找人挑战
短板	流程更重，小需求也会要求设计批准	不负责后续计划、TDD、worktree、审查和完成验证
最佳用法	作为 Superpowers 主流程第一站	作为设计压力测试插入 brainstorming 前后

两者可以组合使用：先用 grill-me 把方案里的薄弱点问出来，再用 Superpowers brainstorming 把结论整理成正式 spec，最后进入 writing-plans。这样既有高压追问的深度，也有工程闭环。

6. 总结与适用建议

Superpowers 的价值不是“多了一堆提示词”，而是把 Agentic Coding 中最容易失控的环节流程化：

• 不清楚需求就不实现。
• 没有设计批准就不写代码。
• 没有计划就不执行。
• 没有失败测试就不写生产代码。
• 没有根因就不修 bug。
• 没有审查就不进入下一步。
• 没有验证证据就不说完成。

如果你的目标是快速生成一段代码，Superpowers 可能显得重。如果你的目标是让 Coding Agent 稳定参与真实项目开发，它的流程约束正是价值所在。

实践上，不必一开始就全量采用。可以先从 verification-before-completion 和 systematic-debugging 开始，解决误报完成和猜修问题；再在新功能上使用 brainstorming 和 writing-plans；最后在复杂任务上引入 subagent-driven-development。

软件设计类 skill 的核心价值，不是让 Agent 看起来更聪明，而是让它在关键节点停下来，像工程师一样工作。