让AI编程从“快”到“可靠”：Superpowers工作流全解析

在AI编程工具越来越普及的圈子里，Superpowers这个名字最近被频繁提起。它不是某个大厂发布的新IDE，也不是又一款“AI编程软件”，而是一套针对AI编程代理设计的开源技能与工作流集合。我最初接触它，是因为自己用命令行AI写代码时觉得“生成速度确实快，但合进项目里总是不踏实”——而Superpowers的核心主张，正好是把AI编程从“快”拉回“可靠”这条轨道上。它适合谁？适合那些不满足于让AI生成一段能跑的代码、而是希望AI在真实项目里按工程流程交付功能的人；也适合正在研究AI编程提示词、agent工作流的开发者，以及所有对“AI写代码但不敢合入”这件事感到头疼的团队。

1. AI编程为何“快而不稳”，Superpowers解决了什么

1.1 直接提示词生成出的代码，问题出在哪

我自己踩过不少坑。最典型的场景是：丢给模型一个需求，比如“写一个定时任务管理模块”，几秒钟它就能吐出一大段代码，看起来结构完整、注释齐全，甚至还能自动生成一个README。但等真正执行起来，问题就暴露了：边界条件没处理、异常路径没有测试、依赖关系与当前项目不一致，甚至核心逻辑和用户需求都错位了。这种“快”带来的是幻觉式自信，模型在回答时倾向于给你一个“看起来合理”的答案，而不是一个“能通过验证”的答案。

根本原因在于，传统聊天式的AI编程提示词缺少约束：没有明确的验收标准，没有测试用例，没有把大任务拆成小步骤的机制。AI生成得越多，后期人工修复的成本就越高。尤其是当上下文一长，模型会遗忘前面的约定，开始凭概率补全，这时候代码“跑得通”和代码“可靠”就完全是两码事了。

1.2 Superpowers到底往AI编程里加了什么

Superpowers的设计者和维护者从工程实践里总结出一个结论：AI编程想要可靠，不能只靠更聪明的模型，更不能靠更长的提示词，而是要靠一套固定的工作流。它把AI编程从“你问我答”变成“按流程推进”，具体加了四样东西：

• 规范驱动开发（Spec-Driven Development）：在写代码之前，先让AI与用户反复澄清需求，产出一份可验证的SPEC，后续所有实现都对照这份规范来。
• 测试驱动开发（TDD）：强制AI先写失败测试、再写实现、再做重构，用“红灯-绿灯-重构”循环约束每一步。
• 子代理（Subagents）：将大任务拆分成多个小任务，分别由独立的AI上下文执行，避免长上下文污染和注意力丢失。
• 技能包（Skills）：将头脑风暴、写SPEC、拆计划、执行计划、写测试、调试、代码评审这些环节固化成可复用的Markdown技能文件，AI按需加载。

这四件事本身都不是新概念，但把它们串成一个可复用的开源工作流，正是Superpowers的价值所在。它本质上是在告诉AI：你不是在“回答一个问题”，而是在“参与一个软件开发项目”，你必须遵守工程流程。

1.3 这个项目适合哪些人和哪些场景

从我的实际体验看，Superpowers的思路并不适合所有用法。如果你只是临时写个脚本、做个原型demo，直接对话式生成就够了，引入这套工作流反而有点重。但如果你在做这几类事情，它的价值就体现出来了：

• 你正在用AI编程代理维护一个真实项目，代码要持续演进、要有人接手维护；
• 你需要AI完成的不只是“写一个函数”，而是“完成一个完整交付物”，比如一个小型CLI工具、一个Web服务、一个数据迁移脚本；
• 你对现有AI生成的代码质量不放心，希望让它先写测试来证明自己；
• 你想给团队成员建立一套统一的AI协作流程，而不是每个人凭感觉乱写提示词；
• 你在研究agent编程范式，想知道“技能+子代理”怎么组合起来产生工程级效果。

