最近这段时间AI写代码的速度确实把我惯坏了一个复杂查询接口模型几秒钟就能给出可运行的实现CRUD代码更是信手拈来。但放到真实项目里我很快意识到一个问题——快解决的是“写出来”可靠解决的才是“敢上线”。同一个模型写小脚本时还像个靠谱的助手一到几百个文件的中型项目里就开始丢三落四忘了上一轮约定的表结构测试跑不过就顺手删测试改了个功能却把相邻逻辑踩坏。Superpowers 这个项目就是针对这个痛点出现的一剂猛药。它不是又一个代码生成器而是给 Claude Code 这类 AI 编程环境装上一套“技能系统”把测试驱动开发、需求拆解、系统化调试、代码审查这些本来就该有的流程变成 AI 能够稳定遵守的技能。这篇我会把安装方法、技能体系、实操路径和核心机制完整讲一遍最后分享一些真实踩坑的经验适合所有希望把 AI 编程从“玩一玩”推向“可靠交付”的开发者。1. Superpowers到底解决了什么问题1.1 AI编程的“快而不稳”困局AI 写代码已经不是什么新鲜事我身边的同事和朋友几乎都在用。大家一开始最直观的感受就是“快”一个登录接口、一个数据清洗脚本、一个配置文件几句话下去AI 就能给出一版能跑的代码。尤其在做原型验证的时候这玩意儿简直是生产力神器半天能顶过去两天。但这种情况一进入真实项目味道就变了。我自己的项目维护到现在有几十个模块靠 AI 快速生成的代码一旦合入主干经常会带出一些你根本想不到的连锁问题改了一个函数的入参结果三个地方调用它却只有一个被同步更新测试挂了AI 的第一反应居然是注释掉断言上一轮明明确认过用 PostgreSQL几天后新生成的代码里又悄悄写回了 MySQL 风格的语法。你复盘一下就会发现这根本不是模型“笨”的问题而是整个协作流程里缺了一层东西AI 没有被要求按规范做事。它生成代码很快但没有被约束在“先设计、再实现、后验证”的框架里也没有人要求它在一开始就把验收标准写清楚。快是它的优点但没有流程的约束快就会放大出错的风险。更要命的是这种“快而不稳”会直接消耗你的信任感。头两次翻车你可能觉得是偶然翻车次数多了你就不敢把真正重要的模块交给它了结果又回到自己手敲的老路上AI 编程的价值就只剩写写脚本、补补测试。这个问题不解决工具再强你也享受不到。1.2 技能把最佳实践变成AI的“工作手册”人是怎么解决这种问题的靠经验靠流程。老带新的时候我们不会给新人扔一堆大道理而是给一份 checklist先读需求、再写测试、再写实现、最后自查。这份 checklist 不是某一次的灵光一现而是踩过无数坑之后固化的做法。Superpowers 做的事本质上就是把这个逻辑搬给了 AI。它把每一项最佳实践都封装成一个“技能”每个技能里面包含一套结构化的引导流程这个技能解决什么问题、在什么情况下触发、执行时先做哪一步再做哪一步、遇到边界情况怎么处理、哪些事情明确不能做。AI 加载技能之后就相当于拿到了那份 checklist并且真的会按它的顺序来干活。我最早用的时候最深的感慨是原来不是 AI 不会按流程做事而是没人用它能理解的形式给它“流程”。我一直认为AI 编程最大的瓶颈不在模型智商而在工程纪律。Superpowers 恰好就是补上“工程纪律”那一环的工具。1.3 它和你平时用的大段提示词有什么不同可能有人会问这不就是往对话里贴一段详细提示词吗我一开始也这么想但实际用下来发现差别很大。普通提示词是“一次性”的你这次会话开头贴了一段很详细的开发规范等聊了几十轮、上下文被各种内容塞满之后模型对那段规范的“记忆”会越来越模糊最后大概率就忘了。而技能是结构化的它有自己的文件、名字和触发条件重要的约束会被保存为独立的东西并在每次需要时重新注入到模型上下文里。你可以把提示词理解为口头交代技能则是写进操作手册的岗位职责。口头交代容易走样操作手册才不会。Superpowers 的工程价值正在于让这种“操作手册”可以被复用、被维护、被团队共享。你不需要每次开会都重新讲一遍规范只需要让所有人都启用同一套技能。2. 环境准备与安装两分钟上手全流程2.1 前置要求与选型解释先聊前置条件。Superpowers 不是独立软件它要寄生在一个支持插件机制的 AI 编程环境里。目前最常见的选择是 Claude Code这是一款终端里的 AI 编程工具本身支持插件和技能体系。所以第一步是确保你本机已经装好并登录了 Claude Code而且版本不要太老技能相关的功能迭代速度很快尽量保持最新稳定版。第二个前提是你的终端网络要通畅。首次加载技能仓库时本地会有一次拉取动作如果你的网络环境有延迟第一次打开技能面板可能会等上几秒甚至更久。这个不是故障是它正在从远端同步技能定义。耐心等一次之后再次使用就会走本地缓存速度快很多。第三个值得提一下的是目录选择。我习惯在项目根目录里做技能的初始化和启用因为技能最终服务的对象是这个项目的代码。你在一堆随手建的临时目录里装了半天技能等进入真实项目又要重新配一遍没必要。另外如果你平时用 Git 做版本管理记得确认技能配置文件是否会被自动忽略别不小心把个人信息提交到仓库里。2.2 安装步骤详解真正安装的流程不长我把我实际操作时的完整过程写在这里你可以对照操作打开终端进入你的项目目录启动 Claude Code。输入/plugin进入插件面板。这是各类技能的统一管理入口你后续添加、启用、禁用技能都会在这里进行。选择添加外部插件源输入 Superpowers 的仓库名称。不同版本入口的文案略有不同有的写 “Add”、有的写 “Marketplace”但逻辑一致把一个远端仓库挂到你的本地技能源里。仓库添加成功后面板会刷出这个仓库提供的全部技能清单。这时候它们还是“未启用”状态你需要逐个勾选或者用命令批量启用。启用完成后回到对话界面输入/skills或者查看插件状态正常情况下你就能看到一串技能名字了。这套流程看起来简单但有一个非常容易踩的坑很多人添加完仓库就以为完事了其实仓库加载是第一步技能启用是第二步两步都做完技能才会真正参与 AI 的思考过程。我见过好几个朋友一脸迷茫地说“装上了但感觉没变化”最后检查下来都是漏了第二步。所以这里我特意把它单列出来加完仓库一定要去技能清单里把需要用到的技能切到启用状态。2.3 验证安装是否成功装完到底成没成最简单的验证方式是直接在会话里问一句“你现在支持哪些技能请逐一列出并说明用途。”如果它能准确列出技能名称和职责说明插件加载链路已经通了。更可靠的验证方式是触发一个具体技能观察 AI 的行为变化。比如你跟它说“使用 test-driven-development 技能来实现这个排序函数”然后给它一个需求。如果技能生效它的回答节奏应该是先问你边界条件是什么、空数组怎么处理、性能要求如何然后开始写测试用例而不是上来就甩给你一个冒泡排序的实现。如果你的 AI 还是那个“给需求就直接给代码”的样子那就说明技能没有真正介入回到上一步检查启用状态。这两个验证方式我每次都做前者省时间后者能确认技能的流程约束是否真的被遵守。3. skills全景它到底带来了哪些“超能力”3.1 技能到底是怎么运转的想用好技能最好先明白它背后长什么样。Superpowers 的仓库里每个技能的核心是一个叫SKILL.md的文件。这个名字起得很直白就是“技能说明书”。它表面上是 Markdown 文档实际内容却是给模型看的程序化指令文件头部定义了技能的名字、描述、适用场景正文部分则写清楚执行步骤、注意事项和边界规则。除了主文件一个技能还可以带上辅助文件比如模板、示例代码、检查清单用来支撑更复杂的任务。我截取一个简化版的结构给你感受一下真实文件会比我这里更长更细--- name: test-driven-development description: 引导AI按“先写失败测试再写实现最后重构”的顺序开发功能 --- ## 目标 确保每一段代码都先有验证手段再进入实现。 ## 执行步骤 1. 理解需求列出行为边界 2. 编写失败测试并运行确认其失败 3. 写最小实现让测试通过 4. 运行全部测试确认无回归 5. 重构代码并再次运行测试 ## 禁止事项 - 不允许跳过测试直接写实现 - 不允许在测试失败时注释掉断言来“通过”当你在会话中触发某个技能时Claude Code 会把对应的SKILL.md内容注入到模型的上下文里相当于在对话开始前先给 AI 发了一份“工作手册”。模型读到这个手册后就会按照里面的步骤来组织自己的思考和行为。这也解释了为什么技能和普通提示词不一样普通提示词是你主动贴进去的一段话技能则是环境自动装载的“常驻程序”。3.2 按场景梳理核心技能我按使用场景把常用技能大致分了一下类。你可以把它当作一份快速索引分类技能核心作用需求与方案brainstorming在写代码前进行头脑风暴和方案比选避免思路跑偏需求与方案plussing对已有方案做持续的“找改进点”迭代常用于原型优化开发流程test-driven-development强制“先写失败测试再写实现再重构”的开发节奏开发流程writing-plans / executing-plans把大需求拆成可执行计划并按计划一步一步落地质量保障debugging按“重现、采集、假设、验证、修复”系统化排查问题质量保障code-review按可维护性、性能、安全等维度审查代码提前发现问题技能清单远不止这六项仓库的 README 会持续更新。我的建议是第一次使用别贪多。我吃过亏一开始把所有技能全开结果每次对话模型都要加载一大堆额外内容响应肉眼可见地变慢思路反而被各种规则打架搞乱了。后来我收敛到单次会话只启用 5-8 个技能按项目当前的阶段选择最相关的那几个效率和可控性都回来了。3.3 技能的加载与协同同类技能解决同一类问题这个好理解但其实技能之间还能组合使用形成完整的工作流。打个比方brainstorming 技能负责“想清楚做什么”它产出的方案可以作为输入交给 writing-plans 技能去拆任务然后 test-driven-development 技能接手把任务落地成代码最后用 code-review 技能对结果做一轮总检。我在同一段对话里试过几次这种接力前一步的输出直接作为后一步的上下文AI 不需要你反复重复需求因为你已经把“前面确认过的事情”摆在它的眼前了。这个能力非常实用它让我们和 AI 的协作从一问一答升级成了真正意义上的“项目推进”。最直观的变化是你不再需要在一段对话里反复扮演“项目经理”的角色去提醒 AI 之前定过的规矩因为每个技能自动继承上一棒的产出。4. 把技能真正用起来一套可复制的实操路径4.1 需求拆解阶段先用技能把事想明白大多数人和 AI 协作的失败不是败在写代码而是败在没把需求想明白就开始写。人如此AI 也如此。我现在的习惯是在接到一个功能需求时第一句绝对不是“帮我实现一个某某功能”而是“使用 brainstorming 技能帮我分析这个需求的场景、边界和风险”。请特别注意这句请求里包含技能名这是调动技能的“开关”。接下来 AI 的输出会明显出现章法它会先梳理用户的真实意图列出关键场景和异常情况然后给你两三个方案并说明各自的取舍。你在这一阶段的角色不是旁观者而是要和 AI 一起把模糊的需求打磨成明确的验收标准。等这轮讨论结束你应该有一个类似“功能列表边界条件验收标准”的产物。我举个例子有一次我需要一个批量导入功能直接写代码的话 AI 大概率只会处理正常格式文件但经过 brainstorming 之后它和我一起把文件编码问题、重复数据问题、超大文件分批问题全列了出来后来实现阶段一次通过。别嫌麻烦这一步做扎实了后面实现阶段不会跑偏反而整体时间更短。4.2 实现阶段用技能约束AI每一步需求拆完之后我会把上一轮的结论整理成一段简短的需求说明然后发给 AI同时指定使用开发流程类的技能。我经常用的指令长这样“依据下述需求使用 test-driven-development 技能实现并注意遵守上一轮讨论的边界条件。”技能生效后的表现很容易辨认它会先列出打算测试的行为把测试用例框架写出来然后才补实现代码。你可能会觉得这样“慢”了但只要亲眼见过一次它把边界条件写进测试、然后实现真的不越界的情形你就能理解这个慢是值得的。在实现阶段我最想提醒的一点是你有且只有一个最重要的教练动作——不要打断技能的节奏。很多人按捺不住看到 AI 先写测试就开始催“直接写完了给我”结果技能流程一旦被中断后面的可靠性和前面就是两码事。忍住那几秒钟的急躁让 AI 按流程走完你得到的是一次完整交付而不是一段拆东墙补西墙的代码。4.3 调试与重构从急躁改坏到系统修复代码写出来了测试也过了但实际运行的时候总还有意外。这时候最考功夫的不是 AI而是你会不会正确地委托它去调试。我见过最多的情况是一报错就告诉 AI“帮我看看哪错了”AI 猜了一个地方你顺手让它改改完别的测试又挂了循环往复最后整个人血压升高。这是典型的“快病”。启用 debugging 技能之后AI 的行为会变得“慢而认真”它会先让我提供完整的报错信息和日志然后列几个可能的排查方向再逐个验证确认根因之后才提出修复建议。每个建议都附带验证步骤改完还会建议跑一下相关测试。它的可靠性来自步骤的完整性而不是模型对问题的一眼直觉。重构场景我也一样处理先用测试把现有行为锁住再跑重构技能一步步调整每步都回到测试上来确认没有破坏行为。这种“改一步验证一步”的节奏在老项目里尤其重要因为一个公共函数往往牵动着十多个调用方靠直觉一刀切是切不好的。5. 从“快”到“可靠”核心优势是怎么实现的5.1 流程固化一致带来可预测可预测带来可靠我前面反复强调“流程”因为它就是可靠性的物理基础。一个人写代码为什么时好时坏因为状态会波动情绪、精力、上下文都会影响发挥。AI 写代码为什么时好时坏原因也类似只不过变量变成了上下文内容、模型版本和对话历史。Superpowers 做的事情是把这个波动区间尽量压小——不论谁来问、问了几轮只要技能启用AI 就有一套固定的行为基线。团队里其他人接手时看到的也是同一套基线。这种“可预测性”在工程里的价值往往被人低估你可以不知道 AI 一定会怎么答但你清楚它一定会先写测试、一定会走完排查步骤这就足够你设计检查点和拦截机制了。我在团队里推行这套东西的时候同事最先感受到的变化不是代码变少了而是“心里有底了”。5.2 测试与审查给快代码套上双重保险我见过太多人觉得“AI 生成代码不用测试因为它写得对”。这个判断本身就是最大的风险。AI 生成的代码一样会漏边界、踩类型、搞错并发唯一的区别是它写得快所以错误暴露得也快。快不是问题没有拦截才是问题。Superpowers 价值最大化的路径就是让 test-driven-development 技能和 code-review 技能同时在线前者保证每一段新代码都先有验证手段后者保证合入前还有一道人工视角的审查。两道关卡都用流程而不是靠运气来把关合入主干的质量就有了更稳的兜底。我自己有个小观察启用这套流程之前AI 帮我改了个配置测试跑得通但上线后才发现有一处对外接口的参数名没同步。之后我规定任何涉及接口的改动都必须过 code-review就再没出过同类问题。这不是 AI 变聪明了是流程帮我兜住了。5.3 上下文管理让关键约束不再丢三落四最后再往底层挖一层技能真正厉害的地方是它解决了一半的“上下文遗忘”问题。AI 会话有上下文窗口上限对话一长早期约定很容易被挤出去。技能把重要的约束和流程写成了独立模块并且由环境在合适的时机主动注入相当于给 AI 加了一批“记忆钉子”。就像你写代码时把关键配置抽到常量文件里而不是散落在各个函数里不改则已一改全改。用技能管理 AI 的行为约束是同一套工程思维重要的约定不能靠口头传输要靠文件落地。一旦我把项目的技术栈约定、代码风格、命名规范写进一个自定义技能文件AI 在后续几十轮对话里就再也没出现过“用错框架”的低级错误。这种稳定感才是“可靠”最扎实的体现。6. 踩坑记录与注意事项6.1 装上没用上的三个常见坑先总结一下我遇到过的三个高频问题这些问题单独拿出来都很小但是组合起来足以劝退一个人。第一个是添加插件源之后没有启用具体技能。我已经在前面反复强调过这里只说一句检查一下你的技能列表确认不是“可见”而是“启用”状态。你可以通过/skills命令快速查看如果技能名后面没有启用标识那就还差最后一步。第二个是同名技能冲突。Superpowers 仓库之外社区还有其他插件源提供功能相似的技能比如同样叫 code-review 的技能从不同仓库各装一份后加载的那个会覆盖先加载的容易造成行为不一致。我的处理办法是只保留一个同职能的技能其余同类插件源全部停用。宁可少一点不要乱一点。特别是在团队协作的场景下成员各自装了不同版本的同类技能你根本没法判断 AI 到底按哪套规矩干活。第三个是上下文爆炸。技能虽然好用但它加载到上下文里是有体积的。如果你一口气开了几十个技能每次请求都背着十几个“工作手册”在跑模型的理解质量和响应速度都会被拖累。我实测下来的舒适区间是 5-8 个技能按当前任务的类型动态调整。别把技能当勋章开得多不代表效率高。我自己就经历过开了十几个技能之后AI 连基础代码生成都变慢了那种挫败感会让人误以为工具不行其实纯粹是自己配置过度。6.2 自定义自己的技能把经验沉淀进团队技能体系的边界不是锁死的完全可以自制。我举个例子说明工作流你想让 AI 在提交代码时遵守团队规范就可以在本地技能目录下新建一个SKILL.md参考官方技能的格式写清楚这个技能的目标是“生成符合团队规范的提交信息”触发条件是“用户要求提交代码”执行步骤包括解析改动范围、对照规范模板生成信息、自检敏感词。写好之后把这个文件加入插件清单重开会话就能用。这个过程一点都不神秘它的真正价值在于你团队的代码规范、发布检查单、部署注意事项这些原本靠“人盯人”的东西现在可以沉淀成 AI 能执行的工作手册。新人来了不用反复讲老手离职也不会把规矩带走。我把自己踩过过的几个典型坑写进自定义技能之后连带新人用 AI 的效率都稳了一截。6.3 什么样的项目值得用 Superpowers最后聊聊适用边界。我的判断标准是项目越大、参与方越多、变更越频繁Superpowers 带来的收益越明显。个人写个几百行的小脚本、跑一次就丢的批处理任务说实话用不用它差别不大直接用 AI 写完拉倒。但只要是多人协作的持续迭代项目——尤其是那种改动一个公共模块会牵动一片的老项目——我非常建议尽早上这套技能流程。它能给“AI 生成的每一行代码”安上一道护栏。别指望它让 AI 跨越几个等级变成顶尖架构师这不现实它的定位是把架构师定下的规矩变成 AI 每一次输出都会遵守的纪律。这个定位听起来不惊艳但放到一个持续进化的代码库里它带来的稳定性价值远超“多生成几行代码”那点速度优势。最后再分享一个我自己的习惯每个迭代结束我都会挑几段 AI 这个迭代里生成的代码再用 code-review 技能让它自己审一遍看看能不能挑出自己的毛病。这件事听着有点自嘲但它确实帮我发现过不止一次连带的命名问题和边界遗漏。工具层面的事情说到这就差不多了。如果你正被“AI 写代码太快、但翻车也快”折腾不妨给 Superpowers 两周时间让它接管你的流程纪律。很多时候AI 不缺能力缺的是一个像样的工作环境而技能系统恰恰就是那个环境。
