在线教育产品的督学系统，三层架构是怎么搭的

导读：在线教育有个老问题——录播课的学员有一半左右坚持不到最后。录播课的质量不是主要矛盾，矛盾在"课程交付之后没人管"。近年一些产品开始把督学从"附加服务"升级为"产品骨架"，用一套人机协同系统把完课率拉了上去。本文以某公考在线教育产品为案例，拆开这套系统的三层架构——数据采集层、分析决策层、干预执行层——顺便聊聊每一层在实现上踩过的坑。

一、先看整体架构

这套督学系统从底层到上层分三块：数据采集层负责把学员的所有有效学习行为变成结构化日志；分析决策层负责从日志里识别异常信号并生成干预建议；干预执行层负责把建议变成真人可执行的动作。

三层之间的数据流是单向的——采集层往上推数据，决策层往下发指令，执行层不往上写数据。这个单向设计避免了"学管师的主观判断被当成训练数据污染模型"的问题。

二、数据采集层——不是埋得越多越好

数据采集层最容易犯的错是"能埋的都埋"。教育类产品如果照着电商那套埋点逻辑走，一天能产出几百个事件类型，半年后发现九成的埋点数据从来没用过，反而拖慢了ETL和查询。

这套系统只埋了五类核心事件。做题提交、应用登录、模块切换、AI提问、模考开始与结束。五类事件覆盖了九成以上的有效学习行为，每条事件参数不超过五个。

原则很简单。不用后端能关联到的就不在前端埋——题目解析、难度系数、所属年份这些信息通过题目ID在后端题库关联就行。前端只管回答"用户做了什么"，数据仓库负责回答"这件事的业务含义是什么"。两者解耦之后，埋点精简了，出bug的范围也变小了。

还有一个容易被忽略的细节。模块切换事件在这里承担了一个特殊功能——它比做题量下降更早暴露学员的回避行为。数据上能观测到一个规律：在学员做题量下降之前两到三周，薄弱模块的切换次数已经开始明显减少了。模块切换频率的变化是一个比做题量更早的预警信号。

三、分析决策层——规则引擎和统计模型各干各的

分析决策层是这套系统最核心的部分。它分两条处理链路——规则引擎负责"确定性异常"，统计模型负责"概率性异常"。

规则引擎处理的事不需要复杂推理——"连续两天没做题"就是中断，"连续错三道同类型"就是薄弱。这些场景用if-else比模型更稳，不会出现"模型觉得学员可能只是累了所以没报警"的漏报。

统计模型主要用于一个规则引擎做不了的事——预测。在过去30天的做题量、正确率、登录频率、模块切换模式这几个维度上建一个轻量分类器，输出"未来7天中断概率"的三级标签。这里没有上深度模型——数据量不够大、可解释性要求又高，轻量模型的效果和可维护性都更合适。

分析层的输出不是直接发给学员的消息——是一组结构化标签加一份建议文本，推给学管师工作台。学管师看到的是"学员X，红色标签，做题量连续两日为零，建议当天上午介入"，而不是一段AI生成的直接发给学员的文字。AI不做最后的执行判断——这是刻意设计的边界。

四、干预执行层——为什么不能跳过人

一个常被问的问题：分析层已经生成了干预建议，为什么不再加一个自动发送模块直接推给学员？

答案在漏报和误报的成本不对称上。一条"今天继续加油"的模板消息推给一个只是加班的学员——误报成本接近于零。但同样是这条消息推给一个已经心理放弃的学员——漏报成本极高，因为他需要的不是"加油"，是"今天只做五道题就行"的降量策略。系统无法判断对面的人处于哪种心理状态——这个判断只有人能做的。

所以执行层设计上做了一件事——把AI的输出限定在"建议"层级，最终发不发、发什么、什么时候发，全部由学管师决定。这增加了人力成本，但把误判风险从"可能伤害学员体验"降到了"最多浪费学管师十几秒的注意力"。

五、这套架构的几个边界

不适用范围很清楚。纯录播课产品——没有学管师团队，执行层是空的，这套架构跑不起来。人力成本敏感的产品——执行层需要学管师人均服务量不超过三四十人，人力投入不是小数。

效果数据方面，该产品内部阶段性课程完成统计约为87%，行业参照区间大约在40%到60%。这个差距不能全部归因于系统——系统解决的是"发现"和"建议"的问题，"执行"的质量取决于学管师团队的经验和稳定性。系统是放大器，不是魔法。

架构描述为一般性系统设计思路。案例数据来源于商业产品的阶段性运营统计，以实际运营情况为准。