最近我经常跟朋友聊到一个现象Claude Code写小脚本确实麻利但项目一复杂就开始自由发挥——该做测试不做做着做着就跑偏需求最后交出来的代码能用但没人敢维护。这其实是工具本身的通病它有能力但缺方法论。直到我刷到一个叫superpowers的开源项目把一堆资深工程师的工作习惯打包成了 Agent Skills装上之后 Claude 的行为方式会发生肉眼可见的变化。这篇文章就把我这两周的实际使用经验完整分享一下包括它到底装了些什么、怎么装、怎么用以及哪些场景其实不该用它。这项目不是什么玄学外挂就是一组按规范编写的 SKILL.md 文件Claude Code 会在任务需要时自动加载对应技能让它在干活前先规划、写代码前先写测试、完工后做系统验证。下面我从项目拆解、安装验证、实战跑单、使用边界这几个角度把整个过程说清楚。1. 先别急着装理解 superpowers 到底改了 Claude 的什么行为1.1 这个项目的本质把工程师方法论翻译成 AI 能执行的流程很多人第一次看到 superpowers 的仓库会有点懵没有花哨的界面没有复杂的算法目录里就是一排排的 markdown 文件。但正是这些文件解决了 Claude Code 最大的问题——它在独立干活时缺少一套稳定的工程化工作流。举个直观的例子。没装 superpowers 之前我给 Claude 一个稍微复杂的任务写一个工具分析某个 git 仓库的提交趋势。它大概率会直接啪地写出一整段脚本然后告诉我完成了。代码能跑但你要问它测试在哪、边界条件考虑了吗、如果仓库是空的怎么办它多半是愣一下然后现场补。这就是典型的能干活但不像工程师在干活。superpowers 的做法是给 Claude 注入一套行为模式接到需求先区分我是该直接做还是该先规划规划时把大任务拆成可验证的小步骤写代码前先想清楚怎么测写完不靠感觉说没问题而是用证据去验证。说白了它让 AI 从代码生成器变成了讲方法和流程的结对工程师。1.2 Skills 和普通提示词、系统 prompt 的关键差异这里要讲清楚一个概念因为很多人会把 skills 误当成更长的 system prompt。两者最大的区别在于加载机制。Claude Code 的 Agent Skills 是按需加载的。每个 skill 都有一个 description 字段Claude 会根据当前任务判断这活需要什么样的知识/流程然后去读对应的 SKILL.md。这就有个明显的好处prompt 是每轮对话都硬塞给模型的token 消耗巨大而且内容太多反而会稀释注意力skill 只在需要的时候才被读进来平时就安安静静躺在目录里不占用任何上下文资源。superpowers 里那十多个技能文件本质上就是十多个专家级操作手册。当 Claude 决定要按 TDD 流程写代码时它才翻开《test-driven-development》这本手册照着里面的步骤执行。这个设计思路非常聪明也解释了为什么装了它之后 Claude 的临场发挥明显减少。1.3 一套方法论集合而不是单个技巧我见过一些类似的AI 工作流项目往往是给你一个大而全的 markdown让你塞进 CLAUDE.md 里。superpowers 不一样的地方在于它把方法论拆成了互相独立、又可以组合的单元。比如你可以让 Claude 先用structured-planning把任务拆解清楚接着用test-driven-development来写实现中途发现需求理解有偏差drift-control会主动提醒你已经偏离原始目标了最后用systematic-verification做完整验证。这些技能不互相打架而是像管道一样串联起来。这也是我推荐把 AGENTS.md 写得尽量精简而把流程交给 skills 的原因——项目背景是这个仓库是什么技能体系管的是该用什么方式干活,两者职责分开Claude 才不容易混乱。2. 逐个拆解 skills 目录这十几个技能文件分别管什么事2.1 动手之前的大脑规划与探索类技能先说我装完后最先翻的structured-planning。这个技能的核心是让 Claude 在动手前先输出一份结构化的执行计划任务目标、关键约束、分步方案、每步的完成标准、验证方式。它逼着 AI 把怎么做这件事说出来而不是闷头就写。实际使用中它的效果很直观以前 Claude 接到大任务经常东一榔头西一棒槌现在它会先把任务拆成 3-5 个阶段每阶段给出明确的交付物。这个行为特别适合设计系统、重构项目这类想清楚再动手的活。和它搭档的是plan-and-execute。这两个听起来像实际分工不同structured-planning关注方案怎么拆plan-and-execute关注拆完之后怎么按阶段推进、每步执行完怎么回看。我自己的感受是小任务只需后者轻量跑一遍大任务才需要前者做完整规划。还有一个必须提的brainstorming。它会在动手前强制 Claude 先给出多个备选方案并简要分析每个方案的利弊。以前让 Claude给出方案对比它总是走个过场装了这个技能后它会真正停下来发散、比较、收敛而不是直接跳到自认为最优的那条路上去。2.2 写代码过程中的纠偏器TDD 与纪律约束这一组是我最常用的尤其test-driven-development。这个技能不是简单告诉 Claude要写测试而是给出了一套严格的循环先写一个会失败的测试运行确认它确实失败再写最简实现让测试通过接着重构重复这个过程。我第一次用的时候还挺不习惯——Claude 居然会先拒绝写实现代码理由是测试还没出现预期的失败。这种机械感恰恰是工程质量的来源。配合disciplined-coding使用它还会强制 Claude 遵守一系列编码纪律不做超出当前任务范围的改动、不删没搞懂用途的代码、每处改动都给出理由。debugging这个技能值得单独说说。以前让 Claude 查 bug它最常见的操作是盯着代码看几秒然后给出一个猜测。而 superpowers 的 debugging 流程要求它先建立假设再设计最小实验去验证假设根据实验结果修正假设最后才定位根因。这套流程对 AI 特别适用因为它本质上是个推理器需要证据而不是直觉。2.3 收尾阶段的守门员验证与复盘类技能写完代码之后systematic-verification会登场。它会让 Claude 不满足于我测过了而是系统地列出验证清单正常路径、边界条件、异常输入、资源清理、向后兼容逐项给出证据。装了这个之后Claude 再也不敢随口说代码没问题因为它自己给自己定的规则就是每个结论都要有据可查。reflective-exploration也很有意思它在任务完成后引导 Claude 做复盘哪些步骤走弯了、哪些假设是错的、如果重来一次会怎么优化。这个技能在长周期项目里价值很高因为它能让 AI 在同一会话内持续积累经验而不是每次从零开始猜。还有drift-control我愿称它为全程监工。它会定期对照最初的计划检查当前行为一旦发现 Claude 在做需求之外的事情就主动指出这个改动不在当前目标范围内。这个技能在独立跑大任务时几乎必备AI 太容易在执行中途添加自己想当然的功能了。2.4 与人协作的技能沟通访谈与结对最后这组经常被忽略但实战价值不低。interviewing让 Claude 在信息不足时主动提问而不是瞎猜。以前它会默认你是一个懂技术的用户很多需求细节不说它就自己脑补有了这个技能它会像产品经理一样把关键信息问清楚再动手。pair-programming则是交互模式上的改变。它让 Claude 从接受命令然后执行变成边做边解释、边征求反馈的结对伙伴。如果你喜欢边写边沟通的工作方式这个技能体验会很好不过它对用户的参与度要求也高纯放手让它干活反而不合适。我把主要技能按场景整理成一张表方便快速查阅技能核心作用适合场景structured-planning任务拆分与完成标准定义大型功能开发、系统设计plan-and-execute分阶段推进与阶段回看多步骤实施类任务brainstorming多方案对比与收敛技术选型、方案设计test-driven-development先写失败测试再实现对工程质量要求高的编码disciplined-coding约束改动范围与编码纪律重构、大型代码库修改debugging假设-实验-验证式排障疑难 bug 定位systematic-verification系统性验证与证据检查需求交付前的最终检查drift-control发现并纠正目标漂移长时间无人干预的独立任务reflective-exploration任务复盘与经验沉淀复杂项目收尾后interviewing需求信息补全与确认需求描述不清晰时pair-programming边写边解释的协作模式喜欢深度交互的用户translate-implementations语言间迁移且行为一致跨语言代码移植3. 从拉代码到跑起来安装与验证的完整操作3.1 方式 A用环境变量全局切换到 superpowers 配置目录先说最常见、也最干净的安装方式。Claude Code 支持通过CLAUDE_CONFIG_DIR环境变量指定配置目录superpowers 仓库本身就是一个符合要求的配置目录。操作如下git clone https://github.com/obra/superpowers.git ~/superpowers export CLAUDE_CONFIG_DIR~/superpowers claude设置完之后Claude Code 会以~/superpowers作为配置根目录去读取它下面的 skills 子目录。这个方案的好处是原仓库完全不动git pull 更新技能很方便坏处是你原来的~/.claude目录里如果存了自定义命令、项目级的 settings.json这些配置在这个会话中就失效了。所以我建议长期使用的朋友把export CLAUDE_CONFIG_DIR~/superpowers写进 shell 的配置文件比如~/.bashrc或~/.zshrc这样每次启动终端自动生效不用每次手动敲。3.2 方式 B软链进默认的 ~/.claude/skills 目录如果你不想动环境变量更推荐这种方式。Claude Code 默认会扫描~/.claude/skills目录下的技能直接把 superpowers 里的技能软链过去就能识别git clone https://github.com/obra/superpowers.git ~/superpowers ln -s ~/superpowers/skills ~/.claude/skills claude这样做的核心优势是保留原有配置。你~/.claude下的 settings、commands 都还在只是多了一个 skills 软链路径。而且软链指向的是仓库里的 skills 源目录仓库一更新软链自动生效。我更推荐方式 B因为它侵入性小、容易回滚。想停用某个技能删掉软链里对应的子目录即可完全不影响其他配置。3.3 安装后的第一件事确认技能真的被识别了装完别急着开干先确认 Claude 能看到这些技能。打开 Claude Code 后分两步验证输入/skills查看当前可用的技能列表不同版本命令可能不同有的版本需要问 Claude 自己直接问它你加载了哪些技能它们的触发条件分别是什么如果它回答出来的名字和 superpowers 仓库里的目录对得上说明识别成功。我遇到过好几个人装完直接干结果技能根本没被加载Claude 行为和以前一模一样——就是因为没有做这个验证步骤。提示如果你用的 Claude Code 版本较旧可能还不支持 Agent Skills。建议先用claude --version确认版本再动手安装。3.4 安装过程中的三个典型坑第一个坑CLAUDE_CONFIG_DIR 指错了位置。这个环境变量要指向仓库根目录不是指向 skills 子目录。有些教程写得不清楚让人指到子目录里结果 Claude 根本找不到配置。判断标准很简单ls $CLAUDE_CONFIG_DIR能看到 skills 这个文件夹就说明指对了。第二个坑复制技能时只复制了 SKILL.md。很多技能文件里会有 references 子目录存了一些参考文档。只把 SKILL.md 复制过去技能就残缺了Claude 执行到一半可能找不到参考材料而陷入迷茫。所以要么整个目录复制/软链要么用 git submodule 管理别手动挑文件。第三个坑多个配置源互相覆盖。如果你同时设置了 CLAUDE_CONFIG_DIR 和项目目录下的.claude/skillsClaude 的加载优先级可能和你想的不一样。我的经验是个人全局技能放~/.claude/skills项目专用技能放项目目录里两边用软链互不干扰最省心。4. 实战验证用 TDD 技能从零做一个 Git 提交统计工具4.1 场景设定与 Claude 的自主选型纸上谈兵没意思我说一个完整的实操案例。任务背景我维护的一个开源仓库想分析最近 8 周的提交趋势看每周的提交数量和变更行数变化用来判断项目活跃度。需求给到 Claude 之后我故意没有指定任何技能想观察它自己怎么选。它首先调用了structured-planning几秒钟后输出了一份计划阶段一确认 git log 的输出格式兼容性区分 git 不同版本阶段二实现数据解析模块并用 pygit2 还是直接解析文本流做对比阶段三编写统计逻辑按周聚合阶段四补充命令行入口与输出格式化注意它在规划时就提出了一个我没有想到的点直接调git log解析文本流比绑 pygit2 更通用、零额外依赖。这是因为brainstorming技能的 description 在起作用促使它在阶段二做了方案对比而不是直接默认用某个库。4.2 真正进入 TDD 流程的感受规划做完它主动申请切换到test-driven-development技能。接下来发生的事情让我印象很深它先写了一个测试文件test_commit_stats.py里面测的是给定一段模拟的 git log 输出解析函数能正确返回按周聚合的统计结果包括空提交列表、不同时区的日期、跨年边界的提交这些用例。写完测试后它跑了一遍并展示了测试失败的信息原因是解析函数还没实现。然后它才开始写commit_stats.py的解析逻辑写完再跑测试全绿。整个过程严格遵守了先看到失败、再实现、再看到通过的循环。这和以前直接甩给你一段代码 一句我测过了是完全不同的质量级别。这中间还有个细节它实现到第二周聚合逻辑时停下来主动说这里有一个边界条件需要你确认如果某周的变更行数是负数比如纯删代码是否要单独标注这种主动追问需求细节的行为明显来自interviewing技能的加载。我给的是模拟数据所以标注了负数即可但它这个追问让工具从被动执行者变成了主动澄清需求的伙伴。4.3 中途差点跑偏drift-control 的现场干预这个案例里最精彩的部分出现在功能做完之后。Claude 说道接下来我可以顺便帮你生成一个 HTML 格式的图表让趋势更直观。这个提议本身听起来很美好但需求范围已经超了——我只要命令行表格输出不要 HTML 图表。如果是以前它可能已经在动手写图表代码了。但这次不一样drift-control的机制在后台发现了这个计划外功能扩展Claude 主动在对话里对需求偏差做出纠正表态这不在原始需求内我建议先记到待办清单里不在本次实现范围内。这个动作虽然技术上不复杂但恰恰是 AI 干活最稀缺的品质知道自己正在做什么以及什么不该做。我后来复盘如果当时真让它把图表写了工具的使用范围、代码复杂度、后续维护成本都会增加而且这个扩展未必是我想要的。4.4 最后的系统性验证与整体效果对比实现完成后它没有直接说完成了而是用systematic-verification走了一遍检查清单对不同 git 输出格式做了兼容测试验证了空仓库场景不报错确认了统计结果与手工抽查数据一致最后才交付。我把装机前后的行为放在一起对比差异非常明显维度安装前安装后任务拆解拿到需求直接写代码先出结构化计划再动手测试策略可选、靠自觉强制先写失败测试需求确认默认用户已说清主动追问模糊细节范围控制容易自由发挥漂移检测自动纠偏完工标准自述没问题系统验证 证据清单说实话单看任何一项技能都不算神奇但把这套流程串起来之后Claude 干活的靠谱程度有显著提升——至少它现在看起来像一个注意工程规范的开发者而不是一个急于交付代码的生成器。5. 用了两周之后的真心话优势、边界与定制思路5.1 别迷信 skills 越多越好按场景选装superpowers 默认带十几个技能但我在实际项目中并不是全部用上。比如pair-programming我很少主动触发因为我习惯让它独立跑任务brainstorming在小需求上也不值得用杀鸡不必用牛刀。关键是理解每个技能的 descriptionsettings里如果技能自带开关就合理控制别让 Claude 每次哪怕写个几十行的脚本也要给你输出一份完整规划。想控制哪个技能被优先使用最简单的方式是在对话里显式指定用 test-driven-development 流程处理这个任务或先不要做 structured-planning。Claude 会依据你的指令并参考技能的 description 来判断。如果你发现它选错了技能通常是 SKILL.md 里的 description 写得和实际行为不符你可以自己改描述来纠正。5.2 哪些场景我明确不建议上 superpowers我也踩过一些过度工程化的坑。比如临时查个 API 用法、让 Claude 帮忙解释一段报错、改一个几行的配置这类任务如果还让它先规划再验证整个交互会变得非常啰嗦。技能的加载本身是有开销的——更长的推理过程、更多的输出 token、更慢的响应速度。所以我的建议是小型任务直接说不要使用任何技能中型任务只开一两个关键技能比如 debugging大型任务才让它完整走流程。另外纯聊天、写作、情感类的场景也不适合它这套技能是围绕软件工程方法论设计的超出这个领域不会带来额外价值。5.3 把 superpowers 变成团队基建而不是个人玩具我用了一段时间后做的第一件事就是把~/superpowers仓库直接并入了团队项目的.claude目录管理。这样团队所有人 clone 项目后Claude Code 自动加载同一套技能大家的 AI 协作方式就是一致的——不会出现你用你的工作流我用我的提示词的混乱。更进一步我照着 SKILL.md 的格式写了一个团队专属技能把我们上线前必须检查的清单依赖安全检查、日志脱敏确认、性能基线比对封装成了一个新的 skill。Claude 在交付前会自动加载它做检查。这个思路值得借鉴superpowers 给的不只是现成的技能更是一套如何把方法论固化给 AI的模板。5.4 最后提醒一句关注仓库更新与版本变动这个项目迭代很快我安装后的两周内就遇到一次目录结构调整——部分技能从旧的目录移到了新的 skills 路径下网上很多老教程跟着失效。建议你以仓库 README 的最新说明为准如果发现某个技能加载不到了先去看看是不是目录结构变动了别急着删配置重装。另外如果你基于 superpowers 做了团队定制升级前最好先看 changelog或者把定制内容独立放在别的目录避免 git pull 时冲突。我自己是把团队技能放在单独目录superpowers 的原始技能通过软链引入两边互不干扰升级就是一条软链的事。说到底superpowers 这样的项目最大的价值不是给你一堆现成的技能文件而是示范了一种思路AI 的能力边界很大程度上取决于我们愿不愿意把自己的工作方法论清晰地整理出来、交给它去执行。工具在持续变强真正拉开差距的是使用工具的思路和流程。