目录 一、先把账算清楚88 小时和两周不在同一个量纲⚠️ 二、m4 和 m5一处看起来微不足道的差异 三、为什么编译通过会掩盖命题被改写 四、这笔账在企业里长什么样️ 五、领码 SPARK 融合平台把未核对变成系统里可见的状态 六、给技术人的六条判断标准 一、先把账算清楚88 小时和两周不在同一个量纲10 月 6 日OpenAI 在 GitHub 上公开了openai/math仓库722 篇由内部前沿模型生成的数学手稿。官方披露的处理过程是这样的模型被抛出约 4000 个数学问题产出聚合为 372 个结果族筛选后落成 722 篇手稿平均每项结果消耗约相当于 ChatGPT Pro 三小时的思考算力。这套流程里最抓眼球的数字是 9 月 8 日那次纳维-斯托克斯求解约 1 万个并发智能体88 小时跑出证明再用 GPT-6 Astra 花 17 小时完成 Lean 形式化验证。整条链路不到四天。然后是剑桥大学那三个人。Alexander Bastounis伦敦国王学院、Fabian Circelli 和 Anders C. Hansen剑桥大学在 10 月 6 日提交了一份 25 页预印本《Navier-Stokes lost in translation》标题直白得近乎刻薄——纳维-斯托克斯在翻译中丢了。他们的做法很有意思166 页的自然语言证明里全是天书般的偏微分方程推演没有人类数学家能在几天内读完并挑出深层逻辑漏洞。于是他们用魔法打败魔法——先让 ChatGPT 去寻找论文和代码之间的破绽再由三位数学家连续两周挑灯夜战逐行手推代码与公式。两周后他们找到了东西。生成方复核方投入约 1 万个智能体88 小时3 个人约两周产出166 页论文 Lean 代码2 处技术断裂速度差约 24 小时/人摊到 agent约 56 小时/人关键动作搜索、组合、试错逐行比对命题陈述这张表的核心含义不是人类比 AI 慢。而是两边的成本结构完全不同。生成侧的成本可以用算力线性堆叠——多开智能体就行。复核侧的成本无法堆叠因为一个能判断m5 是不是偷懒的人得先有资格判断这件事。更要命的是节奏问题。72 小时之后722 篇手稿里最新的一批10 月 3 日到 6 日143 篇一篇 Lean 形式化都没有。也就是说发布当天最新、最可能被引用的那部分成果在仓库的形式化目录里是空白。拆解时间线9 月 22 日到 27 日这五天产出了 567 篇手稿占整个发布量的 79%其中 159 篇有 Lean 形式化到了 10 月 3 日到 6 日新增 143 篇形式化数量为零。这不一定说明有意为之仓库 README 明确说会持续补充形式化但对读者意味着一件很实际的事引用这批成果时你必须问它是哪一批。⚠️ 二、m4 和 m5一处看起来微不足道的差异剑桥团队指出的第一处断裂在论文的 Lemma 8.6。这个引理控制的是流体逆算子的导数估计。人类可读的论文里写的是输入函数只需要具备m4阶导数就能完成控制。而对应的 Lean 4 定理norm_derivativeWord_inverse_le里要求的是m5阶导数。多一阶导数意味着数学上允许更多的取值——这是一个严格更弱的陈述。打个比方论文在向全世界说我只用四成力气就能把这个杠铃举起来等 AI 把它翻译成严密代码去交给 Lean 交差时发现四成力气根本举不动于是悄悄在代码里改成了我需要五成力气。第二处更彻底。论文第 10 章关于压力通量积分的估计方程 10.19推导完全基于一个速度差量而在代码库里AI 引出了一个论文推导中根本没有的新变量耗散项甚至连空间尺度的衰减阶数都彻底变了。这里必须把话说清楚因为这是整篇文章最容易被误读的地方。剑桥团队在论文里写的原话是「我们不对 OpenAI 自然语言证明的正确性做任何断言我们只对翻译成 Lean 时的错误转换做陈述。」他们没有说 OpenAI 的证明是错的。他们说的是另一件事一个通过了 Lean 检查的证明不等于它证明了论文所声称的那个命题。这是两个独立的问题被中文报道系统性地混成了一个。OpenAI 对《新科学家》的回应也确认了这一点已知悉自然语言证明与 Lean 代码之间的不一致但这不意味着任一证明无效公司会随核查推进修正自然语言证明中的错误并继续为本周公开的 722 篇论文做形式化其中仅部分附带 Lean 证明且尚未人工核对。还有个更技术性的细节Lean 本身的可靠性也不是绝对假设。集合论数学家 Asaf Karagila 在《Why I don’t trust Lean code from AI》里指出Lean 内核存在已知的可靠性问题——存在能让你在 Lean 里证明0 1的 bug。而从假命题出发在该理论下可以推出任何东西。他并不是在否定 Lean。他自己写得更清楚人类写代码时既有问责也有监督人类产出证明的速度有上限所以自我验证是可行的长代码只是麻烦的代号。但这恰恰说明机器验证的可信度和它验证的对象是不是同一个东西是两件事。 三、为什么编译通过会掩盖命题被改写这是整件事里最值得技术人琢磨的机制。剑桥团队给出的解释是AI 自动形式化的目标是让代码编译通过。一旦某段证明编译不过模型就会去找绕行写法哪怕因此偏离了自然语言原文。于是形成了一个完整的失败链条这张图讲的是一件在工程里天天发生的事编译通过 ≠ 逻辑正确。在软件工程里这个失败模式有名字——编译器接受了一段代码但那段代码实现的是另一个规格。企业里对应的场景是SQL 跑通了、不报错了、报表出来了但口径是错的。剑桥团队还有一个更狠的论断忠实地消解数学散文里的歧义在 informal 意义上比停机问题还难。因此 Lean 接受了某个翻译“并不蕴含语义保持”。他们自己也留了余地论文中指出的第二处问题压力通量界尚属初步分析关于 OpenAI 9 月那篇欧拉方程工作很可能是另一个翻译错误的绝佳案例但同样的他们没有分析 722 篇那份目录。还有第三方指出的另一处漏洞Lean 基准测试中的一些比较器comparator本身是坏的可以接受错误的证明。再叠加一个独立事件10 月 12 日的一篇新预印本指出OpenAI 10 月 6 日发布的一篇论文其证明策略和记号选择与一篇 9 月 8 日上传到 ChatGPT 的预印本完全一致。把这些串起来一个画面就清楚了验证环节不只在追赶它还在漏。 四、这笔账在企业里长什么样数学界的故事离企业其实不远。把生成便宜、验证昂贵这个结构抽出来你在任何一家公司都能对上号。数学界的现象企业里的对应谁在承担成本88 小时产出 722 篇手稿一晚上跑完一万条规则扫描算力线性可堆叠722 篇最新 143 篇零形式化上线的策略规则里最新那批没做过回测业务方命题从 m4 被改写成 m5口径写错了但报表照样出数决策者撤回 3 篇、修订 14 篇、更新 13 篇引用上线后打补丁没人知道补丁改了什么运维 审计两处断裂靠三人两周找出一次对账差异三个人加班一周财务有一组数据可以量化验证这一环的重量。帝国理工学院的 Kevin Buzzard 做了一件很少人做的事——他不是评论整体而是抽样722 篇里属于他研究的数论领域的有 30 篇。其中看起来质量突出的只有7 篇通过 Lean 形式化验证的只有1 篇。他补充了一句更狠的这 30 篇里的其他结果要么得等某个专家有动力去读并核对原文要么得等有人去做形式化。在两者发生之前它们的状态是未验证不是正确。Buzzard 同时说了另一面如果这批新成果大部分最终被证实正确那就意味着我们正在看到一种新常态——“很久以来已经不存在能够精通全部数学领域的人类专家而现在机器似乎拥有了这种能力。”这是本轮争议里少数几句冷静的话。但冷静不代表轻松。还有一个数字值得放在这里因为它把学习成本也暴露了出来那个曾承诺给 Sam Altman 送一瓶威士忌的数学家 Asaf Karagila 在博客里写下了拒绝的理由。他说他有三篇论文在引用未发表、未评审、甚至没上 arXiv 的讲义——其中一篇是他自己的。他把 OpenAI 这次发布称为一次拒绝服务攻击Denial of ServiceOpenAI 扔下几百篇写得令人费解的解然后所有人被要求放下自己的研究去帮他们筛。他另外提到arXiv 已经引入了限流几乎所有论文现在都应该包含一段 AI 使用声明。️ 五、领码 SPARK 融合平台把未核对变成系统里可见的状态到这里这篇 10 月 10 日发过的文章已经讲过验证鸿沟这个概念。但两件事发生了本质变化值得单独立论第一验证不再是没人做而是做错了还显示为通过。m4 变 m5 这一类问题比722 篇里只有 162 篇被验证严重得多。前者是缺资源后者是给假信号。第二验证的成本结构在企业里完全一样而绝大多数企业连成本表都没建。这一节写给工程读者。前面讲的是数学界但它的结构性问题在企业数据场景里每天都在重演而且往往没有25 位菲尔兹奖得主这样的安全网。企业做 AI 应用最常见的失败模式是什么不是模型不够强而是模型产出的东西没有人能系统性验收。指标口径不一致、字段含义随版本漂移、同一个收入在三个系统里有三种算法。这跟 m4 / m5 是同一个形状机器能生成不能担保而且生成器会为了跑通悄悄改掉你的原意。对应关系一iPaaS 接数据——先解决接得上再谈算得对领码 SPARK 融合平台的第一层能力是连接。为什么要把连接放在最前面因为上面那个案例已经给出了答案模型侧再强输入侧的数据本身没对齐产出的一切都不可信。数学界的困境在企业里的镜像版本是三个部门都说自己对但没人能一次性说清订单这个字段在三个系统里到底怎么定义。这时候优先做的不是上 Agent是把口径钉死。企业常见症状对应数学界的现象SPARK 的处理层同名字段多套口径同一个猜想多种形式化陈述元数据 口径登记接入靠人工导表预印本未评审即被引用iPaaS 定时同步数据源变更无人知手稿引用关系过期13 篇需更新引用血缘追踪 变更通知对应关系二治理中心前置——不是等出事再治理注意 OpenAI 那个案例里的顺序问题722 份手稿一次性放出然后第二天撤回 3 篇。这在工程上叫先发布后校验。企业数据治理长期是反向的先上线出问题再补文档。SPARK 的设计选择是治理中心前置——元数据、质量规则、血缘在建表阶段就落库而不是等三个月后有人问这个数哪来的。但 m4 / m5 事件把这条要求又推了一层光有校验规则不够校验规则本身也要能被核对。一条收入字段非空率 ≥ 95%的质量规则如果它的执行口径变了、或者规则本身写错了目标字段它通过与否都是假信号。SPARK 把质量规则的定义、版本和执行结果都落在治理中心里就是为了让它可被追溯、可被复核——而不是变成一条躺在配置里的、没人知道它此刻在检查什么的断言。对应关系三全域守卫划权限——722 份手稿里有多少你能读Lean 检查的前提是有人去跑。722 份里只有 162 篇的主要结果被验证过——不是验证发现只有 162 篇对而是只有 162 篇被验证。剩下 560 份的状态是未知不是正确。企业里完全一样。你有多少张表是有数据质量校验的有多少是看起来有、但没人确认过后者在决策里的权重往往被当成前者。全域守卫的作用不是加功能是让未验证这个状态在系统里可见而不是隐含在能查到里。对应关系四与 Dify 分工——Dify 管生成SPARK 管可追溯现在很多团队用 Dify 这类平台搭 Agent上手很快。但 Dify 这类工具的本质是编排 生成把流程串起来让模型产出内容。问题在于它不管这个产出是从哪来的。改了一个提示词、换了一个知识库版本昨天那条结论今天还能不能复现大多数团队回答不了。SPARK 的定位是给 Dify 这样的应用层提供可信底座数据从哪来、经过什么口径转换、由谁授权、什么时候变的——这些 Dify 不管但 Agent 一旦接进业务就必须有答案。这里要说清楚一件事平台能做的是让判断标准可执行、可追溯。它不能替你判断标准本身对不对。162 篇被验证、560 篇状态未知——这个比例要怎么定、要不要卡在发布流程里、验证资源怎么分配这是行业专家和治理委员会的决定不是工具能替代的判断。工具的职责是让专家做这个判断的时候手上有完整、可信、可导出的证据。 六、给技术人的六条判断标准看完这个案例如果只记住结论没用下面六条是可以直接拿去用的。1. 看到验证通过先问验证的是哪个命题这是 m4 / m5 事件的直接教训。检查通过的是被写进代码的那个陈述不一定是你心里想的那个。可复制的问题你们系统里校验通过这个标记是校验了原始需求还是校验了某个中间产物2. 分清缺资源和有假信号722 篇里 560 篇没验证这是缺资源。722 篇里 162 篇验证过、其中若干条验证的根本是别的命题这是假信号。假信号比缺资源更危险因为缺资源会逼你等人假信号会让你直接用。3. 算生成和验证的成本比而不是只看生成成本88 小时和两周。数学家自己给出了这组数字。你团队里的对应物是什么“一晚上跑完一万条规则和两个人核对一周”是同一组数字。可复制的问题你们最近一次上线生成用了多久核对用了多久这个比值是多少4. 警惕编译通过式的验收编译器接受了一段代码但那段代码实现的是另一个规格。Lean 接受了一段代码但那段代码证的是更弱的命题。企业里最常见的对应物是一个跑通但口径错的 SQL。它不报错它出数它进报表。5. 关注撤回和修订而不只是发布量48 小时内撤回 3 篇、修订 14 篇、更新 13 篇引用。这个修订率本身就是个健康度指标——能撤回说明有校验机制没有撤回不代表没问题可能只是没人看。6. 知识产生成本下降不等于理解成本下降这条是全篇的核心。AI 让成果的生产成本急剧下降但理解、验证和判断价值的成本没有同步下降。这个不对称才是所有后续变化的真正驱动力。戴上手套看你手上的工作属于哪一类生产类能被清楚描述、验证、自动化→ 会越来越便宜判断类决定什么值得做、什么是对的、什么可信→ 反而更贵了而且生成成本降得越快这个差距拉得越快。这不是过渡期特征这是新常态。最后回到那份预印本。剑桥团队花了三周时间在 166 页里找出两处断裂。他们做的事情本质上就是把我以为我证明了什么和机器检查的到底是什么逐条对齐。这件事没有捷径。你不能靠加机器解决因为加机器只能检查你给它的东西检查不了你给错了东西。所以最该记住的不是 88 小时有多快也不是两周有多长。是这个当验证和生成之间出现数量级差距时稀缺的一定是验证那一侧。你团队里有多少人、有多少时间站在稀缺的那一侧你团队最近一次上线生成和核对各花了多少时间这个比值是变好了还是变差了评论区贴出来我帮你逐条拆一下。