没有测试,AI重构71万行代码(08.15)

你有没有过这种经历：一个看似局部的改动，牵一发而动全身，改完之后你根本不敢点"运行"？

当一次重构要同时保住几十个隐含不变量、横跨几百个互相依赖的文件，依赖图谱复杂到没有任何一个评审者能塞进工作记忆——这时候，人还能审吗？如果人审不动，AI 写得动吗？

如果有人告诉你：不用写测试、不用人审，让 AI 把一个 71 万行的生产系统改了，还一次跑通、跑了三十多次没出 bug——你第一反应大概是"吹牛"。今天这篇，就是来拆这个"吹牛"的。

对象：论文 Specification-first convergence with an AI coding agent（arXiv:2608.12440，Joël Abenhaïm，AI Sovereign Labs，2026-07-31）。一句话概括：一份先写、反复磨、然后冻结的规格说明书，替代了"测试 + 人工评审"这两道传统质量闸门，让 AI 在没 oracle、没人看的情况下，完成了一个本该"重写而非重构"的巨型改动。

一、项目概述

核心问题：当"人审不动"成为瓶颈

当前主流 AI 编码智能体（Claude Code、Codex、Copilot、Cursor）在孤立、自包含的小任务上 throughput 很高，行业默认"生成代码后必须人工 review"。但 review 本身有个硬性天花板：

当一次改动横跨数百个互相依赖的文件、要同时保住几十条隐式不变量时，评审本身就成了瓶颈；超过某个体量，它根本不再是一个现实的质量关卡——没有任何一个评审者能把这种改动的整张依赖图装进工作记忆。

论文引用了一篇系统的度量研究（Farrag 2026）：遥测数据显示，AI 辅助让 PR 变多了，但评审时间最多上涨 91%，整体交付指标却持平。换句话说，AI 把"写"变便宜了，却把"审"挤爆了。

这篇论文的赌注是：与其事后审计生成的代码，不如在生成之前审计"意图"——把意图写成一份书面规格说明书，反复拿它和真实源码对账，直到它不再产生任何发现；然后代码对着这份冻结的参照物生成，再对着同一份参照物审计。

生态定位：和谁站在一起，和谁不一样

这篇论文明确把自己放在一个很窄的配置上：

对比 SWE-bench 范式（评测体系的主流派）：SWE-bench 假设存在一个 oracle——正确行为已经编码在现成的测试里，agent 的任务是找到满足它们的代码。SWE-bench Pro 把任务拉长到工业级，但即便统一 scaffold，当前系统也只解出不到 45% 的实例。而本任务根本不存在这种 oracle：目标行为（关掉面板后生成还能活、还能重新接回同一条流）在改动之前压根不存在，没有任何现成测试能编码它。
对比 SWE-agent：SWE-agent 证明"agent 读写代码库的接口"会独立影响可靠性（与本论文第 5 节"agent 提 patch 而非直接写文件"的执行模型一致）。
对比 loop engineering（Osmani 2026 年 6 月提出，Anthropic 同月跟进）：loop engineering 让外层系统找活、交给 agent、用第二个 agent 检查结果、把过程记在模型上下文之外。它最需要的是"自动判断一个工作单元是否完成"，其最自治形态的例子是"测试通过 + linter 干净"。但它只解决"能拆成独立单元各自校验"的工作；一旦单元拆不开、又没有任何测试能区分对错——这正是本论文的场景。两者是互补而非竞争。
对比工业级部署：Cloudflare 用 7 个领域评审 agent 处理 4.8 万次 MR；Anthropic 在 1250 万行的 vLLM 上单跑 7 小时、靠现成的数值精度参照验证；最强的工业演示是 Bun 重写——53.5 万行 Zig 移植到 Rust，11 天、最多 64 个 Claude 并行、过百万断言的测试套件全部通过、上线生产。但 Bun 的验证栈锚定在 oracle 上：与实现语言无关的百万断言测试、Rust 编译器、对每个改动的对抗式 agent 评审。本任务没有这种 oracle，参照物必须现造。

