2026 年 3 月：Superpowers 与工程化默认动作

2026 年 3 月左右，Superpowers 开始进入日常开发流程。这个阶段的主要问题不是模型完全不会写代码，而是任务经常还没有被整理清楚，模型就已经开始执行。

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

在这个时间点，AI 已经能帮助完成系统开发，但很多工程动作仍然依赖临时提醒。想到先列计划，任务就会稳一些。忘记限定边界，模型就可能直接越界动手。Superpowers 的意义，是把这些容易被漏掉的动作变成可重复的默认值。

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

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

这和只让模型“改一下”差别很大。前者把任务当成一个工程过程，后者更像一次局部生成。Superpowers 在这一阶段暴露出的核心价值，是让执行前的理解、拆解和验证成为默认动作。

这一阶段的开发节奏，从“说一句，改一段”，推进到“先形成任务，再执行任务”。

它天然偏重

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

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

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

阶段沉淀

Superpowers 更像一个阶段性的训练器。

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

这一阶段形成的判断是：工具不是越完整越好。合适的工具，应该能在该重的时候压住风险，在该轻的时候不挡路。

参考来源：

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