另外，如果你是一个提示词工程爱好者，这套skill的写法本身也很有参考价值：它展示了如何把复杂的开发方法论“翻译”成模型能准确理解的Markdown指令。所以即使不用Superpowers原封不动，读一读它的技能文件也能收获很多。

2. 核心优势与技术拆解：可靠来自结构性约束

2.1 以Spec为中心，而不是以“生成结果”为中心

普通AI编程是“目标导向”的：你告诉模型要做什么，它直接生成结果。Superpowers则是“流程导向”的：它先把目标转化为一份可以进行验收的规范，再让AI照着规范工作。

为什么要这样做？打个比方：如果你让装修师傅“随便装个厨房”，师傅手再快，你也不敢就这么住进去。但如果你先和他确定台面尺寸、水电点位、开关品牌，他再动手装，每一步都有据可查。Spec就是这份“装修图纸”。Superpowers里的brainstorm、writing-specs这两个技能，干的其实就是“画图纸”的活。

一份合格的SPEC不只写“我要什么功能”，还要写清楚：

• 背景与动机：为什么需要这个功能，解决谁的什么问题；
• 用户故事/用例：谁在什么条件下会触发什么操作，期望得到什么结果；
• 边界条件：输入为空、错误参数、并发、权限不足等情况下系统应该如何表现；
• 验收标准：具体到“运行某条命令应该输出什么”“某个接口在某种状态下应该返回什么”；
• 非目标（Non-Goals）：明确告诉AI“这次不用做登录、不用做权限、不用做日志”，防止它扩展超出你的预期。

Superpowers会要求AI先通过提问把需求里的模糊点全部确认清楚，再把这些内容写入SPEC文件。这一步看起来“浪费时间”，实则是在用前期的低成本沟通，换取后期高成本的返工避免。我实测下来，花在SPEC上的时间占总耗时的30%到40%，但后续的实现和调试环节省下来的时间远超这个数。

2.2 TDD如何成为AI编程的“安全气囊”

在传统开发中，测试是保障质量的手段；在Superpowers的体系里，测试是给AI编程用的“安全带”。为什么？因为AI有一个非常典型的毛病：它认为自己生成的代码是对的。让它自己检查自己的输出，它通常会回答“我觉得没问题”，但这不是验证，只是自信。测试则是把判断标准从“我觉得”换成“机器告诉我”。

Superpowers强制采用TDD循环，具体到AI执行层面是：

1. 根据当前任务和SPEC，先写一个失败的测试，明确描述期望行为；
2. 运行测试，确认它确实失败（红灯）；
3. 编写最小化的实现代码让测试通过（绿灯）；
4. 运行全量相关测试，确认没有破坏其他行为；
5. 如果有重构必要，在测试保护下进行重构。

这套循环能给AI提供三样东西：清晰的目标、即时的反馈、以及安全的范围。目标就是“让失败的测试通过”；反馈是测试的运行结果；范围由测试定义，只要测试不要求改变，AI就不应该额外发挥。这也是为什么我觉得Superpowers真正强大的地方——它本质上是用工程手段对抗模型的“自由发挥倾向”。

需要注意，这里的“测试”不一定非要是完整的测试框架。对小型脚本，一个断言脚本或一个命令行验证命令也可以。关键是结果必须是机器可判定的，不能是“人类目测觉得没问题”。

2.3 子代理：把单个AI的“长会话”拆成多个专注力

用过一段时间AI编程的人都会遇到一个问题：对话一长，模型开始忘记之前的约定。前十分钟它还在严格遵守你的代码风格，后十分钟就放飞自我了；前面定义的工具类，后面它凭空发明了一个新类。这是因为所有信息都在同一份上下文里，注意力被稀释了。

Superpowers用“子代理”来解决这个问题。它不是简单地在主对话里“开启多线程”，而是按任务创建独立的AI会话上下文，每个子代理只专注于一个明确的小目标。比如：

• 规划子代理：读取SPEC，负责任务拆分，生成PLAN文件，不负责写代码；
• 执行子代理：读取PLAN里的单个任务，专注于写测试和实现；
• 审查子代理：读取实现结果和SPEC，逐条核查验收标准，生成代码评审意见。

