22% 还是 42%：同一个仓库，两个验证率

📋 目录

• 📊 一、三个数字，三个出处
• ⚠️ 二、22% 是怎么算出来的
• 🔍 三、42% 从哪来：36 小时里的变化
• 🧮 四、50% 又是谁说的
• 📉 五、被忽略的那道断崖：143 篇零形式化
• 🔗 六、比验证率更麻烦的一件事：这批手稿的引用链是断的
• 🏗️ 七、这件事对企业数据平台的启示
• 🎯 八、给技术人的六条判断标准

📊 一、三个数字，三个出处

如果你这几天在中文社交平台看到"722 篇 AI 数学手稿"的讨论，大概率会撞见这几个说法：

三个数字都有人引用。三个都不算编造。但它们说的不是同一件事。

这就是本文要解决的问题：这批手稿的形式化验证率不是一个数字，是一个随时间变化、需要标注口径的量。任何不带日期和分母的比例，单独拎出来引用都是在制造误导。

先把关键时间线摆出来，后面所有细节都挂在这上面：

看这张表就能明白：22% 和 42% 之间相差的 20 个百分点，绝大部分不是"新验证了 138 篇"，而是分母和分子同时动了。

⚠️ 二、22% 是怎么算出来的

先看最基础的那个数字：22.4%。

这个数的来源是一次真正的仓库审计，不是转述。审计方法很直接：openai/math仓库里有两个文件可以对账——CONTENTS.md是手稿地图，每篇论文都指向自己的目录；从lean/formalization.yaml里抽出所有条目，得到"有形式化证明的论文"清单。

两边逐条对齐的结果是：

• 从CONTENTS.md抽出722个唯一手稿目录，与官方宣称的 722 完全吻合。
• 从formalization.yaml抽出162个唯一目录，全部能在手稿地图里找到，没有孤儿条目。
• 162 / 722 =22.4%。

关键结论不是这个百分比，而是剩下那 560 篇是什么状态：不是"验证发现只有 162 篇对"，而是只有 162 篇被验证。剩下 560 篇的状态是"未知"。

OpenAI 自己的 README 也承认了这一点，写得很直白：许多（但不是全部）手稿有形式化，「一些未形式化的结果可能存在问题」。

这句自我保留，比任何外部质疑都更有分量。它等于官方承认：722 这个数字里，混着不同成熟度的东西。

不过这个审计里还有一处细节值得单独拎出来，因为它揭示了"分母"这件事有多麻烦：

722 个目录里，721 个在文件夹名里编了日期（格式是...-September-23-2026）。剩下那一个没有日期。所以任何按日期分组统计的审计，都必须先决定：没有日期的那一篇算哪一批？

这不是个无关紧要的细节。下一节就会看到，它直接决定了一个"断崖"结论的形状。

🔍 三、42% 从哪来：36 小时里的变化

第二个数字来自仓库自己的变更日志（history.md）。Retraction Watch 报道里引用了这行：

300 / 719 = ~42%

注意分子分母都变了：分母从 722 降到 719（撤回 3 篇），分子从 162 涨到 300。

分子的增长来自哪里？变更日志记录的过程是：撤回 3 篇、修订若干、更新引用若干，另外新增了 6 项 Lean 形式化。研究者 Dan Roberts 在 X 上把这批变更总结成一句话：「6 new Lean formalizations, 19 modifications, and 3 withdrawals」。

这里出现了一个很有意思的细节，Retraction Watch 也点出来了：公开说明里并没有讲清这 19 处修改与变更日志里的 14 篇证明修订 + 13 篇引用更新是什么对应关系。14 + 13 = 27，而被公开概述的是 19。数字对不上。

不过这不是最要紧的问题。最要紧的是：162 到 300 这 138 的增量，不可能全部来自"新验证了 138 篇"。

一份公开的、有据可查的解释是"新增 6 项形式化"。6 项 ≠ 138 项。

那剩下的差额从哪来？这里必须承认一个事实：关于 300 这个数字的完整构成，公开材料里没有给出可核对的逐条明细。Retraction Watch 的报道明确写了一句：公开说明没有讲清变更如何映射。

