上周有个朋友问我：为什么我用 Claude Code 改一个 bug，经常一轮就能定位到根因，而他自己试的时候，AI 像个没头苍蝇一样乱猜，改了三轮还在原地打转。我说，因为我给 Claude Code 挂了一套叫 superpowers 的"思维外挂"。

这个项目本质上是一堆 SKILL.md 文件，把软件工程里最经典的调试、测试驱动开发、头脑风暴、系统思考等方法论，写成了 Claude Code 可以严格遵循的分步骤指令。它不是一个商业产品，也不是什么需要付费订阅的服务，而是一个可以直接装进自己项目的开源技能仓库。装上之后，AI 在复杂任务里会少一些自由发挥，多一些稳定输出，产出的代码质量和生成结果明显更可控。

这篇文章打算把我从安装到实际使用的完整经验写出来：怎么装、目录结构长什么样、内置了哪些 skills、怎么把它真正引入对话流程，以及我用了大半个月之后踩过的坑和真实感受。如果你也在用 Claude Code 这类 AI 编程工具，并且觉得"AI 确实能干活但总是不太稳"，那这篇应该对你有用。

1. 一个"思维工具箱"项目：superpowers 到底在解决什么问题

1.1 AI 能力很强，但"发挥稳定"是另一回事

先说个反直觉的结论：给一个很强的 AI 立规矩、套流程，反而能激发出它真正的能力。

Claude Code 这类工具刚出来的时候，大家的普遍使用方式是"用大白话描述任务，让它自由发挥"。比如：

• "这个接口偶尔超时，帮我修一下"
• "给这个模块加个缓存"
• "这个页面样式乱了，看看哪里的问题"

模型本身确实很强，但问题是"强"不代表"稳定"。一个任务让 AI 做十次，可能五次效果很好，两次勉强能用，还有两三次它会陷入一种典型的恶性循环：猜一个原因、改一行代码、跑一下、发现不对、再猜一个原因、再改。尤其是修 bug 的时候，这种"猜测式修改"非常危险——改对了是运气，改错了还把原本能跑的代码弄坏。

我一开始也踩过这个坑。有一次让 AI 修一个并发问题，它在没有任何日志和复现步骤的情况下，直接往服务里加了两个互斥锁，结果不仅没解决问题，还把正常的请求路径给阻塞了。当时我就意识到：大模型的知识储备没有问题，缺的是"一个靠谱的解决问题流程"。

1.2 把专家方法论变成"可执行的思维模板"

superpowers 解决的就是这个问题。它不教 AI 新的知识，而是教 AI"怎么想问题"——把人类专家几十年的工程方法论，拆成 AI 可以一步一步走的决策树。

举个例子，普通人让 AI 修 bug 时，AI 通常会直接阅读代码、猜测原因、动手修改。但 superpowers 里的 debugging skill 会强制 AI 走一套完全不同的流程：

1. 先完整描述 bug 的现象和复现条件，没有复现步骤就先让用户提供
2. 先用一个能失败的测试或日志，把"症状"固定下来
3. 再根据锁定范围做最小化修改
4. 修改后重新跑测试，确认问题真的消失，同时检查有没有引入新问题

这套流程对老工程师来说可能稀松平常，但对 AI 来说意义巨大。它每走一步只需要做一个判断，而不是从"读代码-猜问题-动手改"中间直接跳到最后一步。结果就是：AI 生成的 patch 不再是拍脑袋的结果，而是有依据、可验证、可回滚的工程决策。

1.3 它和普通 prompt 的本质区别在哪里

有人可能会问："我自己写 prompt，让 AI 认真一点、多想想再回答，不也一样吗？"

不太一样。普通 prompt 是一次性的请求，AI 收到指令后靠自己的习惯去决定做事的顺序。你让它"先分析再动手"，它可能在开头象征性地分析两行，然后立刻开始改代码——因为训练数据里的习惯太强了。而 superpowers 的 SKILL.md 文件更像一份"操作手册"，里面写的不是"你要细心"，而是具体到每一步要做什么、用什么顺序做、做到什么标准才算通过。AI 在执行的时候，是按手册一步步走的，而不是凭感觉发挥。

