7.8
深览指数
产品人人都是产品经理·我叫小米粒··AI 生成
AI客服上线后为什么越用越“不准”？复盘一个课程咨询助手的持续运营
本文以课程咨询助手为案例，复盘了AI客服上线后从“能回答问题”到“完成服务”的转变过程。核心结论是：AI智能体产品并非一次性交付，而是需要持续运营的服务。文章拆解了任务分类、知识库治理（控制库与证据库分离）、只读连接业务系统，以及建立持续迭代闭环等关键设计原则。适合正在或准备将AI客服/智能体投入实际业务，并关注其长期效果和可维护性的产品经理、运营和技术负责人阅读。原文 ↗
核心观点
- ▍智能体是否能长期产生价值，不取决于上线时回答得多漂亮，而取决于业务变化后，它是否仍然可维护、可追踪、可复核，并能随着真实需求持续演进。
- ▍AI客服的真正升级是从“回答问题”转向“完成服务”，核心是建立任务分类、知识运营、受控工具连接和持续迭代的闭环。
- 01用户真实提问并非标准测试题，会出现“知识已变化”（如课程时间调整）、“需要实时状态”（如报名审核进度）、“输入形式超出预期”（如图片识别）、“需要上下文”（如重复沟通历史）等四类问题。
- 02团队将课程咨询任务拆分为四类：课程知识、业务状态（需查询CRM）、材料处理（需OCR/Skill）、人工服务（退款、投诉等）。
- 03知识库被拆分为“控制知识库”（存放稳定规则，如转人工条件）和“证据知识库”（存放业务材料，每份资料带负责人、有效状态和更新时间），以解决新旧内容冲突。
- 04通过只读MCP Server连接报名系统，只开放查询（提交状态、审核进度、更新时间），不开放修改操作，以控制业务风险和权限。
- 05建立持续运营闭环：查看真实使用记录 -> 判断问题属于哪一层（知识库、路由、Skill、MCP接口等）-> 形成修改建议 -> 加入回归测试。
- 06产品指标从“回答次数”升级为四组指标：任务理解指标、知识与工具指标、服务结果指标（是否真正解决、转人工上下文）、能力演进指标。
反方 / 局限
- — 本文的核心前提是“业务方有意识和能力建立持续运营团队”，但大量企业将智能体项目视为一次性交付，缺乏持续运营的预算、人力或流程，这是文章未深入展开的落地障碍。
- — 文章倡导的“只读连接”和“人工确认写入”原则在控制风险的同时，也可能牺牲用户效率，与“用AI完全替代人工”的期望存在张力。
9 分钟 · 4 卡片 · 6 资料
读原文 →