解锁 AI 辅助开发新范式：Superpowers 让代码开发更高效

先说个我自己的真实体验。以前用 AI 写代码，总觉得是在跟一个“记忆超强但没脑子的实习生”配合。你问它“帮我写一个用户登录接口”，它三秒钟给你甩出一大段代码，看着挺完整，可一旦追问“这个接口在高并发下怎么防刷”“参数校验和现有项目的异常体系怎么统一”，它就沉默了，或者开始一本正经地胡说八道。问题不在于 AI 能力不够，而在于我们压根就没让它具备一套结构化的做事方法。最近我在项目里深度使用了 Superpowers 这套开源的 AI 技能增强方案，说夸张一点，它把 AI 从“回答问题”变成了“参与项目开发”。这篇文章把它的核心思路、安装接入方式和实操经验完整梳理一遍，想折腾 AI 辅助开发的朋友可以直接照着做。

Superpowers 不是某个大厂出的新 IDE，也不是什么云端服务，它本质上是 GitHub 上一套开源的 Skills（技能）集合，里面封装了系统思维、TDD（测试驱动开发）、结构化调试、任务拆解等工作流。通过 CLAUDE.md 或 AGENTS.md 这类文件，把它引入到你现有的 AI 编程工具里（Cursor、Claude Code、VS Code 的 AI 插件都可以），AI 就不再是“你问一句它答一句”的被动角色，而是会自动遵循一套工程化的思考流程：先理解全貌、再拆解任务、然后写测试、最后再实现。这篇文章适合已经在用 AI 写代码、但觉得效率没到预期的开发者，也适合那些想让 AI 输出更稳定、少返工的个人开发者和中小团队。

1. 认识 Superpowers：AI 辅助开发从“问答模式”到“工程模式”的分水岭

1.1 Superpowers 不是什么新鲜框架，而是一套重新组织 AI 能力的“方法论”

很多人第一次听说 Superpowers，会以为它是个新的 AI 模型或者代码生成工具，其实不是。你可以把它理解成一个“AI 工作方法培训包”——它不改变模型本身，而是通过一套精心编写的 Markdown 文件，告诉 AI 在遇到不同类型的任务时，应该按照什么样的流程去思考、计划和执行。

这套东西最早在 GitHub 上以开源形式发布，项目地址是 github.com/obra/superpowers。它的核心物是 skills 目录下的一组技能文件，每个技能都以 SKILL.md 为核心载体。文件开头是一段 YAML 格式的元信息，描述这个技能的适用场景和核心目标，正文则是一套具体的操作流程和原则。AI 在读取这些文件之后，不是把这些内容当成普通的聊天上下文，而是会把它当成“行为准则”来遵循。

拿其中最有代表性的 system-thinking（系统思维）技能来说。平时你让 AI “帮我重构一下用户模块”，它会直接开始改代码。但加载了系统思维技能之后，它会先梳理现有模块的结构、依赖关系、数据流向，画出一个信息架构，再告诉你它计划从哪里动手。整个过程就像一家装修公司进场后，不是拿起锤子就砸墙，而是先看户型图、确认承重墙、列出施工方案才动工。

这套设计背后的核心思路是：AI 生成的代码质量，不只是取决于模型的智力水平，更取决于工作流的约束程度。给 AI 一个明确的、分步骤的思考框架，它犯错的概率就会大幅下降。

1.2 它解决了什么核心痛点：从“答得出”到“干得完”

我们得先说清楚，传统 AI 辅助开发最大的坑到底在哪。我自己总结下来有这么几个：

第一，AI 太容易“抢跑”。你让它做一个功能，它在还没理解项目全局的情况下，就已经开始写代码了。比如你让它往一个老项目的支付模块里加一个优惠券功能，它不知道支付模块的异常处理规范，也不知道金额计算的精度约束，结果生成的代就是“能用但很脏”，和现有代码风格格格不入。

第二，没有验证意识。普通对话模式下，AI 写完代码就认为任务完成了，它不会主动思考“这段代码有没有边界条件？有没有处理失败路径？有没有写测试？”所有的验证工作都压在开发者身上。

第三，上下文一长就乱。在真实项目里，一个功能往往牵扯多个文件、多种状态、多步交互。AI 在对话窗口里聊着聊着，就忘了最初定的技术方案，开始自己发挥，最后产出的代码跟前面的设计完全对不上。

Superpowers 想解决的就是这三件事。它通过强制 AI 在动手之前先“理解任务背景”和“梳理文件结构”，避免抢跑；通过在技能里内置“写测试用测例”和“验证计划”的步骤，让 AI 自己给自己把关；通过把任务拆分成短周期、可验证的小步骤，避免上下文过长导致的逻辑漂移。

