最近我在重新梳理 AI 编程工作流的时候被一套叫 superpowers 的技能包给“按住”了。先说结论它不是某个语言框架也不是代码库而是一整套给 Claude Code 这类编程 Agent 用的行为规范。简单说就是把你手底下的 AI 从“拿到需求就急着撸代码”的急性子调教成“先问清楚、再列计划、最后动手”的老练工程师。如果你已经受够了 AI 写代码速度快但方向经常跑偏或者每次都要在对话里反复强调“先别写代码先想清楚”那这套技能包大概率能救你。这篇文章我打算把它的具体使用、有哪些 skills、怎么引入到自己的环境里一次讲透。1. 先搞清楚 superpowers 到底是什么以及为什么它能改变 AI 写代码的节奏1.1 它不是“代码库”而是一套行为规范我先用一个类比来解释。你招了个能力很强但经验不足的新人最怕什么怕他接到需求就闷头开干干到一半发现理解错了又推倒重来。你给他一本工作手册手册里写清楚“接到需求后第一步做什么、第二步做什么、什么情况下要停下来问人”他的产出质量就会稳定很多。superpowers 干的就是这件事。它不是给你现成的函数库而是把工作流程写成了一个个“技能文件”。这些文件遵循目前各家 AI 编程工具都在推的 Agent Skills 规范核心就是一个 SKILL.md 的 Markdown 文件里面用自然语言写清楚触发条件、执行步骤、注意事项。当你在对话里输入特定命令Agent 就会去读取对应的技能文件然后按照里面的流程来行动。我最早是在 Claude Code 的环境里跑起来的后来发现 VS Code 的几个 AI 插件也能兼容。它的核心思路很简单把“头脑风暴、写计划、按计划实现、系统化调试”这套人类工程师的工作方法翻译成 Agent 能严格执行的流程指令。这么做的价值在于AI 的推理能力已经够强了缺的恰恰是稳定的“工作习惯”而 superpowers 就是用来补这个短板的。1.2 安装前你需要先确认自己的环境在动手安装之前建议先花两分钟确认三件事。第一你用的 AI 编程工具是否支持 Agent Skills 规范。目前我实测下来Claude Code 原生支持VS Code 里几个主流 AI 插件也能通过读取本地技能目录来支持但具体加载方式略有差异。第二你的机器上要有 Git 和基本的命令行环境因为安装本质上是把 GitHub 上的技能仓库拉到你本地。第三最好先想清楚你是给“全局所有项目”用还是只给“某一个项目”用这会影响你装到什么目录。这里有个容易踩的坑很多人以为装完就万事大吉结果发现对话里输入技能名没反应。大概率是因为工具没有扫描到你的技能目录或者技能文件的路径不对。所以装完之后第一件事就是确认技能列表里能看到对应的技能别等到用的时候才发现压根没加载。1.3 两种主流安装方式图形界面装和命令行装如果你用的是 VS Code最省事的办法是直接在扩展市场里搜 superpowers。装好后插件市场会有相应的技能目录AI 插件会自动扫描到。这种方式的好处是可视化管理适合不习惯敲命令的人。如果你跟我一样习惯命令行可以直接用 Git 把仓库克隆到你当前项目的.claude/skills目录里或者放到用户级目录~/.claude/skills下这样所有项目都能用。命令大概是git clone https://github.com/obra/superpowers.git ~/.claude/skills/superpowers装完之后在对话里输入/skills或者直接问“你现在有哪些技能”就能看到加载结果。如果没看到优先检查目录名和 SKILL.md 文件是否存在技能加载通常是靠扫描这个文件来识别的。2. 核心 skills 逐个拆开看每个技能到底是干嘛的2.1 brainstorming让 AI 先当“需求分析师”再当程序员这个技能是我用得最多的也是 superpowers 整套体系里最值得先掌握的一个。它的作用是在动手写代码之前强制 AI 进入“需求澄清”模式。你给一个很模糊的想法它不会马上说“好的我来实现”而是会像产品经理一样反问你的核心用户是谁最想解决的痛点是什么有没有什么约束条件我用一个实际场景说明。有一次我让它帮我做一个“博客后台的标签管理功能”如果我不启用 brainstorming它可能直接就给你生成一堆增删改查的代码界面样式、交互逻辑全靠猜做完以后往往跟预期差很远。但启用 brainstorming 之后它会先跟我来回确认标签需不需要支持层级标签关联文章后文章页要不要展示删除标签时文章里已关联的标签怎么处理这些问题问完需求本身就被打磨得很清晰了后面写代码反而快。这个技能们背后的逻辑是AI 写代码的“速度”其实不是瓶颈真正浪费时间的是“返工”。一次需求没对齐可能就是一两个小时白干。预先把需求边界划清楚看起来多花了 10 分钟实际上省了后面的几个小时。2.2 writing-plans把需求变成带验收标准的施工图需求聊清楚之后下一步就是写计划。writing-plans 这个技能会把前面的讨论结果整理成一份结构化的实施计划文档。它跟那种随便列几条 TODO 的计划完全不一样里面会包括整体目标、分阶段的任务拆解、每个任务的实现思路、依赖关系、以及最关键的“验收标准”。我打个比方brainstorming 产出的是一张“图纸”writing-plans 就是把图纸翻译成“施工方案”先打地基、再砌墙、最后装门窗每一步都有明确的完成定义。有了这份文档你后续让 Agent 写代码的时候它就不是“凭感觉发挥”而是严格按方案推进做完一个阶段对照验收标准自查一遍再进入下一阶段。这个技能最妙的地方在于它生成的不只是给 Agent 看的信息也是给你看的。你可以在计划文档里直接改比如“我其实不需要用户注册功能把这块去掉”或者“数据库表结构要先设计好”。也就是说在代码还没开始写之前你已经通过调整计划把很多隐患排掉了。2.3 implementing按图施工而不是自由发挥从名字也能看出来这个技能是负责“真正动手写代码”的。但它跟直接让 AI 写代码的区别在于它会严格参照前面生成的计划文档一步一步来。每完成一个步骤它会停下来做检查这个模块的代码是否符合计划里定义的验收标准有没有引入不必要的改动如果发现偏离它会主动调整。我自己用下来implementing 解决的最大的痛点是“AI 随手乱改”。以前让 AI 干活它经常顺手帮你重构一个不相关的函数或者改了某个公共组件的样式也没告诉你。但有了计划约束之后它的行动范围被锁死了只改计划内涉及的文件不做无关操作。这一点对于维护老项目的人来说简直是救命稻草。还有一个我很喜欢的细节这个技能会让 AI 在完成关键节点之后把改动内容、影响范围说清楚方便你做 review。它不会一股脑把全部改动交给你而是像同事一样“汇报进度”你在每个节点都有机会喊停。2.4 还有哪些值得留意的技能除了上面三个核心技能它里面还带了一些偏应用场景的工具型技能我挑几个我觉得实用的列一下技能名主要用途我的使用频率debugging系统性排查 Bug先复现再定位不瞎猜较高code-review对已有改动做代码审查找出隐患偶尔test-driven-development按 TDD 思路先写测试再写实现看项目而定webdev针对网页开发的辅助流程做前端时用technical-review从架构层面审查方案的合理性复杂功能时用以 debugging 为例它和普通排查的区别很明显。普通情况下你让 AI 看个报错它经常猜一个原因就直接给修复方案。而 debugging 技能会要求它先想办法复现问题再提出几个可能的假设然后通过加日志或者二分定位去验证最后才动代码。这个过程看着好像“慢”实际上能避免修一个 bug 引出三个新 bug。3. 实际操作记录从“有个想法”到“代码落地”的完整流程3.1 先跑一遍 brainstorming把模糊需求逼出边界我拿一个真实的例子来走一遍完整流程。当时的需求是给一个内容管理后台加“定时发布”功能。听起来很简单对吧但如果直接写问题非常多定时任务放哪一端实现后端是用消息队列还是简单地轮询数据库到了发布时间文章状态怎么流转前端要展示什么如果发布失败怎么处理我先输入了/brainstorming然后把需求背景喂给 Agent。它开始逐条问我这些边界问题并整理成“需求澄清文档”。这一步我很建议你全程参与回答别偷懒。因为它问出来的问题往往就是你自己没想清楚的地方。比如它问我“定时发布的时间精度要求是多少如果用户希望精确到秒技术方案会复杂很多如果只到分钟级别实现方式会简单得多。”这类问题如果不是被它问住我根本不会意识到还需要在这两个方案里做取舍。3.2 拿到需求文档后用 writing-plans 拆解任务需求确认完我接着输入/writing-plans。它会基于刚才的讨论生成一份完整计划。我用简化结构展示一下计划大概长什么样## 目标 实现文章定时发布功能 ## 阶段一数据模型 - Article 表增加 scheduled_at 字段 - 增加发布状态字段 statusdraft / scheduled / published / failed ## 阶段二调度逻辑 - 使用每分钟执行一次的定时任务扫描 scheduled_at 到期的文章 - 发布失败时记录错误信息状态置为 failed ## 阶段三管理界面 - 列表页展示定时发布日期 - 编辑页支持设置定时发布 - 字段校验定时时间必须晚于当前时间 ## 验收标准 - 到达发布时间后文章状态自动变为 published - 发布时间未到前文章不会出现在前端文章列表这份计划里最值钱的是“验收标准”这一段。因为在没有它的时候AI 实现完你还需要自己想“怎么算做对了”现在标准提前定好了它写完代码之后会自己对照检查你再做测试也会轻松很多。3.3 进入 implementing按阶段验收推进计划确认之后我输入/implementing告诉它就按这份计划来。它没有像以前那样一口气创建一大堆文件而是按照阶段一、阶段二、阶段三的顺序推进。每完成一个阶段它会停下来总结改动涉及哪些文件、是否满足验收标准、有没有测试建议。这里有个小技巧我建议你记住在对话里明确跟它说“请按计划里的阶段顺序执行每个阶段完成后等待我确认再继续”。这样你就能卡住每一关防止它在你没看结果的情况下继续往错方向走。我实测下来这样虽然会多几次交互但整体时间反而更短因为每一步的偏差都在最小范围内被纠正了。3.4 我在这个流程里调整过的几个小细节用了几轮之后我摸索出几个适合自己的使用习惯。首先是“顺序别打乱”brainstorming 完直接写计划计划完再实现中间不要跳步。有一回我图省事跳过 writing-plans 直接用 implementing结果它拿着 brainstorming 的需求文档就开干导致实现到一半发现还有几个边界问题没明确只能回头补反而更慢。其次是在计划文档里把“不做什么”也写清楚。比如上面那个定时发布功能我就加了一句“本阶段不做失败重试机制失败仅记录日志”。别小看这一步AI 经常会有“顺手做好事”的冲动你明确画一个功能边界它就不会越界扩展。最后是及时清理旧的技能文件。如果你升级了 superpowers 版本记得删掉旧目录再拉最新的不然 Agent 读到的指令版本混杂行为会变得不可预测。这个我踩过新旧两版技能定义不一致导致 AI 的响应风格一会变排查了挺久才发现是缓存了旧文件。4. 常见问题与排查技巧实录4.1 安装了但技能没有出现在技能列表里这个是最常见的问题。我遇到过的情况主要有三种技能文件放错了目录、目录名不符合扫描规则、或者工具开了缓存没有重新加载。我的排查思路是这样的先确认你选的安装方式是全局还是项目级然后看目录结构是否在模型能扫描到的路径下最后检查 SKILL.md 文件是否真的存在。如果用的是 VS Code 插件试试重新加载窗口很多次问题就出在它没有刷新技能目录。顺便提一句如果你是把技能放在用户级目录改完之后最好先确认一下系统是否真的读取的是这个目录。我自己有次就是因为工具读的是另一个位置的旧配置文件导致我改了技能目录根本没生效。4.2 技能被触发后AI 还是“我行我素”这个问题比较隐蔽表现为你明明输入了/writing-plans但它仍然直接开始写代码或者边写计划边动手。我分析下来最常见的原因是对话上下文里已经堆积了太多“历史任务”它把这些历史指令当成了当前任务的一部分。另外如果你在私人设置文件里写了比较强势的自定义指令也可能覆盖技能里的流程约束。我能给的解决办法有两个。一是尽量在干净的对话里触发技能别让它承载太多无关上下文。二是把技能文件里的核心约束写得再直白一点比如在步骤里加上“在任何代码生成之前必须先输出完整计划文档并等待用户确认”。技能的加载本质上就是读 Markdown你完全可以按自己的需求改它的文案让它更贴合你的工作习惯。4.3 担心技能包与自己的提示词冲突这个顾虑很正常。因为很多人之前已经写了自己的系统提示词怕加载 superpowers 之后两套逻辑互相打架。我的经验是技能的优先级通常高于默认提示词但低于你在对话里临时给的指令。所以如果你发现提示词和技能打架了优先想想哪个对你的项目更重要。如果要让技能强制执行就把提示词里冲突的部分改掉如果你只是想要它偶尔遵守那就靠每次对话里的临时指令来叠加。我个人的建议是让技能成为主导自己写的提示词负责补充“背景信息”和“项目规范”而不是重复规定流程。比如我在提示词里会写清楚项目的技术栈、命名规范、测试要求但“先计划再实现”这种流程控制全权交给技能来处理。这样两者各司其职冲突基本就消失了。4.4 遇到“计划不断调整但代码没跟上”时怎么处理如果你发现计划文档改了又改但 Agent 生成的代码始终是旧逻辑大概率是它没有重新读取计划文件。这种情况下我会把计划里的对应章节重新复制到对话里直接粘贴给它然后要求它“以这个版本为准忽略之前的计划”。实测下来显式粘贴的效果比让它自己去找文件要好得多。还有一个容易忽略的点当计划文档里出现“删除、重命名”这类破坏性操作时Agent 往往倾向于保守执行甚至绕开。这时候需要在对话里明确授权比如“请严格按照计划重命名这个函数并同步更新所有调用点”。不然它可能会给你留一堆兼容旧名字的代码看着像实现了其实埋了雷。最后分享一个我总结的问题速查表你可以直接对照排查现象可能原因解法技能列表不显示目录/文件路径不对检查 SKILL.md 存在且路径正确触发了但没效果上下文太杂或自定义指令冲突新开对话简化指令计划跟代码不一致Agent 没重新读计划直接粘贴最新计划到对话执行到一半跑偏缺少阶段停顿点明确要求“每个阶段等待我确认”改动范围失控未设置“不做什么”在计划里补充功能边界这套东西我实际用了两三周下来最大的感受是它并没有让 AI 变得更“聪明”但确实让 AI 变得更“靠谱”。原来需要我反复盯着的那些细小流程控制现在都下沉到了技能文件里。你如果也想试试建议从 brainstorming 和 writing-plans 这两个入手先把需求澄清和计划环节跑顺再逐步加载其他技能。别着急一次全上等适应了这套工作节奏你大概率会跟我一样对“让 AI 边想边写”这个状态再也回不去了。