所以本文在这里划一条线：

“42%” 是一个引用了仓库变更日志的口径，它的分子构成没有被公开逐条披露。引用它时请注明这是"变更日志口径"，不要与 22% 并列成"验证率提高了"。

这不是吹毛求疵。这恰恰是本栏目的价值所在——区分"仓库自己写的数字"和"我们根据仓库算出来的数字"。前者是二手权威（但仍需注明出处），后者是一手可复核。

按发布日期把仓库拆开看，另一组数字更直观。变更日志和形式化目录叠加起来是这样：

两天占 567 篇、159 篇有形式化；四天占 143 篇、零篇有形式化。

🧮 四、50% 又是谁说的

第三个数字来自 OpenAI 发言人对 Retraction Watch 说的话：“roughly 50%” 的结果是在未经验证的状态下发布的。

这句话本身是坦率的，值得肯定——很多机构不会主动说"我们有一半没验"。

但问题在于，它跟仓库自身的数字对不上。

Retraction Watch 的报道做了一道很简单的算术：按变更日志的 “300 / 719”，未形式化比例是58%。发言人说的是"大约 50%"。

58% 和 50% 差了 8 个百分点。

报道的结论很克制也很准：这个数字"与仓库自身数字算出来的结果不匹配"，所以报道以仓库数字为准。

这类"发言人口径 vs 仓库口径"的偏差，在企业场景里天天发生。销售说"性能提升 50%“，压测报告写的是"在特定负载下提升 47.3%，且不含网络开销”——两边都没说谎，但决策依据已经不一样了。

所以把这三个数字放在一起，正确的读法是这样的：

三张卡片都是真的，三张卡片都不能单独引用。

📉 五、被忽略的那道断崖：143 篇零形式化

前面说过，722 个目录里 721 个带日期。这是一个技术细节，但它带出一个值得单独讨论的发现。

按日期分组后有一个非常干净的模式：9 月下旬那批 567 篇里有 159 篇形式化（28%），而 10 月 3 日到 6 日新增的 143 篇里一篇都没有。

其中 112 篇集中在 10 月 5 日一天。

对这个分布有两种读法。

第一种读法（无害）：形式化滞后于写作。仓库 README 本来就承诺"会继续补充 Lean 形式化"，所以最新的一批没验过完全正常。

第二种读法（需要警惕）：一个批次的验证流水线已经跑完并结束之后，又有五分之一的内容被加进来，并在发布日当天一并放出。两种读法都与现有数据相容——但只有第二种与"发布时机"相容。

跟上一篇那期（88 小时 vs 两周）里提到的剑桥团队工作对照看，这道断崖更刺眼。因为剑桥三人组的工作揭示了另一层：形式化本身可能漏掉最关键的环节。Lean 编译通过，不等于验的是原命题。

这就构成一个双重风险：

也就是说："等它补上形式化再看"这个策略，前提是形式化本身可靠。而 m+4 / m+5 事件说明这个前提不成立。

所以最稳妥的读法是：对于 10 月 3 日到 6 日那批 143 篇，任何人引用时都要额外说明——这些结果既没有机器验证，也没有人工复核。

🔗 六、比验证率更麻烦的一件事：这批手稿的引用链是断的

这一节要说的问题，已经不在"验没验"的层面，而在"这批东西到底从哪来"。

形式化验证率至少还有个分母可以数。但溯源问题连数都数不了。

先看一个已被广泛引用的事实。OpenAI 在仓库里公布了：模型尝试解决约 4000 个问题，平均每项结果消耗约相当于 ChatGPT Pro 三小时的思考算力，并公开了10 个模型推理过程的摘要。注意是 10 个——722 篇手稿里只有 10 篇附带了推理过程说明。

这本身是透明度的加分项。但接着发生了两件事。

第一件：引用链在 ChatGPT 里断掉了。

10 月 12 日的一篇新预印本指出，OpenAI 10 月 6 日发布的一篇论文，其证明策略和记号选择，与一篇 9 月 8 日上传到 ChatGPT 的预印本完全一致。原作者本人的表述是：该结果"也包含在 OpenAI 于 10 月 6 日发布的论文中"。

