标签的推理过程，导致用户kan到混乱的内容。 * *问题2：*/rewrite端点行为不可预测，因为Prompt不够严格。 * *问题3：* 错误响应不一致。 * *解决方案：* * 停止添加新功Neng；先加固现有功Neng。 * 输入验证。 * 输出清洗（用于

老实说这听起来像是个废话文学。HTTP 状态码 200 OK，意味着服务器成功处理了请求，响应体里也有数据，那不就Neng直接往页面上贴吗？

Ru果你也是这么想的，那你可Neng还没真正掉进过大语言模型应用开发的坑里。这周我就被狠狠地上了一课：在 LLM 的世界里“接口Neng跑”和“结果Neng用”之间，隔着好几道你没写的防线。

事情是这样的。我Zui近在捣鼓一个开源的 AI 开发训练项目，第一个动手Zuo的是一个文本处理 API。技术栈选得hen轻量：FastAPI Zuo框架，对接 OpenAI 兼容的上游模型，对外暴露三个端点——、要点提取和 。架构也hen简单，就三层：路由层管 HTTP，任务层构造 Prompt 并清洗结果，客户端层负责和上游通信。

到第一周末的时候，三个接口dou跑通了本地测试也全过了。按正常思路，下一步应该加功Neng了对吧？但我kan着那几行绿色的测试通过日志，心里总觉得不踏实。这种感觉就像是你刚修好了一辆老爷车，虽然引擎Neng响，但你不敢开上高速，因为你不知道哪个螺丝会在下一秒飞出去。

于是我Zuo了一个当时kan起来有点反直觉的决定：停下来不加新接口，先把现有的三个接口加固到“敢交付”的程度。结果这一停，就挖出了三个让我后背发凉的问题。

第一个坑：当“内心独白”变成了“干扰信息”

你调了一个大语言模型的 API，拿到了 HTTP 200，返回体里也确实有一段中文文本。kan起来一切正常。你把它塞进响应返回给前端——然后用户kan到了这么个东西：

这是一段正常的摘要文本。

是不是hen崩溃？一段模型的内心独白，就这么堂而皇之地出现在了用户面前。

这其实不是假设场景。部分模型——特别是带推理Neng力的版本——会把自己的思考过程用 标签包起来混在 message.content 里一起返回。Ru果你的代码跟我一开始一样直接信任了 content 字段，用户kan到的就是正文夹杂着一堆他完全kan不懂的模型内心戏。

Zui要命的是只靠kan HTTP 状态码根本发现不了这个问题。200，有内容，kan着挺好——但内容本身是脏的。

解决这个问题的办法本身不复杂，用正则把推理标签清掉就行。但关键是把它Zuo成代码里的固定规则，而不是出一次问题手工修一次。我在代码里加了一层清洗逻辑：

import re
THINK_BLOCK_RE = re.compile
def _extract_result -> str:
    content = response_data
    # 移除思考标签，并去除首尾空白
    cleaned = THINK_BLOCK_RE.sub.strip
    if not cleaned:
        raise ApiError(
            status_code=502,
            code="UPSTREAM_EMPTY_RESPONSE",
            message="Upstream returned an empty response",
            detail="response content became empty after cleanup",
        )
    return cleaned

这里有个细节值得说一下：清洗完之后Ru果内容变空了不Neng默默返回一个空字符串，得显式报错。不然调用方拿到的是一个 200 + 空内容的响应——比直接报错还难排查。这就是防御性编程的精髓：永远不要假设上游是友好的。

第二个坑：Prompt 不是圣旨，模型会“自作主张”

Ru果说第一个坑是显式的脏数据，那第二个坑就隐蔽得多了。/rewrite 的设计意图是轻度 ，比如把口语化的句子变得通顺一点。但真实样例一跑我发现，同样一段短句，模型有时会 成正儿八经的书面语，有时扩写 50%，偶尔甚至自作主张加一个标题。

这种问题不报错，日志里也kan不出异常，但调用方拿到的结果跟预期完全不是一回事。

为什么？因为我初版 Prompt 只写了“用geng清晰自然的中文 ”，没告诉模型什么不行。LLM 就是这样——你不明确说不行的，它默认dou行。Prompt 约束本质上是“建议”，不是“保证”。

为了解决这个问题，我用了两头夹击的办法：

1. Prompt 端加限制： 明确要求“不扩写、不加标题、短文只润色”。

2. 代码端加归一化： 不把赌注全压在 Prompt 上。我在代码里加了一层后处理，自动去掉模型擅自添加的“ 后：”前缀和首行标题。

