Intel Dokimi 0.2.0：重组 CLI，强化评估门槛

1. 命令名称迁入功能分组

执行旧命令时，会显示提示新命令名称的消息，并以退出码 2 结束。例如，原本用于计算分数的 eval score 已改为 eval score pointwise。

评估与分数计算统一归入 eval，资料列表与检查移至 catalog。追踪和数据输入输出也迁入独立分组。自动化脚本需要将旧名称替换为新名称，并检查按退出码执行的后续处理。

2. 测量缺失与无效分数将导致评估失败

任务运行、评估检查和仓库运行中，若计划的评估项目出错、未评分或缺失，将返回退出码 1。文档检查，以及对答案评分的裁判模型的措辞与一致性检查，会在严格判定失败的严格模式下应用这一标准。变化的重点不在于是否执行了评估，而在于是否确有已评分的结果。

非数值 NaN 或无穷大分数也无法通过。文档检查在严格模式下将 NaN 区间判为失败。基线即用作比较标准的既有评估结果；在严格模式下进行基线比较时，若模型或提供方缺失或标记为未知，也会失败。

过去将空输入视为成功的检查也有变化。若作为资料查找起点的顶层文件夹，即目录根目录中没有 SKILL.md，或报告生成对象中没有评估结果，将返回退出码 1。基准测试预检查中，若指定的输入文件不存在、不可读或为空，则返回退出码 2。

3. 退出码与比较结果的解读也有变化

退出码的基本体系为：成功 0，检查、通过标准或运行失败 1，输入或用法错误 2。仓库运行和评估检查对部分无效输入也返回 1，因此自动化处理还需结合所执行的命令判断。

工具偏好命令因预算限制停止时返回 3，并保留部分结果。其他命令因预算限制停止时返回 1。后端、运行记录和追踪命令在 JSON 输出模式下异常退出时返回 5。

针对各问题分数差异的符号翻转检验用于概率值计算和仓库比较的区间估计。这种方法通过翻转各问题差异的方向来评估观测到的差异，而区间估计以范围而非单一数值呈现分数差异。报告会显示该检验的概率值及分数发生变化的配对数量。

仓库比较还会显示差异计算方法，任务数为 5 或以下时，区间值为空。若没有在两组评估中均获得评分的问题，相对基线的差异也为空。解读比较结果时，除了差异大小，还可查看是否存在配对评分结果。

4. 新验证功能与重新运行成本需一并权衡

新增了查看仓库预算的命令，以及检查评估覆盖范围的功能。针对相对基线的下降幅度和配对比较所需的最少结果数设置通过标准的功能，可选择开启。检查多个模型或仓库变更的开发者，可以在扩大评估范围的同时设定允许变化的标准。

验证手段虽有所增加，但此前复用响应的任务可能产生再次调用的成本。在 Bedrock 和 Vertex 上，裁判、角色设置、问题生成器及验证器不再复用原有缓存响应，即此前调用时保存的响应。OpenRouter 也涉及相同对象，且响应存储键加入了是否采用流式传输，即实时分段发送响应的方式，因此相关调用需再次付费。

输出量设置也有变化。OpenRouter 的输出 token 上限 2000 已取消，新颖性评估调用在未指定 --max-tokens 时会请求 16384 个输出 token。发布说明指出，在 Bedrock 上，litellm 此前发送的请求为 4096 个。

5. 迁移时先检查基线与密钥

分数与判定无法直接与 0.1.0 的结果比较，因此需要重新运行基线。

若在已设置 OPENROUTER_API_KEY 的状态下执行过以下命令，验证器会将 OpenRouter 密钥作为 Google 密钥发送，因此应更换该密钥。

eval questions generate --validate --provider google-vertex

Dokimi 0.2.0 阻止空评估通过并扩展验证手段，但也伴随着命令迁移、重新运行基线及部分调用的额外成本。