我实测下来，最明显的感知是——AI 的“嘴炮”变少了，活变细了。它不再是一股脑地把一坨代码丢给你，而是像团队里的工程师一样，跟你确认方案、分步实现、自查验证。从“答得出”到“干得完”，这就是 Superpowers 对整个 AI 辅助开发范式最核心的改变。

2. 深入了解 Skills 体系：Superpowers 的核心资产

2.1 Skills 到底长什么样，怎么组织

在谈具体使用之前，得先把 Skills 的目录结构和文件格式讲清楚。你把 superpowers 这个仓库克隆下来之后，会看到这样的结构：

bash复制superpowers/
├── CLAUDE.md          # 给 AI 的总入口说明
├── SKILLS.md          # 所有技能文件的索引
├── skills/            # 技能存放目录
│   ├── system-thinking/
│   │   └── SKILL.md
│   ├── debugging/
│   │   └── SKILL.md
│   ├── tdd/
│   │   └── SKILL.md
│   ├── test-driven-development/
│   │   └── SKILL.md
│   ├── planning/
│   │   └── SKILL.md
│   ├── executing-plans/
│   │   └── SKILL.md
│   ├── writing-plans/
│   │   └── SKILL.md
│   ├── browser-simulation/
│   │   └── SKILL.md
│   └── ...
└── ...

每个 SKILL.md 都遵循同一个骨架：头部是 name、description、when_to_use 这样的字段，正文是具体的工作流、原则和步骤。以 debugging 这个技能为例，它内部的逻辑就是典型的“根因驱动”式排查流程，而不是传统的“瞎试”。

AI 编程工具在读取项目配置时，会把这些技能文件的内容注入到系统提示词中，相当于每次对话前 AI 都先“读了一遍培训手册”。你不需要在每次提问时手动触发某个技能，AI 会根据你描述的任务特征，自动匹配对应的技能来执行。

2.2 三条核心工作流：系统思维、调试专家、TDD 驱动

深入用了几个月后，我认为 Superpowers 全部技能里含金量最高的是这三条工作流，它们几乎覆盖了日常开发 80% 的场景。

第一条是系统思维。这个技能要求 AI 在接到任务时，先做四件事：识别现有系统的架构上下文、找出与任务相关的文件和数据流、画出系统的状态图或信息流图、确认任务的约束条件。做完这些，它才会开始动手写代码。简单说，这就是强制 AI 从“局部视角”切换到“全局视角”。

第二条是结构化调试。过去排查 bug，AI 的做法往往是“根据报错信息猜测原因，然后改一行试试”，运气好能蒙对，运气不好就是死循环。加载 debugging 技能之后，AI 会先要求你提供完整的复现步骤和预期行为，然后系统性地提出假说、设计验证方案、检查代码路径、缩小问题范围。整个流程就像医生问诊一样，先了解症状、再体检、才开药，而不是一上来就乱开抗生素。

第三条是TDD 驱动开发。这也是我自己受益最大的一个技能。普通模式下 AI 写完功能代码，你得自己补测试；加载 TDD 技能后，它会倒过来：先根据需求写一组失败的测试用例，再运行测试确认失败，然后才写实现代码让测试通过，最后做重构。这个流程在我们接手不熟悉的项目时特别有价值——AI 写的测试就是一份“可执行的需求文档”，能帮你快速理解系统行为。

2.3 为什么这些策略能提升开发效率：原理解读

很多人会觉得：这些流程我自己平时也大致在做，靠一套 Markdown 文件就能让 AI 做得更好？这里有个最容易被忽略的点：对人来说，流程是经验；对 AI 来说，流程是约束。

大语言模型本质上是“概率预测器”。它生成代码的时候，是根据上下文中最可能的 token 序列来输出的。如果没有强约束，它最可能的输出就是“最平庸但直接”的代码。因为模型在训练的时候，见过了太多“用户问一个功能，回答者直接给代码”的对话，这成了它的本能反应。

Superpowers 的作用，本质是通过系统提示词来改变这个概率分布。当 AI 读取了系统思维技能的指令后，在它的上下文里，“接到任务就直接写代码”的概率就降低了，“先分析结构再动手”的概率就升高了。这是用指令集对抗模型惯性，而不是期待模型自我进化。

