SWE-Skills-Bench：49个公开Skill里39个通过率提升为零，平均增益+1.2%、token开销涨451%，多数Skill其实没用？

SKILL 评测方法学 · 上下文工程 · 增益归因 · 工程治理

摘要与阅读导引

SWE-Skills-Bench 的公开评测结果给出了一个不太令人愉快的数字：在 49 个公开可获取的 Skill 中，有 39 个在软件工程任务上的通过率提升为零，全部 Skill 的平均增益约为 +1.2%，而 token 开销平均上涨约 451%。这组数据常被简化为“多数 Skill 没用”，但笔者认为，这个结论本身过于粗糙。真正值得追问的是：这 451% 的 token 增量花在了哪里，+1.2% 的增益来自哪几个 Skill，以及零增益的 39 个 Skill 究竟是能力无效，还是评测条件没有让它们的能力被激发出来。

本文确立一条贯穿全文的分析主线：Skill 的价值不等于“提示词写得好不好”，而等于“该 Skill 注入的信息增量，是否恰好落在当前模型与当前任务的能力缺口上”。围绕这条主线，文章依次讨论评测方法学与指标定义、Skill 生效的机制模型、公开数据与案例、横向对比与边界条件，最后给出一套可操作的 Skill 筛选、压缩与治理路径。文中涉及的具体数值，除注明来源者外，均为基于公开评测口径的整合或模拟测算，已在相应位置标注。

阅读建议：若关注工程落地，可直接跳到第五节“可操作路径”；若关注评测方法学，重点看第二、三节；若关注学术预判，重点看第六节。

目录

一、背景与问题定义：Skill 从“提示词资产”变成“评测对象”

1.1 Skill 的概念边界

在本文语境中，Skill 指一段可复用、可分发、以自然语言为主体、通常附带少量结构化元数据的指令单元，它被注入到 Agent 或代码助手的上下文中，用于约束任务执行流程、补充领域知识或规定输出格式。它与工具调用（tool use）的区别在于：Skill 不直接执行外部动作，而是改变模型的行为倾向；它与微调的区别在于：Skill 不改变权重，只改变推理时的条件分布。这个定义与 Anthropic 在 2025 年发布的 Agent Skills 工程实践文档中的表述基本一致，即 Skill 是“以文件形式组织的、可被按需加载的指令与资源集合”。

本文评述：把 Skill 定义为“条件分布的扰动项”而非“能力模块”，是理解后续所有评测结果的前提。如果读者把 Skill 想象成给模型装插件，就会对零增益感到意外；但如果把它理解为对输入分布的一次有偏采样，那么零增益甚至负增益都是可预期的——扰动未必落在决策边界附近。

1.2 为什么现在必须评测 Skill

2024 年以来，公开 Skill 仓库的数量增长很快。以 GitHub 上的 awesome-claude-skills、awesome-agent-skills 一类聚合仓库为例，其收录条目在一年内从数十条增长到数百条量级（来源：相关仓库 star 历史与提交记录，2025 年 11 月检索）。与此同时，模型厂商开始把 Skill 作为产品能力的一部分提供，例如 Claude Code 的 skills 目录机制、OpenAI 的 Agents SDK 中的 instructions 组织方式。Skill 从个人经验沉淀变成了可交易、可复用的工程资产，随之而来的问题是：这些资产的质量如何度量？

SWE-Skills-Bench 正是对这一问题的直接回应。它把软件工程任务作为评测域，把 Skill 作为自变量，把任务通过率与 token 消耗作为因变量，构造了一个“Skill 增益”的度量框架。笔者认为，这个框架的价值不在于给出“有用/没用”的二元判断，而在于它第一次把 Skill 的边际收益与边际成本放在同一张表上，使得“是否值得注入”成为一个可以计算的问题。

1.3 问题重述

据此，本文要回答的不是“Skill 有没有用”，而是三个更具体的问题：第一，在什么条件下 Skill 的增益可以被稳定观测到；第二，451% 的 token 开销增长中，有多少是必要的信息增量，有多少是冗余与格式开销；第三，工程团队应当用什么样的流程，把公开 Skill 转化为可验证的私有资产。这三个问题分别对应方法学、机制与工程三个层面，也是后文的结构骨架。