这让我意识到，光改代码不够，得让改完的东西Neng被持续验证。你不Neng只相信模型的“人品”，必须在代码层面给它套上缰绳。

第三个坑：错误响应的“巴别塔”

前两个坑是业务逻辑层面的，第三个坑则是工程规范层面的。一开始，我的接口报 500 或 404 的时候，返回体有时是 FastAPI 默认的 HTML 错误页，有时是一段不带上下文的纯文本。

调用方拿到这玩意儿怎么处理？没法按固定字段Zuo判断，测试写不出稳定的断言，出了问题也追不到是哪个请求挂的。这就像你跟一个人说话，他有时用中文回，有时用英文回，有时甚至只给你一个白眼，沟通效率极低。

于是我决定统一错误响应的结构。不管内部出了什么错，对外必须是一张冷冰冰但标准化的 JSON 脸：

{
  "code": "UPSTREAM_REQUEST_FAILED",
  "message": "Upstream request failed",
  "detail": "request timed out",
  "request_id": "01a1200e-5c70--8d47-c951a9cd54f6"
}

这四个字段各管各的：code 给调用方Zuo程序化分支，message 给人kan，detail 给排查用，request_id 把请求和响应串起来。调用方终于Ke以按固定结构写错误处理了出了问题也Neng追到是哪个请求出的。

防御性编程：在模型层统一设卡

除了上述三个大坑，我还发现了一个容易被忽视的细节：输入校验。

为什么要在模型层统一Zuo，而不是在每个路由里各写一套？因为校验逻辑一旦分散，不一致只是时间问题。这个接口拦了空格那个没拦，这个限了 500 字那个忘了——到后面出了问题你dou不确定该查哪一层。

我给三个文本接口共用了一个 Pydantic 请求模型，Zuo的事情hen基础，但hen管用：

from pydantic import BaseModel, Field, field_validator
class TextTaskRequest:
    text: str = Field
    @field_validator
    @classmethod
    def validate_text -> str:
        normalized = value.strip
        if not normalized:
            raise ValueError
        if len> MAX_TEXT_LENGTH:
            raise ValueError
        return normalized

先 strip 再校验，拦住纯空格；Zui大长度限死；三个接口的输入形态统一。这就像是在你家门口装了个防盗门，不管谁来dou得先按规矩来。

测试：不仅要测“通不通”，还要测“对不对”

Zui后我想聊聊测试。hen多人写 LLM 接口的测试，只是发个请求，断言一下 status_code 是 200 就完事了。这其实是在自欺欺人。

比如下面这段测试，验的不是“错误接口有没有返回”，而是“返回的 request_id 是不是一个合法的 UUID”——这个区别hen重要，前者只是检查“有东西回来了”，后者是在检查“回来的东西结构对不对”：

import uuid
def assert_has_request_id -> None:
    request_id = payload.get
    assert isinstance
    assert request_id
    # 验证它真的是一个 UUID，而不是随便一个字符串
    assert str) == request_id

第一周结束时本地 pytest 跑通了 30 多条测试，覆盖健康检查、正常路径、错误映射、输入边界和 request_id 结构。数量不多，但够用——至少下周回来跑一遍，就知道之前Zuo的东西有没有被破坏。

敢交付的代码才是好代码

这三个坑根因各不相同，但共同指向一个教训：不要因为接口“Neng跑”就觉得它“没问题”。

Ru果你也在用 FastAPI 或者别的什么框架封装 LLM Neng力，这几件事值得对照kankan：

清洗输出： 永远不要直接信任 message.content，正则表达式是你的好朋友。

约束模型： Prompt 是建议，代码是法律，两者结合才Neng保证输出稳定。

统一错误： 标准化的错误响应Neng救命，特别是 request_id。

输入校验： 把校验逻辑收拢到模型层，别让它散落在各处。

同时我也给自己画了明确的边界——这一轮只统一 400 和 500 两类错误，不动 FastAPI 默认的 422 校验格式；只补Zui小的请求追踪链路，不搞完整的日志平台。项目体量还hen小，先把接口契约稳住收益远大于继续堆功Neng。

所以回到标题的问题：LLM 返回 200，Neng否直接展示结果？

我的答案是：绝对不Neng。 200 只是故事的开始，真正的考验在于你敢不敢把这段结果直接展示给你的用户。当你不再盯着状态码，而是盯着内容的“纯净度”和结构的“稳定性”时你才算真正跨过了 LLM 工程化的第一道门槛。

---