这里有个很形象的类比：一个厨师自己炒菜，火候全凭感觉；但如果你给他一份标准作业指导书，告诉他"油温 160 度、下锅后 30 秒翻面、翻面 3 次"，他每次做出来的菜可能不是最好吃的，但一定是最稳定的。superpowers 干的就是这件事——给 AI 一份可以照做的"标准作业指导书"。

这个项目本身对标的也是当下比较流行的 Agent Skills 标准，每个技能就是一个带 frontmatter 的 Markdown 文件，放在项目目录里就能被 Claude Code 自动发现。这意味着你不仅可以用它内置的技能，还可以自己写，完全按照团队的规范来定制。

2. 动手安装：把 .superpowers 装进你的 Claude Code

2.1 安装前的环境检查

在动手之前，先确认你的环境到位了。我假设你已经装好 Claude Code 并且能正常对话，如果还没走到这一步，先装好它再回来。

• 确认 node 环境正常，终端里能运行node --version
• 确认 Claude Code 能正常工作，运行claude --version能看到版本号
• 确认你有一个想试用 superpowers 的项目目录

Claude Code 本身是装在系统层面的，但 superpowers 的技能文件是按项目生效的。你需要把技能装到"你平时会打开 Claude Code 干活的那个项目目录"里，因为它是通过项目根目录下的.superpowers目录和CLAUDE.md文件来加载的。

2.2 安装的具体步骤

我自己安装的时候，仓库的 README 已经推荐过一条比较简洁的路径——直接在 Claude Code 里用内置的 skill 安装命令。不过在写这篇的时候，这个命令的具体写法在不同版本里有一些差异，而且项目迭代比较快，所以我先把最稳妥、任何时候都不会失效的手动方案写清楚。

打开终端，进入你的项目目录，然后依次执行：

# 1. 克隆 superpowers 仓库到任意临时目录 git clone https://github.com/obra/superpowers.git cd superpowers # 2. 回到你的项目目录 cd /你的项目目录 # 3. 把 .superpowers 目录复制到项目根目录 cp -r /路径/superpowers/.superpowers . # 4. 把 CLAUDE.md 也复制过去，或者手动把内容合并进已有的 CLAUDE.md cp /路径/superpowers/CLAUDE.md .

这里有一个很容易踩的细节：.superpowers是隐藏目录，前面有点号。用cp -r复制的时候，如果你只复制superpowers/.superpowers下面的内容而不是整个目录，目录结构就会错掉。我建议直接整目录复制，保证content子目录完整。

如果你用的是比较新的 Claude Code 版本，也可以先看一眼项目 README 里推荐的安装方式，现在官方仓库一般会提供一条更简单的命令，本质上就是把上面这几步封装好了。但无论怎么封装，最终落到项目里的核心就是两个东西：.superpowers目录和CLAUDE.md文件。

2.3 验证是否装成功了

安装完别急着开始用，先做个快速验证：

# 看技能目录是否存在，并且里面有内容 ls .superpowers/content/ # 随便打开一个 skill 的 SKILL.md，确认 frontmatter 正常 cat .superpowers/content/debugging/SKILL.md | head -30

正常情况下，.superpowers/content/下面应该有多个子目录，每个目录里都有一个SKILL.md文件。如果ls什么都看不到，多半是复制的路径不对，或者目录层级被多套了一层。这时候回到项目根目录重新执行ls -a，看看.superpowers是不是真的在根目录下。

然后检查CLAUDE.md。这个文件是 Claude Code 每次启动时都会自动读取的项目级指令文件，安装脚本会把"你拥有这些技能，当任务匹配时自动加载对应的 SKILL.md"这样的加载说明写进去。如果项目里之前已经有一个 CLAUDE.md，注意别被直接覆盖了，建议手动把新内容合并进去，保留你自己原有的项目约定。

2.4 安装失败的常见原因排查

