它到底是什么本质上是一个可组合的 Skill 执行器大多数人第一次听说 Superpowers以为是某种 Claude 的 fine-tune 版本或者是一个专属的 Agent 框架。都不是。Superpowers 的全部实现就是一套 SKILL.md 文件。每个 SKILL.md 文件就是一套流程规范用 Markdown 写成任何人打开都能读懂。整个框架没有自己的运行时不锁定模型不依赖私有 API——它本质上是一套编码进文本的工程方法论。当前版本包含 14 个核心技能分三类开发流程类brainstorming需求澄清、writing-plans任务拆解、executing-plans计划执行、subagent-driven-development子 Agent 并行、using-git-worktrees工作区隔离、finishing-a-development-branch分支收尾质量保证类test-driven-developmentTDD 强制执行、requesting-code-review发起代码评审、receiving-code-review处理评审意见、verification-before-completion完成前验证调试与元技能类systematic-debugging系统化调试、writing-skills编写新 Skill、using-superpowersSuperpowers 激活恢复、dispatching-parallel-agents并行 Agent 调度会话启动时框架通过 Claude Code 的 hook 机制注入一个引导文档小于 2000 tokens告诉 Claude 开始任何任务前先读取相关 Skill。这个设计让整个框架极度轻量它不锁定你用哪个模型不需要自己的运行时跨 Claude Code、Cursor、Gemini CLI、GitHub Copilot CLI、Codex CLI 都能工作。这里有个设计取舍值得注意2000 tokens 的引导注入确实很节省上下文——但它带来了一个已知问题。子 Agent 启动时不会自动继承这个上下文注入导致子 Agent 有时会跳过 TDD 这类约束直接开写。框架目前通过 SubagentStart hook 部分缓解这个问题但 v5.1.0 里仍然是已知问题。遇到时手动触发using-superpowersskill 可以把它拉回来。框架完全透明你可以修改任何 Skill 来适配自己团队的规范——这是刻意的设计决策把工程文化编码成文件而不是锁进平台。图Superpowers 的架构本质——14 个可组合的 Markdown Skill 文件通过 Hook 注入到 Agent 会话形成工程约束层7 阶段工作流从「能跑」到「可维护」Superpowers 把软件开发的一次完整迭代拆成 7 个强制阶段。每个阶段对应一个或多个 Skill框架要求不允许跳过。阶段 1Brainstorming需求澄清这不是闲聊是 Socratic 对话。Claude 会主动问这个功能的边界在哪里有哪些已有代码会受影响你接受什么形式的输出边界条件是什么大多数工程师觉得这一步啰嗦想直接开写。但这一步的设计目的很明确让 Claude 在写代码之前先暴露它对需求的假设。我用裸 Claude Code 踩过的坑有 60% 源头都在这一步省掉了——需求没说清楚Claude 就开始猜了而它猜的方向往往会在你不知道的地方和别的模块打架。Brainstorming 就是把这些隐式假设在写代码之前逼出来让你确认或纠正。阶段 2Git Worktree 隔离在写任何代码之前先建一个干净的 worktree 分支。这不是噱头是防止 Claude 在主分支上做试验性修改污染你的工作区。生产环境里吃过Claude 顺手改了三个文件然后功能坏了这种亏的工程师会明白这一步的价值。v5.1.0 对 worktree skill 做了重写加入了环境检测和基于同意的工作区创建逻辑比之前的版本更稳。阶段 3Writing Plans任务分解把设计分解成 2-5 分钟的原子任务每个任务有明确的文件路径、预期改动、验证步骤。这一步的输出是一份计划文档你需要 review 并确认。这里有个反直觉的建议不要让 Claude 在写完计划之后立刻开始执行。新开一个会话再执行计划防止写计划时累积的上下文污染执行阶段的判断。这是社区里很多重度用户总结出来的框架文档本身也提到了。阶段 4Subagent-Driven Development子 Agent 并行执行这是 Superpowers 架构里最关键的设计。每个原子任务派给一个全新的子 Agent子 Agent 只知道自己这一个任务的上下文执行完报告结果给协调 Agent。背后的逻辑是长时间运行的单一 Agent 上下文会腐化——随着对话轮数增加早期假设会被忘记新的错误会越来越难发现。新鲜子 Agent 的上下文是干净的判断也是干净的。这是 Superpowers 最核心的工程假设也是它和裸 Claude Code 在长周期开发上差距最大的地方。阶段 5TDD测试驱动这是整个框架最暴力的一环。规则只有一条没有失败的测试就没有实现代码。不是尽量先写测试不是写完再补测试是字面意义上的——如果发现子 Agent 在没有失败测试的情况下写了实现代码Superpowers 要求删掉那段代码回到测试先行的状态。RED → GREEN → REFACTOR循环不跳步。阶段 6Code Review代码评审任务之间穿插代码评审发现 critical 级别的问题会阻断后续任务。这里的critical有明确定义逻辑错误、安全漏洞、与 spec 不符——不是风格问题。v5.1.0 对 code review 做了整合去掉了命名 Agent 的方式改为更简洁的自包含模板减少了角色混乱的问题。阶段 7Branch Finishing分支收尾给你四个选项合并到主分支 / 创建 PR / 保留分支 / 丢弃分支。这一步强制你对这次迭代的结果做一个明确的决策而不是先放着。TDD 强制化的背后AI 写代码为什么不加测试会出问题这是很多人觉得「TDD 感觉没必要」的地方我想多说几句因为 AI 场景和人类写代码的场景有本质区别。人类工程师跳过测试写代码通常是偷懒但他脑子里还存着这段代码应该对什么负责的隐式知识。他之后补测试的时候大概率还记得那些边界条件。这是人类的记忆系统在发挥作用。AI 写代码没有这个隐式记忆。Claude 生成的代码是当前上下文的最优解。但当前上下文不等于完整需求。测试是一种合约——测试逼着你在写实现之前把这段代码要保证什么显式地写出来。这个合约用机器可以验证的方式存在于代码库里。没有这个合约Claude 在两周后面对新需求时不知道那个合约存在它可能会完全合理地违反它。我见过最典型的例子一个负责订单状态流转的模块用裸 Claude Code 写的跑了三周没问题。然后加了一个退款逻辑Claude 顺手重构了状态机把一个边界状态合并了——因为在新的上下文里那个状态看起来多余。那个状态是处理异常支付渠道的生产上有 0.3% 的概率触发。没有测试覆盖悄悄坏掉了上线之后客服系统才报警。这不是模型的 bug是系统设计层面的架构隐患。上下文无记忆的 AI 在长周期迭代中天然会侵蚀没有显式约束覆盖的代码区域。有数据支撑这一点。chardetPython 字符编码检测库的维护者用 Superpowers 重写了 v7.0.0跑完 2161 个测试文件、覆盖 99 种编码最终性能提升 41 倍准确率从 94.5% 提升到 96.8%。这个数字的来源不是 Superpowers 有什么神奇算法而是 TDD 强制执行后每次代码变动都必须先有失败测试通过才能保留意味着 Claude 可以大胆重构——因为回归测试会立刻捕获所有破坏。这是 TDD 在 AI 写代码场景下的核心价值让激进优化变得安全。Superpowers 把测试覆盖目标设在 85-95%不是有测试就行。这个数字不是拍脑袋定的——低于 80% 的覆盖率在第二次迭代时 regression 的概率会显著上升高于 95% 的覆盖率写测试的时间投入超过了收益。85-95% 是经验数值上的合理区间。TDD 强制化是在 AI 写代码的场景里对上下文无记忆这个根本问题的系统性解法。图Superpowers 强制 TDD 循环的执行逻辑——代码先于测试存在时框架要求删除实现代码重来