每个子代理拿到的是“与当前任务相关的精简上下文”，而不是整段历史对话。这就像把一个什么都要管的大项目经理替换成一支分工明确的专业团队：规划的人管规划，写代码的人管写代码，审查的人管审查。单个代理的上下文更短、目标更清晰，生成的可靠性和一致性自然更高。

2.4 核心Skills清单与它们分别管什么

Superpowers里内置了几十个skill，但实际上高频用到的主要是下面几个，我按使用频率列一下：

每个skill本质上是“一段带流程的指令文件”，里面写了触发条件、执行步骤、必要的输出格式。主AI看到用户的意图后，会按技能文件里的描述去执行。引入技能的方式，不是说你把技能文件目录放到某个位置，AI就自动全盘遵守；它需要你在CLAUDE.md这种“全局人格文件”里明确声明，让AI知道该读哪些技能、优先读哪一个、在什么阶段调用哪一个。

3. 安装与初始化配置：一步步引入技能

3.1 准备环境与前置条件

在开始安装Superpowers之前，我先说清楚需要准备什么。Superpowers本身不是可执行程序，而是一套“技能库+工作流配置”，因此它需要一个能支持Agent Skills机制的AI编程CLI工具作为宿主。市面上目前主流的选择包括Claude Code这类命令行工具，它们的共同特点是：运行在终端里、可以读写文件、能执行命令、支持通过Markdown文件加载自定义技能。

除了AI编程CLI，你还需要准备：

• Git：用来拉取Superpowers仓库和跟踪配置变更；
• Node.js或Python：具体取决于你要开发的项目类型，主要用来运行测试；
• 一个测试框架或最小验证脚本：哪怕是简单的断言脚本，也能保证TDD循环真的“跑得起来”。

不同AI编程CLI读取技能的方式可能不同，有的从项目的.claude/skills目录读取，有的从全局配置目录读取，所以安装前先看一下宿主工具的官方文档，确认技能目录的读取和覆盖顺序。思路是相通的，只是路径和名称有差异。

3.2 获取Superpowers技能仓库

Superpowers的源码托管在GitHub上，安装方式有几种，我推荐对新手最稳的方案：直接把技能仓库克隆到你的项目里，用独立目录管理。

git clone https://github.com/obra/superpowers.git .superpowers

这么做的好处是：技能目录和项目代码放在一起，项目成员克隆代码后就能顺手拿到同版本技能，不会出现“你的AI用了新版技能，我的还是旧版”的分歧。如果你是单机使用，也可以克隆到~/.superpowers目录，再在全局配置里指向它。

还有一类方式是通过AI编程工具的“市场（Marketplace）”机制安装，即在工具内添加Superpowers插件市场地址，然后通过市场命令加载。这种方式更新更方便，但对新手来说多了一层理解成本。我更建议先从“克隆到本地目录”入手，等熟练了再切换到市场方式。

3.3 配置全局与项目级CLAUDE.md

拿到技能文件后，最关键的一步是让AI知道去哪里读技能、以及遵循什么工作流。以Claude Code这类CLI为例，CLAUDE.md就是AI的“人格说明书”，你可以把它放到全局用户目录，让它影响所有项目；也可以放到项目根目录，只影响当前项目。

我个人的习惯是：全局CLAUDE.md里只做轻量约束，项目级CLAUDE.md里做完整配置。因为不同项目的技能需求、测试工具、代码规范都不一样，全局写得太重反而碍事。一个典型的项目级CLAUDE.md内容如下：

# 项目AI协作规范 - 优先读取 .superpowers/skills 目录下的所有技能定义，并遵循其中的流程。 - 任何功能开发默认采用规范驱动开发：先澄清需求，再编写SPEC，再做计划，最后实现。 - 默认采用TDD：先写失败测试，再写实现，直到测试通过。 - 大任务必须拆分为子任务，并使用子代理执行，禁止在主会话中无限制累积上下文。 - 遇到测试失败时，使用debugging技能系统化定位，禁止直接重写全部代码。