我见过不少人在安装这一步出问题，总结起来基本是这几类：

• 装错了目录：在临时目录里执行了安装，但从不打算在那个目录用 Claude Code。技能装好了，干活的项目里却没有。
• CLAUDE.md 被覆盖：项目里原本有自己的项目规范，复制的时候整个文件被替换掉了，导致项目原有的约定失效。建议先用cat CLAUDE.md看内容，再决定是覆盖还是手动合并。
• 目录嵌套错误：复制成了.superpowers/.superpowers这种两层结构，Claude Code 扫描不到技能文件。

顺便提一句：如果你有多个项目想用同样的技能，不需要每个项目都重新 clone 一遍。可以把.superpowers作为公共配置维护在一个地方，然后在各项目的 CLAUDE.md 里指定技能目录的路径。不过这种做法依赖 Claude Code 对自定义技能路径的支持情况，目前最简单可靠的方式还是每个项目复制一份。

3. SKILL.md 与 Thought Tree：为什么"步骤化提示"比"自由发挥"稳

3.1 SKILL.md 的"身份证"结构

装好之后，值得花几分钟打开一个 SKILL.md 文件看看，理解它的结构。因为只有理解了它长什么样，你才真正知道 superpowers 是怎么控制 AI 行为的，也才能自己去写新的 skill。

一个标准的 SKILL.md 文件长这样，我用 debugging 这个技能的结构来说明：

--- name: debugging description: 当用户遇到代码运行错误、测试失败、行为异常时使用。 --- # When to Use - 用户提供一个 bug 描述，且问题根因未知 - 代码行为与预期不符 - 测试用例失败但原因不明确 # What to Do 1. 要求用户提供一个最小复现步骤，如果无法复现，先建立复现方案 2. 运行现有测试或添加一个预期会失败的测试，锁定失败症状 3. 根据失败信息阅读相关代码，定位根因 4. 做最小化修改，不顺手改无关代码 5. 重新运行测试，确认修复有效且没有引入回归

注意frontmatter里的description字段——那两行描述是 Claude Code 判断"什么时候该加载这个技能"的依据。AI 读完 CLAUDE.md 之后，会拿着用户的任务描述去和各个 skill 的 description 做匹配，匹配上了就自动读取该 SKILL.md，然后按照里面的步骤执行。

所以如果你以后想自己写私有技能，description写得好不好直接决定了 AI 能不能在正确时机触发它。别写得太空泛，比如"处理问题"这种，AI 根本不知道什么时候该用；也不要写得太窄，比如"仅当用户提到 Connection refused 时"，那 AI 换个报错场景就不触发了。合适的粒度应该是"当用户描述一个运行异常且根因不明确时"。

3.2 Thought Tree：一种比"认真点"有效得多的约束方式

superpowers 项目里有一个词叫 Thought Tree，直译是"思维树"。这是它区别于普通 prompt 最核心的设计。

普通 prompt 给 AI 的是一句总目标："修复这个 bug。" 至于怎么修，AI 自己看着办。

Thought Tree 给的是一棵决策树：遇到 A 情况走第 1 步，第 1 步得到 B 结果就走第 2 步，如果第 2 步失败就回退到第 1 步换一种方式。每一步之间不是"写完就结束"，而是存在条件判断和回退机制。

拿 debugging 来举例，这个 skill 背后的 Thought Tree 大致是这样的逻辑：

• 是否清楚复现步骤？
  • 否 → 先让用户提供，不要盲目动手
  • 是 → 进入下一步
• 是否有一个能稳定失败的测试/命令？
  • 否 → 先写一个，把"症状"从模糊描述变成具体断言
  • 是 → 进入隔离定位
• 隔离定位后，是否明确根因？
  • 是 → 做最小修改
  • 否 → 回到上一步继续缩小范围

这套逻辑对工程师来说不稀奇，但它被固化成了 AI 的默认流程后，效果提升是非常明显的。因为模型在普通对话模式下会"跳步"，它倾向于直接从问题描述猜到修改方案；而在 Thought Tree 的引导下，它每次只做一个决策，而且这个决策是基于上一步输出的事实做出的，每一步都给自己留了验证的机会。

