“所有评测配置都合法，所以所有 Skill 都验证过了。”
“智能体能生成结果，所以这个 Skill 已经在生产环境中证明有效。”
这两句话的问题是证据跨级了，不是语法。PASS 只对某个检查、某个用例、某个环境和某个证据范围负责。
四个证据等级
SQEM 把证据分成四层：
| 等级 | 名称 | 能支持的典型结论 |
|---|---|---|
| E1 | 静态 | 结构定义、元数据、引用和静态规则通过 |
| E2 | 评测 | 某些行为契约、规则、评判器或回归用例得到观察 |
| E3 | 运行时 | 在真实智能体运行框架、基准测试或模型与智能体组合中运行过 |
| E4 | 真实项目 | 有真实项目使用、真实失败、用户反馈和长期记录 |
E1 很重要，但只证明工程结构。E2 可以说明特定用例的行为。E3 说明实际运行时里观察过。E4 才开始接近长期实践证据。它们不是质量等级，也不能互相自动替换。
PASS 到底证明什么
一条结果应该写成带范围的陈述：
在版本 V、智能体 A、模型 M、环境 E 下，用例 C 的行为检查 = PASS。而不是：
Skill 的一次检查标记为 PASS，所以它可靠、兼容、有效。后一句把多个未执行的结论偷渡进来了。
状态模型
评测契约允许使用这些状态：
| 状态 | 含义 |
|---|---|
| PASS | 当前检查在当前范围内满足预期 |
| FAIL | 有证据表明预期没有满足 |
| PARTIAL | 只有部分要求或部分环境得到支持 |
| NOT_RUN | 尚未执行 |
| BLOCKED | 因环境、工具、凭据或事件缺失无法完成 |
| INSUFFICIENT_EVIDENCE | 已有观察，但不足以支持目标结论 |
“没有观察到失败”不等于 PASS。没有运行也不等于失败。缺少 skill.selection 追踪记录时，正确状态是 BLOCKED，不是“没有触发”。
一个常见的证据跨级
假设仓库检查了：
SKILL.md存在；- frontmatter 合法；
- 评测 YAML 可以解析；
- 引用文件路径存在。
这些结果可以支持：
规范与 Skill 包检查 = PASS
证据等级 = E1 静态它们不能直接支持：
- 智能体一定会正确触发；
- 模型一定会遵守行为契约；
- 使用 Skill 比不使用 Skill 更好；
- 另一个智能体或模型也兼容；
- 真实项目长期使用没有问题。
这些声明分别需要 E2、E3 或 E4 的对应证据。
质量声明门禁
质量声明应该与证据一一对应：
| 声明 | 需要的证据 |
|---|---|
| “支持 Codex” | Codex 运行时证据 |
| “改善测试设计质量” | 对比基准证据 |
| “跨模型可用” | 跨模型证据 |
| “已在生产中证明” | 真实项目证据 |
| “所有引用均有效” | 静态引用验证 |
这不意味着每个 Skill 都必须拥有所有证据，而是要求团队说清楚目前能作出哪些声明。
质量画像的正确用法
可以用一张质量画像汇总当前状态：
Skill: functional-testing
版本：x.y.z
目标测试级别：L3 已评估
当前测试级别：L2 已验证
Q1 规范 PASS
Q2 设计 PASS
Q3 Skill 包 PASS
Q4 行为 PASS
Q5 有效性 NOT_RUN
Q6 兼容性 PARTIAL
Q7 证据/演进 PASS
证据等级：E2 评测
已知缺口：
- 基准测试尚未执行
- 跨模型证据不完整
- 真实项目证据有限这张表没有把 Skill 压成一个总分，也没有假装未知项已经被验证。它让下一步行动变得具体。
skill-change-verification 的价值在这里
变更验证 Skill 不只是列检查命令。它要求准确说明证据支持什么、哪些没有执行、还有哪些残余风险。
例如 skill-up validate 通过，可以作为静态或结构证据；它不是运行时语义验证。一次命令行冒烟检查可以说明安装路径走通；它不能证明跨模型兼容。一次人工输出看起来不错，可以作为观察记录；它不能替代基准测试或真实项目证据。
报告标题可能掩盖这些边界，所以状态和证据等级应该直接写出来。
输入不完整时的诚实输出
现实任务经常缺少环境、凭据、版本或选择事件。此时报告可以这样写：
触发：BLOCKED
原因：缺少 skill.selection 追踪记录
行为检查：NOT_RUN
原因：未提供运行时目标
静态包检查：PASS
证据等级：E1 静态
质量声明：仅限于 Skill 包有效性这份报告看起来没有那么“绿”，但它不会把未知变成事实。后续拿到环境后，也知道应该从哪里继续。
把一句质量声明拆成证据
团队如果在运行检查前就写清楚什么算证据，质量声明会容易处理很多。“支持 Codex”需要明确目标宿主、Skill 版本、代表性请求、实际观察到的选择和行为，以及保留下来的追踪记录；“改善测试设计质量”需要和明确的基线做比较；“已经在生产中证明”则需要真实项目观察，并且上下文足以解释当时发生了什么。
用一张简单的声明映射表记录五项：声明内容、所需证据等级、当前状态、已知缺口和下一步动作。它不需要把每个状态都填成 PASS，作用是避免一次静态包检查被误当成运行时或生产证据。
这样也更容易维护文档。证据过期、依赖变化或某个运行时不再可用时，把受影响的声明调整为 PARTIAL、NOT_RUN 或 BLOCKED 即可，不用重写整篇说明。这些限制也应该写进产物。
安装与调用
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en --skill skill-change-verification请使用 skill-change-verification Skill。
对每项检查，记录状态、证据等级、运行时元数据、限制，以及它能支持的具体声明。
分别记录静态验证、触发证据、行为证据、基准测试证据、兼容性证据和真实项目证据。
检查无法执行时，保留 NOT_RUN、BLOCKED 或 INSUFFICIENT_EVIDENCE 状态。两个实际问题
PASS 越多，质量画像就越好吗？
不一定。关键是 PASS 是否覆盖了与目标声明相关的风险。一个只有静态 PASS 的质量画像，可能比一个诚实标出基准测试 NOT_RUN 的质量画像更不完整。
PARTIAL 会不会显得项目质量很差？
它只说明证据范围有限。清楚的 PARTIAL 比无依据的“全面通过”更方便决策，也更容易安排下一步验证。