AI ENGINEERING · FIELD NOTE 001
AI 进入真实业务之后，
还有多少工程问题？
接入一个模型 API，往往只需要几行代码。让它稳定进入业务、面对真实用户，并且能够继续维护，才是 AI 应用工程真正开始的地方。
我参与过 AI 对话、内容创作、口语学习和模拟面试等产品。做得越多，越能感受到一个事实：模型能力决定产品上限，工程能力决定它能不能上线。
在演示环境里，我们关心模型能否回答、效果是否惊艳；进入真实业务后，问题会突然变得具体：供应商限流怎么办，流式连接中断怎么办，模型返回格式变化怎么办，敏感内容怎么处理，一次请求到底花了多少 Token，又怎样快速定位线上故障。
“能调用”是能力验证，“能长期运行”才是产品交付。
01 / CONTRACT
先建立统一的模型边界
不同模型供应商的鉴权、参数、流式协议、错误码甚至消息角色都不一样。如果业务代码直接理解这些差异，每接入一家供应商，就会多出一组判断和异常分支。
我更倾向于先定义稳定的业务接口，再通过 Driver 或策略实现隔离供应商差异。上层只表达“发起对话”“生成内容”或“统计用量”，具体怎样拼装请求、解析事件和映射异常，留在对应模型的实现内部。
这层抽象的价值不在于代码看起来整齐，而在于变化来临时，上层业务不用跟着一起重写。模型会变、价格会变、供应商也会变，稳定的边界能够把变化限制在可控范围内。
02 / STREAMING
流式响应不只是“逐字返回”
SSE 或 WebSocket 能让用户更快看到第一个字，但生产环境里的流式交互远不止输出片段。连接可能被用户取消、代理可能超时、供应商可能发送半截错误，业务还要知道一轮对话何时真正结束。
- 统一增量内容、结束信号和异常事件，让前端不必适配每家协议。
- 区分用户主动取消、网络中断和模型错误，避免把不完整内容当成成功结果。
- 在流结束后补齐消息落库、Token 统计和业务状态更新。
- 为首字延迟、整轮耗时和失败类型保留可观测信息。
真正可靠的流式接口，既要让用户觉得快，也要让系统知道发生了什么。
03 / CONTROL
密钥、限流与成本必须进入系统设计
当调用量上来以后，单个 Key 的额度和频率限制会直接影响业务稳定性。KeyPool 可以在多个密钥之间调度请求，但轮询本身并不是终点，还要处理暂时不可用、额度耗尽、并发隔离和故障恢复。
同时，每次调用都应该留下模型、用户、业务场景和 Token 用量。没有这些记录，就无法解释成本为什么上涨，也无法判断某个功能是否值得继续优化。
调度解决“能不能继续调用”，用量统计回答“这次调用值不值得”。两件事必须一起做。
04 / FOUNDATION
模型之外，还有一整套生产底座
AI 功能最终仍然运行在普通的软件系统里。用户、权限、订单、存储、缓存、数据一致性和第三方回调，一个都不会因为用了大模型而消失。
敏感词、生成结果审核与异步复检，形成可追踪的合规链路。
统一存储接口隔离本地、对象存储和不同云厂商，避免业务被基础设施绑定。
记录调用链、异常类型、Token、耗时和资源状态，让问题可以被定位。
模型不可用时明确失败边界，避免无限重试和故障扩大。
这些能力看起来没有模型输出那么直观，却决定了产品能否安全地面对用户，以及团队能否在问题发生后迅速恢复。
05 / CLOSING
把模型当能力，不要当全部
AI 应用工程不是把传统后端换成模型接口，而是在不确定的模型能力之外，重新建立确定的业务边界。越靠近真实用户，越需要把抽象、流式、成本、数据、安全和监控放在同一张图里考虑。
接下来我会继续拆开其中的具体问题：多模型抽象应该做到哪一层、流式协议怎样统一，以及 AI 辅助开发怎样真正进入日常工程。
— 老毕，写于杭州