3.3 一个实际例子：没有 skill 和有 skill 的对比

我举一个自己遇到的真实情况。当时项目里有个 Node.js 服务，偶发性内存上涨，上线跑两天就 OOM。我把问题直接丢给 Claude Code，它的第一反应是"可能是缓存没有清理，我加一个 LRU 过期策略"——这属于典型的猜测式修复，它根本没确认过内存到底是哪个模块涨上去的。

后来我重新用 debugging skill 走了一遍流程：

• 第一步，它要求我提供 OOM 之前的日志和内存快照
• 第二步，它让我先跑一个持续请求的脚本，复现内存上涨
• 第三步，它对比了两次 heap snapshot，发现是数据库连接池的连接没有被释放
• 第四步，它只改了连接池的 release 调用逻辑，补了一个回归测试

前后对比非常明显。不是模型变聪明了，而是它走了一遍"先复现-再定位-后修复"的标准流程，没有机会跳到猜测这一步去乱改代码。

3.4 成本与收益：多花在思考上的 token 值不值得

有人担心，加载 SKILL.md 会占更多 token，会不会很耗钱？

我实测下来，一个 SKILL.md 文件本身大约几百到一千多个字，换算成 token 大概就是 200 到 700 左右。每次任务开始加载一份 skill 文件，多出的成本其实非常有限。真正多花 token 的地方是 Thought Tree 引导的多轮步骤——AI 会多问几次问题、多跑几轮测试、多输出几步中间结论。但和它"乱改代码导致线上故障"或者"你手动排查两小时"的成本比起来，这点 token 开销几乎可以忽略。

我的观点是：如果你用 Claude Code 只是写几个一次性小脚本，追求的是快，那 superpowers 对你价值不大；但如果你在维护会长期运行的业务代码、需要稳定的输出质量，那多花几百个 token 换"少一个隐藏炸弹"，非常划算。

4. 内置 skills 逐个拆解：可以直接抄作业的几个实战技能

4.1 仓库里常见的技能清单

不同的版本和分支里，技能数量和名称会有些出入，我装的时候仓库里大约有七八个常用 skill。为了让你对"能干什么"有个整体概念，我整理了一个表格：

这些技能并不是互相孤立的，它们很多时候是串联使用的。比如一个需求来了，先 brainstorming 定方案，再 writing-plans 拆任务，然后 test-driven-development 写测试写实现，出 bug 了走 debugging，debugging 过程中如果测试失败但看不出来是哪里坏，再走 test-analysis。整套就是一个完整的工作流。

4.2 debugging 和 test-analysis：修复 bug 的黄金组合

用了一段时间下来，我觉得最有价值的两个配套技能是 debugging 和 test-analysis。

debugging 解决的是"该往哪个方向查"的问题，test-analysis 解决的是"测试失败到底说明了什么问题"的问题。两者配合起来的场景很常见：修改一个老模块的时候，可能你动了一行代码，原本无关的测试突然挂了。这时候 AI 要么以为是自己的修改有问题，要么以为是测试本身写得不对，要么慌慌张张地改回原状。test-analysis 会强制它先分析：这个测试断言的对象是什么、它失败是反映哪个行为变化、这个变化是不是这次修改引起的。

我遇到过一次相当隐蔽的情况：AI 修复了一个竞态条件的 bug，改动本身完全正确，结果另一个测试挂了。如果不分析直接就回滚修改，bug 就没修成。test-analysis 走了一遍之后发现，挂掉的测试恰好是在断言那个不正确的旧行为，是测试本身和修复目标冲突了。更新测试之后，一切恢复正常。

这种"代码和测试谁对谁错"的判断，恰恰是普通模式下 AI 最薄弱的地方。因为模型从训练数据里学到的倾向是"尽量让测试变绿"，它很容易做出"既然挂了，那就把测试改掉"的偷懒决策。而 test-analysis 给的流程会先判断测试失败的类型，再决定到底是改代码还是改测试，还有一个明确的兜底原则：如果测试是在描述一个用户真正需要的行为，那就必须改代码而不是改测试。

