谁说“code review 完了”我现在都不太信。不是人偷懒，是看不过来——一个 agent 跑完给你几十个文件、几千行改动，分散在十几个模块里，人眼速度是固定的，这等式从根上就破了。所以现在的问题已经不是“AI 写的代码对不对”，是“你说它对了，凭什么”。AssureCode 就是把这个问题摆到台面上的方案。我先给结论：它提的是真问题，但它的方案——把 safety-case 那套结构化论证搬进 agentic coding——只在要审计、强监管、要过认证的地方值回成本；多数业务团队，它是过度工程，不建议首选。
先把论文条件交代了，不然后面全是裸判断。论文叫 AssureCode: Structured Justification for Trustworthy Agentic Coding，arXiv 2610.29758，Software Engineering，10 月 21 日提交，Logan Murphy 是 submitter，作者七个人，DOI 10.48550/arXiv.2610.29758。我按横评处理：对象是 agentic coding 的“保障方案”这个品类，AssureCode 是重点，参照系是类型检查、单元测试、静态分析、形式验证、human review 这些现有手段。
论文抓两个 assurance 问题：AI 生成的代码有没有照着开发者意图写，以及有没有被充分验证。听着像废话，其实戳中了 agentic coding 之后最没人管的真空。以前代码是人写的，人写的时候脑子里有意图，逐行写逐行懂——验证一部分靠的是写代码的人还没意识到的那种“我在写什么”的感觉。现在 agent 生成一大片，人只捏两个点：prompt 和 review。中间那段生成过程是黑箱，意图和实现的链条断了。你不能默认每一行都有人懂，这个前提已经没了。你我都见过这种 diff：测试全绿，但 review 的人一眼看出某个函数实现的是另一套业务规则。测试绿说明什么？只说明它跑过了它自己写的测试。
覆盖率在 agentic coding 下也会骗人。以前覆盖率算个说得过去的 proxy：代码是人写的，意图贯穿每行，覆盖上去了，至少说明大部分执行路径被踩过。但现在测试也是 agent 写的——实现和测试出自同一个模型、同一份 prompt。这时候覆盖率数字还在，它 proxy 的“另一双眼睛在看”这个关系断了。你拿到的是同源证据：实现和测试可能共享同一个误解。论文把“匹配意图”和“充分验证”拆成两个问题，原因就在这。测试能答后一半，答不了前一半；而前一半恰恰是 agentic coding 里先崩的东西。
六个保障方案、七个维度，方向性对比。不是实测数据，是我对这一项强弱的判断。维度我先定义：意图匹配指方案能不能覆盖“代码做的是不是开发者真想要的事”；验证充分性是方案对正确性的证明力度；可审计性是保障能否被第三方追溯和审查；人工成本是每千行代码要付多少人工维护；动态行为覆盖是对运行时行为的覆盖力；接入成本是团队为用上它要付的工程和培训成本。
| 保障手段 | 意图匹配 | 验证充分性 | 可审计性 | 人工成本 | 动态行为覆盖 | 接入成本 |
|---|---|---|---|---|---|---|
| 类型检查 | 低 | 低 | 中 | 低 | 无 | 低 |
| 单元测试 | 中 | 中 | 中 | 高 | 中 | 中 |
| 静态分析 | 低 | 中 | 中 | 低 | 无 | 中 |
| 形式验证 | 中 | 高 | 高 | 极高 | 低 | 极高 |
| Human review | 高 | 中 | 低 | 极高 | 中 | 低 |
| AssureCode | 高 | 高 | 高 | 高 | 低 | 高 |
几个格子值得单独说。形式验证那格“意图匹配”我给中，不是高——它验证的是 spec 和实现的一致性，spec 写错了，验证再严也只是严谨地证错东西。AssureCode 在这格给高，是因为它的 justification-rationale language 把 developer intention 的 assumptions 显式写进论证结构——这是它比纯形式验证多出来的一块。但这块不是白送的。看人工成本：高。你要把自然语言 prompt、形式规范、意图假设、程序分析证据放进同一个可验证的论证树，四类异质材料必须全部对齐，哪一处不上心，整个 rationale 断链。这不是写个测试的价钱。
另一个反直觉的是 human review 的“可审计性”我给低。人 review 的判断是非结构化的，追不回来。你留下一堆“这里没问题”的意见，半年后没人说得清你当时基于什么证据说的。AssureCode 这格高到独一份：论证链是可验证的，第三方能沿着 rationale 追溯每条 claim 是靠什么 evidence 撑起来的。这是它和所有现有方案拉开距离的地方。
这套东西不是新发明。结构化论证在 safety-critical 那儿有年头了，GSN、goal-strategy-evidence 那套大家见过。AssureCode 做的是把它搬到 agentic code generation 上，但不是简单搬——它定义了一种 justification-rationale language，把四类材料串起来：informal 的自然语言 prompts、formal 的 specifications、developer intention 的 assumptions、program-analysis 的 evidence。四样东西异质性要命。自然语言 prompt 含糊、有上下文；形式规范精确、无歧义、脱离上下文；意图假设是人的、隐式的、会变的；程序分析证据是机器的、局部的、静态的。你要把它们放进同一个可验证结构，就必须把映射关系显式化：prompt 里这句话对应 spec 哪个要求？这个要求对应哪条意图假设？意图假设又对应哪份程序分析证据？链条缺一环，整个 rationale 不可信。这个维护负担比形式验证低，因为它不强制所有 premises 都形式化；但它也不便宜，因为意图假设几乎永远需要人写、人盯、人更新。
AssureCode 的短板在“动态行为覆盖”：低。结构化论证是静态的，它不跑代码，不观察行为，不抓测试结果。这意味着它替代不了测试，替代不了运行时监控。它只能把已有的程序分析证据组织成论证链，不能制造新的动态证据。所以它是胶水层，不是底层原料。别以为上了结构化论证就能砍测试。不能。它只是在测试、类型检查、形式验证上面加一层可审计结构。你下面那层证据是空的，这层只会把空头支票叠得更高。
论文报告了一个 empirical analysis of the implementation，考察它能不能支撑 justified assurance。这里我得说清楚：这是可行性研究，不是优越性对比。它证明的是这方法在受控条件下能被用起来、能产出 rationales、能追踪 evidence；不是它比测试更有效，也不是比形式验证更实用。谁把这两者混为一谈，就是横评里常见的二次失真。我没拿到论文里可供复现的原始数据，所以这一段结论只能到“它迈过了可信度第一道门槛”为止。这不算差，可行性研究本来就是这个尺度。任何把它解读成“AssureCode 被证明优于现有方案”的说法，都是拿可行性当优越性，软文测评的路数。
收一下，给场景化建议。如果你在医疗、航空、金融核心系统，AI 已经参与生成代码，要向监管或客户证明“这些代码不是黑盒，每一步有据可查”，那 AssureCode 是少数能给你可审计论证链的方案之一。这个场景下值得上，因为可审计性这个维度没有便宜替代品。如果你做普通 SaaS、内部工具、快速迭代业务后端，agent 生成之后 review 量已经跟不上，别先上结构化论证。你该做的是缩小 agent 输出范围、限制变更面、逼它一次只改一个模块——这些事比给整个代码库建 rationale 便宜一个数量级。如果你已经有形式验证或强类型加 property testing 的工程文化，团队吃下了那些成本，那 AssureCode 可能是这些手段上面的胶水层——它把你已有的 evidence 组织成可追溯论证，前提是你下面已经有 evidence 可组织。如果你只在乎“跑起来之后行为对不对”，AssureCode 在这事上不比其他方案强，测试和监控不可替代，别想着上它就能砍测试。
补一句：没出现在推荐里不代表差，是场景不匹配。AssureCode 的可审计性在现有方案里独一份——类型检查、测试、review 都给不了第三方可追溯的论证链。但它的成本结构决定了它只在高 stakes、强监管、要过审计的场景兑付。表里把能力边界和成本边界都放着了，你约束是混合的——比如强合规又缺测试工程师——结论自己按约束重排，我给的只是尺子不是答案。判断基于 2026 年 10 月这个版本，下一轮实证如果给出更便宜的工具链或更强的自动化，结论可能翻——我盯着呢。