做 TMUA 题库，先管好数据，再做网页

做 TMUA 题库，先管好数据，再做网页

我以前也会把“做题库”想成做一个网页：学生打开页面，选年份，选 Paper，点选项，系统告诉他对错。

真把 2016 到 2023 年的 TMUA 真题放进去以后，我才发现，网页只是最后露出来的那一层。

简单说，前端就是学生在浏览器里看见和点到的东西，比如题目页面、筛选按钮、提交答案、错题重刷。后端是网站背后替你记东西、算东西的部分，比如保存学生作答记录、统计某一类题的正确率、管理账号和权限。很多网站还会有数据库，专门存题目、用户和成绩。

如果只是让学生打开网页做题，前端就能做很多事。要是希望学生换电脑以后还保留错题，或者老师登录后看到全班数据，那通常就要用到后端和数据库。

我这次做的 TMUA 练习系统主要是把题目做成可在网页里使用的数据，再配一个前端页面让学生练习。做完以后我越来越确定一件事：题库建设的麻烦，首先不在前端，也不在后端，而在数据。

所谓数据，不只是题干和答案。每道题要有稳定 ID，要有清楚的解析，要能按年份、Paper 和知识点筛选，要能和讲义对应起来。学生做完以后，系统最好能告诉他弱在哪里。老师看到一张统计表，也要能相信里面的题目、答案、图片和公式没有乱。

这里说的“数据治理”，不是一个很玄的管理词。放在题库里，它就是几件笨但要命的事：题目怎么编号，字段怎么统一，分类按什么标准来，解析写到什么程度，图片和公式怎么检查，改错以后怎么留下记录。

这次题库覆盖 2016-2023 年，每年 Paper 1 和 Paper 2，每张卷 20 题，一共 320 道。学生可以按年份和 Paper 练习，也可以随机练习、模拟考试、错题重刷；老师可以看成绩和知识点诊断；题目还会连到对应的讲义模块。

放在以前，我大概率不会做。不是不会想，是做不完。

现在有 AI Agent，很多脏活可以交出去。老师不必亲手处理每个技术细节，但要先把标准定清楚。标准不清楚，AI 做得越快，后面越难收拾。

先别急着做页面

很多老师手里都有题目。PDF、Word、截图、课堂讲义、往年试卷，散在各个文件夹里。真要找一道题的时候，也能找到。

但这不等于有题库。

题库也不是“做一个漂亮页面”就能解决的事。页面可以先简陋一点，只要题目能准确显示、学生能顺利提交，早期已经够用。底层数据不能糊弄。

一个对教学有用的题库，至少要回答几个问题：

学生现在应该练哪一类题？

做错以后，下一步该补哪块内容？

老师怎么知道这一班学生是代数弱，还是逻辑弱，还是图像题弱？

一份讲义讲完以后，有没有对应的题可以立刻练？

如果题库回答不了这些问题，它只是一个比较整齐的文件夹。

所以我做 TMUA 题库时，我先问的是：每道题应该带哪些信息？技术上常说“字段”，你可以先把它理解成 Excel 表里的每一列。最后每道题大致长这样：

{
  id: "2016-P1-Q1",
  year: 2016,
  paper: 1,
  num: 1,
  topic: "Algebra",
  question: "...",
  options: { A: "...", B: "..." },
  answer: "H",
  analysis: "...",
  modules: ["a1_algebra_basics"],
  sections: ["a1.expansion_collection"],
  skills: ["coefficient-comparison"]
}

这串东西看起来像技术细节，其实背后是教学判断。前端能不能筛选、统计、推荐，基本都取决于这些字段有没有提前想好。

id 是这道题的身份证号。year、paper、num 解决的是定位问题。学生说“2021 Paper 2 第 17 题看不懂”，老师能马上找到。

topic 解决的是大类诊断。学生到底是函数弱，还是概率弱。

modules 解决的是讲义关联。讲完某一份讲义后，可以直接知道哪些真题能接上。

skills 更细一点，记录学生实际用到的动作，比如因式分解、构造反例、图像交点、分类讨论。

老师不需要一开始就记住这些字段名，但要记住一个问题：这道题为什么值得练？前端只是在调用这些答案，不能替老师做判断。