另外，从工程管理角度看，这套技能体系还有一个重要的副作用：它让 AI 的过程可视化。以前你给了 AI 一个任务，你根本不知道它脑子里的推导过程，它给你一堆代码你就得全盘接受。有了分步式的技能约束后，AI 会在每个关键节点输出中间产物——理解文档、测试用例、执行计划。你可以随时介入纠正方向，而不是等到代码写完了才想办法返工。

3. 安装与接入：5 种方式把 Superpowers 装进你的 AI 编程工具

3.1 方式一：直接克隆到项目目录，单项引入

最省事、也最适合先试水的办法，是把它作为项目级配置引入。先克隆仓库到本地任意目录：

bash复制git clone https://github.com/obra/superpowers.git

然后把整个 superpowers 项目目录复制到你当前项目的根目录下，或者只把你需要的技能子目录复制进项目：

bash复制cp -r superpowers/skills/tdd ./your-project/.skills/tdd

接下来打开项目的 CLAUDE.md 文件（如果没有就直接新建），在里面加一行引用：

markdown复制@path/to/your-project/.skills/tdd

如果你的工具用的是 AGENTS.md（比如 Cursor 新版、Gemini CLI 等），做法一样，改个文件名就行。这相当于告诉 AI：“在当前项目里，请把 TDD 技能加载进来，并按照里面的规则执行。”

3.2 方式二：全局配置，让所有项目共享

如果你不满足于单个项目，希望所有项目都能自动加载这些技能，可以把它装到用户目录的全局配置里。以 Claude Code 为例，全局技能目录通常在 ~/.claude/skills/，你可以把 superpowers 仓库里的技能目录软链过去：

bash复制ln -s /path/to/superpowers/skills/system-thinking ~/.claude/skills/system-thinking
ln -s /path/to/superpowers/skills/debugging ~/.claude/skills/debugging
ln -s /path/to/superpowers/skills/tdd ~/.claude/skills/tdd

然后在 ~/.claude/CLAUDE.md 里统一声明这些技能。还有一种更激进的方式，直接在超级用户的配置里引入整个仓库的索引文件 SKILLS.md，让 AI 自己去查看有哪些技能可选。这种方式的好处是一次配置、省心省力，坏处是对所有项目无差别注入，可能让简单任务也背上沉重的上下文负担。我的建议是第一阶段先用项目级配置，摸清楚哪些技能是你常用的，再决定要不要铺开到全局。

3.3 如何验证你的 AI 已经加载了技能

装完之后，关键问题是：怎么确认 AI 真的读进去了？最直接的验证方式是直接问它：“你现在有哪些可用的技能？请列出技能名称和适用场景。”

如果回答里出现了 system-thinking、debugging、tdd 这些关键词，并能准确说出它们的使用时机，说明加载成功。如果 AI 只是一脸茫然地说“我没有其他技能”，大概率是文件路径或者配置格式出了问题。

另一个更隐蔽的验证方式是行为验证：你故意给它一个模糊的开发任务，比如“帮我优化一下这段代码”，然后看它的反应。如果它开始主动追问“这段代码在什么模块里被调用？”“性能瓶颈是 CPU 密集还是 IO 密集？”，说明系统思维技能已经生效了。如果它直接埋头改代码，说明配置还没生效。

3.4 在 Cursor、VS Code、CLI 中的接入注意点

不同工具的接入细节略有差异，我把容易踩坑的几点单独拿出来说。

在 Cursor 中使用时，最需要注意的是版本差异。老版本 Cursor 引用的是项目根目录的 .cursorrules 文件；新版本开始支持 AGENTS.md，并且支持类似 @path/to/skill 的引用语法。如果你沿用旧的 .cursorrules 写法，新版本不一定会读。建议在项目根目录同时放置一个 AGENTS.md 文件，内容里用 @path 方式引用技能目录。

在 VS Code 里，如果你用的是 Continue、Cline 这类 AI 插件，做法稍微不一样。这些插件通常不支持直接读取 CLAUDE.md，你得把技能文件里的核心指令粘贴到插件的“自定义系统提示词”或者“项目规则”配置里。这也是很多人在 VS Code 里装了 Superpowers 却感觉没反应的主要原因——不是你配置错了，而是插件根本没有去读那个文件。

在 Claude Code / CLI 环境下，接入是最自然的。它原生支持技能目录加载，而且支持在对话中动态调用技能。日常用法是在项目根目录的 CLAUDE.md 里写上技能索引，然后用自然语言告诉 AI：“请按照调试专家流程来排查这个问题。”它的响应质量明显高于普通模式。

注意：任何工具接入后，记得重启会话窗口让配置重新加载，这个操作很多人会忘，然后对着不生效的配置怀疑人生。

