最近开源了一个叫 LiveCourse 的项目核心就一句话把 AI 大模型变成你的专属老师搭一个真正能自主学习、随时答疑、自动出题的课堂。我做这个项目的起因很朴素——团队内部每周都要搞技术培训录播课没人看文档太长没人翻线下讲课又没法覆盖所有人不同步的进度。试过几个现成的在线学习平台要么是传统课程管理要么是套了个聊天机器人离学习这件事本身还差很远。于是干脆自己动手基于大模型和 Agent 做了 LiveCourse现在把它完整拆解一遍从产品思路、技术选型到部署配置、踩坑记录全盘托出给想做 AI 教育应用或自建学习系统的同学一份能直接参考的实操手册。1. LiveCourse 项目概览与设计思路1.1 为什么叫 LiveCourseLiveCourse 这个名字里的 Live 不是直播而是活的课程。市面上大多数在线课程是静态的视频录好就永远不变题库定好就再也不换学员提问只能等助教回复。LiveCourse 的设计理念是让课程随着学员的提问、回答、测验表现实时生长——同一门课给不同学员讲出来的重点、难度、案例都不一样。从产品形态上看LiveCourse 像一个可以自组织的学习空间。学员进入一门课程后会先看到一份动态生成的课程大纲每学完一个章节系统自动弹出测验和思考题答错了会触发一次针对性的知识讲解答对了会继续往下推。整个过程不再依赖人工维护内容大模型在后台根据知识库和学员画像实时生成所有材料。这套思路解决了三类典型问题内容更新跟不上教材和讲义刚写好就过时而 AI 可以基于最新知识库实时生成。学员基础参差不齐统一课件无法兼顾零基础和进阶用户。答疑成本高人工作答存在延迟且老师精力有限。适合用它来搭建企业内部培训系统、在线教育平台的个性化学习模块或者个人知识管理进阶工具。1.2 核心功能拆解LiveCourse 的功能我按学习闭环拆成了五块每一块都是独立模块可以单独使用也可以组合成完整课堂智能课程生成输入课程主题、难度系数、目标学员画像自动生成章节大纲、讲义内容、案例分析、参考文献。自适应学习路径根据测验得分、学习时长、错题知识点动态调整后续章节的深度和顺序。实时 AI 答疑学习过程中随时提问Agent 结合课程上下文、知识库和常见误区给出解答。自动出题与批改每章节生成判断题、选择题、简答题并根据参考答案自动评分主观题用 AI 评定要点覆盖率。学习报告与反馈统计知识点掌握度、学习时长分布、易错点排行生成可导出的个人学习报告。这五块功能覆盖了学—练—测—评—答疑的完整闭环也是我认为自主学习课堂最重要的五根柱子。1.3 技术路线选择背后的思考传统做法是用规则引擎或人工编排内容但 LiveCourse 从设计之初就走了一条更重的路线以大语言模型为核心引擎配合检索增强生成和轻量级 Agent 编排。为什么不用简单的 Prompt 套壳因为学习场景有很强的逻辑性和连贯性。如果只是让大模型直接输出课程内容可能会出现前面章节提前暴露后面知识点、题目与讲义不匹配、答疑时上下文断裂等问题。LiveCourse 的做法是先定一套课程数据模型把生成的每一个章节、每一个知识点、每道题都结构化存储再通过 Agent 在生成时做规划、调用工具、校验结果最后才交给前端渲染。这样的好处是可控性强后期也方便扩展到多学科。技术路线确定后我在模型选型上也纠结了很久最终选择本地部署加 API 混合的方案具体细节下一节展开。2. 技术架构与选型解析2.1 总体架构LiveCourse 的架构可以分成四层前端层基于 React Vite 构建的 Web 应用负责课程浏览、交互式学习、问答输入和学习报告展示。服务层Python FastAPI 提供 REST API 和 WebSocket 接口负责用户管理、课程状态机、会话管理和 Agent 调度。数据层PostgreSQL 存储用户、课程、章节、知识点、测验记录等结构化数据向量数据库存储课程文档切片的 Embedding用于检索增强生成。模型层Ollama 或 vLLM 部署的本地大模型加上可选的外部大模型 API通过统一接口层屏蔽差异。这样分层的好处是各层可以独立扩展。比如模型层如果要从本地模型切换到云端 API只需要改一个 provider 配置数据层如果数据量上来可以把向量库单独拆成集群。组件清单模块技术选型主要职责前端React, Vite, TailwindCSS课程交互界面、实时问答聊天、学习进度可视化后端FastAPI, Uvicorn业务逻辑、会话管理、课程状态机、API 网关Agent 编排LangGraph 自研轻量节点课程规划、答疑、出题、评估等任务流程关系数据库PostgreSQL用户、课程结构、测验结果、学习记录向量库Qdrant知识库切片、历史问答记忆、相似课程推荐模型接入Ollama / OpenAI-compatible API文本生成、Embedding 生成异步任务Celery Redis长任务处理如整门课程生成、批量批改2.2 模型选型本地部署还是 API这是让我最纠结的一层。做 AI 教育产品模型就相当于老师的大脑选错了直接影响效果。我的实际建议是分成两档第一档是追求效果和迭代速度优先调用商用大模型 API比如 DeepSeek、通义千问、Kimi 等这些模型的语文理解、逻辑推理和 Instruction Following 都更成熟生成课程讲义的连贯性好很多。缺点是有成本且课程内容会经过第三方服务器不适合有数据合规要求的教育机构。第二档是本地部署开源模型推荐 qwen2.5 系列、Qwen3 系列或者 Llama 3 系列。本地部署的核心好处是隐私安全、离线可用、单次调用成本几乎为零。但需要一张至少 16GB 显存的显卡才能跑出还算流畅的效果纯 CPU 推理会很痛苦。我最终做的是本地为主、API 兜底默认走本地部署的 qwen2.5:14b量化版遇到复杂的长文生成任务时切换到 API 增强。给新手的硬性建议是先别纠结本地部署用 API 把功能跑通再逐步迁移到本地模型。这样能先把产品逻辑验证清楚避免一开始就掉进环境配置的坑里。2.3 Agent 编排方案课程生成和答疑不能只靠单次模型调用必须靠 Agent 按流程执行。我最初用 LangChain 搭了一版后来发现学习场景的状态流转比较多就改成 LangGraph把整个课程生成拆成五个节点需求解析节点接收用户输入的主题、难度、目标输出课程元信息。知识图谱节点调用模型生成章节列表和知识点依赖关系。内容生成节点逐章节生成讲义每次生成前会把前文摘要作为上下文传入。质量校验节点用另一个 Prompt 检查生成内容是否偏离大纲、是否有知识性错误。存储节点把最终生成结果结构化写入数据库。答疑 Agent 又是一个独立的图流程它先做意图识别判断问题是针对当前章节、全局概念还是课后题然后从向量库检索相关片段再调用模型生成回答最后还会判断是否需要触发重学建议。这个设计比单次 Prompt 的优势在于每一层都可以加缓存、加人工审核、加日志追踪出了问题能准确定位到哪个环节。3. 核心环节实现AI 课程生成与自主学习闭环3.1 课程生成流程从大纲到讲义一个典型的课程生成请求是这样的用户提交帮我生成一门 Python 数据分析入门课程面向有基础编程概念的大学生一共 6 章难度中等偏易。后台 Agent 会先构造一个系统提示词包含课程设计基本原则、知识结构样例和输出 JSON 格式要求把任务下发到模型层。模型返回课程大纲后我会做一次结构校验确保每个章节都有标题、学习目标、正文知识点、示例代码如果适用、思考题和延伸阅读。校验通过后再逐章生成详细讲义。为了避免一次生成过长内容导致模型后半段质量下降我把讲义生成按知识点重新切分每个知识点控制在 300 到 500 字然后拼接成完整章节。这里有一个关键点生成过程中我会把已经生成的前几章摘要喂给模型做上下文保证逻辑一致性。例如第一章讲完了变量和数据类型第二章就不能突然跳到高级装饰器而是要顺着数据操作自然过渡。如果模型生成的章节间出现明显的知识跳跃质量校验节点会打回重生成。# 伪代码课程生成主流程 async def generate_course(request): outline await generate_outline_with_agent(request) validate_outline(outline) for chapter in outline.chapters: context get_generated_excerpts_until(chapter.order) content await generate_chapter_content(chapter, context) quality await check_content_quality(content) if quality.score 0.8: content await regenerate_chapter(chapter, context) save_chapter_to_db(chapter, content) return build_course_manifest(outline)3.2 自动出题与评估机制自动出题比课程生成更讲究细节。判断题和选择题可以用规则加模型生成但简答题必须设定评分标准。我的方案是每道简答题生成时同时生成一个评分要点数组里面包含 3 到 5 个关键知识点。学员提交答案后评估节点会把答案和评分要点交给模型让模型逐条判断是否命中最后输出得分和反馈建议。比如一道题问请简述时间复杂度和空间复杂度的区别评分要点可能是时间复杂度描述算法运行时间随输入规模变化的趋势。空间复杂度描述算法运行所需内存随输入规模变化的趋势。两者可以独立分析优化时间不一定优化空间。能举例说明最好。模型评分时会分别给每个要点打 0 或 1 分并对未命中的要点给出针对性提示。这种方式比直接让模型给个总分更透明学员能看到自己到底漏了哪个知识点。题库更新也是自动化的。课程运行一段时间后后台脚本会收集所有学员的错误答案把高频错误知识点汇总成报告下一次生成同类课程时把这些易错点生成成新的练习题。这样课程就越用越聪明。3.3 实时答疑与学习路径调整答疑功能是所有学习者最依赖的部分。LiveCourse 的答疑界面是一个类似聊天窗口的交互区域但它不是简单的通用问答机器人而是懂你这门课的助教。当学员问这道题为什么选 C时Agent 会先查询当前测验记录的上下文结合题目原文、参考答案、学员本人答错的选项生成一段带解析的回答。如果学员问我是否需要先复习第三章Agent 会根据学习进度和知识点掌握度做诊断并给出路径调整建议。学习路径调整的具体实现是给每个知识点维护一个熟练度分数每次测验完成后更新。分数跌破阈值就在后续课程中插入复习章节分数很高则跳过基础讲解直接进入进阶应用。这个逻辑我最初想用复杂的状态机实现后来发现用简单的规则加模型判断更灵活。{ learner: user_123, course: python-data-analysis, current_chapter: 4, knowledge_points: { pandas_basic: {mastery: 0.82, status: mastered}, data_cleaning: {mastery: 0.55, status: reviewing}, visualization: {mastery: 0.31, status: learning} }, next_action: { type: insert_review, chapter: 3, reason: data_cleaning mastery low, need remediation } }3.4 学习行为数据采集要支撑上面的路径调整必须建立一套完整的行为采集管道。我在前端埋点了这些事件进入章节、观看讲义时长、展开代码块、提交答案、请求提示、切换章节、离开课程。每个事件都带上课程 ID、章节 ID、知识点 ID 和时间戳异步发送到后端。后端把这些事件清洗后存入 PostgreSQL 的分区表每天凌晨跑一个聚合任务更新知识点掌握度和学习时长统计。这套数据和生成模型强相关所以我还特意做了版本管理每次模型升级或 Prompt 调整都会重新生成一批验证集测试效果避免前面课程内容召回逻辑失效。4. 本地部署与实操配置4.1 环境准备这一节直接给可抄的部署方案。我的推荐环境是 Ubuntu 22.04 Python 3.11 Node.js 20硬件要求取决于模型大小。如果用 qwen2.5:7b 量化版一张 8GB 显存的显卡就够了如果跑 14b 量化版建议 16GB 以上显存。# 安装 Python 和 Node sudo apt update sudo apt install -y python3.11 python3.11-venv curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs # 创建虚拟环境 python3.11 -m venv .venv source .venv/bin/activate pip install --upgrade pip4.2 模型部署与配置我这里用的是 Ollama因为它支持 OpenAI 兼容接口集成成本最低。如果你追求更高的并发吞吐可以换成 vLLM但配置复杂度会明显上升。新手先上 Ollama稳定跑通全流程之后再考虑换。# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取中英文混合表现不错的模型 ollama pull qwen2.5:14b # 后台启动服务 ollama serve配置完模型之后在 LiveCourse 的后端.env文件里填入模型配置MODEL_PROVIDERollama OLLAMA_BASE_URLhttp://localhost:11434 LLM_MODELqwen2.5:14b EMBEDDING_MODELbge-m3 TEMPERATURE0.3 MAX_TOKENS4096TEMPERATURE我建议设置在 0.3 左右。课程生成任务需要稳定性和逻辑一致性温度太高容易跑题答疑任务可以适当调到 0.5让回答更灵活一点。如果同一个模型同时服务两类任务我会在后端分别维护两个配置项。4.3 后端服务配置后端我用 FastAPI 开发依赖项包括数据库驱动、向量库客户端、LangGraph、Celery 等。首次启动前先安装依赖并迁移数据库cd backend pip install -r requirements.txt cp .env.example .env # 编辑 .env 里的数据库连接信息 alembic upgrade headPostgreSQL 需要启用 pgvector 扩展如果你只用 Qdrant 做向量检索PostgreSQL 就不需要装 pgvector但我在 LiveCourse 里把向量同时存了一份在 Qdrant方便做语义检索和相似课程推荐。启动后端服务uvicorn app.main:app --host 0.0.0.0 --port 8000 --reload4.4 前端交互配置前端是标准的 Vite React 应用依赖安装和启动没有特殊之处cd frontend npm install npm run dev打开浏览器访问http://localhost:5173第一次进入会看到登录页注册账号后在课程列表页点击创建新课程按钮填入主题和难度系统就会开始异步生成课程。生成期间可以离开页面完成后会在课程列表中通知。4.5 性能调优建议本地部署最头疼的是响应速度。我的实操经验是把生成任务和交互式问答拆成两条链路。课程生成属于长时任务直接交给 Celery 异步处理不在 HTTP 请求里干等学员提问属于短时任务走 WebSocket 实时返回流式结果体验上更像聊天。另外一定要给模型加一层语义缓存。同一个课程里很多学员会问类似的问题我用了 Embedding 相似度加前缀匹配的二级缓存命中率能到 35% 左右显著降低模型压力。注意力机制再强也不如缓存来得实在。5. 常见问题与排查实录5.1 模型回复速度慢最常见的现象是提问后等了十几秒才开始输出。原因通常是模型没有开启 GPU 加速或者模型太大超过了显存容量。先用ollama ps查看当前模型运行的设备类型如果不是 GPU检查是否安装了 CUDA 版本的 Ollama如果显示 GPU but 显存不足改成 7b 或 4bit 量化版本。还有一种情况是后端路由写错了请求被分发到了 CPU 推理进程。检查 .env 里OLLAMA_BASE_URL是否指向真正启用 GPU 的实例。5.2 生成内容事实错误AI 课堂最怕一本正经地胡说八道。我在测试时发现模型在生成技术类课程时偶尔会把 API 参数写错。解决思路有三层在课程生成前把权威知识文档灌入向量库强制 Agent 在生成时先检索相关资料再结合检索结果写内容。在质量校验节点加入第二个模型做事实审查让它标记可能存疑的句子。对生成内容打上AI 生成仅供参考的标签并保留人工审核通道。前两层能挡掉大部分错误但无法完全杜绝。作为教学工具还是需要一个人工复审流程至少在上线课程前过一遍。5.3 并发高时进程崩溃最初实现没有做任何限流几个人同时生成课程时显存直接打满进程被系统杀死。后来我引入了两个保护机制一是模型推理层加了一个信号量控制并发数为 1 到 2二是把课程生成任务全部放进 Celery 队列队列长度超过 10 就拒绝新任务并提示用户等待。# 信号量控制并发 from asyncio import Semaphore _model_semaphore Semaphore(2) async def generate_with_limit(prompt): async with _model_semaphore: return await generate(prompt)如果显存只有 8GB并发数可以设为 1宁可慢一点也不能崩。5.4 中文生成效果不稳定有些英文模型生成中文内容时会出现语序混乱或语气生硬。我的经验是尽量使用中文预训练比例高的模型比如 qwen 系列。另外在 Prompt 里明确加上使用简体中文、面向中文学习者、语言风格自然易懂等约束效果提升非常明显。如果你必须要用某个英文模型可以在生成后加一个中文润色节点但这样会多一次推理开销非必要不建议。5.5 学习路径调整不准确路径调整偶尔会把已经掌握的知识点重复推送或者跳过学员薄弱的基础概念。原因通常出在知识点之间的依赖关系没有定义完整。解决办法是在课程生成阶段要求模型显式输出知识点依赖边即学这个知识点之前必须先掌握哪些前置知识点然后在路径调整引擎里做拓扑排序保证复习顺序不冲突。排查问题速查表现象可能原因解决方案回复速度慢模型跑在 CPU安装 GPU 版 Ollama更换小模型内容答非所问检索召回片段不相关调整 Embedding 模型和相似度阈值课程生成中断输出超过 max_tokens调大 MAX_TOKENS或分段生成前端连接断开WebSocket 会话超时检查代理层超时配置增加心跳数据库连接过多异步任务未释放连接池调小连接池大小加超时回收6. 扩展方向与后续规划6.1 多模态学习支持目前的 LiveCourse 主要针对文本内容后续想接入图片和视频理解能力。比如在生物课中生成细胞结构图在编程课中根据代码自动生成运行流程图。多模态模型可以直接复用现有 Agent 编排架构只需在内容节点增加图片生成工具和视觉理解工具。6.2 多语言课程与国际化学员做多语言支持不只是翻译还要处理文化差异和语言表达习惯。我的规划是把学习内容按语言版本独立存储每个语言版本单独跑一遍课程生成流程而不是靠翻译模型硬翻。因为直译出来的内容在教学场景下经常显得僵硬重新生成的效果会好得多。6.3 课程共享与协作一个人生成课程的能力有限后续会做课程集市让用户可以分享自己生成的课程也可以 Fork 别人的课程进行二次修改。修改时引入增量更新机制只针对章节级差异重新生成避免整门课程重复消耗算力。6.4 与教学管理平台集成面向学校和企业LiveCourse 还可以通过 LTI 1.3 标准接入 Moodle、Canvas 等主流教学管理系统让用户在原有平台里直接使用 AI 课堂功能。这样既利用了现有账号体系和课程管理能力又不用把学员数据迁移到新系统落地阻力会小很多。我在实际开发中发现做 AI 教育产品和做普通 Web 应用最大的区别在于内容生成不是一次性工程而是需要持续迭代的闭环。模型在变学员在变知识库也在变整个系统必须设计成可以不断从真实使用数据中学习修正的样子。如果只把它当成一个套着提示词的课程网站很快就会遇到内容陈旧、答疑失灵的问题。最后分享一个个人经验第一版不要追求功能齐全先跑通输入主题—生成课程—回答问题这个最简闭环哪怕代码写得再粗糙都行。等真实用户开始用了你会发现他们的提问方式、学习节奏和你预想的完全不同这些反馈才是产品迭代最宝贵的数据。AI 课堂的魅力就在这里——它是活的也在跟着学习者一起成长。