大模型 JSON 输出偶尔混入 Markdown：结构化响应的解析与兜底

线上摘要服务有一条很隐蔽的失败路径：模型看起来已经回答成功，HTTP 状态也是 200，但返回体开头多了 ```json，末尾又多了一段解释。直接交给 Go 的 json.Unmarshal 时，业务只能得到“无效字符 '`'”这类解析错误。问题通常不在 JSON 库，而在把“模型生成文本”误当成了“数据库返回结果”。

症状：HTTP 200 也可能拿不到可用 JSON

一次批量生成文章摘要的请求返回了下面这段文本，状态码、耗时和令牌用量都正常：

```json
{"title":"缓存击穿","summary":"...","confidence":0.86}
```
以上是根据输入生成的摘要。

把整段交给 json.Unmarshal 必然失败。另一个常见现场是回答被截断：开头没有围栏，但对象只写到 "confidence":。这两类错误的修复路径不一样，不能统一当成“删掉首尾字符”。

时间线：从生成文本到业务字段的断点

故障一般按四个阶段出现：请求方要求 JSON，模型生成带格式的文本，网关把文本放进响应字段，业务代码直接反序列化。真正缺少的是中间的边界检查。

这里要留意一个判断：如果原始内容本身已经被截断，去掉围栏也救不回来；如果只是外围说明文字，才适合做有限的边界提取。

触发条件：围栏、解释文字和截断分别处理

先保存原始响应，再做最小清理

日志里不要只记录解析错误。至少保留请求标识、模型返回字段的长度、首尾 80 个字符和解析阶段，不要把可能包含用户输入的完整内容无控制地写入生产日志。清理函数只接受一个 JSON 对象或数组，并且用首个合法起点和最后一个合法终点确定边界：

func extractJSON(raw string) (string, error) {
    s := strings.TrimSpace(raw)
    s = strings.TrimPrefix(s, "```json")
    s = strings.TrimPrefix(s, "```JSON")
    s = strings.TrimSuffix(strings.TrimSpace(s), "```")
    s = strings.TrimSpace(s)

    startObj := strings.IndexByte(s, '{')
    startArr := strings.IndexByte(s, '[')
    start := firstNonNegative(startObj, startArr)
    if start 

示例中的 firstNonNegative 和 maxInt 是普通整数辅助函数。生产代码还应限制输入长度，并在清理前后记录 SHA 或请求 ID，方便把问题响应与重试结果对应起来。

不要用贪婪正则替代 JSON 解析器

正则可以识别围栏，却不理解字符串中的转义符。例如字段值里可能合法地出现 "说明：使用 {id}"。最稳妥的顺序是：先按协议拿结构化字段；失败后仅清理外围围栏；再次失败就进入有限重试或人工可观测队列，而不是不断从文本中“猜”对象。

根因：结构化要求没有形成可验收的接口契约

“请返回 JSON”对生成模型来说更像偏好，不是强制的传输协议。即便使用了响应格式约束，也要把应用侧的验收条件写清楚：顶层类型是什么，字段是否必填，数字能否为空，未知字段是否允许，字符串长度的上下限是多少。

可以把响应分成三层检查：

修复动作：把解析和业务校验拆成两道门

Go 中可以先用 json.RawMessage 保留字段，再把关键字段解码到明确结构体。这样“JSON 语法正确但字段不对”不会混进成功分支：

type Summary struct {
    Title      string          `json:"title"`
    Summary    string          `json:"summary"`
    Confidence json.RawMessage `json:"confidence"`
}

func parseSummary(raw string) (Summary, error) {
    text, err := extractJSON(raw)
    if err != nil {
        return Summary{}, err
    }
    var out Summary
    if err := json.Unmarshal([]byte(text), &out); err != nil {
        return Summary{}, fmt.Errorf("decode summary: %w", err)
    }
    if strings.TrimSpace(out.Title) == "" || strings.TrimSpace(out.Summary) == "" {
        return Summary{}, errors.New("required field missing")
    }
    if len([]rune(out.Summary)) > 600 {
        return Summary{}, errors.New("summary too long")
    }
    return out, nil
}

实际项目还可以为 confidence 增加数值范围校验，并对未知字段采用明确策略。字段校验通过后，再把结果交给后续存储或检索流程。不要以“能反序列化”作为唯一成功条件。

反向验证：重试要有边界，成功要能被观测

格式失败可以触发一次更严格的重试：缩短提示词，明确只输出对象，并把上次失败类型作为内部指标，而不是把完整错误文本原样拼回提示词。重试次数建议有上限，使用指数退避，并让同一业务请求携带稳定的幂等标识。

验收日志至少包含 request_id、解析结果、重试次数、失败分类和最终字段校验状态。监控上把“HTTP 成功但结构失败”单独计数，它比单看 5xx 更能提前发现模型输出契约的漂移。

常见问题

只删掉 ```json 和 ``` 就够了吗？

不一定。响应可能还有前后解释文字，也可能已经被截断。清理后仍要运行标准 JSON 解析和业务字段校验。

解析失败是否应该无限重试？

不应该。无限重试会放大费用和延迟。按失败类型设置一次或少量重试，并保留原始失败样本供排查。

响应格式约束能完全替代应用层校验吗？

不能。协议约束降低格式漂移，但字段缺失、枚举不合法和业务长度超限仍应由应用侧验收。

把模型输出当成“需要验收的外部输入”，这条边界立住后，Markdown 围栏只是可观测的格式问题，不会再直接变成线上脏数据。