这件事的严重性不在于"AI 抄了"——而在于它无法被独立判断。因为 OpenAI 用的内部模型从未公开，第三方既不能复现这个模型，也无法确认训练数据里到底有没有那 9 月 8 日的对话。

第二件：审稿人和读者拿不到评估所需的东西。

集合论数学家 Asaf Karagila 拒绝复核 OpenAI 那篇"分割原理不蕴含选择公理"的手稿，理由之一是论文引用了至少三篇未发表、未评审、甚至没上 arXiv 的讲义，其中一篇是他自己的。他还提出了一个很具体的要求：既然成果来源无法追溯，那么判断"作者贡献"的标准就必须变——是否要求把 chat log 公开，或者至少提供给审稿人和编辑？他提到 arXiv 已经引入限流，几乎所有论文现在都应该包含一段 AI 使用声明。

这不只是一个人的做法。剑桥大学那篇预印本还指出了另一处：Lean 基准测试里用到的部分比较器（comparator）本身是坏的，可以接受错误的证明。

把这些串起来，就得到一个比验证率更麻烦的结论：

三条断链：模型不可复现 → 过程不可见；形式化可能漏项 → 结论不可靠；引用不规范 → 归属不可判。

这解释了为什么这批手稿让评审体系失灵：同行评审的全部机制都建立在"作者能回答关于自己工作的问题"这个前提上。而一个由模型批量生成、发布方不打算回答具体技术问题的产出，评审这个动作本身失效了。

西北大学的 Bryna Kra 把话说得很直接：结果总体"惊人"，但"写作方式让人无法理解"，数万页成果亟待核验，“而在这个过程里，同行评审却缺位了”。

所以引用这批手稿时，除了上一期说的"验证率要带日期和分母"，还得多加一条：

问一句"这个结论的来源能追溯到哪"。追溯不到的，无论验证率多高，都只能当线索，不能当依据。

🏗️ 七、这件事对企业数据平台的启示

这一节写给工程读者。

先说一个直接对应："验证率"是企业里最常被引用、也最常被误用的一个指标。

你可以在任何一个公司的数据看板、OKR 汇报、周会上找到这三个数字的变体：

这些和 22% / 42% / 50% 是同一个问题：一个比例离开了它的分母、时点和口径，就变成了一个可以随便用的数字。

对应关系一：iPaaS 接数据——接入数不是可用数

SPARK 的第一层是连接能力。但"接得上"和"接得对"是两件事，而很多团队在汇报里把它们混成一个数字。

数学界这个案例给的启示很具体：722 篇手稿的 722 是产出数，不是可信数。对应到企业里，一个数据源"接进来了"只说明管道通了，不说明字段口径对。

对应关系二：治理中心前置——把"什么时候验的"记下来

22% 变 42% 这件事，暴露了一个系统性问题：验证状态是会变的，而大多数系统只记录当前状态，不记录状态的变化历史。

SPARK 的治理中心前置，落点不只是"在建表阶段就落质量规则"（上一期讲过），这次要强调的是时间维度：

• 质量规则的定义版本要留痕——改了目标字段的规则，等于换了校验对象
• 每条规则的最近执行时间要可见——上周验过的和今天的不是同一件事
• 未覆盖和已覆盖且通过必须是两种状态，不能都显示成绿

这一条直接对应那 143 篇。它们的准确标签是"未覆盖"，而不是"通过"。

对应关系三：全域守卫划权限——验证资源也是要划权限的

Lean 检查的前提是有人去跑。数学界现在的稀缺资源是形式化验证的产能——不是每个数学家都能做 Lean 形式化，这是专门的技能和专门的人。

企业里同构的稀缺资源是：知道某个字段口径到底是什么的人。这个人在不在、什么时候在、有没有空，直接决定了你的数据能不能被信任。

全域守卫在这里的作用不是限制访问，而是让验证责任落到具体的人头上，并让这个分配状态可见。一个字段如果挂在一个没有明确责任人的质量规则下，它的可信度就只存在于"看起来有"。

