模型变强后，一批”教模型做基础动作”的 Skill 正在贬值，但流程约束与团队规范类 Skill 反而更值钱。问题不是要不要装，而是怎么选、怎么删。

技能膨胀的隐性成本

Skill 采用渐进式披露：Agent 默认只看到名称和描述，命中任务后才加载正文。按 Codex 的 Skills 文档，初始技能列表最多占上下文窗口的 2%，窗口大小不明时上限约 8000 字符；超出预算先压缩描述，继续加量则部分 Skill 直接移出列表——装到一百个时，Agent 看到的早已不是一百份完整描述。

成本不止字符数。描述写得宽，一个普通改动可能同时命中好几份 Skill，规则不一致时模型要临场判断执行哪套流程；再混入几份长期没维护的说明，任务跑偏后很难定位原因。上下文窗口变大也没消除问题：内容越杂，关键约束越容易被淹没。

评估一个技能值不值得引入

装之前先问四个问题：

  1. 这件事模型原本就会做吗？”先读项目、再写代码、最后跑测试”这类常规步骤，强模型已不需要教。
  2. 没有它时，我是否在同一个地方反复翻车？连续翻车才值得固化成流程。
  3. 它沉淀了脚本、模板、专业资料还是个人偏好？这类内容模型凭空猜不到。
  4. 规则过期后，我能不能及时发现并删掉？

一个实用的心智实验：先不装它跑一次任务，跑得好就不装；同一个问题反复出现，再把那一小段流程留下来。按这个标准，三类 Skill 值得长期保留：模型猜不到的个人偏好与固定产物、带专业判断和检查项的任务（安全审查、框架迁移）、能减少方向错误的流程（如 grilling 这类动手前持续追问的设计）——模型执行越快，走错方向的代价越大。

技能间的冲突与边界

很多 Skill 越写越大，是因为所有规则都往里塞。按作用范围分开能消解大半冲突：每轮都要遵守的项目约定进 AGENTS.md；特定任务的流程写成 Skill；耗时长的支线调查交给 Subagent；漏一次就事故的机械约束交给 Hook、CI、linter。规则文件管”项目一直怎么做”，Skill 管”某类任务怎么做”。另外，第三方 Skill 本身就是指令，安装前至少通读正文和附带脚本，确认没有越权操作。

定期清理机制

清理要有节奏和数据，不靠感觉。每季度做一次 audit：标记 30 天未触发的条目，先归档观察而非直接删除；保留核心 5～8 个，新项目一律从最小集起步、按需再加。有条件就记录触发日志，或对比启用/禁用后同类任务的成功率与 Token 消耗，用数据决定取舍。两条红线：合规与安全类 Skill 永不自动删；清理后跑一遍回归任务集，确认关键流程没有退化。

小结

  • Skill 有真实的上下文与命中成本，装多了描述会被压缩甚至挤出列表。
  • 引入标准：模型不会的、反复翻车的、沉淀了独有资产的才留下；按作用范围分层放置规则。
  • 季度审计加最小集起步，合规类永不自动删，清理后跑回归。