2026 年开年我 GitHub 星标列表里一口气多了好几个 AI 编程工具链相关的项目Superpowers、Codex、Workbuddy 这几个名字反复出现。Superpowers 从 2024 年一路火到现在几乎成了 skill 体系的代名词而 Codex 和 Workbuddy 又是很多开发团队日常离不开的编码代理。但说句实在话我最近在自己项目里的真实感受恰恰相反把 Superpowers 装进 Codex 之后任务并没有变得更稳token 烧得更快方向偶尔还会跑偏。真正让我工作流重新变得顺手的是一个不到 10 行的 skill。如果你想复现我说的效果建议先把注意力从“哪个 skill 更全”转移到“哪个 skill 更能框住 agent 的行为”。这篇文章会把我为什么不再把 Superpowers 设为默认方案、那个 10 行 skill 的实际内容、以及切换过程中的实操细节一次讲清楚。无论你正在用 Codex、Workbuddy还是刚刚接触 skill 这个概念应该都能从中找到可以立刻试起来的东西。1. 先说结论全家桶式 Superpowers 在 2026 年为什么没那么香了1.1 它确实解决过一个真问题在 Claude Code 刚开放 skill 机制那阵大家最大的痛点并不是模型不够聪明而是模型不知道“什么时候该问、什么时候该做、做到哪一步算完”。Superpowers 的思路就是给模型套上一套显式工作流先头脑风暴再制定计划最后执行并测试。一套流程下来相当于把人类开发者写需求、拆任务、做 review 的节奏硬生生复制给了模型。这套设计在代码库复杂、目标模糊的场景下非常管用。我自己也正经用过很长一段时间的 brainstorming planning executing 三段式从零搭一个内部服务的时候它的阶段划分确实能逼着模型先想清楚再动手减少“接到一句话就闷头写”的冲动。社区里后来把这类做法统称为“流程型 skill”它不直接写某个功能而是定义模型怎么思考。Superpowers 在这里起了一个很大的带动作用后面冒出来的 taste skill、impeccable skill、archify skill本质上都是同一思路的不同切片。但问题也出在这里流程型 skill 好用不代表它应该永远挂在默认配置里。尤其是当你的执行工具从 Claude Code 换到 Codex、Workbuddy 这些自带规划能力的代理之后整套流程里的很多环节就变成了重复劳动。1.2 2026 年失灵的具体表现我最近几个月观察到的失灵不是“完全不能用”而是“处处不划算”。主要有这么几类表现。第一token 开销明显变大。一个几十行的 skill 加上工具说明在每轮对话里都要占用上下文窗口。别小看这几 KB假设一次会话交互 30 轮模型每轮都要重新消费这部分上下文累计下来就是一个不小的数字。更麻烦的是上下文窗口被流程说明挤占之后模型更容易遗忘早期读过的文件内容于是又得回头重新读文件进一步推高消耗。流程越重越容易遗忘越要重新读这是一个恶性循环。第二方向漂移反而更严重。Superpowers 的 brainstorming 阶段要求模型发散地聊方案这在目标模糊时是有价值的。但 2026 年的模型本身已经具备很强的拆分能力你再让它发散一轮再收回来它经常会把“用户让我加个按钮”聊成一个“重新设计整个交互层”的重构计划。我遇到过好几次明明是一个小的功能改动模型在 brainstorming 里提出了四五种激进方案最后选了一个改动面最大的理由是“更符合长期架构”。这种“创造性”放在项目维护阶段其实是灾难。第三和代理内置能力重复。Codex 和 Workbuddy 内部已经自带任务拆分、状态跟踪、自检机制Agent 本身就会维护待办清单也会在跑测试后修正代码。外部再套一套完整工作流等于同时让两个项目经理指挥同一个团队一个让模型按部就班一个让模型自由发挥最后模型自己也容易精神分裂。1.3 让我真正开始切换的转折点触发我彻底转变的是一次很小的线上问题。当时想用 Codex 修一个登录页面的 bug改动本身可能只有 3 行代码。但因为我默认加载了 Superpowers它先按 brainstorming 阶段输出了四种修复方案对比又按 planning 要求写了一整段迁移计划最后在 executing 阶段才慢慢腾腾改代码。你说它错了吗也没错。但整个流程跑了 20 多分钟token 烧掉一大截改完的 diff 还带着一段“VM 建议的重构”。从那次以后我开始记录不同 skill 配置下的任务表现越记越觉得不对劲。2. Codex 和 Workbuddy 的工作流差异决定了它们需要的是“小而准”而不是“全”2.1 Codex 是“短迭代”型选手它缺的不是流程是刹车Codex 的典型工作模式是模型读代码 → 改代码 → 跑测试 → 看结果 → 再改。这个循环本身非常快非常适合在真实仓库里做渐进式修改。它对 skill 的要求不是“教它怎么做”而是“告诉它边界在哪”。举个例子我同时用两套配置跑过同一个 bug 修复任务。一套加载了 30 多行的流程型 skill另一套只加载了下面会讲的 8 行约束型 skill。结果很直观前者第一轮回复会花一大段文字解释自己要执行什么流程后者上来就直接定位到出错函数、给出改动方案。同样一个任务后者第一轮就开始干活了。这并不是说流程型 skill 没有价值而是说在 Codex 这种工具上模型最不缺的就是任务拆解能力缺的反而是一个能阻止它越改越多的“刹车”。另外提一句大家在使用 Codex 时偶尔会遇到本地链路报错比如 endpoint 层面的连接失败。这类问题大多和网络环境、认证配置相关和 skill 选型是两码事真正排查时建议先确认工具本身能连通再调试 skill否则很容易被带偏。2.2 Workbuddy 偏爱“纪律型” skill 来对齐多代理Workbuddy 在我了解到的信息里更偏向团队协作和任务并联的编码代理。也就是说它经常需要把一个大任务拆给多个 agent 并行处理。在这种多代理场景里如果你给每个 agent 都塞一套几百字的流程规则结果往往不是协作而是各说各话。A 代理觉得该先写测试B 代理觉得该先改接口C 代理已经开始重命名目录了。我观察到一个很有意思的现象当我把一套极简的“范围约束”规则放到 Workbuddy 的每个 subagent 里时它们最终产出的代码风格和边界意识反而高度一致。原因很简单多代理协作最需要的不是每个 agent 都有多强的创造力而是对共识的执行力。极简 skill 在这里扮演的角色不是流程手册而是团队契约所有人都只改自己负责的部分所有人都在结束时报告改动清单。2.3 两种工具对 skill 的加载机制有一个共同的坑不同工具对 skill frontmatter 字段的解析并不完全一致。有的读取name和description有的还会读取allowed-tools有的对 description 长度很敏感。直接把 Claude Code 生态里做好的 skill 复制到 Codex 或 Workbuddy经常会出现“description 被读取了但正文规则没生效”的情况。这也是我后来坚定选择极简 skill 的原因之一字段越少跨工具迁移时的出错面越小。当你只依赖name和description两个字段时不管是 Claude Code、Codex、Workbuddy 还是 OpenCode基本都能正确解析。反过来如果你在一个 skill 里混用多种工具的专属字段换一次工具就要踩一次坑。3. 那个不到 10 行的 skill完整示例与逐行设计逻辑3.1 我目前在用的版本长这样这是我现在多个项目里默认加载的 skill文件放在.claude/skills/narrow-delivery/SKILL.md或者对应的 Codex/Workbuddy skill 目录下--- name: narrow-delivery description: 收紧任务范围只做最小必要改动并在结束时给出可执行自检。 --- 1. 动手前用三句话复述任务目标与验收标准若目标不清晰先提问禁止猜测。 2. 执行中只修改与目标直接相关的文件禁止顺手重构、升级依赖、调整无关格式。 3. 结束后输出改动文件清单、每条改动的理由以及你亲自跑过的验证命令。这里只有 8 行。第一次看到这个文件的人多半会觉得“这也太偷懒了”但它恰好解决了 Superpowers 这类流程型 skill 最不在乎的问题明确告诉代理“哪里是终点”。3.2 逐条拆解为什么是这三句话而不是三十句第一条“用三句话复述任务目标与验收标准”。这一条建立了一个确认点。模型面对长任务时理解偏差的一大半发生在第一段 prompt 之后。你让它用自己的话复述一遍目标它就必须把“我理解的任务”显式说出来而不是默默脑补。如果它说不清那大概率是 prompt 本身有歧义这时候让它继续做就是在浪费 token。第二条“只修改与目标直接相关的文件禁止顺手重构”。这是整个 skill 里收益最大的一行。近两年的模型在修改一个函数时非常容易顺手把相邻代码“优化”掉理由往往是“这样更一致”“这里有个潜在 bug”。对于一个完全自主运行的代理来说这种行为会放大 diff 面积引入不必要的回归风险。实测下来有这一行和没有这一行代码 review 阶段需要返工的概率能差出一倍。第三条“输出改动文件清单、理由和验证命令”。它的作用不是给人类看而是逼模型形成一次闭环。很多 agent 在跑完测试后会说“修复完成”但不会告诉你它到底改了什么、为什么这么改。有了这一条模型必须在收尾时把“我改了啥、为什么、怎么验证”讲清楚那些依赖幻觉的“已完成”会被大幅抑制。3.3 为什么不直接用一句系统 prompt 代替你可能想问既然只有三句话为什么不直接在 system prompt 里写还要单独建一个 skill区别在于可检索性和按需加载。直接写进 system prompt意味着它在任何任务里都会生效包括那些不需要约束的场景。而作为 skill它只会在模型判断“这个任务符合 description 描述”时被加载触发面更精准不会干扰模型在自由任务中的发挥。另外用独立文件管理 skill 可以进版本控制每次改动都有记录这在团队协作里的价值是普通 prompt 完全比不了的。3.4 为什么它能顶住大流程段的压力核心原因是2026 年的编码代理已经具备很强的推理和任务拆解能力。Superpowers 本质上是一个方法论文时代的产物当时模型还不太会自己 split task需要 skill 来教而现在 Codex、Workbuddy 内置的 Agent 已经学会了这些套路真正稀缺的是“别做多”的刹车。所以我的立场是流程型 skill 并没有死只是它应该从“默认加载”变成“按需触发”。当你要做一个方向极不明确的原型或者进入一个完全陌生的代码库时临时加载一个 Superpowers 式的流程 skill 依然很香。但日常开发里默认配置应该是一个极简的约束型 skill让模型在已经具备的能力之上自由发挥只在边界处听你指挥。3.5 一个容易踩的设计误用很多人看到这种 skill 之后会忍不住往里面加规则“每周更新 changelog”“必须使用 TDD”“不要用某个 API”“注释必须写成中文”……加上加去又变成一个 100 行的大杂烩。这里必须说清楚极简 skill 的目标是通用行为约束业务规则要放到项目文档或 spec 里不要混进 skill。一旦混入具体业务这个 skill 就失去了跨项目复用的能力也容易和其他项目规则打架。4. 从 Superpowers 切到极简 skill我的迁移实操建议4.1 第一步不要直接删先用一周做对照我的建议是先别急着把 Superpowers 删掉。你可以把它保留在目录里但不要设为默认加载然后新建一个narrow-delivery目录把上面那个 SKILL.md 放进去。接下来一周所有新任务一律走极简 skill期间记录四个数据任务完成轮次、首次通过率、消耗的 token 量、代码 review 中被点到的问题数。这不是一个“凭感觉”的切换而是一个可以量化的工作流对比。我当时的实验结果非常直接极简 skill 在大部分维护型任务上的完成时间缩短了 30% 以上而且“改了无关文件”这个问题几乎消失。等一周后数据摆在面前你再决定要不要永久切换会更有底气。4.2 三个容易翻车的细节细节一description 写太宽。description 是模型决定“这个 skill 要不要被加载”的入口。如果你写成“用于所有编码任务”它会在每个任务里都加载自己反而增加 token 消耗和指令冲突。建议描述尽量具体例如“当你需要在一个已有仓库中做小而明确的改动时使用”。这样模型只有在任务匹配时才会拉起它。细节二复述目标阶段不要要求过长。有人在第一条里写“请列出 200 字的详细实施方案”这种写法等于换一种方式浪费预算。三句话就是三句话目标 验收标准最多再加一句“如果不确定就提问”。精简是对代理能力的基本尊重。细节三frontmatter 字段越少越安全。我前面提过不同工具对字段解析不一致。在 Claude Code 里能正常生效的allowed-tools放到 Codex 的某些老版本里可能直接被忽略Workbuddy 对 description 长度也有自己的脾气。稳妥做法是只保留name和description把规则全部放在正文里。4.3 和 openspec / 需求文档配合的方式如果你所在的团队已经在用 openspec 这类规格驱动流程你会发现极简 skill 不但不冲突反而放大了 spec 的价值。原因很简单极简 skill 只负责约束“怎么做”而“做什么、为什么做”由 spec 提供。二者职责分离之后skill 不会再试图扮演需求分析师的角色spec 也不会越俎代庖去规定模型的代码风格。我自己的一些项目就是“Claude Code openspec narrow-delivery”的组合superpowers 偶尔在原型阶段才会被临时叫出来。整个工作流跑下来最大的感受是可控性上来了模型不再自己给自己加戏。5. 实测对照同一个任务在两种方案下的差别5.1 任务样例与测试方式为了不纸上谈兵我挑了一个中等规模全栈项目里的真实任务做了一次对照给现有后台系统加一个“用户反馈”入口涉及数据库表、API 接口、前端弹窗和基础埋点。这个任务目标清晰但会跨多层非常适合测试 skill 的约束效果。方案 A默认加载完整 Superpowers。方案 B默认加载 narrow-delivery。两边都用 Codex模型保持同一版本初始 prompt 完全一致。除了 skill 之外不额外注入任何业务知识避免变量污染。5.2 对照结果下面是我这次对照实验的记录维度方案 ASuperpowers方案 Bnarrow-delivery从开始到首次提出方案12 分 16 秒6 分 42 秒需要人工介入的轮次4 次1 次最终改动文件数117代码 review 中被点出问题的数量62明显无关的“顺手优化”次数30总 token 消耗估基准约低 28%需要说明这些数字只是一次小样本实验不足以证明极简方案在所有场景都更好。真正让我印象深刻的不是时间而是“无关优化”那一列。满配 skill 的 agent 在执行过程中会顺手对不相干的模块“用自己的审美”动刀改一下命名、调一下格式、换一个写法。这种行为在单次任务里看似无害放到长周期项目里就是 review 成本的无底洞。5.3 什么情况我仍然会切回 Superpowers第一从零搭建一个方向极不明确的原型需要模型先发散、多提几个候选方案。第二处理一个我完全没看过的历史包袱希望模型先做调研和方案对比再动手。第三团队协作时大家统一用一种大流程标准把流程标准化为团队默契。在这些场景里Superpowers 这类流程型 skill 的价值还是很大的。但即便是这些场景我也不会把它挂在默认配置里而是单独建一个按需触发的 skill。默认配置保持轻需要的时候再叫重武器这是我现在比较认可的一种使用方式。6. 最后想分享的两点真实体会这篇文章写到最后我想说的其实就两件事。第一别把 skill 当作“越多越好”的收藏品。我见过很多人手机里存了几十个 skill真正用起来的没几个。一个 skill 每次被加载都要从模型宝贵的上下文窗口里分走一块预算。与其堆数量不如追求每次加载时的边际价值它到底帮你省了多少轮对话、避免了多少次返工。一个 8 行的约束型 skill如果能让代理少做三次无关优化它的价值就已经超过了一整套华丽的流程模板。第二切换不要靠直觉靠记录。我也是在被 superpowers 折腾了两三周之后才下定决心做对照实验的。如果你现在也处在“感觉不太对但说不上来为什么”的状态我建议你拿出一个星期选一个极简 skill 做默认配置记录完成轮次、token 消耗、review 问题数这几个硬指标。一个星期后数据会告诉你答案。最后再分享一个小技巧给这类约束型 skill 命名时别用太花哨的前缀建议直接用能描述行为的短词比如narrow-delivery、focus、scoped-change。这样在 Codex、Workbuddy 的命令行自动补全和配置文件里都更容易被检索到团队之间分享时也更清楚它是干什么的。一个 skill 的价值不在于它写了多少字而在于它在关键时刻让代理停了下来问了一句“你确定要改这个吗” 这句话我猜每个被 agent 惊喜过、也惊吓过的人都会懂。