现在很多产品都想加一点 AI 能力。摘要、问答、分类、生成报告、自动填表，看起来都是“调一下模型接口”。真接进业务系统以后，会发现它更像一条异步工作流，而不是一个普通 HTTP 请求。

前端首先要接受一件事：AI 响应不稳定。

这里的不稳定不是说质量一定差，而是耗时、长度、格式、失败方式都比传统接口更难预测。普通接口要么成功要么失败，AI 功能可能会流式返回、返回半截、格式不符合预期、内容需要二次确认。前端交互如果还按“点按钮，等结果，展示文本”来设计，很快就会显得粗糙。

比较舒服的交互通常会有几个状态：排队中、生成中、可编辑、可重试、已确认。尤其是生成类功能，结果最好不要直接写入业务数据，而是先成为一份草稿。用户确认以后，再落库。

后端也不应该只是把前端请求转发给模型。

模型调用前要做输入清洗、权限检查、上下文组装；调用中要处理超时、重试、限流；调用后要做结构校验、敏感内容过滤、结果存档。中间任何一步失败，都要能给前端一个明确状态。

如果任务超过几秒，我更倾向于放进队列。

前端创建任务，后端返回 taskId。之后通过轮询、SSE 或 WebSocket 拿进度。这样用户刷新页面也能恢复任务状态，后端也能控制并发，不会因为几个长请求把服务拖住。

一个常见的数据流是：

用户提交输入
-> 后端创建 AI 任务
-> 队列消费任务
-> 组装上下文并调用模型
-> 校验和清洗结果
-> 保存草稿
-> 前端展示草稿并等待确认

这条链路看起来比直接调用麻烦，但它更符合真实业务。因为业务系统关心的不只是“模型说了什么”，还关心这段内容是谁生成的、基于什么材料、有没有被用户确认、失败后能不能重试。

LangChain 这类工具适合放在后端编排层。它可以帮你组织 prompt、retriever、tool calling 和输出解析。但它不应该替代业务状态机。任务状态、权限、审计、落库，这些仍然是业务系统自己的责任。

我觉得 AI 功能落地有一个很实用的原则：模型输出先当建议，不要直接当事实。

前端给用户编辑和确认空间，后端保留来源和日志，系统设计上允许失败和重试。这样 AI 能力会更像一个可靠的助手，而不是一个藏在按钮后面的黑盒。

真正做产品时，这些“周边工程”往往比 prompt 本身更重要。