前几天在知乎看到有人问：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 做什么。

强模型时代，什么 Skill 还值得留

我现在会优先保留三类 Skill。

第一类是模型很难凭空猜到的个人偏好和固定产物，比如文章风格、图表规范、公司内部模板、特定代码库的发布流程。 有了这些约束，每次交付才能尽量保持同一套标准。

第二类是带有专业判断、脚本或参考资料的任务。 安全审查、复杂文档处理、特定框架迁移、生产检查，这些任务只靠一句 Prompt 很难覆盖所有细节。Skill 可以把检查项、工具脚本和证据来源放在一起，用到时再加载。

第三类是专门减少方向错误的 Skill。

mattpocock/skills 就更接近我现在喜欢的方向。作者强调这些 Skill 要小、容易修改、可以组合，不接管整个开发过程。你可以只拿走眼前需要的那一块，按自己的项目继续改。

群里也有人在用这套 Skills，甚至拿它做了自己的 guideskill。这个反馈我挺认同：平时用轻量 Skill，任务复杂时再组合，比一开始就套完整流程舒服得多。

这里面我尤其喜欢 grilling。

它的规则很短：动手前持续追问，把计划、决策和依赖关系问清楚；一次只问一个问题，等用户回答后再继续；能从环境中查到的事实自己查，需要取舍的决定再交给用户。

我最近正好拿自己的开源项目试了一次。

这个案例来自我的开源项目 《SpringAI 智能面试平台》（2.0 版本已开源），目前在 GitHub 上接近 2.8k Star。当时我准备把模拟面试和知识库打通，给 grilling 的任务也很直接：帮我把这件事想清楚。

现有实现比我预想的更接近“打通”：知识库面试和普通模拟面试都在用 InterviewSession，作答、评估和部分前端页面也已经复用。所以这次没必要先折腾底层，得先把首期产品范围定下来。

它问的第一个问题，是首期到底要做“完全基于用户资料的定向面试”，还是让用户照常选择 Java、系统设计等 Skill，知识库只负责补充上下文。

它建议我先做前者。因为现有的题库生成、分类、难度、固定追问和评分规则都更贴近这条链路，只要统一入口和历史记录就能跑通；后一种方案还会引出 Skill 题目与知识库题目的混合比例、实时 RAG、来源冲突、评估依据和题目去重，改造范围一下子大了很多。

我确认首期目标后，它才继续问：一场面试只选一个知识库，还是允许组合多个知识库？当前请求、会话字段和题库筛选都只有一个 knowledgeBaseId，所以它建议首期先限制单库，等流程稳定后再考虑多库关联。

接着是入口。知识库面试已经有独立页面，普通模拟面试从“模拟面试中心”进入。最后确定的是双入口共存，但共用同一套配置组件和创建接口，避免后面维护两套交互逻辑。

代码还没开始改，产品目标、数据模型和入口复用方式已经定下来了。

我愿意保留 grilling，原因就在这里。模型写代码已经够快了，麻烦往往出在开工太早：需求范围没定，异常处理没聊，用户场景和技术取舍也还含糊。Agent 按自己的理解一口气做完，我最后还得推倒重来。

模型越强，执行越快，走错方向的代价也会跟着变大。

grilling 没有教模型怎么写代码，它负责在开工前把含糊的地方问出来。这种 Skill 反而很难被强模型替代。

我的 Skill 删减标准

现在每装一个 Skill，我都会多问几句：

• 这件事模型原本就会做吗？
• 没有它时，我是否反复在同一个地方翻车？
• 它有没有沉淀脚本、模板、专业资料或个人偏好？
• 这套规则过期之后，我有没有办法发现并删掉？

只会反复提醒“先读项目、再写代码、最后跑测试”的 Skill，我现在基本直接删。Codex 已经会做这些事，项目里真有特殊要求，写进 AGENTS.md 更省事。

同一个地方连续翻车，才值得我单独写一个 Skill，尤其是那些出错代价不低的任务。里面只留几条关键判断和验证动作，够解决问题就停，不顺手扩成一套大而全的工作流。

关于 Codex 里的 AGENTS.md、权限、MCP、Skills 和 Automations 分工，我另外整理了一篇 Codex 使用指南：配置、AGENTS.md 与 Agentic 工作流。Claude Code、Cursor、Codex 这些工具的实战内容，则统一放在 AI 编程实战指南 里。

这篇文章题目里写了“再见”，但我没准备把 Skill 全删掉。我只是不会再看到一个就装一个。

现在遇到一个新 Skill，我会先不用它跑一次。能跑好，就不装；如果同一个问题反复出现，再把那一小段流程留下来。这样清理完，列表可能短了不少，但每个 Skill 为什么还在，我心里有数。