Claude Code 用了两个多月我一度觉得瓶颈不在模型而在工作流。每次让它改需求它总是很积极地写出一大堆代码然后告诉我完成了可我一跑测试就红成一片。直到我装上 superpowers 这套 Skills才意识到问题出在哪儿——好用的 AI 编程搭档需要的不只是更强的模型而是一套能约束行为的工作纪律。superpowers 是 GitHub 上的一套 Claude Code 技能集来自 Jesse Vincent 的实践核心思路很直白把 TDD、先计划后动手、完成前自查这类优秀工程师的习惯打包成一份份 AI 能读懂的 Skill 文件。装上之后Claude 面对任务不再急着写实现而是先确认需求、先写测试、跑完测试再动手最后逐字核对输出。这篇文章我打算从它的设计思路、安装细节、内置技能拆解、实际体验和踩坑记录几个方面展开给想尝试的朋友一条可以直接照做的路径。1. 先说清楚 superpowers 到底解决了什么问题1.1 大多数 AI 编程助手缺的不是能力是纪律我见过太多人抱怨AI 写代码不靠谱实际打开对话记录一看问题几乎都是同一个提示词一丢出去模型立刻开始写实现中间没有任何验证环节。它默认你的需求是清楚的默认它的理解是对的默认写完的代码能跑。这三个默认在真实项目里几乎每一个都会出问题。这就像一个刚入职的实习生能力确实强但缺一套做事的顺序。你让他把这个模块重构一下他不会先问清楚接口约束、不会先看现有测试直接开写。写完了告诉你应该没问题。结果代码风格不统一、边界条件漏了一堆、测试跑不过。问题不在于他不懂代码而在于他没有形成工程纪律。superpowers 做的事就是把这套纪律固化成文件让 AI 每次开工前都按流程走。它不是某个单一功能而是一组 Skill 的组合拳核心目标只有一个让 AI 表现得像个成熟的工程师而不是个急于表现的实习生。1.2 核心机制用 Skill 文件给 AI 装上行为规则Claude Code 本身支持 Skills 机制简单说就是把一段精心设计的行为指令写进一个带格式的 Markdown 文件里模型在对话中会根据任务描述自动判断该加载哪个技能。每个 Skill 文件包含 frontmatter名称、描述和正文具体行为规则、工作流程、示例。superpowers 的特别之处在于它把多个 Skill 组织成了一个完整体系。比如最出名的 TDD Guard规定模型必须遵循先写测试 - 看到测试失败 - 再写实现 - 测试通过 - 重构的循环Ask for a Plan 则要求面对大任务时先输出详细计划经你确认后再动手。这些 Skill 之间相互配合再配合一份入口级的 CLAUDE.md 配置AI 的行为就从自由发挥变成按流程办事。可以把它类比成给 AI 装了一套 SOP标准作业程序。模型本身还是那个模型推理能力没有变但解题路径被约束了。就像导航软件同样的路况加上必须走高速和车速不超过 120的约束之后行驶策略会完全不同。这种约束不是限制模型而是把不确定性从流程里挤出去。1.3 谁适合装谁不建议装先说适合的愿意使用 TDD 的开发者或团队、对 AI 输出质量有要求的项目、需要多人协作而希望 AI 行为可预期的场景。我个人的体会是如果你原来的工作流已经很重视测试和代码审查superpowers 会让你觉得AI 突然开窍了因为它的默认行为和你的习惯一致。如果你是刚接触 Claude Code 的新手它也值得装因为相当于有人帮你把最佳实践预设好了。不太建议装的情况也有只想拿 AI 生成一次性脚本、跑完就扔的项目项目完全没有测试框架、也暂时不想补的以及你很不喜欢 AI 反过来追着你问需求的场景。TDD Guard 会在你没给测试入口时拒绝写实现代码这种顽固不是所有人都能接受的。所以先说清楚它不改变模型能力改变的是模型的行为契约接受这套契约再装。2. 安装与引入把整套技能装进你的 Claude Code2.1 前置条件与环境确认安装前先确认几个事情Claude Code 已经安装并能正常使用终端输入claude --version能看到版本号。你清楚自己的配置层级~/.claude/是全局配置目录影响所有项目项目根目录下的.claude/只对当前项目生效。终端网络通畅能正常访问 GitHub 仓库。这里多说一句配置层级的事。我见过有人在项目里折腾半天没生效最后发现是因为全局配置里有冲突规则。Claude Code 读取配置时项目级配置会覆盖全局配置但如果两者指令矛盾模型行为就会变得不可预测。建议安装前先看一眼自己现有的~/.claude/CLAUDE.md里写了什么避免后面合并时打架。2.2 安装步骤从 clone 到生效superpowers 的安装方式在仓库 README 里写得很清楚核心流程就三步下载仓库、安装技能文件、合并配置。我实际操作时用的命令大致如下# 1. 克隆仓库到本地 git clone https://github.com/obra/superpowers.git # 2. 进入仓库目录 cd superpowers接下来看 README 里的安装说明。不同版本提供的安装方式可能略有差异有的提供一键安装脚本有的需要手动复制。手动安装的核心动作是把skills目录里的内容放到 Claude Code 能识别的位置# 全局安装把 skills 复制到 ~/.claude/skills/ mkdir -p ~/.claude/skills cp -r skills/* ~/.claude/skills/ # 或者项目级安装放到当前项目的 .claude/skills/ mkdir -p .claude/skills cp -r skills/* .claude/skills/然后是 CLAUDE.md 的合并。仓库根目录下的CLAUDE.md是整个体系的入口配置它描述了模型应如何进入superpowers 模式。最简单的做法是把它的内容追加到你的~/.claude/CLAUDE.md全局或项目根目录的CLAUDE.md项目级里但要注意不是无脑追加得先看有没有规则冲突。后面第 5 部分我会单独讲冲突处理。如果你拿到的是新版本skills 目录里应该是符合 Claude Code 原生规范的子目录结构每个技能一个目录里面有 SKILL.md如果是旧版扁平结构仓库 README 通常会提供对应的转换或安装命令。我建议以 README 为准不要凭感觉猜。2.3 怎么确认装好了装完之后别急着开工先验证。打开 Claude Code输入/skills这个命令会列出当前环境所有可用的技能。如果能看到 tdd-guard、ask-for-a-plan、verify-completion 这些条目说明技能文件已经被正确识别。更直观的办法是直接给 AI 一个小任务比如写一个函数把列表中的重复元素去掉然后观察它的反应。如果它开始反问你输入输出的边界条件并要求先写测试说明 superpowers 已经在起作用了。我还习惯用一个更严格的验证方式直接问你当前遵循哪些开发流程 如果它说出类似先计划、再测试、后实现、最后验证的流程并且和你安装的 skill 描述一致那基本就是真装好了。2.4 全局还是项目级我的选择建议表格对比一下两种方式的差异维度全局安装项目级安装生效范围所有项目仅当前项目优点一次装好到处可用不影响其他项目团队可统一缺点可能和一些项目的特殊规范冲突每个项目都要重复配置适合场景个人日常使用团队协作、有严格项目规范我自己的做法是个人项目全局装公司项目项目级装。原因很简单公司项目往往有自己的一套 CLAUDE.md 规范全局的 superpowers 指令可能和它产生冲突而项目级安装可以精确控制每个仓库的行为。3. 内置 skills 逐个拆解它到底教了 AI 哪些本事3.1 强约束类TDD Guard、Ask for a Plan、Ask for Clarification这些技能的共同特点是管住 AI 的手。TDD Guard 是 superpowers 里最出名的技能它要求 AI 严格遵循测试驱动开发的循环先写测试运行并确认测试失败红灯再写实现代码让测试通过绿灯最后重构。它最核心的约束是没有失败测试的情况下不得写实现代码。我第一次体验时觉得特别别扭因为往常和 AI 对话都是你帮我写个函数它却先问我你要测试什么行为。但用了几天之后我意识到这个过程逼着我把需求想清楚——你不把行为定义成可测试的断言AI 就不动手这其实是帮你在需求阶段堵漏洞。Ask for a Plan 解决的是另一个问题AI 面对大型任务时喜欢一口气全部写完。结果往往是 500 行代码塞进一个文件中间没有 checkpoint错了也不知道错在哪一段。开了这个技能之后面对大任务它会先输出一个分步计划告诉你打算怎么做、每一步的产物是什么等你确认之后再动手。这个计划-确认-执行的节奏特别适合重构老项目或者实现跨模块功能。Ask for Clarification 对应的是需求模糊场景。以前 AI 遇到含糊的指令会直接猜猜错了返工重来。有了这个技能它会主动列出它看到的歧义点逐个向你确认。比如请优化这个接口的查询性能它不会立刻开始改而是先确认数据量大概多少、读多写少还是写多读少、有没有慢查询日志可以看。这些确认过程看着多花了几分钟实际上省掉了后面几小时的返工。3.2 工程习惯类Test-Command、Initialize Project State、Review TODO Comments如果说上一类是约束这一类更像是补全上下文。Test-Command 这个技能解决的问题特别实在Claude 默认不知道你的项目用什么命令跑测试它可能会猜pytest、npm test、go test猜错了就会给出错误的验证结论。这个技能会引导 AI 先找到项目的测试运行方式用正确的命令执行测试。它解决的问题本质上是AI 的验证工具链要和你项目一致否则后续所有 TDD 流程都是纸上的。Initialize Project State 要求 AI 在动手前先摸清项目现状目录结构、核心模块、相关文件的职责、有没有已存在的测试。这和上来就改代码是两种完全不同的工作方式。我自己的感受是开了它之后AI 的回答明显更懂这个项目因为它会引用具体的文件、具体的函数名而不是泛泛地给一段通用代码。Review TODO Comments 做的事很聪明代码里的 TODO/FIXME 注释往往记录了未完成的工作和已知的问题点。AI 接到新任务时会先扫一遍相关代码里的 TODO 注释结合这些上下文判断哪些地方是已知待办、哪些地方不能乱动。这个习惯对一个不熟悉代码库的开发者来说都很重要对 AI 来说更是如此因为它没有之前开发过这个项目的隐性记忆只能靠这些显式标记来补。3.3 质量检查类Verify Completion、Explain the Codebase、Research这一类管的是AI 说完成了到底真完成了没有。Verify Completion 是 AI 说谎的克星。很多 AI 工具的通病是生成代码后直接说完成测试通过但它根本没有真正运行测试。这个技能要求 AI 在汇报完成之前逐字检查输出实际运行验证命令并给出可证明的证据。装上之后AI 如果没跑测试就说完成你会看到它输出里多了一句我尚未验证因为测试命令返回了错误或者主动去修正问题。这种可验证的输出对代码审查来说价值巨大。Explain the Codebase 是一个先理解再动手的辅助技能。当任务涉及多个文件、跨模块改动时AI 会先向用户描述它对代码库的理解让人确认它理解正确之后再动手。这相当于把AI 的心智模型显式化了你可以在它开写之前发现它有没有理解偏。这种把思维过程暴露出来的做法比黑盒式地直接给结果要可靠得多。Research 针对的是需要外部知识的场景。AI 的静态知识有截止日期很多新库的新 API 它不知道。这个技能会让它在回答不确定的技术问题时先做研究比如查文档而不是凭空编造 API。实测中它对某个库的某个函数怎么用这类问题很有帮助能显著减少模型自信地写出了不存在的函数的情况。除了上面这些项目通常还有 IDE 集成相关技能比如配合 VS Code、JetBrains 系的用法和语言专项技能针对 Python、TypeScript、Rust 等语言的 TDD 操作指南。这些目录在仓库里都能看到装好之后用/skills就能列出完整清单具体清单建议以你 clone 到的版本为准因为项目一直在迭代。3.4 Skills 的加载机制AI 怎么知道该用哪个理解了这个机制你就知道为什么这套体系能跑通。每个 Skill 文件都有一个 description 字段模型在对话中会根据用户描述和上下文自动判断要激活哪些技能。换句话说你不需要手动去打开某一项技能只要它在技能目录里存在AI 会在合适的时机调用它。当然也可以手动干预。在 Claude Code 里输入/sk或/skills可以查看技能列表也可以手动指定加载某个技能。如果某个任务你希望 AI 强制走 TDD 流程可以在提示词里明确说遵循 TDD Guard 的流程这样它会优先加载对应技能。这个机制就像给 AI 准备了一个工具架它自己会拿合适的工具你偶尔也可以指定。4. 实操体验加了 superpowers 之后的工作流变化4.1 一个典型的 TDD 会话实录我用一个实际例子说明装上之后发生了什么。需求是给用户模块加一个按邮箱去重的功能。之前跟 AI 对话通常会变成这样 请实现按邮箱去重。 AI 立刻返回一段代码里面用set去重然后说完成了。结果一跑发现只处理了大小写完全一致的邮箱AliceExample.com和aliceexample.com被当成两个用户。装上 superpowers 之后同样的需求对话走向完全变了AI 先问邮箱去重的规则是什么区分大小写吗需要保留哪个记录如果两个记录时间不同以哪个为准我回答之后它开始写测试一个包含大小写混合邮箱的测试数组断言去重后只剩一条记录。它运行测试看到失败因为实现还没写然后才写实现代码再跑测试直到通过。最后它还会问我要不要重构一下把去重逻辑抽成一个独立的工具函数。这种变化最直接的好处是测试用例成了人和 AI 之间的共识文档。你说不清楚的地方测试会替你表达清楚AI 做错了测试会第一时间告诉你而不是等你上线后才发现。4.2 Verify Completion 在实战中的一次拦截有一次我让 Claude 修一个日期解析函数处理的时候没多在意。以前这种任务它基本上改完就汇报已完成、已验证通过。装上 Verify Completion 之后它的输出里多了一步它会真的去翻项目的测试文件找到日期解析相关的测试用例跑一遍。结果其中一个边界用例挂了——它修好了主路径但一个闰年 2 月 29 日的特殊情况没考虑到。然后它自己回去补了这个情况重新跑通所有测试之后才汇报完成。这个例子让我意识到Verify Completion 的价值不在于它多跑了几个命令而在于它把AI 说完成了这句话变成了有测试证据支撑的结论。代码审查的时候你不再需要自己去复现 AI 的所有操作因为它在输出里已经给出了执行过程和结果。这个对团队协作尤其重要审查者可以快速判断 AI 的自查是否到位。4.3 对日常效率的连带影响短期变慢长期变稳坦率说刚装上那几天我感觉效率反而变慢了。原来一个对话能直接生成一坨代码现在 AI 先问问题、再做计划、先写测试看起来多了一堆步骤。但跑了一个星期之后我把账算清楚了以前写代码快调试慢现在写代码慢调试几乎没有了。原来的工作流是AI 写 500 行 - 跑一次挂一片 - 来回修三轮现在是AI 写 30 行测试 - 写 100 行实现 - 一次过。总时间没有增加但代码质量和心理体验完全不同。对团队协作来说变化更明显。因为 superpowers 会引导 AI 分步提交、保留测试、验证后再合并代码 review 的时候我能看懂 AI 每一步在干什么而不是面对一个巨大的 diff 发愁。这种过程可见带来的信任感是用提示词堆不出来的。5. 踩坑记录和调优建议5.1 最常遇到的坑TDD Guard 卡住不动新手装上 superpowers 之后最常见的困惑是AI 怎么一直在写测试不写实现我让它生成一个工具函数它却反问了一堆问题、写了一大段测试然后说现在需要你确认测试用例是否符合预期。这个现象的原因要分两层看。第一层是技能设计如此TDD Guard 要求先有失败的测试这是刻意为之。第二层是项目环境问题如果项目里根本没有测试框架AI 不知道该用什么命令跑测试它就会卡在写测试这一步不知所措。解决方法是配合 Test-Command 技能先让 AI 搞清楚项目的测试命令。如果项目实在没有任何测试基础设施你也可以明确告诉它这是一个一次性脚本不要求写测试它会相应调整策略。power tools 是好工具但也得允许手动换挡。5.2 与已有 CLAUDE.md 配置的冲突第二个坑比较隐蔽。如果你之前已经在 CLAUDE.md 里写过自定义规则比如不要主动问用户直接给出答案装完 superpowers 后你就会发现它的行为变得很怪一会儿问问题一会儿又直接给答案像精神分裂一样。原因就是配置冲突。superpowers 的规则是主动追问、先测后写而你原有的规则是直接干活两条指令同时存在时模型的权重判断就会撕裂。我处理的办法是先把原有 CLAUDE.md 备份一份。逐条对比原有规则和 superpowers 规则找出互相矛盾的。把需要保留的原有规则重写让它们和 superpowers 的方向一致而不是互相打架。比如把不要主动问用户改成如果需求有歧义先列出假设再继续。这样既保留了你的个性化偏好又不破坏整体的工作流约束。5.3 只保留自己需要的 skills不是每个人都适合全量安装。我用了两个月之后最终只保留了五个核心技能TDD Guard、Ask for a Plan、Test-Command、Verify Completion、Initialize Project State。其他技能比如 Research、IDE 相关的我根据自己的工作方式选择性地去掉了。原因是每个技能都有成本描述越长、规则越多模型的注意力就被分散得越厉害响应可能变慢行为也可能被过度约束。保留最核心的几个让每个技能都有明确的适用边界实际效果反而更好。你可以这样操作# 进入技能目录 cd ~/.claude/skills # 列出所有技能 ls # 删除不需要的技能目录 rm -rf research如果你发现某个技能总是被错误触发也可以修改它的 description 字段让它只在真正需要时才被加载。这个动手调校的过程其实比单纯安装更有价值因为你会逐渐理解每个技能对 AI 行为的具体影响。5.4 我的最终配置参考最后分享一份我目前实际在用的配置给想直接抄作业的朋友参考。~/.claude/CLAUDE.md开头部分的要点是- 在开始任何编码任务前先确认需求是否清晰不清晰则列出问题并等待确认。 - 遵循测试驱动开发先写失败测试再写实现最后重构。 - 大任务必须先输出执行计划得到确认后再动手。 - 每次任务结束后必须实际运行验证命令并报告结果不允许未经验证声称完成。 - 主动了解项目结构和运行方式而不是假设。~/.claude/skills/目录下的技能保持精简只留我前面说的那五个。实际使用中这套配置让 Claude Code 的输出稳定性明显提升至少不会再出现没跑测试就说完成的情况。如果你也准备试我的建议是别一次全装。先开 TDD Guard、Ask for a Plan、Verify Completion 这三个跑一周观察它对工作流的影响再决定要不要加其他技能。把 superpowers 当成一套可以随时裁剪的工具箱而不是一个必须全量拥抱的框架你会发现它其实只是把那些你已经知道应该做、但总是忘记做的工作习惯一件件地补了回来。
Claude Code 用了两个多月我一度觉得瓶颈不在模型而在工作流。每次让它改需求它总是很积极地写出一大堆代码然后告诉我完成了可我一跑测试就红成一片。直到我装上 superpowers 这套 Skills才意识到问题出在哪儿——好用的 AI 编程搭档需要的不只是更强的模型而是一套能约束行为的工作纪律。superpowers 是 GitHub 上的一套 Claude Code 技能集来自 Jesse Vincent 的实践核心思路很直白把 TDD、先计划后动手、完成前自查这类优秀工程师的习惯打包成一份份 AI 能读懂的 Skill 文件。装上之后Claude 面对任务不再急着写实现而是先确认需求、先写测试、跑完测试再动手最后逐字核对输出。这篇文章我打算从它的设计思路、安装细节、内置技能拆解、实际体验和踩坑记录几个方面展开给想尝试的朋友一条可以直接照做的路径。1. 先说清楚 superpowers 到底解决了什么问题1.1 大多数 AI 编程助手缺的不是能力是纪律我见过太多人抱怨AI 写代码不靠谱实际打开对话记录一看问题几乎都是同一个提示词一丢出去模型立刻开始写实现中间没有任何验证环节。它默认你的需求是清楚的默认它的理解是对的默认写完的代码能跑。这三个默认在真实项目里几乎每一个都会出问题。这就像一个刚入职的实习生能力确实强但缺一套做事的顺序。你让他把这个模块重构一下他不会先问清楚接口约束、不会先看现有测试直接开写。写完了告诉你应该没问题。结果代码风格不统一、边界条件漏了一堆、测试跑不过。问题不在于他不懂代码而在于他没有形成工程纪律。superpowers 做的事就是把这套纪律固化成文件让 AI 每次开工前都按流程走。它不是某个单一功能而是一组 Skill 的组合拳核心目标只有一个让 AI 表现得像个成熟的工程师而不是个急于表现的实习生。1.2 核心机制用 Skill 文件给 AI 装上行为规则Claude Code 本身支持 Skills 机制简单说就是把一段精心设计的行为指令写进一个带格式的 Markdown 文件里模型在对话中会根据任务描述自动判断该加载哪个技能。每个 Skill 文件包含 frontmatter名称、描述和正文具体行为规则、工作流程、示例。superpowers 的特别之处在于它把多个 Skill 组织成了一个完整体系。比如最出名的 TDD Guard规定模型必须遵循先写测试 - 看到测试失败 - 再写实现 - 测试通过 - 重构的循环Ask for a Plan 则要求面对大任务时先输出详细计划经你确认后再动手。这些 Skill 之间相互配合再配合一份入口级的 CLAUDE.md 配置AI 的行为就从自由发挥变成按流程办事。可以把它类比成给 AI 装了一套 SOP标准作业程序。模型本身还是那个模型推理能力没有变但解题路径被约束了。就像导航软件同样的路况加上必须走高速和车速不超过 120的约束之后行驶策略会完全不同。这种约束不是限制模型而是把不确定性从流程里挤出去。1.3 谁适合装谁不建议装先说适合的愿意使用 TDD 的开发者或团队、对 AI 输出质量有要求的项目、需要多人协作而希望 AI 行为可预期的场景。我个人的体会是如果你原来的工作流已经很重视测试和代码审查superpowers 会让你觉得AI 突然开窍了因为它的默认行为和你的习惯一致。如果你是刚接触 Claude Code 的新手它也值得装因为相当于有人帮你把最佳实践预设好了。不太建议装的情况也有只想拿 AI 生成一次性脚本、跑完就扔的项目项目完全没有测试框架、也暂时不想补的以及你很不喜欢 AI 反过来追着你问需求的场景。TDD Guard 会在你没给测试入口时拒绝写实现代码这种顽固不是所有人都能接受的。所以先说清楚它不改变模型能力改变的是模型的行为契约接受这套契约再装。2. 安装与引入把整套技能装进你的 Claude Code2.1 前置条件与环境确认安装前先确认几个事情Claude Code 已经安装并能正常使用终端输入claude --version能看到版本号。你清楚自己的配置层级~/.claude/是全局配置目录影响所有项目项目根目录下的.claude/只对当前项目生效。终端网络通畅能正常访问 GitHub 仓库。这里多说一句配置层级的事。我见过有人在项目里折腾半天没生效最后发现是因为全局配置里有冲突规则。Claude Code 读取配置时项目级配置会覆盖全局配置但如果两者指令矛盾模型行为就会变得不可预测。建议安装前先看一眼自己现有的~/.claude/CLAUDE.md里写了什么避免后面合并时打架。2.2 安装步骤从 clone 到生效superpowers 的安装方式在仓库 README 里写得很清楚核心流程就三步下载仓库、安装技能文件、合并配置。我实际操作时用的命令大致如下# 1. 克隆仓库到本地 git clone https://github.com/obra/superpowers.git # 2. 进入仓库目录 cd superpowers接下来看 README 里的安装说明。不同版本提供的安装方式可能略有差异有的提供一键安装脚本有的需要手动复制。手动安装的核心动作是把skills目录里的内容放到 Claude Code 能识别的位置# 全局安装把 skills 复制到 ~/.claude/skills/ mkdir -p ~/.claude/skills cp -r skills/* ~/.claude/skills/ # 或者项目级安装放到当前项目的 .claude/skills/ mkdir -p .claude/skills cp -r skills/* .claude/skills/然后是 CLAUDE.md 的合并。仓库根目录下的CLAUDE.md是整个体系的入口配置它描述了模型应如何进入superpowers 模式。最简单的做法是把它的内容追加到你的~/.claude/CLAUDE.md全局或项目根目录的CLAUDE.md项目级里但要注意不是无脑追加得先看有没有规则冲突。后面第 5 部分我会单独讲冲突处理。如果你拿到的是新版本skills 目录里应该是符合 Claude Code 原生规范的子目录结构每个技能一个目录里面有 SKILL.md如果是旧版扁平结构仓库 README 通常会提供对应的转换或安装命令。我建议以 README 为准不要凭感觉猜。2.3 怎么确认装好了装完之后别急着开工先验证。打开 Claude Code输入/skills这个命令会列出当前环境所有可用的技能。如果能看到 tdd-guard、ask-for-a-plan、verify-completion 这些条目说明技能文件已经被正确识别。更直观的办法是直接给 AI 一个小任务比如写一个函数把列表中的重复元素去掉然后观察它的反应。如果它开始反问你输入输出的边界条件并要求先写测试说明 superpowers 已经在起作用了。我还习惯用一个更严格的验证方式直接问你当前遵循哪些开发流程 如果它说出类似先计划、再测试、后实现、最后验证的流程并且和你安装的 skill 描述一致那基本就是真装好了。2.4 全局还是项目级我的选择建议表格对比一下两种方式的差异维度全局安装项目级安装生效范围所有项目仅当前项目优点一次装好到处可用不影响其他项目团队可统一缺点可能和一些项目的特殊规范冲突每个项目都要重复配置适合场景个人日常使用团队协作、有严格项目规范我自己的做法是个人项目全局装公司项目项目级装。原因很简单公司项目往往有自己的一套 CLAUDE.md 规范全局的 superpowers 指令可能和它产生冲突而项目级安装可以精确控制每个仓库的行为。3. 内置 skills 逐个拆解它到底教了 AI 哪些本事3.1 强约束类TDD Guard、Ask for a Plan、Ask for Clarification这些技能的共同特点是管住 AI 的手。TDD Guard 是 superpowers 里最出名的技能它要求 AI 严格遵循测试驱动开发的循环先写测试运行并确认测试失败红灯再写实现代码让测试通过绿灯最后重构。它最核心的约束是没有失败测试的情况下不得写实现代码。我第一次体验时觉得特别别扭因为往常和 AI 对话都是你帮我写个函数它却先问我你要测试什么行为。但用了几天之后我意识到这个过程逼着我把需求想清楚——你不把行为定义成可测试的断言AI 就不动手这其实是帮你在需求阶段堵漏洞。Ask for a Plan 解决的是另一个问题AI 面对大型任务时喜欢一口气全部写完。结果往往是 500 行代码塞进一个文件中间没有 checkpoint错了也不知道错在哪一段。开了这个技能之后面对大任务它会先输出一个分步计划告诉你打算怎么做、每一步的产物是什么等你确认之后再动手。这个计划-确认-执行的节奏特别适合重构老项目或者实现跨模块功能。Ask for Clarification 对应的是需求模糊场景。以前 AI 遇到含糊的指令会直接猜猜错了返工重来。有了这个技能它会主动列出它看到的歧义点逐个向你确认。比如请优化这个接口的查询性能它不会立刻开始改而是先确认数据量大概多少、读多写少还是写多读少、有没有慢查询日志可以看。这些确认过程看着多花了几分钟实际上省掉了后面几小时的返工。3.2 工程习惯类Test-Command、Initialize Project State、Review TODO Comments如果说上一类是约束这一类更像是补全上下文。Test-Command 这个技能解决的问题特别实在Claude 默认不知道你的项目用什么命令跑测试它可能会猜pytest、npm test、go test猜错了就会给出错误的验证结论。这个技能会引导 AI 先找到项目的测试运行方式用正确的命令执行测试。它解决的问题本质上是AI 的验证工具链要和你项目一致否则后续所有 TDD 流程都是纸上的。Initialize Project State 要求 AI 在动手前先摸清项目现状目录结构、核心模块、相关文件的职责、有没有已存在的测试。这和上来就改代码是两种完全不同的工作方式。我自己的感受是开了它之后AI 的回答明显更懂这个项目因为它会引用具体的文件、具体的函数名而不是泛泛地给一段通用代码。Review TODO Comments 做的事很聪明代码里的 TODO/FIXME 注释往往记录了未完成的工作和已知的问题点。AI 接到新任务时会先扫一遍相关代码里的 TODO 注释结合这些上下文判断哪些地方是已知待办、哪些地方不能乱动。这个习惯对一个不熟悉代码库的开发者来说都很重要对 AI 来说更是如此因为它没有之前开发过这个项目的隐性记忆只能靠这些显式标记来补。3.3 质量检查类Verify Completion、Explain the Codebase、Research这一类管的是AI 说完成了到底真完成了没有。Verify Completion 是 AI 说谎的克星。很多 AI 工具的通病是生成代码后直接说完成测试通过但它根本没有真正运行测试。这个技能要求 AI 在汇报完成之前逐字检查输出实际运行验证命令并给出可证明的证据。装上之后AI 如果没跑测试就说完成你会看到它输出里多了一句我尚未验证因为测试命令返回了错误或者主动去修正问题。这种可验证的输出对代码审查来说价值巨大。Explain the Codebase 是一个先理解再动手的辅助技能。当任务涉及多个文件、跨模块改动时AI 会先向用户描述它对代码库的理解让人确认它理解正确之后再动手。这相当于把AI 的心智模型显式化了你可以在它开写之前发现它有没有理解偏。这种把思维过程暴露出来的做法比黑盒式地直接给结果要可靠得多。Research 针对的是需要外部知识的场景。AI 的静态知识有截止日期很多新库的新 API 它不知道。这个技能会让它在回答不确定的技术问题时先做研究比如查文档而不是凭空编造 API。实测中它对某个库的某个函数怎么用这类问题很有帮助能显著减少模型自信地写出了不存在的函数的情况。除了上面这些项目通常还有 IDE 集成相关技能比如配合 VS Code、JetBrains 系的用法和语言专项技能针对 Python、TypeScript、Rust 等语言的 TDD 操作指南。这些目录在仓库里都能看到装好之后用/skills就能列出完整清单具体清单建议以你 clone 到的版本为准因为项目一直在迭代。3.4 Skills 的加载机制AI 怎么知道该用哪个理解了这个机制你就知道为什么这套体系能跑通。每个 Skill 文件都有一个 description 字段模型在对话中会根据用户描述和上下文自动判断要激活哪些技能。换句话说你不需要手动去打开某一项技能只要它在技能目录里存在AI 会在合适的时机调用它。当然也可以手动干预。在 Claude Code 里输入/sk或/skills可以查看技能列表也可以手动指定加载某个技能。如果某个任务你希望 AI 强制走 TDD 流程可以在提示词里明确说遵循 TDD Guard 的流程这样它会优先加载对应技能。这个机制就像给 AI 准备了一个工具架它自己会拿合适的工具你偶尔也可以指定。4. 实操体验加了 superpowers 之后的工作流变化4.1 一个典型的 TDD 会话实录我用一个实际例子说明装上之后发生了什么。需求是给用户模块加一个按邮箱去重的功能。之前跟 AI 对话通常会变成这样 请实现按邮箱去重。 AI 立刻返回一段代码里面用set去重然后说完成了。结果一跑发现只处理了大小写完全一致的邮箱AliceExample.com和aliceexample.com被当成两个用户。装上 superpowers 之后同样的需求对话走向完全变了AI 先问邮箱去重的规则是什么区分大小写吗需要保留哪个记录如果两个记录时间不同以哪个为准我回答之后它开始写测试一个包含大小写混合邮箱的测试数组断言去重后只剩一条记录。它运行测试看到失败因为实现还没写然后才写实现代码再跑测试直到通过。最后它还会问我要不要重构一下把去重逻辑抽成一个独立的工具函数。这种变化最直接的好处是测试用例成了人和 AI 之间的共识文档。你说不清楚的地方测试会替你表达清楚AI 做错了测试会第一时间告诉你而不是等你上线后才发现。4.2 Verify Completion 在实战中的一次拦截有一次我让 Claude 修一个日期解析函数处理的时候没多在意。以前这种任务它基本上改完就汇报已完成、已验证通过。装上 Verify Completion 之后它的输出里多了一步它会真的去翻项目的测试文件找到日期解析相关的测试用例跑一遍。结果其中一个边界用例挂了——它修好了主路径但一个闰年 2 月 29 日的特殊情况没考虑到。然后它自己回去补了这个情况重新跑通所有测试之后才汇报完成。这个例子让我意识到Verify Completion 的价值不在于它多跑了几个命令而在于它把AI 说完成了这句话变成了有测试证据支撑的结论。代码审查的时候你不再需要自己去复现 AI 的所有操作因为它在输出里已经给出了执行过程和结果。这个对团队协作尤其重要审查者可以快速判断 AI 的自查是否到位。4.3 对日常效率的连带影响短期变慢长期变稳坦率说刚装上那几天我感觉效率反而变慢了。原来一个对话能直接生成一坨代码现在 AI 先问问题、再做计划、先写测试看起来多了一堆步骤。但跑了一个星期之后我把账算清楚了以前写代码快调试慢现在写代码慢调试几乎没有了。原来的工作流是AI 写 500 行 - 跑一次挂一片 - 来回修三轮现在是AI 写 30 行测试 - 写 100 行实现 - 一次过。总时间没有增加但代码质量和心理体验完全不同。对团队协作来说变化更明显。因为 superpowers 会引导 AI 分步提交、保留测试、验证后再合并代码 review 的时候我能看懂 AI 每一步在干什么而不是面对一个巨大的 diff 发愁。这种过程可见带来的信任感是用提示词堆不出来的。5. 踩坑记录和调优建议5.1 最常遇到的坑TDD Guard 卡住不动新手装上 superpowers 之后最常见的困惑是AI 怎么一直在写测试不写实现我让它生成一个工具函数它却反问了一堆问题、写了一大段测试然后说现在需要你确认测试用例是否符合预期。这个现象的原因要分两层看。第一层是技能设计如此TDD Guard 要求先有失败的测试这是刻意为之。第二层是项目环境问题如果项目里根本没有测试框架AI 不知道该用什么命令跑测试它就会卡在写测试这一步不知所措。解决方法是配合 Test-Command 技能先让 AI 搞清楚项目的测试命令。如果项目实在没有任何测试基础设施你也可以明确告诉它这是一个一次性脚本不要求写测试它会相应调整策略。power tools 是好工具但也得允许手动换挡。5.2 与已有 CLAUDE.md 配置的冲突第二个坑比较隐蔽。如果你之前已经在 CLAUDE.md 里写过自定义规则比如不要主动问用户直接给出答案装完 superpowers 后你就会发现它的行为变得很怪一会儿问问题一会儿又直接给答案像精神分裂一样。原因就是配置冲突。superpowers 的规则是主动追问、先测后写而你原有的规则是直接干活两条指令同时存在时模型的权重判断就会撕裂。我处理的办法是先把原有 CLAUDE.md 备份一份。逐条对比原有规则和 superpowers 规则找出互相矛盾的。把需要保留的原有规则重写让它们和 superpowers 的方向一致而不是互相打架。比如把不要主动问用户改成如果需求有歧义先列出假设再继续。这样既保留了你的个性化偏好又不破坏整体的工作流约束。5.3 只保留自己需要的 skills不是每个人都适合全量安装。我用了两个月之后最终只保留了五个核心技能TDD Guard、Ask for a Plan、Test-Command、Verify Completion、Initialize Project State。其他技能比如 Research、IDE 相关的我根据自己的工作方式选择性地去掉了。原因是每个技能都有成本描述越长、规则越多模型的注意力就被分散得越厉害响应可能变慢行为也可能被过度约束。保留最核心的几个让每个技能都有明确的适用边界实际效果反而更好。你可以这样操作# 进入技能目录 cd ~/.claude/skills # 列出所有技能 ls # 删除不需要的技能目录 rm -rf research如果你发现某个技能总是被错误触发也可以修改它的 description 字段让它只在真正需要时才被加载。这个动手调校的过程其实比单纯安装更有价值因为你会逐渐理解每个技能对 AI 行为的具体影响。5.4 我的最终配置参考最后分享一份我目前实际在用的配置给想直接抄作业的朋友参考。~/.claude/CLAUDE.md开头部分的要点是- 在开始任何编码任务前先确认需求是否清晰不清晰则列出问题并等待确认。 - 遵循测试驱动开发先写失败测试再写实现最后重构。 - 大任务必须先输出执行计划得到确认后再动手。 - 每次任务结束后必须实际运行验证命令并报告结果不允许未经验证声称完成。 - 主动了解项目结构和运行方式而不是假设。~/.claude/skills/目录下的技能保持精简只留我前面说的那五个。实际使用中这套配置让 Claude Code 的输出稳定性明显提升至少不会再出现没跑测试就说完成的情况。如果你也准备试我的建议是别一次全装。先开 TDD Guard、Ask for a Plan、Verify Completion 这三个跑一周观察它对工作流的影响再决定要不要加其他技能。把 superpowers 当成一套可以随时裁剪的工具箱而不是一个必须全量拥抱的框架你会发现它其实只是把那些你已经知道应该做、但总是忘记做的工作习惯一件件地补了回来。
