TL;DR

本文核心观点：

  1. 规格优先 SCE 协议 — 形式化规格 → 规格 vs 源码审查 → 原子实现 → 编译测试 → 代码 vs 冻结规格验证，全程无人工 code review
  2. 31 轮审计拦下 201 个缺陷 — 14 轮规格细化 + 17 轮验证循环，在任何人执行程序前完成
  3. 全程可复现反例 — 完整规格和 1500+ 页原始会话日志以法语发布，任何人可检查或交 LLM 一致性检查
  4. 结论：可控，但前提是规格冻结与双向审查 — 不是让模型直接 diff 主干，而是「规格先行、审查贯穿」

背景：大规模架构重构的难题

大型架构重构往往是最能检验 AI coding agent 能力的场景：涉及跨模块不变量、跨越数百文件、缺乏预存测试预言（test oracle）。

论文报告了一个单一的、完整可审计的案例研究：在一份 717,725 行生产级 TypeScript 代码库上，让 AI coding agent 在规格优先协议下执行大规模架构重构，没有任何人工 review 生成的代码，也没有预存预言来验证目标行为。

任务：拆除一个核心生命周期不变量

任务目标：拆除一个核心生命周期不变量——保证 AI 请求期间 UI panel 保持打开。目标行为是：流式生成可以在 panel 关闭后继续存活，并在重新打开时重新附加到同一个实时流，且无丢失或重复。

作者评估此任务通过增量重构方式实际上不可行——这类变更传统上需要 rewrite。

SCE 协议：规格优先的 5 步循环

1. 形式化规格（Formal Specification） Agent 编写形式化规格，精确描述目标行为。

2. 规格 vs 源码审查（14 轮） 14 轮审查循环，审计规格与源码之间的一致性——规格是否准确反映了代码的实际行为？边界条件是否被正确描述？

3. 原子实现（Atomic Implementation） 按规格逐原子实现变更。

4. 编译测试反馈循环 每次实现后运行编译和测试，从反馈中迭代。

5. 代码 vs 冻结规格验证（17 轮） 17 轮验证循环，在代码上运行以审计其是否符合冻结规格。目标是两次连续验证通过返回零发现。

数字说话

  • 717,725 行生产级 TypeScript，跨越 3,648 文件
  • 31 轮审计（14 轮规格细化 + 17 轮验证）
  • 201 个缺陷在审计中被纠正，发生在任何人执行程序之前
  • 变更涉及 189 文件（31 个新增）；两笔提交总计 288 文件，34,770 行插入，16,422 行删除
  • 耗时：3 天
  • 成本：USD 2,430

收敛判定

收敛标准是经验的：两次连续验证通过返回零发现。跨第一轮和大约三十轮后续会话，软件行为符合规格，未观察到 bug。

证据发布

完整规格和原始会话日志（1500+ 页，法语）作为证据发布，允许对过程进行检查，并可提交给 LLM 进行一致性检查。

结尾

这篇论文给出的是一份可审计的反例，而不是一个可以被 marketing 引用的成功率数字。它证明的是：在严格的规格优先协议下（规格冻结 + 双向审查），一次原本需要 rewrite 的大规模架构重构可以被 AI agent 以可控方式完成——201 个缺陷在人工执行前被审计拦下，而不是在生产中被发现。关键约束是协议，不是模型。这对「Agent 会不会引入隐蔽破坏」提供了一个具体的、可检验的回答：规格先行、审查贯穿，结果就是可审计的。

Published on 2026-08-31

参考链接