我们用150个任务测试了30个skill，跑出7个反直觉结论

13.3%的请求被Skill“虹吸”：不该用时它却忍不住出手

• 在90条本应直接由裸模型回答的“no-skill”请求中，有12条被系统强行读取了某个Skill，过度调用率达到13.3%。
• 这种现象被称为“Skill虹吸”——当请求语义上贴近某个Skill的描述（如简单的短语生成、概念解释），即使任务本身很轻，系统仍会忍不住加载该Skill。
• 测试发现，Skill在“该用”时召回非常精准，但在“不该用”时缺乏克制，导致不必要的token和耗时浪费。

Token不升反降：这些Skill反而帮模型省了36%的消耗

• 整体看，装上Skill后token和耗时都有增加，但部分Skill却实现了“负倍率”：
  • fliggy-travel-planner、pdf-extract、market-research等Skill的token倍率低于1.0（最低0.64）。
  • 耗时倍率同样低于1.0的包括weather、zhihu-writer、chinese-baby-names。
• 原因在于这些Skill提供了明确的输出边界、清晰的“该做/不该做”规则，模型反而减少了无效探索，整体消耗下降。
• 相反，canvas-design-2、deep-research-pro等Skill位于“双高”区，需要更长上下文和更多工具调用。

质量分飙升0.9：装Skill到底值不值？数据说了算

• 平均质量分从无Skill时的3.80提升到极高配置时的4.70，净增+0.90。
• 实验遵循严格框架：先建立no-skill基线，再对比多种质量等级（low/xhigh）和不同Skill组合。
• 证明Skill带来的质量增益是真实且可量化的，尤其适合需要复杂多步推理的场景。

56%的Skill从未被激活：触发机制才是最大命门

• 参考Vercel评测数据：默认情况下，Skill有56%的case根本没被触发；只有加上明确调用指令，通过率才能从53%拉到79%。
• 相比之下，一份压缩过的AGENTS.md能在同样场景下达到100%触发。
• 根本问题在于Skill的description字段写得再好，系统仍可能因为语义模糊或上下文长度限制而“看不见”它，这成为当前最大痛点。

从“更长的prompt”到“Agent操作系统”：Skill的真正定位

• 过去人们常把Skill当作“更长的prompt”或“专题工作流”，但实际它属于一套分层Agent架构中的第四层：
  • 第一层：memory（自进化经验沉淀）
  • 第二层：CLAUDE.md（常驻项目级规则）
  • 第三层：nested CLAUDE.md（目录级局部约束）
  • 第四层：Skill（按需加载的专题流程）
  • 第五层：hooks（强制执行的确定性约束）
  • 第六层：eval（持续反馈回路）
• 正确做法：“凡是每个会话都应该知道的东西”放进常驻层，“多步流程、专题检查”放进Skill，“必须强制执行”放进hook。而非像过去一样把所有内容塞进CLAUDE.md导致上下文爆炸。