今天很多人使用 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只拆 specspec 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 READMESuperpowers 发布文章Jesse VincentSuperpowers 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 横向对比维度SuperpowersOpenSpecgstackkarpathy-guidelines核心定位Agentic software development 方法论Spec-Driven Development 规格管理流程产品工程与浏览器 QA 工具链轻量 LLM 编码行为准则主要解决的问题Agent 跳过设计、测试、调试、审查和验证需求变更缺少 proposal、delta specs、archiveWeb 产品缺少真实浏览器 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 从设计到交付的完整工程流程”。如果要组合使用一个合理顺序是用 OpenSpec 管重要需求变更。用 Superpowers 把需求推进到实现、测试、审查。用 gstack 做真实浏览器 QA 和发布验证。用 karpathy-guidelines 作为轻量日常约束。5.2 Superpowersbrainstormingvs GrillMeSkill /grill-meSuperpowers 里和软件设计最直接相关的是brainstorming。它经常会被拿来和 Matt Pocock 的grill-me比较。两者都发生在写代码之前但解决的问题不同。brainstorming是完整的软件设计流程从粗略想法出发探索上下文澄清需求提出方案分段确认设计最后写成 spec并衔接后续writing-plans。grill-me更像高压设计访谈。它会围绕已有计划或设计一次只问一个问题沿着决策树追问隐藏假设、风险、依赖和边界。它的强项不是把流程走完而是把模糊方案里的弱点逼出来。维度SuperpowersbrainstormingGrillMeSkill /grill-me核心目标从想法推进到可批准的设计 spec压力测试已有想法、方案或计划交互方式上下文探索、澄清问题、方案比较、分段确认一问一答持续追问假设、依赖和风险输出物正式设计文档并衔接实施计划更清晰的决策、风险、开放问题和推荐答案最强场景用户只有粗略想法需要从 0 到设计用户已有 PRD、技术方案或计划想找人挑战短板流程更重小需求也会要求设计批准不负责后续计划、TDD、worktree、审查和完成验证最佳用法作为 Superpowers 主流程第一站作为设计压力测试插入 brainstorming 前后两者可以组合使用先用grill-me把方案里的薄弱点问出来再用 Superpowersbrainstorming把结论整理成正式 spec最后进入writing-plans。这样既有高压追问的深度也有工程闭环。6. 总结与适用建议Superpowers 的价值不是“多了一堆提示词”而是把 Agentic Coding 中最容易失控的环节流程化不清楚需求就不实现。没有设计批准就不写代码。没有计划就不执行。没有失败测试就不写生产代码。没有根因就不修 bug。没有审查就不进入下一步。没有验证证据就不说完成。如果你的目标是快速生成一段代码Superpowers 可能显得重。如果你的目标是让 Coding Agent 稳定参与真实项目开发它的流程约束正是价值所在。实践上不必一开始就全量采用。可以先从verification-before-completion和systematic-debugging开始解决误报完成和猜修问题再在新功能上使用brainstorming和writing-plans最后在复杂任务上引入subagent-driven-development。软件设计类 skill 的核心价值不是让 Agent 看起来更聪明而是让它在关键节点停下来像工程师一样工作。