去年我第一次用 AI 写代码时，最大的感受就是“快”——需求一说，代码哗啦就出来了。但这种快是有代价的：前三次对话里 AI 写得行云流水，第四次改动时它开始遗忘自己之前定义的函数签名，第五次会凭空引入一个不存在的 API，第六次我花了一个小时去修它刚引入的回归 bug。这种体验太普遍了，以至于很多人把“AI 编程不靠谱”当成定论。直到我开始使用一套叫 Superpowers 的技能包，才真正意识到，AI 编程从“快”走向“可靠”之间，差的不是模型智商，而是一层工程化的工作机制——也就是它到底有没有被赋予正确的思考习惯和验证闭环。
Superpowers 这个东西，说白了是一组可以注入 AI 编程助手的“技能包”，它让 AI 不再只是“你问一句、它答一段”的对话机器，而是被拆成一套带规划、带验证、带自我修正的工程流程。它适合的人群很明确：已经在用 Claude Code、Cursor 这类工具的开发者，尤其是那些发现“AI 写小脚本很爽、写正经项目就翻车”的人。这篇文章我会从 Superpowers 的核心机制讲起，把它的技能清单、安装方式、提示词写法和实际工作流完整拆开，顺带聊聊我实测后的一些心得和踩过的坑。
1. 快而不稳的代码，正在成为 AI 编程最大的隐性成本
1.1 “快”带来的幻觉与回归问题
我团队里有个同事做过一个很形象的比喻：用裸奔状态下的 AI 写代码，像雇了一个知识渊博但完全没有责任心的实习生。你让他查资料，他五分钟给你列十页笔记，看着头头是道；你让他负责一个模块，他前三天干劲十足，第四天开始自作主张地改接口，第五天他自己都记不清改过什么。最关键的问题是，你没法判断他什么时候在胡说。
这就是 AI 编程“快而不稳”的典型症状。我在实际项目里碰到最多的三类问题：
- 幻觉 API：AI 非常自信地调用一个看起来合理、实际上根本不存在的库函数。尤其在长上下文对话里，它可能基于训练数据里的某个相似项目“脑补”出一个接口。
- 上下文遗忘：对话到中后段，AI 会忘记项目早期约定的命名规范、目录结构、依赖版本，甚至把自己定义的函数签名改掉。
- 回归灾难：修 bug A 时顺手破坏了功能 B，而且因为没有测试覆盖，AI 自己完全没有察觉，直到用户反馈才发现。
这些问题单独看都是小事，但叠加在“快”这个前提上，就成了巨大的时间黑洞。我见过太多开发者兴奋地让 AI 半小时内生成了两千行代码，接下来的两周却一直在修这几千行代码产生的问题，最终算总账，效率比纯手写还低。
1.2 为什么“对话式编程”天然缺乏可靠性
要理解 Superpowers 的价值，先得明白普通对话式编程为什么会“不稳”。我拆了三个根因，它们比表面上的“模型不够聪明”要深层得多。
第一，AI 没有工程上下文的概念。你直接说“帮我写一个用户注册接口”，它可以写出很漂亮的代码，但它不知道你的项目里已经有了哪些公共类、哪里放工具函数、错误码规范是什么。它更像是在“真空环境里完成作业”，而不是在“代码库里动手术”。
第二，缺少验证闭环。代码写出来能不能跑、有没有边界漏洞、会不会破坏已有功能，这些问题如果 AI 不主动去验证，就只能靠人来兜底。传统的“人写代码→人测试→人修复”循环里，闭环是由人完成的；但在对话式编程里，AI 只做“写”这一环，验证被省略了，可靠自然无从谈起。
第三，没有任务拆解与阶段规划。面对一个中等规模的需求，普通 AI 对话往往一上来就写代码，而不是先做技术方案、拆任务、列验收条件。这一步跳过之后，AI 产出的代码往往缺少架构分层、异常处理和扩展性设计，因为它从第一步起就不知道“这条路要通向哪里”。
1.3 可靠性的本质：让 AI 拥有“工程习惯”而不是“灵光一现”
我自己做了大量对比之后得出了一个结论：模型的能力决定 AI 编码的“上限”，而工作流和技能决定它在实际项目里的“下限”。一个再聪明的模型，如果只是被当成一次性问答的工具使用，它的输出质量也会被对话模式本身拖累。反之，一个中等能力的模型，如果被注入了一套严谨的“工程习惯”，也能稳定地产出高质量代码。
这套“工程习惯”包括：动手编码前先读代码库结构、实现前先写测试或至少写清验收标准、修改后主动做回归检查、遇到错误先定位根因而不是打补丁——听起来都是人类工程师的基本素养，但 AI 不会自动具备，它需要被“注入”。Superpowers 本质上就是干这件事的：把那些资深工程师脑子里习以为常的方法论，转译成 AI 能理解、能执行、能逐步调用的“技能”。
2. Superpowers 的工作机制：它到底给 AI “加”了什么
2.1 从“万能提示词”到“可复用技能”
早些时候，大家喜欢在网上找所谓的“神仙提示词”，一长段话复制进对话框，指望 AI 突然变聪明。这类提示词确实有点用，但缺点也很明显：一次性、不可复用、没有版本管理、不同项目之间无法迁移。Superpowers 的设计思路完全不一样，它把能力封装成一个个独立的“技能（skill）”文件，每个技能有名字、有描述、有结构化的指令流程，AI 在需要的时候按需加载。
你可以把技能理解成给 AI 配了一本本“岗位操作手册”。比如有一个技能叫“Code Review”，那么当 AI 需要审查代码时，它不只输出“这段代码看着还行”，而是会按照手册里的步骤，逐项检查安全漏洞、边界条件、错误处理、命名可读性，最后生成结构化的 review 报告。这个过程是可重复的，同一个技能在十个不同项目里表现一致。
这套机制最早成型于各大 AI 编程工具的 Agent Skills 规范：一个技能通常由目录、描述文件、指令文档和若干辅助脚本组成。Superpowers 在这个规范上做了大量工程化沉淀，把最常见、最高频的编码场景都封装成了开箱即用的技能包，所以它不是一个单一工具，更像是一个“AI 编码技能库”。
2.2 按需加载与上下文压缩
Superpowers 的另一个关键设计是“按需加载”。AI 对话的上下文窗口是有限的，你把两万字的工程规范全塞进提示词里，不但浪费 token，还会稀释模型对当前任务注意力。技能的加载方式解决的正是这个问题。
具体来说，Superpowers 里的每个技能都有一段精简的“触发描述”。当对话中出现了匹配的场景时，AI 才把对应技能的完整指令读入上下文，执行完退出。这种机制保证了大部分时间模型都聚焦在当前任务，只在必要的节点才“翻开手册”。我在实测中的体感是：上下文被占用的量比过去那种“把全部规范写在 system prompt 里”的方式少了将近一半，而且模型对关键指令的遵从度明显更高。
2.3 技能内建验证闭环：让 AI 自己“检查作业”
这是 Superpowers 和普通“提示词工程”最本质的区别。我翻过不少技能包的源码，发现里面几乎每个技能都带验证步骤。比如“重构技能”里会明确写：重构完成后，必须运行测试套件、必须检查类型错误、必须对比重构前后公共 API 是否一致。换句话说，技能不是只教 AI “怎么做”，还强制它“做完必须证明自己没有搞坏东西”。
这一点听起来简单，实际效果却非常炸裂。过去 AI 改完代码，我问它“测过了吗”，它经常答“应该没问题吧”。注入验证技能之后，它会自己调用工程命令，把测试结果、类型检查结果贴到对话里，如果有问题，它会基于报错信息继续修复。等于把“编码-测试-修复”这个循环真正闭环在了 AI 自己的工作流里，而不是把测试负担全部甩给开发者。
3. 值得优先导入的 Superpowers 技能清单
3.1 规划类：动手编码之前，先让 AI 学会“想”
我最早导入 Superpowers 时，最不以为意的就是规划类技能，觉得这是花架子。结果用了几次之后，发现最省时间的就是它。
比较典型的两个技能：
- Spec-Driven Development（规格驱动开发）：它不是让 AI 直接写代码，而是要求 AI 先与用户确认需求，输出一份包含功能清单、验收标准、边界场景的技术规格，用户确认后才进入实现阶段。这个技能的价值在于，把“人脑里模糊的想法”翻译成“机器可验证的明确标准”，大幅减少后续返工。
- Codebase Impact Analysis（代码库影响分析）：在改动前，AI 先分析这个改动会触及哪些模块、哪些函数的调用方会受影响、需要同步更新哪些测试。这个技能尤其适合中大型项目，避免了 AI“只管改一处、不管炸一片”。
使用规划类技能之后的明显变化：AI 不再急着抛代码，而是先和你对齐方案。对于有经验的开发者来说，这个过程看似多花了几分钟，但节省的是后面几小时的重构时间。
3.2 实现类：让 AI 按工程规范“写代码”
实现环节 Superpowers 里我最常用的是这几个：
- Test-Driven Development（测试驱动开发）：技能强制 AI 先写失败的测试，再写实现，最后运行测试验证通过。注意，这个 TDD 技能和人类工程师的 TDD 有一点点不同，它更偏重“用测试约束 AI 行为”，因为你无法真的“看着它写代码”，但测试文件却是一个硬性的验收绑绳。
- Refactoring Guardian（重构保护）：在执行重构时，技能会要求 AI 先建立基线测试结果，再逐步重构，每完成一步就对比测试输出，并且明确禁止在一次重构中同时修改和功能无关的代码。
- Type-Safe Coding（类型安全意识）：适合 TypeScript、Python 这类语言，技能会注入“所有函数必须显式标注参数和返回类型”“禁止使用隐式 any”“外部数据必须做运行时校验”等规则。
这些技能的作用相当于给 AI 的“自由发挥”装上了护栏，让它尽情写代码，但必须在一定的规范边界内写。
3.3 验证类：让“检查”成为编码流程的一部分
验证类技能是我最推荐新手优先导入的，因为见效最快。装上之后，你对 AI 输出质量的信任程度会有质的提升。
常用技能清单里，Code Review是推荐的第一个。它会把审查拆成安全、性能、可读性、健壮性、一致性五个维度，逐项输出问题列表，并且每个问题都标注严重等级。Regression Checker则会在代码改动后，主动针对受影响模块生成并运行回归测试，输出“是否破坏已有功能”的结论。还有Edge Case Explorer，专门逼着 AI 列出当前输入可能出现的边界条件，并针对性地补测试。
我一向觉得，AI 编程工具最缺的从来不是“写代码”的能力，而是“对自己写的代码负责”的能力。验证类技能补上的正是这块短板。
3.4 修复类：从打补丁到定位根因
修复类技能在排障场景里作用特别大。普通模式下，AI 看到报错信息，经常直接给出一个“看起来能修好”的补丁，但修完可能引入新问题。Superpowers 里的修复类技能核心逻辑完全不同：先复现，再定位，最后出方案。
比如Bug Root-Cause Analyzer这个技能，会在收到 bug 描述后，强制 AI 按这些步骤走：
- 先要求用户提供完整的复现路径或最小复现样例；
- 用静态代码分析或运行时日志锁定异常发生的位置；
- 分析“现象-根因-触发条件”，把三者区分开；
- 给出两个以上候选修复方案，对比影响范围后再实施；
- 实施后必须运行相关测试，并说明为什么这个修复不会引发副作用。
这整套流程下来，AI 的角色就从一个“乱试药的实习生”变成了“先诊断后开方的医生”。我在实际项目里最深的一次体会是，用这个技能定位一个困扰我两天的并发 bug，它通过分析日志和代码路径，直接锁定了缓存过期逻辑里的一个竞态条件，比我手动排查快了太多。
4. 引入技能的两条路径：装现成的与写自己的
4.1 路径一：从仓库克隆安装
当前的 AI 编程技能生态里，很多开发者会把技能打包成标准目录结构分享在 GitHub 上。Superpowers 的安装，本质上就是把这些技能目录放进你 AI 编程工具指定的 skills 文件夹。
以常见的 Claude Code 工作流为例，大致步骤如下：
# 1. 进入你的 AI 工具工作目录 cd ~/.claude # 2. 如果有 skills 目录，直接进入；没有则新建 mkdir -p skills cd skills # 3. 从仓库获取你需要的技能包集合 git clone https://your-skill-repo/superpowers-skills.git当然，不同工具的 skills 目录位置各有不同。Cursor 里可能是在项目级.cursor/skills，Claude Code 则读取~/.claude/skills或项目级.claude/skills。装好之后，关键的验证步骤是重启你的 AI 编程工具，然后在对话中问一句：
你现在可以使用哪些技能？请列出所有你已加载的技能名称和作用。
如果安装成功，AI 会像报菜单一样列出一串技能名。我强烈建议你养成每次安装技能后都做这一步的习惯——我碰到过太多次“以为装好了，实际 AI 根本看不到”的尴尬情况。
4.2 路径二：动手写一个最小可用的自定义 skill
Superpowers 的价值不只是“拿来用”，更在于它提供了一套足够低门槛的自定义机制，让你可以把自己团队里的编码规范沉淀成技能。一个标准的 skill 其实只有两个核心部分：描述文件和一个指令文档。
下面是一个极简示例，定义一个“Python 接口参数校验”技能：
# .cursor/skills/python-input-validation/SKILL.md --- name: python_input_validation description: 当需要编写或修改 Python 函数时使用，用于强制对函数输入参数进行运行时校验。 --- ## 使用时机 - 用户要求新增 Python 函数 - 用户要求修改已有函数的参数逻辑 ## 执行规则 1. 所有函数必须对参数做类型检查，不满足时抛出 TypeError。 2. 所有函数必须对参数取值范围做约束，越界时抛出 ValueError。 3. 校验逻辑必须放在函数体最前面，并用独立 if 判断块实现。 4. 禁止使用 assert 做运行时参数校验，因为 assert 在优化模式下会被忽略。 5. 完成后必须生成一个覆盖“正常输入、类型错误、越界输入”的测试用例。这个文件的name是技能的标识，description是 AI 判断“何时调用该技能”的依据，执行规则是技能真正要注入的指令。把它放进 skills 目录后，AI 就会在你需要编写 Python 函数时自动按这套规则执行。
自己写 skill 的经验是：先从一个高频场景写起，比如“错误码规范”“日志格式规范”，跑顺之后再逐渐增加复杂技能。因为技能的本质是约束 AI 行为的指令，写太多反而会降低 AI 对关键规则的注意力。
4.3 技能加载的验证方法
技能装完之后，如何确认 AI 真的“懂”了这个技能？除了上面说的直接询问，还有一个更可靠的验证方法：给它一个明显的“测试用例”。
以自定义的“python_input_validation”为例，我会直接给 AI 发一条指令：
请编写一个函数 divide_numbers(a, b)，记得遵守可用的技能规范。
如果技能加载成功，AI 输出的函数会自带类型检查和取值范围校验，并主动提及它遵循了输入校验规范。如果输出和普通对话没有区别，那就要检查技能的description是否写得足够清晰，或者目录结构是否被正确识别。
请特别注意：技能不是装上就完了，它需要被“激活”在你的对话流程里。很多技能只有在提示词中明确提到“请使用 XX 技能”或者触发条件匹配时才会被加载。如果你在关键需求里想强制使用某个技能，最稳妥的方式是直接点名。
5. 工作流改造：从“帮我写个功能”到“按技能流程推进”
5.1 一套真实的“计划-编码-评审-修复”循环
Superpowers 真正发挥作用，不是靠单个技能，而是靠把几个技能串成一个完整的工作流。下面是我现在写中大型功能时固定使用的一套流程，你可以直接抄作业。
第一步，需求对齐。我会对 AI 说：
请使用 Spec-Driven Development 技能，先不要写代码。根据我下面这个需求，输出一份技术规格书，包括功能清单、验收标准、边界情况。我不确认之前不要进入实现阶段。
第二步，影响分析。确认规格后，再补一句：
在开始实现前，请使用 Codebase Impact Analysis 技能，列出本次改动涉及的文件、可能受影响的模块，以及需要更新的测试。
第三步，增量实现 + TDD。我会要求 AI：
请按 TDD 流程实现上面规格中的功能。每个功能模块先写测试，再写实现，并运行测试确认通过。一次只实现一个模块。
第四步，代码审查。等 AI 实现完，我会要求：
请使用 Code Review 技能，对本次所有改动做一次审查，按安全、性能、可读性、健壮性、一致性五个维度输出问题清单，并针对每个问题给出修改建议。
第五步，回归验证。最后追加：
请使用 Regression Checker 技能，针对本次改动的核心路径生成回归测试，并运行全部测试，输出最终结论。
这套流程走下来，AI 的角色非常清晰：它先做方案设计师，再做实现者，然后是自检员，最后是测试工程师。它在每个阶段的输出都被上一个阶段约束，也被下一个阶段验证，可靠性就是这么一环扣一环地建立起来的。
5.2 把技能强制“绑”进提示词的正确写法
很多人问我，用了 Superpowers 之后，提示词是不是就不用学了？我的答案是：招式还是得学，但学的重点变了。过去大家研究的是“如何让 AI 理解我的意图”，现在研究的是“如何让 AI 正确触发并执行技能”。
结合 Superpowers 的提示词，有三个关键写法，强烈建议记住：
第一，要在需求里指定触发技能的名称，不要指望 AI 自己领悟。比如你想让它看代码，不要只说“帮我看看这段代码有没有问题”，可以说“请使用 Code Review 技能审查下面代码”。
第二，明确约束 AI 在某个阶段的行为。比如“在实现之前，必须先输出技术方案，等我确认后再继续”，这种过程性约束会让工作流更像真正的工程协作。
第三，要求 AI 给出执行证据。比如“跑完测试后，把测试通过结果贴出来”“重构完成后，对比重构前后的公共接口列表”。这个要求是让技能里的验证闭环真正落地。
我写过的最典型的“技能绑定提示词”是下面这种句式：
请使用 [技能名称]，完成以下 [任务]。 执行步骤要求：[列出你期望的关键步骤，参考技能说明执行]。 完成后必须附上：[验证证据、测试结果、影响分析等]。
这套写法看起来简单，但在实际项目中非常稳，它既调用了技能，又补上了你对过程和结果的个性化要求。
5.3 也要知道什么时候不该用 Superpowers
并不是所有任务都需要技能包装。我现在的判断标准很简单：小型、一次性、没有复用价值的任务，裸用 AI 就够了；中型以上、多人维护、需求会迭代的任务，才值得走完整流程。
比如临时查一个正则表达式的写法、把一段 JSON 转成 YAML、生成一个一次性的数据脚本，这些场景你让 AI 快刀斩乱麻就好，走 TDD 流程纯属浪费。反之，一旦这个代码会长期存在、会被别人引用、会随着需求演进，那 Superpowers 的工作流就是必须的。成本收益的杠杆点在这里：可靠性的价值，是随着代码生命周期变长而指数级放大的。
6. 踩坑记录与效果观察
6.1 技能文档太长，直接把上下文喂爆
我开始用 Superpowers 时犯过一个典型错误：一次性导入了二十多个技能，其中几个技能文档本身就有三四千字，而且描述写得太“贪婪”。结果 AI 经常在无关场景里把技能加载进来，几轮对话之后，上下文窗口就被技能文档占满了，模型反而开始丢三落四。
后来我的解决方案很朴素：精简技能包袱，给技能文档瘦身。单个技能的执行规则尽量控制在 10 条以内，每一条都写成可执行的动作；描述部分写清楚触发场景和限制条件（比如“仅当用户明确提出要执行代码审查时使用”，而不是“当涉及代码质量时使用”）。多技能场景下，优先保留高频刚需技能，其他低频技能等用的时候再装配。
从实际效果看，技能数量和上下文压力之间存在明显的权衡，质量永远大于数量。我现在常用技能也就保留五六个核心的，其余的在需要时手动指定加载。
6.2 技能之间互相打架，AI 不知道该听谁的
另一个坑是技能规则冲突。最典型的一次，我同时启用了“TDD 技能”和“快速原型技能”，两个技能对“是否必须先写测试”给出了完全相反的指示。AI 在执行时一会儿按这个来，一会儿按那个来，输出混乱且不可预测。
排查了一圈，根因是技能描述里的触发条件设置得太宽泛，导致同一个任务命中了两个技能。我的处理方法是给每个技能加上明确的“边界排除”描述，比如在快速原型技能的 description 中写明“本技能仅适用于一次性探索性代码，不适用于需要长期维护的功能模块”。另外，如果在提示词里显式指定了某个技能，AI 应该优先执行用户点名的那个，这需要工具层面的支持，但我在实践中发现，手动点名使用哪个技能是最简单也最有效的冲突解决手段。
6.3 几组项目的实测对比：“快”和“可靠”不完全矛盾
最后聊聊效果。我在几个真实项目里分别用了纯对话模式和 Superpowers 技能工作流，拿三组数据做对比，体感非常明显。
在小型 CRUD 接口项目中，纯对话模式的首次生成速度确实快，大约节省了 30% 时间，但后续返工时间明显增加，总耗时反而比技能模式多了约 20%。在中型服务重构项目中，技能模式的优势最突出，因为它强制 AI 先做影响分析，避免了我最担心的“改一处、炸一片”，整体交付时间反而比纯对话模式快了近一倍——因为纯对话模式下，AI 自己修复回归 bug 的时间实在太长了。而在写测试这个环节上，技能模式下的测试覆盖率显著高于纯对话模式，更重要的是，AI 会主动检查边界条件，而不只是“按正常流程写一遍”。
数据之外的体验变化也很关键：纯对话模式下的代码，我每次合并之前都要人工 review 很久；技能模式下的代码，我 review 的压力明显减小了，因为 AI 自己已经跑过完整验证，我主要看的是业务逻辑对不对，而不是帮它查低级错误。这种“信任感”的提升，很难用数字量化，但对日常开发体验的影响其实是最大的。
6.4 关于 AI 编程可靠性，我最想分享的一句话
用 Superpowers 这几个月，我对“AI 编程可靠性”的理解发生了一些变化。可靠性不是某个神级提示词给的，也不是某个强大模型自然具备的，而是靠一层层机制“叠”出来的：需求阶段有规格约束，实现阶段有测试牵引，提交之前有代码审查，改完以后有回归验证。每一层机制单独看都不复杂，但叠加之后，AI 输出的质量会非常稳定。
如果你现在也被“AI 写代码很快但不靠谱”困扰，我的建议很直接：不要急着换更强的模型，先试着给现有的 AI 编程工作流加一层技能机制。Superpowers 的价值，从来不在于让 AI 写得更快，而在于让 AI 写完之后，你可以放心地说一句“这个改动，应该没问题了”。