AI 适合做脏活，但别让它定标准

如果没有 AI，这个项目最痛苦的地方会是机械劳动。

从 PDF 里抽出题干和选项，整理公式，补答案，写中文解析，处理图片，给题目打标签，再塞进网页数据文件。320 道题，重复做下来很容易崩。

这类事情现在可以交给 Agent 做一大部分。

• 把题目整理成统一格式
• 根据官方答案或已有解析写出中文步骤
• 判断一道题主要考代数、函数、图像还是逻辑
• 给题目建议对应的讲义模块
• 检查答案是不是存在于选项里
• 发现图片路径缺失、公式格式异常、题目 ID 不一致
• 一题一题打开网页，检查题目是否真的显示出来

这已经不只是“帮我打字”了。AI 可以参与数据整理：把原始 PDF 变成结构化题目，把松散解析放进统一字段，把人工很难全面检查的错误先筛出来。

尤其是审核阶段，AI 很适合做第一轮筛查。比如一张 Paper 有 20 道题，可以让 20 个子任务分别检查：题干有没有残缺，选项有没有漏，解析最后答案是否一致，图片有没有加载，标签是否合理。每个子任务只负责一道题，边界很清楚，出错也容易定位。

但这不代表老师可以退出。

AI 可以做判断，但它的判断需要标准。没有标准，它会把分类做得很满，把解析写得很长，最后不一定服务教学。

第一件事：分类标准

题库里最容易被低估的是分类。

一道题到底属于 Algebra、Functions、Graphs，还是 Logic？很多时候没有唯一答案。比如一道题表面在解方程，实际要看图像交点；另一道题用了代数化简，考的却是必要条件和充分条件。

AI 可以给建议，但老师要决定这个分类服务什么。

如果题库只是为了搜索，那标签越多越好。

如果题库是为了复习诊断，主标签就不能太随意。

如果题库要和讲义连接，modules 就必须和讲义结构保持一致。

我后来把分类分成几层。

第一层是学生和老师都能看懂的大类，比如 Algebra、Functions、Graphs、Probability。

第二层是讲义模块，比如 a1_algebra_basics、c_sequences_series、i_functions_graphs。这层要认真做，因为它决定题库能不能反过来支持课程。

第三层是更细的技能，比如 coefficient-comparison、case-analysis、counterexample-construction。这层不一定一开始就完美，可以在审核题目的过程中慢慢长出来。

老师要做的，就是防止分类变成装饰。

每加一个标签，都要问：学生或老师以后会用它做什么？如果没人会用，那它只是好看的元数据。

第二件事：解析写给谁看

AI 很会写解析。甚至有时候太会写。

它会把一道两分钟能做完的选择题，写成五六步，语气很完整，逻辑也很顺。问题是，学生未必需要这么长。

TMUA 的解析不能只追求“完整”。它要服务考试训练。

有些题需要详细拆步骤，因为学生容易卡在第一步。

有些题需要给快捷思路，因为考试时间很紧。

有些题需要指出陷阱，比如选项里哪个答案是常见误算。

有些题不需要长篇解释，写太多反而把要点淹没了。

所以我更愿意把解析分成几个功能：

题目分析：这题到底在考什么。

解题步骤：正常路径怎么走。

快捷思路：考试里有没有更快的判断。

正确答案：最后明确落到哪个选项。

这些栏目 AI 可以生成，但风格要由老师定。解析不是写给 AI 自己看的，是写给下一次还要独立做题的学生看的。

第三件事：题库要和讲义互相支撑

如果题库和讲义分开，它们很快会变成两套系统。

讲义里写“课后练习见题库”，但学生不知道练哪几题。题库里有很多标签，但老师备课时想不起它们对应哪一节课。

我比较在意的是两边互相连起来。

讲义按 TMUA 知识点分成 15 个模块。题库里的每道题，也尽量标出它属于哪些模块。这样讲完指数对数、数列、函数图像、逻辑反例之后，都能找到对应真题。

反过来，题库也会暴露讲义的问题。

如果某类题反复出现，但讲义里没有合适位置，那可能说明讲义需要补一节。

如果很多题都被迫塞进 Algebra，说明 Algebra 这个大类太粗，需要更细的 section。

