Bun的AI驱动Rust重写：百万行代码迁移手册

引言

这个标题令人难以忽视：据报道，Bun 使用动态的 Claude Code 工作流，在 11 天内将主要实现从 Zig 迁移到了 Rust。公开的报道描述了数千次提交、多达 64 个 Claude 智能体、约 78 万行 Rust 代码、每个实现单元配备两名对抗性审查者，以及从无法编译的代码逐步演进到能通过测试套件并上线的移植版本。

错误的教训是语言重写已变成一键式任务。有用的教训是实现吞吐量与验证吞吐量现在已成为独立的工程问题。

AI 智能体生成代码的速度比人类团队阅读代码的速度更快。一旦出现这种情况，传统的拉取请求审查就不再能作为主要的安全机制。团队需要一个系统，将大规模的、概率性的变更转化为由机器可验证证据支持的小型断言。

Bun 后来的生产报告使这一点异常具体。团队报告了 19 个已知回归问题，全部随后修复；11 轮安全审查；对解析器进行持续的、覆盖引导的模糊测试；以及在约 78 万总行代码中、unsafe 块内约有 2.7 万行 Rust 代码。这些事实并未削弱迁移故事，而是展示了在令人印象深刻的演示结束后，严肃的迁移工作是什么样子。

本指南将该经验转化为可复用的验证手册。目标不是复制 Bun 的规模，而是为任何迁移提供一种方法——语言移植、框架替换、API 现代化、数据库转换或全仓库重构——在这些场景中，AI 编码智能体编写的代码量超出了团队能够逐行负责任审查的范围。

关键要点

• Bun 的重写表明 AI 智能体可以压缩实现时间，但这并未表明验证时间可以被消除。
• 可转移资产是迁移系统：书面行为契约、风险地图、小规模试点、隔离的工作单元、独立审查者、确定性门控和可恢复的提交。
• 编译器和遗留测试套件捕捉不同的故障类别。两者都无法捕捉到每一种跨语言语义不匹配、发布模式差异、性能回归或不安全边界。
• 大型差异需要基于证据的审查。人类应审查契约、风险热点、反例、测试缺口以及部署决策，而不是假装每一行生成代码都受到同等程度的审查。
• 团队无需尝试百万行重写即可采用相同模式：要求智能体一次证明一个片段的行为，仅在取得可衡量的结果后才授予更广泛的自主权。

Bun 实际做了什么——以及标题遗漏了什么

工程叙述在大规模代码生成之前就开始了。

据报道，Jarred Sumner 花费了大约三个小时创建 PORTING.md，该文件将重复的 Zig 模式映射到 Rust。另一个工作流分析了结构字段，提出了 Rust 生命周期，将这些选择发送给两名对抗性审查者，并将结果序列化到 LIFETIMES.tsv 中。这些工件也经过了人工审查。

首先

实施试点覆盖了三个文件，而非整个仓库。对于每个文件：

1. 一名智能体实现了Rust版本。
2. 两名新智能体审查了行为等价性及对迁移文档的合规性。
3. 另一名智能体应用了获批的修复方案。

仅在此试点之后，工作才扩展到1,448个Zig文件。

首次大规模运行失败。智能体共享工作区，并使用了诸如 git stash、git stash pop 和 git reset --hard 等命令。它们的变更相互干扰。随后工作流程被修改，禁止使用不安全的协调命令，转而采用四个工作树，每个工作树分配16个智能体。

这一细节比峰值代码生成速率更为关键。并行编程本质上是一个分布式系统问题。共享状态、冲突写入、代价高昂的全局操作、所有权及恢复机制，均需明确的规则。

生成的代码无法立即运行。Bun将编译器错误视为队列，每次只推进一个crate。某一时刻，约16,000个编译器错误被分配给智能体。循环中使用了一个修复者、两个审查者和一个应用智能体，同时限制了 cargo check 和Git操作等昂贵命令的运行频率。

这并非神奇的翻译过程，而是由确定性反馈驱动的阶段性收敛。

Anthropic的动态工作流公告称，在初始撰写时，已有99.8%的现有测试套件通过，同时明确指出该移植尚未投入生产环境。Bun后续文章则涵盖了后续工作：安全审查、模糊测试、生产环境回归、语义修复及不安全代码的缩减。

综合来看，这些资料描述了两种不同的里程碑：

• 实现完成度足以合并
• 证据充分度足以安全运行

