前言
最近留意到github上有个编程skills比较火爆superpowers , 很多人第一眼会觉得 superpowers 是一个"AI 编程插件", 但我更倾向把它理解为一套约束 AI 行为的执行协议（Execution Protocol）, 什么意思？在 Cursor 或 Codex 里：你输入 prompt， AI 自由发挥，本质是：无约束生成。而 superpowers 做的事情是：
- 把整个过程拆成多个阶段
- 每个阶段有明确输入 / 输出
- 严格限制 AI 当前"能做什么"
一、 我们正在面临的"AI 协作困境"
在superpowers实现前，先聊聊目前 AI 编程里最扎心的三个痛点：
- 认知边界的迷失 (Context Drift)： AI 是个典型的"局部主义者"。在几万行的代码库里，它往往只盯着你喂给它的那几个文件。它不知道你项目里已经封装好了
axios，于是自作聪明地又写了一个。结果就是：项目跑通了，但代码复用度降低了。 - 调试的"黑盒"陷阱： 当代码报错时，AI 最常见的反应是"复读机式修复"。它会说"抱歉，我漏了一个判空"，改完报错；再说"抱歉，可能是异步问题"，再改。这种 Trial-and-Error（盲碰）的模式，不仅浪费 Token，更是在消磨开发者的耐心。
- 审查负担 (Review Fatigue)： 现在最累的不是写代码，是 Review。AI 甩给你 500 行改动，你敢合吗？因为缺乏可信的验证路径，你甚至觉得 Review 它的代码比自己重写一遍还累。
二、 核心哲学：工程纪律大于模型能力
superpowers 的核心逻辑是：与其期待模型更聪明，不如让它的行为更规范。
在没有 superpowers 之前，AI 编程助手（如 Cursor、Claude）更像是一个极速打字员 ，而有了它之后，AI 变成了一个资深工程师。
2.1 强制性的"先思后行"（The Thinking Protocol）
- 普通 AI： 看到需求直接开改，改完发现引出 3 个新 Bug。
- Superpowers AI： 被禁止直接动代码。它必须先调用
research技能查阅现有逻辑，再调用plan技能产出方案，最后才动手。这种认知顺序的强制化，极大地减少了"重构灾难"。
2.2 系统化调试（Systematic Debugging）
这是该项目最硬核的优势。它将调试从"碰运气"升级为"科学实验"：
- 它要求 AI 必须通过 Observation（观察） -> Hypothesis（假设） -> Verification（验证） 的闭环。
- AI 不能只说"修好了"，必须提供测试通过的证据。
2.3 环境隔离与安全（Isolation）
利用 git-worktree 技能，AI 的所有实验性修改都在平行空间进行。这让开发者敢于让 AI 进行大规模重构，因为一键即可回滚，主开发分支永远处于受保护状态。
三、 技术底层：它是如何"驯服"AI 的？
superpowers 的底层逻辑并非改变了 LLM（大模型）本身，而是通过工程抽象重新定义了人机交互的边界。
3.1 状态机模型（State Machine）
superpowers 将软件开发抽象成了一个有状态的流程。它定义了不同的"运行等级"：
-
Level 0: Context Gathering（只允许搜索和读取）
-
Level 1: Planning（产出文档，禁止改码）
-
Level 2: Execution（激活文件写入，配合 TDD）
这种物理层面的权限截断，确保了 AI 不会在还没搞懂逻辑时就开始乱写。
3.2 Skill 作为"原子化执行协议"
在源码中，每一个 .md 文件（如 systematic-debugging.md）都是一个 Skill 定义。它的原理包括：
- JSON Schema 绑定： 每个技能对应一组工具调用指令。当 AI 调用技能时，它必须填入符合规范的参数。
- 反馈闭环： 技能执行后，结果会以标准格式返回给 AI。如果 AI 没有按照协议（协议要求先写测试），系统会拒绝执行后续动作。
3.3 基于"上下文修剪"的精准控制
加载全量技能会造成 Token 溢出且让 AI 产生干扰。superpowers 的实现逻辑是：
- 动态注入： 根据当前任务阶段，动态地将相关的
SKILLS.md内容注入到 System Message 中。 - 少即是多： 限制 AI 在特定时刻能看到的"超能力"，反而提高了它的执行精度。
2.4 为什么它更稳定？
我们可以用一个公式来总结它的原理：
<math xmlns="http://www.w3.org/1998/Math/MathML"> S t a b i l i t y = ( L L M R e a s o n i n g ) × ( E n g i n e e r i n g C o n s t r a i n t s ) n Stability = (LLM\ Reasoning) \times (Engineering\ Constraints)^n </math>Stability=(LLM Reasoning)×(Engineering Constraints)n
- 模型（LLM）： 提供推理基础。
- 约束（Constraints）： 由
superpowers提供。
它通过把软件工程的最佳实践（Best Practices）转化为模型必须遵守的原子化指令（Atomic Skills） ，实现了从"概率性代码生成"向"确定性工程闭环"的跨越。
一句话总结： superpowers 的核心不是给 AI 自由，而是给 AI 划定了一条"通往成功的狭窄路径"。
四、 实战：AI 视角下的"重构三部曲"
假设我们要重构一个逻辑混乱的老旧模块，在 superpowers 的加持下，AI 的执行路径是这样的：
4.1：Brainstorming（拒绝直接上手）
AI 接收任务后，第一步是调用 search 和 list_files 摸清家底。它会先输出一个"重构提案"，问你： "我发现这里有三个依赖项，我打算先解耦 A 再改动 B，你觉得呢？" 这种先提问、出方案的习惯，像极了靠谱的架构师。
4.2 环境隔离 (Git Worktrees)
为了保证安全，它会自动创建一个 Git Worktree。这意味着 AI 的所有折腾都在一个隔离的平行空间进行。即便它把代码改得一塌糊涂，也不会影响你当前的工作区。这种自动化运维的能力，让 AI 真正具备了"独立作业"的条件。
4.3 根因追踪 (Systematic Debugging)
遇到一个深层 Bug 时，AI 不再盲目改代码，而是开始执行"系统化观测"。它会先插入 Trace 日志，观察数据流，确认假设后才落笔。这种逻辑闭环，让它的修复成功率呈指数级提升。
五、 总结：AI 时代，我们该学什么？
随着 superpowers 这类工具的成熟，开发者的角色正在发生深刻转变：
我们不再是写代码的人，而是定义"产品"和检查"实现"的人。
与其在提示词里求 AI "请写得好一点"，不如像 superpowers 这样，给它一套标准化的技能说明书。如果你所在的团队有特殊的开发规范（比如特定的内部库或部署流程），你完全可以基于它的框架，自定义一套私有的 Skills。
好的工具不应该给 AI 自由，而应该给 AI 边界。 这或许就是 AI 编程工程化的终极答案。