目录一、先做对照不要把模型本身的能力误认为 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 就不再是一段“看起来很有道理”的提示词而会变成一项可以维护、可以验证、可以演进的工程能力。参考资料OpenAITesting Agent Skills Systematically with Evalshttps://developers.openai.com/blog/eval-skills?utm_sourcechatgpt.com重点参考如何系统化测试 skill、如何验证 skill 是否被调用、如何保存运行产物、如何做回归。OpenAIEvals Best Practiceshttps://developers.openai.com/learn/evals?utm_sourcechatgpt.com重点参考eval 的基本设计方法、测试集构建、grader、持续优化流程。OpenAI APIWorking with evalshttps://developers.openai.com/api/docs/guides/evals?utm_sourcechatgpt.com重点参考如何以程序化方式配置和运行 eval适合理解工程化评测流程。PromptfooDeterministic Metrics for LLM Output ValidationDeterministic Metrics for LLM Output Validation | Promptfoo重点参考确定性检查项例如 exact match、regex、JSON/XML 校验、schema 校验等。AnthropicBuilding Effective AI Agentshttps://www.anthropic.com/engineering/building-effective-agents?utm_sourcechatgpt.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 个作为“延伸阅读”即可。