先说结论
小程序 AI 客服不是“接个聊天接口”就完了。真正可落地的方案，至少要同时考虑：会话体验、业务问答、知识库召回、回复边界、人工兜底、统一模型入口和调用成本。如果你后面还有官网、后台、公众号等多个入口，最好一开始就通过 AI Gateway 把模型调用统一起来。
很多团队想在微信小程序里加 AI 客服，第一反应都是做一个聊天框接大模型。但真正上线时，问题很快就会变成：怎么区分闲聊和业务问答？怎么接知识库？怎么控制成本？怎么保证回复不要胡编？如果后面还要接官网客服、后台助手和企业知识库，那就更不适合每个端都单独乱接模型。
小程序 AI 客服不是“接个聊天接口”就完了。真正可落地的方案，至少要同时考虑：会话体验、业务问答、知识库召回、回复边界、人工兜底、统一模型入口和调用成本。如果你后面还有官网、后台、公众号等多个入口，最好一开始就通过 AI Gateway 把模型调用统一起来。
因为用户在小程序里提的问题，很多都和业务直接相关，比如价格、预约、售后、流程、规则、订单状态、资料说明。它不像纯聊天应用那样可以随便发挥，答错就会直接影响转化和客服体验。所以小程序 AI 客服更像一个“带业务边界的问答系统”，而不是单纯的对话玩具。
最基础的做法，是小程序把用户输入发给后端或云函数，再由后端调用模型接口返回回答。这一层适合先跑通聊天能力、欢迎语、意图识别和简单问答。
如果你想让它回答业务问题，而不是泛泛而谈，就不能只靠模型“自由发挥”，而要把产品文档、FAQ、流程说明、售后规则等资料纳入知识库系统，通过 RAG 或检索增强方式作答。
这套结构的好处是：你后面不止能服务小程序，还能顺手复用到官网、后台、公众号甚至企业微信场景。
因为很多团队一开始是在小程序里直接绑某一家模型接口，后面官网也接一个、后台也接一个、知识库平台再接一个。时间一长，Key、Base URL、模型版本、限额和日志都散掉了。用 AI Gateway 的价值就在于：
Base URL: https://api.bangban.xin/v1
这些问题里，只有少数适合纯模型直接回答，绝大部分更适合基于业务知识库来答。
像“你们是做什么的”“怎么收费”“能不能帮我推荐方案”这类问题，可以通过提示词 + 会话记忆 + 结构化回答模板处理，让回复更稳定、更像客服，而不是东一句西一句。
像“退款规则是什么”“资料准备哪些”“企业版支持什么权限”这类问题，更适合走检索增强链路，先找资料，再让模型基于资料回答，必要时支持引用来源或推荐人工咨询。
这样做比反复换模型更有效，也更接近业务结果。