大模型测试总飘红，先检查断言设计

dev.to 的一篇文章把大模型测试反复飘红的排查重点，放在了断言设计和调用配置上：输出只是换了措辞，逐字匹配却判失败；模型版本和 temperature 没固定，测试条件也可能变化。作者主张先修正这些问题，再处理剩余的随机性，避免靠禁用测试换来没有质量保障的 CI 绿灯。

目前能确认什么

目前拿到的是摘要和部分原文。作者指出，语义一致的回答可以有不同表达，如果业务只关心结果是否正确，完整字符串相等就会把措辞变化算成错误。

他们给出的调整方向是检查输出必须满足的属性：必要信息是否齐全、是否出现不允许的内容、长度是否符合要求。对于 JSON，则检查 Schema（结构约束）、字段值，以及字段之间的关系，例如数量字段是否与数组长度一致。

配置方面，作者建议固定明确的模型版本，并将基础检查的 temperature 设为 0，同时保留按生产温度运行的独立评测。temperature 用于调节生成的随机性，但设为 0 也不能保证输出完全可复现。对仍有波动的任务，节选提出通过多次调用检查通过率，并放到夜间或发布前执行。

我的判断

应当稳定的是业务要求，不必是模型的每一句措辞。

但改成属性断言，也不能只追求容易通过。节选里的关键词检查有明确边界：回答包含 apple，不代表它正确列出了 apple；枚举几个禁止项，也无法覆盖所有额外内容。断言仍要对应业务真正接受的结果。

同样，Schema 校验通过只能证明结构符合约束，不能单独证明内容正确。固定版本和温度后持续失败，也可能是应用逻辑有问题，不能仅凭失败次数认定断言写错。

测试变绿，必须来自验收条件更准确，而不是条件更宽松。

原文尚未完整读取，统计阈值如何确定、如何处理边界任务，还无法确认。节选中的通过率和重复次数应视为示例，不能直接当作所有项目的发布门槛。