需知术语：移植、预言机、差异测试与不安全代码表面

这些定义至关重要，因为团队只有在就证据需证明的内容达成共识后，才能验证迁移是否成功。它们还将智能体的置信声明与外部可核查的结果区分开来。

移植

移植指在新的语言、运行时、平台或框架中重新实现软件，同时保留一组定义好的行为。

"保留行为"需明确边界。移植可能保留公共API和输出，同时有意更改内部架构、性能特征、错误信息或不支持的边缘情况。

行为契约

行为契约是新的实现必须保留的属性清单。

它可能包括：

• 输入与输出
• 错误行为
• 排序
• 副作用
• 并发语义
• 资源限制
• 支持的平台
• 性能预算
• 可观测性要求

现有代码包含行为，但并非所有现有行为都是有意为之。契约将需求与历史遗留问题区分开来。

测试预言机

测试预言机用于判断输出是否正确。

单元测试断言是一种预言机。参考实现、协议规范、黄金文件、数据库不变约束或人工制定的规则也可充当预言机。

Anthropic关于长期运行的指导…

科研编码强调，自主工作需要有参考文献、可衡量目标或测试套件，以便智能体能够判断自身是否在取得进展。

差异测试

差异测试将相同的输入分别发送至新旧实现，然后对比可观察到的结果。

当旧实现值得信赖但缺少完整形式化规范时，该测试尤为有用。结果一致并不能证明两种实现都正确，但结果不一致则能形成精确的调查线索。

蜕变测试

蜕变测试用于在难以编写精确预期输出时，检验多次执行之间的关联性。

示例包括：

• 序列化并解析某个值后，该值应保持不变。
• 重新排序独立输入不应改变集合形式的结果。
• 对幂等迁移执行两次，第二次运行时状态不应发生改变。
• 使用相同幂等键重试操作不应产生重复的副作用。

不安全边界

不安全边界是指目标语言常规保障被削弱或绕过的代码区域。

在Rust中，unsafe 可能在C或C++外部函数接口（FFI）边界、自定义分配器内部或底层运行时集成时是必需的。原始数量并非最终定论。团队需要为每个不安全边界明确所有权、不变量、测试以及具体计划。

逃逸缺陷

逃逸缺陷是指在本应检测到该缺陷的关口——合并、金丝雀部署、候选版本测试或生产环境上线之后——才发现的、由迁移引发的错误。

逃逸缺陷反映的是验证系统本身的反馈，而不仅仅是实现层面的问题。

因果链：为何更快的生成需要更强的验证

智能体并行机制改变了实现的成本结构。如果64个工作线程同时翻译文件，代码生成时间可能会大幅缩短。依赖性图谱、目标语言语义以及共享测试环境并不会消失。吞吐量只是将瓶颈转移到了下游。

瓶颈一：集成

各自合理的文件在编译时可能组合失败。

Bun约16,000个编译错误以及循环的crate依赖关系，说明了局部翻译与全局一致性之间的差距。编译器对于类型、所有权、生命周期、名称及某些控制流属性来说是极佳的确定性判定工具，但它并非产品行为的判定工具。

瓶颈二：语义等价性

Bun记录了一些错误，其中看似各语言极为相似的代码，行为却大相径庭。

示例包括：

• 位于Rust debug_assert! 中的副作用在发布构建中消失，而类似的Zig断言仍会评估其参数。
• 一个急切的 unwrap_or 表达式触发了本该保持惰性的行为。
• 不同实现中字节切片与边界语义存在差异。
• 奇数长度的UTF-16输入暴露了崩溃问题。

这些正是表面审查所遗漏的失败情形，因为翻译后的代码看起来合情合理。

瓶颈三：审查相关性

如果同一个模型使用相同的上下文和假设来编写并审查改动，它可能会再现

原始错误。

Anthropic 的 Claude Code 最佳实践文档建议使用全新的审查者上下文。审查者通过差异对比和标准进行评估，而不继承作者的推理过程。独立性虽不能保证正确性，但能减少共享上下文带来的偏见。

瓶颈 4：运营证据

测试可能通过，但延迟翻倍、内存使用增长、某个操作系统目标出错，或可观测性消失。

变更规模越大，团队越可能在部署后才发现违反的需求。正因如此，迁移计划必须包含金丝雀发布、回滚、遥测对比，以及一套将每个遗漏缺陷转化为新合约规则或测试的流程。

