1. 从“superpowers”说起一个让 AI 编程助手真正长出“技能树”的框架第一次看到 “superpowers” 这个词是在几个做 AI 编程工具链的朋友群里。有人甩了个链接配文是“这玩意儿终于让 Claude Code 不再只会瞎写代码了”。点进去一看核心思路其实很朴素给 AI 编程助手装上一套可插拔的agentic skills framework让它在面对具体开发任务时能像人类工程师一样调用对应的“技能包”而不是每次都从零开始瞎猜。说白了superpowers 是一套面向 AI 编程助手的技能框架与软件开发方法论。它本身不是一个独立的 IDE也不是某个模型而是一层“中间件”——架在 Claude Code、Codex CLI 这类命令行 AI 助手之上把常见的开发动作写测试、做代码审查、生成文档、重构、调试、提交规范等封装成一个个独立的 skillAI 在需要的时候自动加载、按需调用。你可以把它理解成给 AI 助手装了一本“操作手册 工具箱”它不再是那个只会说“好的我来帮你写”的愣头青而是知道“这个场景该用哪个工具、按什么流程走”的老手。这套东西解决的核心痛点很明确AI 编程助手的能力上限往往不取决于模型本身而取决于你给它喂了什么上下文、约束和流程。裸用 Claude Code 或者 Codex CLI你会发现它写小脚本还行一旦涉及多文件重构、测试驱动开发、代码规范审查就开始“自由发挥”——生成的代码风格飘忽、测试覆盖不全、提交信息乱七八糟。superpowers 的价值就在于它把这些“工程纪律”固化成了可复用的技能模块让 AI 的输出稳定在一个可预期的水平线上。这篇文章适合谁看如果你是刚接触 Claude Code、Codex CLI 的新手想搞清楚这套技能框架到底怎么引入、怎么用或者你已经用了一段时间但总觉得 AI 助手“不够听话”想通过 skills 机制把工作流标准化再或者你是团队里负责搭建 AI 辅助开发规范的人需要一套可落地的方案——那这篇内容应该能帮你省下不少自己摸索的时间。我会从整体设计思路讲起然后拆解核心技能、实操引入步骤、常见坑最后给一份可以直接抄的配置清单。2. 整体设计思路为什么是“技能框架”而不是“提示词大全”2.1 从“提示词工程”到“技能工程”的转变早两年大家玩 AI 编程主流思路是攒提示词。什么“你是一个资深 Python 工程师”“请遵循 PEP8 规范”“写完后请自测”——这些提示词确实有用但问题在于它们是扁平的、一次性的、不可组合的。你每次开一个新会话都得重新贴一遍任务一复杂提示词就膨胀到几千字模型反而抓不住重点。superpowers 的思路完全不同。它把“提示词”升级成了“技能”——每个 skill 是一个独立的结构化单元包含触发条件、执行步骤、约束规则、输出格式。AI 助手在运行时会根据当前任务上下文动态决定加载哪些 skill。这就像从“背单词”进化到了“学语法”单词是散的语法是能组合的。我实测下来这种设计最大的好处是上下文利用率高。裸用 Claude Code 时你贴一大堆规范它可能只记住前几条而 skill 是按需加载的当前任务只加载相关的那几个模型注意力集中输出质量明显更稳。2.2 核心架构Skill 是怎么被组织和调用的从公开的资料和实际使用体验来看superpowers 的技能框架大致分三层Skill 定义层每个 skill 是一个独立的描述文件通常是 Markdown 或 YAML 格式里面写清楚这个技能叫什么、什么时候触发、执行步骤是什么、有哪些约束。比如一个“写单元测试”的 skill会规定测试框架选型、命名规范、断言风格、覆盖率要求。路由与加载层AI 助手在接到任务后先做意图识别判断当前任务需要哪些 skill然后把这些 skill 的内容注入到上下文里。这一步是关键决定了 AI 是“精准调用”还是“乱加载一堆”。执行与反馈层AI 按 skill 定义的流程执行执行过程中如果遇到 skill 里预设的检查点比如“测试必须全绿才能提交”会停下来确认或自动修正。这套架构的好处是可扩展。你团队有自己的代码规范写一个 skill 就行。你项目有特殊的部署流程再写一个 skill。所有 skill 都是纯文本版本可控、可 review、可继承。2.3 为什么选 Claude Code 和 Codex CLI 作为主要载体热词里反复出现 Claude Code 和 Codex CLI这不是偶然。这两个工具是目前命令行 AI 编程助手里扩展性最好、社区最活跃的。Claude Code 支持通过配置文件加载自定义指令和技能Codex CLI 则有比较清晰的命令体系和插件机制。superpowers 选择它们作为主要载体本质上是借了这两个工具的“壳”把自己的技能框架塞进去。对比一下就更清楚维度裸用 Claude Code接入 superpowers 后任务理解依赖单次提示词按 skill 路由意图识别更准代码规范靠模型自觉skill 强制约束输出稳定多步任务容易跑偏skill 定义流程步步为营团队协作每人提示词不同skill 统一输出一致可维护性提示词散落各处skill 集中管理版本可控这个对比不是贬低裸用而是说当你只是偶尔写个小脚本裸用完全够但当你把 AI 助手当成日常开发的主力工具技能框架就是刚需。3. 核心技能拆解superpowers 里到底有哪些 skills3.1 开发流程类技能从需求到提交的完整闭环这类 skill 是 superpowers 的骨架覆盖了软件开发的几个关键节点。我按实际使用频率排个序需求拆解 skill接到一个模糊需求时AI 会先把它拆成可执行的任务列表每个任务标注输入、输出、验收标准。这个 skill 的触发条件通常是“用户描述了一个功能需求但没给具体实现步骤”。测试先行 skill强制 AI 在写实现之前先写测试。这个 skill 里会规定测试框架比如 Python 用 pytest、JS 用 vitest、测试文件命名、断言风格。实测下来这个 skill 对输出质量的提升最明显——AI 有了测试作为“靶子”写实现时不容易跑偏。代码审查 skillAI 写完代码后自动触发一轮自审检查命名、复杂度、重复代码、边界条件。这个 skill 会输出一个审查报告列出问题和修改建议。提交规范 skill生成符合 Conventional Commits 规范的提交信息并且强制要求“一个提交只做一件事”。这几个 skill 串起来就是一个完整的“需求→测试→实现→审查→提交”闭环。你不需要每次手动提醒 AI“先写测试”“记得审查”skill 会自动按流程走。3.2 代码质量类技能让 AI 输出像老手写的代码质量类 skill 解决的是“AI 写的代码能跑但不好看”的问题。常见的包括命名规范 skill规定变量、函数、类的命名风格禁止data1、temp、foo这类无意义命名。错误处理 skill强制 AI 在关键路径上加错误处理和日志而不是裸奔try/except或者干脆不处理。重构 skill当检测到函数超过一定行数、嵌套超过一定层数时自动触发重构建议。文档生成 skill为公开函数和类生成 docstring格式统一比如 Google Style 或 NumPy Style。这些 skill 的价值在于把“隐性经验”显性化。老手写代码时脑子里有一堆默认规则新手没有AI 默认也没有。skill 就是把这些规则写下来让 AI 照着做。3.3 工具集成类技能和终端、Git、CI 打通superpowers 不只是管代码内容还管代码周边的操作。这类 skill 包括终端命令执行 skill让 AI 能安全地执行终端命令比如跑测试、装依赖、查 Git 状态。关键是“安全”——skill 里会定义哪些命令可以自动执行哪些需要用户确认。Git 操作 skill自动处理分支创建、暂存、提交、推送。我实测下来这个 skill 配合提交规范 skill 用能省掉大量手动敲 Git 命令的时间。CI 检查 skill在提交前模拟 CI 流程跑 lint、测试、类型检查全绿才允许提交。这里有个细节值得说终端命令执行 skill 通常会配一个“白名单 黑名单”机制。白名单里的命令如pytest、npm test可以直接跑黑名单里的如rm -rf、git push --force必须用户确认。这个设计很务实既提效又防呆。3.4 技能的组合与优先级什么时候加载什么skill 不是越多越好。加载太多上下文被占满模型反而变笨。superpowers 的做法是按任务类型路由任务类型加载的 skill 组合新功能开发需求拆解 测试先行 命名规范 提交规范Bug 修复错误处理 测试先行 代码审查重构重构 代码审查 测试先行文档编写文档生成 命名规范日常提交提交规范 CI 检查这个路由表不是死的你可以根据自己的项目调整。核心原则是当前任务只加载相关 skill避免上下文污染。4. 实操引入从零把 superpowers 跑起来4.1 前置准备Claude Code 和 Codex CLI 的安装在引入 superpowers 之前得先把载体装好。这里分两条线讲。Claude Code 安装以 macOS 和 Ubuntu 为例# macOS 通过 npm 安装 npm install -g anthropic-ai/claude-code # Ubuntu 同样 sudo npm install -g anthropic-ai/claude-code # 验证安装 claude --versionWindows 用户注意Claude Code 对 Windows 的支持一直有点磕绊热词里也出现了“由于与64位版本的windows不兼容”这类问题。我的建议是在 Windows 上用 WSL2装 Ubuntu 子系统然后在子系统里按 Ubuntu 的方式装。这样最稳省得跟兼容性较劲。Codex CLI 安装# 通过 npm 安装 npm install -g openai/codex # 或者用 brewmacOS brew install codex # 验证 codex --version装完之后第一次运行需要配置 API Key 或者登录账号。这一步按官方提示走就行不复杂。4.2 引入 superpowers 技能包三种方式引入方式取决于你用哪个载体以及你想要多细的控制粒度。方式一通过配置文件加载推荐Claude Code 支持在项目根目录放一个配置文件比如.claude/settings.json或类似的在里面声明要加载的 skill 目录。superpowers 的技能包通常是一个文件夹里面每个 skill 一个 Markdown 文件。你只需要在配置里指向这个文件夹{ skills: { enabled: true, paths: [./superpowers-skills] } }这种方式的好处是项目级隔离——不同项目可以加载不同的 skill 组合互不干扰。方式二通过命令行参数临时加载如果你只是想试一下可以在启动 Claude Code 时指定 skill 路径claude --skills ./superpowers-skills这种方式适合快速验证但不适合长期用因为每次都要敲。方式三全局安装到用户目录把 skill 包放到用户目录下的全局配置文件夹里所有项目共享。适合个人开发者团队协作还是推荐方式一。提示不管用哪种方式引入后先用一个简单任务测试一下确认 skill 真的被加载了。可以问 AI“你现在加载了哪些 skill”看它能不能列出来。4.3 验证技能是否生效一个最小测试用例引入之后别急着上大项目先做个小测试。我常用的测试任务是“写一个函数判断一个字符串是不是回文要求先写测试。”如果 skill 生效了AI 应该会先创建一个测试文件写几个测试用例包括空字符串、单字符、正常回文、非回文然后写实现跑测试输出符合规范的提交信息。如果 AI 直接上来就写实现说明 skill 没加载成功回去检查配置路径。4.4 和 VS Code 的配合在编辑器里用起来很多人习惯在 VS Code 里写代码然后切终端跑 Claude Code。其实可以更顺滑VS Code 有 Claude Code 的插件装完之后可以在编辑器内直接调用。配置方式是在 VS Code 的 settings.json 里加上{ claudeCode.enabled: true, claudeCode.skillsPath: ./superpowers-skills }这样你在编辑器里选中一段代码右键就能让 AI 按 skill 规范处理不用来回切窗口。5. 常见问题与排查踩过的坑都在这儿了5.1 安装与配置类问题问题一Claude Code 提示“your organization has disabled claude subscription access”这个通常出现在用组织账号登录时。解决办法是换个人账号或者让管理员在组织设置里开放权限。如果是自己玩直接用个人账号最省事。问题二Windows 上装不上提示 64 位不兼容前面说了上 WSL2。具体步骤管理员权限打开 PowerShell跑wsl --install重启然后进 Ubuntu 子系统装 Node 和 Claude Code。实测这条路最稳。问题三skill 加载了但 AI 不按 skill 走先确认 skill 文件格式对不对——Markdown 的标题层级、触发条件描述是否清晰。其次看是不是加载了太多 skill上下文被占满。最后有些 skill 需要显式触发你可以在提示词里加一句“请按测试先行 skill 执行”。5.2 使用过程中的典型故障问题四AI 执行终端命令时报 internetopenurl() failed这个错误通常和网络环境有关但具体原因得看上下文。先检查命令本身是否需要联网如果不需要可能是 AI 误判了。可以在 skill 里明确哪些命令不需要网络。问题五AI 跑测试跑一半卡住大概率是测试里有需要交互的输入或者死循环。skill 里应该加一条“测试必须是非交互的超时时间设为 30 秒”。问题六提交信息不符合规范检查提交规范 skill 是否加载以及 skill 里的格式定义是否和你的 Git hook 冲突。有时候 pre-commit hook 会拦截导致 AI 生成的提交信息被改。5.3 技能冲突与优先级调整多个 skill 同时触发时可能打架。比如“重构 skill”让你拆函数“命名规范 skill”又要求保持接口稳定。解决办法是在 skill 定义里加优先级字段或者在项目配置里指定覆盖顺序。我的经验是流程类 skill 优先级高于风格类 skill因为流程错了风格再好也白搭。5.4 性能与上下文占用的平衡skill 加载多了token 消耗快响应也慢。建议每个项目只加载当前需要的 skill别一股脑全上定期清理不用的 skill把长 skill 拆成短 skill按需组合。6. 进阶玩法把 superpowers 用出花来6.1 自定义 skill写一个属于你团队的规范superpowers 最大的价值在于可扩展。你完全可以写自己的 skill。一个 skill 文件大概长这样# Skill: 数据库迁移规范 ## 触发条件 当任务涉及数据库 schema 变更时触发。 ## 执行步骤 1. 生成迁移文件命名格式为 YYYYMMDD_description.sql 2. 迁移文件必须包含 up 和 down 两个方向 3. 在测试环境先跑一遍 up再跑 down确认可逆 4. 更新 schema 文档 ## 约束 - 禁止在迁移里做数据删除操作 - 大表变更必须分批执行写完放到 skill 目录配置里加载就生效了。团队里谁用 AI 助手都按这个规范走输出自然统一。6.2 和本地模型配合用 LM Studio 跑离线 skill热词里有人问“claude code 调用 lmstudio 的本地模型”。思路是Claude Code 本身是客户端模型可以换。如果你有 LM Studio 跑本地模型可以通过配置把 Claude Code 的后端指向本地 API。这样 skill 框架照用但推理在本地适合对数据敏感的场景。配置方式是在环境变量里设置 API base URL 指向 LM Studio 的本地端口。6.3 团队协作把 skill 纳入版本管理skill 文件是纯文本天然适合 Git 管理。建议单独开一个 repo 放团队 skill每个项目通过 submodule 或者配置引用。这样 skill 的变更可追溯、可 review新人入职直接拉下来就能用。6.4 和 CI/CD 打通提交前自动跑 skill 检查可以在 Git pre-push hook 里调用 Claude Code让它按 skill 规范做一轮检查全绿才允许推送。这样 skill 不只是“建议”而是“强制”。实测下来这个做法能挡掉不少低级问题。7. 我个人的一些使用体会用 superpowers 这套东西大概几个月了最大的感受是它把 AI 编程助手从“玩具”变成了“工具”。裸用的时候你得时刻盯着生怕它跑偏接入 skill 框架后大部分常规任务可以放心交给它你只需要在关键节点做决策。几个我觉得特别值的点测试先行 skill 让代码质量肉眼可见地提升提交规范 skill 省掉了大量整理 commit 的时间终端命令执行 skill 的白名单机制让我敢让它跑命令了。不太值的点也有skill 写多了确实占上下文得定期清理有些 skill 的触发条件写得太宽泛导致误触发需要反复调。如果让我给新手一个建议别一上来就搞一大堆 skill先从两三个核心的测试先行、提交规范开始用顺了再慢慢加。skill 框架的价值在于“稳定”而稳定来自于“少而精”不是“多而全”。最后分享一个小技巧定期让 AI 自己 review 一遍当前加载的 skill问它“哪些 skill 这次任务没用上、哪些可以合并”它会给出挺靠谱的优化建议。这个习惯帮我砍掉了将近一半的冗余 skill。