二、评测方法学：49、39、+1.2%、451% 这四个数字怎么来的

2.1 任务集与通过率定义

软件工程类评测通常以“问题描述 + 代码仓库快照 + 隐藏测试”的形式组织，通过率定义为隐藏测试全部通过的实例占比。这一范式可追溯到 SWE-bench（Jimenez 等，2023），其原始设定包含 2294 个来自 12 个 Python 仓库的 issue-PR 对。后续的 SWE-bench Verified（OpenAI，2024）从中筛选出 500 个人工确认可解的实例，以降低评测噪声。SWE-Skills-Bench 在任务组织上沿用了这一范式，但把变量从“模型”换成了“Skill 配置”，即在同一模型、同一任务集下比较注入与不注入 Skill 的通过率差异。

这里有一个容易被忽略的方法学细节：通过率是二值指标的均值，其方差对样本量高度敏感。若任务集规模为 N，基线通过率为 p，则单次评测的标准误约为 sqrt(p(1-p)/N)。当 N 在数百量级、p 在 0.3 附近时，标准误约为 2 个百分点。这意味着 +1.2% 的平均增益在统计上很可能不显著。本文评述：任何引用“平均增益 +1.2%”的讨论，都应当同时报告置信区间或显著性检验结果，否则这个数字只能作为描述性统计，不能作为因果结论。

2.2 token 开销的计量口径

451% 这个数字对应的是 token 消耗的相对增幅，即 (注入后 token 数 − 基线 token 数) / 基线 token 数。它的口径依赖三个选择：是否计入系统提示、是否计入多轮交互中的重复注入、是否计入失败重试的消耗。不同口径下同一批 Skill 的开销增幅可能相差一倍以上。为便于讨论，本文采用如下计量模型（模拟测算，用于说明量级关系）：

总开销 T = T_sys + Σ_i (n_i · L_skill_i) + T_task + T_retry
其中：
  T_sys     系统提示与工具定义开销
  n_i       Skill i 在轨迹中被注入的次数
  L_skill_i Skill i 的 token 长度
  T_task    任务本身的上下文（代码、日志、测试输出）
  T_retry   失败重试带来的额外消耗

相对增幅 = (T_with_skill − T_base) / T_base

从这个模型可以看出，451% 的增幅并不必然意味着 Skill 文本本身很长。如果 Skill 导致模型行为改变、进而触发更多轮工具调用与重试，T_retry 与 T_task 都会被放大，形成乘数效应。笔者认为，这是解读该数字最关键的一点：开销增长的主要来源可能不是“读 Skill”，而是“因为读了 Skill 而多做的事”。

2.3 零增益的判定与统计功效

“39 个 Skill 通过率提升为零”这一表述，严格说应理解为“在给定样本量与显著性水平下，未能检测到通过率差异”。这与“真实增益为零”不是同一命题。二者的区别正是统计功效（statistical power）问题。若某 Skill 的真实增益为 +3%，而评测样本量只够检测 +5% 以上的差异，那么它会被归入“零增益”，但这是评测的局限，不是 Skill 的失败。

本文评述：把“未检出”写成“为零”，在传播上更有冲击力，但在方法学上是不严谨的。工程团队在内部复现时，应当对候选 Skill 采用配对比较（同一任务、同一随机种子、仅切换 Skill 开关），并报告配对差异的置信区间。一个可操作的经验法则是：单个 Skill 的评测样本不少于 200 个任务实例，否则结论只能作为筛选信号，不能作为上线依据。

三、机制分析：Skill 为什么会在多数任务上失效

3.1 能力缺口假设

本文提出的核心机制假设是：Skill 的增益取决于它注入的信息是否落在模型当前的能力缺口上。形式化地，设任务 t 的最优策略为 π*(t)，模型在无 Skill 时的策略为 π0(t)，Skill s 诱导的策略为 πs(t)。增益可写为 E[1(πs 成功) − 1(π0 成功)]。当 π0 已经在大多数 t 上接近 π* 时，πs 很难进一步改进；当 π0 在某一子集上系统性偏离 π* 时，若 s 恰好编码了纠正该偏离的信息，增益才会显现。

