最近一两个月我一直在折腾自己的 AI 编程工作流。Claude Code 本身已经很能打但用久了发现一个尴尬同一个模型换一套提示词规则表现可以天差地别。后来我把注意力从“写提示词”转到了“装技能包”才真正体会到什么叫“给助手装上可复用的能力”。这篇文章想聊的就是 superpowers 这个项目它是什么、装完之后你能拿到哪些 skills、具体怎么把它引入到日常开发里以及我实测过程中踩过的几个坑。适合的人群很明确——不满足于把 AI 当问答机器更想让 AI 在真实工程任务里稳定输出的人。1. 先搞清楚 superpowers 解决的是哪个老问题1.1 我以前的做法把所有经验塞进 system prompt在装 superpowers 之前我的方式是典型的“人肉调教”项目根目录放一个 CLAUDE.md把编码规范、禁止事项、常用命令全写进去然后在对话里反复强调“先写测试”“先给方案再动手”。效果当然有但问题也很明显。第一个问题是 token。规范写少了模型记不住写多了每轮对话都在背课文上下文窗口被占掉一大截。第二个问题是优先级。你很难通过几行文字让模型在“写业务代码”“重构老模块”“审查自己的 diff”这些不同场景里自动切换行为。它更像把一堆规则混在一起模型只能凭概率猜你现在想要哪一种。第三个问题是不可复用。这个项目调好的规则换个项目又要重新写一遍哪怕 80% 的内容是重复的。superpowers 对这三个问题的处理方式很简单不把“经验”塞进一句 prompt而是把“经验”拆成一个一个技能文件每个技能文件只讲一件事。需要的时候再触发不需要的时候它安静地待在目录里不占上下文、不干扰正常对话。这个思路听起来不复杂但真正用起来后我发现它比“靠嘴说”稳定太多。1.2 “会技能”和“遵守规则”是完全不同的两件事这里要先区分一个概念。我一直以为给模型讲清楚规则就等于让它学会了技能后来发现这是两回事。遵守规则是约束性的它回答的是“什么不能做”而技能是流程性的它回答的是“遇到这类任务时应该按什么顺序做什么”。比如你不用给模型规定“必须在写代码前列计划”但你可以给它一个 writing-plans 技能里面明确写了先收集需求、拆分目标、列出非目标、标注不确定点、最后生成可验证的步骤。模型在正常情况下不会主动走这套流程但一旦技能被触发它会按里面的模板一步步执行。这有点像一个没受过培训的新员工。你给他一份员工手册他能背但遇到具体任务还是会乱但如果你给他一套“标准作业流程”他照着走出来的东西就有基本盘。superpowers 提供的 skills 就是后者而且是已经经过大量工程场景验证过的流程。这也是我为什么愿意在项目里引入这套东西而不是继续自己攒 prompt。1.3 谁适合装它谁可以先不装先说结论如果你只是偶尔让 AI 帮忙写个脚本、翻译一段文字那没必要装。技能包带来的收益需要“多步骤、可重复、有固定流程”的任务才能体现出来。适合装的人大概是这样的你经常让 AI 做代码审查、做重构、写完整测试、在开始写功能前出方案或者你希望 AI 在接到需求后不要立刻噼里啪啦输出代码而是先拆解、再动手。这种场景下技能包几乎是为“规整 AI 行为”量身定做的。我自己就是在做一次涉及十几个文件的重构时发现同样是 Claude Code开着 brainstorming 技能和不开产出的方案质量差距肉眼可见。不适合的也有如果你的项目代码量很小、任务都很单一那装完会感觉有点“重”因为你会多花精力去管理技能列表本身。这个判断很重要别盲目跟风装一堆技能最后反而不知道怎么用。2. 装完之后你实际能拿到哪几类 skills2.1 规划和思考类动手之前先让脑子转起来superpowers 里最让我惊艳的不是写代码类技能而是规划类技能。典型的有 brainstorming 和 writing-plans。brainstorming 的定位是“发散讨论”。当一个问题还没有明确答案时你让模型启用它它会按技能里的流程不断追问条件、列出候选方案、比较取舍而不是直接给一个看起来最合理的答案。这就避免了 AI 最常见的毛病——自信地给出一个其实没经过推敲的方案。我实际用下来它特别适合接口设计、方案选型、技术债处理这类开放问题。writing-plans 则是把讨论结果固化成可执行计划。技能里通常包含目标、背景、约束、步骤、验证方法、风险点这些结构。它逼着模型把模糊的想法转成白纸黑字并且明确哪些步骤是可验收的。以前我让 AI 写计划它写得像一篇作文用了这个技能后它写得像一个工程任务的 breakdown可以直接拿来排期。2.2 编码执行类TDD、重构、调试、代码审查编码类技能大概是大多数人最先会用到的。我印象比较深的是几个典型的目录test-driven-development、refactoring、debugging、code-review。TDD 技能不是简单让模型“写测试”而是给出一套循环先写一个会失败的测试然后跑测试确认失败再写最小实现让它通过最后重构。如果你做的是一个对稳定性要求比较高的模块这套流程的价值非常大因为每一步的产出都是可验证的。模型在技能约束下不会跳步不会有“测试和实现一起写完再补跑一下”的糊弄行为。refactoring 和 debugging 对我的日常工作帮助也很直接。refactoring 会先要求你明确“重构目标”和“不做行为变更”的边界然后小步提交避免一次改出大问题debugging 则更结构化它引导模型先建立假设、再设计最小复现、再定位根因而不是看到报错就瞎猜。code-review 是把模型切换成“审查者”视角按严重程度列出问题、给修改建议同时区分风格问题和逻辑问题。这几个技能本质上都是把老工程师的“肌肉记忆”做成了显式的检查清单。2.3 子代理和命令技能之外的两种载体很多人以为 superpowers 只有 skills其实它还把能力切成了三种形态技能、子代理、自定义命令。子代理可以理解成“带特定人设和记忆边界的独立会话”。你可以在一个复杂任务里把一个子任务甩给子代理它会用更聚焦的上下文去处理再把结果带回来。这比在主对话里反复切换角色要干净得多尤其是长任务里它能避免主对话被一个临时排查过程刷屏。命令则是把一些常用动作封装成快捷入口比如一键开始 brainstorming、一键让 AI 总结当前分支改动。这三者各有分工技能负责“流程”子代理负责“隔离上下文”命令负责“快捷触发”。实际使用时不必分得特别清楚只需要知道当你发现“某个行为总是要反复教”的时候大概率可以把那套行为固化到其中一种载体里。2.4 技能不是越全越好目录结构才决定效果有一点要提前说你装上 superpowers不代表所有技能都会在每一轮对话里生效。技能通常按目录存放模型只有在判断任务匹配时才会去读取对应的技能文件。所以在实际效果上真正决定模型表现的不是“装了哪些技能”而是“技能的描述写得是否精确、目录组织是否清晰”。我见过一种反面做法把技能的 description 写得特别泛比如“用于写代码”结果模型在简单问答里也触发反而拖慢节奏。正确的做法是让每个技能的描述包含三个信息什么场景用、什么时候不用、用了之后大致会做什么。这样模型才能精准调度。superpowers 自带的技能描述基本符合这个标准这也是我后来自定义技能时对照学习的模板。3. 安装与初始化从零到真正跑起来的过程3.1 前置条件版本和运行时动手安装前先把前置条件说清楚省得到时候一脸懵。superpowers 是建立在 Claude Code 体系上的所以你的终端里得先有可用的 Claude Code并且建议把 CLI 更新到较新的版本。为什么强调版本因为“技能读取”这个能力本身的实现依赖较新版本的客户端。你在旧版本里装好了技能模型很可能完全感知不到表现为你对它说“用 brainstorming”它却假装没听见。这是我第一次踩到的坑后面会细说。另外安装过程会用到 Node.js 环境和基本的 git 能力如果这些已经准备好安装其实非常快。3.2 安装路线的两种选择以我目前查到的主流做法安装大致有两条路线。第一条是通过插件式管理。你可以在 Claude Code 会话里添加一个插件市场来源通常是项目仓库地址然后再安装 superpowers 这个插件。比如在会话里执行“添加插件市场”和“安装插件”两个动作市场地址填项目仓库就行。这种方式的优势是后续更新比较方便插件市场会帮你管理版本。另一条路线是使用项目提供的一键初始化命令运行之后会在终端弹出交互式引导让你选择要启用哪些技能、哪些子代理。我建议第一次使用走交互式引导因为你能直观看到技能列表而不是一股脑装完再挨个试。具体命令以你安装那一刻的官方 README 为准因为这类项目迭代很快我见过 README 在一个月内改过两次安装入口。这里不贴死命令但整个流程的形态就是刚才说的那样要么插件市场管理要么交互式初始化。别在第三方博客里复制命令直接以仓库文档为准这个原则在开源工具上永远不会错。3.3 初始化后必须检查的几件事装完先别急着用做三个检查能省掉后面大量排查时间。第一确认技能目录真实存在。技能本质是一组 markdown 文件理论上你可以直接去技能目录里看到SKILL.md和配套模板文件。如果目录是空的说明安装过程没真正完成不要继续往下走。第二确认客户端能读到技能列表。可以在会话里询问模型当前加载了哪些技能或者用可以输出技能列表的命令去验证。这里有个容易误判的地方模型回答“会哪些技能”时可能是从预训练知识里编的不代表它真读到了目录。可靠的方式是直接看文件结构或者让模型具体描述某个技能文件里的某个步骤如果它能说对细节说明真的加载到了。第三确认触发名称和你预期一致。比如你想用 TDD 技能先搞清楚它的技能名是叫test-driven-development还是类似变体。名称是模型调度时的关键索引记错了你会以为是技能没装好其实是叫法不对。3.4 全局安装还是项目级安装使用中还有个选择技能放在用户全局目录还是放在某个项目的目录。全局安装的好处是任何项目都能用适合那些和业务无关的通用技能比如 brainstorming、writing-plans。坏处是如果你装了特别多技能描述会占用一些上下文空间而且跨项目使用时偶尔会把不符合当前项目规范的技能也带进来。项目级安装则适合和具体工程强相关的技能比如这个项目特有的代码规范检查、发布流程操作。我的习惯是全局放通用的思维类技能项目级放和当前代码库强相关的技能。这样既保证基本能力到处可用又不会让每个项目都被无关技能拖慢。如果你只有一个主力项目那全部放项目级也完全没问题。4. 在日常开发里技能是怎么被“引入”的4.1 两种触发方式显式要求与模型自动调度技能的实际引入方式比我预想的要灵活。一种是显式触发你在对话里直接说“用 brainstorming 技能来聊聊这个方案”模型会明确调起对应技能。另一种是隐式调度当技能目录被加载后模型会根据任务语义自己判断要不要读取某个技能文件。我一开始总是用显式触发后来发现隐式调度才是真正提升效率的地方。比如我把 TDD 技能挂在项目级目录后每次让它实现新功能它会自己先写测试不再需要我反复叮嘱。但隐式调度也有代价它依赖技能 description 写得好不好。所以我说自定义技能时最值得花时间的不是步骤正文是那个 description。4.2 一个真实跑通的流程限流功能的从讨论到重构举一个我最近实际跑通的例子。当时要给现有服务加一个限流能力我没有直接说“帮我实现限流”而是先对 Claude 说“用 brainstorming 技能我们讨论一下在现有架构里做限流的方案。”它会按技能流程问清楚流量模型是什么、限流放在哪一层、失败后是排队还是拒绝、要不要集群共享状态。这些是我没提但它通过技能里的引导问题一步步问出来的。讨论完我说“用 writing-plans 技能把方案整理成实施计划”它立刻把结论转成了目标、非目标、步骤、验证点四段式计划。进入编码阶段后我让它“按 TDD 流程实现第一个版本”它自己先写了针对限流算法的失败测试跑完后告诉我“测试如预期失败接下来实现最小通过逻辑”。测试通过后又进入重构阶段把重复计算抽成公共函数。最后我说“用 code-review 技能检查这次改动”它以审查者视角列出了两个边界条件没覆盖的问题并给了修复建议。整个过程里我没有写一句复杂的提示词只是像分配任务一样说出技能名剩下的流程由技能接管了。4.3 把自定义技能加进这套体系用到顺手之后我自然开始想加自己的技能。这里分享一个最简单的模板思路。在项目根目录的.claude/skills/下新建一个文件夹比如my-code-review里面放一个SKILL.md。文件结构大致是这样的.claude/skills/ └── my-code-review/ └── SKILL.mdSKILL.md的开头是 YAML frontmatter包含name和description。description 要写清楚使用场景和不适用场景。正文部分就是你要模型执行的具体步骤可以包含检查清单、问题模板、输出格式。一个精简的例子--- name: my-code-review description: 仅用于提交前的完整 diff 检查。当用户要求逐行审查未提交修改时使用。不适合回答零散代码疑问或其他常规问答。 --- # 审查步骤 1. 读取 git diff定位改动文件。 2. 按严重程度列出问题阻塞、建议、风格。 3. 对每个问题给出具体修改位置和修改建议。写完之后重启会话让客户端重新扫描技能目录然后试着用一次。如果模型没有按预期调用多半是 description 写得不够精确或者触发时描述的场景和实际不一致。我在这个环节反复试过很多次最后悟出一个原则技能正文要像操作手册不能像散文步骤要可以被验证不能说“如果可能尽量提高代码质量”这种正确的废话。4.4 技能引入的真正意义把习惯变成流程用了一段时间之后我的感受是技能引入带来的最大变化不是模型变聪明了而是我的工作方式变规范了。以前我可能凭心情决定要不要先写方案、要不要先补测试、要不要主动检查边界。现在只要在合适的节点喊出对应的技能名这套流程就会自动发生。对一个长期维护项目来说这种稳定性比偶尔一次惊艳输出更有价值。它相当于把团队里最靠谱那个工程师的做事顺序完整地转移到了 AI 助手身上。5. 实测之后几个值得先记住的坑5.1 技能文件放错层级等于没装第一个坑就是层级问题。我把技能放到用户全局目录后以为所有项目都会自动生效结果在一个旧项目里完全没反应。查了半天才发现那个项目里已经存在一个项目级的技能目录客户端的解析规则里项目级优先全局目录里的同名或近似技能不会被加载。这种事不会报错也不会弹警告只能靠你自己查。我的解决办法是先确定你要在哪个项目里用这个技能再决定放哪个层级的目录。如果同一类技能在全局和项目级都存在以项目级的为准别在全局目录里反复调试一个项目级优先级更高的问题。5.2 技能描述写得太宽泛模型什么任务都想用这个坑出现得比我预想更快。我一开始写自定义技能时description 写的是“用于代码审查”。结果模型在一段简单代码问答里都要强行触发这个技能输出格式变得特别重回答一个“这段代码有没有问题”像在开评审会。看了官方技能的描述风格后我才明白description 里需要写清楚“什么情况下不要用”。比如可以加一句“仅用于提交前的完整 diff 检查不适合回答零散的代码疑问”。模型对技能调度的准确性很大程度上就看你在 description 里给的边界信息够不够。这件事直接决定整个技能系统的使用体验值得认真写。5.3 技能装多了上下文开销比想象中大第三个值得提醒的是 token 开销。技能不是零成本的至少技能描述会被客户端读取用来做调度判断。装的技能数量多了以后即使没有被实际触发也有一部分描述信息会出现在上下文里。我实测的感受是几十个技能全量启用后索引阶段的上下文开销明显上升。如果你也在一个上下文敏感的长任务里工作建议控制启用的技能数量或者把那些低频技能放在不常访问的目录里只保留核心技能在当前层级。必要的时候可以关掉某个技能比让它一直挂着消耗上下文更划算。5.4 验证技能是否生效别只靠嘴问最后这条是最容易误导人的不要靠“问模型你会哪些技能”来确认安装是否成功。模型很可能会根据训练记忆给你一份听起来很有道理、但和实际安装内容对不上的清单。要验证就做两件事。第一用文件管理器直接看技能目录的结构确认SKILL.md在不在第二让模型复述某个技能文件里特有的步骤或模板比如让它说说某技能里关于验收标准的具体描述。如果它能准确说出和文件内容一致的细节那才说明真正加载到了。这个验证步骤虽然有点啰嗦但能帮你免掉后续一堆困惑。说实话我现在的用法已经回不去了如果你问我花了一天时间安装和试玩 superpowers 值不值我的答案是它让我重新理解了“给 AI 加能力”这件事。之前我总想找一段万能提示词后来才发现与其寻找万能提示词不如给模型准备一套可以在不同场景被精准调起的流程库。现在我的日常开发里 brainstorming 负责方案讨论writing-plans 负责把讨论变成计划TDD 和 code-review 负责守住代码质量底线。它们不抢戏也不耽误事只在对应场景里被叫出来干活。装完第一周我最真实的体会是一开始会被“技能没生效”“触发错了”“上下文涨得快”这些小问题折磨但把目录层级、技能描述、启用数量这三件事理顺之后整个系统会变得非常顺手。如果你也准备入坑我给的建议是把“先看官方 README、先检查技能目录、先小范围试一个技能”这三步走完再考虑大规模引入其他技能。等你跑通第一个完整的 brainstorming 到 code-review 闭环之后大概就能理解我为什么说回不去了。