Skill 评测体系：从格式检查到真实任务验证的五层证据链

2026/8/4 11:05:09 拓冰建站浏览量

Skill 质量不能只看格式合规，需要从规范、语义、工程关系、动态效果到交付闭环建立证据链。

导语

一个 Skill 能被解析、格式合规、链接没有失效，是否就说明它值得被 Agent 使用？

答案通常是否定的。

它可能写得很规范，却帮不上真实任务；也可能单独看没有问题，放进仓库后和另一个 Skill 抢同一个触发意图。更麻烦的是，有些 Skill 被调用后不但没有改善结果，反而让 Agent 消耗更多上下文、走更多弯路。

所以，Skill 质量不能只看一个分数。它更像一条证据链：先确认资产能被稳定读取，再判断 Agent 是否能正确理解和执行，接着检查它和其他能力的关系，最后用真实任务验证效果，并把发现的问题纳入修复与交付闭环。

图：Skill 评测从静态规范走向真实任务验证和修复复验

为什么需要分层评测

AI 编程里的上下文资产正在变多。Skill、Agent、参考资料、项目规则、脚本说明、调试流程，都可能进入仓库，成为模型执行任务前会读取的材料。

资产变多以后，问题不再只是“有没有文档”。真正的瓶颈会变成这些：

· 哪份知识对当前目录生效。
· 哪个 Skill 应该在当前请求下触发。
· 两个能力描述相似时，Agent 该选谁。
· 文档说得很完整，但真实任务里是否有用。
· 发现问题后，能不能可信地修复并复验。

目录共置和版本管理只能让上下文“可治理”，不能证明上下文“质量足够”。一个结构正确的 Skill 仍可能语义含糊、边界混乱、触发误伤，或者在真实任务中没有增益。

因此，评测体系要拆成五层：

图：Skill 评测体系的五层证据链

这五层不是从低到高互相替代，而是分别回答不同问题。格式合规不能证明任务有效，动态成功也不能抵消安全风险。

第一层：规范质量

规范检查处理的是确定性问题。它不需要大模型判断，也不该依赖主观评价。

这一层要回答的问题很朴素：Skill 能不能被稳定读取，依赖能不能找到，基本信息是否完整，是否存在明显风险。

常见检查项包括：

检查对象	典型问题
元信息	name、description、触发说明缺失或不可解析
引用资料	必读 reference 不存在、路径错误、循环引用
执行依赖	脚本、环境变量、输出位置没有说明
可迁移性	写死本机路径、依赖私人目录
安全风险	凭证、邮箱、内网地址、敏感路径直接暴露
输出契约	没说明产物格式、写入位置或失败处理

规范层适合放进 CI。因为它判断明确、成本低、可重复，适合做准入门禁。

但它只能证明“资产没有明显坏掉”。一个 description 写得很完整的 Skill，仍可能让 Agent 在错误场景下触发；一个 reference 都存在的 Skill，也可能缺少关键边界条件。

所以规范检查是地基，不是质量结论。

第二层：语义质量

语义质量关注的是确定性规则难以表达的问题：内容是否完整，触发边界是否清楚，错误恢复是否可执行，输出是否足以指导 Agent 行动。

如果让模型自由评价，结果会很不稳定。一次说“基本完整”，另一次可能只给一段空泛建议。为了让评测进入工程治理，需要把开放式判断收束到 Rubric 里。

Rubric Judge 的核心思想是：模型不负责发明评价标准，只负责在给定标准下阅读 Skill、参考资料和必要实现，输出结构化评分、理由、证据和事实缺口。

一个简单评分键可以这样定义：

score:0: 不及格，缺失或损坏，无法发布1: 较差，存在但不足，需要大量修改2: 合格，可用但有明显缺陷3: 良好，稳定，有少量问题4: 优秀，无需改进

单条 Rubric 不应该只写“完整性”，还要告诉 Judge 观察什么：

### 完整性
是否覆盖该领域的常用任务、必要边界和失败处理。- 4：覆盖常用操作和主要边界，用户很少需要跳出 Skill。
- 3：覆盖核心操作，缺少少量高级或低频场景。
- 2：覆盖基本操作，但遗漏明显预期能力。
- 1：只覆盖领域的一小部分。
- 0：内容不可用或只是占位。

为了减少重复扣分，可以把判据投影到几个互斥的工程质量域：

工程质量域	关注点
意图与适用边界	完整性、适用场景、可发现性、触发精度
执行正确性与恢复	正确性、容错、幂等、撤销、失败恢复
Agent 可用性与可观测性	错误报告、反馈质量、渐进式披露、可学习性
上下文与执行效率	token 成本、工具调用成本、执行效率
安全与变更保护	凭证处理、输入验证、数据安全、高风险动作保护
工程演进与组合	模块化、可测试性、可维护性、可组合性

这一步的价值不是给 Skill 打一个好看的分数，而是把“哪里不好”变成可复核的证据。

例如，“完整性 2/4”本身没有行动价值。更有用的诊断应该写成：当前 Skill 已说明依赖安装，但缺少版本冲突处理和失败恢复；现有 reference 也无法证明遇到冲突时应采用哪种策略。

分数必须绑定证据，低分必须说明从当前状态提升到下一档需要补什么。

第三层：工程关系质量

单体评测看不见系统关系。

每个 Skill 单独看都合格，放在一个项目里仍可能互相打架。常见问题有五类：

关系问题	表现
身份冲突	两个 Skill 使用相同或难以区分的身份
意图竞争	多个 Skill 声称处理相似请求，Agent 无法稳定选择
能力重复	不同 Skill 实现近似能力，却没有上下层或替代关系
目录过度拆分	一个完整任务被拆成大量只能固定顺序调用的小 Skill
层级错置	通用能力放在叶子目录，或模块专属能力出现在全局入口