这个假设可以解释一个常见现象：面向“代码风格”“提交信息格式”的 Skill 在强模型上增益接近零，因为强模型在这些维度上已接近饱和；而面向“特定测试框架的断言写法”“特定构建系统的坑”的 Skill 可能带来明显增益，因为这些是长尾知识，模型训练分布覆盖不足。本文评述：这意味着 Skill 的价值具有强烈的模型依赖性——同一个 Skill 在弱模型上可能有效，在强模型上则退化为噪声。任何跨模型复用的 Skill 清单，都应当标注其验证时的模型版本。

3.2 上下文干扰与注意力稀释

第二个机制是上下文干扰。Transformer 的注意力在长上下文中存在稀释效应，这一点在“Lost in the Middle”（Liu 等，2023）中有系统观察：关键信息位于上下文中部时，检索与利用效果显著低于首尾位置。Skill 通常被注入在系统提示或对话前部，看似位置有利，但它同时挤占了任务上下文的预算，使得代码、日志等关键证据被推向后部或被截断。

笔者认为，这解释了为什么部分 Skill 出现负增益：它们不仅没有补上能力缺口，反而把原本可用的证据挤出了有效窗口。在长仓库任务中，这种挤出效应尤为明显，因为任务本身就需要大量上下文。一个可检验的推论是：当任务上下文的基线占用超过模型窗口的 60% 时，注入 Skill 的净收益会转负。这个推论可以用配对实验验证，也是后文筛选流程中“上下文预算检查”步骤的依据。

3.3 指令冲突与过度约束

第三个机制是指令冲突。多个 Skill 同时注入时，可能出现规则互相矛盾的情况，例如一个 Skill 要求“先写测试再改代码”，另一个要求“最小化改动、优先修复”。模型在冲突指令下的行为不确定，往往表现为折中或忽略其中一条。更隐蔽的问题是过度约束：Skill 中大量“必须”“禁止”类表述会压缩模型的搜索空间，使其在需要探索的任务上过早收敛到次优解。

本文评述：这与提示工程中的“指令密度”问题同源。已有研究（如 2024 年关于 LLM 指令遵循的若干工作）表明，指令数量与遵循率之间并非单调关系，超过一定密度后遵循率下降。因此，Skill 的设计目标不应是“覆盖所有情况”，而应是“在最小 token 预算下覆盖最高频的失败模式”。这一原则在后文的压缩流程中会具体展开。

3.4 评测域与 Skill 域的错配

第四个机制是域错配。公开 Skill 中有相当比例面向写作、数据分析、产品文档等场景，被直接放入软件工程评测时，其编码的知识与任务需求无关。这类 Skill 的期望增益本就应该为零，把它们计入“无效”会低估 Skill 生态的整体质量。笔者认为，更合理的做法是先做域匹配过滤，再统计增益分布；否则“39/49 为零”这个比例会被大量无关样本稀释，失去诊断价值。

四、关键数据与案例：增益、开销与任务分布的交叉观察

4.1 增益分布的长尾特征

把 49 个 Skill 的增益按降序排列，典型形态是长尾分布：少数几个 Skill 贡献了几乎全部正增益，多数集中在零附近，少量为负。下表为基于公开评测口径的整合示意（模拟数据，用于展示分布形态，非逐条实测值）：

本文评述：长尾形态本身不是问题，问题在于公开 Skill 生态的默认预期是“装上就有用”。当实际分布是长尾时，无差别安装必然导致平均收益被大量零增益样本拉平，而成本却按安装数量线性甚至超线性增长。这解释了 +1.2% 与 451% 为何会同时出现。

4.2 开销结构拆解

按 2.2 节的模型拆解 451% 的构成，一个合理的估算区间是：Skill 文本直接注入占 15%–25%，因行为改变导致的工具调用与日志回读增加占 40%–55%，失败重试占 20%–30%（模拟测算，基于典型 Agent 轨迹长度分布）。这意味着即使把 Skill 文本压缩一半，总开销也只能下降约 10 个百分点，真正的杠杆在于减少无效的工具调用与重试。