因果结论很简单：

AI 无法消除迁移成本。它只是将成本从编码转向规范制定、工具设计、证据审查和部署控制。

忽视这一转变的团队可能快速完成代码生成，然后花费数月时间确认重写是否真正有效。

面向 AI 驱动迁移的验证架构

该架构包含四个层面。

1. 合约层面

合约层面存储以下内容：

• 公共行为
• 兼容性承诺
• 有意的变更
• 支持的平台矩阵
• 性能预算
• 安全约束
• 可观测性要求

由人工维护该层面，并通过代码库进行版本管理。

2. 执行层面

执行层面包含独立的实现代理。

每个代理接收：

• 一个迁移单元
• 相关的源文件
• 已批准的合约
• 语义映射
• 范围有限的工具
• 针对性的检查

代理不能修改合约或全局测试。它仅编辑分配的范围，并返回提交和证据。

3. 验证层面

验证层面独立于实现。

它可执行以下操作：

• 编译候选代码
• 运行针对性及全局测试
• 执行新旧差异对比检查
• 对解析器和协议边界进行模糊测试
• 扫描安全敏感代码
• 对代表性工作负载进行基准测试
• 让新审查者寻找反例

验证代理可提议测试，但由确定性 CI 决定关口是否通过。

4. 发布层面

发布层面控制集成和生产环境暴露。

它负责：

• 按依赖顺序合并
• 生成可复现的制品
• 通过不可变版本或哈希标识构建
• 在可能情况下运行影子流量
• 逐步扩大金丝雀发布范围
• 监控服务级别指标
• 保留经过测试的回滚路径

AI 可作为编排和证据层位于这些层面之间。团队可使用任务分配迁移片段、隔离工作树、附加合约、收集测试输出，并在推进前要求审查。

关键边界在于：编排仅协调证据，而非将代理的成功声明转化为发布权限。

示例场景：将支付服务从 Python 迁移到 Go

假设有一个 12 万行的 Python 支付服务正在迁移到 Go。业务目标是减少

尾部延迟并简化部署。

一个危险的操作提示可能是：

用 Go 重写此服务并让所有测试通过。

该提示未定义事务语义、错误行为、金额精度、幂等性和上线流程。

第一步：编写契约

团队为每个端点记录以下内容：

• 请求和响应模式
• 授权规则
• 幂等键行为
• 货币舍入规则
• 重试语义
• 数据库事务
• 事件顺序
• 错误码
• 遥测需求

同时标记有意变更，例如移除 Python 特定的调试标头。团队定义支持的平台和依赖矩阵，然后设定 p95 和 p99 延迟预算以及峰值内存上限。

第二步：选择三个试点模块

团队选择：

1. 纯货币格式化模块
2. 带数据库副作用的幂等存储库
3. 只读 HTTP 端点

第一个测试机械翻译。第二个测试事务和并发。第三个测试 HTTP 兼容性。

每个模块由一名实现代理负责处理。初次评审人员仅获得契约、旧源码、建议差异和验证命令。

第三步：将旧服务用作差异验证器

对两个版本回放经过处理的的历史请求语料库。

仅当契约允许差异时才对响应进行标准化处理，然后进行比较。对于写入路径，两个实现均针对一次性数据库快照运行。比较生成的数据行和发出的事件。

随后进行蜕变测试：

• 重复相同的幂等键
• 更改无害的 JSON 键顺序
• 引入重试时序变化
• 测试边界货币值

第四步：对新服务进行影子流量和金丝雀发布

在启用生产环境写入之前，Go 服务接收影子流量，写入操作被禁用或重定向到独立接收端。

团队比较：

• 延迟分布
• 错误分类
• 依赖调用
• 调用链形状
• 内存使用
• 事件行为

然后从低风险商家群体发送 1% 的金丝雀流量。

扩展条件需满足：

• 零无法解释的财务差异
• 错误率持平
• 延迟在约定预算内
• 成功完成回滚演练

实现过程仍可快速推进。安全性源于将"重写服务"转化为可观测的断言。

该示例也说明了领域专业知识为何不可或缺。代理可以翻译代码，但支付专家知道重复事件、舍入差异和重试行为属于业务需求。

阶段 0：定义迁移契约和停止条件

在任何代理编辑代码之前，需确定何种状态可视为同一产品。

清点清单：

