1. 为什么你的 Claude Code 需要 Superpowers如果你用过 Claude Code大概率经历过这个场景一句“帮我实现一个登录功能”几秒钟后几百行代码铺满屏幕看起来挺像回事但仔细一读——没有需求确认、没有测试、没有任务拆分、没有 Code Review。稍微复杂一点的需求改着改着就乱了最后你自己都不知道哪一版是对的。这不是模型能力的问题而是缺少工程约束。Claude Code 本身像一个写代码很快的实习生你给什么它就写什么不会主动问你边界在哪、异常怎么处理、测试覆盖了没有。Superpowers 就是来解决这件事的它是一个运行在 Claude Code 里的插件本质是一套 Skills 框架强制 Claude 在动手写代码之前先想清楚、先规划、先写测试再去实现和审查。这篇文章聚焦的是 Superpowers 里最核心的一条链路——用 Skills 框架把 TDD测试驱动开发真正落地。我会给出可复制的settings.json骨架、Skills 目录结构以及一次完整的 TDD 循环验证动作。适合已经装了 Claude Code、想让 AI 按工程规范写代码的开发者。下面所有配置都基于我实际跑通的版本你可以直接抄。2. 前置准备TaoToken 接入与 Claude Code 环境在配置 Superpowers 之前得先保证 Claude Code 能正常调用模型。我这边用的是 TaoToken 的接入方式它兼容 Anthropic 的接口协议配置起来比较直接。首先去控制台拿一个 API Key。打开 https://taotoken.net/api-keys 创建一个新 Key复制出来备用。注意这个 Key 只在创建时完整显示一次丢了就得重建。然后确认你的 Claude Code 版本。Superpowers 依赖较新的插件系统建议先升级claude --version # 如果低于 1.x执行升级 npm install -g anthropic-ai/claude-code接着配置环境变量让 Claude Code 走 TaoToken 的接口。在~/.claude/settings.json里写入基础配置如果文件不存在就新建{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥 } }这里有个坑要注意ANTHROPIC_BASE_URL填的是https://taotoken.net/api不要自己加/v1后缀Claude Code 内部会拼接路径。我第一次配的时候多加了/v1结果一直报 404排查了半天。配完之后验证一下连通性claude -p 回复 ok如果返回ok说明模型通道没问题。这一步是整个 Superpowers 能跑起来的地基地基不稳后面全是白搭。关于接入的更多细节可以看官方文档 https://taotoken.net/doc 。3. 安装 Superpowers 与 Skills 目录结构环境通了之后装 Superpowers。它通过插件市场分发在 Claude Code 交互模式里执行# 注册市场源 /plugin marketplace add obra/superpowers-marketplace # 安装插件 /plugin install superpowerssuperpowers-marketplace # 验证安装结果 /plugin list/plugin list里能看到superpowers就说明装好了。如果拉取超时可以去 GitHub 把obra/superpowers-marketplace克隆到本地再用本地路径添加市场源效果一样。装完之后Skills 会被放到插件目录下。理解目录结构对后面排查问题很关键典型布局是这样的~/.claude/plugins/superpowers/ ├── skills/ │ ├── using-superpowers/ # 元技能会话启动时自动加载 │ ├── brainstorming/ # 需求澄清 │ ├── writing-plans/ # 计划拆解 │ ├── executing-plans/ # 计划执行调度 │ ├── test-driven-development/ # TDD 强制流程 │ ├── systematic-debugging/ # 系统化调试 │ └── verification-before-completion/ ├── commands/ # 斜杠命令定义 └── plugin.json # 插件元信息每个 skill 目录里通常有一个SKILL.md描述这个技能的触发条件和行为约束。using-superpowers是总开关它在每次会话启动时自动加载要求 Claude 在响应前先检查有没有适用的技能。这就是为什么你不需要手动记命令——描述任务时框架会自动匹配。如果你想在项目级别覆盖某些行为可以在项目根目录建.claude/settings.json它会和全局配置合并。比如强制某个项目始终走 TDD{ superpowers: { autoSkills: [test-driven-development, verification-before-completion] } }4. 可复制的 settings.json 骨架与 TDD 配置Superpowers 的很多行为可以通过settings.json调。下面这份骨架是我在项目里实际用的你可以按需删减{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥 }, permissions: { allow: [ Bash(npm test:*), Bash(pytest:*), Bash(git status), Bash(git diff:*) ] }, superpowers: { enabled: true, autoSkills: [ using-superpowers, test-driven-development, verification-before-completion ], tdd: { requireFailingTest: true, minimalImplementation: true, verifyWithFreshRun: true } } }几个参数值得单独说。requireFailingTest设为true时Claude 必须先写一个会失败的测试跑一遍确认它真的失败才能进入实现阶段。这是 TDD 的核心——如果测试一开始就通过说明它根本没测到东西。minimalImplementation要求只写让测试通过的最小代码避免 AI 顺手把一堆用不上的功能塞进来。verifyWithFreshRun则强制在声称完成前重新跑一次测试拿真实输出说话而不是“我觉得应该没问题”。permissions.allow里放的是测试和 git 相关命令这样 Claude 执行 TDD 循环时不会频繁弹权限确认流程更顺。注意别把rm、git push这类危险命令放进去。配置改完记得重启 Claude Code 会话让设置生效。5. 一次完整的 TDD 循环验证光配不跑等于没配。下面用一个具体例子走一遍实现一个isValidEmail函数。我在会话里直接说“用 TDD 流程实现一个邮箱校验函数”观察 Claude 的动作。第一步它会触发test-driven-development技能先写测试文件// email.test.js const { isValidEmail } require(./email); test(拒绝缺少 的字符串, () { expect(isValidEmail(abc.com)).toBe(false); }); test(接受标准邮箱格式, () { expect(isValidEmail(userexample.com)).toBe(true); });第二步运行测试确认失败npm test # 预期输出Cannot find module ./email # 或 isValidEmail is not a function这一步很关键。如果 Claude 跳过它直接写实现说明 TDD 技能没生效回去检查autoSkills配置。测试确实红了才进入下一步。第三步写最小实现// email.js function isValidEmail(input) { return /^[^\s][^\s]\.[^\s]$/.test(input); } module.exports { isValidEmail };第四步重新跑测试npm test # PASS ./email.test.js # Tests: 2 passed, 2 total看到绿色的2 passed一次 TDD 循环才算闭合。这时候verification-before-completion会介入要求 Claude 提供这次运行的完整输出作为证据而不是口头说“测试通过了”。整个过程中你可以随时用斜杠命令手动干预。比如需求还没想清楚先跑/superpowers:brainstorm把边界问明白计划太大用/superpowers:write-plan拆成精确到文件路径的微任务。正式项目建议走完brainstorming → writing-plans → executing-plans的完整链路TDD 只是执行阶段里的一环。6. 常见报错与排查清单配置过程中最容易踩的几个坑我整理成对照表现象可能原因处理方式404 或接口不通BASE_URL 多加了/v1改回https://taotoken.net/api技能不触发using-superpowers未加载检查autoSkills是否包含它重启会话测试没先失败就写实现requireFailingTest为 false在 settings 里设为 true插件安装超时市场源拉取失败克隆仓库到本地再添加市场源权限频繁弹窗测试命令不在 allow 列表把npm test、pytest加进permissions.allow声称完成但测试没过缺少 fresh run 验证开启verifyWithFreshRun还有一个隐蔽的问题如果你的项目用了 monorepo测试命令可能不是根目录的npm test而是子包的。这时候permissions.allow里的通配要写对比如Bash(npm test --workspace*)否则 Claude 跑测试会被拦下来TDD 循环就断了。排查思路其实就一条先确认模型通道通再确认技能加载了最后确认测试命令能跑。这三层任何一层出问题表现都是“Superpowers 好像没生效”但根因完全不同。7. 把 TDD 变成默认习惯Superpowers 最大的价值不是多写了多少代码而是把“先测试、再实现、后验证”这套流程变成了 Claude Code 的默认行为。你不需要每次提醒它写测试test-driven-development技能会在任何写代码的任务里自动触发你也不需要担心它虚报完成verification-before-completion会逼它拿出真实运行结果。如果你想让这套流程在团队里统一可以把项目级的.claude/settings.json提交到仓库这样每个成员拉下来就是同一套 TDD 约束。长期跑编码任务或者搭 Agent 工作流的话可以考虑 TaoToken 的 Coding Plan配合 Superpowers 的 Skills 框架把规划、执行、审查串成一条稳定的流水线。模型对话入口在 https://taotoken.net/models 接入文档在 https://taotoken.net/doc 需要的话直接去看。最后留一个实用技巧刚开始别急着开全部技能先只启用test-driven-development和verification-before-completion跑顺了再逐步加brainstorming和writing-plans。技能开太多Claude 会在流程判断上花掉不少 token反而拖慢简单任务。