绝大多数团队给 AI 产出加验收时，做的是同一件事：再让一个模型看一遍。Lean 团队这两周给出的答案不一样——既然判定“对不对”的那把尺子自己也会被找到毛病，那就再做几把独立的尺子，让它们互相量。
一次把自己当成目标的审查
Lean 是一个证明助手：你把一个数学命题和它的证明写成代码，内核负责检查这个证明是否真的成立。内核是整件事的地基，它说通过，结论就算成立。
10 月 15 日，Lean 项目负责人 Leonardo de Moura 发了一份公告，第一句就很不客气：AI 智能体非常擅长找软件缺陷，Lean 证明助手的内核也在其中，两次复盘分别挂在 8 月 1 日和 8 月 24 日。他没有在公告里重述那两篇复盘的具体内容，所以不宜从这份公告推断缺陷细节。
这件事值得停一下的地方在于它的方向。过去两年大家习惯的是“用 AI 找别人代码里的问题”，这里发生的是“AI 找到了用来判定对错的那件工具本身的问题”。工具出问题的影响面和一段业务代码出问题不一样：一段代码错了，错一处；判定工具错了，它放行的所有结论都要重新想一遍。
修好不够，再做几把独立的尺子
Lean v4.35.0 的做法分两层。第一层是给所有人一个重检入口：新的 lake check 命令把整个工程导出，用 leanchecker——剥离掉周边包袱的官方内核——在沙箱里重新查一遍，沙箱可以用 –inadvisably-no-sandbox 关掉。第二层是随发行版附带四个额外内核：nanoda、lean4lean、con-leche 与 con-ron，用 lake check –paranoid 可以全部跑一遍。这个模式还会额外跑一个用加固内存分配器构建的官方内核变体，把内存损坏变成一次可检查的中止，而不是静默给出一个错误答案。
第二层里最值得看的是 con-leche。它是第一个用 Lean 本身写成、并且被证明一致的 Lean 内核，由 Claude（Fable 与 Opus）在 Lean FRO 的 Joachim Breitner 重度监督下实现并完成证明。这里的“一致”有明确定义：con-leche 接受的每一个环境都在集合论中有一个模型，遵循 Mario Carneiro 对 Lean 类型论给出的模型；证明本身由官方内核检查，并且假设所用集合论是一致的。
这条路径消掉的是一整类缺陷：内核实现里的编程错误。它甚至没有性能代价——在完整的 Mathlib 导出上，con-leche 执行官方内核 0.69 倍的指令数，八线程约 100 秒查完整个库。
但 con-leche 自己并不无敌。既然它有了一致性证明，剩下可能存在的不可靠缺陷最可能在用来构建它的编译器与运行时，包括大数库。于是 Breitner 用 AI 把 con-leche 翻译成 Rust，再用 Aeneas——一个用 Lean 验证 Rust 代码的工具——证明这个 Rust 版本细化了 con-leche 的检查算法，成品叫 con-ron。公告的论证说得很直白：同一个缺陷同时存在于 Rust 的编译器与运行时的可能性很低，两把尺子一起量，对这一整类缺陷就有很高的防护。
这里真正可搬运的不是“形式化证明”这个技术，而是那句论证结构：先把一类错误用证明彻底消掉，再看剩下那类错误最可能藏在哪里，然后换一套不共享该依赖的实现来压它。每一步都明确回答“这一把尺子还可能在哪儿错”。
反面：也有人选择考人
同一周的 Hacker News 上另有一个小工具走了相反的路。Sphinx 是一个 git 钩子，在受保护分支上拦住推送，读这次改动生成一道场景题，要提交的人回答这个改动在出错时会怎样；答错就讲一遍原因再换一题，答对才放行。官方给的例子是一个 Stripe webhook 处理器：先存事件 ID 再调 charge()，重试会怎样。多数人第一反应是重复扣款，实际是反过来的——已存的 ID 会让重试直接返回成功，于是扣款失败时客户永远不会被收费。
它有一个设计细节比考题本身更值得记：出题的评审方没有看过你跟编码智能体的对话记录，只读改动；你的回答也不会回传给写代码那个智能体，.env 与密钥不会被打开。也就是说，出题者和执行者被刻意隔开了。另有 sphinx yolo 可以跳过，但每次跳过都会留记录。HN 上的反应并不热，讨论里最尖的批评落在那句标语上——“外包你的思考，但别外包你的理解”。
两条路放在一起看更清楚：Lean 选择加机器，Sphinx 选择考人。前者能规模化但代价是再跑一遍完整检查，后者便宜但依赖人真的懂，而且可以被跳过。它们共同的前提是一致的——判定必须由不参与产出的那一方来做。
搬到施工企业：审图意见要过第二把尺
把这套结构搬进施工企业的方案审查，触发点很具体。现在不少项目已经在用智能体预审专项施工方案：把规范条文、项目条件、图纸参数喂进去，出一张问题清单，专业工程师复核后签字。清单确实有用，但复核这一环有个不易察觉的漏洞——复核的人拿的是同一套检索库、同一版台账、同一份规范条文切分，本质上是让同一把尺子量第二遍。人会累，而且读第二遍的注意力天然比第一遍低。
Lean 那套做法给出的关系是：判定不能依赖单一实现，第二把尺子必须是独立实现，不是同一实现的第二次运行。落到方案审查上，第一把尺是模型按规范与项目条件出的意见；第二把尺应该是不跑模型的那一路——把规范里可判定的部分（尺寸限值、构造要求、荷载组合、稳定性系数的算式）写成可执行规则，由程序直接读台账与图纸属性算出来。
关键约束跟着就来了：两把尺不能共用同一份中间数据。Lean 那边特意用 Rust 运行时替换 Lean 运行时，就是为了切断共享依赖；企业这边对应的要求是，第二把尺不能读第一把尺生成的摘要或结论，要直接读结构化台账与图纸属性。如果第二把尺还是去读同一份检索结果，那就只是多问了一次模型。
分歧的处理比结论更重要。Lean 请使用者把内核之间的分歧报到指定邮箱，等于把“两把尺不一致”当成一个要收集的信号。企业里可以照做：两把尺结论不一致的条目单独成表，每条都要有人工裁定和裁定理由，按季度回看。这张表真正的用途不是纠错，而是暴露规则本身哪里定义得含糊——就像内核分歧暴露的是内核的缺陷。
第二把尺不是装上就有用。它有三条成立条件，缺任何一条都会退化成又一次重复阅读。
必须重做的部分也得说清。规范条文的切分不能沿用给模型用的那一份，要按“能不能写成判定式”重新切一遍；专业工程师的角色从“复核清单”变成“裁定分歧”，工作量的结构会变，前几轮很可能更慢而不是更快。这两条不做，第二把尺会退化成一次重复的阅读。
规模这一关迟早会来
Lean 的公告里有一处容易被忽略，却是这套做法真正的边界。它列举了几个项目的体量：Anthropic 的 FLT 超过 1300 万行，Mathlib 250 万行，Tau Ceti 已超 300 万行且还在快速涨，General Courtade–Kumar 定理仓库超过 5000 万行，社区已经在写 10 亿行级数学库的提案。公告说得很直接，当前这种导出后整体重检的做法撑不到这个量级，需要二进制导出格式和增量检查；这两项目前都还在做。
企业这边会遇到同一个形状的问题。第二把尺在项目初期很轻，因为规则少、台账小；等到规则积累到几百条、台账覆盖几十个项目，全量重检一次的开销就会逼着你做取舍——要么只查改动部分，要么把重检排到夜间。查改动部分这一步尤其危险：它等于重新引入了“这把尺子看不全”的假设，而 Lean 恰恰是因为看不全才加的尺子。所以增量检查本身也要有登记：哪些部分这一轮没被两把尺同时量过，得能查出来。
这也提醒一件事的顺序别做反。先把两把尺在什么条件下算一致定义清楚，再谈提速；反过来先上增量、后补一致性，等于把省下来的时间又花回解释分歧上。
两个可以先做的小试验
第一个试验只测分歧率，不急着上系统。找三十份已经审过的专项施工方案，只挑规范里可量化的条目——立杆间距、扫地杆高度、剪刀撑角度、荷载取值这类——用一段规则脚本跑一遍，跟当初智能体给出的清单对照，统计两把尺不一致的条目有多少、其中多少是真问题。这个数字决定了第二把尺值不值得建。
第二个试验是给判定规则标版本号与生效日期，规范改版或台账字段变更都留一条记录，同时开始积累分歧表。跑三个月后回看分歧集中在哪几条规则上，那几条就是最该先写清楚的地方。
来源与说明
[1]: Lean Now Ships with Verified Kernels —— Leonardo de Moura（Lean 项目负责人） / 2026-10-15 (https://leodemoura.github.io/blog/2026-10-15-lean-now-ships-with-verified-kernels/) [2]: Lean v4.35.0 adds sandboxed proof checks and four kernels —— Linxi News / 2026-10-16 (https://news.linxi.com.au/news/lean-adds-independent-kernel-checks-in-v4350) [3]: Lean Now Ships With Verified Kernels（逐条限定官方声明边界） —— Do My Stats / 2026-10-16 (https://domystats.com/software-qa-development/lean-now-ships-with-verified-kernels) [4]: Lean now ships with four extra kernels, one proven consistent by Claude —— Hacker News（121 分） / 2026-10-18 (https://zeli.app/story/50114758) [5]: Show HN: Sphinx – a hook that quizzes you on your AI’s code before shipping —— Hacker News（100 分） / 2026-10-18 (https://hn.today/s/show-hn-sphinx-a-hook-that-quizzes-you-on-your-ais-code-before-shipping) [6]: Sphinx Git hook quizzes developers on agent code before push —— LavX News / 2026-10-18 (https://news.lavx.hu/article/sphinx-git-hook-quizzes-developers-on-agent-code-before-push) [7]: Sphinx: A Git Hook That Quizzes You on Your AI’s Code Before You Ship —— Global AI News / 2026-10-18 (https://www.ai.jp.net/article/sphinx-a-git-hook-that-quizzes-you-on-your-ai-s-code-before-you-ship-2e535b?lang=zh) [8]: What Developers Think About AI Coding Agents（含 Sphinx 与 vibe coding 定义的讨论） —— TerminalBlog / 2026-10-18 (https://terminalblog.com/blog/what-developers-think-ai-coding-agents-hn-oct2026) [9]: Hacker News 当日过 50 分条目汇总（Lean 内核 121 分、Sphinx 100 分） —— crosswalk / 2026-10-18 (https://crosswalk.to/crosswalk/hn-news) [10]: Hacker News Digest · October 18, 2026 —— Zeli / 2026-10-18 (https://zeli.app/digest/2026-10-18)
检索截止：2026-10-19 05:55（Asia/Shanghai）。Lean 的性能与一致性声明均出自官方公告，已按其原文限定边界；Sphinx 为开源小工具，社区反应来自 Hacker News 讨论；施工企业的两个试验为本文设想，未实施。