Superpowers 给我的第一套工程化开发默认值

我最早接触 Superpowers 时，真正吸引我的不是某一个具体 skill，而是它把 AI 编程从一次性对话拉进了一套更像工程流程的轨道。

官方仓库把 Superpowers 定位为 agentic skills framework 和 software development methodology。这个说法很准确。它不是只给模型加几个命令，而是把 brainstorming、计划、实现、TDD、代码审查、完成前验证这些动作串成一条默认路径。

对当时的我来说，这件事很新鲜。前面几个项目里，我已经能借助 AI 把系统做出来，但很多动作还靠临时提醒。今天想到要先列计划，今天就会稳一点。忘了提醒边界，模型就可能直接越界动手。Superpowers 的意义，是把这些容易被忘掉的动作变成可重复的默认值。

它改变的不是功能，而是习惯

在成绩分析系统里，我留下了不少 specs 和 plans。这些文档不是最终产品功能，但它们记录了一个变化：我开始让 AI 在动手前先写清楚要做什么，为什么这么做，涉及哪些文件，怎么验证。

这和只让模型“帮我改一下”差别很大。前者把任务当成一个工程过程，后者更像一次局部生成。Superpowers 让我第一次明确感到，AI 协作里最容易出问题的地方不一定是模型不会写代码，而是模型还没理解任务，就已经开始执行。

所以它给我的第一层价值，是把开发节奏从“说一句，改一段”，推到了“先形成任务，再执行任务”。

它天然偏重

Superpowers 的完整流程很适合复杂任务。需求不清、影响面大、需要审查和验证时，这套动作能防止模型一路冲偏。

但它也天然偏重。完整流程被放到小任务里，就会出现成本倒挂。一次文案调整、一个局部样式问题、一个明确 bug，如果也完整走 brainstorming、计划、TDD、review，节奏会被流程拖慢。

后来我在项目规则里加入轻重分流，就是从这里开始的。Superpowers 没有被我否定。它留下来的，是先对齐边界、保留计划、完成前验证这些习惯。只是它不再适合做所有任务的默认入口。

现在我怎么看它

我更愿意把 Superpowers 看成一个阶段性的训练器。

它帮我把很多原本说不清的开发动作显性化。等这些习惯被我吸收以后，我就不需要每次都完整照搬那条重流程。复杂任务继续保留它的纪律，小任务回到更短路径。

这也是我后来对工具的一个基本判断：工具不是越完整越好。真正合适的工具，应该能在该重的时候压住风险，在该轻的时候不挡路。

参考来源：

• Superpowers 官方仓库
• 本地项目证据：成绩分析系统中的 docs/superpowers/specs、docs/superpowers/plans 和项目规则文件