LLM返回的坏JSON怎么修？这个微型API帮你搞定

调用大语言模型（LLM）时，API 返回 JSON 格式的复杂数据结构是常态。但模型偶尔会输出残缺的 JSON——比如少了个大括号、多了个逗号、引号配对错误——导致后续解析直接崩掉。这类问题往往不是逻辑 bug，而是模型输出本身不可控。一个专门处理这类脏数据的小工具，可能比反复写正则更省事。

rss source: Repair broken JSON returned by LLMs with a tiny API

为什么 LLM 的 JSON 容易出问题

LLM 生成 JSON 本质上是在逐 token 预测文本，而不是像传统程序那样严格序列化。当输出较长、嵌套较深，或者模型在生成过程中被截断时，就会出现字段缺失、括号不匹配、注释混入等问题。开发者常见的应对方式是手动写清洗逻辑，或者用 try/except 兜底重试，但这两条路都不够优雅：前者维护成本高，后者浪费 token 和时间。

LLM Dev Utilities API 瞄准的正是这个缝隙。它不是模型本身，而是一个独立的开发工具接口，专门接收那些“坏掉”的 JSON，尝试把它修复成合法结构再返回。

什么是逐 token 预测：LLM 并非一次性生成整段文本，而是把输入切分成 token（子词单元），然后基于概率分布一个一个地采样输出下一个 token。这意味着模型在生成 { 之后，理论上仍可能接出任何字符，语法约束只是概率上的偏好而非硬性规则。当序列变长、嵌套层级变深时，模型对早期括号的"记忆"会被稀释，闭合符号的预测错误率随之上升。此外，多数模型设有最大输出长度（max tokens），超出后生成被截断，已打开的括号和引号就再也等不到对应的闭合符，这是残缺 JSON 最常见的来源之一。理解这一点就能明白：修复工具处理的不是逻辑错误，而是采样过程本身的统计性缺陷。

这个 API 具体能做什么

LLM Dev Utilities API 提供的功能不止于 JSON 修复，围绕 LLM 开发中的几个常见痛点做了覆盖。

JSON 修复与格式化

核心能力是接收格式错误的 JSON 文本，输出结构正确的版本。从官方给出的示例来看，即使输入像 {name:"Ann", age:30,} 这样缺少外层引号、尾部多余逗号的片段，API 也能尝试还原为合法 JSON。对于需要稳定解析模型输出的应用来说，这层兜底能显著降低崩溃率。

容错 JSON 解析的常见策略：把 {name:"Ann", age:30,} 这类文本还原成合法 JSON，通常依赖一套启发式规则而非严格的语法分析。典型做法包括：为未加引号的键名自动补引号、删除对象或数组末尾的多余逗号、在缺少闭合括号时按栈结构补全、把单引号统一替换为双引号、剔除 // 与 /* */ 注释以及尾随说明性文字。部分实现还会在 JSON 前寻找第一个 { 或 [，截掉模型输出的寒暄前缀。这些规则按顺序应用，任一环节判断失误都会导致后续修复偏离，因此修复工具往往采用"先尝试严格解析、失败后再逐级放宽"的流水线策略，以尽量减少对原本合法内容的误改。

字幕文件清洗

另一个实用场景是处理 SRT 或 WebVTT 字幕格式。LLM 在生成带时间戳的字幕时，经常出现时间格式不统一、序号错乱等问题。API 提供了字幕清洗和格式化能力，对做视频类应用的开发者比较友好。

Token 预算压缩

当输入文本过长时，token 超限会导致请求失败。这个 API 内置了压缩工具，在保留文本主要信息的前提下缩减体积，帮助控制 token 预算。

token 与上下文窗口的关系：token 是模型处理文本的最小计费与容量单位，英文约 4 个字符对应 1 个 token，中文则接近 1 个字对应 1 到 2 个 token。每个模型都有上下文窗口上限，输入与输出的 token 总数不能超过该限制，且超出部分会直接触发报错。压缩工具的作用是在信息损失可控的前提下缩短文本长度，常见手段有去除冗余空白与重复句、抽取关键句、缩写长实体名等。需要注意的是，压缩本身也是一种有损变换，对需要精确引用原文的场景（如法律条款、代码片段）应谨慎使用，最好先评估压缩前后的语义一致性。

日志分类与排查

API 还带了一个 log triage 功能，可以分析和归类模型运行产生的日志，方便实时监控模型行为和性能表现。

一次典型调用的样子

使用模式是标准的请求-响应。向 API 端点发送 POST 请求，带上需要修复的 JSON 或待处理文本，API 返回修复或转换后的结果。如果涉及 token 压缩，响应中也会体现压缩结果。

下面是一个 JSON 修复的调用示例：

curl -X POST 'https://llm-dev-utilities.p.rapidapi.com/json-repair' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: llm-dev-utilities.p.rapidapi.com' \
  -H 'Content-Type: application/json' \
  -d '{"text":"{name:\"Ann\", age:30,}"}'

接口部署在 RapidAPI 平台上，提供免费额度，注册账号拿到 key 之后就能直接测试。

值不值得用

这类工具的价值取决于你的场景。如果你的应用需要从 LLM 稳定提取结构化数据——比如自动填表、函数调用参数解析、批量数据处理——那么一个专门做输出修复的中间层确实能减少很多脏活。它的处理是确定性的，不依赖再次调用模型，速度和成本都可控。

但也要注意，JSON 修复本质上是“猜测意图”。如果模型输出错得太离谱，修复结果可能偏离原意，需要开发者自己校验。它更适合当作容错兜底，而不是替代对模型输出质量的把控。

对独立开发者和小团队来说，零成本起步、按需接入，这种轻量工具的上手门槛确实不高。