Superpowers 是什么，怎么装，跑起来长什么样

上一篇只做了一件事：把问题说透。

这一篇开始解决问题。

先把一个最常见的误区拆掉：很多人第一次听到 Superpowers，会以为它是一个 CLI、一个插件，或者某种“替你自动接管开发流程”的魔法工具。

都不是。

Superpowers 的本质其实很朴素：

它是一套注入给 AI 的工程规则文件集合。

你可以把它理解成一层“行为约束系统”。它不替你写业务，但它会影响 AI 在项目里的工作方式。

适用场景

• 已经在使用 AI 写代码，但感觉输出不稳定的开发者
• 想提升代码可维护性的独立开发者
• 想构建 AI Agent 工程体系的人
• 对 AGENTS.md / AI 协作流程感兴趣的工程师

阅读后你将获得：

• 对 Superpowers 的正确认知（避免误解）
• 一套最小可落地的接入方法
• 一个验证 AI 是否“被约束”的实战方式

核心内容

第 2 篇：Superpowers 是什么，怎么装，跑起来长什么样

上一篇只做了一件事：把问题说透。

这一篇开始解决问题。

先把一个最常见的误区拆掉：很多人第一次听到 Superpowers，会以为它是一个 CLI、一个插件，或者某种“替你自动接管开发流程”的魔法工具。

都不是。

Superpowers 的本质其实很朴素：

它是一套注入给 AI 的工程规则文件集合。

你可以把它理解成一层“行为约束系统”。它不替你写业务，但它会影响 AI 在项目里的工作方式。

先说结论：Superpowers 到底是什么

如果你只记一句话，就记这句：

Superpowers 不是一个替代开发者的工具，而是一套让 AI 像工程师一样工作的规则层。

它解决的不是“模型能力不够”，而是“模型默认没有项目纪律”。

没有这层规则时，AI 很容易：

• 越权修改
• 跳过测试
• 直接进入实现
• 不验证就宣称完成
• 把不同阶段的工作混在一起

有了这层规则后，AI 的表现会更接近一个受流程约束的协作对象。

它不是 CLI，也不是 IDE 插件

这里一定要说清楚，不然后面整套专栏都会建立在错误认知上。

Superpowers：

• 不是一个独立命令行程序
• 不是浏览器插件
• 不是 Cursor 扩展
• 不是某个模型专属能力

它更像是：

• 一套 AGENTS.md 约束
• 一组技能文档
• 一层项目级行为规范

只要你使用的 AI 编码工具支持把项目内规则文件注入上下文，这套方法就能工作。

为什么它有效

因为 AI 编码最常见的问题不是“不会写”，而是“没有边界”。

而 Superpowers 正在做三件事：

1. 给 AI 明确阶段感
2. 给 AI 明确验证义务
3. 给 AI 明确协作边界

这三件事叠加起来，AI 输出的稳定性会显著提升。

它在项目里长什么样

从项目视角看，Superpowers 不神秘。它通常就是几类文件：

• AGENTS.md 项目级规则入口，定义 AI 在这个仓库里的协作方式。
• skills/ 存放不同场景下的工作流说明，比如 brainstorm、design、debug、review、TDD 等。
• superpowers/ 存放更强约束或增强版能力集合。
• 其他辅助说明文件 用来补充使用说明、约束策略、行为规范。

最重要的认知是：这些文件不是“文档附件”，它们本身就在影响 AI 的默认行为。

安装流程：从 0 到可用

这里不绑定某个特定仓库地址，因为不同团队的分发方式可能不同：有人从 GitHub 克隆，有人直接复制模板目录，也有人把规则文件作为项目脚手架的一部分。

但无论来源是什么，真正有效的安装动作其实只有三步。

第一步：把规则文件放进项目

以接下来要做的 TaskCLI 项目为例，目录可以长这样：

taskcli/
  AGENTS.md
  app/
  tests/
  docs/
  .github/

Superpowers 的核心并不是“安装到系统”，而是“进入项目上下文”。

也就是说，真正关键的是：

• 规则文件在项目里
• AI 工具会读取这些规则
• 你在项目工作流里明确使用这些约束

第二步：配置 AGENTS.md

这是最重要的一步。

AGENTS.md 不是装饰品。它是项目里给 AI 的“工作宪法”。

你至少应该在这里约束几件事：

• 先分析，再动手
• 改代码前先说明意图
• 能写测试就不要跳过测试
• 不验证不能宣称完成
• 不要越权修改与当前任务无关的内容

一个最小可用版可以从下面开始：

# AGENTS.md