笔者认为，这个拆解对工程实践有直接含义：优化 Skill 的重点不应放在“把提示词写短”，而应放在“让 Skill 减少不必要的探索”。一个能让模型少跑三轮测试的 Skill，即使文本长 500 token，净开销也可能是负的；反之，一个鼓励模型“全面检查”的 Skill，即使只有 100 token，也可能通过放大轨迹长度使总开销翻倍。

4.3 案例：一个正增益 Skill 与一个零增益 Skill 的对照

正增益案例（示意）：某 Skill 针对 Python 项目中 pytest fixture 的作用域陷阱给出三条判定规则，并附一个最小反例。在涉及 fixture 的 40 个任务实例上，基线通过 14 个，注入后通过 21 个，配对差异 +17.5 个百分点；token 增幅约 210%。其生效原因可归为：该知识点在训练分布中覆盖稀疏，且规则与反例直接对应失败模式。

零增益案例（示意）：某 Skill 要求“修改代码前先阅读相关文件、写出修改计划、再执行”。在 200 个实例上，通过率差异未检出（95% 置信区间跨零），token 增幅约 380%。本文评述：这类流程型 Skill 的问题不在于规则错误，而在于强模型已自发执行类似流程，额外指令只增加了输出长度，没有改变决策。它属于典型的“能力已饱和”情形。

4.4 与既有评测的交叉验证

SWE-bench 系列的历史数据提供了一个参照系：从 2023 年到 2025 年，前沿模型在该基准上的解决率从个位数提升到 70% 以上（来源：SWE-bench 官方排行榜及各模型技术报告）。这一趋势意味着，面向“通用编码能力”的 Skill 的边际价值在快速衰减，而面向“环境特定知识”的 Skill 仍有空间。本文评述：Skill 生态的演化方向应当是从“教模型怎么编程”转向“告诉模型这个仓库、这套工具链的特殊之处”，后者更接近检索增强，而非能力增强。

五、对比与局限：与 RAG、微调、Agent 框架的横向定位

5.1 三种知识注入路径的对比

本文评述：三者不是替代关系，而是成本结构不同的工具。Skill 的优势是零训练成本、可即时回滚；劣势是每次调用都占用上下文预算。因此，Skill 最适合承载“高频、短小、稳定”的规则，而把“低频、长尾、事实密集”的知识交给 RAG。把两者混用，往往导致上下文预算被静态文本占满，检索反而没有空间。

5.2 与 Agent 框架内置能力的重叠

当前主流 Agent 框架（如 LangGraph、AutoGen、OpenAI Agents SDK）已经内置了规划、反思、工具重试等机制。许多公开 Skill 实际上是在重复这些内置能力，例如“先分析再动手”“失败后总结原因”。当框架层已经实现这些行为时，Skill 层的同类指令属于冗余，其增益必然接近零，而开销照常发生。笔者认为，这是 39 个零增益 Skill 中最容易被忽视的一类：它们不是写错了，而是写在了错误的抽象层。

5.3 本类评测的固有局限

需要明确的是，以通过率为唯一指标的评测存在若干局限。第一，通过率不反映代码质量、可维护性与安全性，一个让测试通过但引入技术债的 Skill 会被误判为有效。第二，评测任务集与真实仓库分布存在差异，公开基准多来自开源项目，对私有代码库的代表性有限。第三，单轮评测无法捕捉 Skill 在多轮协作中的长期影响。本文评述：这些局限不否定评测的价值，但要求读者把结论限定在“该基准、该模型、该任务集”的范围内，避免过度外推。

六、可操作路径：Skill 的筛选、压缩与治理流程

6.1 五步筛选流程

基于前文的机制分析，笔者提出一套可直接落地的五步流程，用于把公开 Skill 转化为经过验证的私有资产。该流程的核心思想是“先证伪、再压缩、后固化”，即默认 Skill 无效，只有通过配对实验证明增益的才进入下一环节。

6.2 Skill 压缩的三条规则

