1. 当工具迭代速度超过学术评价周期谁在为数学家的职业路径买单第一次看到“OpenAI才不管数学家的职业生涯呢”这个说法我正和一位在某高校做基础数学研究的朋友吃饭。他放下手机苦笑了一下说组里刚有个博士生用大模型跑了一组猜想验证结果比手算快了不知道多少倍但论文写出来之后审稿人第一句话问的是“这到底算数学贡献还是算工程实现”。这个场景让我意识到标题里那句带着调侃意味的吐槽其实戳中的是一个远比“AI会不会做数学题”更复杂的问题当工具的能力边界以月为单位扩张时依赖长周期评价体系的职业群体他们的路径规划该锚定在哪里。我自己不是数学家但过去几年一直在跟踪大模型在形式化推理和符号计算方向上的落地情况接触过不少做数论、组合数学、代数几何的研究者也帮几个团队做过模型辅助证明的工程化尝试。这篇内容想聊的不是“AI能不能替代数学家”这种已经被嚼烂的话题而是从一个更实际的角度出发当一个数学家发现自己的核心技能——猜想生成、证明构造、反例搜索——正在被工具以极低成本部分覆盖时他真正面临的职业风险是什么以及可以采取哪些具体的应对策略。适合正在读博、做博后、或者已经在高校拿到教职但研究方向偏理论的朋友参考也适合对AI与基础科学交叉领域感兴趣的工程人员了解另一侧的视角。需要提前说明的是我下面提到的所有案例和场景都做了模糊化处理不指向任何具体的机构或个人。涉及的工具选型和操作细节一部分来自我自己跑过的实验一部分来自和一线研究者交流时他们分享的经验我会尽量把“为什么这么做”讲清楚而不是只丢一个结论。2. 大模型在数学研究中的真实能力边界从猜想生成到证明验证2.1 模型擅长什么、不擅长什么得分开看很多人对AI做数学的认知还停留在“让它解一道奥数题”的阶段但实际研究中模型被用到的地方要细碎得多。我自己的观察是当前阶段大模型在数学研究链条上的表现可以分成几个明显的层次。最擅长的是模式识别和类比迁移。比如给定一组整数序列让模型判断它是否可能来自某个已知的递推关系或者从一个已知定理出发让它生成几个结构相似的命题变体。这类任务本质上是在高维空间里做相似度匹配恰好是Transformer架构的强项。我试过让模型在OEIS的公开数据上做序列补全在限定领域内比如线性递推、模形式系数的命中率相当可观虽然不能直接当定理用但作为猜想来源的“灵感触发器”是合格的。中等水平的是符号计算和代数化简。这里的情况比较复杂因为模型本身不做符号推导它是在预测下一个token所以当表达式一长、嵌套一深错误率就会陡增。我见过一个典型的失败案例让模型化简一个包含多重根号和分式嵌套的代数式它给出的结果在数值上碰巧对了几组测试值但符号形式是错的。这种“数值上蒙对”的情况在研究中非常危险因为如果你不逐项验证很容易把错误结论带进后续推导。最不擅长的是长链条的逻辑推理和反例构造。数学证明的每一步都需要严格的逻辑蕴含而模型在超过一定步数之后中间步骤的可靠性会指数级下降。反例构造更麻烦因为它要求模型主动跳出训练分布去寻找一个“不满足条件的对象”这本质上是一个搜索问题而不是生成问题。我试过让模型找某个图论猜想的反例它在小规模图上转了很久给出的候选要么不满足前提条件要么验证下来其实满足猜想最后还是要靠专门的搜索程序来兜底。2.2 一个具体的实验用模型辅助验证组合恒等式为了把上面的判断说得更具体我拿一个自己跑过的实验来拆解。目标是验证一个组合恒等式形式是两边都是二项式系数的求和左边带交错符号右边是一个封闭形式。这种恒等式在组合数学里很常见手工验证需要用到生成函数或者组合双射比较耗时。我的做法是分三步走。第一步让模型生成若干组小参数下的数值用Python的sympy库做精确计算确认等式在有限范围内成立。这一步模型的作用是帮我快速写出计算脚本的框架省去了查API的时间。第二步让模型尝试给出一个证明思路比如“考虑用母函数方法构造某个生成函数并比较系数”。这一步模型给出的思路往往比较泛但偶尔会有惊喜比如它提到可以用Zeilberger算法做自动证明这个方向我自己没想到。第三步根据模型提示的方向用专门的符号计算包去跑Zeilberger算法得到递推关系后再验证。整个流程下来模型真正贡献的是“提示了一个我没想到的工具方向”而不是直接给出了证明。这个比例在我接触的案例里很有代表性模型的价值更多体现在拓宽搜索空间而不是替代核心推导。如果你指望它直接输出一个可发表的证明大概率会失望但如果你把它当成一个知识面很广但不太靠谱的讨论对象它的效率提升是实实在在的。2.3 为什么“验证”比“生成”更难被替代这里有一个容易被忽略的点在数学研究中生成一个猜想或者一个证明草稿的成本其实远低于验证它的成本。一个错误的猜想可能只需要几秒钟就能写出来但要确认它是否成立可能需要几天甚至几个月的努力。模型把生成成本压到了接近零但验证成本并没有同步下降因为验证需要严格的逻辑检查而逻辑检查目前还是靠人或者靠形式化证明助手。这就导致了一个结构性变化研究者的时间分配会从“想猜想”更多地向“筛猜想”倾斜。以前你可能花一周想出一个有意思的猜想然后花一个月去验证现在模型一天能给你生成几十个候选你的工作变成了快速判断哪些值得深入验证。这个转变对职业能力的要求是不一样的——以前更看重直觉和创造力现在更看重判断力和筛选效率。我在和几个做数论的朋友聊的时候他们普遍反映这种“筛选压力”是真实存在的而且随着模型能力提升候选的质量在提高但数量增长得更快。3. 数学家职业路径上的三个真实风险点读博、求职与考核3.1 博士阶段选题的“可计算性”正在被重新定义如果你正在读数学博士或者准备申请有一个变化值得注意过去选导师和选题时大家会避开那些“计算量太大、手工做不动”的方向因为博士时间有限你不可能花五年去手算一个大规模的分类问题。但现在这个约束在松动因为模型和配套的符号计算工具可以帮你处理掉大量机械性工作。这听起来是好事但风险在于当计算门槛降低之后那些原本因为“算不动”而没人做的题目会突然涌入大量竞争者。我认识一个做代数组合的博士生他的课题原本是某个特定类型的对称函数展开手工计算只能做到低阶高阶的系数结构一直没人碰。结果去年他发现有组用模型辅助的团队几个月就把高阶情况推到了他前面。他的应对策略是转向研究这些系数背后的组合意义而不是继续拼计算速度——这个转向是对的因为拼计算你永远拼不过专门做工具的人。所以博士阶段的一个实际建议是选题时不要只看“这个问题有没有意思”还要看“这个问题的核心难点是不是可被工具批量处理的”。如果核心难点是计算量那你要小心如果核心难点是概念构造或者证明策略那相对安全因为模型在这方面的能力还差得远。3.2 求职阶段论文里的“计算贡献”正在贬值数学博士求职尤其是申请教职或者博士后论文是硬通货。但这里有一个微妙的变化如果你的论文主要贡献是“算出了一个之前没人算出来的东西”那它的价值正在被重新评估。审稿人和招聘委员会越来越倾向于问一个问题这个计算为什么必须由人来做如果模型加上合适的工具也能做那这篇论文的不可替代性在哪里我见过一个比较极端的例子某位申请者的论文里有一个关键表格列出了某个组合对象在几十个参数下的计数。这个表格确实是手工算的花了很多时间但审稿人直接指出用现有的符号计算包可以在几小时内复现。最后这篇论文虽然发了但在求职时并没有成为加分项反而被质疑“工作量不够硬核”。反过来那些在证明策略上有创新的论文即使计算量不大反而更受青睐。因为证明策略体现的是研究者的数学品味和构造能力这些东西目前模型还很难模仿。所以如果你在准备求职建议在论文里把“为什么这个证明思路是关键的”讲清楚而不是把大量篇幅花在展示计算结果的规模上。3.3 考核阶段长周期研究与短周期评价的矛盾在加剧拿到教职之后考核压力是另一个现实问题。数学研究的周期本来就长一篇好论文从构思到发表三五年很正常。但现在工具迭代的速度是以月为单位的你很难预测三年后你正在做的方向会不会被工具彻底改变。我认识一位在某高校做几何分析的老师他的研究方向需要大量复杂的估计和不等式推导。去年他花了大半年时间做了一个技术性很强的引理结果今年年初发现有个团队用模型辅助的自动定理证明工具在更一般的条件下给出了一个更简洁的证明。他的工作并没有错但“更简洁的证明”出现之后他那个引理的引用价值就下降了。这种风险在考核周期内是很难对冲的因为你不可能同时做多个方向来分散风险。一个可能的应对方式是在考核期内把一部分精力放在“工具增强型”的研究上也就是那些明确需要结合模型能力才能做的问题。这类研究的好处是你的贡献里包含了“知道怎么用工具”这个技能而这个技能在短期内不会贬值。坏处是这类研究在传统数学评价体系里可能不被认为是“纯数学”需要你在申请经费或者晋升时额外解释。4. 从“被工具替代”到“与工具共生”可操作的应对策略4.1 把模型当成“高带宽的讨论对象”而不是“答案生成器”这个心态转变听起来简单但实际操作中很多人会不自觉地滑向两个极端要么完全不用觉得模型做的东西不可靠要么过度依赖模型说什么就信什么。我自己的经验是把模型定位成一个“知识面很广、反应很快、但经常犯错的合作者”用它的方式来用它。具体怎么做比如你在想一个证明卡在某个步骤上可以把当前的状态描述给模型让它给出几个可能的下一步方向。不要指望它给出完整的证明而是看它提到的方向里有没有你没想到的。我试过在一个图论问题里模型建议我考虑用线性代数方法构造辅助矩阵这个方向我自己没想到虽然后来验证下来那条路走不通但它提醒了我可以从这个角度去思考。另一个用法是让它帮你做“反向检查”。你有一个证明草稿可以让模型尝试找漏洞比如“这个推导里哪一步的隐含假设可能不成立”。模型找出的漏洞不一定对但它提出的问题往往能帮你发现自己思维里的盲区。这种用法比让它直接证明更可靠因为找漏洞是一个相对开放的任务模型不需要给出严格正确的答案只需要给出值得检查的点。4.2 建立自己的“工具链”而不是依赖单一模型我见过一些研究者把所有希望寄托在某个特定模型上这是很危险的。模型会更新API会变价格会调整如果你所有的辅助工作都绑定在一个工具上一旦它出问题你的研究节奏就会被打乱。更稳妥的做法是建立一个分层的工具链。底层是符号计算库比如sympy或者专门的数论计算包这些是确定性的结果可靠。中层是模型用来做猜想生成、方向提示、代码框架生成。上层是形式化证明助手比如Lean或者Coq用来做最终验证。这三层各司其职模型出问题的时候底层和上层还能正常工作。我自己在跑组合恒等式验证的时候就是按这个结构来的sympy负责数值验证模型负责提示证明方向最后如果有形式化验证的需求再转到证明助手。这样即使模型某次给出的方向完全离谱我也不会浪费太多时间因为数值验证会很快告诉我这条路走不通。4.3 在论文和报告中明确“工具贡献”的边界这是一个比较敏感但必须面对的问题如果你的研究里用了模型辅助怎么在论文里交代我的建议是不要藏着掖着但也不要夸大模型的贡献。明确写出哪些部分是模型生成的候选、哪些部分是人工筛选和验证的、哪些部分是独立完成的。这样做有几个好处。第一审稿人不会觉得你在隐瞒什么反而会认为你的方法论是透明的。第二如果后续有人想复现你的工作他们知道哪些步骤需要模型、哪些不需要。第三这也是对自己贡献的一种保护——如果模型只是提供了候选而核心的筛选和证明是你做的那你的贡献就是清晰的。我见过一些论文在致谢里含糊地提一句“使用了AI辅助”但不说明具体用在哪里这种写法反而容易引起审稿人的疑虑。不如直接写清楚在猜想生成阶段使用了某类模型生成了若干候选经过人工筛选后保留了哪几个后续的证明和验证由作者独立完成。这样既诚实又不会削弱自己的贡献。5. 一个具体的操作流程用模型辅助筛选猜想并快速验证5.1 从问题描述到候选猜想的结构化提示假设你有一个研究问题比如“某个类型的整数序列是否满足某种递推关系”。手工做法是查文献、猜形式、验证。用模型辅助的做法可以更系统一些。第一步把问题描述清楚包括已知的条件、你希望得到的结论形式、以及任何已知的类似结果。这一步的目的是给模型足够的上下文让它生成的候选不至于太离谱。我通常会写一段类似“已知序列a_n满足……前几项是……猜测它可能满足一个线性递推关系系数可能是……请给出几个可能的递推形式”这样的提示。第二步让模型生成多个候选不要只生成一个。我一般会要求它给出五到十个不同的形式并标注每个形式的置信度。这一步的关键是多样性因为模型的第一反应往往是训练数据里最常见的模式而你需要的是覆盖不同的可能性。第三步对每个候选做快速数值验证。用sympy写一个脚本对前几十项做精确计算看哪些候选在数值上成立。这一步会筛掉大部分错误候选剩下的再进入下一步。5.2 用符号计算做快速证伪而不是直接证明数值验证通过之后不要急着去证明先尝试证伪。因为证明一个错误的猜想是浪费时间而证伪往往更快。具体做法是对每个候选尝试构造一个反例。可以让模型帮你生成反例的搜索策略比如“如果这个递推关系不成立最可能在哪里出问题”。然后根据这个策略写一个搜索程序在更大的参数范围内找反例。如果找不到反例再考虑证明。这个流程的好处是你把大部分时间花在筛选上而不是花在证明错误的东西上。我自己的经验是模型生成的候选里大概只有一到两个能通过数值验证而这一两个里面又只有一半能通过反例搜索。最终值得去证明的可能只有一个。这个比例听起来很低但考虑到生成成本几乎为零整体效率还是比手工猜想要高。5.3 把验证过程写成可复现的脚本这一步经常被忽略但非常重要。你在验证过程中写的脚本应该保存下来并且加上注释说明每一步在做什么。这样做的原因有两个一是如果你后来需要回头检查可以快速复现二是如果论文里用到了这些验证审稿人可能会要求你提供代码。我自己的习惯是每个研究项目建一个单独的目录里面放三个子目录scripts放验证脚本notes放模型交互的记录results放输出结果。模型交互的记录尤其重要因为你需要知道哪些候选是模型生成的、哪些是你自己改的。这些记录在写论文的方法部分时会很有用。6. 工具迭代周期与学术评价周期的错位一些个人观察6.1 为什么“等工具稳定了再跟进”是一个陷阱我听过不少人说现在模型更新太快等它稳定下来再学也不迟。这个想法在工程领域可能成立但在数学研究里很危险。因为工具的能力边界在变而你的研究品味和判断力是需要时间培养的。如果你等到工具稳定了再开始用你会发现别人已经用了几年的工具积累了大量的使用经验和筛选直觉而你还在摸索基本操作。更重要的是工具迭代本身会改变问题的提法。以前因为计算量太大而没人问的问题现在可以问了以前因为验证成本太高而没人做的猜想现在可以做了。这些新问题的提出往往需要你对工具有深入的理解知道它能做什么、不能做什么。这种理解只能通过实际使用来获得看别人的总结是不够的。6.2 数学家的核心技能正在从“算”向“判断”迁移这个判断我在前面已经提过这里再展开说一下。传统上数学家的核心技能包括计算能力、证明构造能力、猜想提出能力。现在计算能力的重要性在下降因为工具可以替代大部分机械计算。猜想提出能力的重要性在上升但形式在变化——以前是你自己想出猜想现在是你从模型生成的大量候选中筛选出有价值的猜想。证明构造能力依然重要但重点在转移。以前你需要自己写出完整的证明现在你可能只需要写出关键的构造步骤剩下的机械验证可以交给工具。这意味着你对证明的“宏观结构”的理解变得更重要因为你需要判断哪些步骤是关键的、哪些是可以自动化的。这种技能迁移对职业发展的影响是深远的。如果你还在用“我能算多快”来定义自己的竞争力那你会越来越吃力。但如果你能把竞争力定义在“我能判断什么值得算”上那工具越强你的价值反而越大。6.3 一个可能的长期均衡数学家更像“研究导演”我个人的猜测是长期来看数学家的角色会越来越像电影导演——你不需要自己操作每一台设备但你需要知道整个流程、知道什么时候该用什么工具、知道最终要呈现什么效果。具体的技术操作可以交给工具和合作者但判断和决策必须由你来做出。这个类比不一定准确但方向可能是对的。如果你正在规划自己的职业路径可以考虑往这个方向靠多了解工具的能力边界多积累筛选和判断的经验多练习把大问题拆解成工具可以处理的小问题。这些能力在未来的数学研究里会越来越值钱。7. 一些实操中的注意事项和踩过的坑7.1 不要相信模型给出的“证明”哪怕它看起来很漂亮这是我踩过的最大的坑。有一次模型给出了一个非常优雅的证明每一步看起来都很合理我差点就信了。后来仔细检查发现它在第三步用了一个不成立的隐含假设——那个假设在特殊情况下成立但一般情况下不成立。模型没有区分这两种情况因为它只是在预测“看起来像证明的文本”。从那以后我养成了一个习惯模型给出的任何证明我都会逐行检查特别是那些“显然成立”的步骤。因为模型最擅长的就是生成“看起来显然”但实际上有问题的步骤。如果你不检查很容易把错误带进后续工作。7.2 模型对“反例”的敏感度远低于对“正例”的敏感度另一个坑是当你让模型找反例时它往往会给你一些不满足前提条件的例子或者给你一些其实满足猜想的例子。这是因为模型在训练时见到的“正例”远多于“反例”它对反例的分布不熟悉。应对方法是不要让模型直接找反例而是让它生成反例的“搜索策略”。比如“如果这个猜想不成立最可能在哪里出问题应该搜索什么样的参数范围”然后你根据这个策略写程序去搜。这样模型的作用是提供方向而不是提供答案。7.3 保存所有交互记录哪怕当时觉得没用这个建议看起来琐碎但实际很有用。我在做一个项目时模型曾经提到过一个方向我当时觉得不靠谱就忽略了。半年后做另一个项目时突然发现那个方向其实很有用但已经找不到当时的记录了。从那以后我开始用简单的文本文件记录每次和模型的重要交互包括提示、输出、我的判断。这些记录在写论文的方法部分或者申请经费时都是很好的素材。7.4 不要把所有时间花在工具上数学直觉依然需要手工训练最后一个提醒工具再强也不能替代你对数学对象的直觉。我见过一些年轻研究者过度依赖模型结果自己的数学品味在下降——他们能判断模型给出的结果对不对但很难自己提出一个好的问题。这其实是一种退化。我的建议是每天保留一部分时间做“无工具”的思考比如读论文、手推公式、和同行讨论。这些活动看起来效率低但它们在训练你的数学直觉而直觉是筛选模型输出的基础。如果你没有好的直觉模型生成再多候选你也挑不出有价值的那个。8. 写在最后一个从业者的个人体会回到标题那句话“OpenAI才不管数学家的职业生涯呢”。这话说得没错工具的开发者在追求通用能力不会为某个特定职业群体的路径负责。但反过来想这也意味着数学家不需要等待谁来“照顾”自己的职业发展主动权其实在自己手里。我自己的体会是过去两年里我把模型引入研究流程之后花在机械计算上的时间少了大概一半但花在判断和筛选上的时间多了。整体效率是提升的但提升的方式和我想的不一样——不是模型帮我做了更多而是模型让我看到了更多可能性然后我需要花时间去判断哪些可能性值得追。如果你正在这个领域里我的建议是不要问“模型会不会取代我”而是问“模型能帮我看到什么我以前看不到的东西”。这个问题的答案可能比你想的要丰富。