删减 skill 指令前，先测试它教会了模型什么

Nikolay Petrov 将 skill 描述为可重复使用的指令包，它把反复使用的提示词转化为可移植的智能体能力。有些 skill 提供新知识，另一些主要引导可重复的流程。两者都可能有用，但这次演讲关注的是旨在教会模型原本不知道的内容的 skill。

一种基本评估方法是对比加载和不加载 skill 时的相同任务。Petrov 建议尽可能选择可以确定性检查的任务。他举例说，模型没有 skill 时五题答对三题，有 skill 时五题全对；对比还可以包括词元使用量和耗时。

即使 skill 提高了端到端评估成绩，随着模型演进或词元成本成为关注点，其内容仍可能需要重新审视。尝试每一种逐行组合成本很高，而凭直觉删除文本可能删掉模型真正需要的细节。

Petrov 建议借鉴 FActScore 中原子事实的思路，将 skill 拆成可以独立检查的小条目。每个条目配一个问题和预期答案。条目可以描述一般命题，也可以描述更具体的行为约定。

一个 skill 可能拆出 25 或 30 个条目。对于每个问题，团队分别运行加载和不加载 skill 的两组测试，再用模型评审或评审组判断答案。Petrov 建议在可行时使用来自不同模型家族的评审，并避免问题自身泄露答案。

测试可以不使用工具，以探测模型已经知道什么；也可以提供网页访问等工具，更贴近实际环境。这是两种不同的测量：外部信息可能改变模型在没有 skill 时能回答的内容。

两组结果构成四类情况。如果模型在有无 skill 时都能正确回答某个条目，说明在该测试环境下它已有足够知识回答这个问题。如果只有没有 skill 时才能答对，加入 skill 似乎损害了该条目的表现。

如果模型没有 skill 时答错、有 skill 时答对，这个条目就代表该测试中期望获得的增益。如果两种条件下都答错，相关主题仍可能重要，但当前 skill 的写法没有让受测模型成功回答。

Petrov 说，在团队考察的热门 skill 中，导致表现退化的条目很少：他指出展示的 Anthropic skill 中近 400 个条目只有一个这样的案例。他报告称，在一些规模更小、较不流行的 skill 中看到了更多此类情况；这一发现只针对受测 skill、模型和问题。

这些结果可以可视化映射到 skill 文本，展示哪些内容有帮助、已经知道、有害或仍然缺失。Petrov 提醒，评估单位是条目，不一定是一行：同一行或一句话可能包含结果不同的多个条目。

Petrov 说，在报告的实验中，测试 29 个 skill 的 Sonnet 和 Haiku 调用费用约为 14 美元，其中使用 Sonnet 作为评审。这是该次运行的费用，不是评估每个 skill 的通用价格。

评估还可以调整答案评分的严格程度。宽松检查关注是否表达了大致意思；严格检查则要求特定键名、参数值或准确步骤。知道一个概念不等于知道智能体必须使用的具体细节。

Petrov 报告的一次比较中，Opus 按一般理解标准答对约 70% 的 skill 条目，但按具体细节标准只答对 22%。他认为，这一差异说明即使前沿模型知道大致概念，也有理由保留精确数据和操作细节。

在展示的模型和 skill 集合中，小模型通常比大模型知道的内容更少，但不同 skill 的结果差异也很大。有些 skill 旨在引导行为，而不是提供新事实，因此新颖度低并不自动意味着有缺陷。

新颖度只是优化的初始方向，不能代替任务评估。Petrov 建议删除一些看似已知的信息，然后重新运行端到端评估。如果任务结果保持不变，精简后的 skill 可能节省词元和上下文；否则，看似冗余的材料可能仍有用。

实验使用了 Documate。Petrov 将其描述为比较智能体上下文的框架，可用于 skill、AGENTS.md 和 MCP 工具等内容。他说，该框架还支持评估上下文影响、路由、描述和命名，目标是根据测量结果而不是猜测来修改 skill。