再见 Superpowers！很多 Skill 真的可以扔掉了

baiduweb

前几天在知乎看到有人问：Codex 用上 GPT-5.6 后，为什么不少人开始不用 Skills 了？

确实，相信大家也发现，很多 Skill，尤其是开发相关的，真的慢慢就开始用不上了。
我现在看到一个 Skill，会先看它到底能提供什么能力。如果没有确切作用的话，肯定是不会装的。
前两年，模型干活经常漏步骤，Skill 写得越细越让人安心。现在 GPT-5.6 、K3、Claude Fable5 等模型已经很强，能自己补上大部分基础动作，手里的 Skill 也该重新过一遍。

下面我会以 Codex 作为 Coding Agent 为例来谈，其他都是类似的。

很多基础步骤，已经不用再教了

以前的 Skill 经常写成一张操作清单：怎么读项目，怎么找调用链，改完代码跑哪些测试，提交 PR 前再查什么。模型能力不够稳时，这些提醒确实有用。
现在让 Codex 修一处 Bug，通常只要把现象和预期说清楚。它会自己读项目、顺着调用链找问题，改完补测试、跑验证。写文档或者做个小工具也差不多，材料放在哪、最后要交付什么说清楚，中间的步骤它大多能补出来。
长任务、审批、多 Agent 协作，Codex 本身也能处理。要扩展外部能力，还有 Skills、Plugins、MCP 和 Hooks。早期 Agent 那种“不把步骤写满就容易乱跑”的情况，已经少了很多。

一份 SKILL.md 如果没有项目特有的约束，也没有脚本、模板和检查项，只是在重复常规步骤，我不会留。它没给模型增加多少信息，倒可能让一个小任务多走几道流程。
Skill 装多了，还会互相抢活

Codex 不会在会话一开始就把所有 SKILL.md 全文读一遍。它先拿到每个 Skill 的名称、描述和路径，任务匹配上以后再加载正文。这套机制叫渐进式披露。
前面这份 Skill 列表也要占上下文。按照 Codex 的 Skills 文档，它最多使用模型上下文窗口的 2%；无法确定窗口大小时，上限是 8000 个字符。超出预算后，Codex 会先缩短描述。数量继续增加，一些 Skill 会被移出初始列表。
装到 100 个时，Agent 开工前看到的可能已经不是 100 份完整描述。
描述写得宽，一个普通改动就可能命中好几份 Skill；规则有冲突，Codex 还要临时判断听谁的。再混进几份半年没维护的说明，任务跑偏时，很难第一眼想到是 Skill 在添乱。
上下文窗口变大后，旧对话、工具说明和 Skill 描述都能往里放。项目最在意的约束往往只有三五句，埋在这些内容中间，模型偶尔漏看并不稀奇。

Skill 和浏览器书签挺像。刚开始看到什么都想存，总觉得以后用得上。半年后回头一看，常用的还是那几个。
从 Skill 出来到现在，我经常使用、愿意长期维护的，不超过 20 个。比如写作时常用的 draw.io 绘图 Skill，它能固定图表样式，也能避开我反复遇到的排版问题。这种 Skill 我会留着，因为它沉淀的是个人偏好和具体经验，单靠模型临场发挥很难一直稳定。
先分清楚，这条规则到底该放哪

很多 Skill 越写越大，是因为大家把所有规则都往里面塞。
我现在更倾向于这样分：

• 每轮任务都要遵守的项目约定，放进 AGENTS.md 或项目规则文件。
• 只在特定任务中才需要的流程，写成 Skill。
• 耗时较长、会制造大量中间信息的支线调查，交给 Subagent。
• 需要把 Skills、Hooks、MCP 和连接器统一分发给团队，再打包成 Plugin。
• 漏一次就可能出问题的机械约束，交给 Hook、CI、linter 或测试，不要只靠自然语言提醒。
  

规则文件管“这个项目一直怎么做”，Skill 管“遇到这类任务时怎么做”。两者混在一起，最后往往会得到一个很长、什么都想管、又很难维护的 SKILL.md。
Skill 适合可复用的任务流程，可以携带脚本、参考资料和模板，并在命中任务后按需加载。团队要安装和分发时，再用 Plugin 把这些能力打包起来。

如果想系统理解 Skill 和 Prompt、MCP、Function Calling 的分工，可以看 AIGuide：AI 应用开发、AI 编程实战与面试指南。那篇文章更偏工程实现，这里不展开成教程。
为什么我很少再用 Superpowers

像 Superpowers 这类大而全的 Skills 套件，我现在确实用得少了。
刚刚我把这件事丢到群里聊，大家的反应也挺真实：Superpowers 容易把流程越搞越复杂；grilling 能一口气问几十个问题，烦是烦，但需求确实会清楚很多。

项目本身没有问题。它提供的是一套完整的软件开发方法：先通过 brainstorming 澄清需求，再用 writing-plans 拆任务，按 test-driven-development 写测试和实现，通过 git worktree 隔离开发，交给 Subagent 分段执行，最后做代码审查和完成前验证。
复杂项目、陌生代码库、高风险改动，这套流程依然很有价值。
麻烦出在使用时机。假如只是改一处校验逻辑，或者补一个很小的测试，上来就走完“需求澄清 → 设计 → 计划 → 执行 → 审查 → 验证”，时间很容易被流程本身吃掉。
流程越完整，越考验启用时机。任务不够复杂时，它就会从保护变成负担。
现在的 Codex 已经能在执行过程中调整步骤，也会在缺少关键信息时请求确认。很多小任务只需要补几条项目约束，没必要每次都给它套上一整本操作手册。
还有安全问题。SKILL.md 本身就是给 Agent 的指令，第三方 Skill 里如果藏了危险命令、异常脚本或过宽的权限要求，Agent 可能真的会照着做。安装前至少看一遍 SKILL.md、scripts/ 和 references/；套件越大，越该先弄清楚它会让 Agent 做什么。