GPT-5.6携手Fable：生成+验证如何攻克25年数学难题

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具体用什么接口对接，这类任务大概率走的是同一个流程：

1. 定义问题：把“25年难题”翻译成验证器可处理的形式化语言，同时保留一份自然语言版本给模型。
2. 生成候选：把问题、可用公理、已有引理和当前反馈一起交给GPT-5.6，让它生成一段证明或证明骨架。
3. 格式转换：把模型输出的自然语言结构转换成验证器能读取的中间语言。如果模型已经输出验证器接受的结构，这一步可以省略。
4. 验证：Fable接收候选证明，逐条检查。如果通过，就保留；如果失败，返回错误信息。
5. 反馈循环：把错误信息翻译成模型更容易理解的提示词，回到第2步。重复直到通过或达到轮数上限。
6. 人工复核：机器验证通过后，由数学家确认形式化过程本身是否有问题、有没有遗漏条件。

这个流程像极了我们在开发里的“测试驱动”：先有一个失败用例，再写代码，跑测试，根据报错修改，直到测试通过。区别在于数学证明的“测试”严格得多，它不是抽样验证，而是每条规则都必须匹配。

注意：不要一上来就把候选生成数量、温度参数、验证轮数全部拉满。先用一条小引理跑通全流程，确认输入、输出和反馈都没有问题，再扩大到完整难题。

3.2 为什么验证器必须“慢”和“死板”

很多人会问：既然GPT-5.6已经很聪明，为什么不让它自己检查自己？原因很简单：同一个系统生成的推理，再由同一个系统检查，很容易出现“自我确认偏差”。尤其当模型已经预判了“这个结论应该成立”，它会倾向于忽视细节瑕疵。验证器这种工具虽然慢，而且要求每个步骤都显式匹配规则，但它不会因为“结论好像是对的”就放行。它的死板，是信任的基础。

在人工智能辅助科学研究的场景里，“独立性”是一个极其重要的原则。生成器和验证器不能是同一个模型的不同prompt，也不能共享同一个隐藏状态。否则训练出的“验证”很难不被生成的偏好污染。Fable在架构上的价值，就是扮演一个不依赖大模型判断的裁判。

3.3 一个最小可运行示例

下面给出一个伪代码，表示协作结构，而不是某个具体实现：

def solve_with_verifier(problem, verifier, generator, max_rounds=10): feedback = "" for i in range(max_rounds): candidate = generator.generate( problem=problem, feedback=feedback ) 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 验证一直失败时，按什么顺序排查

如果验证一直失败，不要先怀疑模型不够聪明。按下面的顺序排查：

1. 看现象：报错是语法错误、类型不匹配、步骤缺失，还是超时？
2. 看输入：自然语言问题是否完整？形式化规则库是否包含所有定义和引理？
3. 看中间层：模型输出是否被正确翻译成验证器输入？有没有丢失括号、合并了不该合并的表达式？
4. 看参数：模型温度是否过高，导致候选越来越发散？候选数量是否太少？验证超时设置是否过短？
5. 看环境：验证器版本、依赖库、公理库是否一致？有没有缓存了旧结果？
6. 最后才判断是不是模型能力边界：有没有给足反馈？有没有把问题拆分到足够小的子问题？

这个排查顺序的核心思想，是从“离问题最近、最容易出现细节错误”的环节开始检查，而不是一上来就否定整个方案。大部分“验证一直失败”的问题，最后都出在输入格式、规则库或反馈翻译上，而不是模型本身。

5. 这套协作方式能用到哪些场景，边界又在哪里

5.1 适合规则明确、结果可验证、目标单一的场景

这套“生成+验证”的工作流，最适配那些有明确规则和验证手段的领域。数学证明是最经典的例子；除此之外，算法正确性、智能合约安全、协议验证、编译器优化验证，都属于同类结构。在这些场景里，我们可以用一个严格工具做裁判，模型做参赛者。只要裁判规则没写错，最终输出就在逻辑上可靠。

