如何评估 SKILL.md 的质量：完整的评估方法论

在构建 AI Agent 的过程中，Skill（技能）作为可复用的能力单元，其质量直接决定了 Agent 在实际场景中的表现。然而，如何判断一个 Skill 是否真正可靠、能否在生产环境中稳定运行，是每个开发者都需要面对的核心问题。多数开发者在完成 Skill 开发后，往往依赖主观感觉或简单测试来判断其质量，这种做法极易导致上线后出现各种意想不到的问题。本文将介绍一套完整、系统化的 Skill 评估方法论，帮助开发者从多个维度科学地评估 Skill 的质量，确保其在真实场景中具备良好的泛化能力。

三大核心评估维度

Skill 的核心价值在于被重复使用。在开发阶段，开发者和用户可能只测试了几个典型例子，但当 Skill 真正上线后，可能会被调用成千上万次。如果一个 Skill 只在开发时的几个例子上表现良好，但在面对新场景时就出现各种问题，那么这个 Skill 的实用价值就大打折扣。因此，评估 Skill 的核心目标应当是确保其泛化能力，而不是在特定例子上追求完美表现。这就要求我们建立一套科学的评估体系，从多个维度全面考察 Skill 的实际能力。

完整评估流程详解

评估 Skill 质量主要从三个维度进行： 第一，触发准确率（Trigger Accuracy）。Skill 的 description 字段决定了 AI 模型何时应该调用该技能。评估触发率需要准备两类测试用例：一类是应该触发的情况，包括不同的表达方式（正式口语化、简略表达）、用户没有明确提及 Skill 名称但明显需要它的场景、以及边缘用例；另一类是不应该触发的情况，包括关键词相似但实际需求不同、与其他 Skill 有竞争但应让位、以及表面相关但实际不需要该 Skill 的场景。值得注意的是，负例的设计应当避免过于明显，优秀的负例应该是“差一点就该触发”的模糊地带。 第二，输出质量（Output Quality）。这包括定量评估和定性评估两种方式。定量评估主要检查输出文件是否存在、格式是否正确、关键字段是否包含、数值是否在预期范围内等，这些可以通过脚本自动检查，结果是明确的通过或失败。定性评估则关注内容是否符合预期风格、细节是否到位等方面，这需要人工审查，因为很多质量维度难以量化。 第三，效率指标（Efficiency Metrics）。包括 Token 消耗（Sk

评估中的常见误区

测试用例的设计应当基于真实用户 prompt，而非抽象描述。好的测试用例应该包含完整的上下文信息、具体的细节，甚至允许存在一些不完美（如错别字）。例如，不要写“处理数据”这样抽象的 prompt，而应该写类似“我老板发了个 xlsx 文件在我下载文件夹里，叫 'Q4 sales final FINAL v2.xlsx'，她要我加一列显示利润率百分比，收入在 C 列，成本在 D 列”这样具体真实的场景描述。 Step 2：运行对照实验。每个测试用例需要运行两个版本：有 Skill 版本（正常使用）和基线版本（没有 Skill 或旧版 Skill），通过对比才能真正了解 Skill 带来的具体改进。 Step 3：收集反馈。让用户查看输出结果并给出反馈，一般来说，空反馈表示满意，有文字说明则表示存在问题。评估者应当重点关注有具体抱怨的用例，而不是试图让所有用例都达到完美。 Step 4：迭代改进。根据反馈优化 Skill，但关键是要追求泛化而非过拟合。如果用户说图表没有坐标轴标签，不要简单添加“必须给图表加坐标轴标签”的硬规则，而要理解为什么会遗漏，从根本上解决问题。在描

在评估过程中，开发者容易陷入几个常见陷阱： 陷阱一：测试用例过于简单。像“读取这个 PDF”这样的 prompt 不会触发 Skill，因为 AI 可以直接使用基础工具处理。应当测试复杂的、多步骤的、专业化的任务。 陷阱二：只关注成功的用例。失败的用例才是改进的方向，如果所有测试都通过，要么说明测试太简单，要么说明测试覆盖不够全面。 陷阱三：断言缺乏区分度。如果一个断言无论有没有 Skill 都能通过，那它就没有任何测试价值。好的断言应当能区分出 Skill 带来的实际改进。 陷阱四：忽视结果方差。同一个 prompt 多次运行可能产生不同结果，高方差意味着 Skill 不够稳定，需要排查原因。 以量化策略构建 Skill 为例，这是一个将模糊的投资想法转化为可执行量化策略的复杂 Skill。它的评估维度包括触发准确率（测试不同复杂度的正例和负例）、交互流程质量（检查是否一次只问一个问题、是否提供选项而非开放式问题、是否在用户模糊时给出合理默认值等）、策略配置完整性（验证生成的 YAML 配置是否包含 universe、signal、weighting、e

如有侵权，请联系删除。