30个AI技能测试：150个任务揭示的7个反直觉结论

2026年上半年，Skill的数量迎来了井喷式增长。许多公司正忙着将内部工作流程“Skill化”，仿佛给大模型挂载一个Skill，就能立刻让它变得“专业”起来。

然而，当Skill的数量从十几个膨胀到几百个时，一个朴素的问题开始被反复提及：

装上Skill，真的就意味着更强大吗？

带着这个疑问，我们在TRACE严选评测中进行了一系列系统化的实验。我们没有采用“看下载榜”或“跑一次给个分”的轻量做法，而是设定了统一的prompt、统一的裁判和统一的评测标准，让每个Skill与“裸模型”（no-skill）在150组任务级对比、30个Skill的成本与稳定性测试、107条规范性审查，以及一轮跨模型推理强度的可迁移性测试中，进行全方位的较量。

在持续评测Skill的过程中，我们梳理出七个最值得关注的发现，并将相关的实验数据、评测过程和机制解释集中公开。其中不少结论，确实有些出人意料。

01 有Skill不一定效果更好

我们为模型安装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-tra vel-planner、meeting-minutes 等。

原因何在？逐条分析胜负样本数据后，规律其实相当清晰：当Skill真正补充了模型裸能力之外的东西——比如一个清晰的输出结构、一组外部工具、一条受约束的工作流，或一份具体可交付的产物——它才是有价值的。反之，如果Skill只是把模型本来就会的事情，再用Markdown格式“重写一遍”，那么它带来的往往是负担而非增益。

02 Skill 存在虹吸现象

在Skill路由实验中，我们观察到一个有趣的现象，可以称之为“Skill虹吸”：有些请求本身很轻量，裸模型直接回答就足够了，但只要其语义与某个Skill的描述沾边，系统就可能忍不住去调用它。

为了区分不同情况，我们设计了三类测试请求：

第一类是普通适用请求：用户意图明确，本就应触发目标Skill。

第二类是边界适用请求：请求仍应触发目标Skill，但语义上更接近其他相邻Skill，用于测试相近Skill是否会互相干扰。

第三类是本应no-skill的请求：任务非常简单，理论上裸模型直接处理即可，不应调用任何Skill。

结果显示，系统在“该用Skill”时表现良好：普通适用请求的正确触发率达到99.0%（891/900），边界适用请求也达到96.0%（288/300）。这说明路由系统并非普遍失灵。

真正的问题出现在“不该用Skill”时：在90条本应no-skill的请求中，仍有12条触发了某个Skill，过度调用率为13.3%（12/90）。

两个例子很能说明问题：

· 用户说：“不用上网，帮我想5个适合检索‘办公室绿植养护’的中文关键词组合。”这本质上只是一个关键词头脑风暴任务，但“检索”、“关键词”这些词把它“吸”进了搜索类Skill（multi-search-engine）。

· 用户说：“把这句话改得更自然：我们通过更好的客户沟通来创造长期商业价值。”这只是一个单句润色，但“客户沟通”、“商业价值”让它看起来像营销任务，于是被营销类Skill（marketing-skills）捕获。

因此，“Skill虹吸”并非路由系统胡乱触发，而是一种更具体的偏差：该用时召回率高，不该用时却不够克制。当请求只是简单改写、短语生成、概念解释或轻量模板填充时，只要出现了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。

当然，Skill并非总是更贵。像fliggy-tra vel-planner、pdf-extract、market-research等Skill的token倍率反而低于1.0；fliggy-tra vel-planner、market-research、weather等Skill的耗时倍率也低于1.0。原因不难理解：当Skill提供了明确的流程、收敛的输出边界、清晰的“该做/不该做”指令时，模型反而减少了无效的探索和试错，整体消耗得以降低。但就整体趋势而言，安装Skill确实带来了额外的资源开销。

04 更耗token的Skill通常也更慢，但二者并非严格绑定

将每个Skill的token倍率和耗时倍率绘制在同一张散点图上，可以看到一条明显的相关趋势线（Pearson r=0.73）。

canvas-design-2、baoyu-cover-image、wechat-sticker-maker等Skill集中在右上角的“双高”区域。这些Skill通常需要更长的上下文、更多的模型轮次、更频繁的工具调用，或更复杂的产物处理流程。

但有意思的是，也存在两组反例：

· token高 / 耗时不高：例如fitness-coach、note-taker。这些Skill让模型读取了更多上下文、输出了更长文本，但并未显著增加外部等待或文件处理时间。

· token不高 / 耗时高：例如word-docx、wps。这类Skill的瓶颈不在于语言模型本身，而在于Office/WPS工具链调用、脚本执行、文件格式处理等环节，这些耗时在token维度上是“隐形”的。

05 规范性问题主要集中在依赖、边界与资源组织

