前言：这段时间我在自己的项目里一直在用 superpowers，不是简单试一下，而是已经把它放进了日常开发流程里。这篇文章结合我在 Cursor 和 Codex 中长期使用 superpowers 的经验，说明它如何把需求澄清到计划到多代理执行变成 AI 必须执行的流程，让 Vibe Coding 从"爽快生成"走向更稳定的工程交付。
AI 写代码最大的问题，不是不会写
现在很多人用 AI 写代码，大概是这样：
帮我做一个页面。
帮我修一下这个 bug。
帮我把这个功能补上。
然后 AI 马上开始读文件、改代码、跑命令。
这个过程看起来很爽，尤其是第一次用的时候，会觉得效率一下子上来了。
但真正拿它做项目之后，你会发现问题也很明显：
- 需求没问清楚，它就开始实现；
- bug 没定位根因，它就开始打补丁；
- 测试没跑完整，它就开始总结"已完成"；
- 上下文没理解透，它就开始重构一片。
这不是某个模型的问题。
Cursor 会这样，Codex 也会这样。
只要你不给它流程，它默认就会用最快的方式往前冲。
而真实项目里，最快不等于最稳。
这里的关键不是"AI 会不会写代码"，而是"AI 能不能按一个稳定流程完成真实项目里的任务"。
superpowers 做的是什么？
我觉得 superpowers 最有价值的地方，是它把软件工程里的流程，变成了 AI agent 可以执行的 SKILL.md。
比如：
- 做功能前，先
brainstorming； - 需求确认后，写
writing-plans； - 实现时，走
test-driven-development； - 修 bug 时，用
systematic-debugging； - 完成前，用
verification-before-completion； - 任务复杂时，再用 subagent 拆分执行。
这些东西听起来都不新。
但问题是，人类工程师知道要这么做，AI 默认不一定会这么做。
所以 superpowers 的作用不是"提供更多工具"，而是把这些流程变成强约束。
它会让 AI 先判断：
当前任务应该走什么流程？
现在能不能直接改代码？
是否需要先问清楚需求？
完成之前要拿什么证据证明真的完成？
我现在更愿意把它理解成一套 agent 工作规范：先判断流程，再决定是否动手，最后用证据收尾。
这就是我觉得它像"Vibe Coding 界的软件工程"的原因，如下是CodeX和Cursor各自的superpowers插件：
| 使用阶段 | 推荐 skill | 解决的问题 |
|---|---|---|
| 新功能开始前 | brainstorming |
先问清楚需求边界 |
| 写实现计划时 | writing-plans |
把需求拆成可执行步骤 |
| 修 bug 时 | systematic-debugging |
先复现和定位根因 |
| 收尾前 | verification-before-completion |
用证据确认真的完成 |
具体使用
通过/brainstorming 触发：
问答式再次确定需求本身：
生成多套方案供你选择：
最后交付设计Spec文档：
开始实现：
独立子代理执行
为什么觉得它重要？
因为 AI Coding 正在从"代码补全"变成"工程执行"。
以前 AI 只是帮你写一个函数。
现在它可以读代码、改文件、跑命令、开浏览器、提交 PR，甚至调度子 agent。
能力变强以后，流程就更重要。
没有流程，AI 越强，破坏力也越强。
有流程，AI 才能真正变成生产力。
所以我不觉得 superpowers 只是一个插件。
它更像是在提醒我们：
Vibe Coding 不能只靠感觉，最后还是要回到软件工程。
spec、plan、TDD、debugging、review、verification，这些东西没有过时。
它们只是换了一种方式，重新出现在 AI Coding 时代。
我的最小建议
如果你已经在用 Cursor、Codex、Claude Code 这类工具，我建议先从一个动作开始：
不要一上来就让 AI 写代码。
先让它做三件事：
- 先问清楚需求；
- 再写实现计划；
- 最后用真实命令验证结果。
你会发现，AI 不是慢了，而是少返工了。
这才是我觉得 superpowers 最有价值的地方。