• 公共 API
• CLI 行为
• 文件格式
• 数据库影响
• 环境变量
• 遥测数据
• 用户可见的错误消息
• 支持的平台
• 性能特性

将每个属性标记为以下类别之一：

• 保留
• 有意变更
• 弃用
• 未知

未知项并非允许猜测。它们将成为探索任务。

运行旧系统，搜索问题和变更日志，检查生产环境调用链，或咨询维护人员。Bun 的迁移前源码树

重组通过仅移动提交保留 Git 历史，使追溯成为有意为之的要求，而非附带损害。

定义硬性停止条件。在以下情况下停止扩展：

• 试点不匹配率超过阈值。
• 工作人员反复修改受保护的全局测试。
• 编译器错误队列的增长速度快于其关闭速度。
• 目标性能未达到预算。
• 无法构建回滚工件。
• 证据不完整或不可读。

停止操作可保护项目免受沉没成本升级的影响。

合同必须与执行分开控制。代理不得通过削弱要求来“修复”失败的测试。合同变更需要人工审核的修订，说明旧行为为何已过时或不正确。

第一阶段：在大规模生成前构建语义映射

为常见、微妙或危险的源到目标模式创建显式映射。

涵盖以下领域：

• 所有权和生命周期规则
• 可空性
• 异常和错误处理
• 整数溢出
• 时间计算
• 字符串编码
• 并发原语
• 分配器所有权
• FFI
• 调试与发布行为
• 平台特定代码

Bun 的 PORTING.md 和 LIFETIMES.tsv 就起到了这一作用。

它们的价值不仅限于更好的提示。它们为数百名工作人员提供了共享的语义策略。没有这样的映射，每个代理都会发明自己的翻译方法，而不一致性会成为集成问题。

让独立的代理攻击映射：

• 给一个审阅者提供源语言语义。
• 给另一个提供目标语言风险。
• 给第三个提供代表性代码示例。
• 要求提供具体的反例。

人类应检查最高风险的规则，尤其是涉及内存所有权、并发、安全边界、持久性和仅发布行为的规则。

对映射进行版本控制。每个新发现的不匹配都应更新规则，识别受影响的迁移单元，并触发有针对性的重新验证。

语义映射是一个活的规范，而不是一开始就粘贴一次的提示。

第二阶段：设计故意困难的试点

不要只选择最简单的文件。

一个有用的试点包括三种形态：

1. 一个简单的代表性单元
2. 一个依赖权重较大的单元
3. 一个语义热点

Bun 在翻译 1448 个文件之前，使用了三个文件来验证“实施-审阅-修复”循环。确切的数字不如所涵盖的失败模式范围重要。

衡量试点过程，而不仅仅是其输出：

• 工作人员是否尊重文件所有权？
• 提交是否是原子的？
• 审阅者是否发现了真正的缺陷，还是主要产生了噪音？
• 修复者能否在不违反合同的情况下应用建议？
• 证据是否仍然可读？
• 每个接受的单元消耗了多少上下文和计算资源？

故意植入故障。添加一个微妙的发布模式差异、一个边缘案例装置或一个性能阈值，并确认验证系统能够检测到它。

一个只通过了干净示例的测试装置尚未经过测试。

只有当试点产生稳定、可重复的证据时，才应开始扩展。如果后续提示、模型或工具策略发生重大变化，则重新运行小规模试点。工作流配置是生产代码，值得进行回归测试。

第三阶段：以隔离、所有权和原子提交进行扩展

创建与依赖图对齐的迁移单元。

文件级分区很方便，但当行为跨越模块时，它可能是错误的边界。为每个单元分配一个编写者，并使所有权可机器读取。工作人员可以读取依赖项，但只能编辑其范围，除非他们请求协调变更。

在实际可行的情况下，使用单独的工作树、容器或临时虚拟机。

Bun 的共享工作空间失败说明了原因。限制叶型工作人员使用破坏性的 Git 命令和昂贵的全局构建命令。让协调员执行有序的集成。

短期凭证和网络白名单减少了提示注入或依赖项泄露的影响。Anthropic 的沙盒指导将文件系统和网络边界描述为更安全自主性的基础。

每个接受的单元都应产生一个包含以下内容的原子提交：

• 源标识符
• 适用的合同规则
• 执行的命令
• 测试和检查输出
• 审阅者结果
• 批准的例外

