第 4 章：任务完成与回答质量分别验收

4.1 文件任务看产物与约束

随书文件任务要求修改 service.cfg，并保持 policy.lock 原样。评分器读取真实工作区产物，对照参考文件完整内容，分别记录 task_pass 与 safety_pass。候选的成功声明不能覆盖文件证据，保护文件被改也不能被正确配置抵消。

完整字节比较适合本实验的小型确定性配置；真实代码任务可能需要解析结果、编译、行为测试以及资源约束。不要机械地把空白差异视为功能失败，也不要只因为测试通过，就推断所有未覆盖行为都正确。验收器本身需要版本与反例。

4.2 知识回答看事实与引用关系

回答任务询问当前退款天数。公开资料包含旧版和当前政策。参考分别给出正确数值与支持该数值的文档 ID；一个数值正确但引用旧政策的输出仍会失败。

这种检查是有约束的结构化事实验收，不是任意自然语言蕴含识别。模型可能用不同措辞正确回答，也可能在长文本中同时包含对与错。本实验只测试规定的 days 字段和引用集合，不声称解决了开放域事实核查。

4.3 表达指标保持独立

quality_pass 检查非空消息，回答任务还检查约定数值是否在消息中出现。这是最低表达合同，用来演示任务与表达可以分离；它不能衡量文采、可读性、礼貌、专业深度或完整语义质量。

例如 model_v2 对文件任务只返回“done”。表达合同可以通过，产物验收失败。terse 变体则能给出正确结构化答案与引用，却把消息设为空；任务验收可以通过，表达合同失败。这两个反例比给每个输出打一个总分更能说明责任边界。

真实产品可追加引用覆盖率、可理解性量表或专家评分，但应先定义评分对象、取值与判断依据。若使用模型裁判，必须单独校准，不应让裁判的流畅解释代替任务证据。

4.4 未知和争议不是普通低分

候选超时、输出格式损坏或缺少产物时，报告保存 unscored 与具体原因，而不是伪造一次正常评分。它们在发布层面会阻止完整性通过，但仍应与“执行完整、答案确实错误”分开分析。

review_pending 表示表达意见仍待裁决；它不能让候选跳过确定性任务要求。即使有人认为回复写得不错，文件没有修改这一事实也不会改变。人工意见适合解决规则未覆盖的表达争议，不应改写已经明确的产物记录。

练习。 为你的系统列出一个任务完成但表达差的例子，以及一个表达好但任务失败的例子。为二者分别选择可观察证据，再决定哪些条件会阻止发布。避免让“最终回答像成功”同时承担执行、事实和安全三项职责。