GPT-5.6和Fable联手解决了一道悬了25年的数学难题。如果只看标题这大概率会被归进“AI又行了”的新闻流水线里。但真正让我停下来的是“联手”和“25年”这两个词。前者说明这不是一个模型单打独斗后者说明这不是一道能靠语言模型“文字接龙”顺手蒙对的题。在我看来这条新闻值得拆开的重点不是“GPT-5.6有多聪明”而是它和Fable之间形成了一种新的分工——一个负责猜一个负责验。“猜”和“验”背后是两种完全不同的能力。GPT-5.6这类大模型擅长从海量模式里找到可能的路径但不会保证每一步都正确Fable这类工具恰好相反它可能没有创造力却可以严格检查每个推导是否符合规则。把两者绑在一起相当于给模型的想象力装了一道“质检闸门”。这才是“解决25年难题”背后真正值得讨论的方法论。这种模式在软件工程里已经被用过很多年先生成代码再跑测试和静态分析。但放在数学证明的语境里它更接近一条“形式化验证流水线”。下面我想聊的不是那道难题本身而是这套协作系统为什么能成立、落地时有哪些坑以及它对普通开发者和AI使用者到底意味着什么。1. 为什么数学难题不能只靠大模型“硬想”1.1 语言模型和定理证明器天生不是一回事大模型本质上是一个根据前文预测后续文本的系统。它可以在数学题上给出很像样的思路甚至写完一整段证明过程。但注意是“像样”不是“正确”。它没有内置的逻辑内核也不具备“引用某条公理经过若干步推导得到某个结论”的执行能力。它只是把见过的数学模式重新排列组合了一遍。面对一道悬了25年的难题真正的难点往往在于构造一个没有漏洞的论证而这个要求恰好戳中语言模型的核心短板幻觉。幻觉未必是“胡说八道”。更常见的情况是模型把某个数学家常用的证明路径和另一个问题混在一起或者省略掉一个它认为“显然”但实际需要额外验证的步骤。在普通对话里这种省略无伤大雅但在数学证明里一个省略就是一个断点。验证器存在的意义就是把这些断点全部暴露出来。1.2 没有验证器AI给出的证明无法被信任过去两年有很多演示证明大模型能解竞赛题、能发现新的猜想但很少看到它独立解决一个被数学共同体认可的开问题。原因很简单数学共同体接受一个证明靠的不是“AI说这个证明是对的”而是每个步骤都能被人工或机器重新推导。Fable这样的工具就是机器层面的“重新推导”。它把模型生成的自然语言证明映射成形式化规则然后逐条检查。我们可以把Fable理解成一个极其严格的评审它不看名气不看模型参数只检查逻辑链条是否真正连通。GPT-5.6和Fable的联手不是在同一个维度上叠加能力而是补上对方缺失的另一半。25年的悬而未决通常意味着两件事第一人类已经尝试过大量路径靠“灵感和直觉”已经很难突破第二可验证的证明空间可能非常大人工逐条构造速度太慢。AI的优势是高通量地生成候选路径验证器的优势是能快速筛掉无效路径。两者一旦形成循环相当于把“尝试-检查-再尝试”的周期从以月为单位缩短到以小时为单位。这里可以做一个跨领域类比。把它想成新药研发AI负责生成候选分子自动化实验负责筛选毒性人负责制定筛选标准和目标。如果没有筛选环节候选分子再多也没有意义。同样让模型生成一大批证明草稿再由Fable筛掉不成立的最后留下可信的候选再交给人评判。这就是这套协作的基本逻辑。2. 从“生成答案”到“生成证明”难度连着跨了三级2.1 答案、证明、形式化证明三者差别很大“生成答案”只需要预测结果比如“这个不等式的解集是什么”错了可以重跑一次。“生成证明”要复杂得多因为证明是一串推理链中间任何一步断掉结论就不成立。而“生成能被机器验证的证明”比前者更难它不仅要求推理链完整还要求每个符号、每个规则都符合验证器定义的语言。许多人在新闻里看到“AI解决数学难题”下意识以为模型只是“给出了正确答案”。但真实的数学前沿问题几乎所有难度都在“如何证明”而不是“答案是什么”。答案存在但没人能证明它是唯一答案也无法验证推演没有漏掉特殊情况。GPT-5.6可能擅长在知识图谱里做跳跃式联想而Fable这样的验证器擅长把跳跃变成一步一步的脚印。只有跳得足够远又每一步都有脚印才可能真正突破25年前的障碍。2.2 为什么“翻译”往往比“推理”更费时间实际做这类任务时最耗时间的往往不是让模型去“想”而是把数学问题写成形式化语言。25年难题可能涉及大量自定义概念、引理和记号。模型需要先理解这些概念再把证明拆成验证器能读懂的语句。如果某个引理没有被预先形式化验证器就会拒绝后续步骤。所以在这个协作体系里人的任务并不是旁观而是提供一份足够完整的问题描述和规则库。这就引出一个关键点这类成果很难被复现不是因为模型不可复现而是因为“域知识前置”太重。模型可以很快生成候选证明但如果没有花几周时间把基础定义、已有引理、常用的证明策略都翻译成形式化语言验证器根本跑不起来。换句话说真正的瓶颈不在模型智商而在“工程化的知识表示”。从“生成答案”到“生成证明”再到“生成可验证的证明”难度不是线性增加而是在每一个阶段都会引入新的约束。模型负责“猜想一个证明骨架”验证器负责“检查骨架里的每一根骨头”人负责“确定哪些骨头是必要的”。最终只有经历了这三层跳跃一条AI生成的结论才从“陈述”变成“知识”。3. 一个可以复用的协作范式先生成候选再交给验证器3.1 工作流骨架不管GPT-5.6和Fable具体用什么接口对接这类任务大概率走的是同一个流程定义问题把“25年难题”翻译成验证器可处理的形式化语言同时保留一份自然语言版本给模型。生成候选把问题、可用公理、已有引理和当前反馈一起交给GPT-5.6让它生成一段证明或证明骨架。格式转换把模型输出的自然语言结构转换成验证器能读取的中间语言。如果模型已经输出验证器接受的结构这一步可以省略。验证Fable接收候选证明逐条检查。如果通过就保留如果失败返回错误信息。反馈循环把错误信息翻译成模型更容易理解的提示词回到第2步。重复直到通过或达到轮数上限。人工复核机器验证通过后由数学家确认形式化过程本身是否有问题、有没有遗漏条件。这个流程像极了我们在开发里的“测试驱动”先有一个失败用例再写代码跑测试根据报错修改直到测试通过。区别在于数学证明的“测试”严格得多它不是抽样验证而是每条规则都必须匹配。注意不要一上来就把候选生成数量、温度参数、验证轮数全部拉满。先用一条小引理跑通全流程确认输入、输出和反馈都没有问题再扩大到完整难题。3.2 为什么验证器必须“慢”和“死板”很多人会问既然GPT-5.6已经很聪明为什么不让它自己检查自己原因很简单同一个系统生成的推理再由同一个系统检查很容易出现“自我确认偏差”。尤其当模型已经预判了“这个结论应该成立”它会倾向于忽视细节瑕疵。验证器这种工具虽然慢而且要求每个步骤都显式匹配规则但它不会因为“结论好像是对的”就放行。它的死板是信任的基础。在人工智能辅助科学研究的场景里“独立性”是一个极其重要的原则。生成器和验证器不能是同一个模型的不同prompt也不能共享同一个隐藏状态。否则训练出的“验证”很难不被生成的偏好污染。Fable在架构上的价值就是扮演一个不依赖大模型判断的裁判。3.3 一个最小可运行示例下面给出一个伪代码表示协作结构而不是某个具体实现def solve_with_verifier(problem, verifier, generator, max_rounds10): feedback for i in range(max_rounds): candidate generator.generate( problemproblem, feedbackfeedback ) result verifier.verify(candidate) if result.is_valid: return candidate feedback translate_feedback_for_model(result.error) return None # 需要人工介入这段代码虽然简单但包含了核心生成器每次都需要看到上一轮的失败反馈验证器是独立环节。只要反馈信息足够结构化模型就能逐步修正。现实中复杂得多比如需要批量生成候选、并发验证、增量缓存等但骨架是稳定的。把“直接让大模型生成证明”和“大模型生成验证器检查”放在一起对比决策重心会很清晰维度只让大模型直接生成证明大模型生成 验证器检查正确性依赖模型状态存在幻觉通过规则检查可定位错误可解释性输出自然语言难以逐条复核验证器能指出第几步失败效率单轮看似快实际需要人工重查需要多轮迭代单步更慢适用阶段找思路、写草稿最终确认、学术可复现表格看起来简单但反映了两种完全不同的工作方式。前者把信任押在模型的直觉上后者把信任押在规则系统上。对需要长期积累、可复现的知识生产来说后者明显更值得投入。4. 真正落地时最容易踩的五个坑4.1 模型输出的证明不是验证器能读懂的语言这是最普遍的问题。GPT-5.6可能会生成一个数学上“看起来正确”的证明但Fable只接受它定义好的语法和规则。如果问题描述、引理名称、符号体系没有提前统一验证器会在第一句就失败。建议先做一次“翻译层测试”用几个已知为真的简单命题走完整个流程确认中间语言能跑通。这个坑很像开发中“环境不一致”本地能跑CI上挂掉最后发现是Python版本不一样。在AI形式化验证的场景里符号系统就是环境。不要以为模型能“理解”的问题验证器也能“理解”。验证器一字不差地执行指令所有的约定必须在输入里写清。4.2 让模型一上来就挑战最终难题给模型一整道25年难题期望它直接给出完整证明现阶段还不太现实。更合理的做法是把难题拆成若干个引理让模型先证明一个子引理验证通过后再扩大范围。每个引理相当于一次可控冲刺。如果子引理都过不了最终难题大概率也不行。这背后的原因在于生成模型在长链条推理时错误会随着步骤增加而累积。前面几步错得越隐蔽后面的努力就越容易建立在错误基础上。把问题拆小本质上是在缩短推理链提高每一步的验证精度。不要急着让模型直接“证明整道题”。先找一个子引理或一个简化模型证明它通过验证再逐步增加复杂度。4.3 反馈回路没有设计好如果验证失败的反馈只是“第172行类型错误”模型很难从中学会修改。需要把错误信息转换成更接近人类思维的语言例如“这一步试图把整数加法应用到实数上但缺少类型转换”。反馈质量直接决定迭代效率。反馈越具体收敛越快。这可能是整个流程里最容易被低估的部分。许多人以为核心是模型能力强结果发现真正影响结果的是“如何把验证器的报错翻译成模型的prompt”。一个结构清晰的错误反馈可以把10轮迭代压缩到2轮而一个含糊的反馈可能让模型在同一个错误附近打转。4.4 验证器规则库和公理不全有时候证明本身没毛病但验证器报错是因为某个背景定义没有被加入规则库。举例来说如果问题涉及“紧致性”但规则库里没有拓扑学公理验证器就无法继续。因此在启动正式任务前要用一组基础引理测试规则库的完备性。这就像搭建测试环境先让已知用例全部通过再开始新功能开发。一个常见的错误是团队把大量时间花在生成器和提示词上却忽略验证器本身是否配置正确。如果Fable对已有定理的检查都不能通过那它对未知难题的检查结果自然没有意义。先建立一个“回归测试集”里面都是已知正确的经典证明保证每次修改验证器配置后这些样本仍然全绿。4.5 单次成功不等于可复现即使某一次GPT-5.6生成的证明通过验证也不代表这是一个稳定能力。可能只是随机搜索撞到了正确路径。新闻里的“解决一道难题”如果只出现了一次后续还需要继续验证。建议多做几轮独立生成用不同的随机种子、不同的上下文组织方式生成多条证明路径再交给验证器。如果多条路径都通过可信度才高得多。这也意味着当你说“AI解决了一道难题”时最好保留完整的参数、种子、验证器版本和规则库快照。否则其他人无法复现也无法判断是方法有效还是运气使然。单次成功只是“冒烟测试通过”不等于“系统性能力成立”。用不同的条件重复验证才能把一次偶然变成可复用的结果。4.6 验证一直失败时按什么顺序排查如果验证一直失败不要先怀疑模型不够聪明。按下面的顺序排查看现象报错是语法错误、类型不匹配、步骤缺失还是超时看输入自然语言问题是否完整形式化规则库是否包含所有定义和引理看中间层模型输出是否被正确翻译成验证器输入有没有丢失括号、合并了不该合并的表达式看参数模型温度是否过高导致候选越来越发散候选数量是否太少验证超时设置是否过短看环境验证器版本、依赖库、公理库是否一致有没有缓存了旧结果最后才判断是不是模型能力边界有没有给足反馈有没有把问题拆分到足够小的子问题这个排查顺序的核心思想是从“离问题最近、最容易出现细节错误”的环节开始检查而不是一上来就否定整个方案。大部分“验证一直失败”的问题最后都出在输入格式、规则库或反馈翻译上而不是模型本身。5. 这套协作方式能用到哪些场景边界又在哪里5.1 适合规则明确、结果可验证、目标单一的场景这套“生成验证”的工作流最适配那些有明确规则和验证手段的领域。数学证明是最经典的例子除此之外算法正确性、智能合约安全、协议验证、编译器优化验证都属于同类结构。在这些场景里我们可以用一个严格工具做裁判模型做参赛者。只要裁判规则没写错最终输出就在逻辑上可靠。对开发者来说这类场景的特征是可以列出“通过条件”。比如“快速排序的结果是有序的并且是原数组的一个排列”这个条件可以形式化。模型负责生成实现验证器负责检查性质。只要性质写得准AI提供方案、验证器提供质量保障这套组合就能真正用起来。5.2 不适合标准缺失、需要价值判断、目标模糊的场景反过来如果一个问题没有严格验证标准比如“这篇文章是否有深度”“这个产品能否成功”“这个需求是否合理”验证器很难定义规则。即使强行套一个打分模型也只能代表某种偏好不具备数学证明那种普遍性。所以这套体系不会取代人的判断它只会把人的判断放在更高层级划定问题边界、建立规则库、决定什么算“通过”。常常有人把“验证”误解为“人工检查”但人工检查不具备可扩展性也不够稳定。真正的验证器应该是一个独立的自动裁判。如果找不到自动裁判那么“生成验证”就只能退化成“生成人工评审”效果会大打折扣。5.3 对普通开发者的启发生成代码测试的结构也是一样的我们在日常开发里已经经常使用类似范式。代码生成模型负责写函数编译器负责语法检查单元测试负责行为验证。区别是编译器/测试的严格性不如形式化验证但它与GPT-5.6Fable的结构是同一套骨架。如果你正在使用AI辅助开发值得记住的一点是把“AI生成”和“独立校验”分开不要让同一套系统既生产答案又评估答案。校验器可以是单测、CI、静态分析也可以是代码评审工具。这里的核心原则不是“所有东西都必须形式化”而是“应该有某个环节不属于生成模型也不被生成模型的偏好影响”。哪怕只是一个简单的断言测试只要它是独立的就能在AI生成的代码上提供额外一层信任。5.4 需要警惕的前置成本这套方案的适用边界还包括成本。形式化问题定义成本高验证器开发成本高反馈翻译成本高。如果只是写一小段脚本、做一次性的内容生成完全没必要引入这类流程。只有当结果需要长期复用、正式发布、高可靠性或者需要持续维护时才值得投入这些前置成本。一个更现实的经验是先从小规模、低成本的验证工具开始而不是第一版就追求像Fable一样完整的验证器。即便是一个简单的“规则检查器”只要能覆盖最核心的逻辑也能给模型生成结果提供巨大的约束力。随着问题复杂化再把检查器逐步加强。6. 我的判断以后衡量AI能力标准会变成“能不能承担可验证的子任务”6.1 新闻之外真正的“基础设施”正在成形回到GPT-5.6和Fable联手的新闻。我觉得它真正值得记住的不是某个模型又跨越了一个里程碑而是这种“生成验证”的协作模式正在变成一种基础设施。以后评价一个模型强不强或许不再只看排行榜分数而是看它能不能稳定地承担一个“可验证的子任务”。模型负责输出验证器负责兜底人负责定义问题。一个能够被验证器反复检查的模型比一个偶尔给出惊艳答案但不可控的模型更有工程价值。原因很简单工程系统的核心不是峰值能力而是可预测性。你可以在一个可预测的系统上构建更复杂的结构却很难在一个时好时坏的模型上堆叠更多功能。Fable这类验证器的存在正是为了让“可预测性”成为可能。6.2 如果你要从零开始试一次如果你也想做类似尝试不要急着找一道人类数学家25年没解决的问题。先挑一个小而完整的引理准备一个能严格验证的工具写一个反馈回路然后让模型不断尝试。每一次失败都记下来变成下一轮生成的历史信息。这个过程本身比“解决难题”更有复用价值。25年悬而未决的难题被机器辅助解决已经很了不起。但更了不起的是我们终于找到一种方式让AI的想象力不至于变成不可控的幻觉。想象力负责打开门验证器负责确认门后不是悬崖。这种组合才是长期有效的进步方式。