模型输出通过校验，为何仍弄坏看板

一篇 dev.to 文章记录了模型输出校验中的一次漏检：作者的日志分类任务连续两晚生成了通过自制校验的记录，下游看板却被枚举值漂移弄坏。问题出在校验只看字段类型，没有检查取值是否符合下游约定。现有节选展示了漏洞和部分修复代码，但不足以判断具体模型的可靠性。

目前能确认什么

作者让托管模型为每批日志打标签，再写入 JSON 记录。最初的校验只要求 severity 是字符串、line_count 是整数、tags 是列表。

severity 曾返回 high、HIGH 和 sev-3，全部符合字符串类型。下游代码却只匹配 high，其他值静默进入另一分支，图表因此空白。

另外两处边界同样容易漏掉：Python 的 bool 是 int 的子类，isinstance(True, int) 会通过；列表类型检查也不会自动约束元素，[1, null] 仍是列表。

节选还提到，Python 的 json.loads 默认接受 NaN、Infinity 等非标准 JSON 常量。作者在手工编辑的测试样例中发现了这一问题，不能据此认定模型输出过这些值。

修复代码加入了枚举白名单、布尔值排除、列表元素检查，以及解析阶段的异常常量拒绝。测试样例保留原始响应文本，便于重新解析；这些样例由作者编写，并非模型表现的测量结果。

我的判断

通过类型校验，不等于符合下游的数据契约。

对程序员最直接的启发，是检查模型输出进入数据库、统计逻辑或看板前，是否还有未经约束的取值。状态字段需要枚举约束，计数字段要明确是否允许负数，容器则要检查内部元素。

标题提到 JSON Schema，但节选展示的是自制 Python 校验器，不能把这些漏洞归结为标准 JSON Schema 的缺陷。代码也只是返回问题列表，额外字段不会导致失败；调用方如何拒绝或隔离坏记录、真实模型的漂移频率如何，现有材料尚未交代。