写完这份配置后，重启AI编程会话，让CLAUDE.md重新加载。这里有个容易踩的坑：很多CLI工具只有在会话启动时才会读取CLAUDE.md，你在对话中临时修改它，当前会话可能不会生效，所以改完配置记得重开会话。

3.4 验证技能是否加载成功

安装和配置完成后，不要急着开始写业务代码。先做一次加载验证，让AI“自报家门”：

请列出你可以使用的全部skills，并按你当前的系统提示说明，告诉我执行一个功能开发任务时你会按什么顺序调用它们。

一个正常的响应应能列出“superpowers”相关的技能名称，并给出类似“先brainstorming，再writing-specs，再planning，再执行计划并配合TDD”的顺序。如果AI回答“我没有加载到任何skills”，或者列举出的技能和Superpowers毫无关系，那就需要按下面的顺序排查：

1. 检查技能目录路径是否正确，目录名是否拼写准确；
2. 检查CLAUDE.md文件是否放在正确的生效位置；
3. 检查CLAUDE.md里是否明确写了“读取该技能目录”的指令；
4. 重开会话后再试一次。

我见过最多的情况是路径写错，比如仓库克隆到了.superpower（少了个s），或者CLAUDE.md放在了子目录里却没有被识别。细心核对一遍，基本能解决绝大部分加载失败问题。

4. 实操过程：从需求到可验证交付

4.1 先做头脑风暴，而不是先让AI写代码

我以一个具体场景带你走一遍完整流程：假设我想让AI帮我做一个“定时任务提醒CLI工具”，普通用法是直接让它写一个reminder.py；但用Superpowers的流程，第一步是启动brainstorming。

进入新会话，我发出如下提示：

请使用superpowers的brainstorming技能，和我一起梳理一个需求：我要做一个定时任务提醒CLI工具。 我们先不要写代码，先通过提问澄清所有我还没想清楚的问题。

AI会开始追问我问题，这恰恰是我过去最容易跳过的一步。比如它会问：

• 定时任务的来源是什么？是命令行参数、配置文件，还是数据库？
• 提醒方式是什么？终端弹窗、系统通知、还是发邮件？
• 定时精度要求如何？精确到分钟还是秒？
• 任务需要持久化吗？重启后任务是否保留？
• 是否需要支持周期任务，比如“每天上午9点”？
• 运行环境是个人电脑还是服务器？需不需要后台守护进程？

这些问题看着琐碎，但每一个都直接影响后续的数据结构设计。实践证明：如果这些不清楚就开写，AI大概率会做出“看起来都能用、但其实哪个场景都不完全对”的通用模块，最后还是要返工。

4.2 用SPEC把模糊想法固化成验收标准

头脑风暴结束后，我会让AI把澄清结果整理成规范文档：

请使用writing-specs技能，把我们刚刚确认的内容整理成一份SPEC文档，保存到项目根目录的SPEC.md。 验收标准必须写成可运行的命令或可断言的行为，尽量避免模糊形容词。

生成的SPEC应该包含类似下面的内容：

# 定时任务提醒CLI工具 SPEC ## 背景 用户需要一个在终端中创建定时任务并到点提醒的工具。 ## 用户用例 1. 用户通过命令 `reminder add --at "10:00" --message "开会"` 创建一个任务。 2. 用户通过命令 `reminder list` 查看所有未完成任务。 3. 到达指定时间后，终端输出 `提醒：开会`。 ## 验收标准 - 执行 `reminder add --at "10:00" --message "开会"` 后，返回任务ID，且任务出现在 `reminder list` 中。 - 将当前系统时间调至目标时间后，运行 `reminder check`，终端应输出“提醒：开会”。 - 不存在的任务ID执行 `reminder done {id}` 时应返回非零退出码及明确报错。 ## 非目标 - 不做Web界面，不做声音提醒，不做多用户权限。