4. 上手实操：用 Superpowers 完成一个真实功能的完整推演

4.1 任务拆解：让 AI 先“想明白”再“动手写”

理论说得再多，不如跑通一个小功能来得直观。我挑一个实际发生过的场景来演示——给一个内部后台系统加一个“用户导入”功能，支持上传 CSV 文件、预览解析结果、批量写入数据库并返回失败清单。

按平时习惯，你可能直接就把这段需求扔给 AI 让它写代码。但加载了 Superpowers 之后，事情就变成下面的流程。

首先，我向 AI 输入任务描述，并明确要求它使用系统思维技能来处理：

text复制请使用 system-thinking 技能来分析并规划这个功能：
新增用户导入功能，支持上传 CSV、解析预览、批量写入、导出失败清单。现有用户模块已经存在 User 表和相关服务。

它给我的第一轮回复不是代码，而是一份“理解确认文档”，内容包括：

• 识别到的相关文件（用户实体、数据库访问层、现有控制器路由、已有的文件上传组件）
• 数据流示意（CSV 文件 → 解析 → 校验 → 批量写入 → 失败记录）
• 两个关键约束（用户名唯一索引冲突时的处理策略；单批次写入数量上限）
• 三个待确认问题（CSV 编码格式是否固定为 UTF-8；是否需要在导入前做全量预校验；失败清单的导出格式）

这一轮交互看起来“没有产出代码”，但恰恰帮我们避免了后面巨大的返工。因为在真实场景里，用户导入这个功能最容易出的 bug 就是：写到一半遇到重复数据，抛出异常导致批量回滚，你连哪些数据成功、哪些失败都不知道。AI 能在第一时间提出“是否要做失败清单”，说明系统思维确实起作用了。

4.2 从场景到流程：一个功能从“测试先行”到“平滑落地”

在确认完需求后，我告诉 AI：“请使用 tdd 技能先为这个功能设计核心测试用例，再开始实现。”

这个阶段 AI 做了三件事。第一，它梳理出了五个关键测试场景：

1. 上传一个包含 100 条合法数据的 CSV，应全部导入成功。
2. 某一行存在重名字段（用户名与库中已有数据冲突），该行应标记为失败，其他行继续写入。
3. CSV 中某列缺少邮箱，应触发行级校验失败。
4. 文件超过 500 行时，应拒绝上传并提示限制。
5. 写入过程中连接中断，事务应完整回滚且不产生部分数据。

第二，它生成了一组独立的测试代码，放在 tests/test_user_import.py 中，并运行确认测试是失败的（红）。第三，它才着手编写实现代码，先写 CSV 解析模块、再写校验逻辑、最后接数据库批量写入。每写完一个模块就跑一次测试，直到所有测试由红转绿。

整个过程走下来，最让我惊讶的不是代码质量，而是节奏感：AI 不再是“一次性写了一大坨代码再测”，而是像真正按照 TDD 节奏开发的工程师一样，一个功能一个功能地推进，每次运行测试都能看到明确的进展。最终代码量约 300 行，测试覆盖率覆盖了所有核心分支。

4.3 实测体验：哪里变好了，哪里还有坑

直接把使用前后的差异做个对比会更清楚。

坑也确实存在，我遇到最明显的是技能固定流程有时觉得繁琐。比如改一个按钮的颜色，也要求先走系统思维再走 TDD，显然小题大做了。Superpowers 的 when_to_use 字段虽然写了适用场景，但 AI 对复杂度的判断并不总是准。这时候你需要在对话里明确告诉它：“这是一个低风险小改动，跳过计划直接做。”它才会切换回轻量模式。

另外一个坑是“技能间打架”。比如系统思维要求先画信息流图，而 TDD 技能要求先写测试，两个技能叠加时 AI 有时不知道该先执行哪个。我的经验是：如果任务以新功能为主，就用 TDD 为主流程；如果是排查现有系统问题，就以 debugging 为主流程，其余技能为辅。在 Claude 这类工具里，你甚至可以直接指定：“按照 tdd 技能执行，不要使用系统思维技能。”

5. 常见问题与排查技巧实录

5.1 技能没有生效的排查顺序

如果配置完发现 AI 完全没有按照新流程工作，别急着怀疑项目问题，先用以下顺序排查：