Git 既成为协调机制，也成为恢复机制。

Anthropic 的长期运行工作流指导建议在每次提交前进行有意义的提交和测试，因为可恢复的历史可以防止长时间代理运行变成一个难以理解的工件。

不要优化每分钟的行数。优化每小时已验证的单元数。

高生成吞吐量与不断增长的集成队列相结合是负面进展。

第四阶段：将编译器错误和测试视为队列，而非证明

编译器输出创建了结构化的工作。

按所有权单元或依赖层对错误进行分组，删除重复的级联效应，并在解决表面症状前修复根本原因。

除非合同明确允许，否则禁止走捷径，包括：

• 空桩代码
• 被忽略的结果
• 广泛的 allow 属性
• 被禁用的断言
• 占位实现
• 仅为使候选通过而更改的测试

以逐步扩大的范围运行测试：

1. 针对变更模块的单元测试
2. 公共边界的契约测试
3. 跨依赖的集成测试
4. 跨平台测试套件
5. 完整回归测试

将失败输出保留为测试产物。仅凭最终通过的运行记录而无历史数据，可能掩盖开发过程中反复削弱检查标准的问题。

在可行条件下，将测试编写与功能实现分离。

可由一名智能体从契约与旧实现中推导边界案例，另一名智能体编写移植代码。锁定已批准的兼容性测试，使实现人员无法修改。新审查者应评估代码是否因正确原因通过测试。

Bun 的生产回归缺陷揭示了绿色测试套件与语义完整性之间的差距。

某次仅在生产环境出现的 HMR 异常源于 debug_assert! 内的副作用。奇数长度的 UTF-16 崩溃则反映了不同的切片处理行为。每个被消除的缺陷都应同时成为永久性回归测试与新的语义映射规则。

第五阶段：引入差异测试、模糊测试与性能预算

对旧版与新实现运行相同的测试语料库。

对比指标：

• 退出代码
• 标准化输出
• 错误分类
• 副作用
• 数据库状态
• 触发的系统事件
• 追踪日志

构建边界值生成器，覆盖：

• 空输入
• 最大尺寸
• 异常编码格式
• Unix 纪元左右的时间值
• 并发竞态条件
• 平台相关路径
• 资源耗尽场景

持续对解析器与协议边界进行模糊测试。

据 Bun 报告，其覆盖率引导的模糊测试器执行了约 1,000 亿次解析器代码，并生成了约 15 个修复拉取请求。具体数字取决于工作负载。可复用的模式在于：将崩溃发现与可复现测试、智能体建议的修复方案、以及人工审核的拉取请求相连接。

当用户依赖性能表现时，性能即构成行为的一部分。

基准测试指标：

• 冷启动速度
• 吞吐量
• p50 延迟
• p95 延迟
• p99 延迟
• 峰值内存
• 二进制体积
• 构建时间
• 代表性工作负载下的 CPU 占用

比较分布特征而非平均值。在迁移前设定性能预算，防止团队在投入重写后为回归缺陷寻找理由。

同时执行浸泡测试。内存泄漏、描述符泄漏、队列增长、分配器碎片化及罕见竞态条件可能需要数小时乃至数日才能暴露。

具备更强内存安全保证的语言可消除整类缺陷，但仍可能引入不同的内存分配、调度机制或性能行为。

单独审查不安全代码、外部函数接口与安全边界

将以下类别作为独立审查类型分别处理：

• unsafe 代码块
• 外部函数调用
• 裸指针
• 自定义分配器
• 加密边界
• 解析器
• 反序列化器
• 权限检查
• 身份验证逻辑
• 持久化边界

根据源报告数据，Bun 约 78 万行 Rust 代码中约有 2.7 万行位于 unsafe 代码块内，其中大部分与 C/C++ 集成相关。

此类代码区域需要比常规代码审查更严格的处理。

要求在每个不安全边界附近添加不变量注释：

• 必须满足什么条件？
• 由谁建立该不变量？
• 指针保持有效的时间范围？

哪个线程拥有该值？

• 哪个测试覆盖了这个条件？

将重复的不安全模式分组到经过审查的包装器后面。按所有者跟踪不安全的代码行和代码块，而不是将总数视为虚浮指标。

使用：

• 静态分析
• 消毒器
• 依赖审计
• 模糊测试
• 手动安全审查

Bun 的 11 轮安全审查证明了持续加固的过程，而非缺陷不存在的证据。

