简介基于Python语言打造的AI学习平台设计源码面向AI初学者、Python开发者和在线教育平台建设者可作为搭建智能学习系统、设计前后端交互与内容管理的完整参考。ZIP压缩包共1857个文件、约48.55MB类型覆盖图片素材PNG/GIF/JPG共1300余个、Markdown文档、Python脚本、JavaScript/CSS前端代码及Shell配置脚本等既有教学展示所需的大量可视化素材也不乏可直接学习借鉴的源码与部署配置。已有284人学习。这套设计源码并非简单示例Python脚本可支撑核心逻辑Markdown文档适合沉淀课程说明部署配置与域名相关文件让本地运行和自定义域名访问更为便捷同时齐全的图片资源既能用于教程配图和动画演示也能用于界面装饰。对希望快速获得完整AI学习平台设计思路、降低从零搭建成本的人而言是一份能够直接上手改写的宝贵素材。1. 基于Python语言的AI学习平台设计源码真正值钱的部分不在算法在数据闭环很多人拿到「基于Python语言的AI学习平台设计源码」这类项目时第一个动作是翻模型训练文件把注意力全放在神经网络和大模型接口上。我和某高校实验室合作维护过一套学习平台源码最后统计下来与算法强相关的文件只占不到 15%剩下 85% 的代码都在处理同一件事把用户的学习行为变成可以反复计算的数据流。这个源码真正有价值的地方不在某个模型多先进而在它能不能根据答题记录判断掌握度、能不能按知识点前置关系推荐下一步、能不能自动生成错题反刍清单。对想自己做自适应学习系统、在线练习平台或者拿它当毕设课题的人来说这套思路比直接下载一个完整源码包更值得投入。2. 平台架构与数据模型设计把学习行为变成可计算的数据流这一章先解决最基础的问题拿到源码之后从哪里看起。我的经验是先别碰算法文件先看数据模型和模块边界。平台如果数据流设计得乱后面推荐、统计、复盘全部会跟着乱算法再花哨也救不回来。2.1 六类核心模块的职责划分行为数据、评估数据、推荐数据不能互相耦合我维护过的学习平台源码里一般按“数据从哪来、数据到哪去”划分成六个模块用户模块、资源模块、行为模块、评估模块、推荐模块、看板模块。每个模块的职责和依赖方向如下表模块主要资产依赖方向与边界用户模块账号、角色、学习目标被其余模块引用不反向依赖资源模块知识点、题库、讲义视频只被行为模块和推荐模块读取行为模块answer_record、study_session、event只写原始数据不读评估结论评估模块掌握度、学情画像只读行为数据推荐模块候选列表、学习路径只读评估结果看板模块学习曲线、统计报表只读聚合数据这里最容易翻车的是把“行为记录”和“评估结果”混在一张表里。比如在 answer_record 表上直接加一个 mastery_score 字段每次答完题当场更新。表面省事实际上一旦评估算法调整你就得写数据迁移脚本去修正历史数据否则所有学习曲线全部带着旧逻辑的痕迹。Python 生态里的选型我一般用 FastAPI 做接口层、SQLAlchemy 做 ORM、Pydantic 做请求校验原因是 FastAPI 的原生异步对答题这种高频写操作友好SQLAlchemy 的声明式模型可以快速把表结构映射成类。至于重计算任务比如全量掌握度重算丢给 Celery 异步 worker而不是在 Web 进程里起线程池硬扛。2.2 学习行为日志三张核心表AnswerRecord、StudySession、DailyProgress 怎么设计才不返工整个源码的地基是三张表answer_record 存答题明细study_session 存一次连续学习会话daily_progress 存按天的聚合数据。最小可用的 SQLAlchemy 模型如下from sqlalchemy import Column, Integer, String, Float, DateTime, ForeignKey, Text, JSON from sqlalchemy.orm import relationship from sqlalchemy.sql import func from .base import Base class AnswerRecord(Base): __tablename__ answer_records id Column(Integer, primary_keyTrue) user_id Column(Integer, ForeignKey(users.id), indexTrue) kp_id Column(Integer, ForeignKey(knowledge_points.id), indexTrue) correct Column(Integer, default0) # 1 正确 / 0 错误 answer Column(Text) # 学生提交的原文 spend_seconds Column(Integer, default0) # 答题耗时用于疲劳度分析 session_id Column(String(64), indexTrue) # 关联 study_sessions question_code Column(String(32), indexTrue) # 题目唯一编号用于幂等 created_at Column(DateTime, server_defaultfunc.now(), indexTrue) class StudySession(Base): __tablename__ study_sessions id Column(String(64), primary_keyTrue) # 推荐产生的 UUID 会话 user_id Column(Integer, ForeignKey(users.id)) started_at Column(DateTime, server_defaultfunc.now()) ended_at Column(DateTime, nullableTrue) source Column(String(20), defaultself) # self / recommend / review class DailyProgress(Base): __tablename__ daily_progress id Column(Integer, primary_keyTrue) user_id Column(Integer, ForeignKey(users.id)) day Column(String(10), indexTrue) # 统一用本地日期 2026-05-14 answered_count Column(Integer, default0) correct_count Column(Integer, default0) study_minutes Column(Integer, default0)逻辑上answer_record 是纯追加的流水表所有统计都从它聚合出来。correct 用整数而不是布尔是为了让 sum 和 avg 这类聚合查询不需要类型转换。session_id 的作用是隔离一次连续学习避免用户从推荐列表点进一道题时把上次复习会话的数据混在一起。question_code 是幂等键后面避坑章节会专门讲它怎么防止统计翻倍。daily_progress 看似冗余但它是看板模块和连续打卡功能的地基。如果每次看板都直接 count answer_record数据量过万之后接口响应时间会明显变慢。2.3 FastAPI 项目骨架最小可运行的源码目录与依赖注入写法源码目录不必一步到位搞成微服务但目录边界要清晰。我常用的结构是这样ai-learning-platform/ ├── app/ │ ├── main.py # FastAPI 入口与路由注册 │ ├── core/ │ │ └── config.py # 环境变量与参数读取 │ ├── api/ │ │ ├── deps.py # 数据库 Session、Redis 依赖 │ │ └── routes/ │ │ ├── learn.py # 答题、推荐、复习 │ │ └── dashboard.py # 学情统计 │ ├── models/ # SQLAlchemy 模型 │ ├── schemas/ # Pydantic 请求/响应模型 │ └── services/ # 评估、推荐、错题回顾逻辑 ├── scripts/ │ ├── init_db.py # 建表与初始化 │ ├── seed_data.py # 造测试知识点与题目 │ └── simulate_learning.py # 模拟学习行为回放 ├── tests/ └── requirements.txt入口和依赖注入的写法如下# app/main.py from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from app.api.routes import learn, dashboard app FastAPI(titleAI Learning Platform, version0.1.0) app.add_middleware( CORSMiddleware, allow_origins[*], allow_methods[*], allow_headers[*], ) app.include_router(learn.router, prefix/api/learn, tags[learn]) app.include_router(dashboard.router, prefix/api/dashboard, tags[dashboard])# app/api/deps.py from sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker, Session engine create_engine( settings.DATABASE_URL, pool_pre_pingTrue, # 连接被数据库断开后自动重连 pool_size5, # 连接池大小别超过数据库上限 pool_recycle3600, # 空闲连接 1 小时回收避免服务端断开 ) SessionLocal sessionmaker(bindengine, autoflushFalse, autocommitFalse) def get_db(): db SessionLocal() try: yield db finally: db.close()依赖注入的作用是让每个路由函数都拿到独立的数据库会话并且请求结束后自动关闭不需要在每个接口里手工写 try/finally。pool_pre_ping 是血泪经验换来的没有它的时候数据库重启一次连接池里的旧连接会直接导致下一个请求报 500。3. 掌握度评估与自适应推荐算法代码只有 50 行推荐质量全看参数怎么调推荐模块是平台里最像“AI”的部分但实现上并没有那么玄学。自适应的核心是一个决策链路先知道用户学了哪些知识点、掌握程度如何再结合知识点之间的前置关系挑出下一步最该学的内容。3.1 知识点图谱怎么建模前置关系、难度值、学习顺序计算知识点图谱在源码里通常有两种存法一种是用 Neo4j 这类图数据库另一种是在关系表里存 JSON 前置列表。学习平台初期几千个节点以内我建议直接存 JSON省掉一套图数据库的运维成本。# scripts/seed_data.py 的知识点样例 knowledge_points [ {code: PY-BASIC-01, title: Python 变量与类型, difficulty: 0.2, prerequisites: []}, {code: PY-BASIC-02, title: 函数与作用域, difficulty: 0.4, prerequisites: [PY-BASIC-01]}, {code: PY-BASIC-03, title: 闭包与装饰器, difficulty: 0.7, prerequisites: [PY-BASIC-02]}, {code: PY-ALGO-01, title: 复杂度分析, difficulty: 0.5, prerequisites: [PY-BASIC-01]}, ]# app/services/graph.py from typing import Dict, List def build_graph(kps: List[dict]) - Dict[str, List[str]]: 把知识点列表转成邻接表code - 前置 code 列表 graph {} for kp in kps: graph[kp[code]] kp.get(prerequisites, []) return graph def find_learning_order(graph: Dict[str, List[str]], target_code: str) - List[str]: 从目标知识点倒推学习顺序前置优先 order [] visited set() def dfs(code: str): if code in visited: return visited.add(code) for pre in graph.get(code, []): dfs(pre) order.append(code) dfs(target_code) return order这里的关键参数是 difficulty它会影响推荐的候选优先级但不参与前置关系的判定。find_learning_order 用 DFS 回溯是为了在用户点击“学完这个知识点后下一步学什么”时把整个前置链条一次找齐。注意如果图谱节点超过几千个这套实时 DFS 会有明显延迟。规模上来之后把学习顺序改成启动时预计算存成 Redis 缓存而不是每次请求都重新遍历。3.2 掌握度评估函数正确率加权、遗忘曲线衰减、归一化掌握度是一个 0 到 1 之间的浮点数代表用户当前对一个知识点的熟练程度。最简单的做法是正确次数占总答题次数的比例但这样会有问题三周前答对一次和昨天答对一次能被认为是同一个水平吗显然不能。所以评估函数要引入时间衰减和答题顺序权重# app/services/assessment.py import math from datetime import datetime, timezone from typing import List def evaluate_mastery(answer_records: List[dict]) - float: 根据答题记录计算掌握度越近的答题权重越高 if not answer_records: return 0.0 total_weight 0.0 weighted_score 0.0 now datetime.now(timezone.utc) for i, rec in enumerate( sorted(answer_records, keylambda r: r[created_at], reverseTrue) ): # 时间衰减30 天前的一次答题权重下降到 1/e 左右 elapsed_days max((now - rec[created_at]).days, 0) time_weight math.exp(-elapsed_days / 30.0) # 顺序权重最近一次答题对当前水平影响最大 order_weight 1.0 / (1 i * 0.25) w 0.6 * time_weight 0.4 * order_weight weighted_score w * (1.0 if rec[correct] else 0.0) total_weight w score weighted_score / total_weight if total_weight 0 else 0.0 return round(score, 4)参数默认值作用调优建议half_life_days30控制遗忘速度天数越短衰减越快严肃考试类平台调到 15练习类调到 30time_weight0.6时间衰减占总权重比例新用户适当调高老用户保持order_weight0.4最近答题顺序权重答题频率越高这个值可以越低掌握度更新还有一个更平滑的替代方案EMA 指数移动平均。每来一条新记录只把过去的掌握度降低一部分再叠加本次结果def update_mastery(old_score: float, is_correct: int, alpha: float 0.3) - float: EMA 更新新一次答题结果只贡献 30% 权重 new_score 1.0 if is_correct else 0.0 return round(old_score * (1 - alpha) new_score * alpha, 4)EMA 的优点是曲线不会因为一道题判错就剧烈震荡。如果后续做学习曲线可视化建议用 EMA 版本作为展示数据用完整加权版本作为推荐排序数据。3.3 推荐接口实现阈值、冷却时间、候选数三个入口参数决定推荐质量推荐逻辑本质是过滤加排序。过滤条件有三条前置知识点达到掌握阈值、当前知识点还没掌握、不在冷却期内。排序时把掌握度缺口、难度匹配度、最近学习时间综合成一个 priority 分数。# app/services/recommender.py from typing import List def recommend_next( kp_scores: dict, # code - 掌握度 graph: dict, # code - 前置列表 all_kps: List[dict], # 所有知识点 mastery_threshold: float 0.65, # 前置必须达到的掌握度 cooldown_hours: int 6, # 同一知识点最短间隔 max_candidates: int 3, # 返回候选数量 ) - List[dict]: candidates [] for kp in all_kps: code kp[code] pre_scores [kp_scores.get(p, 0.0) for p in graph.get(code, [])] # 前置没掌握先不推荐 if any(s mastery_threshold for s in pre_scores): continue # 自己已经掌握也不需要推荐 if kp_scores.get(code, 0.0) mastery_threshold: continue # 冷却期内不反复推荐同一个知识点避免用户烦躁 elapsed_hours kp.get(last_studied_hours_ago, 9999) if elapsed_hours cooldown_hours: continue urgency 1.0 - kp_scores.get(code, 0.0) # 掌握度越低越紧急 diff_fit 1.0 - abs(kp[difficulty] - 0.5) # 难度越接近 0.5 越合适 recency min(elapsed_hours / 48.0, 1.0) # 学得越久越该捡起来 candidates.append({ **kp, priority: urgency * 0.5 diff_fit * 0.3 recency * 0.2, }) candidates.sort(keylambda x: -x[priority]) return candidates[:max_candidates]参数默认值作用调优建议mastery_threshold0.65判定“学会”的门槛题目难就降到 0.55否则会永远推不出去cooldown_hours6冷却期防止刷同一个点考前冲刺模式调到 1max_candidates3每次返回几个候选移动端给 2网页端给 3 到 5这套逻辑最大的优点是可解释。用户问“为什么推荐这个知识点”你可以直接回答因为你学完了前置的 X 和 Y而这个知识点你还不太熟。可解释性对 AI 学习平台来说比推荐精度更重要因为它直接关系到用户对平台的信任。4. 学习闭环的三个关键模块源码答题提交、错题回顾与每日目标推荐只是入口用户真正每天用的是答题、看解析、回顾错题、完成任务。这一章把学习闭环里的三个关键接口拆开讲。4.1 答题提交与即时掌握度快照一次事务里完成判定和落库答题接口是整个平台写入量最大的接口设计目标只有一个不能丢数据也不能重复数据。# app/api/routes/learn.py from fastapi import APIRouter, Depends from sqlalchemy.orm import Session from app.api.deps import get_db from app.models.learning import AnswerRecord, StudySession from app.schemas.learn import AnswerSubmit router APIRouter() router.post(/submit) def submit_answer(payload: AnswerSubmit, db: Session Depends(get_db)): # 1. 判定答案单选题比较字符串多选题排序后比较简答题走关键词或大模型 is_correct judge_answer( payload.question_type, payload.answer, payload.standard_answer, ) # 2. 写入答题记录session 和 answer 必须在同一事务 record AnswerRecord( user_idpayload.user_id, kp_idpayload.kp_id, correct1 if is_correct else 0, answerpayload.answer, spend_secondspayload.spend_seconds, session_idpayload.session_id, question_codepayload.question_code, ) db.add(record) # 3. 没有会话时补建一条记录本次学习的来源 session db.query(StudySession).filter( StudySession.id payload.session_id ).first() if session is None: db.add(StudySession( idpayload.session_id, user_idpayload.user_id, sourcepayload.source, )) db.commit() # 4. 返回本次答题后的掌握度快照用于前端展示 mastery evaluate_mastery_now(db, payload.user_id, payload.kp_id) return { correct: is_correct, mastery_snapshot: mastery, explanation: payload.explanation if not is_correct else None, }judge_answer 是这个接口里唯一需要按题型扩展的部分。我的建议是给每种题型写一个独立的判定函数不要在一个函数里堆 if else否则后续加判断题、填空题、程序题时改动面会越来越大。第 4 步的掌握度快照会实时重算如果单机并发量超过每秒几十次请求这一步建议改成异步更新接口先返回上次计算的掌握度新记录落库后由 worker 重算。4.2 错题回顾不用静态错题表用动态聚合查询自动更新很多学习平台源码里都有一张错题表答错了就 insert 一条进去答对了再 delete。这个方案最大的问题是逻辑分散用户可能在某个知识点上先错后对、再错再对静态表里的状态很容易和真实水平脱节。我在源码里更推荐用动态聚合查询错题列表不是一张实际存储的表而是一个查询结果# app/services/review.py from datetime import datetime, timedelta, timezone from sqlalchemy.orm import Session from sqlalchemy import func from app.models.learning import AnswerRecord def get_review_list(db: Session, user_id: int, limit: int 10): 最近 3 天内正确率低于 50% 的知识点按错误时间倒序返回 recent ( db.query( AnswerRecord.kp_id, func.count().label(cnt), func.sum(AnswerRecord.correct).label(correct_cnt), func.max(AnswerRecord.created_at).label(last_at), ) .filter( AnswerRecord.user_id user_id, AnswerRecord.created_at datetime.now(timezone.utc) - timedelta(days3), ) .group_by(AnswerRecord.kp_id) .all() ) review_list [] for kp_id, cnt, correct_cnt, last_at in recent: accuracy correct_cnt / cnt if cnt else 0 if accuracy 0.5: review_list.append({ kp_id: kp_id, accuracy: round(accuracy, 2), last_at: last_at, }) review_list.sort(keylambda x: x[last_at], reverseTrue) return review_list[:limit]动态聚合的好处是错题列表永远跟随答题记录自动更新。用户连续答对三道错题正确率超过 50%这个知识点自然从错题列表里消失不需要额外写删除逻辑。时间窗口设 3 天比较合理太短会把低频但重要的知识点漏掉太长会让列表堆满历史遗留问题。4.3 每日学习目标与连续天数用 DailyProgress 聚合表和 streak 函数驱动用户回来学习连续学习天数也就是常说的 streak是学习平台留存的核心机制。实现它不需要每天一个定时任务只需要在写入行为数据时同步更新 daily_progress再写一个计算函数# app/services/streak.py from datetime import datetime, date, timedelta, timezone from sqlalchemy.orm import Session from app.models.learning import DailyProgress def calc_streak(db: Session, user_id: int) - int: 计算连续学习天数断掉重新计数 rows ( db.query(DailyProgress.day) .filter(DailyProgress.user_id user_id) .order_by(DailyProgress.day.desc()) .limit(60) .all() ) study_days {r.day for r in rows} streak 0 cur datetime.now(timezone.utc).date().isoformat() while cur in study_days: streak 1 cur (date.fromisoformat(cur) - timedelta(days1)).isoformat() return streak计算逻辑很直接从今天开始往前数遇到没有学习记录的日子就停止。这里最容易踩的坑是日期时区不一致。如果 recording 用 UTC 日期用户在北京时间凌晨 0 点到 8 点学习记录会被写进“昨天”连续天数就会莫名断掉。所以 daily_progress.day 字段必须用用户所在时区的本地日期而不是服务器 UTC 日期。5. 避坑指南AI 学习平台源码最容易翻车的五个坑这一章写的是我在维护学习平台源码时真实遇到过的坑每一条都对应一个具体的现象、原因和解决办法希望你能绕开。5.1 坑一初始化数据库就撞外键原因是插入顺序与前置引用时机不对现象第一次执行 scripts/init_db.py建表时没有任何问题但往 knowledge_points 插入带 prerequisites 的节点时报外键错误或者程序顺序执行到一半直接中断。原因知识点表用 JSON 存前置关系时SQLAlchemy 不会自动校验 JSON 里的内容。但如果你图省事把前置关系单独建了一张关联表初始化时先插了有前置引用的节点对应前置节点还没插入数据库自然拒绝。解决把初始化拆成两步。第一步只插入所有知识点的基础字段prerequisites 先留空第二步再统一加载前置关系。外键约束全部用整数 id不要用 code 字符串做关联整型主键在数据库层面索引更高效。5.2 坑二推荐结果恒定不变知识点学完了依然被推荐现象用户连续答完 10 道题掌握度已经明显提升但推荐接口每次返回的还是同一个知识点。原因推荐结果被缓存后缓存键没有关联用户最近的答题记录。更隐蔽的一种情况是推荐函数里用了模块级变量存储掌握度进程不重启数据就不更新形成了一种“假缓存”。解决最快的方式是先把缓存去掉直接读数据库数据量几千条时性能完全够用。如果确实要加 Redis 缓存缓存键必须带上用户最近答题时间比如recommend:{user_id}:{last_answer_ts}TTL 设 300 秒这样每次答题后缓存自然失效。掌握度计算也一律从 AnswerRecord 表实时聚合不落地到内存变量。5.3 坑三本地跑得欢部署就超时SQLite 与连接池的并发差异现象源码在本地开发环境一切正常部署到服务器之后接口随机返回 500日志报 database is locked 或 connection reset。原因本地开发一般用 SQLite本质是文件锁单进程没问题多 worker 并发提交时文件锁冲突就会报错。另一个原因是连接池配置不对数据库服务断开空闲连接后连接池里还留着坏连接。解决生产环境换成 PostgreSQL 或 MySQLSQLite 只保留给自动化测试用。连接串至少要配三个参数pool_pre_pingTrue、pool_size5、pool_recycle3600。这几个参数的组合能解决大多数“本地能跑、上线就挂”的数据库问题。5.4 坑四统计面板正确率超过 100%缺少幂等约束导致重复计数现象看板显示正确率 180%明显不合理检查 AnswerRecord 表发现同一条答题记录出现两次。原因前端重复提交或者网络超时后用户手动重试同一个 session 和同一个 question_code 被插入两次。数据库没有唯一约束重复数据直接入库。解决给 answer_record 加唯一索引覆盖 user_id、session_id、question_code 三列然后插入语句换成 on_conflict_do_nothingfrom sqlalchemy.dialects.sqlite import insert as sqlite_insert stmt sqlite_insert(AnswerRecord).values( user_idpayload.user_id, kp_idpayload.kp_id, correct1 if is_correct else 0, answerpayload.answer, spend_secondspayload.spend_seconds, session_idpayload.session_id, question_codepayload.question_code, ) stmt stmt.on_conflict_do_nothing(index_elements[ user_id, session_id, question_code, ]) db.execute(stmt) db.commit()如果是 PostgreSQL把 sqlite_insert 换成 postgresql_insert语法完全一致。加了幂等约束之后即使前端重复调用数据也不会翻倍。5.5 坑五接大模型点评后整个答题接口卡死缺超时与异步降级现象原来 200 毫秒返回的答题接口接入大模型做简答题点评后变成 30 秒模型服务一抖动整个接口直接超时。原因Web 进程在同步等待外部模型服务返回没有设置超时也没有降级策略。一个模型调用慢会拖垮所有请求。解决把大模型点评拆到异步队列接口先返回“批改中”状态批改完成后由前端轮询或 WebSocket 推送结果。如果坚持同步调用至少要用 asyncio.wait_for 做硬超时import asyncio async def call_llm_with_timeout(content: str, timeout: int 10): try: return await asyncio.wait_for( llm_client.complete(content), timeouttimeout, ) except asyncio.TimeoutError: # 降级到传统规则评分保证接口不挂 return fallback_keyword_score(content)这里的关键不是超时时间设多少而是必须有一个降级路径。没有降级路径超时和不超时都等于白搭。6. 上线前用行为回放脚本验证整条学习链路从单机 Demo 到可交付源码最后这一步是我交付任何学习平台源码之前必做的验证流程。很多源码看起来功能齐全但数据链路从来没有被完整跑通过推荐 - 答题 - 评估 - 更新推荐这四个环节只要有一个断开平台就是摆设。我习惯写一个 simulate_learning.py 脚本模拟一批用户按照“学习-答题-复习”的节奏使用平台然后断言关键指标。脚本的核心逻辑如下# scripts/simulate_learning.py import random from datetime import datetime, timedelta, timezone from app.services.recommender import recommend_next from app.services.assessment import evaluate_mastery def simulate_user(db, user_id: int, days: int 7): 模拟一个用户连续 7 天学习每天答 5 题 for day in range(days): # 1. 拿推荐结果 candidates recommend_next(kp_scores, graph, all_kps) if not candidates: continue # 2. 模拟答题掌握度低的题目正确率低一些 for kp in candidates: score kp_scores.get(kp[code], 0.0) correct_prob 0.3 score * 0.6 is_correct 1 if random.random() correct_prob else 0 # 3. 写入答题记录 answer_records.append({ kp_id: kp[id], correct: is_correct, created_at: datetime.now(timezone.utc) - timedelta(daysdays - day), }) # 4. 重算掌握度 for kp in candidates: kp_scores[kp[code]] evaluate_mastery( [r for r in answer_records if r[kp_id] kp[id]] ) return kp_scores跑完之后检查三个指标一是每个知识点的掌握度是否随时间逐步上升二是错题回顾列表是否随正确率提升自动缩短三是推荐结果里的知识点是否与前一轮不同。提示模拟脚本不模拟真实用户但它是数据链路的“最小冒烟测试”。任何一次评估或推荐逻辑改动之后先跑一遍模拟脚本再手动开服务验证能省掉大量排错时间。之前有一次给某位导师交源码我只写了路由和数据模型导师第一句话问“你的推荐依据是从哪张表算出来的”我答不上来因为我自己都没把学习链路完整跑过一遍。从那以后我养成了一个习惯所有学习平台源码交付前先跑一次行为回放脚本把三个指标数据贴进 README。评估逻辑是黑匣子还是能复现决定了这份源码是被当成作业交掉还是真的可以被团队接手投入后续开发。这个习惯帮我绕开了很多次翻车也分享给你希望帮到你。本文还有配套的精品资源点击获取