如果某个技能标签频繁出现，比如分类讨论或构造反例，那它可能值得单独训练。

到这一步，题库就不只是讲义后面的练习链接了。它会反过来提醒我：课程里哪块讲薄了，哪类题没有安放好，哪些技能其实需要单独练。

第四件事：质量底线

技术上，很多错误都可以让 AI 或脚本发现。

比如 ID 重复，答案不在选项里，图片路径不存在，题目缺字段，LaTeX 没渲染，深链打不开。这些应该尽量自动化检查。

但有些质量问题还是要老师判断。

解析有没有绕开关键步骤？

这道题的分类会不会误导学生？

图片虽然显示出来了，但是不是裁掉了重要信息？

解析里的“快捷思路”是否真的适合考试？

一道题放在某个讲义模块下，会不会让学生以为它只考这一个知识点？

这些不是纯技术问题。

我现在更愿意把审核分成两层。第一层交给 Agent 和脚本，查格式、链接、图片、答案一致性。第二层由老师抽查或重点复核，查教学意义。

不需要每个环节都人工从头做，但必须有人对质量负责。

我实际怎么做

我最后基本按这个顺序做。

先让 AI 出一版用途方案。可以直接告诉它：我想做一个给学生练 TMUA 的题库，学生要能按年份、Paper 和知识点练，老师希望看到诊断，题目最好能连到讲义。让它先列功能、数据字段和可能的坑。

老师要做的是审核。哪些功能真的会用？哪些统计只是好看？哪些分类能帮助备课？这些问题不能让 AI 替你拍板。

数据结构也可以先让 AI 起草。它会很快列出 ID、年份、Paper、题号、题干、选项、答案、解析、图片信息和分类标签。老师再看这套字段够不够教学用，哪些字段以后会拖累维护。

接着让 Agent 做初步整理。PDF 解析、题目抽取、公式处理、中文解析、初步分类，这些都适合 AI 批量处理。

再一张卷一张卷审核。每次只处理一张 Paper，每道题单独检查，不混在一起大改。这个阶段主要看数据能不能信：ID 有没有乱，答案有没有对上，图片有没有缺，分类是不是说得过去，解析是不是学生能读懂。

这些稳定以后，再把题目放进前端练习系统。学生端负责练习、筛选、模拟考试、错题重做；教师端负责看提交成绩和薄弱点。前端放在这个位置会舒服很多，因为它是在使用已经整理好的数据，不是在一边补数据一边猜需求。

最后做发布前验证。题目数据要能通过静态检查，网页要能打开，公式和图片要能渲染，深链要能直达具体题目。

这里面很多工作都可以由 AI 参与。老师要把握的是顺序：先让 AI 出方案，再审核方案；先整理数据，再做页面。顺序反了，后面会一直返工。

写给想试的老师

这次做完之后，我对 AI 的看法更具体了一点。

一个能用的题库，过去可能需要录入人员、教研人员、前端开发、后端开发和测试人员。现在一个老师借助 Agent，也可以先做出可用版本。

但老师不能把判断一起外包出去。

老师不一定要亲手写每一行代码，不一定要手动检查每个图片路径，也不一定要逐字录入每道题。AI 可以做这些事。老师要先说清楚什么叫“好题库”：

题目是不是忠实？

解析是不是对学生有帮助？

分类是不是服务复习？

讲义和题库是不是能互相支撑？

公开使用时有没有版权和数据边界？

学生做完以后，下一步能不能更清楚？

如果这些问题没有想清楚，AI 做得越快，系统可能越乱。

如果这些问题想清楚了，AI 的速度才有用。它能把很多原来做不完的工作往前推。

所以我现在看这个 TMUA 题库，最在意的已经不是“我有 320 道题”。

这些题终于不只散落在 PDF 里。它们能进入练习，进入讲义，进入诊断，也进入下一次备课。

这才是题库开始有用的时候。

附录：实现时用到的工具

这部分不是教程，只是把我实际用到的工具说清楚。老师如果想复现，不需要一开始就完全照搬，但要知道每类工具在流程里负责什么。

Agent 工具

我主要用的是 OpenClaw 和 Codex。同类工具还可以包括 Trae SOLO 和 WorkBuddy。