自动化安全审查应补充领域审查，尤其是在身份验证、沙箱逃逸、机密信息和供应链变更方面。

审查迁移机制本身。代理会执行仓库内容、构建脚本和工具输出。受损的依赖项或源代码中的隐藏指令可能影响运行。

文件系统隔离、网络限制、作用域令牌和不可变 CI 检查可降低此风险。

分阶段发布并在需要前演练回滚

合并不等于发布。

从已知提交、工具链、依赖锁定和证据清单中构建版本化工件。保持旧实现可构建。

如果新旧二进制文件可以共存，添加运行时开关或路由层，
而不是不可逆地替换路径。

当副作用可以隔离时，从影子执行开始。
然后按以下顺序进行金丝雀发布：

• 内部用户
• 低风险租户
• 平台
• 区域
• 流量百分比

为以下内容定义自动回滚阈值：

• 正确性不匹配
• 崩溃率
• 延迟
• 内存
• 错误类别
• 支持信号

即使自动阈值未触发，人类必须保留停止扩展的能力。

演练回滚。
确认：

• 旧工件成功启动。
• 模式保持兼容。
• 队列中的工作可以排空。
• 可观测性可识别每个请求由哪个实现处理。
• 测量的回滚时间达到运营目标。

从未执行过的回滚文档只是假设。

每次缺陷泄露后，更新合约、语义映射、测试语料库和风险模型。

Bun 的 19 个已知回归很有用，因为它们暴露了重复的翻译风险。当新实现可运营且团队从中学习后——而非生成的差异合并后——迁移才算完成。

可复用的 AI 迁移策略与证据清单

以下 YAML 设计为可复用的团队工件。根据仓库调整命令、阈值和所有者。

编排系统可将此策略附加到迁移任务，并要求在审查前提供证据清单。

ai_migration:  
  name: payments-python-to-go  
  contract: docs/MIGRATION_CONTRACT.md  
  semantic_map: docs/PORTING_RULES.md  
  old_reference: artifacts/payments-python@sha256:OLD  
  new_candidate: artifacts/payments-go@sha256:NEW  

  worker_policy:  
    isolation: ephemeral_worktree  
    one_writer_per_unit: true  
    forbidden_commands:  
      - "git reset --hard"  
      - "git stash"  
      - "git push --force"  
    editable_paths: ["cmd/", "internal/", "tests/migration/"]  
    protected_paths: ["tests/contracts/", "docs/MIGRATION_CONTRACT.md"]  

  required_gates:  
    compile: "go build ./..."  
    unit: "go test ./..."  
    contracts: ".  

/scripts/run-contract-tests.sh"
differential: "./scripts/compare-old-new.sh --corpus fixtures/replay"
fuzz: "./scripts/fuzz.sh --hours 24 --unique-crashes 0"
security: "./scripts/security-scan.sh --severity high"
performance:
p99_latency_regression_pct: 5
peak_memory_regression_pct: 10
platforms: [linux-amd64, linux-arm64]

independent_review:
fresh_context: true
reviewers_per_unit: 2
require_counterexample_search: true

rollout:
shadow_hours: 48
canary_percentages: [1, 5, 20, 50, 100]
rollback_artifact_required: true
rollback_drill_required: true

evidence_manifest:
include:
- contract_version
- source_and_target_commits
- changed_units
- commands_and_exit_codes
- differential_mismatches
- fuzzing_summary
- benchmark_distributions
- unsafe_or_ffi_inventory
- reviewer_findings
- approved_exceptions
- rollback_drill_result

本策略有意阻止实施人员编辑合约或已批准的合约测试。

它要求：

• 参考制品
• 独立评审
• 量化性能限制
• 发布证据
• 经过测试的回滚路径

例外情况是允许的，但必须记录在案并经过批准，而非隐藏在提示词中。

衡量已验证进展，而非生成量

代码行数、智能体数量和运行天数是有趣的产能指标，但它们并不能衡量产品成功与否。

请使用平衡的迁移记分卡。

已验证单元吞吐量

追踪满足以下条件的迁移单元：

• 编译通过
• 通过定向合约检查
• 接受独立评审
• 集成时无回归

衡量单位时间内被接受的单元数量。

差异闭合度

追踪发现的差异，并确认每个差异是否：

• 已解释
• 已修复
• 被批准为有意为之
• 仍未解决

