Anthropic的Frontier Red Team与形式化方法合作伙伴Theorem表示，他们使用Claude为123个开源库的239个模糊测试入口生成了经机器校验的证明。证明针对的是特定编译后的RISC-V程序，并且只在明确列出的条件下成立；它并没有证明这些库在所有版本、配置和使用场景中都没有漏洞。95

这项工作的规模引人注目：团队称，项目历时数周，产出了约1.8亿行Rocq证明代码。更值得关注的，是AI或许能帮助把形式化验证应用到更多真实软件中；但证明能说明什么，仍取决于研究者具体写下并验证了什么。313

证明了什么？

Anthropic称，在规定假设下，对于所有小于64 MB的输入，以及模型所覆盖的Linux系统响应和内存布局，相关程序都能正常退出，不会触发内存安全错误或断言失败。验证对象是编译后的RISC-V程序，而不是对每个库的所有版本、功能和部署环境作出笼统保证。912

研究团队将Google的OSS-Fuzz项目中已有的模糊测试入口转化为形式化规格。模糊测试会尝试大量输入，寻找程序可能出错的情况；形式化证明则试图证明，某个明确写出的性质对规格覆盖范围内的所有输入都成立。313

Anthropic将这项工作描述为首次大规模借助AI，在汇编层面对生产软件进行形式化验证。这是研究团队对项目新颖性的说法，并非已经独立确立的历史共识。713

Rocq校验提供了什么保障？

Claude负责生成证明，Rocq证明内核负责检查证明是否成立。因此，机械校验并不要求开发者相信Claude的推理，也不需要逐行人工审阅全部证明代码。但这不代表所有前提都无需信任：定理必须准确表达开发者关心的性质，形式化模型和校验器本身也属于证明所依赖的基础。95

Anthropic及相关报道将证明代码总量估为约1.8亿行，平均每个二进制文件约60万行。庞大的代码量体现了这项工作的规模，但行数本身不能说明一个性质适用范围有多广，也不能证明它完全符合某个项目的实际需求。312

测试之外，形式化证明能补上什么？

模糊测试可以尝试大量输入，却无法单凭测试证明某个范围内的每一种输入都安全。有关这项工作的报道说，Claude在验证过程中发现并修复了数百个漏洞，其中包括曾逃过数万亿次模糊测试运行的问题。这些数字是对本项目成果的报道，并不能直接说明形式化验证在其他项目中会以同样方式胜过测试。211

更稳妥的理解是：形式化证明与测试提供的是不同类型的证据。对于已明确说明的性质和范围，证明可以覆盖符合规格的全部输入；测试则验证实际运行过的那些情形。前者并不意味着后者可以省略。92

为什么“已验证”不等于“没有漏洞”？

首先，保证只针对选定的测试入口和特定编译产物，不会自动延伸到库里的每个功能、每种构建配置、其他处理器架构或所有使用方式。95

其次，运行条件很关键。相关报道描述的证明针对单线程、静态编译的RISC-V二进制程序，并假定其在有固定内存预算的Linux模型中运行。实际部署的软件可能采用其他架构或配置，因此不能把这项结果直接当作那些版本的安全保证。122734

最后，证明只能确立定理中写明的内容，而不是开发者可能关心的所有性质。未纳入证明范围的问题仍可能存在；形式化模型或证明校验基础中的错误，也会影响结论的可信度。531

开发者可以如何看待这项成果？

这项工作的核心意义在于，它显示AI辅助或许能让汇编层面的形式化验证扩展到更多真实软件，而不必完全依靠大量专家手工完成。不过，这并不能推出一个适用于所有代码库的成本估算，也不能保证该方法在任何项目上都能成功。713

目前公开的证明只是项目成果的一部分。一份报道说，公开部分覆盖25个库和60个测试入口，并非全部成果；Theorem也宣布推出面向开源维护者的OSS Verify计划。321638

对开发者而言，实际做法是逐项核对证明覆盖的入口、编译产物、假设条件和具体性质，再决定能否依赖它。Claude的成果让LLM辅助形式化验证值得与测试一并评估，但不是停止测试或认定软件已经无漏洞的理由。95

