&Truth入局自动化形式验证：AI写代码之后，谁来证明它没错？

编者按：“氛围编程”把写代码变成了聊天，可软件并不会因为生成得快就自动变对。真正缺的，是能证明它确实按预期工作的办法。WIRED这篇报道盯上的&Truth，想做的正是把形式验证从专家手里的手工活变成自动化工具。

从“能跑”到“可证明”

据WIRED报道，一家叫&Truth的新创公司挤进了自动化形式验证这条赛道。形式验证属于用数学手段证明软件行为符合规格的技术，它不走抽样测试的路子，而是尽量覆盖所有可能的输入与状态，去回答一个更苛刻的问题：这段程序在任何情况下都满足我们写下的要求吗？

它和普通测试的区别，好比“抽查几道题”对上“证明整本习题集的答案都对”。测试能揪出错误，却没法证明错误不存在；形式验证要的恰恰是后者。代价是过程极其磨人：工程师得先写出精确的形式化规格，再把代码转成数学模型，最后靠定理证明器或模型检查器把证明做完。业内常管这叫“pain in the ass”的数学，投入大、周期长，一般只在航空航天、芯片、操作系统这类对可靠性要求极高的领域才见得到。

“烦人的数学”为何突然重要

生成式AI正在改写软件开发的流程。vibe coding说的是开发者用自然语言讲清意图，让模型生成、修改代码，再照着运行结果和感觉继续迭代。编程门槛因此明显降低，原型速度也提上来了。可问题在于，AI生成的代码常常“看着对”：命名合理、结构完整、示例跑得通，边界条件、并发、权限或者异常处理上却可能埋着隐蔽缺陷。

代码产量一旦超过人工审查的能力，传统测试和代码评审就会卡住。自动化形式验证于是重新回到创业者和投资人的视线里：AI既然能写代码，能不能也帮忙写规格、生成证明、定位反例？验证要是足够便宜，它就有机会成为AI编程工具的“安全护栏”，而不只是少数专家才用得起的奢侈品。

&Truth切入的自动化难题

WIRED称&Truth正在参与这场竞赛。报道没有披露它的具体技术路线，但这条赛道要解决的核心痛点很清楚。第一是规格获取：多数开发者不熟悉形式化语言，怎么从自然语言需求或现有代码里半自动地提取出可验证的规格。第二是证明工程：自动定理证明仍离不开大量策略和领域知识，AI可以提出证明草稿，但必须由可信内核检查。第三是可用性：验证结果不能只是一堆逻辑公式，得转化成开发者看得懂的反例、告警和修复建议。

形式验证的真正价值，不是让所有软件都变成“零缺陷”，而是把关键假设显式化，让错误更早暴露。

这也正是&Truth这类初创公司的机会与风险所在。机会在于，AI编程越普及，验证需求越强；风险在于，形式验证本身门槛极高，客户教育成本大，且“自动”往往只能覆盖局部。产品若没法在真实工程里省下足够多的人工，就容易停在演示阶段。

别把“证明”变成新的幻觉

有一个悖论必须警惕：用AI生成证明，可能引入新的不可信环节。形式验证的基石是证明检查器只接受严格推导，只要内核可信，错误证明就过不了关。但规格本身可能写错，AI对需求的理解也可能跑偏。规格要是漏掉了关键安全属性，再漂亮的证明也只是证明了“错误的东西”。所以自动化验证工具得把规格审查、反例解释和人机协作放在同等重要的位置。

另一个限制是规模。大型系统状态空间爆炸，完整验证的成本极高。短期内更现实的路子，可能是对加密、权限、金融结算、智能合约、嵌入式控制等高风险模块做重点验证，再逐步扩到更大的代码库。对氛围编程来说，这意味着不必每次生成都跑完整证明，而是在关键提交和关键模块上设一道数学护栏。

结语

Truth参与的，其实是一场围绕软件可信度的基础设施比拼。编程不会因此变得没有门槛，测试和评审也照样不能省。可它摆出一个信号：AI把写代码的成本压得极低之后，证明代码正确所要花的代价，就会变成新的卡点。谁先把“烦人的数学”做成自动化、做成产品，谁就有机会定下下一代AI编程工具的可靠性标准。