在数学辅导工具这个方向上我一直有个执念大多数学生缺的不是更多题而是“卡住那一刻”能有人帮他看清楚思路错在哪。大模型出现之后AI辅助数学学习的门槛一下子降了下来你可以用LLM做解题、出题、讲步骤、批改过程甚至做自适应练习。这篇文章是我从零开始搭这样一个工具的完整记录包含需求拆解、架构选型、提示词工程、实测踩坑和后续规划给同样想做AI教育产品的朋友一个可直接落地的参考。1. 项目概述与需求拆解1.1 核心需求解析AI究竟能帮数学学习解决什么问题我最初的想法很简单做一个AI数学学习工具让它像家教一样陪着学生做练习。但真动笔设计需求时才发现“像家教”这三个字背后藏着很多具体能力要求。学生数学学习最常见的痛苦点有三个不会做、做错了不知道为什么、会一道但不会举一反三。AI能切入的环节分别对应解题引导、错因分析和变式练习。这里需要区分一个关键点AI辅助数学学习不等于AI直接给答案。如果产品只是把题目丢给大模型然后输出一顿推导过程和最终答案这对学习几乎没有价值反而容易变成抄答案工具。真正有价值的场景是分步引导比如学生卡在第二步时AI只提示这一步需要的定理或思路而不是直接把整个解答亮出来。所以我给自己定了几条产品原则第一AI必须能识别题目类型和难度第二AI要能控制信息释放的粒度先给提示再给详解第三AI要支持解析学生的输入过程而不只是输出第四题目需要有数据支撑来源要可控不能靠模型瞎编。这几条原则直接决定了后面的架构设计和技术选型。1.2 目标用户与场景定位不是做一个“万能答题机”我把目标用户定为初中到高中阶段的学生场景限定在课后练习和考前复习。这个定位避开了几个难啃的骨头一是小学低年级的学生还需要大量图文交互声学、手写识别这些成本很高二是大学高等数学涉及复杂的公式渲染和证明过程通用模型很容易出错需要额外校验三是竞赛数学需要极强的逻辑链和创造性当前大模型的表现还不稳定。初中到高中数学的好处是知识点边界相对清晰题型也有很大规律性。函数、几何、数列、概率这些模块模型只要配合好的提示词和题库数据准确率可以做到很可观。我还加了一个“只看思路”模式让AI分步骤给提示学生可以随时喊停自己继续往下写。这是市面上很多解题类App没做好的体验点。1.3 项目目标与功能范围最小可行产品包含哪些模块我给自己定的MVP目标是一个能运行在网页端的工具支持拍题或输入题目文本AI先做题目分类和难度评估然后提供三层递进的帮助提示、分步解析、完整答案。同时记录学生的作答过程形成简单的错题本。功能范围圈定为五个模块题目录入与标准化、题目分析与标签化、分步提示引擎、答案校验、学习记录储。题目录入需要支持纯文本、公式文本LaTeX和图片录入题目分析要做知识点识别和难度评估分步提示引擎是我重点设计的后面会详细讲答案校验这一块容易被忽视但恰恰是AI数学工具能不能用的关键学习记录则服务于后续的错题回顾和薄弱点反馈。2. 技术选型与架构设计2.1 模型选型当前主流大模型在数学推理上的表现对比做AI数学工具的第一道选择题就是用哪个模型做底座。我实测过几类方案通用对话模型、数学增强模型、外部计算工具LLM组合。通用对话模型比如GPT-4o、Claude系列对常见初中数学题能做对大部分但有个致命问题——它们经常自信地给出错误答案尤其在多步不等式和几何证明里。数学增强模型如GPT-4o的数学模式、Mathstral在数理逻辑上更严谨但部署成本更高。外部工具LLM的方案比如LLM调用SymPy做符号计算准确率最高但工程复杂度也最高。最终我的选型结论是核心解答路径采用“通用LLM Python计算后端”的混合架构。LLM负责读题、拆解题意、生成解题框架和讲解文案SymPy负责所有符号运算和数值计算。这样做的好处是把最容易出错的算术部分从模型身上剥离出来。2.2 整体架构LLM、计算引擎、题库三者如何协作我的整体架构分三层。最上层是交互层负责学生输入题目、选择求助层级、展示分步解析中间是逻辑层包含意图识别模块、题目标准化模块、提示词引擎和答案校验模块最底层是能力层包含大模型API、SymPy计算引擎、题库数据库和学生行为数据库。这个架构最核心的设计思路是“分工”二字。大模型不是万能的尤其是在执行精确计算时它的优势在于理解和生成自然语言。所以我让大模型做三件事读懂题目、拆解思路、组织讲解语言。而SymPy做的是另一件事确保每一个数值结果和代数变换都是精确的。两者通过一个数据协议衔接大模型输出解题框架框架里的每个计算步骤交给SymPy核实最后再由大模型把核实后的步骤包装成学生能听懂的语言。2.3 关键组件选型从OCR到公式渲染的完整技术栈具体组件上我做了这么一套选型前端框架用Next.js兼顾SSR和部署便利公式展示用KaTeX渲染速度快且支持LaTeX语法。后端用Python FastAPI因为要直接调SymPyPython生态最顺。OCR模块用PaddleOCR加公式识别后处理拍题场景下先识别文本和公式再转成LaTeX。数据库用SQLite起步存题目、学生行为日志、错题本后面数据量大了再迁PostgreSQL。大模型API先用兼容OpenAI格式的接口方便换不同模型做评测。这个选型不追求新潮追求的是每个环节都能被自己精确控制。比如KaTeX的渲染质量直接决定了学生看“分步解析”时的体验公式布局错乱会让人瞬间失去耐心。OCR这一块我踩过不少坑后面在实操章节细说。3. 核心功能设计与实现细节3.1 题目标准化与知识点识别让AI“读得懂”数学题数学题进入系统后第一件事不是解答而是标准化。所谓标准化就是把题目拆成结构化字段。比如题干文本、求值目标、已知条件、题型类别、知识点标签、难度系数。这些字段存进数据库后系统才能对题目做后续的检索、归类和变式生成。知识点识别我用了一个比较稳的方案预设知识图谱覆盖初中到高中数学主要考点然后让大模型根据题目内容做多标签分类。比如一道二次函数题模型要输出三个标签函数、二次函数、最值问题。这个标签体系的好处是后续推荐题目时能做到精准匹配错题本也能按知识点维度做聚合分析。难度系数我采用了两级校准机制第一级是模型根据题目结构和常见解法长度给出预估难度取值范围1到5第二级是根据真实用户在一次作答中的正确率动态修正。比如一道题被100个学生试做正确率如果只有30%难度就会从模型预估的3升到4。3.2 分步提示引擎AI数学辅导的核心机制分步提示引擎是整个工具的重头戏也是我和很多做AI解题的朋友反复讨论后打磨出来的机制。它模仿的是真人辅导老师的做法不一次性把答案喂给学生而是像剥洋葱一样逐层给出提示。引擎内部维护了一个“步骤序列”每一次生成解题思路时大模型不仅输出最终答案还会额外输出一组规划好的思维步骤。每个步骤包含三部分StepHint这一步的引导性提示不直接给关键算式、StepDetail这一步的完整推演、以及StepDeps这一步依赖的步骤索引。学生默认只会看到StepHint只有当点击“继续”或“我卡住了”时才会看到下一步的提示。想看完整解答也可以直接切换到StepDetail模式。这里我比较担心的是步骤抽象怎么控制粒度。太粗学生还是看不懂太细学生容易不动脑子照抄。我的调法是参考“认知负荷理论”每一步只引入一个新的推理要素比如第一步是“识别题型”第二步是“写出相关公式”第三步才进入算式操作。3.3 答案校验与计算引擎如何让AI不再“一本正经地胡说八道”学生作答后系统需要判断答案对不对。这个环节如果只依赖大模型判断你会死得很难看。我试过让GPT-4o判断一个分式化简对不对它多次把错误答案判为正确原因在于模型读步骤时被看起来很流畅的表达迷惑了。所以这一模块必须交给计算引擎。我的做法是把所有涉及数值计算、代数化简、方程求解、不等式判定的判断都下沉到SymPy执行。前端学传入一段LaTeX表达式或方程后端把它解析成SymPy对象和参考答案做符号等价性比对。比如参考答案是(x2)^2学生写的答案是x^24x4SymPy可以通过sympy.expand或simplify判断两者相等。这一步极大提升了答案校验的准确率。对于几何题我还接了一个小分支支持线段坐标验证。学生填两个线段相等时系统提取坐标用距离公式校验是否相等。这个看似简单的功能目前在通用模型上直接判断的准确率只有70%左右加上坐标计算后可以稳定到96%以上。3.4 学习记录与错题本让工具越用越“懂”学生学习记录这一块我的设计目标不是做复杂的自适应学习系统而是先把基础数据积累起来。每一次学生提问、每一次求助、每一次作答正确与否、用时多少都被记录下来。这些数据会聚合成两个维度知识点掌握度和解题行为特征。知识点掌握度就是每个标签下的正确率和平均用时用来在复习时推荐薄弱知识点的变式题。解题行为特征则更细一些比如学生更喜欢用提示模式还是直接看详解遇到多步计算是否容易在中途出错。这些特征目前还没有上算法模型但我用规则做了一些分组比如某学生在“二次函数最值”标签下的正确率低于50%系统就会在错题本首页高亮这个知识点并推荐三道同类型基础题。4. 实操过程与核心环节复盘4.1 环境搭建与数据准备从零搭建项目的完整步骤这一部分我把自己的实操过程写细一点方便你照着复现。第一步是初始化项目结构。我创建了一个根目录叫ai-math-tutor内部按前后端分成web/和server/两个子目录。web用的是Next.js 14执行npx create-next-applatest web --typescriptserver用的是FastAPI直接python -m venv venv建虚拟环境然后装依赖。依赖清单我列几个关键的fastapi、uvicorn、sympy、paddleocr、paddlepaddle、openai、sqlite3、python-dotenv。大模型调用我用的是openai库因为它的客户端支持绝大多数兼容OpenAI协议的API服务换厂商只需要改base_url和api_key。日志模块我习惯用loguru排查问题时比自带的logging直观很多。第二步是准备题库种子数据。我从历年真题里摘出100道初中数学题分代数、几何、概率统计三类每题都通过程序化的方式把题目转换成JSON格式。格式内部包含题干、答案、详细解析、知识点标签、难度预估。这些种子数据的意义不只是用来只读查询更重要的是用作提示词的Few-shot示例。给模型看五道高质量的代表题它能更好理解你的输出格式要求。4.2 提示词工程写给大模型的“教学指令”设计提示词工程是这类工具的重头戏我前后迭代了差不多半个月。这一部分我从两个方向去调一是结构化的输出格式二是教学话术的约束。结构化输出的目的是让大模型稳定返回JSON格式的结果。我定义了一套专门的Schema核心字段包括problem_type题型、tags知识点标签、difficulty难度1-5、steps步骤列表、answer最终答案、thought给学生看的思路解析。为了确保不出现乱格式我在提示词里明确给出一个示例返回片段并强调“只输出JSON不要其他文字”。这一步在调优时能帮你省很多解析报错的烦心事。教学话术的约束更重要。我试过让模型自由发挥结果它经常写出“我们可以通过观察发现”这类空话或者直接甩出一个超出年级范围的方法。后来我在提示词里加了几条硬性约束第一每一步的提示必须指引学生自己推导不能只给结论第二全篇不得出现“显然”“易得”这类模糊词第三遇到需要计算的地方必须标注为“调用计算引擎”由后端执行模型不直接给出未经验证的算式。这些约束让输出质量有了质的提升。4.3 实际开发中的代码片段与效果验证我贴两段关键的代码都是我自己跑通的如果你照着做会少走很多弯路。第一段是大模型的JSON输出解析与校验。大模型偶尔会返回冗余文字或者JSON格式不规范所以我在解析之前加了清洗逻辑。用正则提取最外层的JSON对象然后交给json.loads如果失败就再做一次二次补全。这个处理在真实轮CPU中很常见不做清洗的话线上会频繁触发异常。import json import re def parse_llm_json_response(text): text text.strip() # 去除可能的markdown代码块包裹 if text.startswith(): text re.sub(r^(?:json)?|$, , text, flagsre.MULTILINE) # 提取最外层JSON对象 match re.search(r\{.*\}, text, re.DOTALL) if not match: raise ValueError(No JSON object found in response) obj_str match.group(0) try: return json.loads(obj_str) except json.JSONDecodeError: # 常见问题单双引号混用、末尾多逗号 # 这里做一层粗糙修复更多情况建议直接请求模型重新输出 obj_str re.sub(r,\s*([}\]]), r\1, obj_str) return json.loads(obj_str)第二段是SymPy的答案校验。这里的关键是符号等价判断不是字符串相等。我封装了一个validate_solution函数把所有需要校验的表达式统一转成SymPy对象再比较。import sympy as sp def validate_solution(user_answer_str, reference_answer_str): x sp.Symbol(x) try: user_expr sp.sympify(user_answer_str) ref_expr sp.sympify(reference_answer_str) simplified_diff sp.simplify(user_expr - ref_expr) if simplified_diff 0: return True, 答案正确 else: return False, f答案有误化简差值为 {simplified_diff} except Exception as e: return False, f表达式解析失败{e}实测下来加入SymPy校验之后判断题的准确率从直接让LLM判断的70%左右提升到了95%以上。剩下的5%错误主要来自几何辅助线的验证那部分需要额外的规则补充。4.4 题目变式与扩展如何让AI生成“不超纲”的同类型题错题本要有价值光收藏原题不够还得能生成同知识点的变式题。变式生成我试过两种思路直接让大模型改题和模板替换改题。直接让大模型改题的优点是快缺点是容易改超纲。比如一道三元一次方程组的题目模型可能改成需要用到矩阵变换的解法这明显超出初中范围。模板替换改题则稳定得多。我预先为人教版教材的常考题型建了一批模板模板是带占位符的题干比如“已知抛物线$ya{x^2}bxc$经过点$A({m},0)$、$B({n},0)$求顶点坐标”然后让模型负责填充占位符的具体数值并校验填充后的题干逻辑自洽。数值填充不是随机数要注意题目条件和计算量的平衡。数字太大会导致学生算到崩溃数字太特殊如0、1过多又会失去练习价值。我给每个模板配置了数值范围约束比如一次函数题中斜率取值在1到5之间常数项在-10到10之间。通过这种方式模型生成的变式题既多样又不超纲。5. 常见问题排查与避坑指南5.1 模型输出格式不稳定的问题大模型返回的JSON时好时坏是我开发中遇到的头号问题。有时数组里混入了null有时多了一个空行有时把“false”写成了“False”。这些问题在初期几乎每天都要处理。我的解决方案有三层。第一层是在提示词中提供强约束的示例不给模型即兴发挥的空间第二层是后端做宽容解析上文那种正则提取加json.loads的兜底逻辑能用第三层是重试机制如果解析失败超过两次就直接把原样返回的文本交给人工审核。实测三层叠加后格式错误率从12%降到1%以内。5.2 SymPy计算与数学规则冲突的排查SymPy不是万能的有几个地方需要特别注意。第一个是矩阵运算目前SymPy对矩阵特征值特征向量计算很强大但涉及到几何变换矩阵的左乘右乘顺序容易搞混第二个是条件约束比如判断一个不等式解集时SymPy只给纯数学解不考虑题目中“整数解”这类学科限制第三个是符号变量定义冲突。我在一次函数题目里用了b作为常数项同时题目又出现了另一个常量b导致求导时变量混淆。建议你给系统加上一个“计算前置规则层”。在调用SymPy前先根据题目解析结果把需要约束的条件转换成代码。比如题里明确了“求整数解”就在求解后加一个筛选整数解的步骤。这层规则目前没法完全自动化需要人工维护一个条件规则库。5.3 OCR识别公式错乱与预处理拍题场景的OCR效果直接影响产品体验。我实测PaddleOCR对纯文本的识别准确率很高但公式部分经常出问题尤其是分数和上下标错一个字符整个式子意思就变了。我的处理流程是先用OCR引擎识别完整图片然后把文本和公式区域分离。纯文本部分走通用OCR公式区域走专用OCR模型再进行一次“公式纠错”用LaTeX语法解析器检查识别结果如果存在括号不匹配或缺运算符就尝试修正。修正不了的直接提示用户重新拍题或手动输入。这个流程虽然牺牲了一点自动化程度但能保证进入系统的题目绝大部分是准确的。另外还有一个很实用的细节拍照时提醒用户把题目拍正避免手部阴影和倾斜。前期我在产品里加了实时预览框如果检测到图片倾斜角度大于15度就提示重拍这比后台做图像矫正省心很多。5.4 学生依赖答案而不思考的问题做这类工具不可避免会面临一个质疑学生会不会只是拿AI来抄答案。我自己的应对思路是产品机制和话术设计两手抓。机制上我默认把“分步提示模式”设为学生的第一接触方式完整答案要连续点击多次才能看到并且每一步增加5秒阅读确认时间。话术上提示词里我要求模型在给出完整答案时插入一句自我反思引导比如“请复核这一步中系数变化是否正确”。这些细节不能完全杜绝抄答案但能增加无意识抄答案的成本让真正想学习的学生更容易走完思考链路。6. 实测数据与效果评估6.1 不同年级、不同题型的正确率对比为了验证工具的实际效果我用300道人工标注过的题目做了一轮回归测试涵盖初中三个年级的主要知识点。测试内容包括题目分类准确率、解题步骤完整度、最终答案正确率、提示语得当用户留存率。结果显示分类准确率在87%左右答案最终正确率在93%以上。提示语的用户留存率因为还没有正式上线只做了小样本内测数据是69%。不同题型的表现差异很明显。代数和概率统计题正确率明显高于几何题。几何题的问题是辅助线的构造模型经常给出风格奇特的辅助线方案虽然不是完全错误但偏离了常规解法学生看了反而困惑。这一点我暂时处理的办法是引导模型优先使用教材标准解法必要时调用题库中的相似题解法作为参考。6.2 学生端体验反馈与迭代方向小范围内测里我收到了几条很关键的反馈。第一学生希望分步解析中的“知识点提示”能直接跳转到对应的教材章节不想自己再搜第二部分学生反映提示步骤太机械读起来像说明书不像老师在对话第三学生希望支持手写输入而不只是拍照和键盘输入。这几点基本勾勒了我下一阶段的迭代方向一是打通知识点提示和在线教材的绑定关系做一个“知识卡片”浮层二是调整提示词模板让提示更像“老师问了一个问题”而不是“机器给出一个结论”三是接入手写识别引擎把手写公式转换成LaTeX。第三点的工程量比较大我打算先接一个成熟的手写公式识别SDK等用户量上来了再自研。7. 项目后续扩展与我的实在建议7.1 从“解题工具”到“学习伙伴”的进化路径目前这个工具的核心能力是解题辅助但我更想把它做成一个有延续性的学习伙伴。路径上看有三个阶段可以推进。第一是数据积累阶段的“错因聚类”记录每道错题的错误类型比如粗心算错、概念不清、方法不对形成个人错误画像。第二是推荐引擎阶段的“薄弱点定向练习”基于错因画像从题库中选出有针对性的变式题。第三是对话式批改阶段的“过程辅导”学生传上手写的解题过程AI不只是判断对错还要像老师一样在每一步旁批。这三个阶段都不需要推翻现有架构都是在现有“题目标准化、行为记录、答案校验”的基础上做上层扩展。关键是数据协议要在早期设计好题目、步骤、行为日志的字段一定要规范别等到数据多了再重构。7.2 给同类项目开发者的几点实用建议如果你也想做AI数学学习工具我有几条实在建议。第一先想清楚计算引擎怎么接不要指望大模型自己算对数学第二提示词工程投入的精力一定要大于模型选型好的提示词能让中等模型发挥出接近顶尖模型的水平第三题目数据是护城河通用模型API再强没有高质量的题库和知识标签体系做出来的产品也是空中楼阁第四MVP阶段一定要控制范围不要一开始就做太多花哨的自适应功能先把“一道题的完整辅导链路”打磨通。我个人在实际碰壁后的体会是做这类工具最难的不是技术而是教学设计的细节。同一个AI你用“直接给答案”的提示词和“层层引导”的提示词教出来的效果完全不一样。开发者如果自己不懂教学过程做出来的工具就像一本没有重点的习题集。所以做这个项目的过程中我花了很多时间去访谈老师、观察学生卡在哪一步这些收获最后都反馈到了提示词和交互设计里。工具跑通只是第一步真正让它对学生有帮助需要持续的教学向调优。