告别Superpowers：用不到10行极简Skill让AI编程更稳定高效

去年年底到现在我一直在折腾 Superpowers、Codex 和 Workbuddy 这套组合GitHub 上的 star 数看着吓人各种安装教程、使用指南、权重调优文章遍地都是。如果你正在用 Codex 或 Workbuddy 跑日常开发任务大概率也装过 Superpowers 这类大型 skill 集合甚至把 brainstorming、TDD、debugging 这些模块全部挂了上去期待 agent 能像资深工程师一样稳定交付。我的结论是这套方案在 2026 年已经开始过重了真正让 agent 稳定靠谱的反而是我自己写的一个不到 10 行的极简 skill。先说清楚一个背景Superpowers 这类 skill 集合的核心价值是把一整套软件工程方法论编码成 agent 的行为规范。早期模型能力不够时这种“手把手教”的方式确实能显著提升输出质量。但模型本身在迭代当底层推理能力已经足够强之后继续堆砌几百行行为指令带来的是上下文污染和 token 损耗而不是更聪明的表现。这篇文章就是把我这段时间的实践、踩坑和最终方案整理出来想给正在纠结“要不要上 Superpowers”的朋友一个参考。1. 大型 skill 集合到底解决什么问题1.1 大型 skill 集合的本质Superpowers 这类项目本质上是一个“方法论打包器”。它不是教模型写代码而是把人类工程师的工作习惯拆成可执行的步骤模块。比如 brainstorming skill会强制 agent 在动手前先列出三到五个方案分析每个方案的利弊TDD skill 会让 agent 先写失败测试再写实现代码debugging skill 则引导 agent 按“复现-定位-修复-验证”四个阶段推进。这种做法的出发点很好因为我见过太多 AI 编程翻车现场需求没理解清楚就开写写到一半发现方向错了代码一次性生成几百行报错后无从排查改了一个 bug 引入两个新 bug。大型 skill 集合的作用就是用流程约束来兜住这些低级错误让 agent 至少看起来像一个“有职业素养的程序员”。早期我用 Superpowers 时确实感觉到了明显变化。尤其是它的 brainstorming 模块逼着 agent 在动工前先和我对齐方案这大大减少了返工次数。在那个人工智能编码助手刚起步的阶段这种结构化约束是刚需因为模型很容易自信满满地跑偏你要是不拦着它能给你写出一整套用不上的功能。1.2 为什么 2026 年它开始“失效”到了现在这个时间点底层模型的指令遵循能力和推理水平已经上了好几个台阶。你给一个足够聪明的 agent 一个模糊需求它自己就能想到要问清楚边界条件、要考虑异常场景、要设计测试验证路径。这些能力不再需要几百行 skill 指令去“教”或者说教的效果边际递减得非常厉害。我做过一个对比实验同一个全栈小项目分别用“裸 Codex 一个极简 skill”和“Codex Superpowers 全量模块”去跑。结果非常反直觉极简 skill 组的代码质量反而更高而且整体耗时少了将近 40%。原因在于Superpowers 的指令体系会占用大量上下文空间每次对话开始时agent 都要加载这些行为规范真正留给代码逻辑的“注意力”反而变少了。还有一个很实际的问题大型 skill 集合的模块之间存在指令重叠甚至冲突。比如 brainstorming 要求“动手前先讨论方案”TDD 要求“先写测试再写代码”两者叠加时agent 经常陷入两头为难的状态反而拖慢进度。你去看那些“Superpowers 安装真是绝了”的帖子下面评论区大概率有人问为什么自己的 agent 变蠢了十有八九是模块冲突导致的上下文污染。1.3 权重的诱惑与上下文税很多人在配置 Superpowers 时会调 skill 权重把某个模块的优先级提到很高。这个思路在早期模型上有用因为模型对指令的敏感度低需要权重来强调“先做这个再做那个”。但现在模型对指令的敏感度已经很高了权重过高反而会让 agent 死守流程丧失基本的灵活判断。我把这称为“上下文税”每一条 skill 指令都是要付 token 费用和上下文开销的。指令越多agent 的推理空间越小越容易变成“流程机器人”。尤其当你同时挂了 Superpowers 和 Workbuddy 这套组合时两边的指令叠加上下文窗口的可用比例会大幅下降。注意上下文不是越满越好agent 需要在上下文里腾出空间来“思考”你的代码、你的项目结构、你的需求细节。你把上下文全塞给行为规范它自然没有余力去理解业务。2. 极简 skill 的核心设计逻辑2.1 不到 10 行的规则长什么样我调试到最终稳定使用的 skill去掉格式标记后核心规则只有 8 行左右。它的目的不是教 agent 怎么做而是划定 agent 和人的协作边界让 agent 在关键节点主动停下来对齐。--- name: minimal-align description: 极简行为约束技能用于任何 AI 编程 agent 的对齐与交付控制。 --- - 拿到需求先复述核心目标确认理解一致后再动手。 - 需求有模糊点先提问一次只问一个最关键的问题。 - 拆解任务时控制在三个可交付步骤内每步都可验证。 - 编码遵循项目现有风格不擅自引入新依赖。 - 每个步骤完成后简述改动内容与验证方式不夸大产出。这个 skill 的精髓在于它把“对话节奏”而不是“技术流程”作为核心约束。它不告诉 agent 怎么写代码只告诉它在什么时候要停下来和人对齐。这正好踩中了 AI 编程最大的坑agent 太爱一口气把活干完而人在这个过程中完全失控。2.2 逐条拆解为什么这几条够了第一条“先复述核心目标”是为了触发 agent 的“自我解释效应”。模型在复述需求时如果理解有偏差会在复述阶段就暴露出来而不是等到代码写完才被发现。这一条能拦截掉大概一半的需求理解错误。第二条“有模糊点先提问一次只问一个”是控制对话成本的关键。很多 agent 一次抛三四个问题用户根本答不过来最后干脆不答了agent 又只能瞎猜。一次只问一个最关键的能保证对话推进下去同时不打断 agent 的思考节奏。第三条“拆解任务控制在三个可交付步骤内”是防止 agent 把任务拆得太碎。拆得越碎每一步之间的衔接成本越高整体失败率也越高。三个步骤是最少的层级既能让用户看清进度又不会让 agent 陷入“每十步一回头”的低效状态。第四条“遵循项目风格不擅自引入新依赖”是针对实际的工程协作场景。agent 最大的破坏力不是写错代码而是引入一堆不必要的依赖把一个干净项目变成依赖地狱。这条规则直接锁死了这个问题。第五条“每步完成后简述改动与验证方式”是要让用户全程保持掌控感。你可以随时看到 agent 做了什么、怎么验证的不需要等到最后才发现方向错了。2.3 与大型 skill 集合的取舍对比维度Superpowers 类大型 skill极简对齐 skill上下文占用高数百行指令常驻极低常见留白给业务模型能力适配度适合旧模型新模型边际收益低吃模型基础能力越强越出彩模块冲突风险较高需要手工调优权重无冲突单层规则上手成本需要阅读大量文档和模块说明十分钟写完即用适用场景大型重构、复杂多阶段任务日常开发、功能迭代失败模式流程臃肿、灵活性差依赖模型本身推理水平这个对比不是说 Superpowers 一无是处而是说它需要匹配使用场景和经济成本。如果你只是写一些 CRUD 功能、修 bug、做小范围迭代极简 skill 的效率优势非常明显。只有在大型架构重构、复杂性能优化这类任务上Superpowers 的系统方法论才能体现出价值。3. 实操建议从零部署到日常使用3.1 手把手写一个自己的极简 skill我这个 skill 不是直接抄来的而是根据自己项目的实际情况裁剪出来的。写 skill 的第一步不是急着堆规则而是回顾你过去一周和 agent 协作时最常出现哪几类问题。比如如果你的 agent 经常不等你确认需求就开写那就把“先复述再动手”放在第一条。如果它经常一次性改太多文件就把“一次只做一个变更”加进去。我自己写的初始版本有七条规则用了一周后发现其中两套规则的效果是可替换的就砍掉了。现在这个版本是七个规则压缩到五个之后的结果。每次砍掉一条规则我会刻意观察 agent 的行为有没有退化如果没有就说明这条规则本来就是多余的。提示规则不是越多越好写到“再砍一条就会出问题”的状态才是最佳状态。这就跟代码一样最好的代码是删到不能再删的代码。3.2 放对目录按工具要求启用不同的工具对 skill 的挂载方式不太一样。像 Codex 这类 CLI 工具通常支持通过 AGENTS.md 文件把规则注入到每次会话中你只需要把极简 skill 的内容放进项目根目录的 AGENTS.md 里或者放到全局配置目录下作为默认指令。Workbuddy 这类桌面工具一般有独立的 skill 管理界面可以新建一个 skill 条目把规则粘贴进去后启用即可。放置位置决定了“这个规则只对这个项目生效”还是“对所有项目都生效”。我的建议是极简 skill 放到全局配置里因为它的约束都是通用行为边界对任何项目都适用。而像 TDD、架构设计这类特定方法论才需要按项目单独挂载。如果你用的是 Codex CLI还需要注意一点项目根目录的 AGENTS.md 会叠加全局配置文件。如果全局已经有一个零散规则的项目级 AGENTS.md极简 skill 的内容会和其他指令混在一起效果可能打折扣。建议把极简 skill 放到全局然后清理项目里那些临时性的“一次性指令”保持整个指令体系干净。3.3 Codex / Workbuddy 场景下的启用细节在 Codex 里启用极简 skill 时有一个小技巧把规则放到 AGENTS.md 的顶部让模型在会话早期就“看到”它。模型的注意力在会话启动时最集中放在后面的规则容易被淹没在后续的大量系统提示和工具说明中。Workbuddy 的场景稍微不同它的 skill 体系更强调模块化可能会要求你给 skill 设定触发条件或应用范围。这时候就把极简 skill 设为“始终生效”不需要设触发条件因为它本身就是一个行为框架不需要等特定上下文才生效。还有一个容易被忽略的操作启用后不要急着开始业务任务先让 agent 用新的 skill 规则跑一个最小例子确认它真的在按照规则行事。你可以在对话里故意给一个模糊需求观察它是否先提问而不是直接开写。如果它没提问说明规则没有被正确加载这时候需要检查挂载路径或文件格式。4. 常见问题与排查技巧实录4.1 规则没生效agent 还是老样子这是一个很常见的坑。很多人在配置好极简 skill 后发现 agent 的行为没有任何变化就开始怀疑“是不是规则不够多”。其实大概率是加载顺序或格式的问题。Codex 这类工具对 AGENTS.md 的格式有特定要求有些工具要求用特定的标记块包裹规则格式不对会直接忽略整个文件。排查方法是在对话里直接问 agent“你当前的行为约束是什么”如果它能准确复述规则内容说明加载成功。如果复述不出来就检查文件路径是否在工具的扫描范围内以及格式是否匹配。实测下来这一步能解决九成“规则无效”的问题。4.2 加载了规则但 agent 偶尔还会跳过提问这种情况一般是 agent 的“判断”认为当前任务足够清晰不需要对齐。我的处理方式是在碰到具体问题时用一句“你忘了我们先要确认需求”来提醒它。这会给模型一个强化信号后续它会更愿意在模糊场景下主动提问。多次强化之后这个行为会变得更稳定。还有一个小技巧是在规则里加一句“当你不确定需求是否清晰时默认认为不清晰”。这能大幅降低 agent 跳过提问的概率。虽然听起来有点绕但在实际测试中这句话的效果立竿见影。4.3 Codex 切换服务后的接口报错排查用 Codex CLI 连接不同的模型服务时偶尔会碰到类似 “cc switch local proxy failed while handling codex endpoint /responses” 的报错现象是切换服务后接口调不通会话直接中断。这通常不是 skill 配置的问题而是服务切换后本地接口的响应路径没有正确刷新。我的排查顺序是先确认目标服务本身是可用的直接访问它的 /responses 接口看是否正常返回再检查本地配置里指向的服务地址、端口和密钥是否和当前目标服务一致然后尝试重启 Codex 进程让配置重新加载。九成情况是切服务时端口被之前的进程占用或者密钥没有同步更新重启进程就能解决。4.4 Workbuddy 和其他工具指令互相覆盖这是一种比较隐蔽的冲突。Workbuddy 和 Codex 同时使用时两边可能各自加载一套规则后加载的规则会覆盖前面已经生效的指令。结果是两边都配了极简 skill但行为表现却完全不是那么回事。排查方法是看会话的完整上下文找到实际生效的指令来自哪个工具。如果发现是覆盖问题就只在其中一个工具里启用极简 skill另一个用空的 AGENTS.md 或者把相关配置关闭。不要让两个工具同时注入同一套规则这会白白浪费上下文空间。5. 什么场景下我还是会切回 Superpowers5.1 大型模块重构在大型模块重构这类任务中Superpowers 这种系统化方法论还是有其价值。它强制 agent 先做现状分析、再设计迁移方案、分批次执行这让重构过程中每一步都有据可查。尤其当项目代码量很大、历史包袱很重时这种强流程约束能显著降低失控风险。我会在遇到这类任务时把极简 skill 暂时停掉切换到 Superpowers 的重构模块。这相当于平时日常任务用轻武器重活再上重火力。不要一个配置打天下工具的切换本身就是一种优化策略。5.2 复杂性能问题定位性能问题定位也是最典型的“流程胜利”场景。一个复杂的性能问题可能是数据库索引、内存泄漏、算法复杂度、外部接口延迟等多重原因叠加。极简 skill 的“三步走”策略在这种场景下会显得力不从心而 Superpowers 的 debugging 模块会引导 agent 按照系统化排障路径逐层下钻避免遗漏关键因素。不过我会限制这类任务的使用频率因为它非常消耗时间。简单的问题用重型方法论反而是杀鸡用牛刀。5.3 我的混合方案现在的日常配置是全局加载极简 skill项目里按需挂载 Superpowers 的特定模块。只有当任务内容明确落在某个模块的适用范围时才临时启用对应模块。这种组合既能享受极简 skill 的高效率和低开销又能在大任务上维持专业深度。组合的关键是做好“开关管理”。我会在每个项目开始时明确列出这次要启用的模块项目结束后关掉。如果你现在还在用 Superpowers 全量配置可以先试着停掉一半不常用的模块观察两周你会发现手头的 agent 突然变得轻快了很多。6. 过来人的几点经验6.1 调 skill 比改 prompt 更值得花时间我在早期总是花大量时间调 prompt试图靠聊天时补一句“你要先想清楚再做”来约束 agent。效果非常不稳定因为 prompt 是一次性的agent 这次记住了下次对话又忘了。skill 规则不一样它是常驻的能持续影响每一次对话的行为边界。所以当你发现 agent 经常出现同类低级失误时别急着在每次对话里重复强调把它写进 skill。这就像培养人的习惯靠一次谈话改变不了人但靠一套制度可以。6.2 观察行为日志而不是只听道歉agent 在犯错之后经常非常诚恳地道歉然后继续犯同样的错。你要看的不是它说了什么而是它的行为轨迹。Codex 这类工具会有详细的会话日志定期翻一翻看看 agent 在哪些节点上出现了和规则相悖的行为。这些行为日志比任何一句道歉都有价值。我在用这个方式排查后把原来的七条规则压缩到了五条因为有几条规则其实从未触发过。保留它们只是浪费上下文。行为日志就是你优化 skill 最可靠的数据源。6.3 每个月清理一次 skill 目录skill 目录会像一个衣柜一样越来越满你总会想着“这个模块以后可能用得上”然后留着它。但每多挂一个模块都是在增加上下文负担。我现在的习惯是每个月末花十分钟把所有模块过一遍凡是这个月没用到的一律停用。清理的时候有个判断标准如果停用之后一个月都没感觉到“少了点什么”这个模块就是真正可有可无的。留下来的一定是能稳定提升交付质量的模块。这套方法坚持了几个月我最大的体会是agent 最好用的状态不是你给了它多少能力而是你给了它多少清晰的边界。规则少不是偷懒是把真正的思考空间还给模型让它把聪明劲用在你的项目上而不是用在解读你的规矩上。