前几天在知乎上看到一个值得探讨的问题：Codex用上GPT-5.6之后，为什么越来越多用户开始放弃使用Skills？

确实，相信大家也注意到了，许多Skill，尤其是那些开发相关的工具，正逐渐变得有些鸡肋。如今看到一个新Skill，第一反应是先琢磨它到底能提供什么独特能力。如果没什么实际作用，自然不会安装。

前两年，模型执行任务经常遗漏步骤，Skill写得越详细越让人安心。但现在GPT-5.6、K3、Claude Fable5这些模型的能力确实提升了不少，很多基础操作模型自己能补全。手头的Skill，也是时候重新筛选一遍了。

很多基础步骤，已经不需要再额外指导了

以前的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把这些能力打包起来。

为什么我很少再用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，尤其是那些出错代价不低的任务。里面只留几条关键判断和验证动作，够解决问题就停，不顺手扩成一套大而全的工作流。

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

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