我会和AI反复确认SPEC里的每一条验收标准。“终端应输出提醒”这个说法还可以更精确，比如是否包含时间格式、是否允许自定义前缀，这些细节都值得在SPEC阶段敲定。因为后面AI的实现完全参考这份SPEC，这里少一个细节，实现阶段AI就多一分自由发挥的空间，也就多一分偏差风险。

4.3 制定计划并派出子代理执行

SPEC确定之后，进入planning阶段：

请使用planning技能，把SPEC拆分为可独立执行的任务清单，保存为PLAN.md。 每个任务要尽量小，保证可以独立运行测试验证，并将任务分成“需要子代理执行”和“可以在主会话执行”两类。

好的计划拆分粒度，我建议控制在一个任务能在一个小时内完成的范围。比如：

1. 初始化项目结构，创建reminder.py入口和测试目录；
2. 实现任务存储模块：增删查任务，支持持久化；
3. 实现命令行参数解析：add、list、done、check；
4. 实现定时检查逻辑：读取任务、比对时间、输出提醒；
5. 为每个模块编写测试并生成验证报告。

Plan生成后，再让AI通过子代理执行某一部分：

请使用subagents技能，为任务2“实现任务存储模块”创建一个执行子代理。 子代理只读取SPEC.md和PLAN.md中与任务2相关的内容，完成实现并运行测试后，把结果汇报到主会话。

这里我强烈建议你亲自观察子代理的独立上下文：它应该只拿到与“任务存储模块”相关的信息，而不是整段长对话。如果它开始“回忆”你在brainstorm阶段说的某句无关话，那说明上下文隔离做得还不够。真正高效的做法是每个子代理都是一个短小精悍的“专职员工”，领到任务就专注完成，不关心其他人在干嘛。

4.4 TDD执行循环与代码审查收尾

在具体实现阶段，千万不要让AI一口气把计划里所有任务全写完。每跑完一个任务，就要让它先停一下，运行测试确认当前环节是绿的。我的典型提示是：

现在执行PLAN.md中的任务5“实现定时检查逻辑”。 请严格按照TDD流程：先写失败测试，再实现代码，再运行测试。 如果测试没有先失败就通过了，请调整测试使其覆盖真实行为。 完成后汇报：测试结果、修改了哪些文件、SPEC中哪些验收标准已经满足。

一次实操中，AI先写了一个check命令的测试，测试期望“到点后输出提醒”，但实现里只写了“打印所有任务”，第一个测试当然是失败的；AI接着实现循环比对逻辑，测试通过。这个过程虽然看起来“多写了一次测试”，但它保证了AI没有在测试还没定义清楚时就急着“自由发挥”。

全部实现完成后，让AI做code-review：

请使用code-review技能，对照SPEC.md逐一检查当前实现是否满足所有验收标准。 重点检查：是否有未处理的异常分支、是否有测试未覆盖的场景、是否存在与SPEC不一致的“额外发挥”。 输出格式：每条结论标注 [符合]/[不符合]/[存疑]，并给出证据。

这份审阅报告就是你决定“能否合入”的依据。如果AI在实现时悄悄加了一个SPEC里没提的“导出CSV功能”，review阶段就应该抓出来。因为它不是用户要的东西，加得越多，后期维护成本越高。

5. 常见问题与避坑指南：真实使用中的血泪教训

5.1 模型总是想办法跳过测试直接给实现

我在实际使用中最频繁遇到的问题，就是模型明明看到CLAUDE.md写着“默认采用TDD”，但一进入执行阶段还是直接开始写实现代码，测试被放在最后甚至根本不写。原因在于，模型以“让用户满意”为优先目标，而用户表面上最想要的是“看到代码”，测试只是约束，它潜意识里认为代码比测试更“有用”。

对策有两个层面。第一层面是在CLAUDE.md里加强措辞，把“可以TDD”改成“禁止在测试未写的情况下编写实现代码，违规会直接导致项目失败”。第二层面是在执行提示里增加硬性检查步骤：“先调用TDD技能，将测试文件写入磁盘，运行测试确认失败，再写实现。”如果模型仍然跳过，不要继续对话，直接中断它的回答，让它“回滚刚才的修改，按TDD流程重新执行”。不要留任何妥协空间，否则它会不断试探边界。

