Skill 到底有没有用？一次没有提升的编程基准实验
Agent Skill 很容易给人一种确定感：把专家流程写进 SKILL.md，模型就会按照这套流程工作。真正跑进 benchmark 后，结果没有这么整齐。
通用任务上的公开实验报告了明显提升，软件工程任务的平均增益却很小。我们把自己的元 Skill 放进困难编程任务，也没有提高通过率，token 反而增加。
没有测到提升，不等于 Skill 一定无效；但“规则写得更完整”也不是有效性的证据。Skill 必须用同一模型、同一 Agent 和同一预算做配对实验，提升还要通过可信的验证器。
Skill 改变上下文，不改变权重
同一个模型在没有 Skill 和加入 Skill 时，可以写成：
是任务， 是模型输出， 是加入上下文的规程。两边使用同一组参数 。Skill 可能提高正确动作的概率，也可能因为内容太长、版本不符或规则冲突而干扰原任务。
因此，评价 Skill 不能只看“有 Skill 时通过了多少任务”。最基本的量是同条件下的差值：
模型、Agent harness、推理预算、任务版本和验证器都要保持一致。否则，分数变化可能来自别的变量。
两个公开 benchmark 给出了不同结果
SkillsBench 当前包含 87 个任务和 8 个领域，使用确定性验证器比较无 Skill 与策划 Skill。论文在 18 种模型和 Agent 配置上的汇总结果是：平均通过率从 33.9% 提高到 50.5%，增加 16.6 个百分点。SkillsBench 还观察到，模块不超过三个的聚焦 Skill 比大型、穷举式 Skill 表现更好。
SkillsBench 证明程序性知识在合适任务上可以产生明显增益，但不能据此外推所有 Skill 都有效，因为任务类型、Skill 质量和验证器共同决定结果。
SWE-Skills-Bench 专门测软件工程 Skill。该基准把 49 个公开 Skill 与固定提交的真实仓库配对，再用验收条件生成执行测试。结果明显更冷：39 个 Skill 没有提高通过率，平均增益只有 1.2%；token 开销最高增加 451%，三个 Skill 还因版本不匹配让性能下降，只有七个专用 Skill 获得有意义的提升。
两篇论文并不矛盾。SkillsBench 说明策划好的程序知识能帮助多领域任务；SWE-Skills-Bench 说明软件仓库对版本和上下文匹配更敏感。Skill 越通用，越可能只重复模型已经知道的常识；Skill 越具体，又越容易与另一个版本的项目冲突。
我们怎样跑困难编程任务
实验使用 GeniusHTX/SWE-Skills-Bench 的困难任务，保持模型和执行方式不变，比较无 Skill、原版 Skill 和修改后的元 Skill。
| 官方困难任务 | 无 Skill | 原版 Skill | 修改版 Skill |
|---|---|---|---|
| TDD Workflow | 3/14 | 3/14 | 3/14 |
| XLSX | 4/11 | 4/11 | 4/11 |
| Risk Metrics | 7/10 | 7/10 | 7/10 |
三组通过率完全相同。原版比基线多用 18.9% token，修改版仍多用 13.8%。后来拆出的通用元 Skill 在两组 Risk Metrics 上也没有提升：一组保持 13/13，token 增加 29.5%；另一组保持 7/10，token 增加 59.7%。
在这批任务上，Skill 没有改善成功率，只增加了上下文和执行成本。这是实验结果，不应改写成“模型理解得更深”或“流程更规范”。
Baseline 太强时，Skill 没有上升空间
Risk Metrics 的一组任务在无 Skill 时已经 13/13。通过率到达上限以后，即使 Skill 改善了中间过程，最终指标也观察不到提升。
这类任务不能回答 Skill 是否有效，只能说明 benchmark 在当前模型上过于容易。真正有区分度的数据应包含 baseline 稳定失败、Skill 又确实可能提供缺失知识的任务。
但“挑 baseline 失败的任务”也不能变成事后筛选。若先看结果，再只保留 Skill 成功的样本，提升会被人为放大。困难集应在实验前根据规则确定，或者把筛选过程完整报告出来。
验证器失败不能算模型失败
实验还暴露了评测环境的问题：
| 任务 | 已确认的环境干扰 | 对结论的影响 |
|---|---|---|
| XLSX | 官方 Python 镜像缺少旧版 openpyxl 依赖的 jdcal，部分代码与 Python 3.12 不兼容 | 依赖失败可能发生在候选代码运行以前 |
| TDD Workflow | Turborepo 验证器读取根目录 JSON5，而不是任务要求的子目录 turbo.json | 验证目标与任务契约不一致 |
| Risk Metrics | 一组环境没有安装 numpy，却运行 pyfolio 示例 | 环境缺失会制造与实现无关的失败 |
依赖缺失和验证目标错位会污染绝对分数，也会削弱 Skill Lift 的解释力。但环境问题不能反过来替 Skill 证明有效。三组条件得到相同通过率，当前可成立的结论仍然是：没有测到提升。
评测必须区分四种失败：模型没有生成正确实现、Agent 没有执行成功、环境缺少必要依赖、验证器检查了错误对象。把它们全部记成 0，得到的是一张混合故障表。
为什么通用元 Skill 很难提高仓库通过率
元 Skill 通常要求先确认目标、查证据、控制范围并运行测试。这些规则适合降低误报和越权，却不一定提供某个仓库任务缺少的具体知识。
如果 baseline 已经会读代码和跑测试，重复提醒不会产生新能力。反而因为上下文变长，模型需要在更多规则与任务信息之间分配注意力。SWE-Skills-Bench 中“大多数 Skill 零提升”和高 token 开销，与这次实验方向一致。
真正取得显著增益的往往是专用 Skill。专用 Skill 可能提供模型原本不知道的 API 版本、文件格式约束或项目特有工作流。此时 Skill 补的是任务所需信息，而不是再写一遍“认真分析、充分验证”。
通用编程集很难验证业务型 Skill。支付产品资格、资金期限和退款责任并不在 TDD 或 XLSX 任务里。一个 Skill 如果主要防止业务误判，应增加相应的业务决策任务和可执行验收，不能拿无关代码题证明它有效。
一套可信的 Skill 评测应满足什么
Skill 评测至少需要以下条件：
| 条件 | 原因 |
|---|---|
| 同模型、同 harness、同预算 | 隔离 Skill 变量 |
| 预先确定任务集 | 避免只挑 Skill 成功样本 |
| baseline 有失败空间 | 防止通过率天花板掩盖差异 |
| 验证器与任务契约一致 | 避免把环境故障算成能力失败 |
| 同时报通过率和 token | 防止用大量成本换取不可见收益 |
| 记录逐任务变化 | 区分普遍增益、少数特例和负迁移 |
若 Skill 的目标是减少误报，还要给误报计成本。只统计抓到多少候选问题，会鼓励 Agent 扩大报告；只有把错误修改、人工核查和重复 review 的代价写入指标，才能评价它是否真的改善了工程结果。
没有提升也是有效结论
这次实验没有证明元 Skill 能提高困难编程任务的通过率。实验同时表明，Skill 的效果依赖任务匹配，额外上下文不是免费的，验证器也可能成为主要误差源。
在业务和代码审查中继续使用 Skill，需要把 Skill 当作风险控制规程，而不是模型升级。Skill 能要求 Agent 查完整路径、尊重授权并允许“无需修改”，但这些价值仍要用对应任务验证。
最稳妥的报告方式很简单：在当前模型、当前任务和当前验证器下，通过率没有变化，token 成本上升。证据只支持到这里。
相关文章
- Coding Agent 分数上涨，测到的究竟是什么？：同一个模型换一套执行框架，Coding benchmark 为什么会明显上涨？本文拆开模型权重、训练轨迹、harness、推理预算和验证器各自贡献了什么。
- AI 为什么永远还能再找出一个 P0？：微信支付的 90 天券和 30 天资金冻结期，暴露了 AI 为什么会漏掉业务后果，又为什么能在代码审查里无限制造 P0。
- CLI Agent 的长任务为什么越做越不可靠：CLI Agent 在长任务中失控，不是模型参数逐步变差，而是当前上下文偏离了项目的可验证状态。缩短未验证跨度，比单纯扩大窗口更重要。