你有没有发现：AI 编程助手越来越聪明，但用起来反而越来越累？
读完本文你将了解：Superpowers 的技能触发机制 | 子 Agent 驱动开发流程 | 为什么 94% 的 PR 被拒 | 适合什么场景
🎯 这个项目解决什么问题？
上周我跟一个朋友聊，他说现在用 AI 写代码最大的矛盾是：Agent 太勤快了，勤快得让人害怕。
你随口说一句"帮我写个用户登录功能"，它不问任何前置条件，三秒就甩给你一套完整代码——数据库 Schema、JWT 中间件、登录页面一套全了。看起来爽，跑起来就炸。因为你的服务用的不是 JWT 是 Session，你的数据库是 PostgreSQL 不是 MySQL，你的页面框架是 Vue 不是 React。Agent 全猜错了。
这就是当前 AI 编程助手的核心问题：它们默认"你的需求就是它理解的那样"，而不是先确认你到底要什么。你改需求时它不检查影响范围，你让它写代码它不写测试，你让它重构它直接改核心文件——像个刚毕业的实习生，能跑但不可靠。
Superpowers 的做法是给 Agent 装一套自动触发的软件工程方法论。它不是让你去学新概念，而是让你的 Agent 自己学会在写代码之前先停下来思考、先弄清需求、先做设计评审。它默认"Agent 没有品味、没有判断力、没有项目上下文"，然后通过 14 个自动触发技能把这些能力补上。
简单说：装上 Superpowers，Agent 从"你让我写我就写"变成了"我先帮你搞清到底要写什么"。
🔧 快速上手
安装
取决于你用什么 Agent 平台。以最常用的 Claude Code 为例，一行命令：
/plugininstallsuperpowers@claude-plugins-official如果从社区市场安装：
/plugin marketplaceaddobra/superpowers-marketplace /plugininstallsuperpowers@superpowers-marketplaceCodex、Cursor、Gemini CLI 各有对应的安装方式（见项目 README），本质上都是一个插件注册的动作。
最简使用
装完不需要任何配置。下次你跟 Agent 说话时，Superpowers 会自动触发。
试试这个对话：
我：帮我做一个个人博客系统 Agent：先等一下——你想用这个博客做什么？是技术写作还是照片展示？ 有偏好的技术栈吗？需要 CMS 后台还是纯静态生成？Agent 不再直接甩代码，而是先进入需求澄清阶段（brainstorming 技能自动触发）。它会一条一条问你，直到把需求磨清楚，然后给你一份设计文档让你审批。
预期效果
设计阶段（brainstorming） ├── 探索项目上下文（检查已有文件、最近 commit） ├── 逐条提问（意图、技术约束、成功标准） ├── 提出 2-3 个方案对比 ├── 展示设计文档（分段展示，逐段确认） └── 保存到 docs/superpowers/specs/ 目录 实现阶段（writing-plans → subagent-driven-development） ├── 生成可执行的任务清单（2-5 分钟粒度） ├── 每个任务独立子 Agent 执行 ├── 每个任务执行后：规格审查 + 代码质量审查 └── 自动提交，不停就继续⚠️ 如果 Agent 没有按这个流程走，检查一下插件是否成功安装。
⚙️ 技术原理
Superpowers 的核心洞察只有一个：Agent 的行为由它看到的指令决定，而不是它的能力。所以 Superpowers 做的事情并非提升 Agent 的推理能力——它只是在恰当的时间点，把正确的指令插入到 Agent 的上下文中。
为什么是"技能自动触发"而不是"提示词集合"？
早期做 AI Agent 提升的人都走同一条路：写一个超级详细的 system prompt，把所有方法论塞进去。这条路很快撞墙——上下文越长，Agent 的实际遵循度反而越低。
Superpowers 选的是条件触发 + 上下文隔离路线：
如果 "用户提出新功能需求" → 加载 brainstorming 技能 如果 "brainstorming 完成并审批" → 加载 writing-plans 技能 如果 "有可执行计划" → 加载 subagent-driven-development 技能每个技能只在需要时才被加载，用完就退出上下文。Agent 的注意力始终保持聚焦，不会因为"看到太多指令"反而漏掉关键规则。
这个设计的代价是：你需要一套状态机机制来管理技能之间的跳转。Superpowers 的实现方式是让每个技能的 SKILL.md 中显式声明触发条件和出口条件——上一个技能执行完，自然触发下一个。14 个技能形成一个有向图，每个节点知道自己的前驱和后继。
子 Agent 驱动的双审机制
subagent-driven-development 是 Superpowers 最精妙的部分。它不光让 Agent 把任务分发出去——每个任务完成后还要过两道审查：
- 规格审查（spec-reviewer）：子 Agent 产出的代码是否符合设计文档的规格？
- 代码质量审查（code-quality-reviewer）：代码可读性、测试覆盖、边界情况。
审不过就打回重做，过了才进下一个任务。这套流程模仿的是 Google 的代码审查文化——人工审查的质量上限就是双审制，因为不同的人会注意不同的问题。Superpowers 用两个独立的子 Agent 分别扮演这两个角色，审查视角不会重叠。
🏗️ 架构分析
模块划分
| 模块 | 职责 |
|---|---|
| skills/ | 14 个可触发技能，每个独立成一目录，有自己的 SKILL.md |
| hooks/ | Shell 层面的钩子，在会话开始时加载环境 |
| CLAUDE.md / AGENTS.md | Agent 入口指令，定义"先读这个再干活" |
| 14 skills catalog | 从需求到交付的完整技能链 |
每个 skill 目录下包含 SKILL.md（触发条件 + 行为描述）和辅助文件（审查 prompt、可视化指南等）。结构极度扁平，没有复杂依赖——这也是设计意图：每个技能可被独立理解、独立替换。
设计亮点
"反向"质量门：默认拒绝而不是默认通过。
Superpowers 对 Agent 的行为预设是"你不知道怎么干"，而不是"你会干"。每个技能里都有<HARD-GATE>标记——在特定条件下强制执行门禁检查：
- brainstorming：在用户审批设计前，禁止任何代码实现
- subagent-driven-development：在执行下一个任务前，必须先过审查
- test-driven-development：在实现前必须先写失败测试
这不是"建议"，是硬编码在技能指令中的行为约束。
不够好的地方
Superpowers 的 14 个技能是一个有向流程链，不是灵活的网状图。如果你的工作流跟标准路径不同（比如你不需要 TDD，或者你的项目已经在 clean baseline 上），部分技能反而会成为"卡住流程的面子工程"。目前项目没有提供"跳过某技能"的机制。
✅ 优缺点 & 适用场景
优点
- 自动触发，零学习成本：装上就行，不需要你学会用
- 子 Agent 驱动 + 双审机制：质量控制的自动化程度远超单一 Agent
- 平台无关：同一套技能在 Claude Code、Codex、Cursor、Gemini CLI 上都能用
缺点
- 流程强制性太强：不适合快速原型或实验性项目，每个步骤都要走完
- 上下文消耗大：每个子 Agent 启动都占用 token，小项目（<5 个文件）反而比直接写更慢
适合谁
- 立刻试试：用 Claude Code 做多文件项目开发的团队；对代码质量有要求但没钱做人工 Review 的独立开发者
- 再等等：如果你的项目是个人玩具或少于 10 个文件的手笔，Superpowers 的重流程会让你觉得慢得想放弃。直接手写更快
竞品一句话
跟 Cursor Rules 或自定义 System Prompt 比，Superpowers 的独特之处是不依赖你写提示词的能力——全是预写好的方法论。代价是灵活性低：你想改流程就得 fork 整个 repo。
