1. 从“superpowers”这个热词说起：它到底指什么
第一次看到“superpowers”这个词挂在热词榜上，我脑子里冒出来的第一个念头是：这又是哪个游戏或者影视作品里的梗？但翻了一圈讨论之后发现，大家聊的其实是给 AI 编程助手加装“超能力”的那套技能包机制。说白了，就是让原本只会按部就班写代码的 AI，突然学会了一整套“老司机的操作习惯”——比如先规划再动手、写完自己检查、遇到报错会排查、改完代码会跑测试。这套东西在社区里被叫做 superpowers，也有人直接叫它“技能包”或者“能力扩展”。
我之所以对这个话题感兴趣，是因为我自己用 AI 辅助写代码有一段时间了，最大的痛点就是：AI 写出来的东西看着像那么回事，但一跑就崩。它不会主动去想边界条件，不会考虑你项目里已有的代码风格，更不会在改完之后帮你验证一下有没有把别的地方搞坏。superpowers 这类机制的出现，本质上就是在解决这个问题——它不是让 AI 变得更“聪明”，而是让 AI 变得更“靠谱”。
这篇文章适合几类人看：一是刚开始接触 AI 编程助手、还没搞明白怎么让它稳定输出可用代码的新手；二是已经用了一段时间、但总觉得 AI 写的代码“差点意思”的开发者；三是想了解这套技能包机制背后设计思路的技术爱好者。我会从它解决什么问题、核心机制怎么运作、怎么安装配置、实际用起来什么感觉、以及踩过哪些坑这几个角度，把这件事讲透。
需要提前说明的是，superpowers 并不是某一个具体的软件产品，而是一类给 AI 助手注入结构化工作流程的扩展机制。不同的工具链下有不同的实现方式，但核心思路是相通的。下面我讲的内容，是基于社区里常见的实践方式和我自己的使用经验来展开的，具体到你的环境可能需要做适配。
2. 为什么裸奔的 AI 写代码总是不靠谱
2.1 一个真实的翻车场景
先讲个我自己的经历。前段时间我要给一个项目加一个“批量导出数据”的功能，需求不复杂：从数据库里查出一批记录，按条件过滤，然后生成一个文件让用户下载。我把需求描述丢给 AI，它刷刷刷给我写了一段代码，看起来逻辑清晰、命名规范，我复制粘贴进去，一跑——报错。
报错的原因很简单：它用了一个我项目里根本没引入的库。我回去看它的代码，发现它默认假设我用的是某个流行的框架，但实际上我的项目用的是另一套技术栈。这就是典型的“AI 不知道你的上下文”问题。它是在一个通用的知识库里生成代码，而不是在你的项目环境里思考。
更麻烦的是，当我告诉它“用某某库代替”之后，它改是改了，但改完之后又引入了新的问题：原来能跑的那部分逻辑被它顺手“优化”掉了。我不得不花时间逐行对比，才发现它在重构的时候把我一个关键的判空条件给删了。
这个场景我相信用过 AI 写代码的人都遇到过。问题的根源不在于 AI 的代码能力不行，而在于它缺少一套约束自己行为的流程。它就像一个技术很好但完全不看需求文档、不跑测试、不做代码审查的实习生，你让他写他就写，写完就交差，至于能不能用，那不是他考虑的事。
2.2 裸奔 AI 的四个典型毛病
我把这些问题归纳了一下，大概有这么几类：
第一，不主动获取上下文。AI 不会自己去读你的项目结构、配置文件、依赖列表。你不告诉它，它就按自己的默认假设来。这就导致它生成的代码经常和你的项目“水土不服”。
第二，不做计划直接动手。你给它一个稍微复杂点的需求，它不会先拆解任务、规划步骤，而是直接开始写。写到一半发现方向不对，又回头改，改来改去最后出来的东西逻辑混乱。
第三，写完不验证。代码生成完就结束了，它不会主动去跑一下测试、检查一下语法、看看有没有明显的逻辑漏洞。你得自己发现有问题再回去找它。
第四，改代码不看影响面。你让它改一个函数，它可能顺手把调用这个函数的其他地方也改了，但它不会告诉你它改了哪些地方，也不会评估这些改动会不会引入新的问题。
这四个毛病叠加在一起，就导致了一个结果：AI 生成的代码，你需要花大量时间去审查、修正、验证，省下来的时间又还回去了。superpowers 这类机制要解决的，就是这个问题。
2.3 superpowers 的核心思路：给 AI 装上“工作流”
superpowers 的本质，是把一套结构化的软件开发工作流注入到 AI 的行为模式里。它不是在教 AI 怎么写代码，而是在教 AI怎么像一个有经验的工程师一样工作。
具体来说，它给 AI 加上了这么几个“超能力”：
- 先规划再执行：接到任务后，先分析需求、拆解步骤、识别依赖，形成一个计划，然后再动手写代码。
- 主动获取上下文：在写代码之前，先去读项目里的相关文件，了解现有的代码风格、依赖库、目录结构。
- 写完自检：代码生成后，主动检查语法、逻辑、边界条件，发现问题自己先修一轮。
- 改完验证：修改代码后，跑一下相关的测试或者至少做一次静态检查，确认没有引入新的问题。
- 记录变更：清楚地告诉你它改了什么、为什么改、影响范围是什么。
这些能力单独看都不稀奇，但组合在一起，就让 AI 从一个“代码生成器”变成了一个“能独立完成任务的助手”。你给它的指令可以更粗粒度，比如“帮我加一个用户登录功能”，它会自己去规划、去读代码、去实现、去验证，最后给你一个可用的结果。
3. superpowers 的安装与配置：不同环境下的落地方式
3.1 先搞清楚你用的是哪套工具链
superpowers 不是一个独立的软件，它需要依附在某个 AI 编程助手之上。目前社区里讨论比较多的几套工具链，包括但不限于：
- 基于命令行的 AI 编程助手
- 集成在编辑器里的 AI 插件
- 独立运行的 AI 代码生成工具
不同的工具链，superpowers 的安装方式差别很大。有的是一组配置文件，你把它放到项目的特定目录下就能生效；有的是一个插件包，需要通过包管理器安装；还有的是通过 API 调用的方式，在请求里带上特定的参数来激活。
所以在动手之前，你得先确认两件事：你用的是哪个 AI 编程工具，以及这个工具是否支持技能包扩展机制。如果不支持，那 superpowers 就无从谈起。
3.2 通用安装流程拆解
虽然不同工具的安装细节不同，但大致的流程是相似的。我把它拆成几个步骤，你可以对照自己的环境来操作。
第一步：确认工具版本。很多技能包机制是在特定版本之后才支持的。你需要先检查你用的工具是不是最新版本，或者至少是支持扩展的版本。通常可以通过命令行输入版本查询命令来确认。
第二步：获取技能包文件。superpowers 的技能包通常以一组配置文件的形式存在，可能是一个目录，里面包含多个描述文件。你需要从社区仓库或者官方渠道获取这些文件。获取方式可能是直接下载压缩包，也可能是通过包管理器安装。
第三步：放置到正确的位置。这是最容易出错的一步。技能包文件需要放到工具能够识别的位置。常见的位置包括：项目的根目录下的特定文件夹、用户主目录下的配置文件夹、或者工具安装目录下的扩展文件夹。具体放哪里，取决于你用的工具。
第四步：激活技能包。有些工具会自动识别放置好的技能包，有些则需要你在配置文件里显式声明启用哪些技能。这一步通常需要编辑一个配置文件，把技能包的名称或者路径加进去。
第五步：验证是否生效。安装完成后，你需要验证一下技能包是否真的起作用了。验证方法通常是给 AI 发一个稍微复杂点的任务，观察它的行为有没有变化——比如它会不会先问你项目的情况，会不会在写代码之前先列一个计划。
3.3 配置文件的常见字段说明
技能包的配置文件通常包含这么几类信息：
| 字段类型 | 作用 | 常见取值示例 |
|---|---|---|
| 技能名称 | 标识这个技能叫什么 | plan-first, self-check, context-aware |
| 触发条件 | 什么情况下激活这个技能 | 收到代码生成请求时、修改文件时 |
| 行为描述 | 具体要 AI 做什么 | 先输出计划再写代码、写完检查语法 |
| 优先级 | 多个技能同时触发时的执行顺序 | 高、中、低 |
| 适用范围 | 对哪些文件类型或任务类型生效 | .java, .py, 所有文件 |
这些字段的具体名称和格式，不同工具链下会有差异。你需要参考你所使用工具的文档来填写。但核心逻辑是一样的：告诉 AI 在什么情况下、按照什么规则、做什么事情。
3.4 一个容易忽略的细节：技能包的加载顺序
我在配置的时候踩过一个坑：同时启用了多个技能包，结果它们之间产生了冲突。比如一个技能要求“先输出计划再写代码”，另一个技能要求“直接生成代码不要废话”，两个规则打架，AI 的行为就变得很奇怪，有时候输出计划有时候不输出，完全看它心情。
后来我才搞明白，技能包是有加载顺序的。后加载的技能可能会覆盖先加载的技能，或者两个技能同时生效时会产生不可预期的结果。解决办法是：明确指定技能的优先级，或者只启用你真正需要的技能。不要贪多，把一堆技能全打开，那样反而会让 AI 的行为变得不可预测。
4. 实际用起来是什么感觉：从“代码生成器”到“编程搭档”
4.1 一个完整的任务流程对比
为了让你直观感受到 superpowers 带来的变化，我拿一个实际任务来对比。任务很简单：给一个已有的 Java 项目加一个“根据用户 ID 查询订单列表”的接口。
没有 superpowers 的情况：
我：“帮我写一个根据用户 ID 查询订单列表的接口。”
AI 直接输出一段代码，包含 Controller、Service、Mapper 三层。代码看起来没问题，但我复制进去之后发现：它用的分页库和我项目里的不一样，它假设的返回格式和我项目里的统一响应格式不一致，它没有处理用户 ID 为空的情况。
我需要来回改好几轮，每次都要把项目的实际情况告诉它。
有 superpowers 的情况：
我：“帮我写一个根据用户 ID 查询订单列表的接口。”
AI 先输出一个计划：第一步，读取项目里的 Controller 示例，了解现有的接口风格；第二步，读取统一响应类的定义；第三步，确认分页库的使用方式；第四步，生成代码；第五步，自检边界条件。
然后它真的去读了项目里的文件，生成的代码直接就能用，连 import 都是对的。
这个对比的核心差异在于：AI 从“凭想象写代码”变成了“看着你的项目写代码”。它不再需要你反复纠正，因为它自己会去获取必要的信息。
4.2 规划能力带来的最大改变
superpowers 里我觉得最实用的一个能力是“先规划再执行”。这个能力看起来简单，但效果非常明显。
以前我给 AI 一个复杂任务，比如“重构这个模块，把里面的数据库操作抽离出来”，它会直接开始改代码，改到一半发现有些地方依赖了原来的结构，又回头调整，最后出来的结果往往不完整。
有了规划能力之后，它会先输出一个步骤列表：先识别所有数据库操作的位置，然后设计抽离后的接口，再逐个替换，最后跑测试验证。每一步做什么、先后顺序是什么，都列得清清楚楚。我可以在它动手之前先审查这个计划，觉得没问题再让它执行。如果计划有问题，我直接指出，它调整计划后再执行，避免了改到一半发现方向不对的情况。
这个能力对新手尤其友好，因为计划本身就是一份很好的学习材料。你可以看到一个有经验的工程师是怎么拆解任务的，哪些步骤是关键的，哪些地方容易出问题。
4.3 自检机制的实际效果
自检机制是另一个让我觉得“回不去了”的功能。以前 AI 写完代码，我得自己一行一行看，找语法错误、找逻辑漏洞、找边界条件没处理的地方。现在它会自己先过一遍，把明显的问题修掉。
我观察过它的自检过程，大致包括这么几类检查：
- 语法层面：括号有没有配对、分号有没有漏、变量有没有声明。
- 逻辑层面：条件判断有没有覆盖所有分支、循环有没有终止条件、空值有没有处理。
- 一致性层面：命名风格和项目里其他代码是否一致、异常处理方式是否统一。
- 依赖层面：引用的类和方法是否存在、import 是否完整。
当然，它的自检不是万能的，复杂业务逻辑的问题它不一定能发现。但至少那些低级的、明显的错误，它自己能修掉一大半。这给我省了很多时间。
4.4 上下文感知：让 AI 真正“看懂”你的项目
上下文感知这个能力，我觉得是 superpowers 里技术含量最高的一个。它让 AI 不再是一个孤立的代码生成器，而是能“看到”你项目全貌的助手。
具体来说，当它需要写一个功能时，它会主动去读相关的文件。比如要写一个 Service 类，它会先去看项目里已有的 Service 类是怎么写的，了解包名、注解、依赖注入方式、异常处理风格。然后它生成的代码就会和现有代码保持一致。
这个能力解决了一个很实际的问题：团队协作中的代码风格统一。以前 AI 生成的代码往往带着一股“通用模板”的味道，和项目里的代码风格格格不入。现在它生成的代码，放在项目里不会显得突兀，因为它就是照着项目里的风格写的。
5. 踩坑记录：那些文档里不会告诉你的问题
5.1 技能包和项目配置的冲突
我遇到过一个很隐蔽的问题：技能包启用后，AI 的行为变得很奇怪，有时候会输出一些和项目无关的内容。排查了很久才发现，是技能包里的某个规则和项目里的配置文件产生了冲突。
具体来说，技能包里有一条规则是“在生成代码前先输出计划”，而项目里有一个配置文件规定了“输出内容必须符合特定的格式”。两个规则同时生效时，AI 不知道该听谁的，就产生了一些混乱的输出。
解决办法是：检查技能包的规则和项目现有配置是否有重叠或冲突的地方。如果有，要么调整技能包的规则，要么在项目配置里明确优先级。这个问题在文档里通常不会提到，因为文档假设你是在一个干净的环境里使用技能包，但实际项目中往往有很多已有的配置。
5.2 技能过多导致的“过度思考”
刚开始用的时候，我恨不得把所有能开的技能都打开，觉得功能越多越好。结果发现，AI 变得“过度思考”了。一个简单的任务，它要规划半天、检查半天，输出一大堆中间过程，真正有用的代码反而被淹没在废话里。
后来我学乖了，根据任务类型来选择性地启用技能。写新功能的时候，开启规划和上下文感知；改 bug 的时候，开启自检和影响面分析；做简单修改的时候，只保留最基本的技能。这样 AI 的行为更聚焦，输出也更干净。
5.3 技能包更新后的兼容性问题
技能包本身也是会迭代的。我有一次更新了技能包版本之后，发现原来能正常工作的配置突然失效了。原因是新版本的技能包改了配置文件的格式，旧的配置不再被识别。
这个坑的教训是：更新技能包之前，先备份你的配置文件。更新之后，对照新版本的文档检查一下配置格式有没有变化。如果技能包提供了迁移工具或者兼容层，优先使用它们，而不是手动改配置。
5.4 对 AI 能力的边界要有清醒认识
superpowers 能让 AI 变得更靠谱，但它不能让 AI 变成万能。有些任务它依然做不好，比如：
- 需要深度业务理解的逻辑（它不知道你的业务规则）
- 涉及复杂算法优化的场景（它生成的算法可能不是最优的）
- 需要跨多个系统协调的任务（它只能看到当前项目）
我的经验是：把 superpowers 当作一个能力放大器，而不是一个替代品。它能帮你处理那些重复性的、模式化的编码任务，让你有更多时间专注于真正需要人类判断力的部分。但最终的代码审查、架构决策、业务逻辑确认，还是得你自己来。
6. 进阶玩法：把 superpowers 融入日常开发流程
6.1 为团队定制专属技能包
社区里通用的技能包解决的是共性问题，但每个团队都有自己的特殊情况。比如你们团队可能有一套特定的代码规范、一套特定的异常处理流程、一套特定的日志格式。这些都可以写成自定义的技能包。
自定义技能包的编写思路是：把你希望 AI 遵守的规则，用结构化的方式描述出来。比如“所有 Service 类必须继承 BaseService”“所有对外接口必须加权限注解”“所有数据库操作必须走统一的 DAO 层”。把这些规则写成技能包文件，AI 在生成代码时就会自动遵守。
这个做法的好处是，新人入职时，AI 就成了一个随时在线的代码规范教练。新人让 AI 写代码，AI 生成的代码天然符合团队规范，减少了代码审查时的来回修改。
6.2 结合代码审查流程使用
superpowers 的自检能力，可以和代码审查流程结合起来。我的做法是：让 AI 在提交代码之前先做一轮自检，把自检结果附在提交说明里。这样审查的人可以看到 AI 已经检查过哪些方面，重点关注那些 AI 检查不了的部分。
具体操作上，可以在技能包里加一条规则：在完成代码修改后，输出一份自检报告，内容包括修改了哪些文件、每个文件改了什么、做了哪些检查、还有哪些地方需要人工确认。这份报告直接贴到代码审查工具里，审查效率能提升不少。
6.3 用技能包来沉淀项目知识
每个项目都有一些“只有老员工才知道”的知识，比如某个模块为什么不能随便改、某个配置为什么不能动、某个接口为什么有奇怪的参数。这些知识以前只能靠口口相传，现在可以写成技能包规则。
比如你可以写一条规则：“修改 OrderService 时，必须检查 OrderStatusEnum 的兼容性，因为历史数据中存在已废弃的状态值。”AI 在修改相关代码时就会自动检查这个点，避免踩到历史遗留的坑。
这个用法的价值在于：把隐性的项目知识显性化、自动化。知识不再依赖某个人的记忆，而是变成了 AI 可以执行的规则。
6.4 多技能包的组合策略
当你有了多个技能包之后，怎么组合使用就成了一个问题。我的经验是，按照任务的生命周期来组合：
| 任务阶段 | 推荐启用的技能 | 目的 |
|---|---|---|
| 需求分析 | 规划、上下文感知 | 理解需求、了解项目现状 |
| 编码实现 | 上下文感知、代码风格 | 生成符合项目风格的代码 |
| 自测阶段 | 自检、边界检查 | 发现明显问题 |
| 提交审查 | 变更记录、影响分析 | 生成审查材料 |
| 部署验证 | 测试生成、验证 | 确认功能正常 |
这个组合不是固定的，你可以根据自己的习惯调整。核心原则是：每个阶段只启用当前最需要的技能，避免技能之间的干扰。
7. 我对 superpowers 这类机制的看法
用了一段时间之后，我最大的感受是：AI 编程助手的竞争，正在从“模型能力”转向“工作流能力”。以前大家比的是谁的模型更聪明、谁生成的代码更准确。但现在模型能力差距在缩小，真正拉开差距的是谁能把 AI 更好地融入到实际的开发流程中。
superpowers 这类机制的价值，不在于它让 AI 多写了多少代码，而在于它让 AI 写的代码更可用、更可控、更可预期。它把 AI 从一个“黑盒生成器”变成了一个“透明的工作伙伴”，你能看到它在想什么、做什么、检查什么，你可以在它工作的每个环节介入和调整。
当然，这套机制也不是没有代价的。它增加了配置的复杂度，需要你花时间去理解和调试。对于简单的、一次性的任务，可能直接让 AI 写反而更快。但对于长期的、团队协作的项目，这套机制带来的收益是明显的。
我个人的建议是：先从最简单的技能开始用起，比如只开启“先规划再执行”这一个能力。感受一下它带来的变化，然后再逐步增加其他技能。不要一上来就搞一套复杂的配置，那样很容易被各种问题劝退。等你对这套机制熟悉了，再根据自己的需求去定制和扩展。
最后说一个我自己的小技巧：我会定期回顾 AI 生成的代码，看看哪些地方它做得好、哪些地方还需要我修正。然后把那些反复出现的问题，写成新的技能包规则。这样 AI 就在不断“学习”我的偏好，生成的代码越来越符合我的预期。这个过程本身就是一种很有意思的体验——你在训练你的 AI 搭档，让它越来越懂你。
