给 AI 超能力：Superpowers Skill 入门
如果你用过 AI 写代码，大概都遇过这种情况：
你讲一长串需求，AI 兴致勃勃说「好，我写好了」，结果一跑——根本不能用，或者修一个 bug 又制造三个新的 bug。AI 看起来很聪明，但总给人一种：技术很强，态度很随便 的感觉。
Superpowers 这套东西，就是专门来治 AI 这个「没纪律的天才」的。
Superpowers 是什么？不是代码库，是「AI 员工手册」
很多人第一眼以为 Superpowers 是一个框架或套件，其实不是。
它更像是一本写给 AI Agent 的 「员工手册」，告诉它：在不同阶段，必须按什么流程做事。
它放在 GitHub 上，有单独的 skills 仓库
superpowers-skills，里面是一份份 Markdown 文档。每一份文档叫一个 Skill，描述「在某种情境下，你（AI）必须怎么做」。
再配合 Claude Code 的插件，把这些规则接到 AI 的日常对话和写码流程里。
一句话：
Superpowers 用一堆 skills，把 AI 从「会写代码的实习生」，训练成「有职业素养的工程师」。
核心概念：用 15 个 Skills，管住 AI 的开发流程
作者把完整的软件开发流程拆成一系列技能：从「先问清楚需求」到「最后合并分支」，每一步都有对应的 skill 来约束 AI。
你可以想象一条典型流程大概是这样：
brainstorming：先问清楚需求，设计方案。writing-plans：写一份「傻瓜也能照做」的执行计划。test-driven-development：严格 TDD，先写测试，再写代码。systematic-debugging：出 bug 时，禁止乱猜，只能按步骤查根因。subagent-driven-development：交给子代理写代码＋做双重 code review。verification-before-completion：任何「完成了」的宣称之前，必须先跑验证。receiving-code-review、writing-skills等负责审查、写新 skill 的规则。
下面挑几条最有趣、对非工程师也看得懂的 skill 来讲。
Skill 示例一：brainstorming —— AI 先当个好提问者
痛点：
AI 很爱「没问完就开写」，结果写错方向，你改来改去，还不如自己写。
brainstorming 这个 skill 强制 AI 在动手前，必须先用「苏格拉底式提问」把需求问清楚：
一次只问一个问题，不准一口气丢十个。
能用选择题就不用开放式问题。
设计方案要分段写，每段结束都要问你「这样对吗？」再继续。
想象一个对话：
你：我要做一个「会议纪要自动整理」的小工具。
AI（用 brainstorming skill）：
你习惯用哪种工具开会录音？（Zoom 录音 / 语音档上传 / 文字逐字稿）
你要输出的是「条列重点」还是「完整摘要」？
这个工具是你自己用，还是整个团队都会用？
…
问完一轮，它再写一份 200～300 字的小设计书，最后问你：
「以上理解是否正确？如果有误，请指出，我会重新修正设计。」
这一步看起来慢，实际上帮你省掉大量「做了才发现方向错了」的返工。
Skill 示例二：writing-plans —— 假设执行者「什么都不懂」
writing-plans 是很多人看了会惊呼「也太啰嗦了吧」的 skill。
它有一个很残酷的前提：
假设执行这份计划的人：
对专案一无所知
品味普通
不喜欢写测试
所以计划必须写到「连这样的人照做也不会出大事」。
这份 plan 会怎么写？大概是这种感觉：
每个步骤只做一件事，2～5 分钟能完成。
不准写「加上适当的测试」，要写出完整测试代码和文件路径。
不准写「跑一下测试」，要写出具体指令（例如
npm test）和预期输出长什么样。
举个极简版例子（真实 skill 会更细）：
在
src/meeting_summary.ts新增summarizeTranscript函数，内容如下：…代码…在
tests/meeting_summary.test.ts新增测试，内容如下：…代码…在终端执行
npm test meeting_summary.test.ts，确认有 1 个新测试通过、0 失败。
这样的计划有点像是：
把「高级工程师脑中的隐性经验」，全部摊开放进文件里。
好处是：你可以把一个任务，放心交给「一个不认识的 subagent」或「下一次新开的 AI session」，它照计划走也不会迷路。
Skill 示例三：test-driven-development —— 没有失败测试，就不准写代码
Superpowers 里最「凶」的一条，就是 test-driven-development。
它写得非常直白：
「没有先写测试，就不准写 production code。」
并且把各种常见的偷懒理由全部预先堵死，例如：
觉得功能太简单，不想写测试？——简单的代码也会出错，写测试只要几十秒。
说「我先手动测过」？——手动测试没记录、不能重跑。
已经先写了代码再补测试？——对不起，要把那段代码删掉，当没发生，重新来过。
这背后是典型的 TDD 循环：
先写一个会失败的测试（Red）。
运行确认它真的失败。
写最小的代码让测试通过（Green）。
再重构，让代码变干净。
对你有什么启发？
即使你不是工程师，也可以学到一个思路：
在「动手做」之前，先明确「我要如何验证这件事算成功」。
你可以把这个方法用在：写课程大纲、设计工作坊、甚至开新产品——先想清楚，成功的验证标准是什么。
Skill 示例四：systematic-debugging —— 不准瞎猜，只能系统化排查
当系统出 bug 时，很多 AI 会进入「疯狂猜测模式」——改一行试试看、不行再改下一行，浪费大量时间。
systematic-debugging skill 规定：修 bug 要分四个阶段，不能跳步：
根因调查：
把错误讯息读完，而不是只看一眼。
想办法稳定重现问题，不能重现就不准修。
看最近的代码 diff，是不是有可疑变更。
模式分析：
找一段「正常工作的类似代码」，跟有问题的地方对照。
假说与测试：
提出一个具体的假说，一次只改一个点去验证。
实作与防御：
写测试重现问题，再修复。多次修不动，就要怀疑架构本身有问题。
这套流程，其实是把工程师的 debug 经验，转成一份 AI 也看得懂的「标准作业程序」。
你不一定全用，但你可以借 Superpowers 的思路，去写自己的「排错 checklist」。
Skill 示例五：verification-before-completion —— 说「完成」之前，先给证据
很多 AI 有个坏毛病：
「应该没问题了」、「看起来 OK」、「我有信心这次可以」……但实际上根本没跑任何检查。
verification-before-completion 这个 skill 直接说：
「在没有验证证据之前宣称完成，是不诚实，不是有效率。」
它要求 AI：
说「测试都通过了」前，必须实际跑测试，并检查输出、确认 0 失败。
说「build 成功」前，要看命令的 exit code 是否为 0。
说「这个 bug 修好了」前，要重跑当初的复现步骤，确认问题真的消失。
并且给了一套「自查清单」：
证明这项宣称的命令是什么？
刚刚有没有完整跑一次？
输出有没有仔细看？
确认结果真的支撑你的结论了吗？
对我们人类同样适用：
写完一篇文、做完一支视频、上线一个新页面，先问自己：「我真的验证过了吗？」
很有梗的 Skill：如何接 Code Review，还教 AI 用「暗号」
有一个很受讨论的 skill 叫 receiving-code-review，专门教 AI：当你收到别人给的 code review 意见，要怎么回应比较专业。
它明确禁止那种我们常见的客套回应：
「你说得太对了！」
「好棒的建议！」
「我马上照做！」（但其实没验证过）
在这个规则里：
礼貌不是重点，「技术上有没有道理」才是重点。
正确做法是：
先用自己的话，复述对方的技术要求，确认没误解。
用代码和测试来验证这个建议是不是适合当前专案。
如果判断审查者错了，要用技术理由推回去，而不是因为「不好意思」就照单全收。
更有趣的是：
为了防止 AI 在某些「政治敏感」或「职场微妙」的情况下直接顶撞人类，文档里甚至设计了一个暗号句子：
「Strange things are afoot at the Circle K」
这句话本来出自一部老电影，在一般技术对话不太会自然出现，所以一旦看到，就可以理解为：
「我（AI）觉得这里有问题，但现在不方便讲明，你可以认真检查一下。」
很少有技术文档，会教 AI 怎么处理人际关系，这也是 Superpowers 让很多人觉得有趣的地方。
Skill 示例六：writing-skills —— 连「写 Skill」本身，也用 TDD
Superpowers 不只管「写代码」，连「怎么写新的 Skill」也有专门的 skill：writing-skills。
它主张：
写 skill 本身，就是一种「对流程做 TDD」。
流程大概是：
先设计一个高压情境，用 subagent 在没有这个 skill 的情况下执行任务，看它会犯什么错。
针对这些真实发生的问题，写出 skill 文档。
再用同样情境测试一次，这次加载 skill，看 AI 是否遵守。
如果 AI 又绕过了规则，就继续补漏洞、再测一次。
它甚至把这个过程直接和传统 TDD 对上表：
TDD 概念在 Superpowers 里测试案例用 subagent 设计的压力场景生产代码Skill 文档（SKILL.md）测试失败（红）没有 skill 时，AI 乱来测试通过（绿）有 skill 时，AI 按规矩做重构在不破坏规则的前提下，补漏洞、改写 skill
这说明一个重点：
Superpowers 不是凭空想出来的规范，而是从真实 AI 行为中，反复「看它犯错 → 写规则 → 再试一次」打磨出来的。
它厉害在哪里？也有什么限制？
设计上几个很有意思的点
用「必须」而不是「建议」
多数指南写「你应该…」，Superpowers 直接写「你必须…」，甚至写出「违反规则字面意义，就是违反规则精神」，堵住 AI 用「我理解的是精神」来偷懒。大量列出「常见藉口 vs 现实」表格
每条规则后面都会列出 AI 可能说的各种理由，再一一反驳，这其实是在「封堵 AI 找借口的路」。每一步都要求验证
不只结果要验证，连测试本身也要先确认「会失败」，再确认「修完会通过」。
这些做法，让 Superpowers 不只是「一组最佳实践」，更像是「专门针对 AI 思维漏洞做的行为训练。」
现实中的限制
当然，它也不是万能药：
完全依赖 AI 的「自律」
这些都只是文档，没有硬性技术限制，AI 其实可以选择不理会。成本很高
像subagent-driven-development一次任务要开 3 个 subagent，token 和时间都烧得很快。对小任务来说有点「牛刀杀鸡」
修一个 typo、改一行配置，如果全套走完 brainstorming、plan、TDD、review，会非常重。
作者也坦白承认：
这套东西更适合「需要高质量、长期维护」的专案，而不是快速试验的小脚本。
你可以怎么用这个「思路」？
即使你不直接安装 Superpowers，也很值得做三件事：
把它当作「如何指挥 AI 写代码」的教材，读一遍，你会更知道该怎么写指令、怎么要求验证。
从里面挑几条最适合你的流程，简化成自己的团队规范，比如：
一律要求「先讲测试怎么写，再让 AI 写实现」。
要求 AI 在说「完成」之前贴上完整的命令和输出。
如果你自己在带新人，不妨把里头那种「藉口 vs 现实」的表格改写，给新人和 AI 一起看。
最后
Superpowers 真正有价值的地方，不是「我照抄它的所有规矩」，而是它提供了一套 系统化思考 AI 工作流 的范本：
把经验写成文字，把文字变成习惯，让 AI 跟人一起遵守。