深夜十一点半的房客咨询 - 民宿房东自动回复AI的一次落地复盘
一、业务痛点：房东不是客服，但房客以为他是
我管理着一个五人小团队，为几家民宿运营方做系统支持。去年接到一个需求：房东们最头疼的不是打扫卫生，而是消息。
具体场景是这样的：房客下单前后会问一堆问题——“停车位怎么进？”“能提前寄存行李吗？”“附近有什么好吃的？”这些问题集中在两个时段：晚上九点到十二点，以及早上七点前。而房东自己也在睡觉，或者正在另一套房子里忙活。回复慢了，订单取消率上升；雇人值班，成本又压不住。
人工客服方案的报价我们算过账：三家民宿、日均咨询约六十条，雇一个兼职夜班客服每月成本在四千元左右，而且培训成本高、流动性大、回答口径不统一——上一任客服说“可加床”，下一任说“不可加床”，产生的纠纷最后都回到房东头上。
痛点可以归纳为三条：
- 响应时间不可控：夜间与清晨的咨询几乎全部超时；
- 回答口径不统一：不同人的回答存在事实漂移，引发客诉；
- 风险无法集中管控：涉及退款、押金、安全承诺的问题，人工回答随意性大。
这三条决定了我们做自动回复AI的设计重心：不只是“回得快”，而是“回得准、回得有边界、回得可追溯”。
二、架构设计：管理者最关心的三个问题
从管理视角出发，我给团队定的设计约束不是“用哪个模型”，而是先回答三个问题：
谁负责知识？谁负责兜底？谁负责审核？
对应的架构分四层：
- 消息接入层：对接各民宿平台的开放接口或 IM 通道，统一转成内部消息格式。这一层的关键设计是消息打标——来源渠道、房源ID、紧急程度随消息一起流转，后面每一层都能读到。
- 意图路由层（AI 判定）：用一次轻量模型调用做意图分类，把消息分成四类——事实咨询（可自动回）、预订协商（自动回+抄送房东）、投诉与安全（直接转人工）、闲聊（礼貌简答）。这一层是风险控制的核心：退款、押金、人身安全类关键词直接走人工通道，AI 不碰。
- 知识增强生成层（RAG）：每套房源维护一份结构化知识库（入住须知、设施清单、周边指南），AI 回答必须基于检索到的知识片段，回答里附带“依据来源ID”。没有检索到依据的问题，AI 只能说“我已记录，房东会尽快回复”，不允许自由发挥。
- 审计与兜底层：所有自动回复落库，每日生成审计报表；置信度低于阈值、或房客连续追问两次相同问题的会话，自动升级给房东。
三、关键实现步骤
流程清单如下：
- 梳理三家民宿的高频问题清单（从历史聊天记录人工归纳，约120条），确定意图分类体系；
- 为每套房源编写结构化知识文档，约定“无依据不回答”的硬规则；
- 搭建消息接入层与统一消息格式，跑通一个渠道的内环测试；
- 配置意图路由：编写风险关键词表，明确哪些必须转人工；
- 接入 AI API 网关，统一管理多家模型的调用、密钥与用量；
- 灰度上线：前两周 AI 只起草、房东点发送，对比 AI 草稿与房东修改的差异率；
- 差异率稳定后开启自动发送，但保留每日报表与抽样审核机制；
- 建立知识库更新流程：房东改了设施（比如新买了烘干机），一条消息触发知识文档更新，次日生效。
其中第6步是管理者必须坚持的：AI 先当助手，再当自动机。灰度期的差异率数据，是说服房东信任系统的最好材料。
核心路由代码示意（简化版）：
async def handle_message(msg):
intent = await classify_intent(msg.text) # 意图分类
if intent.has_risk_keywords(RISK_LIST): # 退款/押金/安全
return escalate_to_host(msg)
if intent.type == "factual":
chunks = knowledge_base.search(msg.house_id, msg.text)
if chunks.score < CONFIDENCE_THRESHOLD:
return mark_pending(msg) # 无依据，不乱答
answer = await generate_with_citations(msg.text, chunks)
audit_log.record(msg, answer, chunks) # 全量落库
return auto_reply(msg, answer)
return escalate_to_host(msg)四、为什么统一 AI API 网关能降低维护成本
上线三个月后，我们对架构做了一次调整：把所有模型调用收口到统一的 AI API 网关。原因很实际：
模型会换，业务代码不该跟着改。 我们的事实问答用一个大模型，意图分类用一个小模型，后期还想试试更便宜的新模型。如果每个调用点直连各家厂商 SDK，换一次模型就要改三处代码、测三遍。收口到网关后，模型切换只是网关侧改一个配置，业务代码里的调用地址和参数格式完全不变。
密钥与权限集中管理。 团队里三个人都会写调用代码，密钥散落在各处迟早出事。网关统一持钥、统一计费，我作为管理者能在后台看到每个房源、每个功能的调用量与成本，月底结账不用再对一堆账单。
降级与限流在一处做。 某家模型服务波动时，网关自动切备用模型；调用量异常时自动熔断。这些逻辑写在网关层，业务代码零感知。
一句话总结：网关把“模型选型”从开发问题变成了管理问题——这正是小团队最需要的分工。
五、落地效果与经验
灰度两个月后全自动开启。夜间咨询的首响时间从平均两小时以上降到一分钟内；因回答口径不一致引发的客诉基本消失；AI 无法回答而转人工的比例稳定在15%左右——这个数字反而成了知识库更新的路标：哪类问题转人工多，就说明哪部分知识文档要补。
最大的经验教训：先建风险边界，再追求回复率。自动回复覆盖85%的常规咨询已经很值了，剩下15%交给人工，比让AI硬答要安全得多。
如果你也在为小团队选型AI接入方案，想用一套统一的网关管理多模型调用、集中控密钥和用量，可以先在 https://api.thistoken.ai/register 注册体验，把模型管理的成本从代码里挪到后台配置里。
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。