微软 PDD Kit：让 Agent 写的代码自己拿出数学证明，登录逻辑先过这一关

先说判断：审代码这件事，正在从“看代码”变成“看意图”

2026 年 11 月 5 日，微软研究院（Microsoft Research）发布了一个叫 PDD Kit 的工具包，全称是 Proof-Driven Development Kit，证明驱动开发工具包。它想解决的问题，每个用 Agent 写过代码的人都遇到过：Agent 一坐下来就能交出几万行代码，功能看着全、测试看着绿，可你敢不敢合并不再取决于你读了多少行，而取决于你根本读不完。逐行审代码这条路，在 Agent 的出活速度面前已经走到头了。

微软研究院给出的答案不是“让 Agent 自己检查自己”，也不是“多写点测试”。他们的判断很直接：测试只能证明代码在试过的输入上是对的，审代码只能证明你看过的那几行是对的。真正能覆盖“所有输入”的办法，是数学证明——让代码带着一份能被机器验证的证明一起交上来，证明它满足你写下来的规约。PDD Kit 就是把这套以前只属于安全关键系统、需要形式化方法专家才能玩转的手艺，搬到日常的全栈 Web 应用上，而且全程不需要你懂形式化方法。

先把结论摆在前面：这仍然是一个研究原型（research prototype），今天只支持 Rust，也还没到人人能用的程度。但它戳中的问题是真实的，思路也是新的——它不要求你去读证明，而是要求你去审意图。代码和证明都由 Agent 写、由机器验，人只审一件事：你到底想要什么。这对所有靠 Agent 出活的团队都值得认真看一眼。

它到底是什么：意图变成规约，规约变成证明

Proof-Driven Development，证明驱动开发，是微软研究院给这套新范式起的名字。PDD Kit 是实现它的工具包，跑在 GitHub Next 的 Chopin 里面——Chopin 是 GitHub Next 的实时多人规划环境，团队和 Agent 在同一份共享文档里做规划。整个流程分三段：pdd-plan 负责把意图变成规约，pdd-prove 负责证明代码满足规约并补齐测试，pdd-ship 负责把证明检查放进 CI。

工作方式是这样的。你先用大白话告诉它你要什么，PDD Kit 会像一个较真的评审一样反问你，把含糊的地方一个个钉死，写成一份“意图工件”（intent artifact），也就是一份人能读懂的、把你的意思说清楚的文档。能形式化的部分会被转成 Verus 规约——Verus 是微软研究院与卡内基梅隆大学、VMware 研究院、苏黎世联邦理工学院等机构联合开发的 Rust 证明语言；不能形式化的部分则转成非形式规约，交给测试去覆盖。接着 Agent 写代码、写证明，Verus 逐条验证；验证不过，构建就失败，跟测试挂掉一个待遇。

这里的关键设计是“证明什么、不证明什么”被明确地画了出来。PDD Kit 把每个验证结果都标清楚出处：形式化验证是数学证明，代码对所有可能的输入都满足规约；经验验证是跑出来的证据，只说明代码在试过的输入上是对的。二者的分界线叫可信计算基（Trusted Computing Base，TCB），也就是证明默认“它就是对的”的那部分代码。PDD Kit 会把这条线摆到台面上，让你逐件签字确认，而不是藏在某个你永远不会读的角落里。

实战：给一个 5000 行 Rust 商店的登录逻辑上证明

为了证明这套东西能在真实代码库里跑，微软研究院的团队写了一个叫 Pet Store 的全栈 Web 应用，全部用 Rust 写，大约 5000 行：后端是 Axum 加 SQLite，管库存、促销、订单和结账；前端是编译成 WebAssembly 的 Leptos 应用。他们只挑了其中最敏感的一块来验证：登录逻辑。理由很实在——登录出 bug，丢的是用户账号甚至管理员权限，证明的力气花在这里最值。

开发者的原始需求只有两句话：“只有密码对了才能拿到 token”“只有管理员账号才能拿到管理员 token”。PDD Kit 的工作就是从这两句含糊的大白话出发，先把歧义揪出来。最精彩的是第一张决策卡：只说“只有密码对了才能拿到 token”，一个把所有人都拒绝掉的登录也完全满足这句话——它确实没让任何一个密码错误的人拿到 token。真正的意思必须同时包含反方向：“密码对了就一定能拿到 token”。形式化地说，前者是“有 token 就能推出密码正确”，后者是它的逆命题，合起来才是“当且仅当”。Agent 自己干活时会在这里悄悄替你选一个方向还不告诉你，PDD Kit 的做法是把这个选择题摆出来，让人亲手选。

