导读 introduction
本文提出了一套8维度的Skill量化评估框架，通过元数据质量、执行引导清晰度、领域知识密度等指标对Skill进行打分评级，解决了Skill质量难以客观衡量的问题。为提升评估可靠性，设计了多模型交叉验证流程，并适配不同AI工具环境提供四种执行策略。该框架既能帮助开发者识别改进短板，也能辅助用户横向对比选择优质Skill，但需注意其侧重于文档与设计质量评估，并非运行时性能的完整度量。
00 为什么需要一把尺子？
Skill 是 Agent 能力的最小封装单元，它把领域知识、工作流程和工具集成打包成一个即插即用的模块，让通用 Agent 秒变领域专家。
现在所有人都在写 Skill、分享 Skill，但面临的问题是：
-
👷 你写的那个 Skill，真的够好吗？
-
🛜 网络上获取的 Skill 选哪一个更好？
能跑 和好用之间隔着十万八千里。
一个 Skill，description 写得太宽泛了，很可能 Agent 根本不会触发它；工作流缺少分支逻辑，可能碰到稍复杂的输入就翻车；明明需要附带脚本却硬塞在 Markdown 里，每次执行都重写一遍相同的代码。更麻烦的是，这些问题写的时候不一定能看出来，只有真正使用的时候才会暴露（也有可能不会暴露）。
基于此设定了一套 8 个维度的量化评估框架并实现了一个评估 Skill，从元数据质量、执行引导、领域知识密度到工作流完整性等，逐项打分、加权汇总，最终给出 Skill 的 S/A/B/C/D 等级评定。它能帮你审视自己的 Skill：哪里还有短板、该怎么改；也能横向对比多个 Skill：谁设计得更好、好在哪里。
审视自己的作品，它是改进路线图 ；对比他人的作品，它是选型决策工具。
01 八个维度，把"感觉"变成"分数"
我们要评估一个 Skill 的好坏，不能只靠感觉，必须要有一套可量化的标准。
1.1 八个评估维度分布在 Skill 生命周期的三个阶段中
下面的 8 个维度分布在一个 Skill 从被发现 到被执行完成的完整生命周期，分成三个评估阶段：
第一阶段：能不能被找到
一个 Skill 装好之后，Agent 在每次对话中只会读到它的 name 和 description。如果这几十个字写得不好，Skill 就根本不会被触发，后面写得再好也没用了。
D1. 元数据质量 评估的就是这个第一印象 。description 是否精准地描述了功能？是否包含了用户可能使用的关键词？最好的 description 甚至会写明不该在什么场景触发，防止误触发。
这是唯一一个决定 Skill 生死的维度。其他维度影响的是"好不好用"，D1 决定的是"有没有机会被用到"。
第二阶段：用起来顺不顺
Agent 决定触发后，会加载 SKILL.md 的完整内容。这时候考验的是：Agent 能不能顺畅地把任务执行完？
这一阶段有四个维度：
-
D2. 执行引导清晰度：Agent 加载了 Skill，但面对用户的具体输入，它知道该走哪条路吗？什么情况需要追问用户？什么情况该直接执行？什么操作不该做？好的 Skill 像一本清晰的操作手册，而不是一堆信息的堆砌；
-
D4. 工作流完整性 ：如果说 D2 是每一步怎么走 ，D4 就是整条路是否走得通。流程是否端到端？步骤之间的衔接是否顺畅？碰到异常（API 超时、文件下载失败）有没有处理方案？
-
D5. 输入输出清晰度：用户给什么、最终得到什么？这听起来是基本功，但很多 Skill 只写了中间步骤，用户第一次看完全不知道整个流程的起点和终点是什么；
-
D6. 资源利用 ：该用脚本的地方是不是用了脚本？该放参考文档的地方是不是放了？还是把所有东西都塞在一个巨大的 SKILL.md 里？好的资源结构遵循渐进式披露 （SKILL.md 保持精简，详细内容按需加载）；
第三阶段：值不值得存在
最后，跳出执行细节，从更高的视角审视这个 Skill 本身。
-
D3. 领域知识密度：这是 Skill 存在的根本理由。如果 Skill 里的内容，通用 Agent 不靠它也能做到，那它就没必要存在。好的 Skill 内嵌了难以获取的专业知识：私有 API 的调用方式、内部系统的数据模型、行业特定的最佳实践。
-
D7. 写作质量 ：SKILL.md 本质上是写给另一个 AI 看的技术文档。结构是否清晰？有没有冗余？Agent 能否快速扫读并抓到关键信息？
-
D8. 范围与聚焦：一个 Skill 应该做好一件事，而不是试图包揽一切。过宽的 Skill 什么都做不好，过窄的 Skill 不值得封装。
1.2 权重与评级
并非所有维度同等重要。我们按对 Skill 实际效果的影响程度分配权重：
每个维度具体的评分方式这里不赘述，有兴趣的同学可以从附录下载 Skill 查看。
加权求和后，总分映射为五个等级：
接下来，我们用这套框架实际评估一个 Skill，看看分数背后的含义。
02 拿自己开刀：一个真实的 Skill 评估
光看评分标准还是比较抽象，这里先拿一个真实的 Skill 跑一遍评估。
演示中使用的是百度内部 AI 工作助手 dodo。使用其他支持 Skill 的 AI 工具如 Claude Code、小龙虾等也都是可以的。
下面参与评估的这个 Skill 是我在内部另一篇实例中真实开发并已投入使用的：
评估得出的具体问题与建议摘录如下：
问题与建议
D1. 元数据质量 (3/10)：description 过于简略，缺少触发条件
影响：Agent 无法自动识别何时应触发此 Skill
建议：扩展 description，包含触发关键词和功能概述
D7. 写作质量 (7/10)：存在重复内容
影响：文档冗余，影响可读性
建议：删除重复的 SQL 示例（第 333-347 行），保留一处即可；合并重复的说明段落
总体评价
ip-bill 是一个功能完整、执行清晰的 Skill，适合自动化处理公网 IP 出账流程。主要优势在于：
工作流设计严谨，包含连通性检查和错误处理
领域知识丰富，API、数据库、BOS 等各环节都有详细说明
资源组织合理，脚本、参考文档、示例文件齐全
主要改进空间在于元数据描述 和文档精简。增强 description 中的触发条件描述，有助于 Agent 自动识别使用场景。
03 选谁好？两个同类 Skill 的正面对决
这里从 dodo 的可用 Skill 列表中随便选取了两个功能相近的 Skill 进行评估对比：
-
Skill A：workos-weekly
-
Skill B：subordinate-weekly-report
详细评估结果摘录如下：
各自优劣势
workos-weekly 更强的方面：
领域知识密度更高（OKR 关系、活跃空间、洞察分析等）
资源利用更丰富（references、examples、CHANGELOG）
工作流更复杂（9 步端到端流程）
subordinate-weekly-report 更强的方面：
元数据质量更高（场景路由表更清晰）
输入输出清晰度更高（每个 action 都有完整的输入输出示例）
场景覆盖更全面（6 种 action 覆盖多种查询场景）
subordinate-weekly-report 更弱的方面：
领域知识密度较低（专业概念较少）
资源利用不足（参考资料较少）
经验总结
两个 Skill 做得好的地方：
都有明确的触发条件和反向排除条件
都有清晰的执行引导和错误处理
都聚焦于单一场景，边界清晰
写作质量都很高，结构清晰易读
可借鉴的经验：
workos-weekly 的 HARD-GATE 设计值得借鉴，能明确强制规则
subordinate-weekly-report 的场景路由表设计优秀，能快速匹配用户意图
两个 Skill 都有详细的命令示例和输出示例，降低了 Agent 的理解成本
04 一个模型就够了？多模型交叉验证
前面的评估案例中，分数评定由一个模型完成。这就像一场考试只有一个阅卷老师，他可能偏严，也可能偏松，我们却无从判断。
实测中很明显的看到，不同模型对同一个 Skill 的评分存在些许差异。例如用 GLM-5.1 评估某 Skill，得到 7.8 / A，换成 Claude Opus 4.6 评估则为 6.5 / B。分数差了一个等级，但两个模型指出的核心问题却是趋同的。
这说明单模型评分的绝对值 不够可靠，但不同模型之间的共识是有价值的。
基于这个观察，我又给本 skill-evaluator 增加了多模型交叉验证机制：让多个模型独立评估、互相质疑、最终再由主模型完成仲裁，把一家之言升级为专家评审团。
4.1 评估流程
第一阶段：独立评估。
多个模型各自按 8 维度标准独立打分。
第二阶段：交叉互审。
所有独立评估完成后，每个模型会看到其他模型的评分。它们需要找出与自己分差 ≥ 2 分的维度，明确指出对方哪里评得不合理，并且必须引用 Skill 中的具体内容作为证据。例如：你 D3 给了 8 分，但这个 Skill 的领域知识只覆盖了 API 调用方式，缺少数据模型和决策逻辑的描述（见第 45-60 行），7 分以上要求要有丰富的专家知识，我认为 6 分更合理。
并且，在审查完对方之后，每个模型还要做自我修正：看了对方的论据后，我是否要调整自己的分数？这一步迫使模型认真对待对方的质疑，而不是固执己见。
第三阶段：仲裁综合。
由主模型（仲裁者）汇总所有独立评估和交叉互审的结果，对每个维度做出最终裁决。
4.2 三级共识机制
针对于每个评估维度，这里设计了一个三级共识机制，用于主模型执行仲裁：
在最终的评估报告中，每个维度都会标注共识度，让使用者能直接看出哪些分数是比较确定的，哪些是有争议的。
例如：
如果一个维度被标记为"仲裁"，说明这个维度的质量确实处于模糊地带，值得 Skill 作者重点关注。
4.3 当多模型不被支持时
不是所有环境都支持多模型调用，为此在这里我设计了一个兜底方案：单模型多视角评估。
在这个方案中，单一模型扮演三个不同的评审角色，依据评审风格分为：
三个视角评完后同样进行交叉审查和仲裁。
虽然本质上还是一个模型，但通过角色分化强制引入多样性：严格派可能在 D4 给 5 分，务实派同一维度给 8 分，这种分歧是有意义的。
05 四种执行策略的自动路由
不同的 AI 工具能力不同。有的工具（如 Claude Code）支持通过 subagent 同时调用自家多个模型，dodo 也支持这种模式调用 Claude 的 Opus 4.6、Sonnet 4.6、Haiku 4.5 模型。但如果想融合更多其他第三方模型或自定义评估模型列表目前还没有原生支持。所以这里在 Skill 中集成了千帆平台的模型能力，对于上述 Claude 系列之外的模型则通过千帆的能力支持。
5.1 四种策略
如果交叉验证只能在特定工具上跑，这个功能的适用范围就很窄。为了保证在各种 AI 工具及不同的触发场景中本 Skill 执行的兼容性，这里设计了四种执行策略：
从使用者的视角，只需要提供参与评审的模型：指定主模型（仲裁模型）和交叉评审模型。
策略路由逻辑根据模型列表自动分类：
-
全是工具原生模型走 A；
-
全是第三方走 B，两者都有走 A + B；
-
如果运行中出了问题自动降级到策略 C；
策略 B 依赖一个 Python 脚本来调用千帆 API。这个脚本只使用了 Python 标准库，不需要操心依赖之类的问题。脚本支持了多模型并行调用和自动重试。
5.2 模型组合与实际效果
这里测试了几种模型组合的评审效果：
当前 Skill 中已默认配置了模型，主模型为：当前 Agent 自身设置的模型；交叉互评模型为：ernie-5.0、sonnet、glm-5.1、minimax-m2.5。
06 三堂会审：多模型评估实践
上文中对我写的 ip-bill 这个 Skill 进行了单模型的评估，最终评估结果虽然有理有据，但是我们仍然无法确定其权威性，一家之言终归是片面的：这个模型的结果是偏严了还是偏松了？它指出的问题是最关键的还是恰好它注意到的？那些没被扣分的维度，是真的没问题，还是被这个模型忽略了？
用多模型交叉验证对 ip-bill 再评一次。这次由 ernie-5.0、sonnet 4.6、glm-5.1、minimax-m2.5 四个来自不同厂商的模型独立评估，互相质疑，最终由主模型 Claude Code Opus 4.6 仲裁出一份经过质证的结论。评估结果篇幅较长，这里我直接导出了一份报告文件：
07 评完之后怎么改？
拿到评估结果和改进建议后，可以继续让 AI 助手代劳。本文为了演示方便，拆分成了评估 + 优化，懒得看结果的话可以让 AI 助手直接一步处理分析 + 优化（这里演示的是单模型评估后优化，多模型的操作也是类似的）。
更多的用法实践可以自行扩展，例如多 Skill 的对比优化，互相学习其优点改进缺点等等，主要还是要依赖模型的分析能力。
08 写在最后
回到开头的两个问题：自己写的 Skill 够不够好？网上下载的选哪个？
现在你有了一套 8 维度的评估框架来回答它们，给 Skill 打分、找短板、做对比，把感觉还行 变成可量化的判断。并且可以选择通过多模型交叉评估来避免单模型一言堂的造成的评估局限，但是多模型也会增大 Token 的消耗和 Skill 的运行时间，具体使用哪种方式来评估可以由使用者自由选择。
随着更多人写 Skill、分享 Skill，我们可能需要更完善的评估手段：自动化的静态检查工具、基于实际执行数据的动态评分、社区驱动的 Skill 评级体系。这些都值得探索。
这套评估框架只是一把尺子，也有一定的局限性，它度量的是 Skill 的文档工程质量，而非运行时的全部真相。
知道它能量什么、不能量什么，才能用好它。
09 附录
本案例中的 Skill 地址