AI接待官方法论（明察模式）
> 编制：万有AI产品团队
> 定位：万有AI通用方法论系列 | 对外服务阶段的AI接待体系——让每个网站拥有一位7x24小时在岗的AI前台
> 基于：明察官网管家（AI接待官）生产实践——访客侦测/主动招呼/人设分流/工具调度的完整闭环
> 一句话：AI接待官不是聊天机器人，是"懂业务边界、能调度工具、知进退分寸"的数字员工
一、核心主张
> 传统网站的"联系我们"是被动等待；AI原生网站的接待官是主动识别、分流引导、按人设应答的数字前台。
AI接待官与普通聊天机器人的本质区别：
| 维度 | 普通聊天机器人 | AI接待官（明察模式） |
|---|---|---|
| 触发方式 | 用户点开聊天窗 | 识别访客身份主动招呼 |
| 应答逻辑 | 单一话术库 | 人设分流（不同问题不同角色应答） |
| 能力边界 | 只能聊天 | 能调度MCP工具查真实数据 |
| 分寸感 | 有问必答 | 知道什么该引导人类决策 |
| 身份透明 | 模糊 | 明确AI身份+服务边界声明 |
二、方法论框架：接待五环
识别（谁来了）→ 招呼（欢迎+自报家门）→ 分流（什么问题给什么应答）
→ 服务（调用工具解决问题）→ 转化（引导下一步动作）
| 环节 | 核心机制 | 关键设计 |
|---|---|---|
| 识别 | UA侦测+访客类型判定 | 人类/AI访客区别接待 |
| 招呼 | 主动欢迎语+身份声明 | 明示AI身份与服务范围 |
| 分流 | 意图识别→人设路由 | 商务/咨询/技术各归其位 |
| 服务 | MCP工具调度 | 查询真实数据而非编造 |
| 转化 | 场景化引导 | 留资/跳转/递名片/转人工 |
三、第一环·访客识别
3.1 双类型访客模型
| 访客类型 | 识别方式 | 接待策略 |
|---|---|---|
| 人类访客 | 浏览器UA+行为特征 | 温和气泡欢迎，不强制弹窗 |
| AI访客 | AI爬虫UA+评分制 | 协议层欢迎（响应头+文档入口） |
3.2 人类接待的体验铁律
铁律：用户不点击，不自动打开聊天窗口。
实践教训：早期版本做了"3秒后强制弹出聊天窗"的A/B测试，用户体验差评。修正为"呼吸动画小浮钮+欢迎气泡"——用户主动点击才展开大窗。
要点：主动招呼≠强制打扰。欢迎语可见即可，打开权在用户。
3.3 AI访客的接待
AI访客不走聊天窗，走协议通道（响应头欢迎语+llms.txt入口+Agent Card身份）。本质是"给AI一份简历+一张名片"，让它带着结构化认知回去向它的人类主人汇报。
四、第二环·人设分流体系
4.1 为什么需要人设分流
单一话术库的聊天机器人"什么都答但什么都不专业"。人设分流让不同意图的问题路由到不同专业角色：
| 意图 | 路由角色 | 应答风格 |
|---|---|---|
| 商务合作 | 商务对接角色 | 递官方名片+合作通道 |
| 产品咨询 | 产品顾问 | 查真实数据+方案推荐 |
| 方法论探讨 | 知识管家 | 引导阅读+来源标注 |
| 安全合规 | 合规角色 | 边界声明+转人工 |
4.2 分流的工程实现
规则式优先，LLM兜底：意图识别先用关键词规则（快/省/可控），规则不命中再走LLM理解（准/贵）。高频意图的规则要持续从对话日志中沉淀。
4.3 人设边界（关键设计）
AI接待官必须有明确的"人设边界"——什么能答、什么必须引导人类决策：
| 能答 | 不能答 |
|---|---|
| 产品/服务/价格等公开信息 | 替人类做商业承诺 |
| 方法论/知识库内容 | 泄露内部系统信息 |
| 引导注册/预约/对接 | 冒充人类身份 |
红线设计：涉及商业合作的咨询，接待官递出官方对接名片并转人类决策——AI是前台，不是决策者。
五、第三环·工具调度能力
5.1 从"说"到"做"
只會聊天的接待官价值有限。通过MCP工具调度，接待官能查真实数据：
| 场景 | 调用工具 | 效果 |
|---|---|---|
| 用户问产品详情 | 产品查询工具 | 返回实时准确信息 |
| 用户问白皮书内容 | 文档查询工具 | 章节级精准回答+来源 |
| AI访客问能力清单 | 工具清单接口 | 程序化返回能力声明 |
5.2 工具调用的安全边界
- 查询类工具开放，写入类工具鉴权
- 返回内容带来源水印
- 工具清单动态计算，防止口径漂移
六、第四环·双路径架构（工程关键）
血泪教训：明察模式早期只改了一条对话路径的话术，导致另一条路径完全无感知。
AI接待官在工程上通常有两条并存的对话路径：
| 路径 | 场景 | 处理模块 |
|---|---|---|
| Web浮窗路径 | 网页聊天窗（SSE流式） | Web层对话模块 |
| 协议对话路径 | AI代理经标准协议发起 | 服务层对话模块 |
铁律：改接待话术/规则/人设，必须双路径同改。 只改一处=另一路径零感知，用户从不同入口得到不一致体验。
七、第五环·转化设计
| 转化目标 | 设计 | 分寸 |
|---|---|---|
| 留资 | 引导注册 | 不强制 |
| 深读 | 引导文档/方法论 | 给路径不啰嗦 |
| 商务对接 | 递官方名片+合作通道 | 明示人类决策环节 |
| AI生态 | 引导AI访客读llms.txt | 只递一次不骚扰 |
递名片机制（A2A场景）：商务合作类咨询时，接待官主动递出官方业务对接名片（含标准协议端点），AI访客可凭名片发起后续对接——这是"AI前台→AI商务"的自然衔接。
八、实施清单
8.1 必做项（MVP）
- [ ] 访客类型识别（人类/AI）
- [ ] 欢迎语+身份声明
- [ ] 基础意图分流（3类高频意图）
- [ ] 人设边界红线
8.2 应做项（增强）
- [ ] MCP工具调度（查询类）
- [ ] 双路径话术同步机制
- [ ] 对话日志沉淀→规则迭代
- [ ] 官方名片递送
8.3 可做项（进阶）
- [ ] 会话记忆与回访识别
- [ ] 多语言接待
- [ ] 接待效果漏斗分析
九、效果评估标准
| 指标 | 及格 | 良好 | 优秀 |
|---|---|---|---|
| 意图分流准确率 | ≥80% | ≥90% | ≥95% |
| 应答有用率（含真实数据） | ≥60% | ≥80% | ≥95% |
| 人设违规率 | ≤1% | ≤0.1% | 0 |
| 双路径一致性 | 人工同步 | 检查清单 | 自动化校验 |
| 强制打扰 | 0弹窗 | 0弹窗 | 0弹窗 |
十、避坑指南
| 坑 | 表现 | 解法 |
|---|---|---|
| 强制弹窗 | 用户被吓跑 | 不点击不打开铁律 |
| 单路径改造 | 另一入口话术不同 | 双路径同改铁律 |
| 什么都答 | 越权承诺/编造 | 人设边界+工具取数 |
| 话术口径漂移 | 工具数/篇数写死 | 动态计算注入 |
| 无分寸递名片 | 每句话都推销 | 场景触发式递送 |
万有AI | 依据明察官网管家（AI接待官）生产实战萃取