先别急着“接模型”

很多人以为做 AI 应用，就是后端发一个请求给大模型，再把回答吐给用户。真上线才发现，问题不在“能不能回”，而在“回错了怎么办、卡住了怎么办、该不该让它操作业务”。

我的判断是：AI 后端不是接口工程，而是一套秩序工程。尤其对内容、教育、咨询类业务来说，AI 不是来炫技的，它要稳定地帮人答疑、分流、检索、生成、提醒，同时不能乱说、乱查、乱操作。

第一层：先分流，不要什么都问模型

用户一进来，不要直接丢给大模型。先判断问题类型。

可以粗分成四类：

  1. 问常识：让模型直接回答，但要限制口径。
  2. 问资料：先查知识库，再回答。
  3. 问个人状态：必须走业务系统，比如订单、课程、作业、进度。
  4. 要执行动作：必须确认，比如改信息、发通知、提交表单。

这一步很重要。因为模型不是万能前台，它更像一个会说话的调度员。调度员要先知道这件事该找谁办。

第二层：知识库不是仓库，是“可引用的口径”

很多人做 RAG，只是把资料塞进向量库。结果 AI 回答看似丰富，其实东拼西凑。

真正有用的知识库，要按“可回答问题”来整理，而不是按“我有什么文件”来堆。比如教育场景里，课程介绍、报名规则、退费规则、学习建议、常见问题，应该拆成清晰模块，每段都有边界。

一个简单标准：如果这段资料不能支撑一句明确回答，就不要直接入库。知识库越乱，AI 越像在蒙。

第三层：业务接口要有边界

当 AI 要查课程进度、生成学习计划、提醒用户补作业时，就进入业务接口调用。

这里最容易出事。原则很简单：能读的可以自动读，能改的必须确认，高风险的必须二次确认。

比如“帮我改手机号”“帮我取消报名”“帮我发给全部学员”，这些不能让 AI 一句话就执行。后端要把操作拆成：识别意图、展示影响、用户确认、再执行。

AI 可以建议，但不能无权限决策。

第四层：流式输出解决体验，不解决质量

SSE 流式输出很适合 AI 产品，因为用户不用等一大坨文字生成完。但不要误会，流式只是体验层优化，不是工程质量本身。

真正要做的是：开始生成前告诉用户正在处理；生成中能中断；失败时能兜底；涉及资料时能说明依据；涉及操作时能停下来等确认。

对普通业务来说，这比“回答更聪明”更重要。用户不怕 AI 慢一点，怕它装懂、乱来、没交代。

第五层：日志和兜底是上线底线

AI 应用必须记录几个关键点：用户问了什么、系统怎么分流、查了哪些资料、调用了哪些接口、模型返回了什么、最后有没有报错。

这不是为了监控员工，而是为了复盘问题。否则一旦用户说“AI 刚才乱答了”，你根本不知道是哪一层出错。

兜底也要提前设计：知识库没查到，就说没查到；接口失败，就提示稍后再试；问题高风险，就转人工或要求确认。不要让模型硬编一个体面的答案。

可落地的六步清单

  1. 先列出用户最常问的 20 个问题。
  2. 把问题分成常识、资料、个人状态、执行动作。
  3. 给每类问题设定回答边界和禁止事项。
  4. 把资料按问答场景整理进知识库。
  5. 对业务接口区分“只读”“可修改”“高风险”。
  6. 上线前补齐日志、错误提示、人工兜底。

最后一句话：接 AI 不是把模型接进系统，而是把不确定性关进流程里。谁能把这套流程做稳，谁才真正拿到了 AI 提效的红利。