把大模型接进业务系统，真正难的是这五件事

接第一个 AI 功能的时候，我以为难点在提示词。做完三个项目之后发现，提示词只占工作量的两成，剩下八成全是工程问题。

一、超时和重试

大模型接口的响应时间不是一个稳定值。同样一段文本，平时 2 秒，高峰期可能 30 秒还没吐完第一个字。如果你的业务接口默认超时是 10 秒，那线上一定会有偶发的失败。

我的做法是把超时分成两段：首字超时和总超时。首字超时给 8 到 12 秒，总超时按业务能忍受的上限给（我们这边是 60 秒）。首字迟迟不来，基本可以判定这次请求废了，直接切备用模型；总超时到了还没结束，退回同步兜底逻辑。

重试要小心。模型调用不是幂等的，重试一次就是一次真实计费。所以只在网络错误和 5xx 时重试，而且最多一次，超时不重试。

二、幂等

用户点一次"生成"，前端可能因为网络抖动发两次请求。如果不做幂等，你会生成两份内容、扣两次费，用户还会看到两条不一样的结果。

我们用一个请求指纹：用户 id + 业务对象 id + 输入内容的哈希。同一个指纹在 5 分钟内重复进来，直接返回第一次的结果。这个逻辑放在业务层，不要指望模型侧去重。

三、成本

第一版上线两周，账单比预期高了四倍。排查下来三个原因：

• 系统提示词写得太长，每次请求都带着，占了输入 token 的一半
• 没有区分模型，简单的分类任务也用最贵的模型
• 用户重复刷新页面，每次都重新生成

改完之后成本降了 70%：把系统提示词从 1800 token 压到 600，分类和抽取走小模型，生成结果按业务对象缓存半小时。

四、可观测性

线上出了问题，你得能回答：这次请求用了哪个模型、多少 token、耗时多少、返回了什么。只打一行"调用失败"是没法排查的。

我们记录四个字段：模型名、输入输出 token 数、首字延迟、总耗时。日志里不存完整正文（有隐私），只存哈希和长度。真要复现问题，用哈希去对象存储里捞。

五、灰度

模型升级、提示词改版，都会让输出风格变化。直接全量切，用户会明显感觉到"今天这个 AI 变笨了"。

我们用两层灰度：先给内部账号跑一天，看人工抽检通过率；再按用户 id 尾号放 10%、30%、100%。每一层至少观察 24 小时，重点看失败率和人工修正率，不是看调用量。

这五件事没有一件是"AI"的，但每一件都能让项目延期。模型选型反而是最简单的部分——现在的主流模型，做业务场景基本都够用。