目录
一、先做对照：不要把模型本身的能力误认为 skill 的能力
二、存结果：不要只看当下，要让结果可以复查、比较和回归
三、优先用确定性检查：不要轻易把裁判权交给另一个模型
四、不要只测“答案”，还要测 skill 是否真的被使用
五、测试集要来自真实任务，而不是想象中的完美样例
六、把 eval 当成 skill 的说明书，而不是附属品
七、一个实用的 skill 评测框架
八、真正重要的不是分数，而是可解释的改进
参考资料
干货分享，感谢您的阅读！
现在很多团队都在给 AI agent 写 skill。所谓 skill，本质上不是一个玄学提示词，而是一组可复用的操作知识：它可能包含说明文档、脚本、模板、检查清单、示例文件、命令约定，甚至是一整套工作流。它的目标不是让模型“看起来更聪明”，而是让模型在某一类任务上更稳定、更可复现、更符合团队标准。
问题是：一个 skill 写出来之后，怎么判断它真的有用？
很多人的第一反应是：再找一个大模型来打分。让模型看两份输出，然后问它哪个更好。这个方法不是不能用，但它不应该是第一选择。因为你真正想测的，不是“另一个模型喜不喜欢这个答案”，而是这个 skill 是否让系统在真实任务里更可靠、更可控、更可回归。
一个好 skill 的评测，重点不是主观评价，而是工程化验证。
一、先做对照：不要把模型本身的能力误认为 skill 的能力
测 skill 最重要的第一步，是做对照实验。
同一道任务，至少要跑两遍：一遍不带 skill，一遍带 skill。其他条件尽可能保持一致，包括模型、输入、工具环境、上下文、温度、文件、依赖、运行入口。然后比较两组结果的差异。
原因很简单：大模型本身能力很强。很多任务，即使不给 skill，它也可能完成得不错。如果没有对照，你很容易把模型本来就会做的事情归功于 skill。
反过来，有些 skill 看起来写得很详细，但实际带上之后输出反而变差。它可能增加了无关约束，干扰了模型判断；也可能把任务流程写得过死，让模型在边界情况里无法灵活处理。已有关于 LLM 应用回归测试的研究也指出，prompt 或模型接口的变化可能引入不可预期的性能退化，因此仅凭一次“看起来不错”的结果并不可靠。
所以，评估 skill 的第一原则是：不要问“它写得好不好”，而要问“有它和没它相比，结果是否稳定变好”。
更具体地说，可以观察四类差异：
- 第一，任务是否完成。带 skill 后，成功率是否更高？
- 第二，路径是否正确。模型是否按照 skill 期望的流程调用工具、运行脚本、读取文件、生成产物？
- 第三，输出是否更符合规范。比如格式、命名、目录结构、字段、引用、测试结果是否满足要求。
- 第四，失败方式是否更可控。即使失败，它是否能暴露出清晰原因，而不是胡乱补全、静默跳过或编造结果。
OpenAI 关于 skill eval 的实践也强调，一个 eval 可以被理解为“prompt → 捕获运行过程与产物 → 一组检查项 → 可随时间比较的分数”，评估的不只是最终文本，还包括模型是否调用了 skill、是否执行了预期命令、是否产出了符合约定的文件。
这句话很关键：skill 不是只看最终答案，它还要看过程是否被约束住了。
二、存结果：不要只看当下，要让结果可以复查、比较和回归
第二件事，是把每次真实输出都保存下来。
很多团队做 eval 最大的问题，是只看控制台里的一次结果。今天看一眼，觉得不错，就改 skill；明天再看一眼，觉得也行，就继续改。最后没人知道到底是哪一次改动让质量变好，哪一次改动引入了退化。
正确做法是：每次评测都应当把真实运行结果落盘，并提交到代码库或至少进入可追踪的 artifact 存储。
这里的“结果”不只是最终回答。更理想的保存内容包括：
任务输入、是否启用 skill、模型版本、skill 版本、运行时间、工具调用记录、命令输出、生成文件、最终响应、检查项结果、失败原因。
这样做有三个价值。
- 第一，可以复查。后来发现某个 skill 有问题时，可以回到历史结果里看它从什么时候开始坏掉。
- 第二，可以比较。你可以比较不同 skill 版本、不同模型版本、不同提示词策略下的输出差异。
- 第三，可以回归。以后修改 skill 时，不是凭感觉重新试几条 case，而是跑一套固定测试集，看历史上通过的任务是否仍然通过。
这也是为什么 LLM eval 越来越像软件工程里的测试体系。OpenAI 的 eval 文档把 eval 定义为衡量模型性能的结构化测试，用来提升准确性、性能和可靠性；同时也强调测试数据需要代表真实使用场景。 生产级 LLM 应用的评估实践通常也会分成部署前的离线测试、CI/CD 中的回归测试，以及上线后的生产监控。
换句话说，skill eval 不应该是一次性的验收，而应该是持续运行的质量系统。
一个成熟的 skill 仓库，应该像代码仓库一样，有版本、有测试、有 fixture、有 golden output、有失败日志、有变更记录。每次修改 skill，都应该能回答一个问题：这次改动到底让哪些任务变好了，又让哪些任务变差了？
三、优先用确定性检查：不要轻易把裁判权交给另一个模型
第三件事，是尽量使用确定性检查项。
很多人喜欢用 LLM-as-judge，是因为它方便。让另一个模型判断输出是否好、是否完整、是否符合要求，看起来比写脚本省事。但问题在于，裁判本身也是模型，也有不稳定性、偏好、幻觉和上下文敏感性。
LLM-as-judge 适合处理那些难以程序化判断的语义问题，比如文章是否自然、解释是否充分、答案是否抓住了用户意图。但它不适合替代所有检查，更不适合作为第一层质量防线。
能写死的检查项，就不要交给模型判断。
例如：
输出必须是合法 JSON，可以用 JSON parser 检查。
字段必须包含title、summary、items，可以用 schema 检查。
生成的文件必须存在，可以用文件系统检查。
Python 脚本必须能运行，可以直接执行测试。
Markdown 必须包含指定标题，可以用字符串或正则检查。
引用数量不能少于 3 个，可以用规则统计。
表格列名必须固定，可以解析表格结构。
如果任务要求修改代码，就跑单元测试、lint、type check。
如果任务要求生成报告，就检查文件是否创建、章节是否齐全、数据是否来自指定来源。
Promptfoo 等评测工具也把 deterministic assertions 作为重要能力，支持 exact match、regex、JSON/XML 校验、schema 校验、相似度等多种确定性或半确定性检查方式。 相关研究也指出，在生产 LLM pipeline 中，开发者需要把任务要求转化为 assertions 或 guardrails，因为模型常常会在大规模输入下不完全遵循指令。
这背后有一个工程原则：先用机器能确定判断的规则拦住低级错误，再把真正需要语义判断的部分交给人或模型。
一个合理的评测分层通常是：
- 第一层，硬性检查。文件是否存在、格式是否合法、命令是否成功、字段是否齐全、禁止内容是否出现。
- 第二层，结构检查。输出是否符合模板、步骤是否完整、工具调用是否符合预期、是否遗漏关键部分。
- 第三层，语义检查。内容是否准确、解释是否清楚、方案是否合理。
- 第四层，人工抽检。对高价值、低频、复杂任务进行专家复核。
- LLM-as-judge 可以放在第三层，但不应该替代第一层和第二层。
四、不要只测“答案”，还要测 skill 是否真的被使用
评估 skill 时，还有一个常见误区：只看最后输出，不看模型有没有用 skill。
这会导致一个问题：有时候输出看起来对，但其实模型没有调用 skill，而是凭通用能力完成了任务。这样的结果对 skill 改进没有帮助。因为你无法知道 skill 的内容是否有效，也无法知道模型在什么情况下会忽略它。所以 skill eval 应该包含“过程检查”。
例如：
模型是否读取了 skill 指定的文件？
是否运行了 skill 要求的脚本？
是否使用了规定的模板？
是否遵循了指定目录结构？
是否调用了正确工具而不是绕过工具？
是否在失败时返回 skill 规定的错误信息？
如果一个 skill 的作用是教模型生成 Excel 文件，那么 eval 不应该只看最终答复里有没有说“已生成”。它应该检查真实文件是否存在，能否被打开，sheet 名是否正确，公式是否存在，格式是否符合规范。
如果一个 skill 的作用是教模型分析日志，那么 eval 不应该只看总结是否流畅。它应该检查模型是否读取了日志文件，是否提取了关键错误码，是否运行了分析脚本，是否把异常样本输出到指定位置。
skill 的价值不在于“给模型增加一段背景知识”，而在于把某类任务变成可执行、可检查、可复用的流程。
五、测试集要来自真实任务，而不是想象中的完美样例
很多 skill 在 demo 里很好用，一到真实场景就崩。原因通常不是 skill 完全没用，而是测试集太干净。
真实用户的任务往往有歧义、缺文件、格式混乱、目标不完整、输入过长、边界条件奇怪。一个 skill 如果只在理想样例上测试，很容易高估效果。
更好的测试集应该包括四类 case：
- 第一，典型任务。最常见、最希望 skill 稳定完成的场景。
- 第二，边界任务。输入不完整、格式有轻微问题、文件命名不标准、要求含糊。
- 第三，反例任务。不应该调用这个 skill 的任务，用来测试 skill 是否被误触发。
- 第四，回归任务。历史上出过 bug 的任务，每次修改 skill 都必须重跑。
尤其要重视反例。一个 skill 不仅要在该用的时候好用，也要在不该用的时候不乱用。否则它会污染其他任务，让模型过度套模板、过度运行脚本、过度引用流程。
这和 Anthropic 在 agent 工程实践中强调的“简单、可组合模式”是一致的：有效系统往往不是靠复杂框架堆出来，而是靠清晰边界、明确流程和可组合组件实现。 skill 也一样。一个好 skill 应该边界清楚，知道自己解决什么问题，也知道什么问题不该由它解决。
六、把 eval 当成 skill 的说明书，而不是附属品
很多人写 skill 时，先写说明文档，最后才想怎么测。更好的方式是反过来：写 skill 的同时写 eval。
因为 eval 会倒逼你把 skill 的目标说清楚。
如果你不知道怎么测一个 skill，往往说明你还没想清楚它到底要改善什么。是提高成功率？减少格式错误？缩短执行步骤？降低人工返工？增强安全性？减少幻觉？提高文件产物质量？不同目标对应完全不同的检查项。
一个好 skill 至少应该回答这些问题：
它适用于哪些任务？
不适用于哪些任务？
它要求模型采取哪些步骤？
哪些步骤是必须的，哪些是建议的？
它应该产生哪些可验证产物？
什么情况算成功？
什么情况算失败？
失败时应该如何暴露问题？
这些问题写清楚后，eval 其实就自然出现了。
因此，不要把 eval 当成 skill 写完之后的补充工作。eval 本身就是 skill 设计的一部分。没有 eval 的 skill，很难持续改进；没有 skill 的 eval，也很难形成可复用能力。
七、一个实用的 skill 评测框架
可以把一个 skill 的评测设计成下面这个闭环：
- 第一步，定义任务集。收集 20 到 100 个真实或高仿真的任务输入，覆盖典型、边界、反例、历史 bug。
- 第二步，建立对照组。每个任务分别跑 baseline 和 skill 两种条件。
- 第三步，捕获全过程。保存 prompt、trace、工具调用、生成文件、最终输出和环境信息。
- 第四步，执行确定性检查。优先用脚本检查格式、文件、字段、命令、schema、目录、引用、测试结果。
- 第五步，补充语义评估。对无法写死的质量维度，使用人工 rubric 或 LLM-as-judge，但要明确评分标准，并尽量固定裁判模型和提示词。
- 第六步，计算差异。不要只看平均分，要看成功率、失败类型、退化 case、误触发率、产物合规率。
- 第七步，进入回归。每次修改 skill 后自动重跑核心 case，确保改动没有破坏历史能力。
这套流程看起来比“找个模型打分”麻烦，但它带来的收益非常大：你终于可以把 skill 从经验主义变成工程资产。
八、真正重要的不是分数，而是可解释的改进
最后要强调一点：eval 的目的不是得到一个漂亮分数，而是帮助你知道下一步怎么改。
如果一个 skill 从 70 分变成 82 分，但你不知道为什么，那这个分数意义有限。
更有价值的是知道：
哪些 case 原来失败，现在成功了？
哪些 case 原来成功，现在失败了？
skill 的哪条规则产生了帮助？
哪条规则引入了干扰？
模型在哪些任务上没有调用 skill？
哪些检查项最常失败？
失败是因为 skill 不清楚，还是任务本身缺少信息？
这才是 eval 的真正作用。它不是裁判，而是诊断系统。
好的 skill 不是一次写出来的，而是在真实任务、保存结果、确定性检查、持续回归中打磨出来的。
所以，怎么测一个 skill 到底好不好用？
不是让另一个大模型随便打个分。
而是做三件事：
做对照，确认提升真的是 skill 带来的。
存结果，让每次运行都可以复查、比较和回归。
用确定性检查项，把能脚本化的判断都脚本化，把模型裁判留给真正需要语义判断的地方。
当你做到这三点，skill 就不再是一段“看起来很有道理”的提示词，而会变成一项可以维护、可以验证、可以演进的工程能力。
参考资料
- OpenAI：Testing Agent Skills Systematically with Evalshttps://developers.openai.com/blog/eval-skills?utm_source=chatgpt.com
重点参考：如何系统化测试 skill、如何验证 skill 是否被调用、如何保存运行产物、如何做回归。 - OpenAI：Evals Best Practiceshttps://developers.openai.com/learn/evals?utm_source=chatgpt.com
重点参考：eval 的基本设计方法、测试集构建、grader、持续优化流程。 - OpenAI API：Working with evalshttps://developers.openai.com/api/docs/guides/evals?utm_source=chatgpt.com
重点参考：如何以程序化方式配置和运行 eval，适合理解工程化评测流程。 - Promptfoo：Deterministic Metrics for LLM Output ValidationDeterministic Metrics for LLM Output Validation | Promptfoo
重点参考：确定性检查项，例如 exact match、regex、JSON/XML 校验、schema 校验等。 - Anthropic：Building Effective AI Agentshttps://www.anthropic.com/engineering/building-effective-agents?utm_source=chatgpt.com
重点参考：agent 系统设计原则，尤其是简单、可组合、可控的工作流思想。 - OAgents: An Empirical Study of Building Effective Agents[2506.15741] OAgents: An Empirical Study of Building Effective Agents
重点参考：agent 评测的可复现性问题、随机运行方差、标准化 evaluation protocol 的重要性。 - Skill-Mix: a Flexible and Expandable Family of Evaluations for AI Models[2310.17567] Skill-Mix: a Flexible and Expandable Family of Evaluations for AI models
重点参考：如何从“单一能力评测”转向“技能组合能力评测”，适合作为 skill eval 的理论补充。 - Beyond Rubrics: Exploration-Guided Evaluation Skills for Reward Modeling[2606.07040] Beyond Rubrics: Exploration-Guided Evaluation Skills for Reward Modeling
重点参考：rubric 与 evaluation skill 的关系，以及可复用评测技能在 judge 场景中的新研究方向。
我建议文章里重点引用前 5 个，后 3 个作为“延伸阅读”即可。