TRACE评测中的C维度（结构规范）常被误解为“文档是否美观”，实际上它更接近“技术债务”的范畴。

在对30个Skill的C维度复评中，共发现了107条规范性问题。

在依赖管理、维护一致性、资源组织、触发边界这四类问题中，存在大量“主要”级别的问题。这意味着它们会直接影响Agent判断“何时使用、如何运行、需要什么工具、产物在哪里、文档与脚本是否一致”。

综合来看，一个Skill可能效果不错，但只要存在依赖未写清、边界过宽、资源引用缺失或元数据漂移等问题，其后续的复用、评测和自动化升级都会变得越来越脆弱。

06 稳定性风险来自工具链、长等待和反复修正

提起“Skill不稳定”，第一反应往往是“模型答错了”。但合并历史运行风险与重复运行实验数据后，我们发现情况恰恰相反——最常见的不稳定因素，并非来自模型本身。

近一半的Skill都至少在工具链、外部调用、长时间等待或反复修正中遇到过问题。这指向一个被低估的事实：

当Skill从“提示词”演变为“包含工具、脚本、文件、外部服务和交付物的完整流程”时，其稳定性就不再仅仅是大模型的能力问题，而是一个系统工程链路问题。

越是依赖多步骤工具链、外部API、本地执行环境和长时间等待的Skill，其稳定性的暴露面就越大。

07 提高模型推理强度通常能改善Skill表现，但收益不均匀

最后一个发现来自P-M1（可迁移性）实验。该实验覆盖了首批推荐的10个Skill，每个Skill选取5个任务，分别在“低”和“极高”两档模型推理强度下运行，并由顶级旗舰模型担任裁判。

从整体看，提升推理强度的收益是显著的：

· 平均质量分从“低”档的3.80提升至“极高”档的4.70，平均提升+0.90；

· 50个任务级对比中，“极高”档胜出39次，“低”档胜出5次，平局6次；

· 10个Skill中，有9个在“极高”档下质量上升，仅pdf-extract基本持平。

但收益的分布并不均匀。对推理强度更敏感的，主要是以下三类Skill：

· 需要处理隐藏约束的（如data-analysis：涉及业务规则、口径细节）；

· 需要细节核对、多步交付的（如logo-creator、baoyu-cover-image：涉及视觉细节、布局合理性）；

· 强创作类的（如language-learning、deep-research-pro：涉及长文质量、推理深度）。

而像pdf-extract、xmind-generator这类流程明确、结构性强的Skill，本身已将“易错点”压缩进了固定流程，模型推理强度的变化反而难以拉开差距。

需要强调的是，这项实验的结论不并入TRACE五维均分，仅作为评估推荐风险的补充观察。但它提供了一个非常实用的指引。

08 给开发者的建议

基于以上实验结果，我们为Skill开发者总结了几条建议：

1. 先建立no-skill基线，证明Skill确实能带来增益。

2. 清晰定义适用边界，避免“Skill虹吸”现象。

3. 控制上下文和资源加载，防止Skill成为成本黑洞。

4. 将隐性约束明确写入流程，而非寄希望于模型自行领悟。

5. 关注工具链、文件和外部服务引入的工程稳定性风险。

6. 持续记录误触发、失败样本和异常耗时，像迭代产品一样迭代Skill。

09 写在最后

这些实验结论，部分碘伏了我们对于Skill的固有认知。

当前关于Skill未来的讨论，大多聚焦于“它能做什么”——多一个Skill，就像给模型多装备一张技能卡。但这轮实验给出的提醒恰恰相反：在急切追问“还能加什么”之前，更值得先弄清楚它的技术边界究竟在哪里。

这种边界感，对不同角色意味着不同的东西。对企业管理者而言，Skill是一种诱人的杠杆，仿佛装上它，普通团队就能立刻产出资深专家的成果；而对实际使用者来说，Skill更像一件趁手或不趁手的工具，选错了反而要花额外时间收拾残局。

两种期待之间的落差，正是当下大量Skill“看起来炫酷，用起来一般”的根源。弄清楚一个Skill究竟补上了模型的哪块短板，又在何处只是徒增成本，远比盲目上架更多Skill来得重要。

而当前的困境在于，关于Skill的客观定量分析仍然太少。它的“魔法”与大模型本身的“魔法”纠缠在一起，效率、效果、稳定性、成本，大多还是一个难以说清的黑盒。整个行业更熟悉“它能做什么”的演示，却鲜少有人深究“它到底值不值、什么时候反而会碍事”。

只有当越来越多人开始用客观审慎的眼光，回头审视“装上这个Skill是不是真的更好”时，它才能从一种“魔法”，逐渐转变为一种可以被检验、被复用、被信任的“方法”。

在那一天到来之前，克制地问一句“真的需要它吗”，或许比急着再安装一个，更接近问题的答案。

来源：互联网