如何评估你写的 SKILL.md 质量？一套完整的 Eval 方法论

在AI Agent的开发实践中，Skill作为实现特定功能的核心单元，其质量直接决定了Agent的实际表现。然而，很多开发者在完成Skill编写后，往往仅凭几个测试样例就匆匆上线，这种做法存在极大风险。由于Skill的价值在于被重复使用——在开发阶段可能只测试几十个用例，但上线后可能被调用成千上万次——如果Skill在特定例子上表现良好却无法泛化到新场景，那么整个Agent系统的可靠性都将受到严重影响。

概述

因此，评估Skill的核心目标应该是：确保Skill的泛化能力，而不是在特定例子上过拟合。这要求我们建立一套系统化的评估方法论，从多个维度全面审视Skill的表现。

评估的三个核心维度

第一个维度是触发准确率（Trigger Accuracy）。Skill的description字段决定了模型何时应该调用它，这直接影响到Skill能否被正确触达。评估触发率需要精心准备两类测试用例：应该触发的用例应覆盖不同的表达方式，包括正式表述、口语化表达、简略描述，以及用户没有明确提到Skill名称但明显需要它的场景；不应该触发的用例则需要设计那些关键词相似但实际需求不同的场景、与其他Skill存在竞争关系但应让步的场景，以及表面相关但实际不需要该Skill的情况。值得注意的是，负例的设计要避免过于明显，比如用"写个斐波那契函数"作为PDF Skill的负例就没有任何测试价值，因为它太容易被区分。真正有效的负例应该是"差一点就该触发"的边缘场景。

第二个维度是输出质量（Output Quality），这需要结合定量和定性两种评估方式。定量评估主要通过断言（Assertions）检查输出文件是否存在、格式是否正确、关键字段是否包含、数值是否在预期范围内等，这些可以用脚本自动检查，结果是pass或fail，没有主观性。定性评估则需要人工审查内容是否符合预期风格、细节是否到位等无法量化的方面。

完整的评估流程应该遵循以下步骤：首先，准备真实详细的测试用例，这些prompt应该包含上下文、细节，甚至偶尔的错别字；其次，为每个测试用例跑两个版本进行对照实验，分别是有Skill版本和基线版本（没有Skill或旧版Skill），这样才能准确衡量Skill带来的改进；然后，收集用户反馈时要注意，空反馈通常意味着满意，而有文字反馈则说明存在问题，应该重点关注具体的抱怨而非追求所有用例都完美；最后，根据反馈迭代改进时要注意泛化而非过拟合——当用户指出某个问题时，应该理解背后的根本原因并从源头解决，而不是简单地添加硬性规则。

第三个维度是效率指标（Efficiency Metrics），包括Token消耗、执行时间和步骤数量。这些指标帮助我们发现Skill中拖后腿的部分——如果模型每次都花大量时间做同一件事，说明这部分应该被抽取成脚本而非依赖模型推理。

在评估过程中还需要警惕几个常见陷阱：测试用例设计过于简单导致无法真正检验Skill能力；只关注成功的用例而忽视失败用例才是改进方向；断言缺乏区分度导致无论是否有Skill都能通过；以及忽视结果方差——同一prompt多次运行可能产生不同结果，高方差意味着Skill不稳定。

如有侵权，请联系删除。