一句话定位：这是一份在"无 oracle + 全链路无人审阅 + 数百文件强耦合"这个最凶险配置下，一份被完整打点的证据。

与同类方案的本质差异

最妙的一刀，切在"谁来当裁判"上。Anthropic 的 loop engineering 指南建议：写代码的 agent 不能是审代码的 agent，要用一个对改动毫无记忆的第二 agent，理由是"新鲜上下文的评审者偏见更小、不被第一 agent 的推理带偏"。本论文换了一种分离方式：

检查者是同一个 agent 的新会话，而不是换了指令的另一个 agent；它比对的是一份在代码存在之前就写好并冻结的文档。本协议依赖的分离，存在于那个"参照物"里，而不在评审者的身份里。

这个设计直接呼应了 Huang et al. 2024（Large Language Models Cannot Self-Correct Reasoning Yet）的结论：一个模型在没有任何外部东西可比对的情况下改写自己的输出，不会变好、甚至可能更差。本协议的精髓，就是给模型一个外部、冻结、在代码之前就存在的参照物——分离发生在参照物，而不是审稿人。

二、功能与使用

先说清楚：这篇论文不是开源工具。AICode 智能体是作者公司的闭源产品，代码库本身也闭源（这反而排除了"模型在训练数据里见过答案"的嫌疑）。论文真正的可复用产物是一套方法论 + 1,500+ 页法语原始会话日志（已公开，可供任何人喂给 LLM 做一致性核验）。

所以这一节不给你 pip install，而是把方法拆成可照抄的能力模块 + 一段可套用的操作循环 + 一组实例化参数。

方法暴露的能力模块

论文把整个流程固化成一个 五阶段工作流：ideate（立意）→ specify（规格）→ refine（精炼）→ code（实现）→ verify（核验），每个阶段跑在独立会话里：

阶段	产出物	对账参照	决策点
Ideate 立意	口头化意图与约束	真实源码	操作员确认范围
Specify 规格	形式化规格书	无（首次生产）	操作员略读
Refine ×N 精炼	修订后的规格书	真实源码	操作员重跑 / 冻结
Code 实现	补丁	冻结的规格书	无（补丁免检直接应用）
Verify ×M 核验	修正	冻结的规格书	操作员接受 / 连续两次零发现即停

两个阶段是循环：refine 拿规格书对账源码、反复改到挑不出错；verify 拿代码对账冻结规格书、反复改到挑不出错。

可照抄的操作循环（伪代码）

spec = agent.ideate(request, source_code)        # 立意 + 首版规格for i in range(REFINE_MAX):                       # 精炼循环（本例 14 轮）    findings = agent.audit(spec, against=source_code)    if findings == 0: break    spec = agent.revise(spec, fixes=findings)frozen_spec = spec                               # 冻结参照物for j in range(VERIFY_MAX):                      # 核验循环（本例 17 轮）    corrections = agent.audit(source_code, against=frozen_spec)    if corrections == 0:        consecutive_zero += 1        if consecutive_zero >= 2: break           # 收敛判据：连续两次零发现    else:        source_code = agent.apply(corrections)        consecutive_zero = 0

实例化参数（来自本案例）

模型：OpenAI ChatGPT 5.6 Sol，max reasoning 模式
Refine 轮数：14（平均 35 分钟/轮；范围从 110 个受影响文件扩展到 160 个，因为不断发现此前没注意到的依赖）
Verify 轮数：17（审计本身 7–45 分钟/轮，加自动生成修正 15–60 分钟/轮）
收敛判据：连续两次 verify 零发现（本例在第 16、17 轮达成）
系统提示词体量：约 250,000 字符，编码了从 construction 期观察到的失败里累积出的数百条规则（与 Davis et al. 的治理基座 1.16 MLOC 异曲同工——把反复出现的失败转成持久机制）
关键纪律：agent 不自动修编译/类型/单测错误（设计选择，为了让信号可见）；残留错误在独立会话里修

你能直接照搬的最小可用版本

