模型能力变强以后，我不再按“装得越多越完整”来管理 Skills。通用规划可以先交给模型，Skill 只保留那些额外提供知识、工具、边界和验收标准的部分。

争议的核心不是要不要 Skills

最近一轮讨论集中在 Superpowers、GSD 等流程型 Skills：它们会要求 Agent 先头脑风暴、写规格、拆计划、执行 TDD、调用子 Agent，再进行多轮 Review 和验证。模型能力较弱时，这种外置脚手架能明显改善执行纪律；但当模型本身已经具备较强的规划、调试、测试和工具调用能力，同一套流程也可能变成重复编排。

整理这篇文章前，我集中读了相关中文讨论，也对照了海外社区反馈与官方文档。这些材料能反映近期争议，但不是统计调查，也不能代表所有 Codex 用户。

观点大致分成三类：

  • 一部分用户移除了整套通用流程，认为原生规划已经够用，额外 Skill 主要增加耗时、交互和用量。
  • 一部分用户仍在复杂任务中使用，但不再让它覆盖所有任务，而是只保留 TDD、规格审查、并行执行等少数组件。
  • 另一部分用户认为问题不在 Skill 本身，而在触发范围过宽、流程过重，以及没有按项目实际情况裁剪。

近期中英文社区里，确实出现了减少通用流程型 Skills、收紧触发范围和改用显式调用的倾向。但这仍然只是社区观察，不是官方基准测试。Token 增长还可能来自推理档位、任务复杂度、子 Agent 数量、缓存或产品版本，不能只凭体感归因于 Skills。

这些材料支持的是一个较窄的判断：现在没有必要再给所有任务强加同一套通用方法论，但这不等于 Skills 机制已经无用。

先理解 Skills 实际如何占用上下文

根据 OpenAI 的 Build skills 文档，Codex 使用渐进式披露：会话开始时只把 Skill 的名称、描述和路径放入上下文，只有决定使用某个 Skill 后，才读取完整的 SKILL.md。

初始 Skill 列表最多占模型上下文窗口的 2%；上下文窗口未知时，上限为 8,000 个字符。Skills 很多时，Codex 会先缩短描述，必要时省略部分 Skill 并发出警告。

因此，不能把所有用量增长都归因于“安装了很多 Skills”。真正容易产生额外开销的是：

  • description 太宽，导致普通任务也被隐式匹配。
  • Skill 被触发后加载了很长的正文和引用资料。
  • 工作流强制增加计划、Review、子 Agent 或多轮确认。
  • 多个 Skills 同时规定相似流程，造成重复执行或指令冲突。

要优化的重点不是盲目清空 Skills 目录，而是减少误触发和触发后的无效步骤。

先问 Skill 多提供了什么

我现在更关心一个 Skill 提供了什么新增信息，而不是它包含多少“最佳实践”：

Skill 类型 建议 判断依据
通用规划、强制多 Agent、固定 Review 流程 降级或改为显式调用 容易与模型原生能力重叠，简单任务中开销最明显
只有方法论、没有项目事实的长指令 精简；没有稳定收益时删除 更像重复提示词，维护成本高
领域知识、证据规则、固定输出 保留，但记录来源、版本和失效条件 模型无法保证自动获得或持续更新
私有 API、MCP、浏览器或内部数据接入 保留，并收紧触发范围 依赖真实工具、权限与错误处理
构建、测试、发布等仓库工作流 放到项目级 Skill 或 AGENTS.md 只对特定代码库成立，应随代码审查
部署、迁移、批量修改等高风险流程 保留审批点、回滚和完成证据 不能只依赖模型自行判断风险
需要可重复、可审计结果的脚本 确有确定性需求时保留 脚本比临时生成命令更稳定

最应该先处理的是触发范围含糊的 Skill。例如：

description: Use for coding, debugging, planning, testing, or reviewing tasks.

这几乎覆盖了所有开发请求。即使 Skill 本身只为少数复杂任务设计，模型也很难从描述中判断什么时候不该用。

遇到这种描述，不必立即卸载。可以依次尝试：

  1. 去掉已经被模型稳定完成的通用步骤。
  2. 补上明确的触发条件和排除条件。
  3. 从用户全局范围移到具体仓库。
  4. 改为只允许显式调用。
  5. 如果仍然没有可观察收益，再禁用或卸载。

用现有配置做一次取舍

