Claude把费马大定理人工智能人工智能写成了1300万行代码

AI能写出答案，不等于你能放心交出去。让AI整理报表，文件很快就交回来了，还附着一句“已检查”。你不想重算一遍，但明天要拿这份表解释差异的人，是你。这才是普通人用AI的别扭之处：它省下了动手的时间，却没告诉你凭什么放心。9月4日，Anthropic公布：Claude用约11天完成费马大定理的形式化证明，写出约1300万行Lean代码。不是重新发现定理，而是把已有证明变成计算机能核验的形式。别急着问“数学都能做了，报表还用查吗”。这次成功背后的核验条件，你的工作未必有。

两类任务的核验强度不同，此图仅比较检查环节。不是一个聊天框，独自干完了这件事人写证明，会省略同行能补全的步骤；形式化则要把定义、前提和推导写清楚。因此，1300万行首先是核验工程的规模，不是发现了同等规模的新数学。官方披露，早期尝试也失败过：Agent失去对项目状态的掌握，协作失效。换用Prove2Me平台，把定理之间的依赖关系组织起来，Agent才更清楚下一步证明什么、哪些结果可以复用。项目还有数十个Agent协作，消耗约60亿输出token，使用内部研究模型。它不是一次普通聊天，也不能被当成订阅用户随手可复现的能力。所以，别拿这样的系统成果，责怪自己“连一张表都用不好AI”。你缺的可能不是提示词，而是配套的检查。

20元扣错订单，四项检查仍然全过为说明检查的边界，本文在9月6日用Python做了一个构造数据实验，不是Claude实测：四笔订单共300元，A103应退20元。先生成正确结果，再故意把这20元扣到A104上。

同一组构造数据：退款对象错配，总额不变，两笔订单净额出错。两版数据都通过了四项检查：订单数为4、编号集合一致、净额合计280元、没有负数。换一种查法：从原始退款单出发，按订单编号计算“支付额－退款额”，逐笔比对。错误版立刻露出两处差异：A103多20元，A104少20元。合计能查出少扣、多扣，却查不出扣给了谁。不是检查程序失灵，而是验收条件漏了对应关系。想复现，在Excel里建图中的支付表，另建“A103、20”的退款表。保留原表，再复制退款表把编号改成A104；分别按编号扣减，比较两版合计和逐笔结果即可。证明对了，还要确认没答错题报表检查不能等同于数学证明。这个小实验只说明：满足几项汇总条件，不能保证每笔记录都正确。Anthropic原文有个关键细节：除了用Lean检查证明，还用比较器确认，所证明的定理陈述与Mathlib中的费马大定理陈述相匹配。它不仅检查“推导成立吗”，还检查“证明的是原本那道题吗”。这不意味着Claude曾偷换命题，而是系统没有把对象一致当成理所当然。报表也一样。任务是“按订单扣对应退款”，验收就不能退化成“总额对上了”。否则，账面平了，具体订单却错了。假如这样的结果进入逐单结算，相关人员问的不会是“合计多少”，而是“为什么我这笔被扣了钱”。这是假设的业务后果，不是实验中发生的真实损失。源数据也要有依据：如果退款表最初就写错了对象，按编号计算仍会出错，必须回查原始凭证。检查不能替错误输入兜底。下次别只让AI“再检查一下”可以把要求写具体：“按订单编号匹配退款，列出每笔支付额、退款额和净额；另列重复编号、匹配失败和复算差异。不要仅凭合计一致就写检查通过。”再把一份故意有错的数据交给检查器。如果它抓不住已知错误，就别拿它验收正式文件。能抓住这一个，也不代表覆盖所有错误。这条新闻值得带回工作里的，不是“AI无所不能”，而是把核验也算进交付。否则，文件生成得再快，最后那个不敢点发送的人，还是你。你最近一次不敢直接交出AI结果，具体卡在哪一步？