4.3 brainstorming 和 writing-plans：需求发散到落地的链路

很多人没意识到，superpowers 最有用的地方不只是修 bug，而是做新功能的前期思考。

我实测过 brainstorming skill 的效果：在对话里说一句"我需要给订单模块加一个批量导出功能，先别写代码，帮我做方案"，如果 AI 自动加载了 brainstorming，它会给出一组完全不同的输出——不再是直接开始生成代码，而是先列三到五个可能方案，每个方案给出优缺点、实现成本、推荐选型。比如它会对比：

• 方案 A：同步导出，简单直接，但大数据量容易超时
• 方案 B：后台异步生成文件，用户下载，复杂度中等，支持大数据量
• 方案 C：走消息队列加分布式任务，最稳，但对当前项目来说过度设计

然后它会要求你做一个选择，或者直接给出推荐。

这个价值在于：AI 在自由模式下很容易锚定在它"第一个想到的方案"上，诱导你做出错误的决策；而 brainstorming 流程强制它先探索方案空间，本质上是在对抗模型的"急于下结论"倾向。

方案定了之后，接上 writing-plans 技能，AI 会把方案拆成一个一个可执行的步骤，每步都有明确的验收标准。例如：

1. 新增导出任务的表结构和状态字段
2. 实现任务创建接口，写入队列
3. 实现后台生成逻辑，文件上传到临时存储
4. 实现下载接口和过期清理
5. 补充并发通知

有了这份计划，再选择用不用 test-driven-development 去推进实现，整个流程就很顺了。

4.4 其他技能和私有 skill 的扩展思路

除了上面这几个核心技能，taking-a-break 看起来最像"非技术技能"，但你如果在 AI 编程工具上花时间长，会意识到它的价值。人有思维僵化的时候，AI 也有——同一个模型在同一个上下文里反复绕圈，越绕越死。taking-a-break 会强制它做一个状态重置：停下来、用新的视角重新描述问题、列出已经试过但无效的做法、再从一个未尝试过的假设重新开始。这招在复杂 bug 上实测相当管用。

更关键的是，这个结构让你能"造自己的技能"。你只需要在.superpowers/content/下新建一个目录，比如code-review，里面放一个同样结构的 SKILL.md，把团队代码评审的检查项写进去。从此往后，每次提交代码前让 AI 加载这个私有 skill，它就会按你团队的规范逐条检查。这个能力其实比内置技能更有长期价值——它不是把外部方法论搬进来，而是把你自己的经验固化成了 AI 的肌肉记忆。

5. 在 Claude Code 里正确调用 skill：@ 引用与自动触发两套姿势

5.1 显式调用：直接用 @ 把技能文件塞给 AI

安装和原理都了解之后，回到日常使用上。你在对话里怎么让 AI 用某个技能？

最直接的方式是显式引用。在 Claude Code 的输入框里，直接输入@加文件路径，选中你想用的那个 SKILL.md。比如：

@.superpowers/content/debugging/SKILL.md 帮我查一下这个接口偶发 500 的问题

这么做的效果是：AI 会先读取debugging/SKILL.md的内容，然后识别出"用户要求我按照这个技能来执行"，接着它就会严格照着文件里的 Thought Tree 走，而不是凭直觉自由发挥。

我为什么要强调"显式引用"？因为自动触发虽然方便，但在某些场景下不够可靠。你如果明确知道这个任务应该走什么流程，直接指定技能文件是控制性最强的做法——AI 大概率不会跑偏。

显式引用时有一点要注意：路径是相对当前项目根目录的，所以开头的.superpowers/content/一定不能省。如果嫌路径长，可以先输入@.然后按 Tab，Claude Code 会自动补全候选文件，不用手敲。

5.2 自动触发：让 AI 自己判断该用哪个技能

