Chatwoot 上下文注入设计
1. 执行摘要
当前阶段，AOVIS 最合理的做法不是把 Chatwoot 接成一个“大而全客服中台”，而是先做已登录用户的最小业务上下文注入。
目标很明确：
- 让客服看到“这是哪位已登录用户”
- 让客服看到最少但足够有用的订单 / 发货 / 套餐 / 保修上下文
- 不把业务主数据库直接暴露给 Chatwoot
- 不在第一阶段做 AI 知识库或大规模实时同步
2. 当前阶段的判断
当前更适合的模式是：
- 页面加载后按登录状态拉取一次最小上下文
- 后端做字段映射与最小暴露
- 前端 widget 只负责把用户身份同步到 Chatwoot
不建议现在就做：
- 直接连业务主库
- 大量 webhook 同步
- 复杂实时事件流
- 自动退款或自动售后决策
3. 推荐架构
3.1 最小架构
- 前端：在 Chatwoot widget 初始化时同步登录状态
- 后端：新增 Support Context API
- 中间层：只输出 Chatwoot 需要的最小字段
- Chatwoot：只接收展示和客服需要的上下文
3.2 为什么要有中间层
中间层的作用是：
- 做字段映射
- 做权限控制
- 做最小暴露
- 避免 Chatwoot 直接触碰敏感表
4. 分阶段落地
Phase 0：最小登录用户上下文注入
当前优先级最高。
实现方式：
- 新增
Support Context API - 前端 widget 在登录后同步用户身份
- Chatwoot 侧只展示最小信息集
Phase 1：字段补强 + 基础知识库
在 Phase 0 稳定后，再补：
- 订单号
- tracking number
- 保修状态
- 云存储 / cellular plan 状态
Phase 2：AI / tool calling
等前两阶段稳定后，再考虑：
- 知识库问答
- 工具调用
- 更复杂的客服自动化
5. 最小数据模型
建议只保留以下属性：
- Contact Attributes：客户基础信息
- Conversation Attributes：订单 / 发货 / 套餐 / 保修状态
- Reserved Fields：未来可扩展字段
不要在第一阶段暴露：
- 业务主库的完整表结构
- 敏感内部字段
- 不需要的遥测数据
6. 典型客服场景
第一阶段应该优先覆盖这些问题：
- 我已经下单了，为什么还没发货
- 我收到了货，但激活不了
- tracking number 在哪里
- 我为什么看不到云存储
- cellular plan 是否有效
- 我买的是哪个 SKU
- 我现在还在不在保修期内
- 我要退款 / 售后咨询
7. 实施检查清单
前端
- widget 需要能同步登录状态
- 未登录用户和已登录用户要区分处理
后端
- 提供 Support Context API
- 只返回最小必要字段
- 对外部请求做鉴权
Chatwoot 配置
- 配置 widget
- 配置 inbox
- 配置支持入口文案
8. 风险与反模式
不要在当前阶段做：
- 大而全客服中台
- 直接连业务主数据库
- 匿名访客也查业务上下文
- 设备遥测接入
- 自动答复 / 自动退款决策
9. 最终建议
当前阶段最合理的顺序是：
- 先让客服界面不再匿名
- 再补订单 / 发货 / 套餐 / 保修字段
- 最后再考虑知识库和 AI 自动化