AI输出JSON校验通过却仍有错？工单案例核对结构、负责人和原文证据

先约定字段，再让 AI 提取

本篇原始材料只有一句自编说明：“Ticket T-007: User cannot export PDF. Product not identified. Owner unassigned.” 目标是提取工单编号、问题类别、负责人和证据片段。类别约定为 export、login、unknown；负责人无依据则写 null。这个约定来自编辑任务，不是模型自动定义的业务规则。

JSON Schema 官方对象文档解释 properties、required 与 additionalProperties 的用途。用这些约束控制输出结构，仍需自己确定字段含义和允许范围。某个属性被允许出现，不能证明它在材料中被确认。

复制一个有明确边界的 Schema

下面是自编的简单 Schema，适合本站 Draft-07 校验工具。它拒绝约定之外的字段，要求四个字段存在，并检查编号、类别与数据类型。它没有访问工单系统，也不会自动判断某个负责人名字是否来自原文。

若需要让 AI 产生输出，可用后面的自编提示词。先输入同一份原文和约定，再保留模型返回的原始内容；不要在未核对时自动“清理”到通过校验。

{
  "type": "object",
  "properties": {
    "ticketId": {
      "type": "string",
      "pattern": "^T-[0-9]{3}$"
    },
    "category": {
      "enum": [
        "export",
        "login",
        "unknown"
      ]
    },
    "owner": {
      "type": [
        "string",
        "null"
      ]
    },
    "evidence": {
      "type": "string",
      "minLength": 1
    }
  },
  "required": [
    "ticketId",
    "category",
    "owner",
    "evidence"
  ],
  "additionalProperties": false
}

从以下原文提取 JSON，不补充事实。
字段：ticketId、category、owner、evidence，全部保留。
category 只能是 export、login、unknown；无负责人依据则 owner 为 null。
evidence 使用原文问题片段。只返回 JSON，不增加其他字段。
原文：Ticket T-007: User cannot export PDF. Product not identified. Owner unassigned.

三份输出要经历不同的验收

第一份编辑构造的错误对象把 ticketId 写成数字 7，把 category 写成 urgent，还加 priority。它不符合约定的结构。第二份改好结构，却仍填 owner: Mina；名字是编辑故意加入的无依据内容。第三份将 owner 改为 null，才与本例“未分配”的事实对应。

这里最重要的是第二份：它的 owner 是允许的字符串，Schema 不知道 Mina 是否真实负责这张工单。校验器不会替你读原文，更不能以“通过”覆盖原始材料。

在本站工具运行，再回到原文

打开JSON查询与Schema工具，用“JSON输入”和“JSON Schema”两个独立区域，不要把Schema也粘进业务对象。粘贴schema.json后，按下列顺序逐份检查。运行之间核对当前文件名和输入内容，避免沿用上一份结果。

校验结果可下载为json-result.txt。这是校验器的文字答复，不是包含工单数据的正式JSON导出，也不是人工审核证书。每次下载后按候选文件另存；同时保留原候选JSON和独立审核账本。

1. 1
   先粘贴invalid-syntax.json，运行“校验输入”；应出现JSON解析错误。改回正确源对象，不靠删业务字段换取成功。
2. 2
   粘贴第一份结构错误对象，保持原Schema运行。应看到约束错误，涉及额外priority、ticketId类型或category枚举；不要求不同版本的错误顺序或措辞完全一致。
3. 3
   粘贴第二份对象，运行应显示“校验通过”。在JSON Pointer路径填/owner，运行“查询路径”，应返回字符串“Mina”；回source.txt可知该负责人无依据。
4. 4
   粘贴第三份对象，运行同一Schema仍应通过；查询/owner应返回null。再查询/ticketId应是字符串“T-007”。
5. 5
   逐值核对category为export、evidence为原文片段cannot export PDF，owner为null。将结构结论与证据结论分别写入review-ledger.csv；本例只接受第三份。
6. 6
   下载各自的校验文字结果，重新打开并对照候选文件名。下载文件不替代原JSON，不能从一行“通过”重建已验对象。

什么时候该保留待确认，而不是修成通过？

如果原文含糊、版本不明或字段定义尚未确定，保留待确认项并请负责人员判断。一次校验不能证明分类覆盖了所有真实场景，也不能确认跨记录关系。用空值与零值核查方法定义未知信息，避免为了凑字段随意填 0、空字符串或人名。

当前工具支持 Draft-07，JSON 输入、对比内容与 Schema 合计上限为 200 万字符，在本地执行校验。语法错误、Schema 问题与业务证据问题要分开处理。导出表格时再按CSV 与 JSON 转换检查核对编号与空值；转换不会修复无依据事实。

先把输入、校验结果和审核结论分开保存

练习ZIP包含source.txt、schema.json、output-01-invalid-structure.json、output-02-valid-unverified.json、output-03-source-aligned.json、invalid-syntax.json与review-ledger.csv。三份输出沿用正文原有案例；invalid-syntax额外演示语法损坏。原文只有T-007无法导出PDF、产品未识别、负责人未分配这几个事实。

三份输出不是三个工单，不能纵向合并为三条真实业务记录。审核账本每行是一份候选输出的检查结果。原文、候选文件、工具返回和最终接受决定使用不同文件名；否则第二份的“校验通过”很容易被误贴到第三份的证据结论上。

两个通过，一个接受：审核账本怎么写

结构层有两份通过，证据层只有一份可接受。这是三个编辑候选的练习结果，不能写成模型准确率为1/3，也不能把两次校验成功计为两张已完成工单。没有运行模型，本例也无法估计它实际会犯错的频率。

负责人缺字段、空字符串与null是三种不同情况。required要求字段出现；owner的类型允许字符串或null，所以空字符串同样可能通过当前Schema，却不符合本例明确的未知值约定。若团队约定未知用null，应在人工规则或更严格Schema里明确这一点，不能依赖绿色通过提示猜测。

恢复时先修正无依据的值，再对修正对象重跑原Schema并重新比对证据。只改审核账本为“已通过”、不保留最终JSON，不构成可复查的交付。后续转表格可参考CSV与JSON转换核对，防止null与空格在转换时失去区别。