问题
大型在线教育项目(如 MOOC 或批量培训项目)的学员在注册阶段集中提问,数量增长快于工作人员规模。现有混合支持体系(AI 助手、同伴回答、FAQ 库、人工升级)能覆盖大多数信息类问题,但对「我提交的材料现在到哪一步了」这类进度查询无能为力——研究数据显示 "at least 20.4% of queries concern the progress of a pending submission",而 AI 助手只能应答其中 1.3%,因为存量答案无法报告个人当前状态,最终只能升级给管理员,常以同步批量活动形式处理,效率低。
目标用户
运营大型在线教育项目(高校在线学位、企业批量培训、规模化认证项目)的教务和运营团队。市场规模取决于此类项目的数量,信号未给出具体规模,定性判断为中等:有大量学员集中提问的项目都存在此问题。
解决方案
核心是一个接入学员系统数据的状态查询层:
- 进度查询对话:学员用自然语言问"我的证书提交审到哪了",机器人从后台数据库读取该学员的待办状态并生成即时回答
- 数据集成:与项目已有的学员管理系统/表单后台对接,获取提交记录的实时状态(收件、审核中、驳回、完成)
- 查询识别分流:自动区分"信息类问题"(交给现有 FAQ/AI 助手)与"状态类问题"(查询实时数据),与现有混合支持体系共存而非替代
- 主动状态推送:状态变化(如审核完成)时主动通知学员,减少后续重复追问
- 管理端看板:管理员可看到高频状态查询集中在哪些环节,定位流程瓶颈 AI 的角色:意图分类(区分信息类 vs 状态类)、把数据库中的结构化状态翻译成自然语言回答。
为什么是现在
研究表明纯静态答案体系(FAQ、存量语料)结构性无法回答个人化状态问题(仅覆盖 1.3%),而 LLM 结合实时数据查询(工具调用/RAG)已能把"读数据库 + 生成自然语言回答"做成低成本方案,这是以往规则机器人做不到的。
MVP 范围
第一版:接入单一项目的学员系统(通过导出表或 API),支持 3-5 种常见提交类型(证书、offer letter 等)的状态查询,以对话机器人形式嵌入学员已有的答疑渠道,含意图分流。明确不做:不替代现有 FAQ/AI 助手体系,不做通用教务系统,不做自动审批本身(只报告状态不改变状态)。
风险
- 集成依赖:必须逐项目对接学员管理系统,数据格式各异,是主要工作量;
- 隐私合规:学员提交材料(证书、offer)属个人信息,需权限控制和最小化读取;
- 替代方案简单:项目方可能让管理员定期批量广播进度,或升级现有客服工具加一个数据库查询插件,门槛不算高;
- 单一研究来源:证据来自一篇 arXiv 研究,尚无付费意愿或真实采购行为的信号。
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
arXiv cs.HC10月1日痛点
“Large online programmes receive heavy volumes of queries during onboarding, at a scale that grows faster than the number of staff available to answer them.”
Query volume in large online programmes grows faster than available staff, and demand is concentrated in narrow process steps like certificate and offer letter submission.原文
arXiv cs.HC10月1日新能力
“at least 20.4% of queries concern the progress of a pending submission rather than a request for information, a class the assistant served only 1.3% of the time, since a stored answer cannot report an individual's current status.”
A hybrid support system (AI assistant, peer answers, FAQ corpus, escalation) resolves most student onboarding queries at scale, but stored answers cannot report the status of a pending submission.原文