两句话的需求，最终落成 login_flow 函数上的 8 条 ensures 保证：没给邮箱也没给用户名，返回 400；token 只发给登录所指的那个账号，且密码必须对得上，token 里带的 id 和角色必须就是这个账号的；密码对了一定能拿到 token，除非查询或签名失败返回 500；查无此人或密码错误返回 401；读不懂的哈希返回 500 且不发 token；管理员角色只可能来自用用户名查到的管理员表记录；用邮箱登录的 token 一定是顾客角色。五块核心逻辑——login_flow、login_core、lookup_target、decide_login、issue_token——全部被 Verus 证明满足各自的契约，覆盖所有输入。

证明也不是无所不包。六件东西被明确划进“信任但不证明”的范围：两次数据库查询、包着 bcrypt 的密码校验、签发 token 的 JWT 签名、读时钟算过期时间（恰好 24 小时后，即 86400 秒）、数据库报错的转换，以及处理请求外壳的解包。每一件都有开发者签字确认的假设契约，并且都配了针对真实 bcrypt、真实 SQLite 表结构和真实路由的测试。博客原文说得很坦白：这套保证的强度，取决于这六件受信部件，其中密码校验和两次查询扛了最大的分量——测试能撑住它们，但没有任何东西能证明它们。

最值得记住的词：“vibe verification”

这篇博客里我最喜欢的一个概念，叫“vibe verification”，可以译作“凭感觉的验证”。意思是：当模型自己写规约、自己写证明时，它很容易滑向弱不变量——那些能通过验证、但几乎什么都没约束住的条款。证明通过了，实际保证的东西却少得可怜。这和 vibe coding 的毛病是同一个根：看起来都对了，实际上没人较真。

PDD Kit 对付这个问题的办法有两层。第一层是流程上的：规约从意图工件里推导出来，推导过程有两名评审 Agent 专门挑刺，检查规约是否忠实于你的要求、有没有许下证明不了的诺言，迭代到评审一致通过为止。第二层是技术上的，叫变异检查（mutation check）：pdd-prove 会给每条 ensures 条款在代码的副本里故意种一个 bug——比如让登录拒绝所有人，或者先查用户名再查邮箱——然后要求 Verus 必须在对应的条款上把每个变异体都揪出来。有一个变异体溜过去了，就说明那条款什么都没约束住，得当成缺口打回去重做。而且规矩很硬：如果某个异步结构在当前锁定的 Verus 版本里表达不出来，任务会停下来问人，绝不悄悄换成同步写法、也不放宽契约。目标不许挪。

博客的 FAQ 里有一张对照表，把四种做法的区别说得很干净：规格驱动开发（Spec-Driven Development）的问题是没有任何东西强制执行规约；测试驱动开发只覆盖抽样输入，而且测试常常是按已实现的样子写的；让 Agent 自己检查自己的工作，检查者和写代码的是同一个模型；证明驱动开发则由 Verus 自动验证“代码满足你批准过的规约”。PDD 保留了规格驱动的规划循环，也保留了测试——只不过测试退到它该待的位置：覆盖证明够不着的地方。

合并不再是“终于读完了代码”，而是“意图已经审过，证明已经通过”。通过验证的改动以 PR 的形式交上来，附带一份收据：每条需求是被形式化验证了，还是被经验检查了。pdd-ship 再把 Verus 检查加进 CI，从此无论人还是 Agent 改登录逻辑，都得继续通过同一份规约；证明坏了，构建就失败。顺带的好处是，CI 还能瘦身：那些只是重复验证“已证明内容”的示例测试可以删掉，只保留守住可信边界的测试。

别跟 10 月那篇形式化验证搞混：这是另一回事

VibeFix 在 10 月 22 日发过一篇相关的文章：Anthropic 与 Theorem 合作，让 Claude 给 123 个开源库写数学证明，做到 RISC-V 汇编级、1.8 亿行 Rocq。那篇讲的是“规模纪录”——证明能做到多大、多少库、多大代码量。PDD Kit 讲的不是规模，而是“日常流程”：它不追求一次验证整个世界，而是让你从登录、支付、权限这种最怕出错的角落开始，一块一块地验；它也不追求证明本身有多大，而是把人的评审精力从“逐行读代码”挪到“审意图、签字确认信任边界”上。一个讲的是验证能力的上限，另一个讲的是验证怎么住进日常开发流程。两篇互补，不重复。

同样要分清的是，PDD Kit 不是测试工具，也不是代码评审工具。它不替你判断需求对不对——规约本身写错了，证明只能保证你错得彻底。博客的 FAQ 直面了这一点：证明只能证明代码满足规约，不能证明规约就是你的本意。所以整个工具包才把那么多力气花在意图澄清上：决策卡、意图地图、评审 Agent、变异检查，全是围着“别让规约写错”转的。

冷静一点：它现在还不能直接拿去用