项目级分析最容易犯的错误，是把启发式信号直接当成结论。

比如两个 Skill 都包含“日志”这个触发词，不代表它们一定冲突。一个可能负责“如何记录日志”，另一个负责“如何拉取日志”。触发词重叠只是候选信号，不能直接判断为意图竞争。

更稳的做法是两阶段：

图：工程关系质量需要识别能力重叠与触发冲突

确定性层负责高召回和可追溯，比如名称相似度、触发词重叠、目录位置、引用关系、输出动作。Judge 只处理已经缩小的候选集合，判断候选到底是冲突、重复、层级错置，还是只是领域词相同。

这能避免两个极端：完全靠规则会误报很多，完全让模型全量两两比较又昂贵、不稳定。

工程关系层回答的是：项目里的 Skill 是否构成一个健康的能力系统。

第四层：动态效果

静态文档写得再合理，也可能在真实执行时失败。

Skill 可能没有在正确请求下触发，可能遗漏关键步骤，可能引入错误修改，也可能花了很多 token 却没有改善结果。动态评测要观察的是：有它和没它，真实任务表现有没有可解释差异。

动态评测至少包含四类指标：

维度	观察指标	回答的问题
选择质量	应触发命中率、误触发率	Skill 是否在正确时机介入
任务价值	任务完成率、断言通过率、关键步骤覆盖	Skill 是否提高结果质量
执行成本	token、耗时、工具调用次数	改善结果花了多少资源
稳定性	多次执行波动、失败分布	增益是否可重复获得

这里要避免一个误解：成本越低不一定越好。

一个 Skill 可能增加少量工具调用，却显著提高断言通过率；也可能运行更快，但因为跳过验证而产生错误结果。动态评测必须同时呈现价值、成本和稳定性，才能判断它值得保留、需要优化，还是应该重新设计。

测试题目也不能凭空编。

更可靠的题目应该来自真实需求、代码变更、历史问题、用户反馈或可追溯任务记录，并区分三类事实：

事实类型	用途
用户可见事实	作为题面输入，模拟真实请求
隐藏判定事实	用于评测，不暴露给 Agent
来源证据	用于复核题目不是模型编造

如果只有一个模糊标题，没有需求、diff、日志或验收边界，就应该标记为信息不足，而不是让模型补出一个看起来合理的评测题。

动态成功也不能反向证明一切。一次任务通过，不能说明 description 长期准确，也不能覆盖全项目的能力冲突。动态评测解决真实效果问题，但不替代前面三层。

第五层：修复与交付闭环

评测只生成报告是不够的。报告如果不能进入修复、复验和交付流程，很快会变成另一个过期文档。

完整闭环要回答六个问题：

问题是否有足够事实支持修复。
多个问题能否按 Skill 和语义区块形成整体改法。
修改是否有直接证据或明确推理链。
修复是否造成语义漂移或预期外产物。
目标问题复验后是否消失，是否引入新问题。
通过验证的批次能否形成可审计提交边界。

这里最关键的一点，是避免“为了通过检查而修改”。

例如，为了满足 description 长度规则，随手追加一句“可以处理相关任务”，可能让 lint 通过，却让触发边界更模糊。为了提高 Rubric 分数，把错误恢复写成一段泛泛说明，也可能没有任何可执行价值。

修复系统应该要求证据约束。能从代码、reference、测试或历史任务中证明的内容，才适合写入 Skill。信息不足时，应该标记为待决策，而不是让模型补齐。

交付也要分层。修改文件、通过复验、提交、推送、发起合并请求，应该分别记录状态。只有通过验证的文件才能进入提交计划，高风险或不可逆动作还需要独立授权。

不要压成平均分

五层评测回答的是不同问题，不能简单加权成一个总分。

一个动态效果很好的 Skill，如果泄露凭证，不能靠任务得分高来发布。一个格式完全合规的 Skill，如果真实任务没有任何增益，也不能因为 lint 满分就被认为有效。

更合理的结果模型，是保留分层结论：

评测层	结果形态
规范检查	通过 / 警告 / 失败
语义评测	评分、理由、证据、事实缺口
工程关系	候选 / 已确认 / 已排除 / 信息不足
动态效果	结果、增益、成本、稳定性
修复交付	已修复 / 待决策 / 缺上下文 / 已验证 / 已交付

最终建议应该由门禁组合得出，而不是由平均分猜测。

安全失败可以直接阻塞发布；关系候选只要求进入复核；动态增益不足可能意味着要重新设计，而不是继续补文档。

从文档资产到工程产品

上下文资产进入仓库，只是第一步。

真正的质量工程，是让每项能力都能被持续验证：能否被稳定读取，能否正确指导 Agent，能否和其他能力协调，能否改善真实任务，发现的问题能否被修复并复验。

代码有编译、测试、Review 和发布机制。上下文也需要自己的反馈循环：

图：从文档资产走向可治理的工程产品

这套体系的目标不是制造更多流程，而是避免上下文资产变成一堆“看起来有用”的文档。

Skill 的最终价值不在于它被收录进仓库，而在于它能以可接受的成本，持续帮助 Agent 更可靠地完成真实任务。

结语

Skill 质量不是一个孤立分数，而是一条证据链。

规范质量保证它能被读取，语义质量保证它能指导行动，工程关系质量保证它不会和其他能力冲突，动态效果证明它真的改善任务，修复与交付闭环则保证问题不会只停留在报告里。

当这些证据都能被追溯，Skill 维护才会从“写一份说明文档”变成真正的上下文质量工程。

建站实战干货