AI助手上线后回答得不错，用户为什么还是不用？复盘一个课程咨询助手的三轮迭代
演示里“能流畅答标准问”不等于用户会用：课程咨询助手要从回答质量升级为任务路由 + 知识运营 + 只读业务连接 + 服务闭环指标，才从“会聊天的功能”变成可持续运营的服务产品。
基本信息
- 来源类型：文章（人人都是产品经理）
- 原文位置：
raw/articles/2026-07-17-woshipm-course-consulting-assistant-3-iterations.md - Telegram stub：
raw/articles/2026-07-17-200809-tg-82b83f.md - 提取路径：
raw/extracts/20260717-204834/woshipm.com/ai.md - 原文 URL：https://www.woshipm.com/ai/6431494.html
- 作者：我叫小米粒
- 发布时间：2026-07-17
- 消化日期：2026-07-17
- 约字数：正文约 4500 字符（抓取 Markdown）
- 说明：案例由智能体交付常见问题合并整理，不对应单一客户，也未使用未经验证的效果数据
核心观点
- “答得像话”≠“事办成了”：第一版导入课程介绍与报名流程、挂聊天窗口、答不了就转顾问，演示题都能过；真实用户问的是审核进度、班次改期、材料截图能否用、是否已与某顾问沟通过。模型完成了“返回一段话”，用户侧事情没解决——指标若只看对话次数会好看、看任务完成率会难看。
- 产品目标要从“回答了多少”改成“解决了多少”：重新拆用户旅程四类任务——①课程知识 ②实时状态 ③材料处理 ④人工服务。智能体先判任务类型再选知识库 / 业务查询 / OCR·Skill / 人工，角色是服务入口与任务路由器，而不是包办一切的全能聊天框。
- 知识库是产品运营工作，不是上线前一次性上传：控制知识库（可答边界、必须引用最新资料、无法确认时的处理、必转人工、禁止承诺）与证据知识库（课程介绍、招生安排、服务说明、历史通知）分离；明确资料负责人、更新时间、版本状态，旧资料不得与新资料混在同一有效范围。无更新责任时，更强模型只会生成更流畅的过期错误答案。
- 接业务系统先只读、先低风险：经身份确认后用 MCP 模型上下文协议 Server 查询报名状态；改手机号、取消报名、调班次等写操作仍人工确认。材料截图走 OCR + 材料解析 Skill，输出定义为“材料准备提示”而非最终审核结论。PM 要盯四问：用户是否有权、工具读写范围、失败如何提示、哪些结果必须人确认——接系统后产品设计包含权限、失败态、日志与责任边界。
- 评估要从回答质量升级为服务闭环四层指标：任务理解（意图、路由正确、是否反复问）、执行过程（知识命中、工具成功、降级、无依据回答）、业务结果（是否进入下一步、人工是否拿到完整上下文、人工改了多少 AI 内容）、产品运营（增长最快的问题、常缺资料、被频繁请求但未建设的能力、几乎无人使用的功能）。指标用途是决定下一轮补知识、加 Skill、接 MCP 还是改流程，而不是证明 AI “多聪明”。
- 智能体产品飞轮 = 未解决问题 → 新知识 / Skills / MCP / 流程 → 评测确认变好：前台 AI 承接并路由，后台由模型 + 智能体 + 数据与能力集合（知识库、Skills、MCP Server、有边界的上下文记忆）完成服务；记忆可保留偏好与纠错，不能无差别写长期记忆或自动改线上知识与工具配置。Haoee / Dify 类平台适合运营服务入口闭环；高校/政府/医院/国企等需数据不出域与权限审计的走私有化要素平台——工程思路同源、交付形态不同。
实操内容保留
操作步骤 · 三轮迭代路径
V1（标准问答，易翻车）
- 导入课程介绍与报名流程
- 配置知识问答智能体
- 在服务入口提供聊天窗口
- 回答不了提示联系顾问
V2 · 第一次复盘：重定义目标与任务路由
- 把成功标准从“返回文字”改为“推动用户进入下一步”
- 咨询需求拆四类：课程知识 / 实时状态 / 材料处理 / 人工服务
- 智能体先判断任务类型，再选择知识、工具或人工
- 产品定位改为服务入口 + 任务路由器
V3 · 第二次迭代：知识体系运营化
- 控制知识库（稳定规则）：
- 什么信息可以直接回答
- 哪些内容必须引用最新资料
- 无法确认时如何处理
- 哪些问题必须转人工
- 不允许作出哪些承诺
- 证据知识库：课程介绍、招生安排、服务说明、历史通知
- 明确资料负责人、更新时间、版本状态；旧资料与新资料隔离有效范围
V4 · 第三次迭代：业务连接但克制执行权限
- 报名状态：身份确认后，MCP Server 只读查询报名系统
- 写操作（改手机号 / 取消报名 / 调班次）：保留人工确认
- 材料截图：OCR + 材料解析 Skill → 输出“材料准备提示”，正式审核仍由人做
- 工具接入时强制过四问：权限、读写范围、失败提示、人工确认边界
评估指标体系（可直接复用）
| 层级 | 指标示例 |
|---|---|
| 任务理解 | 意图是否识别正确；是否路由到正确知识/工具/人工；同一问题是否被反复询问 |
| 执行过程 | 知识库是否正确命中；工具调用是否成功；失败是否进入降级；是否出现无依据回答 |
| 业务结果 | 用户是否完成下一步；哪些问题仍需人工；顾问接手是否已有完整上下文；人工需修改多少 AI 内容 |
| 产品运营 | 哪些问题增长最快；哪些资料常缺；哪些能力被频繁请求但未建设；哪些功能几乎无人使用 |
产品经理六问（上线前设计清单）
- 用户为什么来？
- 系统如何判断任务？
- 需要调用什么知识和工具？
- 失败时怎么办？
- 哪些动作需要人工确认？
- 使用反馈如何进入下一轮迭代？
Prompt / 代码
（本文无独立 Prompt 模板或代码块；可复用内容为任务分类、知识双库结构、MCP 只读边界与四层评估表，见上。）
关键概念
- 服务闭环 — 以任务完成与业务结果衡量智能体，而非对话次数
- 任务路由 — 先判任务类型再选知识/工具/人工的入口逻辑
- 控制知识库 — 稳定规则与边界（可答、必引最新、禁承诺、转人工）
- 证据知识库 — 可变业务资料与通知，需版本与责任人
- MCP 模型上下文协议 — 连接报名系统做只读状态查询
- Skill — 材料 OCR/解析等可复用能力包
- RAG 知识库 — 课程知识检索的底座，但必须运营化
- Agent安全护栏 — 只读优先、写操作人工确认、材料结论不越权
- 闭环沉淀 — 失败与缺口转化为知识、Skill、MCP、流程改进
- AI产品经理 — 设计的是任务、权限与飞轮，不是“AI 能说什么”
- 意图识别 — 任务理解指标中的第一环
- Dify — 文中与 Haoee 并列的智能体运营平台参考
- 企业AI落地 — 从演示到可运营服务的主题归属
- AI产品经理工作流 — PM 如何定义目标、指标与迭代节奏
与其他素材的关联
- 与 2026-05-26-智能客服MVP三件事：同属客服/咨询场景；彼文用“大模型只做 NLU + 状态机 + API”轻量闭环，本文强调任务四分法 + 知识运营 + MCP 只读 + 四层指标，互补为“架构形态”与“迭代叙事”。
- 与 2026-07-07-woshipm-agent-safety-guardrails：护栏文给风险路由与可撤回性；本文用报名查询只读、材料“提示非结论”做交付级落地样例。
- 与 2026-07-11-woshipm-enterprise-rag-knowledge-layering：知识分层落库偏工程；本文补“控制库 vs 证据库 + 责任人/版本/有效范围”的运营面。
- 与 2026-07-16-woshipm-ai-landing-methodology-finance-to-pm / 2026-07-16-woshipm-digitalization-cost-management：先规则/数据/责任再上智能；本文把同一纪律落到咨询助手三轮复盘。
- 与 2026-07-16-woshipm-ai-map-tool-iteration / AI 驱动产品迭代：都是“走一步发现下一层”；本文迭代对象是服务能力（路由→知识运营→业务连接→指标），不是功能地图。
原文精彩摘录
从模型角度看，它完成了回答；从用户角度看，事情没有解决。
团队最初关注的是“AI回答了多少问题”，但真正应该关注的是“用户的问题解决了多少”。这是两种完全不同的产品目标。
知识库不是项目上线前的一次性准备，而是产品内容体系的一部分。没有明确的更新责任，再强的模型也只能依据过期资料生成更流畅的错误答案。
查询报名进度属于低风险只读操作，可以由智能体辅助完成；修改手机号、取消报名、调整班次等操作则继续保留人工确认。……输出被定义为“材料准备提示”，不是最终审核结论。
智能体产品的真正飞轮，不是生成更多回答，而是不断发现没有解决的问题，把这些问题转化为新的知识、Skills、MCP能力和流程改进，再通过评测确认是否真的变好。