本节面向使用「群聊答疑专员」搭建客服答疑场景的团队，包含场景配置方法和运营实践。「Q仔」是阿里内部基于该功能搭建的 Qoder 产品答疑案例，不是独立的产品功能。
场景目标与处理原则
客服答疑场景通常服务产品支持群、客户服务群或内部服务群。群内问题既包括已有知识，也包括新口径、例外情况和需要产品、技术或业务专家判断的问题。
配置目标不是让群聊答疑专员在所有情况下直接作答，而是建立一条可持续的处理链路：
- 有可靠知识依据时，在群内直接回答。
- 知识不足、依据冲突或超出能力边界时，说明暂时无法确认，并向对应专家求助。
- 获得专家确认后，将答案返回原群。
- 将确认过的新口径沉淀到知识库，供后续同类问题复用。
客服答疑的处理原则：能确认时直接回答，不能确认时向专家求助，并将结果带回原群。
客服答疑场景配置
| 配置项 | 推荐配置 | 配置要点 |
|---|
| 角色与范围 | 使用「群聊答疑专员」模板创建 Waker，并设置与服务场景一致的名称 | 在简介、基础设置和回复设置中明确服务对象、问题范围和拒答边界，不将推测表述为事实 |
| 机器人与群聊 | 配置 IM 机器人，先接入测试群，再逐步接入正式服务群 | 使用配对模式控制接入范围；每接入一个新群，都先验证收消息、回复和记录链路 |
| 知识库 | 绑定产品文档、常见问题、版本说明、服务流程和已确认答疑口径 | 只保留当前有效资料；相互冲突的版本或不同业务口径分开维护 |
| 专家 | 按问题类型配置产品、技术、服务或业务专家 | 专业标签应直接对应问题类别；避免“综合专家”等过宽标签 |
| 回复方式 | 使用自然、简洁的群聊表达 | 先回答结论，再补充必要依据；无法确认时说明原因和下一步，不使用生硬的固定客服话术 |
| 答疑记录 | 持续查看未回复、失败、专家协助和低质量回答 | 根据记录调整知识资料、专业标签、回复边界和群聊接入范围 |
- 已知问题：确认能够依据知识库直接回答。
- 未知问题：确认不会编造答案，并能够进入专家协助流程。
- 越界问题：确认能够说明不在服务范围内，不混入其他业务口径。
最佳实践案例：Q仔
Q仔是阿里内部面向 Qoder 产品答疑群搭建的群聊答疑专员。本案例用于说明客服答疑场景如何落地，不代表所有团队都需要使用相同名称、知识或专家配置。
Q仔沿用前述客服答疑场景配置，并按 Qoder 产品支持特点做以下设置：
| 配置项 | Q仔实践 |
|---|
| 服务范围 | 处理 Qoder 的安装、账号、功能、版本和常见使用问题；超出范围时不直接给出结论 |
| 接入群聊 | 先在测试群验证，再分批接入 Qoder 产品答疑群 |
| 知识资料 | 使用 Qoder 产品文档、FAQ、版本说明、已知问题和专家确认后的答疑口径 |
| 专家配置 | 按“安装与环境”“账号与权限”“产品功能”“版本与兼容性”等问题类型设置专业标签 |
| 回复方式 | 使用自然、简洁的群聊表达；能确认时直接回答，不能确认时说明原因并向专家求助 |
| 持续维护 | 抽查答疑记录，将专家确认的新口径沉淀为知识，并及时修正过期内容 |
组织知识：区分标准知识和场景知识
客服答疑中常同时存在两类知识：
| 知识类型 | 示例 | 维护建议 |
|---|
| 标准产品知识 | 产品支持哪些功能、如何安装、某版本包含哪些能力 | 由产品或文档负责人维护，版本变化后及时更新 |
| 场景或组织知识 | 内部申请流程、负责人、特殊审批规则、客户侧约定 | 由对应业务专家确认；不同团队或客户的内容分开存放 |
专家协作：答不上时继续推进
为每位专家配置清晰的专业标签，例如“安装与环境”“账号与权限”“产品功能”“版本与兼容性”。出现知识不足、证据冲突或需要人工判断的问题时，群聊答疑专员按标签选择专家。
专家只需确认、补充或纠正答案，不必接管整段群聊。确认完成后，群聊答疑专员将结果返回原群，让提问者在原会话中得到完整答复。
将已确认答案沉淀为新知识
专家协助不应只解决当前问题。对于可复用的答案，按以下方式维护：
- 保留原问题、适用范围、确认答案和确认人。
- 将答案整理为可独立理解的知识条目，补充版本、时间或组织范围。
- 发现旧知识错误或过期时，同步修正或下线，不并列保留冲突口径。
- 使用相同问题的另一种说法复测，确认后续能够直接命中。
专家确认一次后，将答案沉淀为知识，后续同类问题可以直接复用。
群聊回复方式
群聊答疑专员在群内应像一位熟悉业务、懂分寸的同事，而不是照读客服话术：
- 结合当前群聊上下文理解省略信息和连续追问。
- 优先给出简短结论，只补充与当前问题相关的步骤或依据。
- 可以自然回应轻松交流，但应及时回到问题本身。
- 不确定时直接说明，不用模糊表述掩盖信息不足。
- 涉及风险、权限或例外判断时，优先交由专家确认。
可复用的客服答疑场景
| 场景 | 建议知识 | 建议专家 | 重点验证 |
|---|
| 产品支持群 | 产品文档、FAQ、版本说明、已知问题 | 产品经理、技术支持 | 版本口径是否准确，未知问题是否转专家 |
| 客户服务群 | 标准产品知识、客户约定、客户侧流程 | 产品方和客户方专家 | 不同客户知识是否隔离，答案是否符合客户实际 |
| 内部服务群 | 制度、流程、权限和办理指南 | 业务负责人、IT 或职能专家 | 规则变更后是否及时更新，敏感问题是否正确转交 |
| 项目交付群 | 实施手册、项目约定、交付记录 | 交付经理、解决方案专家 | 是否区分通用方案与项目特例 |
上线与持续运营
先选择一个问题范围明确、专家响应稳定的测试群试运行。验收通过后，再逐步扩大群聊和问题范围。
上线后定期抽查答疑记录，重点关注知识内问题是否答对、知识外问题是否正确求助、专家答案是否回到原群，以及已确认答案是否完成沉淀。每次修改知识库、专家、回复设置或机器人配置后，都应重新验证一条已知问题和一条未知问题。