哪怕你不用 AICode，这套"先冻结一份意图参照物、再反复对账"的纪律也能立刻套：

让 agent 把你的需求写成一份形式化规格书（接口、模块、异步协议都写清），不要只给自然语言；
让它独立会话地拿这份规格书去审你的源码，挑"规格和现实对不上的地方"，改到挑不出；
冻结规格书，让 agent 实现对标它的代码；
再开独立会话，拿代码对账冻结规格书，改到连续两轮零发现；
最后才第一次手动运行。

这五个动作，本案例跑了三天、花了 2,430 美元——但在任何人运行程序之前，已经修掉了 201 个缺陷。

三、技术实现

被改造的系统长什么样

代码库是一个 VS Code 扩展，本身就是一个 AI 编码智能体（同品类、同体量，对标市面上的商用作价）。操作开始时它有 717,725 行 TypeScript、3,648 个文件，由单一开发者（即本文作者）在约 4,000 次提交下、用同一套"规格优先"方法论维护——本文只是把其中一次操作完整打点。

三个相关组件：

编排后端：跑在扩展宿主进程里，负责发起模型请求并流式输出；
React 前端：跑在 webview 里，把响应文本、推理轨迹、工具调用、代码块交错渲染成一个复合视图；
自定义 RPC 数据总线：连接两个进程。

要拆掉的"不变量"

任务要拆除一个核心生命周期不变量：保证"一个 AI 请求期间，UI 面板始终开着"。目标行为是：流式生成在面板关闭后依然存活，重开面板时能重新接回同一条活着的流，不丢、不重。

这个要求破坏了周边代码赖以建立的一个结构保证，波及：请求生命周期、内存所有权、缓存恢复、异步事件排序、半消费流的重新挂载。具体难点包括：从半消费的流里重建复合显示；面板关闭与在途生成之间的竞态；重开时面板初始化、已生成内容重放、新 token 实时流三方的三方争用。

作者评估：这种"边拆中心不变量、边端到端重建系统"的任务，常规做法就是重写受影响组件，比当重构试更现实。

五阶段协议的技术细节

1. 立意与规格（Ideate + Specify） 从初始需求和一次范围澄清，agent 产出一份形式化规格书，描述对 110 个文件（共享契约、后端、前端、RPC 总线）的改动。注意：初始请求是纯自然语言，没指定类型、模块、协议或要处理的异步操作——这些本身就是被研究的工作的一部分。

2. 精炼循环（Refine ×14） 每轮是独立会话，平均 35 分钟。14 轮共产生约 85 处规格修正，作用域从 110 个文件扩展到 160 个（不断发现此前没注意到的依赖）。第 14 轮零发现，于是第 13 轮产出的规格书被冻结，作为后续所有阶段的参照。

有个测量上的诚实注记：一次平台侧的迁移故障导致部分轮次的修正清单没能恢复，表中那些轮次记为"约 5 处"的估算。这种"把坑自己写出来"的态度，后面还会反复看到。

3. 实现（Code） agent 一开始拒绝了实现请求，理由是：部分实现会让仓库处于不一致状态、违反规格书的原子性要求。它说：

"我没有对仓库做任何改动……这次迁移影响 160 个文件，含 31 个新文件，跨共享契约、后端注册表、传输、持久化、面板、SidebarStore 和 React 运行时。部分实现会让仓库处于不一致状态、违反规格书的原子性要求。所以我没引入一个会把 Prompt 或 EasyAgents 搞坏的半成品迁移。"

agent 提议十步分解，最终接受三步，在三次连续片段中实现，每次由显式人工确认触发，agent 总耗时 2 小时 21 分 44 秒。

4. 反馈循环（Feedback loop） agent 不自动修编译/类型/单测失败——这是刻意设计，为了让这些信号保持可见。残留的语法、类型、单测错误在独立会话里、一小时内修完。

5. 核验循环（Verify ×17） 每轮让 agent 把当前源码对账冻结规格书，报告残留的架构缺陷与微妙偏离并修正。与反馈循环不同，它针对的是架构一致性而非编译合法性。17 轮共产生 116 处代码修正。