## 工作原则
- 先分析需求，再开始实现
- 优先保持修改范围最小
- 未经验证，不要声称完成
- 实现功能时优先补充或更新测试

## 输出要求
- 改动前先说明要改什么
- 改动后说明验证方式和结果
- 如果存在不确定性，先暴露问题，不要直接猜

这不是最终版，但足够让你感受到：AI 一旦被规则约束，行为会稳定很多。

第三步：在真实任务里验证它有没有生效

环境装完之后，不要停在“文件已经放好了”。

你必须立刻用一个最小任务验证它有没有真的改变 AI 的行为。

最适合的就是一个 Hello World 级别的命令。

场景

我们让 AI 实现一个最简单的命令：

hello --name lin

输出：

Hello, lin!

没有 Superpowers 时，AI 常见行为

• 直接写实现
• 不考虑参数解析方式
• 不考虑错误输入
• 不写测试
• 不解释设计决策

有 Superpowers 时，AI 常见行为

• 先澄清命令格式
• 说明文件放在哪
• 提出测试场景
• 给出最小实现路径
• 执行后报告验证结果

这里最值得观察的，不是它“写出来的代码是不是更高级”，而是它有没有开始遵守基本工程纪律。

一个最小对比例子

如果你只问：

帮我实现 hello --name lin

AI 大概率会直接输出一段代码。

但如果你问：

请在当前项目约束下实现 hello --name <name>。
先说明：
1. 你准备改哪些文件
2. 你会补哪些测试
3. 你如何验证结果
确认后再给出最小实现

它的工作方式通常会马上变得更“像工程师”：

• 先交代范围
• 先考虑测试
• 先定义验证
• 再进入实现

这就是 Superpowers 最直观的价值：不是把 AI 变成另一个模型，而是把同一个模型放进更好的工作方式里。

读者最容易误解的三件事

1. 以为装完就自动变强

不会。

Superpowers 提供的是约束框架，不是自动驾驶。你还是要定义任务、Review 结果、决定取舍。

2. 以为它替代基础工程能力

不会。

如果你自己没有测试意识、没有边界意识、没有最小修改意识，规则文件也救不了你。

3. 以为它只适合复杂项目

恰恰相反。

独立开发者做中小项目时最容易“先跑起来再说”，而这正是 AI 把技术债放大的温床。

小项目更需要尽早建立纪律。

为什么我们下一篇直接进入真实项目

很多教程到这里会停在“环境已经搭好”的状态。

但真正有用的方法，必须进入真实上下文才能验证。

所以下一篇开始，我们不再做 Demo。

我们会正式启动贯穿整套专栏的实例项目：

TaskCLI，一个个人任务管理命令行工具。

从下一篇开始，每一篇都推进它的一个真实阶段。你跟着做完，手上最终会有：

• 一个完整项目
• 一套 AGENTS.md 模板
• 一组可复用 Prompt
• 一条可迁移到别的项目的工程流程

本篇交付物

• 对 Superpowers 的清晰定义
• 一份最小可用的 AGENTS.md 示例
• 一套不依赖特定平台的安装与接入思路
• 一个用于验证规则是否生效的 Hello World 方法

与上一篇/下一篇的衔接

上一篇解释了为什么 AI 写出来的代码会越来越难维护。

这一篇把“约束 AI”这件事落到了项目文件和工作方式上。

下一篇开始，正式进入 TaskCLI 项目启动阶段：先不写代码，先用 /brainstorm 把需求想清楚。

补充说明

在真实项目中使用 Superpowers 时，有几个非常关键的实践建议：

• 不要一次性引入过多规则，先从最小 AGENTS.md 开始
• 每一条规则都要“可观察”，否则很难判断是否生效
• Prompt + 规则文件是组合关系，而不是替代关系
• 不同项目可以复用规则，但必须允许局部调整

此外，这套方法并不依赖某一个具体模型：

• ChatGPT 可以用
• Codex 可以用
• Claude 也可以用

只要你的工具支持“读取项目文件作为上下文”，它就可以生效。

结论

Superpowers 的核心价值不在于“增强 AI”，而在于“约束 AI”。

它让 AI 从：

👉 一次性回答机器

变成：

👉 可协作、可验证、可约束的工程参与者

这才是 AI 开发从“能用”走向“可维护”的关键一步。

与上一篇/下一篇的衔接

上一篇解决了一个核心问题：为什么 AI 会让代码越来越难维护。

这一篇给出了第一层解决方案：通过 Superpowers 建立最基础的工程约束。

下一篇开始，我们会把这些约束真正用在项目里，从 TaskCLI 的需求分析开始，正式进入工程化开发流程。