模型分类结果写成“待办”“待处理”“pending”，怎样统一枚举而不吞掉新类别

模型把同一种状态写成“待办”“待处理”和 pending，可以通过别名表归一。但归一不应把新类别吞掉。一个默认返回 pending 的函数，会让“已取消”“暂停审批”甚至拼写错误都看起来正常，最终污染分类统计。

先发布可以合并的词表

本文规范枚举只有 pending、done、cancelled。版本一登记“待办”“待处理”和 pending 对应 pending，“完成”和 done 对应 done，“取消”和 cancelled 对应 cancelled。仅对字符串做首尾空白清理与英文大小写折叠，不删除内部字符，不做拼音或相似度猜测。

这一词表是演示业务合同，与模型平台的内置枚举无关。Structured Outputs 的枚举约束可以限制输出集合，但已有文件、缓存或兼容接口仍可能送来别名。适配器要明确声明自己接受什么，不能一边说只收规范值，一边悄悄采用任意自然语言标签。

每条转换留下原始值

归一台账包含原值、处理后的查找键、别名表版本、规范值与状态。已登记别名输出 mapped；非空但未登记的字符串输出 unknown；空白和空字符串输出 empty；数字、布尔或数组输出 type_error。四类结果的后续动作不同，不应都变成 null 然后丢弃原因。

附件检查已登记中文与英文别名映射一致，并给“暂停审批”做未知对照。失败反例是用 "待" in value 判 pending，这会把“等待取消确认”也归成待办，掩盖一个需要单独设计的新状态。另一个反例是把数字一转换成字符串再找别名，让原本的类型问题消失。

新增别名需要历史回放

业务确认“处理中”也应归 pending 时，先形成版本二，重放版本一的全部样本，确认原有分类没有改变，再增加新样本。历史记录保留当时使用的表版本，否则同一条原始结果在不同日期会显示不同归类，却查不到原因。

需要更改既有映射时，应作为语义迁移处理，而不只是新增同义词。例如以前的“完成”只代表处理结束，后来改为交付成功，旧结果不能自动被重新解释。应按业务定义补充标签或拆分状态，让变化可审查。

归一后仍要验证任务中的合法状态转换。一个 cancelled 值合法，不代表已支付订单可以直接取消。本文只验证标签映射，不执行任何订单动作，也不声称减少了真实模型误分类。交付时把未知率与已映射比例分开报告，有未知类别是需要治理的信号，不是应被默认值遮住的异常。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a014.json，离线检查器 a014.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a014.py。

一手资料1；一手资料2。资料核对日期：2026-10-24。