# 模型多回了一句"好的"，下游就崩了

![封面_公众号_900x383.png](https://developer.qcloudimg.com/http-save/yehe-11546919/32e85116d6f4264fdb1e1c60c80fb75b.png)
先说我碰上的一件事。

一条链路跑了几个月，一直很稳。模型没换，我只是在 prompt 里改了一句措辞。

现在这类链路到处都是：调模型、拿结果、解析、入库。做客服摘要的、做单据识别的、做数据抽取的，基本都长这样。

第二天凌晨，它红了。

查下来的原因有点好笑：模型在 JSON 前面，多回了一句"好的，以下是结果"。

程序拿这段文字去解析，第 1 行第 1 个字符是个"好"字，当场就懵了：

```
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```

当天发现，当天修，半小时的事。

---

## 一、真正麻烦的，不是报错的那批

如果所有问题都这么响，日子反而好过。

麻烦的是另一批——它们不响。

举个真实的：有个订单金额，本该是整数 `120`，模型返回成了字符串 `"120"`。

程序不挑食，照样收下。下游取金额的地方写着"取不到就当 0"，可这回它取到了，取到的是一个字符串。于是这个字符串一路往下走，进了业务逻辑，进了数据库。

两周后对账，这笔账才对不上。

我们把两种情况的账算一下：

| | 多了句寒暄 | 金额变成字符串 |
|---|---|---|
| 什么时候知道 | 当场，报错 | 两周后，对账 |
| 表面上 | 红的，很吓人 | 绿的，一切正常 |
| 处理成本 | 半小时 | 回溯数据、修数、重对账 |
| 有没留下垃圾 | 没有 | **脏数据已经进库了** |

会叫的那批，成本其实很低。不会叫的那批，才是最贵的。

---

## 二、问题出在哪：我们把它当成了一个普通函数

回头看，当初的设计大概是这样想的：

```
调模型 → 拿到结果 → 解析 → 入库
```

四步，一行代码能串起来，看着就是个普通的函数调用。画设计图的时候，它跟一个本地方法画在同一个格子里，谁也不觉得有问题。

这个判断当时真不算错，它安安稳稳跑了几个月。

错的是它的前提。

**普通函数是有脾气的规矩人。** 你让它返回整数，它就返回整数。说好要三个字段，它就给你三个字段。换个版本还得先改依赖声明，它会提前告诉你。

模型不是这样子。它更像个外包——今天交 Excel，明天交张截图，后天先来一句"好的老板，文件在下面"。你要的那三个字段，它心情好给三个，心情一般给两个，有时候还自动帮你把数字改成了字符串。

换模型会变，改 prompt 会变，连措辞微调一下都会变。它一直在慢慢变，只是变得小，你看不出来。

问题是：这几个月里，一直没有人在门口验收。

---

## 三、缺的不是一行判断，是三件事

**第一件，门口没人验货。**

模型返回的东西，一路直接进了解析、进了业务、进了库。格式对不对、字段齐不齐、类型对不对，没人管。

**第二件，缺了就自己填。**

`d.get("amount", 0)` 这行代码看着很贴心——取不到就给个 0，不报错，程序接着跑。

但它的真实含义是：**快递少了一件，我们自己找个空箱子顶上，让账面上看起来是齐的。**

金额缺失还能把账算对吗？不能。那这里就不该"填"。

**第三件，退了几单没人记。**

整条链路上，没有一个指标在统计"模型给的东西不合格的比例是多少"。

所以你不知道这是偶发一次，还是已经成了常态。你只知道账对不上，但不知道是从哪天开始的。

---

## 四、改法：拆包、验货、退回、记账

想清楚之后就四步，都不难。

![腾讯云投稿04_配图_信任边界.png](https://developer.qcloudimg.com/http-save/yehe-11546919/d12c8dd868bd977e3777478a3c60c455.png)

**第一步，拆包装。**

模型给你的不是干净 JSON，是一段话——前面可能有寒暄，外面可能裹着 markdown 代码块，末尾可能还有"希望对你有帮助"。这些是运输途中蹭上的包装，得先撕掉。

还要留个心眼：如果括号没配平，说明输出被截断了，这时候要直接报错，别拿半截去解析。

**第二步，对清单。**

按事先写好的清单，一个字段一个字段地对：这个在不在、是不是数字、是不是空的。

这一步有个坑，我踩过。

我原本以为，只要声明了"amount 是整数"，就完事了。实测不是：

```
amount="120"   →  通过，存进去变成 120
amount=120.7   →  拦下
amount=true    →  通过，存进去变成 1
```

看最后一行。`true` 被悄悄转成了 `1`，校验报告上写着"通过"。

原因不复杂：校验工具默认是"能转就转"，因为它平时要接表单输入，用户填的 "28" 就该当成 28。这个默认值在接表单时是好事，在**验收模型输出时正好帮了倒忙**——它把你最想抓的那个"变形"给抹平了。

把严格模式打开，说一是一，不许转。三个输入全拦下，正常的输入也没误伤，这个我实测过。

**第三步，不合格就退回。**

清单对不上，正确动作是：把模型的原始返回记下来，告警，让这次调用失败。

错误的动作是：给个默认值，接着跑。

这两者的区别，是"一个请求失败"和"一批数据出错"的区别。

**第四步，记账。**

把"不合格率"做成一个指标，按字段分开记。有了这个数，你才知道模型这次升级是不是把某个字段搞坏了。

---

## 五、多这道手续，会不会变慢

每次提这个方案，都有人问会不会拖慢链路。我没争论，直接在本机测了一遍。

样本是一条普通订单 `{"order_id": "A1001", "amount": 120, "currency": "CNY"}`，循环 20000 次取平均：

| 走法 | 耗时 | 相对不校验 |
|---|---|---|
| A 直接解析，不做校验 | 1.955 μs | 1.00x |
| B 先解析成字典，再校验 | 7.543 μs | 3.86x |
| C 一步解析加校验 | 1.889 μs | **0.97x** |
| D 同 C，开严格模式 | 1.790 μs | **0.92x** |


![腾讯云投稿03_配图_耗时对比.png](https://developer.qcloudimg.com/http-save/yehe-11546919/7d2264fe8d1e9c0b8a6b370562f33705.png)


B 确实慢，接近 4 倍——它先把字符串拆成字典，再回头在 Python 里查一遍。

但 C 和 D 反而比"什么都不校验"还快，因为它们一步到位，中间那本字典根本没建。

所以选 D。开严格模式，一次搞定，还比不校验更快。

这点时间有多小？它占一次模型调用的 0.000179%。换算成人话：一千次调用，这一步加起来不到 2 毫秒；而这一千次调用本身，要花十几分钟。

---

## 六、最后几句

这件事之后我改了一个习惯：**模型返回的东西，没过验收，就不算数据。**

它跟第三方的接口、跟用户上传的文件是一类东西——外面来的，都得先验。区别只是它比别的更爱变，而且变的时候不会通知你。

另外两条也顺手记下了。

缺字段就报错，别自己填。填空看着温柔，其实是把问题往后推两周。

不合格率做成指标。不然你只能在对账的时候，被动地发现它。

最后一句：模型多回一句"好的"，你就得多查一轮。**验收放在门口，成本是几行代码；放到下游去追，成本是几个通宵。**

---

## 附：复跑说明

文中数据均来自本机实测，可复跑对照：

| 项 | 值 |
|---|---|
| Python | 3.13.14 |
| pydantic | 2.14.1 |
| 计时方式 | `time.perf_counter()`，循环 20000 次取均值 |
| 样本 | `{"order_id": "A1001", "amount": 120, "currency": "CNY"}` |

绝对耗时受机器负载影响会有波动，但"C 和 D 比 A、B 都快"这个趋势是稳定的。

### 参考出处

- pydantic 官方文档 · 严格模式：https://docs.pydantic.dev/latest/concepts/strict_mode/
- Python 标准库 `json`：https://docs.python.org/3/library/json.html

---

**关于作者**

马顺华，做数据库运维，常驻杭州，日常跟国产分布式数据库和智能运维打交道。

*原创内容 · 转载请联系授权*


现在这类链路到处都是：调模型、拿结果、解析、入库。做客服摘要的、做单据识别的、做数据抽取的，基本都长这样。

模型多回了一句“好的”，我的链路半夜红了

模型没换，prompt 只改了一句措辞，它就在 JSON 前多回了句“好的”，链路凌晨就红了。更麻烦的是不报错的那批：金额从数字变成了字符串“120”，两周后对账才发现。这篇讲怎么在入口拦住这类变形，附实测耗时。

运维工程师

人工智能

后端

运维

模型输出非标准JSON导致下游崩溃，根源在于未设验收机制。解决之道：拆包、验字段、严格模式、不合格即报错、记录不合格率。此举耗时仅增加0.000179%，性能反升8%。缺字段严禁默认填充，防脏数据入库。改模型输出校验，守护全链路数据质量。

分布式数据库

数据库运维

代码解释

数据库

Markdown

Python

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

模型多回了一句“好的”，我的链路半夜红了-腾讯云开发者社区-腾讯云

模型多回了一句“好的”，我的链路半夜红了

模型多回了一句“好的”，我的链路半夜红了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