AI Python Mentor：用FastAPI与RAG构建AI编程学习平台

单纯用LLM API搭一个聊天界面并不难。难的是围绕AI构建一套完整的学习平台——把结构化课程、编程练习、个性化学习和AI导师整合进同一个全栈系统。开源项目AI Python Mentor正是对这一问题的系统回答。

该项目由开发者coffee1337在GitHub上开源，目标是帮助用户学习Python和后端开发。与市面上"让AI直接生成解释"的做法不同，AI Python Mentor的核心理念是：AI应该支撑结构化学习，而不是替代它。

为什么需要"AI+课程"而非"AI+聊天"

一个通用LLM可以解释Python概念，但它不知道学生当前在学哪一课，也不知道课程材料的最新版本是什么。这导致AI的回答可能技术正确，却完全不适合学习者当前的水平。

AI Python Mentor通过组合多种学习机制来解决这个问题：

• 覆盖Python和后端概念的结构化课程
• 编程练习与知识检测
• 能访问课程上下文的AI导师
• 个性化学习路线图
• 进度追踪与间隔重复
• 面向职业的技能差距分析
• 实战作品集项目

这种多机制组合的设计思路，使得平台既有AI的灵活性，又保持了课程体系的严谨性。

技术栈选型

项目的技术栈选择体现了清晰的分层思维：

后端采用Python 3.12 + FastAPI + PostgreSQL，配合SQLAlchemy和Alembic管理数据访问与schema演进，Pydantic负责数据校验，全程基于AsyncIO异步模型。开发者选择FastAPI的原因是其对异步API开发、显式校验和模块化后端设计的良好支持。

前端使用Next.js 15 + React 19 + TypeScript，保持现代React生态的主流配置。

AI层包含LLM Gateway、检索增强生成（RAG）、基于课程的知识索引，以及token用量与成本核算。

基础设施方面，采用Docker与Docker Compose、GitHub Actions、后台Worker和数据库迁移工具。

说个细节，项目还特别支持原生Windows开发环境，无需为每个本地工作流都依赖Docker——这在开发者体验上是一个务实的考量。

系统架构：模块化单体与AI解耦

AI Python Mentor采用模块化单体（modular monolith）架构，而非上来就拆微服务。核心API负责认证、学习进度、课程、练习和集成，专门化任务则由独立进程处理。

架构的一个关键设计目标是：核心学习功能不依赖外部AI服务的可用性。如果AI Gateway不可用，用户仍能访问课程和其他非AI功能。这种解耦让应用更易维护和演进，也避免了"AI挂了整个平台就瘫了"的问题。

模块化单体（Modular Monolith） 是一种介于传统单体应用与微服务之间的架构风格。它仍以单个部署单元运行，但在代码层面按业务能力（如认证、课程、练习、AI集成）划分出边界清晰的模块，模块之间通过显式接口而非任意互相调用进行通信。相比微服务，它避免了分布式事务、网络调用、服务发现等带来的复杂度和运维成本；相比“大泥球”式的单体，它又保留了未来按需拆分服务的能力。对于早期项目或小团队而言，这种架构可以让团队先把业务逻辑和边界理清楚，等到某个模块确实需要独立伸缩或独立部署时，再把它拆出去。AI Python Mentor正是利用这种结构，把核心学习平台与AI能力在模块层面解耦，从而实现在AI Gateway不可用时，课程等非AI功能依然能正常提供服务。

用RAG打造有课程上下文的AI导师

RAG在这个项目里扮演了关键角色。AI Python Mentor使用基于已发布课程内容不可变快照构建的本地知识索引，基本流程是：

1. 学生提问
2. 识别当前课程
3. 检索相关课程上下文
4. 构建LLM请求
5. 生成有上下文依据的解释
6. 追踪用量与成本

通过从学习材料中检索上下文，AI导师的解释能扎根于学生正在学习的内容。平台还会追踪AI用量和成本——这在依赖付费LLM API的产品中是必须考虑的问题，而非事后补充。

核心洞察：RAG在教育场景中的价值不在于"让AI更聪明"，而在于让答案反映特定版本的学习材料。

检索增强生成（RAG, Retrieval-Augmented Generation） 是一种把“外部知识检索”与“大模型生成”结合的技术范式。它的典型流程是：先把外部文档切分成片段并转化为向量，存入向量数据库或本地索引；当用户提出问题时，系统先把问题向量化，再检索出语义最相近的若干片段；最后把这些片段作为上下文，与用户问题一起拼进提示词交给LLM生成答案。RAG的关键价值在于，它让模型回答时依据的是被检索到的真实材料，而不是仅凭训练时记住的参数化知识，因此能降低幻觉，并让答案可追溯到具体来源。在教育场景中，这一点尤其重要：课程内容可能更新到某个特定版本，RAG能确保AI导师的解释与当前发布的材料一致，而不是给出与课程脱节的泛泛之谈。