压缩的目标不是缩短文本，而是提高单位 token 的信息密度。笔者总结三条可执行的规则：其一，把“必须/禁止”类规则改写为“判定条件 + 反例”，因为反例比禁令更容易被模型利用；其二，删除所有模型已默认执行的行为描述，只保留偏离默认的指令；其三，把长清单改为决策树，减少模型在多项规则间的权衡成本。经验上，这三条规则可将典型 Skill 的 token 长度压缩 40%–60%，而通过率不降。

本文评述：压缩过程本身也是一次有效性检验。如果一个 Skill 在压缩 50% 后增益消失，说明其增益来自冗余表述带来的“强调效应”，而非实质信息，这类 Skill 应当被淘汰而非保留。

6.3 治理：版本、归属与退役

Skill 一旦进入生产，就需要像代码一样治理。建议为每个 Skill 维护四项元数据：验证时的模型版本、验证任务集标识、实测增益与开销、负责人。当模型升级时，所有 Skill 自动进入“待复验”状态，未复验的不得继续注入。这一机制可以避免“模型变强后 Skill 变成噪声”却无人清理的常见问题。

此外，建议设置退役阈值：连续两个复验周期增益未检出，或 token 增幅超过 300% 且增益低于 2% 的 Skill，自动进入退役候选。本文评述：治理的价值在于把一次性的评测结论转化为持续的成本控制，否则今天有效的 Skill 会在半年后成为沉默的开销来源。

6.4 拓展资源

以下资源可用于深入理解评测方法与 Skill 工程实践，链接均在新窗口打开：

SWE-bench 官方站点与排行榜；SWE-bench 代码仓库；Anthropic Agent Skills 工程文档；Anthropic 公开 Skills 仓库；OpenAI Agents 开发指南；Lost in the Middle 论文；SWE-bench 相关技术讲解视频。

七、结论与展望

回到开篇的数字：39/49 零增益、平均 +1.2%、token 涨 451%。本文的分析表明，这三个数字并不矛盾，它们共同刻画了一个长尾分布——少数 Skill 贡献主要增益，多数 Skill 在能力已饱和或域不匹配的条件下退化为纯开销。把这一结果解读为“Skill 无用”是过度概括；把它解读为“评测有误”则是回避问题。更准确的结论是：Skill 的价值高度条件化，必须逐条验证，不能按清单批量安装。

展望未来，笔者认为有三个方向值得关注。第一，按需加载机制：把静态注入改为基于任务描述的动态检索，使 Skill 的上下文成本与实际使用挂钩。第二，Skill 与评测的闭环：让 Skill 携带其验证元数据，形成可追溯的质量信号。第三，面向环境知识的 Skill 化：把仓库特有的构建、测试、部署知识沉淀为 Skill，这类知识是模型训练分布难以覆盖的，也是当前增益最稳定的来源。

最后需要强调，本文引用的具体数值中，部分为公开评测口径下的整合或模拟测算，已在文中标注；读者在引用时应回到原始文献与原始评测报告，结合自身模型版本与任务集重新验证。Skill 工程仍处在方法学快速演化的阶段，任何结论都应视为当前时点的快照，而非终局判断。

参考文献与拓展资源

本文参考与检索的资料共计 62 项，其中 2023 年及以后发表的文献占比约 58%，涵盖软件工程基准、Agent 评测、上下文学习与提示工程四个方向。以下列出 9 项主要参考文献，供进一步查阅；其余条目包括 SWE-bench 各版本技术报告、Agent Skills 工程文档、LangGraph 与 AutoGen 官方文档、以及 2024–2025 年关于指令遵循与长上下文利用的若干预印本，因篇幅所限不逐一列出。

关于数据集预处理：本文涉及的评测任务集沿用 SWE-bench 系列的 issue-PR 对组织方式，任务实例经过去重、去除无法复现的用例、并统一测试执行环境；token 统计以模型分词器为准，多轮轨迹按累计输入输出 token 计；模拟测算部分基于典型 Agent 轨迹长度分布生成，仅用于说明量级关系，不代表任何单一系统的实测值。