架构层面的两个设计选择（值得抄）

"写码 agent ≠ 审码 agent"被替换成"参照物分离"：同一 agent 的新会话，比对一份代码存在之前就冻结的文档。分离在参照物，不在身份。
把编译错误的修正权从主 agent 手里拿走：故意不自动修，让语法/类型信号作为独立信号暴露出来。这是用"一次额外的独立会话"换"主循环不被噪声污染"的 tradeoff。

四、应用场景

适用场景

这套协议最适合的是**"拆不变量级"的大规模重构**，尤其是那些：

横跨数百文件、强耦合、隐式不变量众多；
没有现成测试能编码目标行为（目标行为改动前不存在）；
传统做法会建议"重写而非重构"；
评审者的工作记忆装不下整张依赖图。

典型例子：拆掉一个贯穿系统的核心生命周期假设、把嵌入式逻辑抽取成泛型库、对生产系统进行"看不见但真实"的架构迁移。

目标用户群体

单一开发者维护的大型闭源系统：没人审、又不信自动化盲改的人。本案例的作者本人就是这类人。
对"AI 盲改生产代码"有信任焦虑的团队：把信任从"审代码"转移到"信过程"。
需要可审计、可复现证据链的场景：1,500+ 页原始日志意味着过程可被第三方喂给 LLM 做一致性核验，而非只信作者一面之词。

今日产业界的同频信号

写这篇的当天，GitHub Trending 日榜上 github/spec-kit（+1,147/日） 赫然在列——GitHub 官方的"规格驱动开发"工具包。这篇论文，恰好是 spec-driven 在研究级、最凶险配置下的一个完整证据体。产业界和学术界在同一天，从不同方向压住了同一个赌注：把意图写清楚、冻结、反复对账，比事后救火更省。

五、优化方案

性能 / 成本 / 质量优化策略

1. 缺陷越早修越便宜（核心经济律） 论文金句：一个在规格阶段被抓住的缺陷，改一段文字就能修；同一个缺陷在生成之后被抓住，要改的是一组互相依赖的代码改动。精炼循环干的就是这件事——把"正确性"前置，避免实现阶段空转。

2. 收敛靠重复，不靠单点可靠 "一份书面规格书，被挑战十四次、被字面执行、再被审计十七次对着它自己——确实通过重复收敛到了一致性。这不要求模型在任意单次都可靠。"这是对"模型自校正"幻觉的一记清醒针：分离在参照物，重复提供收敛。

3. 冻结参照物 = 固定靶 代码被一轮轮对账一个固定目标，直到挑不出偏离。固定靶让"何时停"有客观判据（连续两次零发现），而不是靠人拍脑袋说"差不多了"。

4. 把失败沉淀进系统提示词 约 25 万字符的系统提示词，是从 construction 期观察到的失败里增量修正累积出来的数百条规则。这把"昂贵的手工审阅需求"自动化掉一部分——和 Davis et al. 把反复失败转成持久机制是同一条路。

已知局限（作者自己列的，逐条）

单案例：一个任务、一个代码库、一个操作员。没有成功率分布、没有可复现性证据。
无对照组：没用其他 agent 在可比条件下试同一任务（作者承认，找得到那些工具专家才能不偏不倚地比）。
自报告：作者设计了工具、执行了操作、报告了结果。原始日志公开供检视，但报告本身不独立。
"未见 bug"的定义：指首次手动执行、约三十次后续使用、以及自动化测试套件上的观察行为。它不是"无潜在缺陷"的证明——任何长度的测试或使用窗口都证不出" absence of latent defects"。
闭源：代码库不能公开，第三方无法在同一材料上重放。
模型依赖：结果来自特定前沿模型 + 扩展推理模式；协议在更弱模型上的表现未刻画。
打点范围：公开日志只覆盖所报告的操作；"整个系统都用同一方法论构建"是作者声明，4,000 次提交的历史无法 retroactively 打点。

