怎样才能写出好 skill？现在终于有数据了

怎样才能写出好 skill？现在终于有数据了

原文：*How do you write a good skill? There's actual data now.*

作者：Aparna Dhinakaran (@aparnadhinak)

发布时间：2026-07-07

互动数据：💬 7 🔁 25 ❤️ 257 🔖 535 👀 56612

---

上周在旧金山举行的 AI Engineer World's Fair 上，skill 是最热门的话题之一。Latent Space 的 AINews 也这么说；Paul Bakaus 主持了一场工作坊，专门讲解构建 skill 这门“黑魔法”；从 Anthropic 到 GitHub，厂商也开始把官方 skill 当作正式产品能力发布。但对大多数 AI 工程师来说，怎样写好 skill 一直更像民间经验：听演讲、看推文，再靠不断试错。

现在，这种局面可以结束了。今年 2 月发表的一篇论文，加上 6 月发表的两篇论文，终于用这个行业评估其他技术时的方式来测量 skill：运行任务、给结果打分、对比不同条件。结果是一套真正有数据支持的 skill 编写规则，其中不少结论相当反直觉。

什么才算 skill？

像往常一样，我们先确保大家谈论的是同一件事。本文所说的 skill，是一组按需加载的领域知识包，通常以文件夹形式存在，里面包含指令、术语，有时还包括脚本和其他资源。它处在一条“容器逐渐变丰富”的光谱上：从 prompt 到 tool，再到最近刚出现的 recipe（配方）。最后这个概念来自 Introspection 的 Roland Gavrilescu。他在 skill 之上又定义了一个新层级：“我们已经从 agent tool 走向 agent skill。Recipe 是更大的容器”，其中还会加入 eval、judge，以及让系统随时间持续改进的反馈信号。

SkillsBench 论文（arXiv:2602.12670，2026 年 2 月首次发表）给出了正式定义：skill 必须模块化、可复用，承载过程性指导，并能跨模型移植——最后这条事实证明相当棘手。System prompt 不满足这些条件，RAG 检索和 tool description 也不属于 skill。论文作者给了一个类比：模型是 CPU，运行框架（harness）是操作系统，skill 是应用程序。

那么，这三篇论文究竟发现了什么？好 skill 里应该放什么？核心有五点。

1. 不要让模型替自己编写 skill

让智能体直接替你写 skill，诱惑力很大。SkillsBench 就测试了这种做法：每项任务分别在三种条件下运行——不加载 skill、加载专家编写的 skill，以及加载模型为自己生成的 skill。专家编写的 skill 显著提高了通过率；模型自编的 skill 毫无帮助，平均得分甚至比无 skill 基线低 1.3 个百分点。作者的结论是：模型无法稳定地写出那些自己在执行时能从中受益的过程性知识。

失败方式很值得研究。模型要么写出空泛的步骤，比如只说“用 pandas 处理数据”，却不给任何实际 API 用法；要么从一开始就没有意识到任务需要专门知识。指望模型自己从经历中学会，也没有好结果。研究 skill 演化的 SkillComposer 论文（arXiv:2606.06079，2026 年 6 月）发现，不加控制地从此前解决同类问题的运行日志里提取 skill，会让编码表现跌到无 skill 基线以下。

这其实是 Bakaus 在 AIEWF 接受 Latent Space 采访时所说观点的数据版。他的设计 skill Impeccable 所做的，就是把模型似懂非懂的词，赋予精确的专业含义。如果只让一个没有辅助的模型把网页做得“更大胆”，它往往会堆上渐变和霓虹。Impeccable 则把“大胆”定义为明确的层级、尺度和果断的字体排版。“一个形容词背后如果没有实质，就只是个漂亮却空洞的词，”Bakaus 说，“你必须真正告诉 agent，你说的到底是什么意思。”专家词汇正是 skill 的价值，而现在数据表明，模型无法凭空为自己补上这部分知识。Gavrilescu 把限制说得更直白：如果没有人先把知识提炼出来，“你不可能简单地把所有东西都装进一个 Markdown 文件”。

所以，skill 得由你亲自写。接下来的问题是：该写多大？

2. 把 skill 写到面面俱到，并不是正路

SkillsBench 发现，只有两三个文件、主题聚焦的 skill，无论对比更大的文件包还是穷尽式文档，表现都更好。那些试图记录一切的“完整型”skill，反而会让通过率降到无 skill 基线以下。每一次都是：详细但范围明确，胜过百科全书式堆砌。

这与最优秀的 skill 作者已经采用的方法一致。Bakaus 说，设计 skill 的关键是找到“恰到好处的控制程度”：不是所有东西都应该放在 skill 这一抽象层里；小幅调整时，直接操作依然更快；探索阶段，开放式 prompt 仍然有用。只有当某种判断是模型会反复做错的，才值得把它编码进 skill，而不是把整本手册抄进去。

追求“完整”的本能，恰恰是敌人。你每增加一段文字，它都要和其他段落争夺模型的注意力；越过一个低得出人意料的阈值之后，新增内容不但不帮忙，反而开始拖累表现。把这个问题从单个 skill 放大到整个 skill 库，后果又会怎样？

3. 加载更多 skill，会让智能体变差

既然一个 skill 有帮助，把整个 skill 库全加载进来，岂不是更好？另一篇生成式 skill 组合论文——很容易混淆的是，它也叫 SkillComposer（arXiv:2606.32025，2026 年 6 月 30 日）——直接测试了这个问题。把完整的 196 个 skill 全塞进上下文，编码任务得分比只选择少量相关 skill 低 16 个百分点，同时还多消耗 23% 的输入 token。上下文泛滥同时输掉了准确率和成本。