逃逸缺陷

追踪那些通过本应拦截它们的关卡但未能被捕获的缺陷。

每个逃逸缺陷都应对应缺失的合约规则、测试、预言机、评审步骤或发布阈值。

人工投入

衡量人类在以下方面投入的时间：

• 定义合约
• 解决歧义
• 评审高风险代码
• 调查差异
• 操作部署

AI 可以缩短实施时间，同时提升规范质量。这是良好的权衡，而非自动化失败。

计算与工具成本

衡量每个被接受的单元对应的模型、计算和工具总成本。

动态工作流可能比普通会话消耗更多令牌。并行化在能减少高价值工作的等待时间且不造成更大验证积压时是合理的。

迁移后可维护性

追踪：

• 启动时间
• 构建速度
• 变更失败率
• 评审延迟
• 缺陷密度
• 不安全模块的所有权
• 调试难易度
• 操作文档质量

一个快速交付但对团队仍显不透明的移植项目，只是转移了技术债务而非真正消除它。

团队如何在不重写百万行代码的情况下启动

选择一个具有实时参考实现且界限明确的迁移任务，例如：

• 一个 SDK 版本变更
• 一个框架子系统
• 一个 CLI 命令
• 一个服务端点

编写一个

单一页面行为合约及三个聚焦风险的试点案例。

将实施与审查拆分为独立的智能体任务，使其上下文保持独立。

实施前：

1. 锁定验收检查项目。
2. 要求实施者提交代码提交和证据，而非文字描述。
3. 要求审查者找出反例并识别缺失的测试。
4. 在模型外运行CI中的检查。
5. 试点成功后才扩展至下一依赖层级。

保留完整运行记录：

• 提示词
• 模型
• 工具范围
• 源提交
• 目标提交
• 变更路径
• 检查项
• 失败项
• 审查者发现
• 异常情况
• 成本
• 最终决策

该记录使团队能对比工具链版本并追溯缺陷，无需猜测智能体所见内容。

采用简单的授权规则：

自主权必须靠实力赢得。

持续产生通过验证单元的工作流可获得更广的文件范围或更长的无人值守运行时间，但不会自动获得部署权限。

能力、证据与授权始终分离。

局限性：Bun案例未能证明的部分

Bun是一个非典型项目。

其创建者主导了迁移工作，对代码库有深入了解，并拥有直接架构决策权。旧实现拥有庞大测试套件，Rust提供强编译器反馈，项目可利用大规模并行计算。

多数团队无法同时具备这些优势。

该案例由Anthropic提供，原始文章指出工作使用了预发布的Claude Fable 5模型。这是有价值的一手证据，但并非独立供应商对比。

关于人工团队所需时长的论断属于反事实估算。团队不应仅凭一次成功迁移就做出采购决策。

报告的19个回归问题为已知缺陷，不保证完整统计。模糊测试执行和安全审查轮次衡量的是工作量，而非缺陷的不存在性。

最有依据的结论相对谨慎：

当与强确定性反馈和专家编排结合时，大型AI驱动迁移是可行的，但在代码生成完成后，其风险仍是工程问题。

该结论仍有意义。团队可尝试此前因成本而搁置的现代化项目，前提是为规格说明、验证和受控部署分配与实施规模相当的预算。

迁移实践检查清单

• 定义保留、变更、弃用及未知行为。
• 盘点平台、性能、遥测、错误和副作用合约。
• 为高风险源到目标模式构建语义映射。
• 保护合约及已批准的测试不受实施人员影响。
• 在仓库级推广前先运行困难试点单元。
• 隔离编写者，限制破坏性Git及网络操作。
• 要求原子提交包含命令、输出及合约引用。
• 对高风险单元使用全新上下文的对抗性审查者。
• 运行编译器、单元测试、合约测试、集成测试及跨平台门禁。
• 在代表性语料库上对比新旧实现。
• 添加变形测试、

模糊测试、消毒器及性能检查。

• 盘点unsafe、FFI、认证、解析器及持久性边界。
• 保留可重现的回滚制品，并进行回滚演练。
• 通过影子发布和金丝雀阶段逐步推出，并设置自动停止阈值。
• 将每个逃逸的缺陷转化为契约或验证改进。
• 衡量已验证单元、不匹配项、人工投入、成本及可维护性。

常见问题

Bun 用 Rust 重写了什么？