作者自己给出的最清晰下一步：由独立操作员在公开代码库上执行同一协议——一次性消掉第 1、3、5 三条局限。

我的评价：这篇最值钱的不是"71 万行一次跑通"这个结果（单案例，谨慎看待），而是它把一个可复制的操作纪律和完整证据链摊开给你看。在 AI 编码圈集体焦虑"agent 写得多、人审不动"的当下，它给了一个不靠更强模型、而靠"过程结构"破局的样本。缺点也很诚实——这正是它能让人信的原因。

🔬 重点 · 评测体系：当没有 oracle 时，"评测"是什么？

这一节是整篇论文最锋利的地方，值得单独拎出来。

它如何重新定义 coding agent 的"评测"

主流评测（SWE-bench / SWE-bench Pro / HumanEval）都暗含一个前提：正确行为已经被某处编码（测试、规格、参考实现），agent 的任务是逼近它。论文把这套前提整个掀掉：

任务的目标行为在改动前不存在 → 没有测试能编码它 → 没有 oracle 可满足，只有一份规格书要现造、然后拿住实现。
因此"评测"在这里不是"跑测试看通过率"，而是两道审计循环：refine 审计规格 vs 源码（14 轮，≈85 处规格修正），verify 审计代码 vs 冻结规格（17 轮，116 处代码修正）。

评测结论（可量化的）

31 次审计 pass，201 个缺陷/歧义/架构偏离，在任何人运行程序之前被修掉（规格 ≈85 + 代码 116）。
缺陷密度曲线有信息量：refine 轮次里，修正数从 5→10→11 起伏，到第 14 轮归零；verify 轮次里，第 4 轮高达 21 处，之后整体下行，第 16、17 轮归零。这说明"收敛"不是线性的，中间会有反弹（第 4 轮 21 处是峰值），停止规则必须靠"连续两次零发现"而非"某轮少了就停"。
作用域漂移：冻结时追踪 160 个文件，最终实现触达 189 个（含 31 个新文件）。冻结时的计数反映的是"冻结时刻的计划范围"，不是实现和后续 17 轮 verify 额外碰到的文件。这是个重要的方法论诚实点：你以为范围锁了，其实还在长。

与 SWE-bench 范式的对照表

维度	SWE-bench 范式	本论文协议
正确性来源	现成测试（oracle 存在）	现造并冻结的规格书（无 oracle）
评审时机	生成后跑测试	生成前审意图 + 生成后审实现
停止判据	测试通过	连续两次审计零发现
适用任务	行为已存在、可被测试编码	行为不存在、无法被测试编码
评审者	测试套件 / 人	同 agent 新会话 × 冻结参照物

一个被作者主动暴露的诚实动作

论文没有把"首次手动执行即通过、三十次使用无 bug、原有单测无回归"包装成"证明无缺陷"。它明确写："未见 bug"不是"无潜在缺陷的证明"——任何测试活动或使用窗口都证不出 absence。这种自我拆台，反而让"评测体系"这一章有了真正的可信度。

⚡ 重点 · 推理加速：2,430 美元买来的"意图缓存"

coding 场景的推理加速，通常让人想到 vLLM、投机解码、prefix cache。这篇给了一个少有人讲的角度：把"正确性"前置，本身就是一种推理成本优化。

成本账（来自论文）

三天操作，模型推理花费 USD 2,430。
实现阶段 agent 耗时 2 小时 21 分 44 秒（三次片段，每次显式人工确认触发）。
反馈循环（修编译/类型/单测错误）独立会话 < 1 小时。
体量：717,725 行 → 改动后 ≈ 736,000 行；两个 commit 合计 288 文件、34,770 增、16,422 删；本文聚焦的 Slice 2 单 commit 即 189 文件、23,663 增、11,850 删。

换算一下：2,430 美元 / 717,725 行 ≈ 每千行约 3.4 美元。对于一次"拆核心不变量"的重构，这个单价低得反直觉——但关键不在模型便宜，而在流程把浪费压下去了。

