在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执行层面是根据当前任务和SPEC先写一个失败的测试明确描述期望行为运行测试确认它确实失败红灯编写最小化的实现代码让测试通过绿灯运行全量相关测试确认没有破坏其他行为如果有重构必要在测试保护下进行重构。这套循环能给AI提供三样东西清晰的目标、即时的反馈、以及安全的范围。目标就是“让失败的测试通过”反馈是测试的运行结果范围由测试定义只要测试不要求改变AI就不应该额外发挥。这也是为什么我觉得Superpowers真正强大的地方——它本质上是用工程手段对抗模型的“自由发挥倾向”。需要注意这里的“测试”不一定非要是完整的测试框架。对小型脚本一个断言脚本或一个命令行验证命令也可以。关键是结果必须是机器可判定的不能是“人类目测觉得没问题”。2.3 子代理把单个AI的“长会话”拆成多个专注力用过一段时间AI编程的人都会遇到一个问题对话一长模型开始忘记之前的约定。前十分钟它还在严格遵守你的代码风格后十分钟就放飞自我了前面定义的工具类后面它凭空发明了一个新类。这是因为所有信息都在同一份上下文里注意力被稀释了。Superpowers用“子代理”来解决这个问题。它不是简单地在主对话里“开启多线程”而是按任务创建独立的AI会话上下文每个子代理只专注于一个明确的小目标。比如规划子代理读取SPEC负责任务拆分生成PLAN文件不负责写代码执行子代理读取PLAN里的单个任务专注于写测试和实现审查子代理读取实现结果和SPEC逐条核查验收标准生成代码评审意见。每个子代理拿到的是“与当前任务相关的精简上下文”而不是整段历史对话。这就像把一个什么都要管的大项目经理替换成一支分工明确的专业团队规划的人管规划写代码的人管写代码审查的人管审查。单个代理的上下文更短、目标更清晰生成的可靠性和一致性自然更高。2.4 核心Skills清单与它们分别管什么Superpowers里内置了几十个skill但实际上高频用到的主要是下面几个我按使用频率列一下技能名作用典型触发场景brainstorming澄清需求、发散问题、讨论方案拿到一个新需求但还没想清楚时writing-specs把需求固化成可验收的SPEC文档确定要做什么之后、写代码之前planning将SPEC拆分为可执行的任务计划需要把大目标拆成小步骤时executing-plans按计划逐步实现并在每步做验证开始写代码或驱动多个子代理时TDD相关技能强制先写测试再写实现任何功能开发、bug修复debugging按系统化流程定位和修复问题测试失败、运行报错时code-review对照SPEC审查已实现代码功能完成后、merge之前subagents相关生成并管理多个子代理上下文任务量较大、上下文开始拖垮主会话时每个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毫无关系那就需要按下面的顺序排查检查技能目录路径是否正确目录名是否拼写准确检查CLAUDE.md文件是否放在正确的生效位置检查CLAUDE.md里是否明确写了“读取该技能目录”的指令重开会话后再试一次。我见过最多的情况是路径写错比如仓库克隆到了.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。 每个任务要尽量小保证可以独立运行测试验证并将任务分成“需要子代理执行”和“可以在主会话执行”两类。好的计划拆分粒度我建议控制在一个任务能在一个小时内完成的范围。比如初始化项目结构创建reminder.py入口和测试目录实现任务存储模块增删查任务支持持久化实现命令行参数解析add、list、done、check实现定时检查逻辑读取任务、比对时间、输出提醒为每个模块编写测试并生成验证报告。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编程这件事与其追求让模型一次性生成非常多的代码不如为它搭建一个绝对可靠的流程让它在流程里一步一个脚印地产出。真正开始用的时候别贪多先拿一个小项目完整跑一遍兄弟你会发现慢下来反而更快。