Bun 将此前用 Zig 编写的主要实现迁移到了 Rust 中。已发布的内容大致描述了约 78 万行 Rust 代码及高度并行化的 AI 辅助工作流程，随后进行了广泛的测试、安全审查、模糊测试及生产环境加固。

AI 是否在没有人工审查的情况下完成了 Bun 的 Rust 重写？

不。人工编写的迁移规则、手动制品审查、隔离的工作流程、编译器反馈、独立的审查代理、安全审查、模糊测试及生产发布控制都发挥了重要作用。这一案例更适合理解为 AI 加速的工程实践，而非无人值守的代码转换。

为什么在语言迁移中，现有的测试不足以胜任？

现有测试通常只覆盖了部分观察到的行为。它们可能遗漏仅存在于发布版本的语义、平台差异、性能回退、不安全边界、遥测变化或测试套件中从未编码的边缘情况。

代码迁移中的差分测试是什么？

差分测试使用相同的输入运行新旧两种实现，并比较它们的可观察输出及副作用。当旧系统可信但缺乏完整的正式规范时，该方法尤为有用。

为什么实施代理和审查代理应使用独立的上下文？

新的审查者不太可能继承编写代理的假设和推理错误。审查者可以专注于契约、差异、证据及反例，而非维护产生变更的实现路径。

迁移过程中，团队应如何审查 unsafe Rust 代码？

每个 unsafe 块或 FFI 边界都应有指定的负责人、文档化的不变式、针对性测试，以及关于指针有效性、生命周期和线程所有权的清晰说明。静态分析、消毒器、模糊测试、依赖审查及人工安全审查应与常规代码审查分开进行。

AI 辅助迁移应跟踪哪些指标？

跟踪已验证单元的吞吐量、不匹配项的闭合速度、逃逸缺陷、人工投入、计算成本、发布健康度及迁移后的可维护性。生成的代码行数和代理数量是容量指标，而非正确性的证明。

小型团队能否在不运行数十个代理的情况下使用这份指南？

可以。从单一有界组件、书面行为契约、三个以风险为重点的试点、独立的实施与审查上下文、确定性的 CI 门控以及经过测试的回滚路径开始。仅当工作流程反复产生可验证的结果后再扩展规模。

相关工具

• Bun：一款集 JavaScript 和 TypeScript 于一体的工具包，其 Rust 迁移为主要案例研究。

本操作手册。

• Rust：一种系统编程语言，具备强大的编译时安全保证和显式的 unsafe 边界。
• Claude Code：Anthropic 的代理式编码环境，用于源材料所述的动态工作流。
• GitHub Actions：适用于确定性编译、测试、安全、基准测试和证据门的 CI/CD 平台。
• cargo-fuzz：基于 libFuzzer 构建的 Rust 项目标准模糊测试工具。
• Miri：可检测不安全代码中某些未定义行为的 Rust 解释器。

相关链接

• Bun：用 Rust 重写 Bun：Bun 官方关于重写、生产环境强化、模糊测试及已知回归问题的工程说明。
• Bun 源码仓库：包含 Rust 实现、问题、测试及迁移历史的 Bun 官方仓库。
• Anthropic：引入动态工作流：Anthropic 对 Bun 迁移过程中使用的多智能体工作流的描述。
• Claude Code 最佳实践：关于任务结构、全新审查上下文、测试及长时间运行编码工作流的官方指南。
• Claude Code 沙箱化：Anthropic 对文件系统和网络隔离以实现更安全的自主编码的说明。
• Rustonomicon：认识安全与不安全：关于安全代码与不安全代码边界的 Rust 官方指南。
• GitHub CODEOWNERS 文档：GitHub 关于机器可读的所有权及必需审查工作流的文档。

总结

Bun 的 Rust 重写证明，AI 编码代理能够大幅压缩实现时间，同时也说明了为何验证必须成为第一等工程体系。契约、语义映射、隔离工作单元、独立审查、差异测试、模糊测试、性能预算及分阶段发布，是将生成代码转化为可信迁移证据的关键。

实际经验绝非简单复制智能体数量或代码行数，而是将迁移拆分为有边界的断言，为每一项断言提供确定性证明，只有当工作流反复产生可靠结果后，才逐步扩大自主性。

大规模 AI 辅助重写的完成节点，并非生成代码被合并之时，而是新系统通过验证、可操作、可恢复、可理解之日。