有选择地加载，效果好得多。论文把选择 skill 看成一个组合问题：选哪些、选几个、按什么顺序。研究者训练了一个只有 390 万参数的小型 composer，它什么别的都不做，只输出一串排好顺序的 skill ID。用在 GPT-5.2-Codex 上时，它让通过率比无 skill 基线提高 23.1 个百分点，已经接近 oracle——也就是每次都能选中完美 skill 组合的理想选择器。Bakaus 则从实践侧走到了同一种架构：他在 Impeccable 内部加入路由，把任务导向相关指令，并把它比作专家混合模型（mixture-of-experts）。一边用 skill 外部的专用模型路由，一边在 skill 内部路由，但两者存在的理由相同：skill 的效果，取决于决定何时加载它的机制。

至此，规则已经很清楚：自己写、保持短小、不要写太多。但你的 skill 还得经得起实际运行环境的考验。

4. 你声称支持的每一种 harness，都要单独测试

skill 的格式可以移植——大家都接受 SKILL.md——但事实证明，skill 的行为并不能自动移植。SkillsBench 在多种运行框架上评估同一批 skill，发现不同“模型—harness”组合带来的提升介于 4.1 到 25.7 个百分点。Claude Code 对 skill 的利用率最高；Codex CLI 则经常直接忽略 skill：嘴上承认读到了 skill 的内容，动手时却还是按自己的方案实现。

这个结论不会让资深 skill 作者意外。Bakaus 指出，Codex 和 Claude 处理 subagent 与权限的方式并不相同，因此同时面向 Claude Code、Cursor、GitHub Copilot 和 Codex 的 skill，不能假定所有环境都有同样的能力。Impeccable 的做法是为每个目标 harness 发布不同的编译版本。如果某类模型有已知坏习惯，对应 skill 就会额外加入规则，明确禁止那些行为。可移植性不是兼容性字段里写一句声明就能获得的属性，而是必须针对每个目标工程化出来的结果。harness 和 skill 文件本身一样，都是 skill 行为的一部分。

自己写、保持短小、不要太多、每个 harness 单独发布。可 skill 究竟应该解决什么问题？

5. 把 skill 用在模型最薄弱的地方

SkillsBench 按领域测量了 skill 带来的提升：软件工程只有 4.5 个百分点，医疗健康则达到 51.9 个百分点，制造业也紧随其后。skill 在软件领域帮助最小，因为模型的预训练数据已经高度覆盖这一领域；在训练覆盖稀薄的领域，帮助最大。

SkillsBench 的作者还抓取了公开 skill 生态，发现全部 skill 中有 38% 都是软件开发 skill。社区正在最不需要 skill 的地方集中建设 skill。如果你要决定把编写 skill 的精力投到哪里，真正的套利空间在模型本来就不知道的领域：公司的内部规范、受监管行业、专业工作流，以及任何预训练覆盖不足的地方。通用编码工作流 skill 是一笔拥挤、优势很小的交易；编码“你们合规团队如何审查供应商合同”的 skill 则完全不同。

这五项发现都有一个共同前提：它们全都来自严谨测量。因此，你不能闭着眼照抄结论。

不测试，就不可能知道 skill 是否真的有效

上面每项结果都来自同一种方法，而且你自己也能运行：准备一组任务，在其他条件完全一致的前提下运行两遍，一遍加载 skill，一遍不加载。用同一套方式给两次结果打分，再看差值。就这么简单。这些论文采用的是自动化检查：脚本验证输出并直接返回通过或失败，不需要人工主观判断，因此对比结果可信，也可以重复。

这一步至关重要，因为 skill 真的可能造成伤害。在 SkillsBench 的 84 项任务中，有 16 项加载 skill 后的得分反而低于不加载。只凭肉眼看输出，你发现不了这种退步，因为加载 skill 的结果通常显得更专业，哪怕它实际上更不容易通过。只有“加载/不加载”的对照实验能把问题抓出来。

研究 skill 演化的那篇论文又往前走了一步，把同样的方法变成质量门槛：只有当某次 skill 修改让任务集通过率获得有意义的提升时，才接受这次改动。保留可测量地有效的东西，丢掉无效的东西。这样一来，skill 维护就不再靠感觉，而是一个闭环。这也正是 Gavrilescu 所说 recipe 概念的含义：eval 和反馈信号被包在 skill 外面，成为这件产物的一等组成部分。Arize AX 就能帮助你构建这类 eval。

当然，仍有一些空白。对于没有自动化检查的领域，该怎么评分？例如“设计是否变得更大胆”，并不存在一个天然的通过/失败标准。又该如何测量 Bakaus 在 AIEWF 提醒的另一种失败模式：如果所有人都使用同一个 skill 做前端设计，最后是不是所有作品都会长得一样？如果一个 skill 让所有用户的输出趋同，那么即使每份单独输出的得分都很好，它仍然失败了。这两个问题都需要新的评估方法，而整个行业尚未形成标准。

民间经验时代结束了

五个月前，想写好 skill，还得跟着散落各处的工作坊和演讲慢慢学。现在，我们终于有了一份由数万次实验支持的清单：亲自编写、保持短小、不要写太多、按 harness 测试、对准模型的薄弱领域，并用 eval 验证每一次改动。

做这些测量的人已经完成了最困难的部分。数据已经在你手里，现在把事情做对。