Anthropic的Frontier Red Team与形式化方法合作伙伴Theorem表示，他们使用Claude为123个开源库的239个模糊测试入口生成了经机器校验的证明。证明针对的是特定编译后的RISC-V程序，并且只在明确列出的条件下成立；它并没有证明这些库在所有版本、配置和使用场景中都没有漏洞。95

这项工作的规模引人注目：团队称，项目历时数周，产出了约1.8亿行Rocq证明代码。更值得关注的，是AI或许能帮助把形式化验证应用到更多真实软件中；但证明能说明什么，仍取决于研究者具体写下并验证了什么。313

证明了什么？

Anthropic称，在规定假设下，对于所有小于64 MB的输入，以及模型所覆盖的Linux系统响应和内存布局，相关程序都能正常退出，不会触发内存安全错误或断言失败。验证对象是编译后的RISC-V程序，而不是对每个库的所有版本、功能和部署环境作出笼统保证。912

研究团队将Google的OSS-Fuzz项目中已有的模糊测试入口转化为形式化规格。模糊测试会尝试大量输入，寻找程序可能出错的情况；形式化证明则试图证明，某个明确写出的性质对规格覆盖范围内的所有输入都成立。313

Anthropic将这项工作描述为首次大规模借助AI，在汇编层面对生产软件进行形式化验证。这是研究团队对项目新颖性的说法，并非已经独立确立的历史共识。713

Rocq校验提供了什么保障？

Claude负责生成证明，Rocq证明内核负责检查证明是否成立。因此，机械校验并不要求开发者相信Claude的推理，也不需要逐行人工审阅全部证明代码。但这不代表所有前提都无需信任：定理必须准确表达开发者关心的性质，形式化模型和校验器本身也属于证明所依赖的基础。95

Anthropic及相关报道将证明代码总量估为约1.8亿行，平均每个二进制文件约60万行。庞大的代码量体现了这项工作的规模，但行数本身不能说明一个性质适用范围有多广，也不能证明它完全符合某个项目的实际需求。312

测试之外，形式化证明能补上什么？

模糊测试可以尝试大量输入，却无法单凭测试证明某个范围内的每一种输入都安全。有关这项工作的报道说，Claude在验证过程中发现并修复了数百个漏洞，其中包括曾逃过数万亿次模糊测试运行的问题。这些数字是对本项目成果的报道，并不能直接说明形式化验证在其他项目中会以同样方式胜过测试。211

更稳妥的理解是：形式化证明与测试提供的是不同类型的证据。对于已明确说明的性质和范围，证明可以覆盖符合规格的全部输入；测试则验证实际运行过的那些情形。前者并不意味着后者可以省略。92

为什么“已验证”不等于“没有漏洞”？

首先，保证只针对选定的测试入口和特定编译产物，不会自动延伸到库里的每个功能、每种构建配置、其他处理器架构或所有使用方式。95

其次，运行条件很关键。相关报道描述的证明针对单线程、静态编译的RISC-V二进制程序，并假定其在有固定内存预算的Linux模型中运行。实际部署的软件可能采用其他架构或配置，因此不能把这项结果直接当作那些版本的安全保证。122734

最后，证明只能确立定理中写明的内容，而不是开发者可能关心的所有性质。未纳入证明范围的问题仍可能存在；形式化模型或证明校验基础中的错误，也会影响结论的可信度。531

开发者可以如何看待这项成果？

这项工作的核心意义在于，它显示AI辅助或许能让汇编层面的形式化验证扩展到更多真实软件，而不必完全依靠大量专家手工完成。不过，这并不能推出一个适用于所有代码库的成本估算，也不能保证该方法在任何项目上都能成功。713

目前公开的证明只是项目成果的一部分。一份报道说，公开部分覆盖25个库和60个测试入口，并非全部成果；Theorem也宣布推出面向开源维护者的OSS Verify计划。321638

对开发者而言，实际做法是逐项核对证明覆盖的入口、编译产物、假设条件和具体性质，再决定能否依赖它。Claude的成果让LLM辅助形式化验证值得与测试一并评估，但不是停止测试或认定软件已经无漏洞的理由。95