我又遇到了“修了，但真的修干净了吗？”

上周二晚上十点，我在杭州给客户交付自动报价系统。版本刚上线，我复查了三遍旧漏洞，心里还是没底：漏掉的不是显眼报错，而是一段没人再看的权限逻辑。以前我会继续熬，甚至买更贵的测试服务；这次我试着看 Google DeepMind 的 AI 数学验证实验，才意识到它能帮团队用“证明”检查代码，而不是只靠逐个试错。

它不是替你写代码，而是给代码找反例

这套方法先让人写出程序必须遵守的规则，再让 AI 生成大量数学证明，逐条证明代码满足规则，或找到违反规则的例子。Signal 的研究团队还故意把两个已修复的旧漏洞恢复，再看系统能否重新发现。四周内，他们生成了约 650 万行证明。

我比较喜欢其中一个场景：2025 年 3 月，纽约一家小型医疗软件团队把“只有值班医生能看完整病历”写成明确规则，让系统检查不同角色是否可能越权。团队负责人 Maya Chen 说，他们当天先抓到两个测试用例没覆盖的路径。名字是虚构的，但场景很普通——不是大型银行，而是十个人、每天处理敏感资料的小团队。

今天复刻：预算不高，但要准备一位懂业务的人

钱：Google 的公开研究没有给出可直接购买的套餐；按我这次小范围试验估算，准备正式验证预算可先留 5000 元以上，主要用于测试环境和安全人员复核，而不是直接购买模型调用。时间：接入现有代码库约 2—6 周，做一次规则与证明的小范围试跑约 3—7 天。技术门槛：需要有人能把业务规则说清，也要有人能读懂代码；非码农可以参与规则编写，但很难独自完成验证。

第一步不是点“生成”按钮，而是打开你所用开发工具里的测试页面，新建一个最小项目，写下三条最不能被违反的权限规则，再挑一个只处理假数据的小模块让工程师协助验证。我之前犯过的错，是先让 AI 扫整个系统，结果噪声太多；缩到一个模块后，业务人员才看得懂报告。这个方法不是所有人都需要，现在不试也没事。

如果你正处在不同阶段，我会这样选

如果你是刚起步：我先不引入这套流程。把最关键的一条权限规则写成测试用例，找熟悉业务的人手工复核；预算紧张时，先买 20—50 元的外部安全检查更实际。

如果你已经有 1—2 个客户：我会选一份正在交付的项目，用假数据跑 3—7 天小范围验证，并把结果作为客户沟通附件；预计先准备 5000 元，不急着扩大。

如果你正在扩规模：我会让工程师建立“业务规则库”，每次发布都自动跑验证，再保留人工签字环节。此时更值得讨论的是稳定性和总预算，而不是一次生成了多少证明。

AI 数学验证值得看，但它不是安全许可证。你可以先拿一个低风险模块观察：它能否发现你和客户都没想到的问题。如果不能，也及时收手，别让工具反过来拖慢交付。