最近在折腾给 Codex CLI 加技能包的事发现一个叫superpowers的开源项目在开发者圈子里传得很快。它解决的是一个很具体的问题AI 编程助手越来越强但经常“有劲没处使”——你让它改个 bug它不先定位根因就上手你让它加个功能它不写测试就开搞。superpowers 就是给这类终端 AI 助手装上的一套“工作方法”技能包核心思路是让 AI 在动手前先学会规划、在实现前先写测试、在修 bug 前先复现。这篇文章写给三类人一是刚开始用 Codex CLI、觉得生成质量不稳定的朋友二是已经在用 WorkBuddy、Trae 这类支持 skill 机制的开发工具、想统一管理 AI 工作流的人三是单纯好奇“技能包到底怎么改变 AI 行为”的爱好者。我会把 superpowers 的构成、skill 的加载原理、在不同工具里的安装方式以及实测下来哪些技能最实用、哪些坑别踩一次讲完。1. superpowers 的本质先给 AI 立规矩再让它干活1.1 为什么叫“超能力”先明确一个概念superpowers 不是一个新的 AI 模型也不是 Codex CLI 的插件它是一套结构化的技能文件集合来自开源社区作者是 Perl 圈的老熟人 Jesse Vincent。这个项目最早是给 Claude Code 用的后来因为 Codex CLI 等终端助手开始支持同类 skill 机制就顺势扩展成了多工具通用的技能包。它的命名很直白——把这些技能装进 AI 助手之后助手就像获得了“超能力”。但这些能力不是让模型变聪明而是约束模型的行为方式。普通情况下你让 AI“帮我修这个 bug”它会直接开干装上技能包之后它会先按技能文件里的流程走复现问题、读日志、缩小范围、提出假设、验证假设、改代码、写回归测试。整个过程像有个资深工程师在旁边盯着它按套路出牌。这个思路和“提示词工程”最大的区别在于提示词是临时的、碎片化的而技能是持久化、可复用、带触发条件的。你不需要每次对话都重复“请先写测试再写实现”技能文件会自动在合适的时机插入对应的工作流指令。1.2 技能文件的结构superpowers 仓库里每个技能都是一个独立目录核心文件是SKILL.md里面用 Markdown 写了技能的元信息和具体执行步骤。典型结构长这样skills/ ├── brainstorming/ │ ├── SKILL.md │ └── references/ │ └── ideation-techniques.md ├── test-driven-development/ │ ├── SKILL.md │ └── references/ │ └── tdd-workflow.md ├── systematic-debugging/ │ ├── SKILL.md │ └── references/ │ └── debugging-checklist.md └── writing-plans/ ├── SKILL.md └── references/ └── plan-template.mdSKILL.md的开头通常有一段 YAML 格式的元数据描述这个技能的名称、适合什么场景、大概的触发关键词后面就是正文指令。AI 在对话过程中读到这些元数据判断当前任务是否匹配某个技能匹配就自动加载对应的完整指令。这个设计的好处是技能可以独立演进。你觉得某个技能写得不好直接改对应的 Markdown 文件社区有人分享了更好的技能复制进目录就能用。不需要改代码、不需要重装插件、不需要动模型配置。2. skill 机制在不同工具里的加载逻辑既然要装技能就得先搞明白目标工具到底怎么识别和加载技能。这一块很多教程一句话带过但实际踩坑往往都出在这里。2.1 Codex CLI 的 skills 目录Codex CLI 是 OpenAI 出的终端编程助手天然支持 skill 机制。它会在你的用户目录下维护一个~/.codex/配置文件夹技能放在~/.codex/skills/目录里每个技能一个子目录和前面说的结构一致。Codex CLI 加载技能的逻辑是在对话开始时扫描技能目录把每个SKILL.md的元数据和摘要读进上下文然后在对话过程中根据用户请求动态匹配。这意味着技能的描述写得清不清楚直接决定它会不会被触发。你可以把SKILL.md开头的描述当成“广告位”写清楚“这个技能解决什么问题、适合什么任务”AI 才知道什么时候该用。2.2 WorkBuddy 的 skill 接入WorkBuddy 是 Rails 社区很活跃的 AI 编程工具走的是和 Codex CLI 类似的路子。它支持通过命令行工具安装外部 skill内置了类似workbuddy skill add之类的管理命令。我在它的文档里看到它会把技能装进项目内部的.workbuddy/skills/目录这样同一个技能可以跟着项目走团队协作时所有成员拿到同一套技能配置。这种“项目级技能目录”和 Codex CLI 的“用户级技能目录”有个重要区别用户级技能对所有项目生效项目级技能只对当前仓库生效。实际使用中我建议通用技能放用户级项目特有技能放项目级。比如 TDD、调试这类通用技能放用户级而“这个项目必须用 pytest mock 的特定写法”这种约束放项目级更合理。2.3 Trae CN 的技能配置Trae CN 是字节跳动的 AI IDE也跟进了 skill 机制。它通常是在 IDE 的设置面板里配置自定义技能或者在项目根目录放.trae/skills/目录。和 Codex CLI、WorkBuddy 不一样的是Trae 作为完整 IDE技能不仅影响对话补全还会影响编辑器里的内联操作加载时机更复杂。我的经验是在 Trae 里装技能最好先确认版本支持 skills然后在设置里打开“自定义技能”开关把技能目录指过去。Trae CN 的文档更新比较勤安装前建议先看一眼当前版本的官方说明因为不同小版本之间技能加载逻辑可能有差异。3. Codex CLI 安装 superpowers 的完整流程这一节是全文最“抄作业”的部分。我用 Codex CLI 为例从零开始完整走一遍。3.1 准备环境安装之前先确认两件事。第一Codex CLI 版本不能太老我建议至少是0.x的较新版本因为旧版本对 skills 的支持不完整。第二确认你的终端能正常跑 Codex CLI 的命令即codex --version能输出版本号。codex --version mkdir -p ~/.codex/skills第二行命令先建好技能目录后面会用到。3.2 克隆仓库并链接技能从 GitHub 克隆 superpowers 仓库到本地任意位置然后把仓库里的skills目录里的技能软链到~/.codex/skills/。我习惯用软链而不是直接复制这样之后git pull拉取最新版就能自动更新技能不用重复复制。cd ~/Projects git clone https://github.com/obra/superpowers.git cd superpowers # 把仓库里的 skills 目录下的所有技能软链到 Codex CLI 的技能目录 for skill_dir in skills/*/; do skill_name$(basename $skill_dir) ln -sfn $(pwd)/$skill_dir $HOME/.codex/skills/$skill_name done执行完可以用ls -la ~/.codex/skills/确认软链是否创建成功。如果只想装其中某几个技能就不要用循环直接软链单个目录比如ln -sfn ~/Projects/superpowers/skills/systematic-debugging ~/.codex/skills/systematic-debugging3.3 配置 AGENTS.md 让 AI 感知技能技能目录创建好了还要让 Codex CLI 知道“你有这些技能可以用”。这一步是关键。在项目根目录或者用户目录下创建AGENTS.md文件里面告诉 AI 技能的存放位置和使用原则。我通常写在用户级也就是~/.codex/AGENTS.md让所有项目都生效# Skills 本环境包含一组可用的技能包位于 ~/.codex/skills/ 目录。 当任务匹配某个技能时请先读取对应的 SKILL.md 并严格遵循其中的步骤。 常用技能包括 - test-driven-development编写新功能时使用先写测试再写实现。 - systematic-debugging排查 bug 时使用按系统化流程定位根因。 - writing-plans复杂任务开始前使用先产出实施计划。 - brainstorming需求模糊时使用先梳理方案再动手。这里有个细节AGENTS.md本身就是 AI 的“贴身指南”Codex CLI 在每次会话启动时都会读到它。所以你不需要在每次对话里提“你有技能”它自己就知道。3.4 验证安装是否生效验证分两步。第一步进入 Codex CLI 交互界面输入一个和某个技能强相关的指令比如“我需要重构这个模块但我对方案不确定”看它是否会自动触发brainstorming技能输出方案而不是直接改代码。第二步直接输入“你有哪些技能可用”看它能否列出~/.codex/skills/里的技能清单。如果它完全没反应大概率是技能描述写得太含糊AI 判断当前任务不匹配或者AGENTS.md路径不对。我建议在AGENTS.md里把技能描述写得直白一点AI 是读字面意思的别让它猜。4. WorkBuddy 与 Trae CN 安装的差异点Codex CLI 的流程走通之后WorkBuddy 和 Trae CN 就相对简单了因为它们的设计逻辑相似只是命令和目录位置不同。4.1 WorkBuddy 安装步骤WorkBuddy 官方提供了安装外部 skill 的命令。根据社区里流传最多的用法装 superpowers 的方式是workbuddy skill add superpowers这条命令会从 GitHub 拉取 superpowers 仓库并安装到当前项目或用户目录。如果你的网络环境拉取 GitHub 不稳定也可以手动克隆后复制到.workbuddy/skills/目录效果一样。装完之后在WorkBuddy会话里测试一下 TDD 技能是否被触发。WorkBuddy 的日志输出比 Codex CLI 详细如果技能没加载日志里通常能看到原因这点比 Codex CLI 友好。4.2 Trae CN 安装步骤Trae CN 走的是 IDE 设置路线。打开设置面板找到“技能/Skills”相关选项开启自定义技能然后把superpowers/skills/目录添加进去。如果你用的是项目级配置也可以把技能目录复制到项目根目录的.trae/skills/。Trae 有个特殊点它对SKILL.md的解析比较严格YAML 元数据里的字段如果格式不对整个技能会被忽略。所以从仓库直接复制的技能一般没问题但你自己改过元数据的技能要特别留意格式建议用在线 YAML 校验工具检查一遍再放进去。此外Trae CN 里不同的模型对技能的遵循程度有差别。本地小模型和云端的旗舰模型在“是否严格执行技能步骤”这件事上表现差异很大实测下来大模型执行得更稳定。如果你发现技能装了但 AI 不听话先检查是不是模型选得太小。5. 核心 skill 逐个拆解规划、TDD、调试到底能干什么装了技能包之后最关心的就是里面到底有哪些技能、每个技能怎么影响 AI 的行为。我把最常用的几个拆开讲。5.1 brainstorming 与 writing-plans让 AI 先想清楚再做这两个技能解决的是同一个病AI 太着急。你给 Codex CLI 一个需求它恨不得马上输出代码。brainstorming会在需求模糊时强制 AI 先提出多种方案、列出权衡、让你确认后再往下走writing-plans则是把大任务拆成有依赖关系的步骤并输出一份带验收条件的执行计划。我实际用下来的体会是这俩技能搭配使用效果最好。需求模糊时先brainstorming梳理方向方向定了再writing-plans产出步骤。步骤拆得越细后面执行越不会跑偏。这就像写代码之前先画架构图看着多了一步实际上省了返工的时间。5.2 test-driven-development先写测试再写实现TDD 技能是 superpowers 里最有“性格”的一个。它要求 AI 在写任何功能代码之前先写一个会失败的测试然后运行测试确认失败再写最小实现让测试通过最后重构。这个流程听起来简单但普通对话里 AI 几乎不会主动这么做。装上之后你只要说“用 TDD 实现这个函数”它就自动进入“红灯-绿灯-重构”的循环。测试文件写在哪个目录、用什么测试框架、怎么运行单个测试这些它都会从项目上下文里推断不需要你额外交代。这个技能对测试基础设施比较完善的项目帮助最大如果项目本身没有测试环境技能会先引导你搭建基础测试框架这本身也是好事。5.3 systematic-debugging按流程找根因不瞎改代码systematic-debugging是我个人最喜欢的技能。它的核心是让 AI 遵循一套排错流程先复现问题再收集信息然后提出假设用实验验证假设找到根因后修改最后写回归测试。整个过程会要求 AI 输出“当前假设”和“验证结果”而不是闷头改一行代码就说修好了。这个技能在真实项目里特别有用。普通的 AI 调试方式经常是“猜一个原因、改一下、跑一遍、不行再猜”有时候碰巧改对了但不知道为什么。系统化调试让 AI 把每一步推理都摆在明面上你一眼就能看出它在往哪个方向排查就算最后没解决你也能基于它的排查过程给出下一步指引。5.4 其他值得关注的技能仓库里还有其他技能比如code-review让 AI 按审查清单检查代码、commit-message-writing根据 diff 生成符合规范的提交信息、writing-prd把需求整理成产品需求文档等。这些技能触发频率不如前三个高但特定场景下很省事。比如code-review对刚写完的大改动做一轮系统检查能发现不少潜在的边界问题。我自己习惯在合入代码前用这个技能让 AI 以“挑剔的审查者”身份过一遍改动效果比让 AI 直接“帮我检查代码”好很多因为它会按清单逐项检查而不是泛泛地夸你代码写得不错。6. 实测体验哪些场景提升最明显哪些坑要躲6.1 提升最明显的三个场景第一新功能开发。以前让 Codex CLI 直接写一个新模块经常写到一半发现方向不对重来成本很高。开启writing-planstest-driven-development之后它会先给方案、再按测试驱动的方式推进虽然生成的代码速度感觉慢了但一次通过的几率高了很多。第二疑难 bug 排查。有一次遇到一个只在特定数据量下才出现的性能问题我自己排查了半天没头绪让 Codex CLI 用systematic-debugging技能分析它按流程列了五个假设逐个用采样数据验证最后定位到一条在数据量大时走错索引的查询。这个过程它全程输出推理步骤我很清楚地看到它是怎么排除其他假设的。第三代码审查。对于自己刚写完的大改动让 AI 用code-review技能过一遍能发现一些肉眼容易漏掉的边界情况和资源释放问题。它不像真人审查会有情面清单上列了什么就查什么。6.2 实际踩过的坑坑一技能描述被改坏导致触发失灵。我一开始觉得某个技能的描述写得不够“高级”自己改了几句结果反而导致 AI 识别不了触发条件那个技能彻底沉默了。后来我意识到技能描述不是给人类看的是给 AI 做语义匹配用的最好保持原样最多补充例子不要大幅删改。坑二多个技能同时触发导致指令冲突。有一次我让 AI“给这个接口加功能并保证不破坏现有逻辑”结果test-driven-development和code-review同时被触发AI 的行为变得很割裂一会儿在写测试一会儿在审查已有代码。解决办法是在指令里明确优先级比如“先用 TDD 写写完再 review”把技能的执行顺序说清楚。坑三项目级技能被提交进仓库造成团队困惑。WorkBuddy 和 Trae 的项目级技能目录如果不加.gitignore软链或复制的技能文件会被提交进仓库其他成员 pull 下来之后可能会激活他们本不想启用的技能。我的建议是技能目录加入.gitignore需要共享的技能单独放一个配置文件说明让大家各自安装。6.3 我的使用建议如果你刚开始接触我建议不要一次装全部技能先装test-driven-development和systematic-debugging这两个用一周感受变化再逐步增加。装多了之后 AI 在技能选择上会犹豫反而影响响应速度。另外superpowers 里技能的执行效果和底层模型能力有直接关系。能力强的模型能严格按技能步骤执行能力弱的模型可能会“跳步”比如 TDD 技能要求先跑测试确认失败但模型直接跳到了写实现。如果你发现技能流程没有被完整执行先换更强一点的模型试试往往比调试技能配置更有效。最后说一个更新习惯superpowers 仓库本身迭代很快我的做法是每周git pull一次看更新日志里有没有修复我踩过的坑。技能包这种东西社区维护者的实际经验比你自己摸索的要多得多跟着更新不会吃亏。
给 Codex CLI 装 superpowers：用技能包让 AI 先规划、再写码
最近在折腾给 Codex CLI 加技能包的事发现一个叫superpowers的开源项目在开发者圈子里传得很快。它解决的是一个很具体的问题AI 编程助手越来越强但经常“有劲没处使”——你让它改个 bug它不先定位根因就上手你让它加个功能它不写测试就开搞。superpowers 就是给这类终端 AI 助手装上的一套“工作方法”技能包核心思路是让 AI 在动手前先学会规划、在实现前先写测试、在修 bug 前先复现。这篇文章写给三类人一是刚开始用 Codex CLI、觉得生成质量不稳定的朋友二是已经在用 WorkBuddy、Trae 这类支持 skill 机制的开发工具、想统一管理 AI 工作流的人三是单纯好奇“技能包到底怎么改变 AI 行为”的爱好者。我会把 superpowers 的构成、skill 的加载原理、在不同工具里的安装方式以及实测下来哪些技能最实用、哪些坑别踩一次讲完。1. superpowers 的本质先给 AI 立规矩再让它干活1.1 为什么叫“超能力”先明确一个概念superpowers 不是一个新的 AI 模型也不是 Codex CLI 的插件它是一套结构化的技能文件集合来自开源社区作者是 Perl 圈的老熟人 Jesse Vincent。这个项目最早是给 Claude Code 用的后来因为 Codex CLI 等终端助手开始支持同类 skill 机制就顺势扩展成了多工具通用的技能包。它的命名很直白——把这些技能装进 AI 助手之后助手就像获得了“超能力”。但这些能力不是让模型变聪明而是约束模型的行为方式。普通情况下你让 AI“帮我修这个 bug”它会直接开干装上技能包之后它会先按技能文件里的流程走复现问题、读日志、缩小范围、提出假设、验证假设、改代码、写回归测试。整个过程像有个资深工程师在旁边盯着它按套路出牌。这个思路和“提示词工程”最大的区别在于提示词是临时的、碎片化的而技能是持久化、可复用、带触发条件的。你不需要每次对话都重复“请先写测试再写实现”技能文件会自动在合适的时机插入对应的工作流指令。1.2 技能文件的结构superpowers 仓库里每个技能都是一个独立目录核心文件是SKILL.md里面用 Markdown 写了技能的元信息和具体执行步骤。典型结构长这样skills/ ├── brainstorming/ │ ├── SKILL.md │ └── references/ │ └── ideation-techniques.md ├── test-driven-development/ │ ├── SKILL.md │ └── references/ │ └── tdd-workflow.md ├── systematic-debugging/ │ ├── SKILL.md │ └── references/ │ └── debugging-checklist.md └── writing-plans/ ├── SKILL.md └── references/ └── plan-template.mdSKILL.md的开头通常有一段 YAML 格式的元数据描述这个技能的名称、适合什么场景、大概的触发关键词后面就是正文指令。AI 在对话过程中读到这些元数据判断当前任务是否匹配某个技能匹配就自动加载对应的完整指令。这个设计的好处是技能可以独立演进。你觉得某个技能写得不好直接改对应的 Markdown 文件社区有人分享了更好的技能复制进目录就能用。不需要改代码、不需要重装插件、不需要动模型配置。2. skill 机制在不同工具里的加载逻辑既然要装技能就得先搞明白目标工具到底怎么识别和加载技能。这一块很多教程一句话带过但实际踩坑往往都出在这里。2.1 Codex CLI 的 skills 目录Codex CLI 是 OpenAI 出的终端编程助手天然支持 skill 机制。它会在你的用户目录下维护一个~/.codex/配置文件夹技能放在~/.codex/skills/目录里每个技能一个子目录和前面说的结构一致。Codex CLI 加载技能的逻辑是在对话开始时扫描技能目录把每个SKILL.md的元数据和摘要读进上下文然后在对话过程中根据用户请求动态匹配。这意味着技能的描述写得清不清楚直接决定它会不会被触发。你可以把SKILL.md开头的描述当成“广告位”写清楚“这个技能解决什么问题、适合什么任务”AI 才知道什么时候该用。2.2 WorkBuddy 的 skill 接入WorkBuddy 是 Rails 社区很活跃的 AI 编程工具走的是和 Codex CLI 类似的路子。它支持通过命令行工具安装外部 skill内置了类似workbuddy skill add之类的管理命令。我在它的文档里看到它会把技能装进项目内部的.workbuddy/skills/目录这样同一个技能可以跟着项目走团队协作时所有成员拿到同一套技能配置。这种“项目级技能目录”和 Codex CLI 的“用户级技能目录”有个重要区别用户级技能对所有项目生效项目级技能只对当前仓库生效。实际使用中我建议通用技能放用户级项目特有技能放项目级。比如 TDD、调试这类通用技能放用户级而“这个项目必须用 pytest mock 的特定写法”这种约束放项目级更合理。2.3 Trae CN 的技能配置Trae CN 是字节跳动的 AI IDE也跟进了 skill 机制。它通常是在 IDE 的设置面板里配置自定义技能或者在项目根目录放.trae/skills/目录。和 Codex CLI、WorkBuddy 不一样的是Trae 作为完整 IDE技能不仅影响对话补全还会影响编辑器里的内联操作加载时机更复杂。我的经验是在 Trae 里装技能最好先确认版本支持 skills然后在设置里打开“自定义技能”开关把技能目录指过去。Trae CN 的文档更新比较勤安装前建议先看一眼当前版本的官方说明因为不同小版本之间技能加载逻辑可能有差异。3. Codex CLI 安装 superpowers 的完整流程这一节是全文最“抄作业”的部分。我用 Codex CLI 为例从零开始完整走一遍。3.1 准备环境安装之前先确认两件事。第一Codex CLI 版本不能太老我建议至少是0.x的较新版本因为旧版本对 skills 的支持不完整。第二确认你的终端能正常跑 Codex CLI 的命令即codex --version能输出版本号。codex --version mkdir -p ~/.codex/skills第二行命令先建好技能目录后面会用到。3.2 克隆仓库并链接技能从 GitHub 克隆 superpowers 仓库到本地任意位置然后把仓库里的skills目录里的技能软链到~/.codex/skills/。我习惯用软链而不是直接复制这样之后git pull拉取最新版就能自动更新技能不用重复复制。cd ~/Projects git clone https://github.com/obra/superpowers.git cd superpowers # 把仓库里的 skills 目录下的所有技能软链到 Codex CLI 的技能目录 for skill_dir in skills/*/; do skill_name$(basename $skill_dir) ln -sfn $(pwd)/$skill_dir $HOME/.codex/skills/$skill_name done执行完可以用ls -la ~/.codex/skills/确认软链是否创建成功。如果只想装其中某几个技能就不要用循环直接软链单个目录比如ln -sfn ~/Projects/superpowers/skills/systematic-debugging ~/.codex/skills/systematic-debugging3.3 配置 AGENTS.md 让 AI 感知技能技能目录创建好了还要让 Codex CLI 知道“你有这些技能可以用”。这一步是关键。在项目根目录或者用户目录下创建AGENTS.md文件里面告诉 AI 技能的存放位置和使用原则。我通常写在用户级也就是~/.codex/AGENTS.md让所有项目都生效# Skills 本环境包含一组可用的技能包位于 ~/.codex/skills/ 目录。 当任务匹配某个技能时请先读取对应的 SKILL.md 并严格遵循其中的步骤。 常用技能包括 - test-driven-development编写新功能时使用先写测试再写实现。 - systematic-debugging排查 bug 时使用按系统化流程定位根因。 - writing-plans复杂任务开始前使用先产出实施计划。 - brainstorming需求模糊时使用先梳理方案再动手。这里有个细节AGENTS.md本身就是 AI 的“贴身指南”Codex CLI 在每次会话启动时都会读到它。所以你不需要在每次对话里提“你有技能”它自己就知道。3.4 验证安装是否生效验证分两步。第一步进入 Codex CLI 交互界面输入一个和某个技能强相关的指令比如“我需要重构这个模块但我对方案不确定”看它是否会自动触发brainstorming技能输出方案而不是直接改代码。第二步直接输入“你有哪些技能可用”看它能否列出~/.codex/skills/里的技能清单。如果它完全没反应大概率是技能描述写得太含糊AI 判断当前任务不匹配或者AGENTS.md路径不对。我建议在AGENTS.md里把技能描述写得直白一点AI 是读字面意思的别让它猜。4. WorkBuddy 与 Trae CN 安装的差异点Codex CLI 的流程走通之后WorkBuddy 和 Trae CN 就相对简单了因为它们的设计逻辑相似只是命令和目录位置不同。4.1 WorkBuddy 安装步骤WorkBuddy 官方提供了安装外部 skill 的命令。根据社区里流传最多的用法装 superpowers 的方式是workbuddy skill add superpowers这条命令会从 GitHub 拉取 superpowers 仓库并安装到当前项目或用户目录。如果你的网络环境拉取 GitHub 不稳定也可以手动克隆后复制到.workbuddy/skills/目录效果一样。装完之后在WorkBuddy会话里测试一下 TDD 技能是否被触发。WorkBuddy 的日志输出比 Codex CLI 详细如果技能没加载日志里通常能看到原因这点比 Codex CLI 友好。4.2 Trae CN 安装步骤Trae CN 走的是 IDE 设置路线。打开设置面板找到“技能/Skills”相关选项开启自定义技能然后把superpowers/skills/目录添加进去。如果你用的是项目级配置也可以把技能目录复制到项目根目录的.trae/skills/。Trae 有个特殊点它对SKILL.md的解析比较严格YAML 元数据里的字段如果格式不对整个技能会被忽略。所以从仓库直接复制的技能一般没问题但你自己改过元数据的技能要特别留意格式建议用在线 YAML 校验工具检查一遍再放进去。此外Trae CN 里不同的模型对技能的遵循程度有差别。本地小模型和云端的旗舰模型在“是否严格执行技能步骤”这件事上表现差异很大实测下来大模型执行得更稳定。如果你发现技能装了但 AI 不听话先检查是不是模型选得太小。5. 核心 skill 逐个拆解规划、TDD、调试到底能干什么装了技能包之后最关心的就是里面到底有哪些技能、每个技能怎么影响 AI 的行为。我把最常用的几个拆开讲。5.1 brainstorming 与 writing-plans让 AI 先想清楚再做这两个技能解决的是同一个病AI 太着急。你给 Codex CLI 一个需求它恨不得马上输出代码。brainstorming会在需求模糊时强制 AI 先提出多种方案、列出权衡、让你确认后再往下走writing-plans则是把大任务拆成有依赖关系的步骤并输出一份带验收条件的执行计划。我实际用下来的体会是这俩技能搭配使用效果最好。需求模糊时先brainstorming梳理方向方向定了再writing-plans产出步骤。步骤拆得越细后面执行越不会跑偏。这就像写代码之前先画架构图看着多了一步实际上省了返工的时间。5.2 test-driven-development先写测试再写实现TDD 技能是 superpowers 里最有“性格”的一个。它要求 AI 在写任何功能代码之前先写一个会失败的测试然后运行测试确认失败再写最小实现让测试通过最后重构。这个流程听起来简单但普通对话里 AI 几乎不会主动这么做。装上之后你只要说“用 TDD 实现这个函数”它就自动进入“红灯-绿灯-重构”的循环。测试文件写在哪个目录、用什么测试框架、怎么运行单个测试这些它都会从项目上下文里推断不需要你额外交代。这个技能对测试基础设施比较完善的项目帮助最大如果项目本身没有测试环境技能会先引导你搭建基础测试框架这本身也是好事。5.3 systematic-debugging按流程找根因不瞎改代码systematic-debugging是我个人最喜欢的技能。它的核心是让 AI 遵循一套排错流程先复现问题再收集信息然后提出假设用实验验证假设找到根因后修改最后写回归测试。整个过程会要求 AI 输出“当前假设”和“验证结果”而不是闷头改一行代码就说修好了。这个技能在真实项目里特别有用。普通的 AI 调试方式经常是“猜一个原因、改一下、跑一遍、不行再猜”有时候碰巧改对了但不知道为什么。系统化调试让 AI 把每一步推理都摆在明面上你一眼就能看出它在往哪个方向排查就算最后没解决你也能基于它的排查过程给出下一步指引。5.4 其他值得关注的技能仓库里还有其他技能比如code-review让 AI 按审查清单检查代码、commit-message-writing根据 diff 生成符合规范的提交信息、writing-prd把需求整理成产品需求文档等。这些技能触发频率不如前三个高但特定场景下很省事。比如code-review对刚写完的大改动做一轮系统检查能发现不少潜在的边界问题。我自己习惯在合入代码前用这个技能让 AI 以“挑剔的审查者”身份过一遍改动效果比让 AI 直接“帮我检查代码”好很多因为它会按清单逐项检查而不是泛泛地夸你代码写得不错。6. 实测体验哪些场景提升最明显哪些坑要躲6.1 提升最明显的三个场景第一新功能开发。以前让 Codex CLI 直接写一个新模块经常写到一半发现方向不对重来成本很高。开启writing-planstest-driven-development之后它会先给方案、再按测试驱动的方式推进虽然生成的代码速度感觉慢了但一次通过的几率高了很多。第二疑难 bug 排查。有一次遇到一个只在特定数据量下才出现的性能问题我自己排查了半天没头绪让 Codex CLI 用systematic-debugging技能分析它按流程列了五个假设逐个用采样数据验证最后定位到一条在数据量大时走错索引的查询。这个过程它全程输出推理步骤我很清楚地看到它是怎么排除其他假设的。第三代码审查。对于自己刚写完的大改动让 AI 用code-review技能过一遍能发现一些肉眼容易漏掉的边界情况和资源释放问题。它不像真人审查会有情面清单上列了什么就查什么。6.2 实际踩过的坑坑一技能描述被改坏导致触发失灵。我一开始觉得某个技能的描述写得不够“高级”自己改了几句结果反而导致 AI 识别不了触发条件那个技能彻底沉默了。后来我意识到技能描述不是给人类看的是给 AI 做语义匹配用的最好保持原样最多补充例子不要大幅删改。坑二多个技能同时触发导致指令冲突。有一次我让 AI“给这个接口加功能并保证不破坏现有逻辑”结果test-driven-development和code-review同时被触发AI 的行为变得很割裂一会儿在写测试一会儿在审查已有代码。解决办法是在指令里明确优先级比如“先用 TDD 写写完再 review”把技能的执行顺序说清楚。坑三项目级技能被提交进仓库造成团队困惑。WorkBuddy 和 Trae 的项目级技能目录如果不加.gitignore软链或复制的技能文件会被提交进仓库其他成员 pull 下来之后可能会激活他们本不想启用的技能。我的建议是技能目录加入.gitignore需要共享的技能单独放一个配置文件说明让大家各自安装。6.3 我的使用建议如果你刚开始接触我建议不要一次装全部技能先装test-driven-development和systematic-debugging这两个用一周感受变化再逐步增加。装多了之后 AI 在技能选择上会犹豫反而影响响应速度。另外superpowers 里技能的执行效果和底层模型能力有直接关系。能力强的模型能严格按技能步骤执行能力弱的模型可能会“跳步”比如 TDD 技能要求先跑测试确认失败但模型直接跳到了写实现。如果你发现技能流程没有被完整执行先换更强一点的模型试试往往比调试技能配置更有效。最后说一个更新习惯superpowers 仓库本身迭代很快我的做法是每周git pull一次看更新日志里有没有修复我踩过的坑。技能包这种东西社区维护者的实际经验比你自己摸索的要多得多跟着更新不会吃亏。
