如果要设计蚂蚁金服内部自动客服系统，如何定义用户场景、能力边界、流程和评估指标？｜蚂蚁集团产品面经解析

60 秒回答模板

我会先限定这是内部自动客服系统，不假设任何公司真实内部实现。产品目标是让员工或内部业务同学在 IT、HR、财务、合规、流程制度、系统使用等问题上更快获得可信答案，并在无法自动解决时顺畅转工单或人工。第一步做场景分层：高频问答适合 FAQ/RAG，流程办理适合表单和工作流，账号权限类需要身份校验和审批，政策合规类需要引用来源和人工兜底。第二步定义能力边界：系统可以做意图识别、知识检索、答案生成、材料补全、工单创建、进度查询和多轮澄清；不能越权查看敏感信息，不能替用户做高风险审批，不能在低置信时编答案。第三步设计流程：用户提问后识别身份和权限，再做意图分类与必要澄清，检索企业知识库和业务系统，生成带来源的回答；需要动作时调用工单、审批或查询工具；低置信、敏感高风险或用户不满意时转人工并带上上下文。第四步看指标：自助解决率、首响时间、平均解决时长、答案准确率、引用命中率、转人工率、重复咨询率、满意度、人工节省、违规回答率和敏感数据泄露风险。

考点 场景分层

难度 真实面经题

回答目标 展示企业级 AI 产品设计能力：能把内部自动客服拆成场景、知识、权限、流程、指标和运营闭环。

深入解析

定义内部用户和任务

内部自动客服用户可能是普通员工、业务运营、客服坐席、技术支持或管理者。典型场景包括制度查询、报销流程、账号权限、办公系统故障、审批进度、知识库检索、内部工具使用和跨部门咨询。产品要先拆分问答型、查询型、办理型、审批型和故障型任务。

知识可信比流畅更重要

企业内部客服不能只追求回答像人，而要回答有依据、可追溯、可更新。知识来源包括制度文档、FAQ、SOP、工单历史、系统帮助中心和业务接口结果，并要有版本、owner、有效期和权限标签。

权限安全是核心能力

内部系统涉及员工信息、组织权限、审批记录、财务数据和业务敏感信息。用户能问到什么、系统能查到什么、模型能看到什么、回答能展示什么，都要按角色和场景控制。高风险动作应通过现有审批或人工确认完成。

流程覆盖自动和人工

完整链路可以是：入口统一接入聊天窗口或内部工作台，身份识别和意图分类，必要时澄清，随后检索知识库或调用内部系统，生成结构化回答或办理建议。低置信、用户否定、超时未解决、敏感高风险和多轮失败都应进入人工升级。

指标分效果、效率和风险

效果指标包括自助解决率、一次解决率、答案准确率、引用命中率、满意度和重复咨询率；效率指标包括首响、平均解决时长、人工时长下降、工单补全率和单位咨询成本；风险指标包括错误引导、违规回答、越权访问和敏感信息泄露。

运营闭环决定长期质量

上线后要持续做 badcase 归因，区分知识缺失、召回错误、意图分类错、权限拦截不合理、工具调用失败或模型生成不稳。每类问题对应补文档、改索引、重写 SOP、优化 prompt、修接口或调整人工分流。

易错点

把内部自动客服答成外部 C 端通用客服，忽略员工权限、内部系统和组织流程。
只讲 LLM 问答，不讲知识治理、来源引用、权限校验、工单流转和人工升级。
把所有问题都自动处理，忽略审批、合规、财务、账号安全等高风险场景必须兜底。
指标只写满意度或响应时间，不分解决率、准确率、效率、成本和安全风险。

面试官追问

为什么不能只做一个大模型聊天框？

内部问题涉及权限、制度版本、业务系统状态和流程动作，单纯聊天框无法保证答案可信、动作合规和问题闭环。模型应放在知识检索、工具调用、工单流转和安全审计之中。

如何处理模型回答不确定？

用检索置信度、答案一致性、问题类型和风险等级判断。低置信或高风险场景应澄清、展示候选路径、转人工或创建工单，避免模型编造制度或流程。

MVP 怎么设计？

先选高频、低风险、知识边界清晰的场景，如制度 FAQ、系统使用说明、工单进度查询和标准流程指引。先证明首响、解决率和人工减负，再接入复杂办理。

如何让人工客服愿意使用？

系统要减少重复劳动，例如自动总结问题、补全工单字段、推荐知识条目、给相似历史案例，并让人工修正回流到知识库和评测集。