5.2 SPEC写成了“产品说明书”，但无法驱动验证

这是另一个常见毛病：我让AI编写SPEC，结果它写出来的是“系统应支持定时任务”“系统应具备良好的可扩展性”这种正确的废话。这种SPEC没法驱动AI的行为，因为AI在实现阶段无法判断“良好扩展性”怎么算达标。

解决办法是在SPEC阶段就要求“每一条验收标准必须对应一个可执行命令或断言”。我给AI立了一条规则：如果某条验收标准不能用“运行X命令，观察Y输出”的句式表达，那它就不是验收标准，而是宣传文案。比如“提供清晰的用户反馈”要改成“当用户执行不存在的任务ID时，命令返回退出码1，并在stderr输出包含task not found的报错信息”。只有把标准压到这个颗粒度，TDD的测试编写才有着落点。

5.3 技能明明安装了，但AI“假装没看见”

偶尔会遇到这种情况：技能文件目录存在，CLAUDE.md里也写了，但AI的响应完全不像加载了技能，从头到尾就是个普通对话。我排查过几轮后发现，问题通常出在“约束优先级”上。如果CLAUDE.md里的指令是“尽量遵循”，模型就会把它当成“可选项”，一忙起来就忘了。你需要把“必须”这个词写出来：必须、绝对、否则禁止。

另外，每个AI工具对系统提示、CLAUDE.md、用户消息的优先级排序可能不同。Superpowers的作者也提到过，如果你想让工作流绝对生效，可能需要把关键约束同时放到“项目记忆文件”和“用户首轮消息”里双层声明。我的做法是：项目CLAUDE.md里放完整规则，然后在每轮关键任务开始时都追加一句“按项目规则执行，即spec→plan→tdd”，相当于双重保险。

5.4 任务执行到一半“上下文失控”，代码风格开始漂移

如果在主会话里一口气让AI实现完整PLAN，到了第四个任务时，它往往会开始丢前面的约定：之前用的变量命名风格，后面变了；之前定义了某个工具类，后面又重新发明了一个类似但不同名的类。这就是上下文污染的典型症状。

Superpowers的方案是“尽快拆分子代理”。但作为使用者，你还需要养成一个习惯：主会话只做管理和验收，不做具体实现。每当主会话的上下文开始积累到一定长度，就重新开一个会话，只让它读取PLAN.md和当前项目状态，要从“上一个任务的结果”继续，而不是从“历史对话”继续。把PLAN文件当成唯一的跨会话记忆，这样每个新会话都是从同一份可靠状态出发。

5.5 权限与代码库安全：别让AI“放手去干”

最后一条是安全提醒。Superpowers这类工作流往往赋予AI“运行命令”和“修改文件”的权限，这在提高效率的同时也放大了风险。不要在一开始就把整个仓库的读写权限都交给AI，也别让它“自由探索内部结构”。我建议先给它最小必要权限：

• 允许读取SPEC、PLAN、当前模块文件；
• 允许运行测试命令；
• 对修改操作，要求先给出diff再执行；
• 涉及依赖安装、删除文件、影响全库的操作，必须报告后由你确认。

更保守的做法是在单独的测试分支里运行整个工作流，验证SPEC和计划跑通了，再合入主干。我听说过不少“AI把没写完的代码合进主分支”的案例，基本都是因为权限放得太宽、流程又没卡住。

一点个人体会

Superpowers并不是什么神奇的提示词，它是一套“用工程流程约束AI行为”的实践方案。我用了大约一周后，最明显的变化不是代码生成得更快，而是“返工少了”。过去AI给我一个功能，我可能要花半小时查边界、补测试；现在这些事在流程里被前置了。它让我开始重新思考AI编程这件事：与其追求让模型一次性生成非常多的代码，不如为它搭建一个绝对可靠的流程，让它在流程里一步一个脚印地产出。真正开始用的时候，别贪多，先拿一个小项目完整跑一遍兄弟，你会发现，慢下来，反而更快。