2026上半年，skill数量井喷。很多公司在把所有的内部工作流程skill化，给大模型加上一个skill，模型就被期待能“立刻变专业”。
但当Skill数量从十几个膨胀到几百个，一个朴素的问题被反复提起：
装上Skill，是不是真就一定更强大？
带着这个疑问，我们在TRACE严选评测中做了系统化的实验。我们没有采用“看下载榜”或“跑一次给个分”的轻量做法，而是在统一的prompt、统一的裁判和统一的评测口径下，让每个Skill与“裸模型”（no-skill）跑完150 组任务级对比、30个Skill的成本与稳定性、107 条规范性问题、以及一轮跨模型推理强度的可迁移性测试。
关于TRACE严选评测的详细介绍，可以查看《3张图、5000字，认真聊聊什么才是好的skill》。
在持续评测Skill的过程中，我们整理出7个最值得关注的发现，并将相关实验数据、评测过程和机制解释集中公开。其中很多结论，出乎我们的意料。
01
有Skill不一定效果更好
我们装Skill的最初想法，是让大模型或通用Agent，获得更强的某方面的专业能力。但是在实验中，第一个被推翻的直觉，正是“装了skill就更好”。
在150组任务级对照中，Skill组共胜出62次（41.3%） ，no-skill组胜出55次（36.7%） ，平局33次（22.0%）。Skill组只是略占优势 ，远谈不上压倒性。
更关键的是，差异在Skill之间剧烈分化：
· 稳定带来正增益 的Skill包括：data-analysis、multi-search-engine、baoyu-cover-image 等；
·不如裸模型 的Skill：note-taker、fliggy-travel-planner、meeting-minutes等。
为什么会这样？把胜负样本数据一条条翻下来，规律其实很清晰：当Skill真正补充了模型裸能力之外的东西，比如一个清晰的输出结构、一组外部工具、一条受约束的工作流，或一份具体可交付的产物，它就是有用的；当 Skill 只是把模型本来就会的事情再“用 Markdown 重写一遍”时，它带来的更多是负担而非增益。
02
Skill 存在虹吸现象
我们在 Skill 路由实验中观察到一个现象，可以称为 “Skill 虹吸 ”：有些请求本来很轻，裸模型直接回答就够了，但只要语义上贴近某个 Skill，系统仍可能忍不住去读取这个 Skill。
为了区分两件事，我们设计了三类请求：
第一类是普通适用请求 ：用户意图很明确，本来就应该触发目标 Skill。
第二类是边界适用请求 ：用户请求仍然应该触发目标 Skill，但语义上更接近相邻 Skill，用来观察相近 Skill 是否会互相干扰。
第三类是本应no-skill的请求 ：任务很轻，理论上裸模型直接回答即可，不应该调用任何 Skill。
结果显示，系统在“该用 Skill”时表现很好：普通适用请求的正确触发率为 99.0%（891/900），边界适用请求也达到 96.0% （288/300）。这说明它不是普遍找不到正确 Skill。
真正的问题出现在“不该用 Skill”时：90 条本应 no-skill 的请求里，有 12 条仍读取了某个 Skill，过度调用率为 13.3% （12/90）。
两个例子很直观：
· 用户说：“不用上网，帮我想 5 个适合检索‘办公室绿植养护’的中文关键词组合。”
这本来只是关键词头脑风暴，但“检索”“关键词”把它吸进了搜索类 Skill（multi-search-engine）。
· 用户说：“把这句话改得更自然：我们通过更好的客户沟通来创造长期商业价值。”
这本来只是单句改写，但“客户沟通”“商业价值”让它看起来像营销任务，于是被吸进了营销类 Skill（marketing-skills）。
因此，“Skill 虹吸”不是路由系统乱触发，是一种更具体的偏差：该用 Skill 时，它很会召回；不该用Skill时，它有时不够克制 。 当请求只是简单改写、短语生成、概念解释或轻量模板时，只要出现 Skill description 中的相关领域词，就可能被吸进某个 Skill。
这种副作用会带来额外上下文和潜在 token / 时间成本，也会让本来一句话能完成的任务，被套进更重的专门工作流里。
03
多数Skill并不能节省token与时间
为了回答“装上 Skill 后是否更贵？”这个问题，我们定义了两个指标：
· token 倍率 = skill 组平均每任务 token / no-skill 组平均每任务 token；
· 耗时倍率 = skill 组平均每任务耗时 / no-skill 组平均每任务耗时。
1.0表示与no-skill持平，大于 1.0 即更贵。30 个 Skill 的全样本 实验结果是这样的：
也就是说，装上Skill后，token消耗平均多了48%，耗时平均长了19% 。
其中token的消耗上涨更明显。倍率最高的一批集中在多媒体生成、复杂产物组织、结构化交付场景：
耗时的分布相对温和，但同样存在“极端拉长”时长的尾部skill：
值得注意的是，Skill不总是更贵。fliggy-travel-planner、pdf-extract、market-research、word-docx、chinese-baby-names等Skill的token倍率反而低于1.0；fliggy-travel-planner、market-research、weather、zhihu-writer、chinese-baby-names的耗时倍率也低于1.0。原因也不难理解：当Skill给出了明确的流程、收束的输出边界、清晰的“该做 / 不该做” ，模型反而少做了无效探索，整体消耗下降。但就整体而言，装上 skill 后，token 和时间消耗都有所增加。
04
更耗token的Skill通常也更慢，但二者不是严格绑定
我们把每个 Skill 的 token 倍率和耗时倍率画到同一张散点图上，会看到一条相关斜线：Pearson r=0.73。
canvas-design-2、baoyu-cover-image、wechat-sticker-maker、logo-creator、deep-research-pro、multi-search-engine 都集中在右上角的“双高”区。这些 Skill 通常需要更长上下文、更多模型轮次、更频繁的工具调用，或更复杂的产物处理。
但有意思的是两组反例：
· token 高 / 耗时不高：fitness-coach、note-taker、weather、zhihu-writer。Skill 让模型读了更多上下文、写了更长回答，但没增加外部等待和文件处理。
· token 不高 / 耗时高：word-docx、wps。这类Skill的瓶颈不在语言模型，而在 Office/WPS工具链、脚本执行、文件格式处理，这些时间在token维度根本看不见。
05
规范性问题主要集中在依赖、边界与资源组织
TRACE中的C维度（结构规范）经常被误读为“文档好不好看”，实际上它更接近于“工程债”。
30个Skill的C维度复评共发现107 条规范性问题。
在依赖、维护一致性、资源组织、触发边界这四类里，都存在大量major级问题，意味着它们会直接影响Agent判断“什么时候用、怎么运行、需要什么工具、产物在哪里、文档与脚本是否一致”。
把这些问题串起来看，一个Skill可能效果不错，但只要依赖没写清、边界过宽、资源引用缺失或元数据漂移，后续复用、评测、自动化升级都会越来越脆弱。
06
稳定性风险来自工具链、长等待和反复修正
提起“Skill 不稳定”，第一反应往往是“模型答错了”。但合并历史运行风险与重复运行实验后，我们看到的画面正好相反——最常见的不稳定，不是来自模型本身。
近一半的Skill都至少在工具链、外部调用、长等待或反复修正中遇到过问题。这其实指向一个被低估的事实：
当 Skill 从“提示词”演变为“带工具、脚本、文件、外部服务和交付物的完整流程”，稳定性就不再是大模型的能力问题，而是一个工程链路问题。
越依赖多步骤工具链、外部 API、本地执行环境和长时间等待的 Skill，稳定性的暴露面就越大。
07
提高模型推理强度通常能改善Skill表现，但收益不均匀
最后一个发现来自P-M1（Portability，可迁移性实验，覆盖首批推荐的10 个Skill，每个Skill 选5个任务，分别在low与xhigh两档模型推理强度下运行，由顶级旗舰模型担任裁判。
整体看，收益是显著的 ：
· 平均质量分：low 3.80 → xhigh 4.70 ，平均提升 +0.90 ；
· 50个任务级对比中：xhigh 胜 39 ，low 胜 5 ，平 6 ；
· 10个Skill 中，9个 在xhigh下质量上升，仅pdf-extract基本持平。
但收益分布并不均匀 。对推理强度更敏感的，主要是这三类：
·需要处理隐藏约束 的（data-analysis：业务规则、口径细节）；
·需要细节核对、多步交付 的（logo-creator、baoyu-cover-image、canvas-design-2：视觉细节、布局合理性）；
·强创作类 的（language-learning、deep-research-pro：长文质量、推理深度）。
而像pdf-extract、xmind-generator这种流程明确、结构性强 的 Skill，本身就把“易错点”压缩进了固定流程，模型推理强度的变化反而拉不开差距。
需要强调一点：这一项实验不并入TRACE五维均分 ，只作为推荐风险的补充观察。但它给出了一个非常实用的指引。
08
给开发者的建议
基于以上实验结果，我们总结了几条给skill开发者的建议：
1. 先做 no-skill baseline，证明 Skill 真的有收益
2. 写清楚适用边界，避免 Skill 虹吸现象
3. 控制上下文和资源加载，避免 Skill 变成成本黑洞
4. 把隐性约束写进流程，而不是寄希望于模型自己想起
5. 关注工具链、文件和外部服务带来的工程稳定性
6. 持续记录误触发、失败样本和异常耗时，像产品一样迭代 Skill
09
写在最后
这些实验结论，有的颠覆了我们对于skill的认知。
关于Skill的未来，眼下被讨论得最多的是它能做什么——多一个 Skill，就像给模型多发一张技能卡。但这轮实验给出的提醒恰恰相反：在急着追问“还能加什么”之前，更值得先弄清楚它的技术边界在哪里。
这种边界感，对不同的人意味着不同的东西。对企业管理者，Skill是一种诱人的杠杆，仿佛给团队装上它，普通员工就能一夜之间产出资深员工的活儿；而对真正在使用它的人，Skill更像一件趁手或不趁手的工具，装错了反而要花时间替它收拾残局。
两种期待之间的落差，正是今天大量 Skill“看起来很会、用起来一般”的来源。弄清楚一个 Skill 到底补上了模型的哪块短板、又在哪里只是徒增成本，比再多上架几个Skill更重要。
而眼下的难处在于，关于Skill的客观定量分析还太少。它的魔法和大模型本身的魔法缠在一起，效率、效果、稳定性、成本，大多还是一个说不清的黑盒。整个行业更熟悉“它能做什么”的演示，却很少有人去深究“它到底值不值、什么时候反而碍事”。
期待越来越多人用客观审慎的眼光客观评估回“装上这个Skill 是不是真的更好”，它才算从魔法，慢慢变回一种可以被检验、被复用、被信任的方法。
这一天到来之前，克制地问一句“它真的需要吗”，或许比急着再装一个，更接近答案。