先说限制。第一，只支持 Rust。你的代码库如果已经是 Rust，什么都不用迁移；其他语言可以把关键部分移植到 Rust、用同一份规约验证，或者通过绑定调用已验证的 Rust 代码。但对绝大多数用 TypeScript、Python 的 vibe coding 项目来说，这意味着 PDD Kit 今天还够不着你的主代码库。第二，证明本身仍然费力气，主要花在“把证明写出来”这一步上，规约越清楚、力气越小——这也是为什么工具包一半的功夫都花在意图澄清上。第三，保证的强度受制于可信边界，bcrypt、数据库查询、时钟、JWT 签名这些最关键的环节仍然是“信任加测试”，不是证明。第四，证明不承诺任何关于“会不会完成、要花多久、被频繁尝试时会怎样”的事情，限流、超时、错误文案好不好用，都不在证明的射程内。

微软研究院自己也把话说得很收敛：这是一个研究原型，目标是搞清楚这条路能走多远，可信边界会随着时间显著缩小。他们建议的起点是“ bug 代价最大的地方”——登录、支付、权限——然后一块一块地往外扩。对普通开发者来说，更现实的启发在方法论那一层：即使你不用 Verus，也可以偷走它的两个习惯。第一，把“只有……才……”这种单向表述写成双向的，问自己一句“反过来还成立吗”。第二，把测试和评审的精力从“代码长什么样”挪到“需求到底是什么”上，并且把“哪些东西我只是相信它是对的”明确写下来。很多线上事故的根子，不在代码写错了，而在需求从一开始就没被钉死。

还有一个背景值得注意：这项工作是微软研究院 Catalyst 实验室、GitHub Next 和软件工程研究组（RiSE）的合作，跑在 GitHub Next 的 Chopin 环境里。微软研究院把 Agent 写作代码的验证问题，同时押在了两个方向上——一是让 Agent 自己写证明（PDD Kit），二是让证明检查住进 CI（pdd-ship）。如果这条路走得通，以后审 Agent 代码的标准答案可能不再是“你读完了吗”，而是“你的规约审过了吗，证明通过了吗”。

证明是怎么跑出来的：七个任务、一个死循环

规约签完字，开发者的评审工作就结束了，剩下的全是机器的活。pdd-prove 会把批准过的计划变成一张小任务图：对登录这个例子来说一共七个任务——先让 login.rs 在 Verus 下成功构建，同时不改变任何一条契约的含义；再分别证明密码决策、token 签发和整个登录流程；然后给受信包装写测试、跑端到端登录测试、验证 token 签名行为。每个任务跑的是同一个循环：Agent 写实现和证明，Verus 拿着规约逐条校验；受信边界的部分补上计划里定好的测试；最后由一个 LLM 验证者把计划、规约和结果并排放在一起通读，专门找缺口——有哪条需求既没有证明也没有通过的检查，就打回去给 Agent 重做。如果缺口出在规约本身，比如两条需求互相矛盾，那就不是 Agent 的事了，会作为决策返回给开发者。

这个循环里最值得注意的细节是第一步的规矩：让代码在 Verus 下构建时，不许改变任何契约的含义。如果某个异步结构在当前锁定的 Verus 版本里表达不出来，任务会停下来问人，而不是悄悄换一种写法绕过去。目标不许挪，这条红线从规约一路贯穿到构建。等全部任务通过，pdd-prove 会开出 PR：新增一个 verified/ 目录，里面是 login_flow、它的各个部件、它们的证明，以及受信包装和配套测试；真实的登录处理函数改走 login_flow，但对外暴露的 HTTP 状态码保持今天的样子——400、401、500 各归其位，已有的 API 测试不用改。PR 描述就是一份收据：每条登录需求后面标着“已形式化验证”或“已经验检查”。

还有一个容易被忽略的收益：CI 变强了，同时变瘦了。强，是因为 Verus 检查进了 CI，此后任何人或 Agent 改登录逻辑，都得继续通过同一份规约，证明一坏构建就失败，跟测试挂掉一个待遇。瘦，是因为证明覆盖的部分不需要再用示例测试重复验证——比如密码门“对的密码给 token、错的密码拒绝”这种例子，既然已经对所有输入证明过了，逐个举例的测试就可以删掉，只保留守住可信边界的测试，比如针对真实 bcrypt、真实 SQLite 表结构和真实路由的那些。测试从“越多越好”变成“只守边界”，这对被 Agent 生成的海量低质量测试撑大的 CI 来说，是一次反向瘦身。

写给 vibe coder 的一句话

你今天大概用不上 PDD Kit——除非你在写 Rust。但它点破了一个迟早要面对的现实：Agent 写代码的速度已经超过了人逐行审读的速度，评审必须升级。测试能告诉你“试过的都对了”，只有证明能告诉你“没试过的也对了”。而证明的前提，是你得先把“你到底想要什么”说清楚。下一回你让 Agent 写登录、写支付、写权限的时候，不妨先学 PDD Kit 的做法：把需求写成双向的、把“哪些东西我只是相信”列出来、把含糊的边界问清楚再开工。这一步不花钱，却是所有验证的前提。