1. 为什么我要自己搭一个AI辅导老师
市面上打着“AI学习助手”旗号的产品不少，但真正用起来你会发现几个绕不开的痛点：要么是按月订阅费用不低，要么是对话记录留在别人服务器上心里不踏实，要么是通用模型对学科知识的把握浮于表面，问一道稍微绕一点的物理题就开始胡编。我自己在辅导几个学生的时候，反复被同一个问题困扰——每个学生的薄弱点完全不同，用同一个通用助手去应付所有人，效果约等于没有。
DeepTutor 这个开源项目吸引我的地方，就在于它把“个性化”这件事真正落到了架构层面。它不是简单套一个聊天界面，而是把知识库检索、学科提示词模板、学习进度追踪这几块拆开，让你可以针对不同学生、不同科目分别配置。换句话说，你搭出来的不是一个通用聊天机器人，而是一个能记住“这个学生在三角函数上老出错、那个学生对化学方程式配平有障碍”的专属辅导老师。
这篇内容适合谁看？如果你是有一定动手能力的家长、独立教师、教培从业者，或者单纯想给自己搭一个不受平台限制的学习工具，那这套部署流程值得花一个下午跑一遍。整个过程不需要你懂深度学习训练，但需要你会基本的命令行操作、能看懂配置文件。我会把每一步为什么这么做讲清楚，包括我踩过的几个坑，让你少走弯路。
需要提前说明的是，DeepTutor 本身是一个开源框架，它的能力上限取决于你接入的模型和你喂给它的知识库。我下面讲的是基于常见实践的完整部署路径，具体版本号可能随项目迭代有变化，但核心逻辑是稳定的。
2. 部署前的环境盘点与选型逻辑
2.1 硬件到底要什么配置才够用
很多人一看到“AI”两个字就以为必须上高端显卡，其实要分情况。DeepTutor 的架构是“前端交互 + 后端推理 + 向量检索”三层，真正吃硬件的是推理那一层。如果你打算本地跑模型，那显存确实是硬门槛；但如果你接入的是云端模型接口，那本地只需要一台能跑向量数据库和Web服务的普通机器就行。
我实测下来，分三种情况给你参考：
| 部署方式 | 最低配置 | 推荐配置 | 适用场景 |
|---|---|---|---|
| 纯云端模型接口 | 2核4G内存 | 4核8G内存 | 个人使用、学生数量少 |
| 本地小模型（7B级别） | 8核16G内存 + 8G显存 | 12核32G + 12G显存 | 注重隐私、不想调接口 |
| 本地大模型（13B以上） | 12核32G + 16G显存 | 16核64G + 24G显存 | 多学生并发、复杂推理 |
这里有个容易被忽略的点：向量数据库对内存的消耗会随着知识库文档数量增长。我一开始用4G内存的机器，导入了几本教材之后检索速度明显变慢，后来加到8G才顺畅。所以如果你打算喂大量资料，内存要留足余量。
提示：如果你只是先跑通流程验证效果，完全可以用云端接口 + 最低配置先跑起来，等确认好用再考虑升级硬件或转本地模型。
2.2 依赖环境里最容易翻车的几个地方
DeepTutor 的依赖栈大致是 Python 后端 + Node 前端 + 向量数据库。听起来常规，但实际操作中有几个坑我必须要提醒你。
第一个是 Python 版本。项目通常要求 3.10 或 3.11，如果你系统自带的是 3.8 或者 3.12，某些依赖包会编译失败。我建议用 conda 或 pyenv 单独建一个虚拟环境，别污染系统 Python。命令大概是这样：
conda create -n deeptutor python=3.11 conda activate deeptutor第二个是向量数据库的选择。项目默认可能用的是某款轻量级向量库，但如果你知识库规模大，建议换成支持持久化和索引优化的方案。这个在配置文件里改一行的事，但选错了后期迁移很麻烦。
第三个是前端构建时的 Node 版本。我遇到过 Node 16 构建报错、换成 Node 18 就正常的情况。如果你不确定，直接上 Node 18 LTS 最稳。
2.3 模型接入方式的选择：本地还是云端
这是整个部署里最关键的决策，没有之一。我把它拆成几个维度帮你判断：
隐私敏感度：如果学生的学习数据、你的辅导记录绝对不能外传，那必须本地模型。云端接口意味着对话内容会经过第三方服务器。
预算：本地模型是一次性硬件投入，云端接口是按调用量付费。学生多、对话频繁的话，长期看本地更划算；但如果你只是偶尔用，云端前期成本几乎为零。
效果要求：同等硬件条件下，云端大模型的效果通常优于本地能跑的小模型。如果你对回答质量要求高，又不想买昂贵显卡，云端接口是更务实的选择。
维护精力：本地模型需要你自己处理模型更新、显存优化、并发调度；云端接口这些都不用管，但你要处理网络波动和接口限流。
我自己的方案是混合：日常答疑用云端接口保证质量，涉及学生隐私数据（比如错题本分析）走本地小模型。DeepTutor 的配置支持多模型路由，这个后面会讲怎么配。
3. 从零到跑通的完整部署链路
3.1 拉取代码与目录结构解读
先把项目拉到本地：
git clone <项目仓库地址> deeptutor cd deeptutor拉下来之后别急着装依赖，先花两分钟看看目录结构，这能帮你后面少走很多弯路。典型的目录大概长这样：
backend/：Python 后端，核心的检索和推理逻辑都在这里frontend/：前端界面，负责聊天窗口和学习进度展示config/：配置文件目录，模型接入、数据库连接都在这改data/：知识库原始文档存放位置scripts/：一些辅助脚本，比如初始化数据库、导入文档
我特别要提醒的是config/目录。很多人部署失败就是因为没仔细看配置文件里的注释，直接用了默认值。默认值通常是为了演示方便，不一定适合你的实际场景。
3.2 后端依赖安装与数据库初始化
进入后端目录装依赖：
cd backend pip install -r requirements.txt这一步如果卡在某个包上，大概率是编译工具链不全。Linux 下先装build-essential和python3-dev，Windows 下建议用 WSL 或者直接上 Linux 服务器，能省掉大量折腾。
依赖装完后，初始化向量数据库。项目一般会提供一个脚本：
python scripts/init_db.py这个脚本会创建数据库表结构、初始化索引。如果你后面要换向量库，这一步要重新跑。我建议初始化完成后先跑一个测试脚本验证连接是否正常，别等到导入文档时才发现连不上。
3.3 知识库文档的预处理与导入
这是决定你的AI辅导老师“聪不聪明”的关键步骤。DeepTutor 支持导入 PDF、Word、Markdown 等格式，但不是直接扔进去就行。
文档预处理有几个要点：
分块策略：太长的文档要切成合适大小的块，一般 500-1000 字一块比较合适。切太碎会丢失上下文，切太大检索精度下降。项目通常有默认的分块参数，但你可以根据教材特点调整。
元数据标注：给每个文档块打上科目、年级、章节标签。这样检索时可以按标签过滤，比如学生问三角函数，就只在数学-三角章节里检索，避免化学内容干扰。
格式清洗：PDF 里的公式、表格转成纯文本后往往面目全非。如果教材里公式多，建议先用工具转成 LaTeX 再导入，效果会好很多。
导入命令大概是这样：
python scripts/import_docs.py --path ../data/math --subject math --grade 10导入完成后，一定要做一次检索测试，随便问一个知识点，看返回的文档块是否相关。这一步偷懒，后面答疑质量差你都不知道问题出在哪。
3.4 前端构建与联调
后端跑起来后，进前端目录：
cd frontend npm install npm run build构建完成后启动服务，默认会连本地后端。如果前后端端口不一致，记得在环境变量或配置文件里改。
联调阶段重点测三件事：聊天是否正常返回、知识库检索是否生效、学习进度是否正确记录。我遇到过前端显示正常但后端检索没触发的情况，原因是配置文件里知识库开关没打开。这种问题看日志最快，别在前端瞎猜。
4. 让辅导老师真正“个性化”的配置技巧
4.1 学科提示词模板的定制方法
DeepTutor 默认的提示词是通用型的，你要让它变成“数学老师”或者“物理老师”，得自己改提示词模板。这个在config/prompts/目录下，每个学科一个文件。
一个好的学科提示词应该包含这几层：
角色设定：明确告诉模型它是哪个学科的老师，教学风格是什么。比如“你是一位耐心的高中数学老师，擅长用生活例子解释抽象概念”。
回答结构：规定它先分析题目考点，再给解题步骤，最后总结易错点。这样输出更稳定，不会东一句西一句。
边界约束：明确告诉它什么不该做。比如“如果学生问的问题超出当前章节范围，引导他先掌握当前知识点”。
我改过一版物理的提示词，加了“每次解题前先画出受力分析或电路简图”的要求，学生反馈说比之前清楚多了。这种细节就是个性化的价值所在。
4.2 学习进度追踪的数据结构
DeepTutor 会记录每个学生的对话历史和答题情况，这些数据存在数据库里。你要做个性化辅导，就得会看这些数据。
核心表大概有这几张：学生表、对话记录表、知识点掌握度表。知识点掌握度是根据答题正确率和提问频率动态计算的。你可以定期导出这些数据，看看哪个学生在哪个知识点上卡住了。
我自己的做法是每周跑一次统计脚本，把掌握度低于阈值的学生和知识点列出来，然后针对性地调整知识库或提示词。这个动作看起来简单，但坚持做下来，辅导效果提升很明显。
4.3 多学生场景下的隔离与并发
如果你要同时辅导多个学生，隔离很重要。DeepTutor 支持按学生ID隔离对话上下文，但知识库是共享的。这意味着你可以建一个公共知识库，再给每个学生建私有知识库放他的错题本。
并发方面，如果用本地模型，要注意显存占用。同时来三个学生提问，显存可能就爆了。解决方案要么是排队处理，要么是限制并发数。云端接口一般没这个问题，但要注意接口的速率限制。
注意：多学生场景下，日志要按学生分开记录，否则出了问题根本查不到是谁的请求导致的。
5. 实测中遇到的典型问题与排查思路
5.1 检索结果不相关：从分块到嵌入模型的排查链
这是最常见的问题：学生问了一个问题，AI 回答得驴唇不对马嘴。排查要按顺序来。
先看检索返回的文档块内容。如果返回的块本身就不相关，那问题在检索层。可能原因有：分块太大导致语义模糊、嵌入模型不适合中文、知识库里根本没有相关内容。
如果返回的块相关但回答不相关，那问题在生成层。可能是提示词没写好，或者模型能力不够。
我遇到过一次，检索返回的块是对的，但模型硬是忽略了检索内容自己编。后来发现是提示词里没强调“必须基于提供的参考资料回答”。加上这句之后就正常了。
5.2 响应速度慢的几种成因与优化
慢的原因可能出在三个环节：检索慢、推理慢、网络慢。
检索慢通常是向量库索引没建好，或者数据量太大没做分区。建好索引、按科目分区能明显改善。
推理慢如果是本地模型，看显存是否吃满、是否用了量化。量化能大幅降低显存占用，但会损失一点精度，这个取舍要看你的场景。
网络慢就是云端接口的问题了，换个时间段或者换个接口试试。
5.3 对话上下文丢失的修复过程
有学生反馈聊到一半，AI 突然忘了前面说过什么。这是上下文管理的问题。
DeepTutor 默认会保留一定轮数的对话历史，超出部分会被截断。如果你需要更长的记忆，要么调大保留轮数（但会消耗更多 token），要么把重要信息存到外部记忆里。
我的做法是在提示词里加一条：如果学生提到之前讨论过的内容，先从对话历史里找，找不到就明确告诉学生“我这边没有之前的记录，你能再说明一下吗”。这样至少不会瞎编。
5.4 模型胡编知识点的抑制手段
大模型胡编是个老问题。除了提示词约束，还有几个实用手段：
降低温度参数：温度越低，输出越保守，胡编概率越小。辅导场景建议设 0.3 以下。
检索增强：强制模型基于检索到的内容回答，检索不到就说不知道。
后置校验：对关键知识点，可以用规则或另一个模型做校验。这个成本高，但重要场景值得做。
我试过把温度从 0.7 降到 0.2，胡编明显减少，但回答变得有点死板。后来折中到 0.4，配合强约束提示词，效果比较平衡。
6. 上线之后还能怎么折腾
部署跑通只是起点。我后来做了几件事，让这个辅导老师越来越顺手。
一是定期更新知识库。教材改版、考试大纲调整，知识库要跟着变。我设了个每月提醒，检查有没有新资料要导入。
二是收集学生反馈优化提示词。学生说“这个解释听不懂”，我就去看对话记录，找到具体是哪类问题没讲清楚，然后改提示词。迭代几轮之后，回答质量提升很明显。
三是做数据备份。对话记录和知识库都是心血，我配了个定时任务每天备份数据库和文档目录。这个习惯帮我躲过一次硬盘故障。
四是探索多模型路由。不同学科用不同模型，数学用推理强的，语文用文笔好的。DeepTutor 的配置支持这个，虽然配置起来麻烦点，但效果确实有提升。
如果你也想搭一个，我的建议是先用最小配置跑通，确认核心流程没问题，再逐步加知识库、调提示词、优化性能。一上来就追求完美配置，很容易在某个环节卡住然后放弃。先把东西跑起来，用起来，再慢慢打磨，这才是最实际的路径。