对开发者来说，这类场景的特征是可以列出“通过条件”。比如“快速排序的结果是有序的，并且是原数组的一个排列”，这个条件可以形式化。模型负责生成实现，验证器负责检查性质。只要性质写得准，AI提供方案、验证器提供质量保障，这套组合就能真正用起来。

5.2 不适合标准缺失、需要价值判断、目标模糊的场景

反过来，如果一个问题没有严格验证标准，比如“这篇文章是否有深度”“这个产品能否成功”“这个需求是否合理”，验证器很难定义规则。即使强行套一个打分模型，也只能代表某种偏好，不具备数学证明那种普遍性。所以，这套体系不会取代人的判断，它只会把人的判断放在更高层级：划定问题边界、建立规则库、决定什么算“通过”。

常常有人把“验证”误解为“人工检查”，但人工检查不具备可扩展性，也不够稳定。真正的验证器应该是一个独立的自动裁判。如果找不到自动裁判，那么“生成+验证”就只能退化成“生成+人工评审”，效果会大打折扣。

5.3 对普通开发者的启发：生成代码+测试的结构也是一样的

我们在日常开发里已经经常使用类似范式。代码生成模型负责写函数，编译器负责语法检查，单元测试负责行为验证。区别是编译器/测试的严格性不如形式化验证，但它与GPT-5.6+Fable的结构是同一套骨架。如果你正在使用AI辅助开发，值得记住的一点是：把“AI生成”和“独立校验”分开，不要让同一套系统既生产答案又评估答案。校验器可以是单测、CI、静态分析，也可以是代码评审工具。

这里的核心原则，不是“所有东西都必须形式化”，而是“应该有某个环节不属于生成模型，也不被生成模型的偏好影响”。哪怕只是一个简单的断言测试，只要它是独立的，就能在AI生成的代码上提供额外一层信任。

5.4 需要警惕的前置成本

这套方案的适用边界还包括成本。形式化问题定义成本高，验证器开发成本高，反馈翻译成本高。如果只是写一小段脚本、做一次性的内容生成，完全没必要引入这类流程。只有当结果需要长期复用、正式发布、高可靠性，或者需要持续维护时，才值得投入这些前置成本。

一个更现实的经验是：先从小规模、低成本的验证工具开始，而不是第一版就追求像Fable一样完整的验证器。即便是一个简单的“规则检查器”，只要能覆盖最核心的逻辑，也能给模型生成结果提供巨大的约束力。随着问题复杂化，再把检查器逐步加强。

6. 我的判断：以后衡量AI能力，标准会变成“能不能承担可验证的子任务”

6.1 新闻之外，真正的“基础设施”正在成形

回到GPT-5.6和Fable联手的新闻。我觉得它真正值得记住的，不是某个模型又跨越了一个里程碑，而是这种“生成+验证”的协作模式正在变成一种基础设施。以后评价一个模型强不强，或许不再只看排行榜分数，而是看它能不能稳定地承担一个“可验证的子任务”。模型负责输出，验证器负责兜底，人负责定义问题。

一个能够被验证器反复检查的模型，比一个偶尔给出惊艳答案但不可控的模型更有工程价值。原因很简单：工程系统的核心不是峰值能力，而是可预测性。你可以在一个可预测的系统上构建更复杂的结构，却很难在一个时好时坏的模型上堆叠更多功能。Fable这类验证器的存在，正是为了让“可预测性”成为可能。

6.2 如果你要从零开始试一次

如果你也想做类似尝试，不要急着找一道人类数学家25年没解决的问题。先挑一个小而完整的引理，准备一个能严格验证的工具，写一个反馈回路，然后让模型不断尝试。每一次失败都记下来，变成下一轮生成的历史信息。这个过程本身，比“解决难题”更有复用价值。

25年悬而未决的难题被机器辅助解决，已经很了不起。但更了不起的是，我们终于找到一种方式，让AI的想象力不至于变成不可控的幻觉。想象力负责打开门，验证器负责确认门后不是悬崖。这种组合，才是长期有效的进步方式。