Python代码执行的安全边界

编程练习需要执行用户提交的Python代码。用户按简单契约提交解法：

def solve(payload):
    # 用户实现
    ...

练习可以定义公开示例和隐藏测试，平台存储提交和尝试历史。但如果直接在主API中执行不受信任的Python代码，将带来严重的安全风险。

因此，系统将执行调度与主应用分离，定义了独立的Python Runner架构。生产执行模型围绕隔离和资源限制设计，包括容器或沙箱边界。

关键设计决策：主Web API绝不成为任意用户代码的执行环境。开发者也坦诚指出，不受信任代码执行默认关闭，生产Runner仍需适当的隔离部署和安全配置。

沙箱（Sandbox）与容器隔离 是执行不受信任代码时的核心安全手段。沙箱通过限制代码可访问的系统资源（文件、网络、进程、系统调用等），把潜在破坏控制在最小范围内；容器则利用命名空间和控制组提供进程、文件系统、网络层面的隔离。对于需要运行用户提交代码的平台，常见实践包括：在独立的一次性容器中执行、禁止或严格限制网络访问、设置CPU与内存上限、限制执行时长、以非root用户运行、挂载只读文件系统，以及通过seccomp等机制过滤危险系统调用。即便采取了这些措施，容器逃逸、资源耗尽等风险依然存在，因此生产环境通常还需要更彻底的隔离方案（如gVisor、Firecracker微虚拟机）以及严格的配额与审计。这也解释了为什么该项目默认关闭不受信任代码执行，并强调主Web API绝不直接运行用户代码。

认证、后台任务与测试

后端包含完整的账号安全功能：基于Cookie的会话、Argon2密码哈希、CSRF防护、邮箱确认与密码恢复、会话撤销、账号导出与删除、管理审计日志。这些功能提醒我们：真实应用需要的远不止一个能工作的登录接口。

架构还包含后台处理，用于通知和执行调度等负载，避免所有操作都挤在HTTP请求中执行。

测试方面，仓库包含后端功能、数据库迁移、前端构建、Worker逻辑和浏览器流程的自动化检查，由GitHub Actions驱动。

后台任务（Background Jobs）与Worker 是Web应用中处理非即时、耗时长或需要重试的工作的常见模式。与在HTTP请求内同步完成不同，后台任务会把工作放入队列（如Redis、RabbitMQ或数据库队列），由独立的Worker进程异步消费执行。这样做的好处是：HTTP接口能快速返回，避免用户长时间等待；任务可以按需重试、限流、延时执行；计算密集或可能失败的操作不会拖垮Web服务本身。典型场景包括发送邮件通知、执行代码评测调度、生成报告、定时清理数据等。在AI Python Mentor中，后台Worker承担通知和执行调度等负载，避免所有操作都挤在HTTP请求周期中执行，这也是保障系统稳定性和响应速度的重要工程实践。

当前状态与暴露的工程教训

项目仍在积极开发中。核心学习平台、后端、AI集成、数据库层和CI基础设施已实现，当前工作聚焦于产品打磨、学习内容质量、AI评估和生产部署。

开发者保持透明：拥有面向生产的架构，不等于所有计划的生产组件都已部署。

项目沉淀出四条工程教训：

1. AI应该是组件，而非整个架构——有用的AI产品仍需要可靠的认证、数据模型、应用逻辑和运维保障。
2. 结构化上下文很重要——RAG在答案需要反映特定版本材料时尤其有价值。
3. 安全边界要早期设计——当应用接受可执行代码时尤为关键。
4. 运维关注点就是产品功能——用量配额、成本追踪、后台任务和测试都关乎AI应用的长期可行性。

结语

AI Python Mentor的价值不仅在于它是一个可用的学习平台，更在于它展示了一种构建AI产品的思路：把AI当作系统中的一个组件，围绕它构建完整的工程支撑。对于正在做AI+教育、RAG系统或SaaS MVP的开发者，这个开源项目的架构决策值得参考。

代码与架构可访问GitHub仓库查看，开发者也在寻求Python后端、FastAPI、AI/LLM集成、RAG系统和SaaS MVP开发方面的合作机会。

GitHub：https://github.com/coffee1337/ai-python-mentor