安装时复制的 CLAUDE.md 里通常包含一段"技能加载说明"，大意是告诉 Claude Code：项目里有这些技能文件，当用户任务匹配某技能时，先阅读对应的 SKILL.md 再响应。

当你什么都不做，直接说一句话，比如"前端这个页面在 Safari 上渲染乱了，帮我看看"，AI 可能会自动读取 debugging skill，然后按流程问你：复现步骤是什么、控制台有没有报错、需要什么设备信息。这就是自动触发——用户在对话里完全感觉不到 skills 的存在，但 AI 的行为明显变得更有条理。

自动触发依赖的是 CLAUDE.md 的内容是否清晰，以及模型对 description 匹配的准确性。实测下来，它多数时候是准的，但偶尔会"乱触发"——比如一个很简单的提问也触发了 brainstorming，或者该触发 debugging 的时候没触发，结果 AI 又回到自由发挥模式。

所以我的建议是：日常简单任务，依赖自动触发就行，省事；关键任务和明确要走流程的任务，用显式 @ 引用，最稳。

5.3 两套姿势结合使用的最佳实践

再分享一个实际操作中的习惯：在任务开头加一句"确认你准备用哪个技能来执行这个任务，并简述步骤"。这样 AI 会先输出类似"我将按 debugging skill 的流程处理：先复现，再定位，最后修复"这样的说明。看到这句话，你就知道它有没有正确识别场景。如果它没说要用 skill，或者说的技能明显不对，你就可以立刻纠正——重新 @ 一个正确的 SKILL.md 进去，或者手动补充关键约束。

时间长了你会形成自己的判断：哪些任务适合让 AI 自己选流程，哪些任务必须硬性指定。比如我自己，凡是涉及生产环境代码修改、数据库变更、复杂的 bug 排查，一律手动 @；凡是加注释、重命名变量、简化表达式这类低风险操作，就完全交给自动触发。

5.4 一次真实的对话体验对比

为了更直观，我写一个简化版的对话对比。左侧是没用 skill 的回复习惯，右侧是加载 debugging skill 之后的回复习惯：

场景：用户说"我的订单导出功能突然超时，昨天还能用"。

• 自由模式：AI 大概率会直接读代码，然后说"我怀疑是导出数据量太大导致，建议加一个分页批量处理"然后就开工了。
• debugging 模式：AI 会说"在动手前，我需要先确认三个信息：最近是否改过导出逻辑、超时具体出现在第几秒、有没有对应时间段的日志。请提供后我先复现，再定位。"

看起来"多问了几个问题、效率变低了"，但实际上，前者是在用猜测覆盖不确定性，后者是在把不确定性压缩到最小之后再动手。我最终的体验是：后者看着慢，但通常一次就修对；前者看着快，一半概率要返工。

6. 用了一段时间的真实体会：哪些场景赚了，哪些坑要躲

6.1 收益最大的三个场景

说实话，不是所有任务加载 superpowers 都有明显感觉。它在我这三类场景里收益最明显：

• 老项目修 bug：项目越老，历史包袱越重，AI 自由发挥的破坏力越大。debugging 流程强制它先复现、后修复，显著降低了"修好一个 bug 引入两个新 bug"的概率。
• 需要严格回归的模块改动：有测试的项目里，test-driven-development 和 test-analysis 配合使用，AI 会先把预期行为固化成测试，再动手改实现，最后跑全量回归。这个流程在自由模式下经常被跳过。
• 新需求的方案设计：brainstorming 解决了"AI 直接写第一个想到的方案"的问题。我甚至有两次在它列出的多个方案里发现，它推荐的方案并不是最优解，反而是它发散出来的另一个方案更契合项目现状。这一步如果没有流程约束，你根本看不到那个更好的选项。

6.2 坑一：不是所有技能都该自动触发，过度流程化也是成本

前面讲了自动触发的好处，但有一个副作用：它会让你觉得"AI 变啰嗦了"。尤其是当一个明确简单的问题被判断成某个 skill 的匹配场景时，AI 会按流程问一堆问题，实际上你只是想要一个快速答案。

