Superpowers Skill - 让 Claude Code 和 Codex 按工程流程做开发

Superpowers Skill 的核心价值，不是给 AI 增加某个单点功能，而是把需求澄清、方案设计、TDD、调试、代码审查和完成前验证这些工程动作固化成可复用流程。本文基于 Superpowers 与 Startup Superpowers 的素材，拆解 Skill 是什么、适合哪些开发场景、使用和不使用的差别，以及在 Claude Code 和 Codex 中如何落地。先说结论：Skill 不是提示词，而是“流程约束”最近看 Superpowers 相关资料时，我觉得最值得关注的不是它有多少个具体 skill，而是它试图解决一个很现实的问题：AI coding agent 很容易“会写代码，但不一定按工程流程做事”。你让它修 bug，它可能马上读文件、猜原因、改代码。你让它做功能，它可能直接开干，等写完才发现需求理解偏了。你让它重构，它可能顺手改了一堆相邻代码，最后风险比收益还大。这不是模型“不会写代码”，而是软件开发本身需要流程纪律：先弄清楚目标，而不是马上实现。先形成可验证计划，而不是边写边想。修 bug 要追根因，而不是猜一个补丁。新功能要尽量测试先行，而不是完成后补测。宣布完成前要验证，而不是凭感觉说“应该好了”。Superpowers Skill 做的事情，就是把这些流程变成一组可加载、可组合、可复用的 agent 操作规程。它不是让 AI “更聪明”，而是让 AI 更像一个被流程约束住的工程师。Superpowers 是什么？从官方项目描述看，Superpowers 是一套面向 coding agents 的软件开发方法论。它建立在一组 composable skills 之上，通过初始指令确保 agent 在合适场景下调用这些 skills。换成更工程化的说法：Superpowers = 一套把“软件工程最佳实践”编码成 agent 工作流的 skill 框架。它的基本思路不是“给模型一段更长的提示词”，而是把不同任务拆成不同 skill：Skill解决的问题核心产出brainstorming需求还不清楚，不能马上写代码经过澄清的设计方向writing-plans方案需要落成可执行步骤带文件路径、任务拆分和验证方式的计划test-driven-development新功能或修复需要测试约束RED-GREEN-REFACTOR 循环systematic-debuggingbug 不能靠猜根因假设、逐步验证、最小修复verification-before-completion完成不能只靠口头声明实际运行、测试、浏览器或设备验证requesting-code-review提交前需要找风险按严重程度排列的问题清单using-git-worktrees多任务并行需要隔离独立工作区和干净基线这些 skill 组合起来，覆盖了从需求讨论到最终收尾的完整开发链路。Skill 到底是干嘛用的？如果只看表面，Skill 像是一份说明书：什么时候该做什么，先做哪一步，验证什么结果。但在 AI agent 场景里，它的作用更具体：1. 把“怎么做”从对话里抽离出来普通使用方式下，用户每次都要提醒：先别急着写代码。先分析一下方案。写测试。不要大范围重构。改完记得跑测试。这很累，而且用户一旦忘记提醒，agent 就可能退回默认行为。Skill 的意义是把这类重复约束沉淀下来。用户只需要说“修这个 bug”或者“实现这个功能”，agent 根据任务类型加载对应 skill，自动进入调试流程、TDD 流程或计划流程。也就是说：没有 Skill：用户反复教 agent 怎么做。有 Skill：用户只描述要做什么，Skill 约束 agent 怎么做。2. 降低 agent 的“即兴发挥”AI 写代码的一个常见问题是行动太快。它可以很流畅地解释、实现、补丁、总结，但流畅不等于正确。Superpowers 的核心约束是把 agent 从“直接写代码”拉回“先走流程”：粗略需求 ↓brainstorming 澄清目标 ↓writing-plans 拆成可执行任务 ↓test-driven-development 约束实现 ↓requesting-code-review 检查风险 ↓verification-before-completion 完成前验证这条链路看起来慢，但它解决的是复杂项目里最昂贵的问题：方向错、边界错、验证缺失、回归没人发现。3. 让流程跨会话保持一致单次对话里，你可以给 agent 很长的系统提示。但真实项目往往跨很多天、很多会话。Skill 的价值在于：每次会话都能重新加载最新流程。同一类任务走同一套标准。团队可以把流程写进仓库或插件，而不是散落在聊天记录里。这对长期项目很重要。软件项目真正麻烦的地方往往不是某一段代码，而是“今天、明天、下周再回来时，大家是否仍然按同一套工程纪律做事”。使用场景：什么时候值得用 Superpowers Skill？不是所有任务都需要重流程。问一个命令、查一个小配置、改一个明显 typo，直接做就可以。Superpowers 更适合这些场景。场景一：新功能开发典型输入：帮我给这个项目加一个会员订阅功能。没有 skill 时，agent 很可能马上找文件、写 UI、补 API、加状态字段。问题是：会员能力涉及支付、权限、状态同步、失败回滚、测试和上线风险，不适合直接开写。使用 Superpowers 后，合理流程应该是：brainstorming：先澄清功能边界，比如套餐、试用、退款、权限降级。writing-plans：拆出数据结构、接口、UI、测试、验收步骤。test-driven-development