AI 工具可能很早就显得很有说服力，但这不代表它已经可靠。精致的结果只能证明某个输入产生过一个可接受输出；自动化需要更强的证据：任务边界稳定、失败可见，而且错误结果能够恢复，不会污染后续工作。
因此，评估应该从模型比较之前开始。首先定义工具允许做什么。
冻结任务合同
先写清楚四件事：
- 工具可以使用哪些输入事实；
- 必须返回哪些输出字段；
- 不得虚构哪些陈述或转换；
- 审查者根据什么条件接受结果。
产品描述工具可以重组用户提供的事实，但不能虚构材料、认证、性能声明或客户结果。SQL 调试工具可以解释可能的正确性与性能问题，但在缺少 Schema 时，依赖 Schema 的结论必须保持条件化。
没有这个边界，评估就会退化成偏好测试。审查者会奖励流畅的文本，即使工具解决的是另一个任务。
先测试代表性输入，再测试边界情况
先选择少量能代表真实使用方式的普通示例。这里的目标是确认合同是否连贯，而不是立刻寻找罕见故障。
每个用例保持相同的输出要求，只改变输入事实。优先检查可以直接观察的指标：必需字段是否存在、原始事实是否保留、是否出现无依据陈述、格式是否符合要求。
普通用例通过后，再加入边界情况：字段缺失、事实矛盾、输入异常长、指令含糊，或者应该拒绝的内容。
把确定性检查与主观判断分开
有些标准可以精确判断：标题是否存在、JSON 是否通过 Schema、产品声明是否能在输入事实中找到。
另一些标准需要审查者判断：摘要是否保留关键限制、视觉 Brief 是否符合目标情绪、解释是否适合目标读者。
这两类标准应分别记录。确定性失败应自动阻止验收；主观评分则要保存审查者、评分规则和证据，让其他人能够理解结论。
不只测试成功结果，也要测试失败行为
AI 工具进入工作流之前，至少强制制造一次已知失败，并确认系统不会把部分结果当成完整结果传给下游。
安全失败应该回答三个问题：
- 什么失败了？
- 哪些已接受输入或产物仍然有效？
- 最小重试动作是什么？
如果唯一恢复方式是“全部重新运行”，这个工具还不适合作为工作流节点。
提升证据，而不是提升信心
只有当公开声明与实际收集的证据一致时，工具才能从 Demo 进入“已评估”状态。少量受控用例可以支持一个狭窄任务声明，但不能证明普遍准确、供应商永远可用，也不能支持跨任务排名。
这种克制本身就是产品设计。它告诉用户哪些能力可以依赖，也告诉开发者哪些状态必须保持可观察，并防止自动化放大一个从未通过下游资格验证的结果。