对应关系四：与 Dify 分工——Dify 管生成，SPARK 管可追溯

Dify 这类工具的本质是编排 + 生成：把流程串起来，让模型产出内容。它不管"这个产出是从哪来的"。

而在这一期的主题下，这一点尤其要紧：一个数字从产出到被引用，中间经过了哪些变换、每次变换有没有被校验过——这条链路必须存在，而且必须能查。

SPARK 的定位是给 Dify 这样的应用层提供可信底座：数据从哪来、经过什么口径转换、由谁授权、什么时候变的。这些 Dify 不管，但 Agent 一旦接进业务就必须有答案。

这里要说清楚一件事：平台能做的，是让口径可执行、可追溯。它不能替你判断"22% 算高了还是算低了"这个标准本身对不对。验证率要卡在多少、哪些字段必须过人工复核——这是行业专家和治理委员会的决定，不是工具能替代的判断。

工具的职责是：让专家做这个判断的时候，手上有完整、可信、可导出的证据。

🎯 八、给技术人的六条判断标准

1. 引用任何比例之前，先问三个问题

分子是什么？分母是什么？哪一天？

22.4% 的分子是"有 Lean 形式化的手稿目录"，分母是 722，日期是 10 月 7 日。三个都变了，数字就变了。

可复制的问题：你们周报里那个百分比，分子分母分别是什么？上周和这周的分母一样吗？

2. 区分"已验证"和"验证通过"

这是 m+4 / m+5 那期的核心，也是这期的核心。722 篇里 162 篇被验证过，这 162 篇里又有多少验证的是原命题——这是两个独立的问题，不能合并。

已验证= 有人去跑了。
验证通过= 跑出来的结果和你的原始需求对得上。

3. 看修订率，不只看发布量

722 → 719（撤 3）、修订 14、更新引用 13。这个修订率本身就是个健康度指标——能撤回说明有校验机制，没有撤回不代表没问题，可能只是没人看。

而且要看修订的时间跨度：48 小时内撤回 3 篇，和一个月后慢慢修 20 篇，是两种状态。

4. 警惕"未验证"被当成"正确"

最常见的误用。剩 560 篇的状态是未知，不是正确。企业里一样：接口能通不代表字段对，上线通过不代表验收过。

未验证是一个需要被单独标注的状态，不是"没问题"的默认状态。

5. 数字会变，所以结论要带时间戳

这条看起来像常识，但在实际引用里最常被忽略。

仓库 README 自己写着"会继续更新这个仓库的形式化"。也就是说22.4% 是一个注定过期的数字。你今天写下"只有 22% 通过验证"，下周它就是错的。

6. 追溯不到的，只能当线索，不能当依据

这一期新增的一条，也是最容易被跳过的。

722 篇手稿只公开了 10 篇的推理过程摘要，模型本身没公开，引用里还混着未评审的讲义。这三条加起来意味着：你没法判断某个结果是从哪来的。

企业里的对应物是：一份报表里的数字，如果没人说得清它的取数逻辑、变换过程和引用来源，那它即使通过了所有校验规则，也只能当线索。

可复制的问题：你手上正在用的那个关键指标，能不能在三分钟内说清它从哪个源表、经过哪几步变换来的？

可复制的问题：你们的看板、汇报和文档里，有多少数字是"自动更新"的，有多少是"当时记下来"的？后者有没有标注统计时点？

最后回到那 143 篇。

这批手稿发布在 10 月 6 日，零形式化。三个月后、半年后，它们大概率会被补上形式化，形式化比例会涨到一个漂亮得多的数字。

到那时候，再回头看今天流传的"只有 22% 通过验证"，你会发现这句话在描述一个已经过期的快照。

所以这期文章真正想留下的，不是"哪个数字对"，而是这个习惯：

引用一个比例的时候，把它的时间点、分母、和"谁在什么口径下算的"一起写出来。否则你引用的不是数据，是传闻。

你最近引用过的某个百分比，能立刻补上它的分子、分母和统计日期吗？评论区贴一条，我帮你一起核。