民宿房东半夜被消息淹没，我第一次给AI接客服却差点翻车
先说我踩过的坑
去年帮朋友的民宿预订平台做房东端自动回复，我信心满满：这不就是调个大模型 API、拼个 prompt 的事吗？三天就能上线。
第一版架构大概是这样：平台后端收到房客咨询 → 拼好 prompt → 直连某家大模型 API → 把回复推给房东确认。看起来干净利落。
两周后问题排着队来了：
坑一：模型不会说“人话”。 房客问“晚上十一点到可以入住吗”，AI 回了一段两百字的热情介绍，从房间设施聊到周边美食，就是不回答“可以”。房客等了三分钟，转手订了隔壁。
坑二：AI 开始编造。 有房客问“可以带宠物吗”，模型在没有任何数据支撑的情况下，自信地回答“可以携带小型宠物”——而这套房源明令禁止。房东第二天找我的时候，语气已经不太好了。
坑三：密钥管理一团糟。 我把 API Key 写在服务器环境变量里，后端日志里偶尔会打出完整的请求头。有一天额度突然被刷掉一大截，我到现在都不知道是泄露还是被爬。
坑四：换模型的代价出乎意料。 第一家模型对中文民宿场景的理解不太行，想换一家试试——结果发现请求格式、参数名、流式返回的结构全不一样，改了整整两天，中间还把线上服务搞挂了一次。
失败的根因：把“调 API”当成了“做系统”
复盘下来，第一版的错误不在于技术选型，而在于把一个业务系统简化成了一次 API 调用。自动回复 AI 的核心从来不是模型本身，而是：
- 上下文从哪来——房源信息、订单状态、退订政策，模型不知道这些就只能靠编；
- 边界在哪——哪些问题 AI 可以直接答，哪些必须转人工；
- 接入层谁管——密钥、计费、多模型切换、日志审计，这些不该散落在业务代码里。
想清楚这三点，重写的架构就顺了。
重构后的架构
房客消息
│
▼
消息网关（业务层）
│── ① 意图分类：闲聊/房源咨询/订单问题/投诉
│── ② 上下文组装：房源数据 + 订单数据 + 历史消息
▼
回复生成服务
│── ③ 受限生成：只允许基于注入的房源事实回答
│── ④ 置信度判断：低置信 → 转人工 + 通知房东
▼
统一 AI API 网关（这一层是关键，后面细说）
│── 密钥托管 / 用量配额 / 多模型路由 / 审计日志
▼
大模型（可随时切换供应商）对比第一版，多出来的不是复杂度，而是可控性。意图分类用便宜的小模型跑，只有真正需要生成回复的才走大模型，成本直接降了一半以上。
关键实现步骤
- 先做知识注入，再做生成。 把每个房源的结构化数据（入住时间、宠物政策、退订规则、周边交通）整理成固定格式的上下文块，prompt 里明确要求“仅基于以下信息回答，信息中没有的一律回复‘这个问题我帮您确认一下房东’”。这一条改完，编造问题基本消失。
- 建立转人工机制。 与其追求 100% 自动回复，不如定义清楚“哪些必须转人工”：投诉、退款、Ai 置信度低于阈值、房客连续两次追问同一问题。上线后大约 30% 的消息走人工，但房东的反馈反而更好——因为他们觉得系统“知道分寸”。
- 回复长度硬约束。 在 prompt 里限制“回复不超过三句话，先直接回答问题”，同时做后处理截断。即时通讯场景里，长回复等于没回复。
- 全部走统一 AI API 网关。 这是这次重构里对长期维护成本影响最大的决定，展开说说。
为什么统一 AI 网关能显著降低维护成本
第一版直连模型 API 时，我实际上把三件事捆在了业务代码里：
- 密钥生命周期管理：轮换密钥要发版，日志泄露风险自己扛；
- 供应商耦合：换模型等于重写接入代码，模型一年换代好几次，这个成本会反复发生；
- 成本可观测性缺失：不知道哪个功能烧了多少 token，优化无从下手。
接入统一网关后，这三件事全部从业务代码里剥离。业务侧只持有一个网关密钥，真实密钥托管在网关侧，轮换不需要动业务代码；网关把不同供应商的模型统一成一套请求格式，切换模型从两天的工作变成改一个模型名字符串；每个调用都带业务标签，后台能直接看到“自动回复”这个场景每天烧多少钱、命中了多少次。
对小团队来说，这相当于用很低的成本雇佣了一个“AI 基础设施维护员”。你可以把精力全部放在 prompt 调优、上下文工程这些真正产生业务价值的地方。
一个最小可行的流程清单
# 伪代码：房东自动回复的处理流水线
async def handle_guest_message(msg):
# 1. 意图分类（小模型，走统一网关）
intent = await ai_gateway.chat(
model="cheap-classifier",
prompt=f"分类以下民宿咨询: {msg.text}",
tag="intent-classify"
)
# 2. 非咨询类直接走规则
if intent in ("complaint", "refund"):
return transfer_to_host(msg, reason=intent)
# 3. 组装受控上下文
context = build_listing_context(msg.listing_id) # 房源事实数据
# 4. 生成回复（大模型，三句话硬约束）
reply = await ai_gateway.chat(
model="main-model",
prompt=REPLY_TEMPLATE.format(context=context, question=msg.text),
tag="auto-reply",
max_tokens=150
)
# 5. 置信度兜底
if reply.confidence < 0.7:
return transfer_to_host(msg, reason="low-confidence")
return send_to_guest(msg, reply)写在最后
这次重构给我最大的教训是：AI 应用失败的原因，大多不在模型，而在模型外面那一圈工程。上下文、边界、接入层，这三样做扎实了，普通模型也能干好活；做不好，再强的模型也会编造、会失控、会让你半夜爬起来改代码。
如果你也在做类似的 AI 应用，建议第一步就把接入层搭在统一网关上，别像我把密钥裸奔了两周才醒悟。可以从这里开始：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。