最近几个月我用AI编程工具写代码的时间比手动敲键盘的时间还多。最直观的感受是“快”需求一讲代码马上就出来了看起来像模像样跑起来也能完成主流程。但真正让我睡不着觉的也是这些“快”。功能改完了旁边被连带改掉的配置没人发现测试全绿了绿的原因是断言写反了做到一半断了会话新开的AI完全不知道前面干了什么乱接一段继续干。这就是典型的“快而不稳”速度上来了可靠性反而成了最大的短板。直到我上手了Superpowers才慢慢把这两件事重新对齐速度可以保留但过程必须可控、结果必须可验证。它不是另一个IDE也不是代码生成器而是一套和AI编程工具配合使用的技能框架核心思路是让AI在一个可见的状态机里干活先列计划、再写测试、小步实现、如实汇报。这篇文章我就从“为什么AI编程不可靠”这个痛点讲起把Superpowers的安装、核心机制、完整工作流以及我实际踩过的坑一次性说清楚。1. 快而不稳AI编程的“速度快”正在透支“可信度”1.1 为什么AI写代码很快却总让人心里没底先说个扎心的结论AI写代码快的本质是它把“生成代码”这件事做得太好了但把“编程”的其他环节——理解上下文、确认边界、验证结果、维护一致性——做得并不可靠。普通对话式AI编程的流程通常是这样的你丢一句“帮我加一个导出功能”AI直接改代码改完回一句“已完成”。如果你不问它不会主动告诉你改了哪几个文件也不会告诉你它默认删掉了某个不相关但“看起来没用”的函数。问题是代码不是文字。文字写错了读者最多理解偏代码改错了轻则编译失败重则线上事故。我把这比作让一个手脚麻利的实习生直接改生产代码他速度快但你没有给他交代验收标准他也没有任务清单更不会主动汇报风险。结果就是他交上来一个“他认为完成了”的东西而你在验收时才发现所有你认为“理所当然该保留”的东西都被他的“合理性判断”处理掉了。AI的不靠谱本质上不是能力问题而是过程不可控的问题。1.2 我反复踩到的三次典型翻车这里说三个我真实遇到过的案例基本代表了“AI编程不可靠”的三种典型形态。第一次是改导出功能的时候AI顺手删掉了另一个模块里“看着没被引用”的常量结果那个模块在特定配置下直接崩了。报错信息出来以后AI自动进入“自我修复循环”先加一个兼容层再改一个调用方然后又发现两个新错误再改……最后它交出来的代码能跑通测试但整个改动涉及了完全不该动的六个文件。第二次是测试假阳性。AI写了个测试跑了一下说“全部通过”。我后来检查发现测试里的断言比较的是两个相同的临时变量相当于自己和自己比。这比不写测试更危险因为它在给你制造“好像很可靠”的错觉。第三次是长任务中断。在一个大一点的改动里做到一半我把会话关了。第二天重新开了一个新会话AI完全不知道昨天的进展照着旧代码继续写把已经改好的部分又覆盖了一部分最后整个工作区处于一种“两套逻辑混在一起”的状态。这三个案例问题都不在“生成速度”。就算AI生成快十倍只要过程不可控、结果不可验证这些坑就会换个面目继续出现。所以真正需要改变的不是换更强的模型而是给AI一个可执行、可追踪、可审批的工作规范。Superpowers就是冲着这个问题来的。2. Superpowers是什么一套给AI的“工作规范”不是一个IDE2.1 它到底解决了什么问题很多人第一次听到Superpowers会以为它是一个编程IDE或者一个代码补全插件。实际上它是一套提示词驱动的“技能框架”skills framework。你可以把它理解成给AI编程工具装上了一套“岗位说明书操作SOP”。Superpowers本身不写代码也不编译代码。它做的事情是告诉AI接到需求以后先别急着写实现先去做调研、拆任务、列清单每做一个任务之前先想清楚怎么验证做完一个任务之后必须更新状态记录让下一个任务和下一个会话都知道当前进展遇到不确定的地方要主动报告而不是自作主张。它和Codex CLI、Claude Code这类工具的配合方式就像给一个经验丰富但纪律性差的程序员配了一个严格的项目经理。AI仍然是那个“快”的执行者但Superpowers负责给它的工作加上节奏和护栏。这里有个很关键的理念转变不要指望AI从模型层面变得“可靠”而是要在工作流层面设计一套机制让不可靠的行为被及时暴露和纠正。可靠性不是模型的天赋而是流程的产品。2.2 三个核心概念States、Skills、Goals深入用下来Superpowers最核心的三个概念是States状态、Skills技能、Goals目标。这三者分别回答的是“AI现在在哪”、“AI会做什么”、“AI要去哪”。概念作用直观理解States状态记录当前工作进展、下一步计划、遇到的阻碍项目共享的“工作日志”AI和人都能看Skills技能一组按场景组织的指令包比如拆任务、写测试、修复问题AI的“工具箱”按需调用Goals目标把大需求拆解成可验证的小任务清单一份带验收标准的待办事项列表拿做菜打比方普通的AI编程像是直接把所有食材丢给一个大厨让他自由发挥你只能等上菜Superpowers则是先给你一份带检查点的菜谱切配阶段、调味阶段、火候阶段每个阶段都有明确的操作步骤和验收标准做完一步打一个勾你随时可以进厨房检查。AI还是那个厨子但流程不再靠“感觉”了。2.3 “驾驶座”隐喻谁才是项目的负责人Superpowers还有一个很反直觉的设计它刻意让AI慢下来。在默认工作流里AI接到需求后第一件事不是写代码而是生成一份任务清单等你确认。这个“等确认”的动作就是整篇文章标题里“可靠”二字的起点。我特别喜欢它的一个比喻AI是“副驾驶”人类是“驾驶员”。副驾驶可以帮忙看路、提醒限速、提出建议但方向盘和油门始终在驾驶员手里。一旦副驾驶抢方向盘——也就是AI自作主张改了一个没在清单上的文件——Superpowers会通过状态机制把这个越界行为暴露出来让你能及时发现并纠正。这和“多轮对话式编程”有本质区别对话式编程里AI的每一次行动都是基于它自己对上下文的理解而你很难判断它理解到了哪一步Superpowers把AI的“心理活动”变成了一个可见、可查、可审批的状态文件。你不需要猜它在想什么只需要看它记了什么。3. 落地准备从克隆仓库到第一次跑通技能3.1 前置要求与工具选择Superpowers不是完全独立运行的工具它需要挂载到一个支持“skills机制”的AI编程CLI上。目前社区里用得比较多的两个载体是Claude Code和Codex CLI。我自己是两边都试过Claude Code对自然语言指令的理解更细腻Codex CLI和GitHub工作流结合得更自然。你选哪个都行关键是确认你用的CLI版本支持加载外部skills目录。除了CLI本身你还需要准备一个能跑Node或Python的基础环境具体取决于你的CLI载体、Git命令行工具以及一个有效的API访问权限。Codex CLI这类工具通常需要你有对应的付费API额度——热搜词里那个“codex付费ai编程软件”说的就是这个意思它不是免费的但按量付费对个人开发者来说成本还算可控。3.2 安装与目录链接安装过程不复杂但有一个细节容易踩坑必须把Superpowers的skills目录链接到你的CLI实际会读取的技能目录里而不是放在某个自定义位置等着它自动发现。我当时在Claude Code环境下的操作大致是这样的地址以官方仓库为准# 第一步克隆Superpowers仓库到本地 git clone https://github.com/superpowers/superpowers.git ~/superpowers # 第二步把skills目录软链到Claude Code的技能目录 ln -s ~/superpowers/skills ~/.claude/skills如果你用的是Codex CLI那么路径一般对应~/.codex/skills原理相同。装完以后我建议先做一个“技能自检”用一句话要求AI列出当前项目启用的技能列表。如果AI能罗列出Superpowers相关的技能说明加载成功如果它一脸茫然多半是路径没对或者工具版本不支持。要特别提醒的是不同CLI工具对“技能”的加载方式有差异。有的工具要求技能目录下必须有特定格式的元信息文件有的工具只认特定文件夹层级。所以装完不验证等于白装这一步一定要做。3.3 第一个练习让AI生成一份任务清单安装成功后不要急着让它写功能。我强烈建议你的第一个练习是做“任务拆解”这是Superpowers最基础也最重要的能力。你可以在任意一个项目目录下启动CLI然后输入指令“请阅读当前项目结构和代码生成一份完整的任务清单按依赖关系排序。”如果Superpowers正常工作AI给出的回答会呈现出明显的三段式结构Work Summary本次工作的总结Next Task下一步要做的具体任务Blockers当前遇到的阻碍或需要用户确认的问题这和我第1节说的“自由发挥式回答”完全不一样。它不会直接说“好的我将帮你添加这个功能”而是会先给出一个计划并主动询问“在开始任务1之前有一个配置项需要你确认是否可以修改”看到这种回答出现你就可以放心了这套流程已经接管了AI的行为接下来要做的就是学会怎么用它的工作流来跑真实项目。4. 从需求到提交Superpowers工作流的一条完整链路4.1 工作流全景规划、拆分、执行、验证、记录用Superpowers跑一个真实需求完整链路大概是这样的步骤触发方式产出物目的1. 需求输入自然语言描述需求原始需求上下文让AI明确方向2. 任务拆解指令“生成任务清单”结构化Task List把大需求变成可执行单元3. 人类审批你审查任务清单确认或调整后的清单建立“人类掌舵”的边界4. 测试先行针对当前任务写测试失败状态的测试用例定义“完成”的标准5. 小步实现实现当前任务最小可运行的代码改动让变更可审查、可回滚6. 验证反馈运行测试通过/失败报告用事实验证而不是用“感觉”7. 状态更新更新状态文件新的Work Summary保证后续任务/会话知道进展这个流程看起来比普通对话式编程“啰嗦”得多但这正是可靠性的来源每一步都有检查点你可以随时喊停。4.2 实战演示给一个Node CLI工具加“--json”输出参数我拿最近一个真实需求来演示我的一个Node命令行工具默认输出的是人类可读的文本现在需要加一个--json参数让它输出结构化JSON方便别的程序调用。如果是以前用普通对话式AI我会直接说“加个--json参数输出JSON格式。”AI噼里啪啦改完测试也是绿的但JSON里到底有哪些字段、字段命名稳不稳定、错误信息有没有结构全靠它临场发挥。用Superpowers就不一样了。第一步我让它生成任务清单它的输出大意是Work Summary: - 已阅读项目入口文件发现当前输出逻辑集中在utils/formatter.js - 已确认CLI参数解析库为commander Next Task: - 任务1为 --json 参数补充单元测试验证对象字段名与嵌套结构 - 任务2实现 JSON 格式化函数保持与现有文本输出字段一致 - 任务3补充命令行参数解析测试覆盖错误参数场景 - 任务4更新 README 示例 Blockers: - 暂无阻碍但需要你确认 JSON 输出字段是否包含时间戳注意这里的“Blockers”字段AI主动把不确定的东西暴露出来而不是替我做决定。这就是前面说的“副驾驶提醒”。我确认字段方案之后它会先从任务1开始也就是写测试。测试代码里的断言全是“我给的数据应该输出什么”的预期结果。我特意检查了断言写法它确实是在测“真实函数输出和硬编码预期的差异”而不是自己和自己比。写完测试它会先跑一遍确认测试失败这是TDD的关键——先看到红色再写实现让测试变绿。整个过程中它一次只做任务1完成并更新状态文件后才申请进入任务2“任务1已完成测试已通过是否继续任务2”这就是和“一个提示词改到底”最大的区别你手里永远有一个“审批权”而AI的手里永远有一个“当前进度锚点”。4.3 为什么这条链路让代码更可靠把这条链路拆开看每个环节都在对抗一类不可靠因素任务拆解对抗“漏改”需求被拆成清单每个文件、每个函数都落到一个具体任务里不会出现“顺手改了另一个模块”。测试先行对抗“假完成”完成的标准是“测试通过”不是“AI觉得写完了”。小步实现对抗“大爆炸式改动”一个任务对应一条测试和一个小diff出问题能精准定位回滚也容易。状态更新对抗“失忆”状态文件记录每一步即使会话中断新会话也能从状态文件里恢复认知。可靠性从来不是靠“模型更聪明”堆出来的而是靠流程把“不可控”变成“可控”。5. 可靠性不是玄学Superpowers的三种制衡机制5.1 状态可见把AI的“心理活动”摊在桌面上在传统编程里代码评审靠看diff在AI编程里你连“AI当时心里在想什么”这个信息都没有。Superpowers解决这个问题的方式很朴素强制AI用一个结构化状态文件记录“我刚才做了什么、我接下来要做什么、我卡在哪”。这个状态文件就是项目里的“共享内存”。你随时可以打开看不用去猜AI有没有跑偏。如果它上一步说是“在修复测试”但状态文件里写的是“已经重写了三个模块”你立刻就能发现偏差。我自己的习惯是每完成一个任务就让AI把更新后的状态文件读一遍给我听显示在终端里。这不仅是在验证它有没有按规矩办事也是在下一次“无状态对话”开始前给新会话留一份可靠的交接文档。5.2 测试护栏把“我以为能跑”变成“证明能跑”Superpowers的测试优先不是简单地在提示词里加一句“请写测试”。它会要求AI明确描述“这条测试在验证什么行为”并且强制先让测试失败再写实现。这个“先失败”的设计极其重要如果你没看到红色就等于没证明存在一个可检测的回归。这里我特别想说一个很容易被忽视的点AI写的测试本身也可能有问题——比如断言写反、测了同样的东西或者跳过关键路径。所以我在实战中要求AI在每个测试文件里加一行注释说明“这个用例如果被破坏对应的是什么业务行为”并在测试报告里同时输出“新增用例数”和“修改用例数”。不要迷信所谓“全绿”要相信“测试确实验证了你以为它验证的东西”。就目前版本的模型能力来说让AI在Superpowers流程下写测试比我用普通对话让它写测试质量高得多。因为流程里每一步都在强化同一个信号测试是标准不是装饰品。5.3 审批门槛让AI提交“下一步计划”而不是直接执行最后一道制衡机制是“计划审批门槛”。Superpowers默认不让AI一口气把任务清单全跑完。它每完成一个小任务会停一下更新状态然后等你发出“继续”的指令再进入下一个任务。这种做法看起来拖慢了节奏但在复杂项目里它其实是把“不可逆的大错”拆成了“可逆的小错”。我举一个对比普通模式AI一口气改了8个文件测试挂了你都不知道是第几步开始错的。Superpowers模式AI每改1个文件就跑一次测试你现在就能看到这个文件是不是导火索。改错一个文件你只需要让它回滚这个小任务改错八个文件你只能动用git reset然后祈祷手速够快。审批门槛的本质是把一次性的高风险操作变成多次低风险的小操作。这也正是“可靠”这个词的工程含义。6. 我的踩坑记录与调优建议6.1 坑一任务粒度太大一个任务改动半个代码库我刚用Superpowers时不太会写“需求输入”总想着“既然AI这么强我一句话把整个模块讲了它自己会拆”。结果AI拆出来的任务清单里任务1直接是“重构数据层并调整所有调用方”。这种任务粒度跟没拆差不多。后来我学会了一个技巧在让AI生成任务清单之前先自己把需求按“可验证单元”切出一条粗边界。比如“先只做CLI参数解析再做输出格式化最后改文档”。AI在边界内拆出来的二级任务才真正可执行、可评审。任务粒度越小每个小步的可靠度越高整体出错的概率就越低。6.2 坑二状态文件冲突两个会话互相覆盖有一次我在两个终端窗口同时跑Superpowers一个在改前端一个在改后端。两个会话共用同一个状态文件结果后面的会话把前面会话的工作总结覆盖了。等到再开会话时AI完全丢失了前端那部分进度还以为是新需求。这个坑的根源很简单状态文件默认是单文件的没有并发控制。现在的解决方式也很简单一个项目同一个时间段内只开一个Superpowers主会话或者给不同分支配不同的状态文件路径。如果你想多线程推进项目请让AI先生成两份独立的任务清单分别关联各自的状态文件不要共用一个。6.3 坑三CLI工具不认全套技能不同CLI工具对skills目录结构的兼容性不一样。在Claude Code里跑通的技能挪到Codex CLI里可能完全不响应因为触发语法和加载机制有差异。这不是Superpowers的问题是工具生态还没完全统一。我的建议是先选定一个主力CLI把一套技能跑熟不要频繁切换。真要切换就给目标工具单独做一次技能自检以它实际加载到的技能列表为准别拿上一个环境的经验硬套。6.4 稳定使用后的三个习惯跑了一段Superpowers工作流之后我沉淀下来三个习惯分享给想上手的朋友第一每个实现任务之后人必须看一遍diff再放行。别嫌麻烦这段付出买来的是“AI不会偷偷改别的东西”的确定性。第二要求AI把“下一步计划”写成一条清晰的指令你自己评审它。比如它会写“下一步实现task 2修改formatter.js补充对应测试”。你如果觉得这个步骤有问题随时可以改不必拘泥于AI的计划。第三让AI维护一份面向人类的CHANGELOG。Superpowers本身侧重“过程管理”但变更日志是给同事和未来自己看的。我习惯每完成一组关联任务让AI更新一次变更日志“新增了--json参数影响CLI输出模块A的行为保持不变。”说到底Superpowers并不能把烂架构变成好架构也不能让一个没有测试习惯的团队突然变得严谨。它的价值在于让AI编程的每一步都变得可以检查、可以回滚、可以理解。当你不再需要祈祷“AI这次应该没乱改”而是可以直接翻开状态文件看它到底干了什么编程这件事才真正重新回到了“可靠”的轨道上。