做 Python 教学工具时，我最在意的并不是“AI 能不能回答问题”，而是学生每次学习之后，系统能不能知道他做过什么、卡在哪里，以及下一步应该学什么。只把大模型接进聊天框，很难把这些过程变成连续、可解释的学习记录。

所以我开始做 PyMentor Lab：一个面向高等教育 Python 学习场景的全栈学习系统。它把学习证据、能力画像、个性化路径、代码练习、AI 辅导和延迟复习串在一起。大模型负责生成建议和学习材料，正式的路径与掌握度判断则交给可复核的确定性规则。

项目仓库：SuShuheng/PyMentor-Lab。

从一次答题，形成可追踪的学习证据

PyMentor Lab 的核心不是单轮问答，而是一条持续更新的学习闭环：

  1. 学生完成练习、运行代码或提交答案；
  2. 系统把交互记录为学习证据；
  3. 证据更新到八个维度的能力画像；
  4. 路径引擎根据画像和课程知识结构验证下一步学习内容；
  5. 任务编译器生成练习，AI 辅导流程提供提示与学习资源；
  6. 确定性掌握策略结合测评结果安排掌握状态和延迟复测。

课程知识资产目前包含 14 章、93 个知识节点。它们为路径规划和任务生成提供结构化基础，也让系统可以把“为什么推荐这一步”关联到具体知识点和学习记录。

让大模型参与教学，但不替学生打分

AI 可以帮助解释概念、生成示例和提示，也可以根据任务生成多种学习资源。但如果让模型直接决定学生是否掌握知识，结果就很难稳定复现，也不容易解释。

因此，项目把职责拆开：LangGraph 工作流负责组织画像分析、路径校验、任务编译、资源生成、测评和延迟复习等环节；掌握度、路径和关键快照则由后端确定性引擎负责。模型产出进入正式流程前，还要经过结构校验和发布门禁。

这使关键结论可以回看它所依据的证据与规则。模型适合提供教学辅助，正式的掌握判断仍由可验证的逻辑完成。

一个多端协作的单体仓库

项目采用 monorepo 组织，主要部分包括：

  • Web 学生端：学习、代码实验、查看学习资源；
  • Admin 管理端：运维、健康状态、日志、审计和 Agent 回放等功能；
  • Electron 桌面端：桌面应用外壳；
  • FastAPI 后端：身份与权限、学习证据、路径、掌握度和代码执行编排；
  • LangGraph.js Worker：运行多节点辅导流程和资源生成；
  • Python 沙箱：隔离运行学生提交的代码，并收集运行轨迹；
  • 共享契约与课程资产：通过 Pydantic 和 Zod 约束 Python 服务与 TypeScript 前端、Worker 之间的数据边界。

本地开发环境由 Docker Compose 组织 PostgreSQL、Redis、MinIO、API、Worker 和沙箱等服务。跨端契约有单独的检查门禁，避免服务和界面各自理解出不同的数据格式。

当前进度与适用边界

仓库内 2026-07-19 生成的 V1.0 缺口报告记录了后端确定性引擎与多项集成闭环的验证结果，包括代码沙箱、掌握策略、五类学习资源、六节点 Agent 工作流和 93 个课程知识节点。报告同时明确标记 V1.0 尚未达到正式发布条件：前端 P0 功能仍有缺口，部分管理与语音能力未完成，真实模型服务和 Windows 签名交付也存在外部条件。这些状态对应报告形成时的项目快照，发布前应以仓库最新进展为准。

因此，当前更适合把它看作持续迭代中的竞赛项目与学习系统原型。项目仓库中的许可为专有许可（All Rights Reserved），并非开源许可证；查看或访问仓库不代表可以复制、分发或商用。若准备公开发布本文，建议同时确认仓库的可见范围与许可说明。

写在最后

PyMentor Lab 让我不断回到一个问题：教育场景里的 AI，怎样才能既有生成能力，又能对重要结论负责？目前我的答案是把模型放在它擅长的辅助位置，再用清晰的数据证据和确定性规则托住关键判断。

项目仍在推进中。接下来我会继续补齐学习流程的前端体验、管理能力和真实服务验证，也会根据实现进度更新这篇介绍。

项目资料

  • 项目仓库：GitHub - SuShuheng/PyMentor-Lab
  • 项目技术栈：Python 3.13、FastAPI、LangGraph.js、React、TypeScript、Electron、PostgreSQL、Redis、MinIO、Docker Compose
  • 发布状态：以仓库中的最新说明与验证报告为准