这些工具在这个项目里的作用差不多：进入本地文件夹或代码仓库，读取文件，批量修改文件，生成前端页面，运行构建，再把结果交给你检查。

比如让 Agent 只处理一张 Paper，把题目补成统一格式；或者让它检查 questions_data.js 里某一道题的 ID、答案、图片路径和 LaTeX；也可以让它改前端页面，跑一次构建，看题目能不能正常显示。

我的经验是：不要让 Agent 自由发挥太多。最好给它一个很窄的任务，比如“只检查 2019-P1-Q03 这一题的数据和渲染问题”，或者“只把这一张 Paper 的题目补上 modules、sections、skills”。任务越窄，越容易验收。

解析工具

PDF 解析主要用 LlamaParse。

真题 PDF 里最麻烦的是公式、选项、图形和分页。普通 OCR 很容易把选项粘到题干里，或者把页码、页眉、版权信息混进题目。LlamaParse 可以做第一轮结构化提取，至少把题目、公式和部分版面关系拆出来。

但解析工具只能解决“从 PDF 里拿出来”的问题，不能保证拿出来的内容一定适合进题库。后面仍然要让 Agent 检查：题干有没有残缺，选项是否连续，图片是不是对应这一题，公式是否能在网页里渲染。

版本管理

版本管理用 GitHub。

题库这种项目一定要有版本管理。原因很简单：你会反复改题、改解析、改标签、改前端。如果没有 Git，很快就不知道哪一次修改引入了错误。

我会尽量让每次提交只解决一类问题。比如一次只修某一张 Paper 的 20 道题，一次只改图片路径，一次只调整标签体系。这样出了问题还能回头查。

GitHub 还有一个好处：它让 Agent 的工作有边界。Agent 改完以后，不能只说“我完成了”，还要看具体 diff，看它到底改了哪些文件。

AI API

模型 API 主要用 小米 MiMo API 和 OpenAI API / GPT。

我在这里更看重多模态能力。TMUA 题目里有图像、坐标轴、几何图和排版细节，模型如果能读图，检查图片和题干是否对应时会方便很多。

• 生成初稿：把题目解析先写成中文步骤。
• 读图核对：检查题干和图片是否对应。
• 检查逻辑：判断解析有没有跳步。
• 辅助分类：根据题目判断 topic、module、skill。

如果用 Codex、Trae SOLO 或 WorkBuddy 这类工具，很多时候它们已经内置模型，不需要老师单独绑定 API。OpenClaw 这类工作流可能会需要自己配置模型。这里不用把事情想复杂：有一个能稳定处理文字和图片的模型就够用，重点仍然是任务拆得够不够清楚。

成绩收集工具

模拟测试做完以后，我用了 QuickForm 收集学生提交的成绩。

这个用途很简单：学生做完一套模拟测试后，提交姓名、班级、年份、Paper、分数和用时。老师不用在聊天记录里翻成绩，也不用临时建一个乱七八糟的表格。后面要看某一套卷的整体表现，直接从表单结果里看就行。

完整流程图

我的工具分工

简单整理成一张表：

环节	主要工具	老师要把握什么
PDF 初步解析	LlamaParse	题干、选项、公式和图片是否忠实
初稿整理	Agent + MiMo / GPT	字段是否完整，解析是否像给学生看的
逐题修订	Agent	每个 Agent 只改自己负责的题
标签分类	Agent + MiMo / GPT	分类是否服务讲义和复习，而不是只求好看
前端实现	Agent	学生练习路径是否顺，页面是否能真的用
版本管理	GitHub	每次提交范围是否清楚，能不能回滚
发布前检查	Agent + 本地脚本 + 浏览器	构建、链接、公式、图片和深链是否正常
模拟成绩收集	QuickForm	是否能对应学生、年份、Paper、分数和用时

工具不是越多越好。先把环节拆清楚，再决定哪一步交给谁。

解析工具把原始材料拆出来。Agent 去改文件、跑构建、做批量检查。MiMo 或 GPT 用在读图和生成解析上。GitHub 留下修改记录。QuickForm 收模拟测试成绩。老师看标准有没有跑偏。

我现在做类似项目时，会先问这件事可以拆成哪些环节，每个环节的错误会造成什么后果。想清楚这些，再决定交给哪个工具。