熟悉我的朋友都知道这几年我一直在折腾在线教育产品从最早的录播课、直播课到在线题库前后做过好几个项目但始终有个心结绝大多数在线学习工具本质上还是“把人当成播放器”点开视频、听完、做几道题结束。学习这件事被拆得支离破碎却没有人真正回答“你哪里没懂”“下一步该补什么”。直到我把AI拽进教学主流程做了一个名为LiveCourse 的 AI 驱动的自主学习课堂才感觉在线学习终于有了点该有的样子。这篇文章会把整个项目的设计思路、核心模块、关键代码和踩坑记录全部拆开讲适合正在做AI应用开发、教育产品或者单纯想给自学体系装上大脑的人参考。1. 项目整体构思AI驱动能解决什么真问题1.1 从“单向输出”到“主动探索”的学习闭环做过课的人都知道传统在线课堂的逻辑特别简单老师录视频、学生看视频、系统出题、学生答题。这个流程最大的问题不在于内容质量而在于它默认所有学生的起点和节奏是一样的。同一个知识点有人已经会了系统还在反复讲有人卡在某个概念上系统却因为“进度没到”不给他跳过的权利。LiveCourse想解决的就是这件事把课堂的主动权还给学习者让AI根据每个人当前的状态动态调整学习内容。这听起来像是自适应学习的旧概念但AI大模型成熟以后实现的深度完全不同。过去自适应学习只能通过选择题判断“对错”现在大模型能做的是看懂学生用自然语言描述的困惑结合他的历史行为数据实时生成一份专属于他的下一步学习路径。学生在LiveCourse里可以随时向AI助教提问可以要求换一种讲解方式可以跳过已经掌握的内容也可以让AI当场生成一套针对性的变式练习。如果这一整套闭环跑通学习这件事就不再是“老师讲什么你听什么”而是“你想学什么系统陪你学什么”。这也是我把项目命名为LiveCourse的初衷课程不是录好之后一成不变的而是活的随着学习者的状态一直变化。1.2 方案选型思考为什么坚持“AI驱动”而不是“AI点缀”在项目早期我其实做了一个很保守的原型架构跟市面上的产品差不多传统学习管理系统做主体AI只负责一个课后的问答机器人。结果测试下来用户用过一次就不再用了。原因很简单问答机器人放在学习主流程之外对学习者来说就是个“偶尔想起来才用一下”的附加功能体验不到AI真正的价值。后来我推翻重来把AI提到核心决策的位置上不仅答疑是AI路径规划是AI练习生成是AI连每一节课后总结、知识图谱的更新和学习报告的生成也是AI。整个系统从“记录学习行为”变成“理解学习状态并主动反馈”。这样改完之后用户留存数据明显提升。这里我想说的道理是如果你打算做一个AI产品最怕的不是AI不够聪明而是把AI当作锦上添花的插件这样用户根本感知不到它的存在。AI必须处在主流程的关键节点上它的能力才有被感知、被认可的机会。1.3 LiveCourse的能力边界与目标用户在动手搭之前得先搞清楚LiveCourse到底“是”什么、“不是”什么。我给它定了三个核心能力个性化学习路径动态规划根据学习者当前水平、目标、时间安排自动生成并动态调整学习计划。开放式AI答疑与知识辅助允许学习者用任意自然语言提问系统基于课程知识库和大模型能力给出解释。自动评测与学习洞察通过对话、练习、阶段性测验等多维度数据自动产出学习报告和薄弱点分析。至于LiveCourse“不是”什么它不是要替代真实老师也不追求涵盖所有学科。我早期测试切入的是编程、数学、语言这三类逻辑性比较强、知识边界相对清晰的学科因为这类内容更容易用知识图谱和规则去校验AI的输出质量。做产品最忌讳一上来就铺得很大把能力圈画清楚反而更容易在一个方向上打磨到好用。2. 系统架构与核心模块拆解2.1 总体架构围绕“感知—规划—执行—反馈”构建学习闭环LiveCourse整个系统可以看作一个经典的自主智能体结构只是领域从“任务处理”换成了“学习辅助”。我把它拆成四个层级感知层负责采集学习者的行为数据包括观看视频的停留时长、答题正确率、提问记录、文本输入的语义特征等。规划层根据感知层的数据结合学习目标与课程知识图谱生成或调整学习路径。执行层包括具体的课程内容生成、练习题目生成、知识点讲解以及AI助教的问答交互。反馈层将学习过程中收集到的结果反馈回规划层形成闭环同时向学习者输出可读的进度报告。各模块之间我用事件消息解耦。比如感知层检测到用户连续三道同类型题做错就会触发一个“理解困难”事件规划层收到后会把该知识点设为待强化状态并在下一步的学习任务中插入同类型但难度降低的讲解内容。这里最关键的编程思想是“不要在大模型对话里做太多业务逻辑”AI只负责它擅长的内容生成和理解流程控制必须交给传统代码。这也是很多AI应用翻车的原因用自然语言去调度所有流程结果稍微复杂一点就失控。2.2 学习路径生成器从知识图谱到动态规划学习路径生成器是整个LiveCourse里最核心的模块。它需要回答三个问题你现在在哪你想到哪去中间需要经过哪些节点。我采用的方式是“知识图谱 规则引擎 大模型动态补充”的混合方案。先由学科专家维护好一份知识图谱节点是知识点边是前置依赖关系。比如“理解递归需要先掌握函数调用栈”那么“函数调用栈”就是“递归”的前置节点。系统在生成路径时先根据知识图谱做一次拓扑排序确定一个大致的序列然后由大模型根据学生情况做局部调整学习速度快的可以跳过某些基础节点学得慢的则在两个节点之间自动补充过渡内容。这一块还有个容易忽略的细节路径生成不是一次性的。学习者的能力是动态变化的所以路径调整必须频繁触发。我在实现时设计了一个“每日规划线程”每天凌晨根据前一日学习数据重新计算一次后续路径同时白天如果检测到阶段性测验结果大幅偏离预期也会即时触发一次局部重规划。2.3 AI答疑与知识库RAG的结合AI答疑是LiveCourse里用户感知最强烈的功能但也是最容易出现翻车事故的地方。如果你只是把大模型直接接进来学生问一个课程之外的问题它照样回答得头头是道这个在严肃学习场景里是不可接受的。我用的方案是RAG检索增强生成。先构建课程专属知识库把课程讲义、视频字幕、教材、常见问答对全部切分成chunk向量化后存入向量数据库。学生提问时系统先向量检索出最相关的课程片段连同问题一起拼进Prompt交给大模型。这样有两个好处第一回答内容有了课程依据不再是模型凭空发挥幻觉率大幅下降第二当知识库中没有相关内容时系统可以明确告诉学习者“这个问题不在当前课程范围内”而不是硬答一通误导学生。在实测过程中我把搜索结果的召回数量控制在3到5个chunk每个chunk大概300到500个字符兼顾上下文窗口和检索精度。Prompt里我还加了一条硬约束只许基于给定的上下文回答如果上下文不足以支撑必须说出“我无法从本课程内容中确认”。这个约束条件对控制幻觉效果非常明显。2.4 自动评测与学习报告的生成逻辑自动评测模块的价值在于它能代替老师完成一部分重复劳动同时还能给出比人工批改更快、更细的反馈。LiveCourse里有两类评测客观题自动判分这类比较简单计算标准答案匹配度即可。主观题与代码题AI评阅这里需要小心设计。直接让大模型输出分数不够可靠我采用的是“评分标准 分项打分 评语生成”三步走。先把题目的评分标准随学生答案一起交给大模型让它分项打分比如“逻辑完整性0到5分知识点正确性0到5分表达清晰度0到5分”再让其输出最终总分和评语。学习报告则是所有模块数据的汇总。我设计了一个模板化生成方式每个模板里有一些变量槽位由大模型填充。这样做的好处是报告结构稳定不会因为模型发挥不稳定而产生乱七八糟的格式。报告里包括知识点掌握度雷达图、薄弱环节列表、下一步学习建议以及最近一段时间的趋势变化。实测下来学生看到报告后按建议去学的比例远高于看完成绩就关掉的比例。3. 关键环节实操从零搭起一个能用的AI课堂3.1 基础技术选型与部署方式LiveCourse后端我采用的是Java Spring Boot作为主框架AI交互部分集成了Spring AI项目这个组合对已有Java技术栈的团队特别友好。Spring AI帮我把各类大模型调用封装成了统一接口切换模型供应商时不需要改业务代码只改配置就行。另外由于要处理知识图谱和向量检索我在数据层用了PostgreSQL搭配pgvector插件省去单独维护一套向量数据库的运维成本。前端用的是Vue 3加TypeScript实时交互部分走WebSocket。选择WebSocket而不是普通HTTP轮询是因为AI助教回答是流式输出的学生能看到一个字一个字打出来的过程体验更接近真人对话。这部分体验做好了学生对AI的信任感会强很多。如果你一个人开发前端可以先用简化版我在早期甚至只用了一个聊天页面加一个课程列表页面照样能跑通核心闭环。代码目录结构大致是这样的livecourse/ ├── backend │ ├── src/main/java │ │ ├── agent │ │ ├── assessment │ │ ├── course │ │ ├── knowledge │ │ ├── learner │ │ └── report │ └── src/main/resources ├── frontend ├── data │ ├── raw_courses │ ├── chunks │ └── vectors └── scripts ├── build_kb.py └── eval_pipeline.py3.2 本地部署大模型还是调用云端API这是很多AI应用开发者纠结的问题。我的经验是在项目初期别碰本地部署直接用云端API把业务跑通优先验证产品逻辑是否成立。等到了需要做数据隐私保护、或者推理成本已经高到无法接受的程度再考虑本地部署。不过我最终在生产环境里选择了混合方案日常问答、路径生成这类对实时性要求高、隐私敏感度高的任务走本地部署的Qwen系列模型课程内容生成、长文本报告总结这类对模型能力要求更高的任务走云端大模型API。本地部署时我用的是vLLM做推理服务显存根据模型大小选择7B到14B级别的模型在单张24G显卡上已经能跑出不错的效果响应速度也基本够用。本地部署时还有几个参数值得记一下。温度参数我设置在0.3左右太低了回答显得机械太高了容易跑偏最大输出token数按场景区分答疑控制在512报告生成可以给到2048。上下文长度设置成4096就够React组件的项目用了过大反而增加推理延迟和成本。3.3 构建课程知识库数据清洗与向量化知识库的质量直接决定RAG效果的上限这一步千万别偷懒。我最初图省事直接把课程PDF解析出来的纯文本切块丢进向量库结果检索出来的片段经常是半句话可读性很差。后来老老实实做了三步处理第一步结构清洗。把PDF、Word里的页眉页脚、页码、目录信息去掉表格转成结构化文本代码块单独提取。这一步是为了让后续切分和向量化不受到噪音干扰。第二步智能切块。不能按固定的字符数硬切否则会把一个完整知识点拦腰截断。我写了一个切分脚本优先按章节标题、段落、句子边界切分块大小控制在300到500字。切完后做一轮校验如果发现某个块开头是“综上所述”这类依赖前文的词说明切分位置有问题需要手动调整。第三步向量化与索引。中文场景下向量化模型同样存在“一词多义”的问题单纯用开源Embedding模型容易造成检索偏差。我测试过几款中文向量模型最后选择了效果最稳定的一个并为每个chunk生成了两条索引一条是原始文本向量一条是由大模型生成的摘要向量。检索时两条向量都参与召回再合并去重。这个技巧把知识库的命中准确率提高了不少。3.4 AI助教代理的完整实现流程如果说知识库是LiveCourse的骨架AI助教就是它的表情。我发现学生对助教的交互方式非常在意语气太生硬不行回答太啰嗦也不行。这里我没有用那种激进的角色扮演而是通过提示词设定了三层结构。第一层是角色设定。助教被定义成“既懂知识又懂学习方法的辅导者”它会先尝试理解学生的问题再用通俗的语言讲解而不是直接丢给一长篇答案。第二层是回答策略。系统内置了几种回答策略模板如果学生说“我不懂”助教走“概念拆解”策略如果学生说“这题不会做”助教走“引导式提问”策略先反问两个问题帮助学生自己找到思路如果学生要求“举例子”助教走“类比讲解”策略。这层策略的调度代码在Java里写死不用大模型来判断能显著提高回答的稳定性。第三层是安全兜底。助教回答前会经过一个敏感词和学科上下文的双重校验发现越界就直接拒绝并建议用户查阅课程外资源。这部分对于面向公众的服务是必选项尤其是AI教育产品宁可保守也不能让模型胡说八道。核心问答接口的伪代码大概长这样PostMapping(/api/tutor/chat) public ResponseEntityTutorResponse chat( RequestBody TutorRequest request) { // 1. 生成向量并检索知识库 ListChunk chunks knowledgeService.search(request.getQuestion(), 5); // 2. 判断是否需要走策略路由 String strategy strategyRouter.route(request.getQuestion()); // 3. 构建提示词并调用模型 String prompt promptBuilder.build(request, chunks, strategy); String answer modelService.streamGenerate(prompt, request.getHistory()); // 4. 安全校验 boolean safe safetyChecker.check(answer); if (!safe) { answer 抱歉这个内容我暂时无法回答建议查阅课程指定教材。; } // 5. 保存问答记录 recordService.save(request.getUserId(), request.getQuestion(), answer); return ResponseEntity.ok(new TutorResponse(answer)); }这里每一步都不能省尤其是步骤2的策略路由它决定了助教是“有灵魂的辅导者”还是“大模型复读机”。我调试中最满意的一次回答是学生问“我理解不了递归里那个return到底回给了谁”助教没有直接解释概念而是反问了一句“你有没有玩过‘传话游戏’上一层的传话人接到答案之后会做什么动作”然后一步步引导他自己说出答案。这种交互效果单纯靠大模型是做不到的一定是策略提示词加上知识库内容一起作用的。3.5 作业与练习生成的参数控制练习生成是另一个高频使用模块。最初我让大模型自由出题结果题目质量很不稳定有的太难有的太简单有的跟当前知识点的关联度很低。后来给题目生成加入了一套参数化控制方案。我会在请求中传入三个关键参数知识点ID限定出题范围、难度等级从1到5、题型类型单选、填空、简答、代码题。大模型返回的题目会先经过一轮规则校验比如选择题必须有且只有一个正确答案、简答题必须有参考得分点、代码题必须能编译通过。校验不通过的会重新生成最多重试两次仍不通过就降级为模板题库里的同类题目。难度参数的控制靠的是提示词描述而不是让模型自己理解数字。比如难度3在提示词里体现为“需要对知识点有基本理解能够处理简单的变式应用”。如果直接用“难度3”这种抽象描述大模型产生的题目难度波动很大。这个细节我调了很久才发现。4. 踩坑实录常见问题与排查技巧4.1 大模型幻觉问题比想象中更顽固把大模型接入教育场景首先要面对的就是幻觉问题。学生问一个课堂上没讲过的概念模型很可能会一本正经地按自己的理解去回答而且语气非常自信学生很难辨别真伪。我在早期测试时就被坑过一次助教把某个编程语言的一个并不存在的库函数讲得头头是道还给了完整示例学生照着敲编译报错回来问我怎么回事。排查之后我做了三道防线。第一道RAG检索凡是课程知识库中命中率足够高的内容要求模型只基于检索结果回答。第二道回答置信度提示提示词里明确要求模型在不确定时输出“我无法确定”同时系统对回答中是否存在知识库外的实体做一个轻量校验。第三道人工兜底异常标记当助教被学生连续追问三次以上系统自动把该答案标记为“存疑”并推荐学生联系真人老师或查看指定教材章节。这套组合拳下来幻觉率控制在了可接受的范围。4.2 响应延迟高形势比想象的复杂AI课堂最影响体验的就是等待。大模型推理速度再快流式输出也需要时间一旦并发量上来响应延迟会明显升高。我遇到过一次严重的性能问题下午六点学生下课集中使用AI助教接口平均响应时间从3秒飙到15秒直接触发用户投诉。排查过程大概是这样的。先看监控面板发现问题不在模型推理本身而是业务线程池被打满请求全在排队。后来定位到原因是每次请求前我都会调用一个向量检索服务而这个服务的连接池配置过小在高并发下连接被占满后续请求全部阻塞。解决办法很简单扩大连接池、增加缓存把高频问题及其答案缓存到本地命中直接返回不用再走一遍“检索生成”全链路。另外流式输出对前端也有要求。我用的SSEServer-Sent Events做流式推送但一开始在网关层没配置好缓冲导致前端收到的是攒了很长时间的一次性大包体验跟非流式没有区别。后面把网关的proxy_buffering关掉才真正实现逐字输出。如果你也遇到AI接口慢建议按这个顺序排查先看网络和网关层再看连接池和缓存最后才怀疑模型推理本身。大多数情况下问题都不在大模型而在你周围的基础设施。4.3 知识库检索不准问题通常出在切分知识库检索不准是最让人抓狂的问题因为不好定位。有一次学生问“进程和线程有什么区别”返回的课程片段却是一段关于操作系统的历史介绍跟问题毫无关系助教只能照着历史介绍乱答一通。我查了很久最后发现原因出在切分策略上。原始教材里“进程与线程”这一节的正文被切成了三块但第二个块开头是“相比之下”这说明它依赖前文的对比语境单独拿出来向量化语义就和原意偏离了。后来我设计了一套上下文补充机制每个chunk除了本身内容之外会把它的上级标题和相邻段落的第一句一起存进元数据。检索时用主内容做向量召回但返回给模型时会把补充上下文拼上去。这样“相比之下”这个块即使被单独检索到模型也能知道它是在对比进程和线程而不是在讲什么别的东西。这个问题的教训是RAG系统的上限更多取决于知识库的处理质量而不是模型能力。你花一周时间做数据清洗效果比换一个更大的模型明显得多。4.4 数据隐私与评测盲区这两个坑绕不开教育数据隐私极其敏感尤其是学生画像、学习记录这类数据。我在部署时把用户数据和AI服务做了物理隔离用户行为数据存储在自建数据库向量化之前的文本脱敏后才送入外部API而且只传必要字段绝不传手机号、姓名等身份信息。本地部署的模型则可以放心处理全部数据这也是我坚持保留本地模型的原因之一。另外一个容易被忽略的是评测盲区。AI评阅主观题时它可能被学生“看起来认真但实际跑题”的答案欺骗。我给大模型的评分提示词中加了一条优先判断答案是否切题再评估知识深度和表达。同时建立了一个人工抽检流程每批自动评测的作业中抽取10%由真人老师复核复核结果用于持续调优评分提示词。这两个问题都属于“做对了用户感觉不到做错了会被立刻骂死”的类型需要投入足够注意力。产品和工程的成功往往取决于这些容易被忽略的边缘环节。5. 项目上线之后的真实体会LiveCourse上线运行这段时间我最大的感受是AI进课堂这件事真正的门槛不在于调通一个大模型接口而在于你能不能围绕它打造一个稳定的学习闭环。模型能力再强如果知识库是脏的、策略路由是乱的、评测标准是模糊的用户体验一样会崩掉。我给准备做类似项目的朋友的建议是先画出完整业务流程明确AI在每个关键节点到底承担什么角色再搭骨架先用最简单的单向流程把产品跑通最后才逐步引入动态规划、复杂评测这些进阶能力。别一开始就沉迷于调提示词、画Agent架构图那些都是锦上添花的东西。最后再分享一个我在调试中反复使用的技巧每次改动系统之后我会内部先模拟一组“典型学生”的行为序列比如“学完第3章之后连错三题”看系统在这条路径上的表现是否符合预期。这种“按剧本走查”的方式帮我发现了很多随机测试发现不了的逻辑漏洞。如果你也在做类似的AI学习产品不妨试试这个笨办法。