一句话定义：JSON 修复（JSON Repair）是把大模型输出的、语法不合法的文本，自动加工成能被 JSON 解析器正常读取的合法 JSON 的过程。
半截 JSON 是怎么来的
模型输出不是数据库查询，它是一段流式生成的文本。常见翻车姿势有：输出被 max_tokens 截断，最后停在 "title": "如何 这种地方；热心地加上 `json 代码围栏，前后还补一句"以上是结果"；用单引号、留尾逗号、写注释、把 null 写成 None、用中文引号。这些都过不了严格解析。
为什么不能直接 json.loads
json.loads 是严格解析器：只判断，不修补。像验钞机——假钞直接吐出来，不会帮你把撕掉的角粘回去。更坑的是报错位置有误导性：它通常指在文本末尾附近（Expecting value、Expecting ',' delimiter），而真正的问题可能在前几十个字符处，一个尾逗号就把后面全带偏了。
修复通常分三层
1. 清洗（sanitize）：剥掉代码围栏、前后说明文字、BOM、注释、尾逗号，把单引号和中文引号换成标准双引号。
2. 补全（complete）：用一个栈记录未闭合的 {、[ 和未结束的字符串，从后往前按顺序补齐；也可以丢弃最后一个不完整字段。
3. 宽松解析（tolerant parse）：用容错的解析器接受无引号 key、NaN 之类的方言，再转成标准结构。
这三步像把摔散的乐高按图纸拼回去：括号是凸起和凹槽，必须一一对上；对不上就是缺件，不能硬塞。
补全还是重试
| 症状 | 建议 | 理由 |
|---|---|---|
| 输出被截断 | 优先补全 | 前面的内容是对的，重试大概率再截一次，还多花 token |
| 尾逗号、围栏、单引号 | 清洗即可 | 成本几乎为零，结果确定 |
| 结构错乱、字段缺失、值明显跑偏 | 重试 | 补出来的内容是编的，不可信 |
| 同一请求反复失败 | 改方案 | 换结构化输出或 JSON 模式、缩小单次输出、拆成分片生成 |
判断标准很简单：错误在"外壳"就修，在"内容"就重试。
给从业者的一句提醒
补全只保语法，不保语义。修复后的对象仍要过一遍 schema 校验（如 JSON Schema、Pydantic 模型），否则你会拿到一个合法但字段缺失的 JSON，错误悄悄流到下游。工程上应把修复层当兜底网而不是主路径：优先让模型一开始就输出合法结构，修复只负责接住漏网的；同时给"解析失败率"打点监控，这个数字涨了，说明提示词或截断设置该调了。
对普通用户来说，你看到的结构化卡片、表格、表单能正常渲染，背后很可能就有一层这样默默干活的修复逻辑。各家模型和库对结构化输出的支持范围不同，具体以官方页面为准。