"缺陷越早修越便宜" = token 经济学

论文的核心经济律：一个在规格阶段被抓住的缺陷，改一段文字；同一个缺陷在生成之后被抓住，要改一组互相依赖的代码。把正确性前置，等价于把高成本的"代码级返工"替换为低成本的"规格级返工"。这跟本周我们已经拆过的几篇是一脉相承的：

08-07 Reasonix：把 prefix cache 稳定性当架构第一性原理，命中率 99.82%、单次日成本从 1.38——省在重复前缀的 KV 复用。
08-10 TokTier：指出前缀缓存只加速模型侧，前端分词每次全量重扫长上下文，tokenization 占比随命中率升到 64% 致 TTFT 见顶——省在被忽视的分词瓶颈。
08-11 LivePlan：上下文单调递增、轨迹末尾最贵，所以"执行前阻断"是复合式节省（一个 2000 token 垃圾观察 × 剩余 30 步 = 6 万 token·次）——省在不让错误观察污染后续每一步。
08-13 EvoX Genesis：被接受版本历史 = 稳定前缀 → 97.4% prefix cache 命中 → 120 小时 / 25 万行 / $44 从零造出 C 编译器——省在持久世界的稳定前缀。

本篇补上第五块拼图：冻结的规格书，是一份"意图缓存"。它把"目标"固定下来，让实现和核验两轮都对着同一个不变靶心，避免了"边写边猜意图、反复推倒重来"的 aimless exploration。意图一旦冻结，模型不再为"我到底要做什么"反复烧 token——这是比 KV cache 更上游的一层缓存。

两个值得记的推理侧 tradeoff

不自动修编译错误：agent 故意不自我修复语法/类型/单测失败，让信号作为独立信号暴露，在独立会话修。这是用"一次额外会话"换"主循环上下文不被噪声污染"——和 LivePlan"执行前阻断"共享同一个直觉：让错误信号保持可见，比让它被悄悄消化更省总账。
系统提示词 25 万字符：把反复失败沉淀成持久规则，等于把"昂贵的手工审阅"部分自动化。规则进上下文一次，后续每个会话都受益——这本身就是一种静态的、可复用的上下文缓存，对应 Davis et al. 把失败转成 1.16 MLOC 治理基座的同向实践。

与同类成本基准的横向位置

Bun 重写：53.5 万行 Zig→Rust，11 天，64 agent 并行，靠百万断言测试套件做 oracle——有 oracle 锚定，所以可并行摊薄。
本案例：71.7 万行，3 天，$2,430，无 oracle、全链路无人审阅——贵在"串行 31 轮审计"而非"算力"，但换来了"无 oracle 场景下的可验收性"。
两者的成本结构正好互补：Bun 用 oracle 换并行，本案例用过程结构换 oracle 的缺席。

总结

把今天拆的东西压成五句话：

瓶颈不在"写"，在"审"：AI 把写变便宜了，却把评审挤爆了（评审时间最多 +91%，交付持平）。
与其事后审计代码，不如事前审计意图：先写一份形式化规格书，反复对账源码磨到零发现，再冻结它。
"裁判"的分离在参照物，不在身份：同一 agent 的新会话，对账一份代码存在之前就冻结的文档——这恰好绕开了"模型不能自校正"的死穴。
评测体系被重写了：没有 oracle 时，"评测"= 两道审计循环 + "连续两次零发现"的停止判据，而非跑测试看通过率。
推理加速的隐藏维度是"意图缓存"：把正确性前置、冻结目标，等于在最上游消掉了 aimless exploration 的 token 浪费——与本周 Reasonix/TokTier/LivePlan/EvoX 的"省"是同一家族。

最该记住的一句：这份论文的价值不在"71 万行一次跑通"（单案例，谨慎），而在它把一个可复制的操作纪律和完整证据链摊开给你看。 当产业界同一天把 github/spec-kit 顶上 Trending，你可以相信：spec-driven，已经从口号变成了可打点的工程实践。