我遇到过的情况是：我只想让 AI 把 README 里的几个错别字改一下，结果它触发了 writing-plans，开始列修改计划，差点生成一份变更文档。这时候显式 @ 反而是一种"踩刹车"的手段——比如我直接用@.superpowers/content/.../SKILL.md里不存在的场景，或者直接说"不要走任何 skill 流程，直接改掉错别字"。

所以我的结论是：不要试图让所有 skills 保持自动挂载。如果你发现某个 skill 经常在不该触发的时候触发，最简单的处理是把 CLAUDE.md 里的加载说明调整一下，改成"仅当用户明确要求或问题属于复杂场景时，才加载相应技能"。

6.3 坑二：中文描述和英文 skill 描述之间的语义错位

superpowers 的技能描述是英文的，而你日常对话可能是中文的。这就会产生一个比较隐蔽的坑：AI 在匹配"用户任务"和"技能描述"的时候，跨语言语义相似度有时候会判断不准。

比如你说"帮我测一下这个接口"，AI 可能不会触发 test-driven-development，因为这句话听起来像一个简单请求，而不是"开发一个经过测试的功能"。但如果你说"这个功能还没有测试覆盖，请按 TDD 流程先补测试，再实现功能"，触发就非常准确。

怎么解决？两个办法。一是熟悉技能清单，在关键需求里主动带上技能名字："请用 test-driven-development 技能处理这个功能"；二是如果你长期用中文协作，可以考虑把自己常用技能的 description 改成中文，这个是允许的——它就是一个 Markdown 文件里的字段，按自己的语言习惯改就行。唯一要记住的是，改完之后 AI 能匹配得更好，但指令性的步骤内容建议保持英文不动，避免破坏原有的结构。

6.4 坑三：项目更新快，建议维护自己的 fork

superpowers 是个活跃的开源项目，更新频率不低。这意味着"装一次用一年"的思路行不通，隔一段时间去看，仓库里可能就多了新技能或者修掉了一些步骤里的问题。

但如果你直接拷贝了仓库文件放进项目里，后续更新就麻烦了。我建议如果打算长期用在生产项目上，最好把仓库 fork 一份到自己名下，然后拉下来维护。这样你做本地修改（比如改中文 description、加自己的私有技能）不会和上游冲突，等上游有值得同步的更新时再手动 merge 过来。

还有一个很容易被忽略的细节：项目一旦装到了多个工程里，版本就很容易漂移，这个项目的是上个月的版本，那个项目的是这周的版本，行为不一致会让人困惑。最好在某个约定的位置记录一下安装来源的 commit 号，方便回溯。

6.5 最后分享一个我现在最常用的扩展习惯

说到维护 fork，我顺便分享一个让我受益最多的延展用法：把团队的 Code Review 检查清单做成了一个私有 skill。

以前我们团队的新人提代码，我要逐条看命名、错误处理、边界条件、日志规范，来回评论几轮。后来我照着 superpowers 里的结构，写了一个code-review技能，把我们团队的所有检查项固化成了 SKILL.md：

1. 先通读需求描述，确认改动范围与需求一致
2. 按清单检查命名、类型安全、边界条件
3. 检查错误处理是否兜住了异常路径
4. 检查日志是否包含关键上下文
5. 输出评论时给修改建议，不只是指出问题

之后每次有代码评审需求，我就让 AI 加载这个技能，它按清单逐项出结果，虽然有几次判断不够准，但整体效率提升非常明显。这件事给我的最大启发在于：superpowers 真正的价值不是那几个内置技能，而是它提供了一套"把成熟方法论固化成 AI 执行模板"的机制。任何你知道怎么做但又嫌重复的工作，理论上都可以变成一个 SKILL.md 文件，从此交给 AI 去按步骤执行。

如果你也想长期用下去，不妨从一个你最熟悉、最重复的环节开始写自己的第一个私有 skill。装完、跑通、看到 AI 按你的思路做事之后，你对这套"思维外挂"的理解会比我写多少字都管用。