以我现在维护的内容为例，worldcup-predictor 仍然适合保留。它提供的不是“先规划再回答”，而是比赛数据分层、市场基线读取、淘汰赛输出、纪律风险和复盘校准等专用规则。这些规则还要随着数据源和赛事变化更新，不能因为模型变强就停止维护。

这个博客仓库的 Ruby 版本、测试入口、文章元数据、专题顺序和发布要求，则继续由仓库的 AGENTS.md 与脚本负责。它们不需要再复制进一个全局开发 Skill。

Superpowers 一类通用流程更适合按任务决定：涉及多个合理方案、公开接口或不可逆决策时再显式使用；小改动不默认走完整的头脑风暴、规格、TDD 和多 Agent Review。这只是作用域取舍，不是已经完成的用量 A/B 测试。

把流程控制改成结果约束

旧写法经常规定每一步怎么做：

先调用 brainstorming，再生成 spec，然后拆成 20 个任务，
每个任务执行 TDD，最后启动 5 个子 Agent Review。

更适合强模型的写法，是说明边界、证据和完成标准：

仅在需求存在多个合理方案、会改变公开接口或包含不可逆决策时先产出 spec。
实现必须覆盖现有测试，并为新增的非平凡分支补测试。
完成前运行仓库规定的完整验证，列出未验证项；
只有审查范围能够独立拆分时才使用子 Agent。

后一种写法不规定模型必须表演哪些步骤，只规定何时需要额外流程，以及最终必须交付什么证据。模型升级后，这类约束也不容易与原生能力冲突。

收紧触发范围

Codex 支持显式调用和隐式调用。隐式调用依赖 description，因此描述应该先写最关键的使用场景，再写清边界：

---
name: release-check
description: Use only when preparing a production release for this repository. Verify the release checklist, migration rollback, version metadata, and deployment evidence. Do not use for ordinary development builds or local previews.
---

如果 Skill 成本较高、含外部副作用，或只在少数任务中使用，可以在 agents/openai.yaml 中关闭隐式调用：

policy:
  allow_implicit_invocation: false

之后用明确的 $release-check 调用。根据 OpenAI 的 Build skills 文档，这个开关的默认值是 true。

2026 年 7 月 15 日，我在 Codex CLI 0.144.4、gpt-5.6-sol、low 推理档位下做了隔离复测。探针 Skill 关闭隐式调用后，普通请求即使包含描述中的触发词，也没有加载 Skill；改用明确的 $skill 调用后，Skill 指令正常生效。这个测试只验证调用路由，不证明某套大型流程一定更快或更省 Token。

作用域也应该尽量小：个人在所有项目都会使用的 Skill 才放用户级目录；只服务某个仓库或模块的工作流，应放进对应的 .agents/skills。这样既减少无关候选项，也能让 Skill 与代码一起审查和演进。

一套可执行的精简方法

不要凭感觉一次性卸载全部 Skills。可以用下面的顺序做一次盘点：

  1. 从最近一个月的任务记录中列出实际使用过的 Skills；如果没有完整日志，就选几类能够复现的代表任务。
  2. 给每个 Skill 标记主要价值：领域知识、工具接入、仓库事实、安全边界、确定性脚本，还是通用流程。
  3. 删除已经与模型原生能力高度重叠、又没有项目事实的指令。
  4. 收紧 description，写清“什么时候使用”和“什么时候不要使用”。
  5. 将低频、高成本或高副作用 Skill 改成显式调用。
  6. 用同一模型、同一推理档位和同一组代表任务，分别测试启用与禁用后的结果。

对比时至少记录：任务是否完成、需要人工纠正几次、总耗时、是否执行了多余步骤、是否遗漏验收项，以及产品能提供的用量数据。单次成功或失败都不足以下结论；更有意义的是看 Skill 是否持续减少错误和人工干预。

完成一轮对比后，用三个问题决定是否保留：

  1. 去掉它以后，模型会缺少关键事实、工具、权限边界或验收标准吗？
  2. 它是否只在明确场景触发，而不是接管所有任务？
  3. 它带来的质量提升，是否大于额外的时间、用量和维护成本？

如果三个答案都是否定的，我会删除这个 Skill；如果只是触发范围有问题，就先改为项目级或显式调用。模型继续升级后，重新测试与原生能力重叠的部分即可，领域事实、工具接入和风险边界仍要单独维护。