这个系列的第一篇我不想急着放代码。一个AI辅助数学学习的工具真正的难点从来不在某个单一功能而在于把“看懂题目、定位卡点、启发思考、巩固练习”这条链路完整串起来。过去大半个月我翻了不少市面上的方案也亲手做了几轮技术选型验证踩了一些坑所以才有了这篇规划笔记。这个系列我会用编号01、02、03的方式持续记录从动机到架构从选型到调试尽量把每一步取舍都写清楚。为什么现在想做这件事说来也简单通用对话大模型能解不少数学题拍照答疑产品也流行很多年了但两者之间有一条明显的空档。多数已有方案要么直接给答案要么把AI当成一个精美的搜索引擎而数学学习真正需要的是在学生的思路中断时给出恰到好处的提醒——不替他走完而是陪他走完。这个需求我目前很少看到有产品真正接住。所以我给自己定的目标很明确做一个“不说答案、还能教会你”的AI辅助数学学习工具。它会先判断你的解法卡在哪个环节再一步步给提示如果你确实做不出来才展示完整解析。这篇文章主要回答四个问题为什么选这个方向、范围划到哪、技术路线怎么搭、第一批验证怎么做。1. 为什么是“AI辅助数学学习”三个真实存在的痛点1.1 学生缺的不是答案是“卡在哪一步”的判断先讲一个最常见的场景学生做练习卡住了身边没有老师。他掏出手机拍照几秒钟拿到一个完整答案。看懂了关掉手机下次遇到同类题还是不会。这不是学生笨而是“看懂解析”和“自己会做”在认知难度上差了整整一个量级。传统答疑工具把学习问题简化成了检索问题答案跳过了最关键的过程诊断。比如一道因式分解题学生可能错在符号处理也可能在提取公因式之前就理解错了式子的整体结构。标准答案不会告诉他这些AI辅助数学学习工具的价值就在这里——把“我这题不会”翻译成“你其实已经走到了哪一步、卡在了哪个认知点上”。我试过一个很典型的例子解方程 (2(x-3)4(x-3))不少学生上手就两边约掉 ((x-3))然后得到 (24)反复验算都觉得哪里不对。真正的卡点并不是移项或合并同类项而是“等式两边能不能同时除以一个可能等于零的式子”这个前提条件没有建立。如果AI只说“把含x的式子都移到左边”等于完全没讲。它必须识别出学生“两边直接约掉”这个动作背后的具体漏洞才能给出有效引导。1.2 题目的输入效率决定了工具会不会被用起来第二个痛点特别务实拍题。数学题和普通文本不一样里面全是公式结构分数线上下有内容、根号嵌套多层、上标下标叠在一起普通OCR按行扫描一遇到这些结构基本就乱了。我测试过一些通用文字识别接口纯文本段落识别率很高但换成数学试卷截图公式区域就开始出错负号丢失、分母错位、等号后面内容被截断。用户拍一道题如果识别结果需要手动修改三次以上这个工具基本就被卸载了。所以我把题目输入当成“前置生死线”来对待下文会单独讲选型逻辑。这里要补充一个很容易被忽略的细节题目通常不是纯公式而是文字描述和公式混排。应用题题干里的中英文、数字、单位都会和公式交错在一起。处理这类混合版面不是简单接一个公式OCR而是要先把版面切成“文本块”和“公式块”再分别走不同的识别链路最后拼装成结构化的题目文本。1.3 学习反馈没有形成闭环第三个痛点是反馈闭环的缺失。做题、错、看解析、结束。没有记录没有归因没有变式巩固。传统纸质练习册天然做不到这一点但AI可以、也应该做到。AI能做的不只是判对错而是为每一道错题打上结构化的标签错误发生在概念理解层、代数计算层还是审题环节这个错误对应的前置知识点是什么需不需要推一道同类型但数字不同的变式题来检验。这个思路在学习科学里并不新鲜间隔练习和反馈矫正早就有大量实证支持缺的只是一个愿意把“错因”当核心数据去建模的产品。我不打算把这个工具定位成“能解所有数学题”的万能解题器。它更像一个耐心的陪练记录你的每次卡顿把卡顿原因结构化然后针对性地陪你补上那一个缺口。从产品角度说这个定位比“题题都能解”更有长期价值。2. 项目边界把“不做什么”先写清楚2.1 目标用户和使用场景先聚焦课后自主练习立项时最容易犯的错就是目标过大。我见过不少项目一开始就扬言要覆盖小学到高中全学段题目类型无所不包最后团队半年做出来一个每个功能都浅尝辄止的Demo。我这次特意把边界收得很窄。第一版只服务一个场景中学阶段学生在课后自主练习时遇到不会做的题身边没有老师需要有人帮他理思路。这个场景有几个特点——用户有明确的学习动机需求发生频率高而且当前可用的帮助手段都很弱问同学不方便搜答案又只是抄一遍。工具只要能在这个薄弱的环节真正帮上忙就有不可替代的价值。我不打算做课堂教学场景。教室里有老师有互动节奏有黑板板书AI贸然插进去只会添乱。自学场景则完全不同那里没有及时反馈AI的启发式引导恰好能填补结构性的空缺。2.2 第一版功能范围单题互动优先学情分析延后功能范围我按优先级切成了三层。第一版死死咬住P0不做额外的发挥优先级功能说明P0拍照/截图识别题目文字与公式混排的结构化识别P0卡点诊断与分步引导不直接给答案按学生的回答动态推进P0完整解析兜底连续三次提示后仍做不出才展示解题过程P1错题本与知识点标签自动记录错题标记关联知识点P1同类变式题推荐基于标签和题面检索推荐变式P2学情周报与薄弱点预测需要积累足够数据第二期再上这个排序背后的逻辑是先证明“单题互动”有价值再谈“长期学习数据”。如果一道题都陪不好错题本和周报都是空中楼阁。做产品最怕引入大量功能最后每个都做得平庸。先把单题体验做成“用过就回不去”的水准后面的事情才有意义。2.3 三条不做的红线除了功能范围我还给自己立了三条红线它们和功能清单同等重要。第一条不做代答作业的工具。用户输入题目工具直接吐出完整答案这就是自动化抄写它削弱学习过程本质上与我做这个项目的初衷相悖。我允许系统展示完整解析但前提是学生已经尝试过、卡住了、并明确表达了“我想看过程”。第二条不做“套壳题库”。市面上有些产品挂上“AI智能学习”的牌子背后只是一个搜索题库的接口。AI的价值在于动态的、针对个体的对话引导如果只是把检索结果包装成对话用户很快就会发现它并不理解自己留存率一定崩。第三条不做以监控为目的的家长端。实时报告孩子正在做哪道题、卡了多久、有没有偷懒这种功能短期能刺激家长付费长期会让孩子对这个工具有强烈的防备心理。我宁愿让用户数据只服务于“帮他学得更好”而不是服务于“让别人控制他”。这些红线可能让产品在商业上走得慢一点但它们决定了这个工具的用户体验是“被陪伴”而不是“被监视”。我倾向于把这个属性当成长期壁垒来建设。3. 技术选型从公式识别到推理引擎每一环的取舍逻辑3.1 公式识别普通OCR和公式OCR是两种完全不同的东西数学公式是二维排版结构分数线的上下关系、根号的覆盖范围、上标下标的分层这些结构信息一旦丢失语义会完全改变。普通OCR按行扫描文字遇到 (\frac{ab}{cd}) 这种结构时会把分子分母当成两行独立文本输出结果基本无法使用。所以公式识别必须走专门方案。这类方案通常分两步第一步检测图像中的公式区域第二步将公式区域转换输出为结构化的LaTeX表示。市面上的开源公式识别模型和商业OCR接口我都做过初步测试结论比较明确清晰印刷体的截图开源模型已经能打到七八十分手写体和复杂矩阵场景商业接口的鲁棒性优势更大但成本也随之上升。我的做法是接一个通用识别能力作为底座同时再包一层规则化后处理。后处理专门盯着几类高频错误全角半角符号混用、负号被识别成连字符、分数线错位、等号溢出。这些错误不修正后面的解题链路一定会被污染。补充一个接口设计建议OCR结果不要直接进入大模型最好先经过标准化模块把题面转成统一的文本结构比如普通文本、LaTeX公式、选择题选项分段存储。这个中间层能为后面的诊断和检索省下大量麻烦。3.2 推理层通用大模型“裸奔”解题计算翻车率很高通用对话大模型的自然语言理解能力很强但直接让它解数学题有一个致命问题精确计算不可靠。三位数乘法、多项式展开、分数运算这类确定性计算模型经常一本正经地算出错误结果。数学解题最后结果错了前面讲解再顺都是枉然。我的路线是“混合推理”模型负责理解题意、拆解思路、生成人话讲解精确计算交给外部工具代数化简和符号变换交给符号计算引擎。举个例子模型识别出这道题需要用配方法它只需要规划“应该配方、配方之后得到哪类结构”具体的代数式展开和合并交给符号引擎完成再把计算结果回填给模型由模型组织成自然的引导语。这样还有一个附加好处可解释性大幅提升。每一步计算都能追溯到符号引擎的输出而不是大模型信口说出来的。对教育类产品来说这个可追溯性非常关键它意味着系统敢为自己的每一句话负责。3.3 知识组织单道题和它的“前驱知识点”光会解一道题还不够工具如果要推荐同类题、定位薄弱点就需要一个知识组织层。这个层我打算用“轻量知识图谱 向量检索”组合实现而不是一开始就建一个大而全的知识体系。具体设计是这样先人工定义一小批核心知识点比如“移项”“合并同类项”“配方法”“因式分解”等等然后标注它们之间的关系尤其是前驱后继关系。因式分解是解一元二次方程的前置技能移项是合并同类项的前置技能。这样当学生在某一步卡住时系统可以从当前题目追溯到具体的前置知识点并给出针对性提示。向量检索则负责处理“找同类题”的需求。把每道题目的题面文本和知识点标签一起嵌入到向量空间检索时先按知识点过滤再按向量相似度排序。它负责找“长得像”的题知识图谱负责解释“为什么像”。两层结合才不是单纯的关键词匹配。3.4 交互层不是一次给答案而是状态机这一步是我自己踩过坑才想明白的。最开始我试用过一个方案直接把题目丢给对话模型请求它“分步骤讲解”模型确实输出了步骤但五步一次性全部给出来了用户体验和直接抄答案没有任何区别。分步引导不能一次性输出全部过程必须在每个关键节点停下等学生给出回应再根据回应的质量决定下一轮提示的力度。在工程实现上这是一个典型的状态机DIAGNOSIS, HINT_1, HINT_2, SOLUTION range(4) def next_action(state, student_input): if state DIAGNOSIS: # 第一步先让学生说出当前的思路 return ask_question(这道题你打算先从哪里下手) if state HINT_1: # 根据学生回答判断错误类型给第一层提示 error_type detect_error_type(student_input) if error_type MISS_ZERO: return hint(等号两边似乎有一个共同因子它可以直接约掉吗) return fallback_hint() if state HINT_2: # 第二层提示更贴近具体操作 return hint(想一想等式两边同时除以同一个数需要满足什么条件) # 状态累加到上限只好展示完整解析 return show_solution()状态机的好处是可控、可测试、可记录。每一次跳转都会留下日志这些日志就是评估“AI引导质量”的一手材料。如果用户第一次在第二层提示后才做出来和第三次在完整解析后才做出来这两个情况对应的教学效果完全不同。4. MVP构建路线先跑通一道题的完整闭环4.1 为什么我选“一元二次方程”作为第一个试点这个决定说出来有点土但我确实把一大批知识点放在桌上挑了很久——函数、几何、概率、数列都考虑过最终锁定的是一元二次方程。原因有三个。第一知识点边界极其清晰解法路径不算复杂但题型覆盖面够广有概念判断、有代数解法、有应用题建模能一次性验证多种诊断逻辑。第二常见错误类型足够丰富缺根、漏解、配方失误、符号错误、应用题列式出错这些都是可以明确分类的错因适合用来检验诊断模块的准确率。第三它在中学数学里是绝对核心的内容和后续的函数、不等式都强关联工具做好了之后自然可以向外延伸。把范围缩小到一元二次方程意味着我可以在两周内做出一个真正能用的闭环而不是花两个月做出一堆没调试过的模块拼装件。4.2 两周开发计划我的开发计划切成了四个阶段每个阶段都有明确的产出物阶段时间核心工作验收产出第一阶段Day 1-3接入OCR接口实现题目标准化图像输入到结构化题目文本的稳定转换第二阶段Day 4-7实现对话状态机和提示模板完成单题三步引导的对话Demo第三阶段Day 8-10接入同类题检索支持基础变式推荐第四阶段Day 11-14搭建评测脚本小范围试用带日志的评估结果和问题清单每一个阶段的产出都可以独立验证避免最后一天才发现问题却不知道是哪一环引入的。4.3 评测指标和最小数据集没有评测闭环开发很容易变成“自认为好用”。我准备了一个大约80道题的最小评测集题型分成三类概念题、解法题、应用题并按难度做了简单分层。每道题都有预先标注的标准答案、常见错误类型和提示语料。围绕这个数据集我定义了三项核心指标第一是题面识别率图像输入后经过自动纠错和后处理能在三次之内得到可用结构化题面的比例。这项指标偏工程决定了用户进来的第一印象。第二是卡点识别准确率把标注的常见错误类型和AI诊断出的错误类型做比对看系统能不能准确命中真实卡点。这项指标偏算法是启发式教学的地基。第三是引导有效率记录了用户经过提示后自行做出题目的比例。这项指标偏产品反映的是整个交互闭环的真实效果。我特别强调一点第三项指标的口径必须严格学生要在没有看到完整解析的情况下自己写出正确答案才能算一次“有效引导”。4.4 最小数据集之外日志先行这个习惯是我做过几个项目后总结出来的——日志能力要在第一天就搭好而不是上线前再补。每次对话的识别结果、状态跳转、提示层级、最终是否做对全部结构化落库。以后不管是分析用户卡点分布还是迭代提示模板都靠这批数据。5. 我现在就能预见的坑幻觉、模糊题面、公式失真和账单5.1 大模型幻觉一本正经地算出错误答案哪怕用了混合推理模型在生成讲解文字时仍然可能顺手写错一个式子。比如解 (x^24)模型可能在最终总结时漏掉 (x-2) 这个根。我已经在一次快速验证里亲眼见过这种情况。对策很简单关键结论必须留痕可校验。所有数据结果尽量从符号计算引擎取模型只负责组织语言。如果某些题目类型的计算确实无法外置比如几何面积推导就必须在提示约束中加入“先计算再复述”的规则并在输出侧做关键数值的抽检。5.2 拍照质量千奇百怪手写体、倾斜、卷面污渍我预计到真实用户上传的图片里什么都有手写体、纸上反光、拍摄倾斜、书页阴影、同桌的手臂入镜。这些问题有些靠算法可以修正有些则必须靠产品交互来兜底。第一版我决定只接受清晰的印刷体截图和拍摄图手写体识别单独立项放到后面做。哪怕这样也要在图片进入识别前做一次预检分辨率太低或模糊度太高的图直接提示用户重新拍摄而不是让OCR硬跑一轮输出一个错误结果。这个交互细节能省下不少后端识别资源。5.3 公式在普通文本里的可读性问题AI生成LaTeX很容易但大多数手机屏幕对一大堆反斜杠和花括号并不友好。如果对话界面直接把“( \frac{\sqrt{x1}}{2} )”这样的原始字符串抛给用户那就是灾难。解决方案是前端必须配备公式渲染组件同时约定模型的输出格式只允许使用标准LaTeX子集禁止自定义宏公式尽量独立成行。这个约束看起来小实际体验差的往往就是这些细节。5.4 Token成本和响应速度一次引导对话可能烧掉多次调用分步引导意味着大模型对话不是一次调用而是多次往返。一次完整的引导流程可能要触发五到八次模型请求Token消耗比单问答高出一个数量级。如果响应速度再慢学生早就不耐烦了。我计划用三层手段来对冲成本常见题型的解析和提示语做缓存命中缓存时零模型调用用本地轻量模型先做题型分类和简单错误识别把大模型调用限制在真正需要深层推理的环节严格控制上下文长度只保留与当前步骤相关的历史消息不把整段对话来回重复发送。5.5 一条容易被忽略的底限教育类工具的安全边界比普通工具更敏感。我坚持一个简单的原则不收集任何身份信息日志里只有做题行为数据不提供任何形式的代写能力不做排名、比较和焦虑制造。所有功能设计都围绕“学习者的成长”而不是“学习者的评价”。这个底限不写进代码但比代码影响更大。这个系列叫01就说明后面还会有02、03。下一期我计划展开公式OCR的选型对比和那80道评测集的标注细节这两部分是整个系统能不能站住的根基。这个项目最后能做成什么样子说实话我没有十足把握但把目标缩小到“陪一个学生认真走完一道题”我觉得至少是值得先试出来的。