• 确认文件命名：是否使用了工具支持的 CLAUDE.md 或 AGENTS.md？大小写有没有错？多工具共用项目时，不同的 AI 插件只认自己指定的文件名，这是最常见的原因。
• 确认引用语法：技能目录的 @ 引用路径是否正确？相对路径是从项目根目录算的，不要放错层级。
• 确认技能文件格式：SKILL.md 开头的 YAML frontmatter 是否被工具完整读取？有些插件要求 YAML 字段严格用 name: description: 格式，多一个空格或缺一个冒号，整个文件就会被跳过。
• 确认上下文足够长：技能注入会占用上下文窗口，如果模型上下文被塞满，后面的技能指令可能被截断，AI 自然就“失忆”了。遇到这种情况，换成上下文更长的模型，或者只注入当前任务需要的单个技能。
• 强制触发一次：直接给 AI 下命令“严格按照 debugging 技能来分析下面这个问题”，如果它还是我行我素，那基本可以确定技能没有被加载成功。

5.2 上下文撑爆、内存溢出的应对

Superpowers 全家桶全量注入的时候，技能文件加起来有几万 token，对上下文窗口是个不小的考验。尤其在使用 32K 上下文的小模型时，很可能技能加载完，项目代码就没地方放了。

我的处理方案是“按需注入”。项目根目录只保留索引文件，里面列表所有技能名称和一句话摘要；当 AI 接到任务、判断需要使用某个技能时，再告诉它“去 .skills/tdd/SKILL.md 路径读取详细指令”。这样整个上下文里只常驻技能摘要，详细内容按需加载，实测下来上下文占用率降低了 70% 左右。

在 Claude Code 这类工具里，还可以利用工具本身的“读取文件能力”做到动态加载：CLAUDE.md 里只写“技能清单见 SKILLS.md，需要用时自行读取”，剩下的交给 AI 自己决定。

5.3 什么场景不适合用 Superpowers

说了很多好处，但这个方案绝不是银弹。有几个场景我个人觉得使用这套体系会拖慢节奏，甚至适得其反。

第一是纯探索性原型的验证。你只是想快速验证一个技术方案行不行，比如“用 WebSocket 做实时白板协程会不会有延迟问题”。这种场景下，你需要的是一次快速试错，而 Superpowers 的完整流程会让你在还没开始写代码的时候就先写一大堆分析和测试，浪费时间。

第二是代码风格极不一致的遗留系统。当项目结构混乱、没有清晰分层时，系统思维技能会让 AI 陷入对现有代码的过度分析，迟迟出不了结果。这种项目更适合让 AI 先“局部小步改动”，而不是“全局理解系统”。

第三是零测试基础的项目。TDD 技能再强大，也需要项目有可运行的测试基础设施。如果一个项目连 pytest 都没有配置，AI 生成一万个测试用例也跑不起来。先花一天把测试框架搭好，再来聊 Superpowers，顺序别搞反。

5.4 效率提升的实际感受与量化参考

最后分享几组我实际观测到的数据。这些数字没有统一基准，只是个人使用感受，但能给你一个相对直观的体感。

我拿一个中等规模的后端项目做了对照测试。任务是“新增一个带缓存的消息队列消费者，处理订单状态变更事件”。在没有 Superpowers 的常规 AI 对话模式下，AI 第一次生成的代码有 3 处边界问题，我手动修改 + 反复追问花了约 40 分钟才完成。在开启 Superpowers（主要用到系统思维 + TDD 技能）后，第一次生成的代码就通过了全部测试，中间我能感觉到 AI 每一步都在“自我约束”，完整耗时约 15 分钟。

项目里的存量 bug 排查，过去我自己的流程是：看报错、搜代码、打印日志、定位问题，平均每个 bug 15 分钟。用上 debugging 技能后，AI 会自动检查二分日志策略，先区分“是否是输入数据问题”，再定位“是逻辑分支问题还是依赖服务问题”，很多 bug 我只需要把报错信息转述给 AI，它就能给出一个带有验证步骤的排查方案，实际我动手的时间减少到 5 分钟以内。

最后提醒一句：Superpowers 的安装只是一次性的动作，真正的收益来自于你愿意调整自己的工作习惯。它的技能体系再好，也不能替你决定“何时该用、何时该跳过”。我的做法是在项目里保留它，但通过对话指令灵活控制它的参与程度：大功能走全流程，小改动直接开关关闭，这种“弹性接入”的方式是最舒服的。

如果你也想尝试，建议先只加一个 system-thinking 技能，用一周感受一下与 AI 协作节奏的变化，再逐步引入 debugging 和 tdd。从最小的切入点开始，才不会因为流程繁琐而早早弃坑。这套玩法不会让你的 AI 变成超人，但它确实能让你的 AI“办事更靠谱”。