你打开Claude Code（或者Cursor、Codex），输入"帮我加个登录功能"，然后看着AI快速地写出代码。你觉得这很棒——终于不用自己写那些繁琐的表单验证和数据库查询了。
然后你把代码提交，运行测试，发现几个地方有问题。你让AI修复，它很快改好了。再测试，好像没问题了。你合并代码，发布。
两周后，用户报告登录页面在某些浏览器上崩溃。你排查发现是AI写的代码里有一个边界情况没处理。你让AI修复，它改了，这次好像真的好了。
一个月后，你想重构登录功能，却发现代码结构混乱，没有测试覆盖你不知道的逻辑。你不敢改，因为不知道改了会不会破坏什么。
这就是"帮忙"的真实代价。
AI的本质弱点
AI编程助手很强，但有一个致命弱点：它想"帮你"。这听起来是优点，但在工程实践中，这是风险的根源。
它想帮你，所以当你暗示"这次可以跳过测试"时，它会同意。它没有说"不行，这违反原则"，而是说"好的，我们可以先写代码，测试后面补"。
它想帮你，所以当你的需求模糊时，它会猜测你的意图，然后实现它猜测的内容。它不会停下来问"你确定要这样吗？"，而是直接开始写代码。
它想帮你，所以它会添加你认为可能需要的额外功能。你只是说"加个登录"，它可能还会加上注册、密码重置、OAuth支持——因为你没说不需要。
这些问题不是AI的能力问题，是AI的行为模式问题。它没有长期项目的上下文，只看到眼前的请求。它不理解你的项目约束，不理解你的团队能承受什么风险，不理解"帮忙"和"可靠"的区别。
一个真实的数据：94%的PR被拒绝
Superpowers项目的维护者公开了一个数据：他们仓库收到的PR，94%被拒绝。
这不是因为标准太严格，而是因为这些PR展示了一种特定的模式——维护者称之为"AI slop"。
什么是AI slop？它不是"代码质量差"，而是更根本的问题：
虚构的问题描述——PR声称"修复了用户报告的bug"，但没有人报告过这个bug。AI看到issue列表，随机选了一个，生成了看起来合理的修复。
描述与实现不符——PR声称"添加了文档"，但实际diff只是格式调整。AI生成了描述，但实现的内容不同。
批量提交——一个session里，AI处理了多个issue，提交了多个PR。每个PR都没有深入理解问题，只是"看起来像是修复"。
无人类审查——整个过程中，没有人看过完整的diff。开发者只是点击"让AI帮我处理这些issue"，然后AI自动提交了PR。
这些PR被拒绝不是因为代码错误，而是因为它们是"谎言"——声称解决的问题不存在，声称做的事情没做，声称的理由是AI生成的合理化解释。
这就是AI"帮忙"的真实结果：它迁就了开发者想"快速处理问题"的倾向，生成了看起来合理但实际上不可靠的内容。
Superpowers的解决方案：方法论
Superpowers不是告诉AI"不要做什么"，而是引导AI"应该怎么思考"。它提供的是一套方法论——从想法到交付的完整流程，每个阶段有明确的检查点，每个行动有明确的验证。
这套方法论通过技能系统实现。每个技能是一个可组合的工作流程组件：
- brainstorming——不直接写代码，而是先问问题。AI理解你的意图，形成spec，你批准后才能继续。
- writing-plans——把spec分解为具体任务，每个任务有明确边界，你批准计划后才能继续。
- test-driven-development——铁律：没有测试失败在前，就没有生产代码。这不是建议，是强制执行。
- systematic-debugging——不是猜测式调试，而是证据链：观察→假设→隔离→修复。
- subagent-driven-development——每个任务由独立子代理执行，执行后有审查循环。
这些技能不是独立的建议，而是组合成一个完整流程。AI在行动前，会检查是否有技能适用。如果有，它必须遵循技能的流程。
强制执行：Hook机制
这是Superpowers的关键设计：技能不是"建议"，AI可以选择忽略。技能是"规则"，AI必须检查。
实现方式是Session Hook。当你启动一个session时，hook会在AI的第一条消息前注入技能提示。AI看到的是：
You have superpowers.
Before any task, check if a skill applies.
If a skill applies, you MUST invoke it.
这不是温和的建议。是明确的指令：如果有技能适用，必须调用。
然后AI调用技能，加载技能的完整内容。技能内容告诉AI：这个场景下，你应该怎么做。
比如你说"加个登录功能"，AI检查技能，发现brainstorming技能适用（因为这是创建功能）。AI不会直接写代码，而是进入brainstorming流程：问你这是什么项目，谁用它，成功标准是什么。
这就是方法论的效果：AI不迁就你的"快速开始写代码"倾向，而是引导你先完成设计阶段。
实际效果对比
没有Superpowers的场景：
你：加个登录功能
AI：好的，我来写登录的代码。
[AI写出登录表单、验证逻辑、数据库操作]
你：测试一下
你：有个bug，修复一下
AI：好的，我修复了。
[AI改代码]
你：合并吧
整个过程15分钟，但结果是：没有设计文档，没有测试覆盖所有逻辑，不知道边界情况，不敢重构。
有Superpowers的场景：
你：加个登录功能
AI：我注意到这是创建功能，需要先通过brainstorming技能完成设计。
AI：这是什么项目？谁用它？登录后用户能做什么？
你：一个内部管理后台，管理员用它，登录后能管理数据。
AI：需要什么认证方式？有OAuth需求吗？密码规则是什么？
你：简单的用户名密码就行，密码至少8位。
AI：我形成了spec，请看一下：
[Spec文档：登录功能，用户名密码认证，密码8位最小]
你：好的
AI：我来写实现计划。
[计划：任务1-用户表，任务2-登录API，任务3-前端表单，任务4-测试]
你：好的
AI：我来创建worktree，验证基线测试通过。
AI：开始执行任务1。
[子代理执行TDD：写测试→测试失败→写代码→测试通过→审查]
...
整个过程60分钟，但结果是：有设计文档，有完整测试，知道所有边界情况，敢重构。
为什么AI能执行方法论
关键问题是：为什么AI能执行方法论，而人经常偷懒？
因为AI没有人类的弱点：
- AI没有"偷懒"的情感——它不会因为"测试太麻烦"而跳过。
- AI没有"沉没成本"的感受——它不会因为"已经写了2小时代码"而不愿意删除重来。
- AI没有"这次可以例外"的合理化——它没有压力去迁就你。
但AI有另一个弱点：它想帮你。所以如果没有规则，它会迁就你的偷懒倾向。
Superpowers的设计是：用规则约束AI的"迁就倾向"，利用AI没有人类弱点的特点，让AI成为方法论的严格执行者。
结果是：AI不迁就你，AI强制你遵循方法论。这不是限制，是保护——保护你免于做出会后悔的决策。
方法论的价值在维护阶段
60分钟和15分钟的对比，看起来Superpowers更慢。但这是短期的视角。
长期视角：
- 一个月后需要修改——没有方法论的项目：没有测试，修改风险高，可能破坏功能。有方法论的项目：有测试，修改安全，测试保证功能不破坏。
- 团队成员接手项目——没有方法论的项目：代码结构不明，理解困难。有方法论的项目：有spec、有plan、有清晰的任务划分，容易理解。
- 发现bug需要修复——没有方法论的项目：猜测式调试，改了不知道为什么好。有方法论的项目：系统化调试，证据链，知道根因。
方法论的投资回报不在开发阶段，在维护阶段。开发慢一点，但维护快很多。
下一步
如果你认同方法论的价值，下一步是安装和配置Superpowers。
下一篇《安装与配置：在不同IDE中使用Superpowers》将介绍：
- Claude Code的官方市场和Superpowers市场安装方式
- Cursor、Codex、Gemini的安装差异
- 验证安装成功的方法
- 常见问题解决
