前言

最近留意到github上有个编程skills比较火爆superpowers。很多人第一眼会觉得 superpowers 是一个“AI 编程插件”,但我更倾向把它理解为一套约束 AI 行为的执行协议,什么意思？在 Cursor 或 Codex 里：你输入 prompt。AI 自由发挥，本质是：无约束生成。说起来，而 superpowers 做的事情是：

• 把整个过程拆成多个阶段
• 每个阶段有明确输入 / 输出
• 严格限制 AI 当前“能做什么”

一、 我们正在面临的“AI 协作困境”

在superpowers实现前。先聊聊目前 AI 编程里最扎心的三个痛点：

1. 认知边界的迷失 ： AI 是个典型的“局部主义者”。在几万行的代码库里它往往只盯着你喂给它的那几个文件。它不知道你项目里已经封装好了 axios于是自作聪明地又写了一个。结果就是的观点是，项目跑通了但代码复用度降低了。
2. 调试的“黑盒”陷阱： 当代码报错时AI 最常见的反应是“复读机式修复”。话说回来，它会说“抱歉，我漏了一个判空”，改完报错；再说“抱歉，可能是异步问题”，再改。这种 Trial-and-Error的模式。不仅浪费 Token，更是在消磨开发者的耐心。
3. 审查负担 ： 现在最累的不是写代码，是 Review。AI 甩给你 行改动，你敢合吗？因为缺乏可信的验证方法，你甚至觉得 Review 它的代码比自己重写一遍还累。

二、 主要哲学：工程纪律大于模型能力

superpowers 的主要原因是：与其期待模型更聪明，不如让它的行为更规范。

在没有 superpowers 之前。AI 编程助手更像是一个极速打字员而有了它之后AI 变成了一个资深工程师.

强制性的“先思后行”

• 普通 AI： 看到需求直接开改，改完发现引出 个新 Bug。怎么说呢，
• Superpowers AI： 被禁止直接动代码。怎么说呢，它必须先调用 research 技能查阅现有逻辑。 再调用 plan 技能产出方案，最终才动手。这种认知顺序的强制化

程序化调试

这是该项目最硬核的优势。它将调试从“碰运气”升级为“科学实验”：

•    Observation → Hyposis → Verification 的闭环。
•    AI 不能只说“修好了”，必须提供测试通过 的证据。

环境隔离与安全

   利用 git-worktree 技能，AI 的所有实验性修改都在平行空间进行。这让开发者敢于让 AI进行 大规模重构。因为一键即可回滚，主开发分支永远处于受保护状态。其实，

superpowers 的根本原因并非改变 LLM 本身。而是通过工程抽象重新定义人机交互边界.

状态机模型

superpowers 将软件开发抽象成 有状态流程。它定义不同运行等级 ：

•  
  
  Level : Context Garing
  
  

• **Level : Planning**

*
• * *Level : Execution* （激活文件写入，配合 TDD )** *这种物理层面的权限截断 确保 AI 不会 在还没搞懂逻辑时就开始乱写。* / li>

  • / ul>

    h4

    **

  在源码中，每个 .md 文件 如 systematic-debugging.md 是一个 Skill 定义。其原理包括这方面，

  <

  • JSON Schema绑定 ：每个技能对应一组工具调用指令。当 AI 调用技能时它必须填入符合规范参数。

  • 反馈闭环 ：技能执行后结果以标准格式返回 给 AI。如果没有按照协议，程序拒绝执行后续动作。

  ​

   ​
  

  …

  ​​

  — …，…，…不过，

  html

  ---