For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/zh/articles/bun-s-ai-powered-rust-rewrite.md.
基于Bun从Zig到Rust的AI辅助迁移实践验证手册，涵盖行为契约、隔离编码代理、差分测试、模糊测试、非安全代码审查、进度指标及安全发布机制。
这个标题令人难以忽视：据报道，Bun 使用动态的 Claude Code 工作流，在 11 天内将主要实现从 Zig 迁移到了 Rust。公开的报道描述了数千次提交、多达 64 个 Claude 智能体、约 78 万行 Rust 代码、每个实现单元配备两名对抗性审查者，以及从无法编译的代码逐步演进到能通过测试套件并上线的移植版本。
错误的教训是语言重写已变成一键式任务。有用的教训是实现吞吐量与验证吞吐量现在已成为独立的工程问题。
AI 智能体生成代码的速度比人类团队阅读代码的速度更快。一旦出现这种情况，传统的拉取请求审查就不再能作为主要的安全机制。团队需要一个系统，将大规模的、概率性的变更转化为由机器可验证证据支持的小型断言。
Bun 后来的生产报告使这一点异常具体。团队报告了 19 个已知回归问题，全部随后修复；11 轮安全审查；对解析器进行持续的、覆盖引导的模糊测试；以及在约 78 万总行代码中、unsafe 块内约有 2.7 万行 Rust 代码。这些事实并未削弱迁移故事，而是展示了在令人印象深刻的演示结束后，严肃的迁移工作是什么样子。
本指南将该经验转化为可复用的验证手册。目标不是复制 Bun 的规模，而是为任何迁移提供一种方法——语言移植、框架替换、API 现代化、数据库转换或全仓库重构——在这些场景中，AI 编码智能体编写的代码量超出了团队能够逐行负责任审查的范围。
工程叙述在大规模代码生成之前就开始了。
据报道，Jarred Sumner 花费了大约三个小时创建 PORTING.md，该文件将重复的 Zig 模式映射到 Rust。另一个工作流分析了结构字段，提出了 Rust 生命周期，将这些选择发送给两名对抗性审查者，并将结果序列化到 LIFETIMES.tsv 中。这些工件也经过了人工审查。
首先
实施试点覆盖了三个文件，而非整个仓库。对于每个文件：
仅在此试点之后，工作才扩展到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记录了一些错误，其中看似各语言极为相似的代码，行为却大相径庭。
示例包括：
debug_assert! 中的副作用在发布构建中消失，而类似的Zig断言仍会评估其参数。unwrap_or 表达式触发了本该保持惰性的行为。这些正是表面审查所遗漏的失败情形，因为翻译后的代码看起来合情合理。
如果同一个模型使用相同的上下文和假设来编写并审查改动，它可能会再现
原始错误。
Anthropic 的 Claude Code 最佳实践文档建议使用全新的审查者上下文。审查者通过差异对比和标准进行评估，而不继承作者的推理过程。独立性虽不能保证正确性，但能减少共享上下文带来的偏见。
测试可能通过，但延迟翻倍、内存使用增长、某个操作系统目标出错，或可观测性消失。
变更规模越大，团队越可能在部署后才发现违反的需求。正因如此，迁移计划必须包含金丝雀发布、回滚、遥测对比，以及一套将每个遗漏缺陷转化为新合约规则或测试的流程。
因果结论很简单：
AI 无法消除迁移成本。它只是将成本从编码转向规范制定、工具设计、证据审查和部署控制。
忽视这一转变的团队可能快速完成代码生成，然后花费数月时间确认重写是否真正有效。
该架构包含四个层面。
合约层面存储以下内容：
由人工维护该层面，并通过代码库进行版本管理。
执行层面包含独立的实现代理。
每个代理接收：
代理不能修改合约或全局测试。它仅编辑分配的范围，并返回提交和证据。
验证层面独立于实现。
它可执行以下操作：
验证代理可提议测试，但由确定性 CI 决定关口是否通过。
发布层面控制集成和生产环境暴露。
它负责：
AI 可作为编排和证据层位于这些层面之间。团队可使用任务分配迁移片段、隔离工作树、附加合约、收集测试输出，并在推进前要求审查。
关键边界在于：编排仅协调证据，而非将代理的成功声明转化为发布权限。
假设有一个 12 万行的 Python 支付服务正在迁移到 Go。业务目标是减少
尾部延迟并简化部署。
一个危险的操作提示可能是：
用 Go 重写此服务并让所有测试通过。
该提示未定义事务语义、错误行为、金额精度、幂等性和上线流程。
团队为每个端点记录以下内容：
同时标记有意变更，例如移除 Python 特定的调试标头。团队定义支持的平台和依赖矩阵，然后设定 p95 和 p99 延迟预算以及峰值内存上限。
团队选择：
第一个测试机械翻译。第二个测试事务和并发。第三个测试 HTTP 兼容性。
每个模块由一名实现代理负责处理。初次评审人员仅获得契约、旧源码、建议差异和验证命令。
对两个版本回放经过处理的的历史请求语料库。
仅当契约允许差异时才对响应进行标准化处理，然后进行比较。对于写入路径，两个实现均针对一次性数据库快照运行。比较生成的数据行和发出的事件。
随后进行蜕变测试：
在启用生产环境写入之前，Go 服务接收影子流量，写入操作被禁用或重定向到独立接收端。
团队比较：
然后从低风险商家群体发送 1% 的金丝雀流量。
扩展条件需满足：
实现过程仍可快速推进。安全性源于将"重写服务"转化为可观测的断言。
该示例也说明了领域专业知识为何不可或缺。代理可以翻译代码，但支付专家知道重复事件、舍入差异和重试行为属于业务需求。
在任何代理编辑代码之前，需确定何种状态可视为同一产品。
清点清单：
将每个属性标记为以下类别之一：
未知项并非允许猜测。它们将成为探索任务。
运行旧系统，搜索问题和变更日志，检查生产环境调用链，或咨询维护人员。Bun 的迁移前源码树
重组通过仅移动提交保留 Git 历史，使追溯成为有意为之的要求，而非附带损害。
定义硬性停止条件。在以下情况下停止扩展：
停止操作可保护项目免受沉没成本升级的影响。
合同必须与执行分开控制。代理不得通过削弱要求来“修复”失败的测试。合同变更需要人工审核的修订，说明旧行为为何已过时或不正确。
为常见、微妙或危险的源到目标模式创建显式映射。
涵盖以下领域：
Bun 的 PORTING.md 和 LIFETIMES.tsv 就起到了这一作用。
它们的价值不仅限于更好的提示。它们为数百名工作人员提供了共享的语义策略。没有这样的映射，每个代理都会发明自己的翻译方法，而不一致性会成为集成问题。
让独立的代理攻击映射：
人类应检查最高风险的规则，尤其是涉及内存所有权、并发、安全边界、持久性和仅发布行为的规则。
对映射进行版本控制。每个新发现的不匹配都应更新规则，识别受影响的迁移单元，并触发有针对性的重新验证。
语义映射是一个活的规范，而不是一开始就粘贴一次的提示。
不要只选择最简单的文件。
一个有用的试点包括三种形态：
Bun 在翻译 1448 个文件之前，使用了三个文件来验证“实施-审阅-修复”循环。确切的数字不如所涵盖的失败模式范围重要。
衡量试点过程，而不仅仅是其输出：
故意植入故障。添加一个微妙的发布模式差异、一个边缘案例装置或一个性能阈值，并确认验证系统能够检测到它。
一个只通过了干净示例的测试装置尚未经过测试。
只有当试点产生稳定、可重复的证据时，才应开始扩展。如果后续提示、模型或工具策略发生重大变化，则重新运行小规模试点。工作流配置是生产代码，值得进行回归测试。
创建与依赖图对齐的迁移单元。
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
文件级分区很方便，但当行为跨越模块时，它可能是错误的边界。为每个单元分配一个编写者，并使所有权可机器读取。工作人员可以读取依赖项，但只能编辑其范围，除非他们请求协调变更。
在实际可行的情况下，使用单独的工作树、容器或临时虚拟机。
Bun 的共享工作空间失败说明了原因。限制叶型工作人员使用破坏性的 Git 命令和昂贵的全局构建命令。让协调员执行有序的集成。
短期凭证和网络白名单减少了提示注入或依赖项泄露的影响。Anthropic 的沙盒指导将文件系统和网络边界描述为更安全自主性的基础。
每个接受的单元都应产生一个包含以下内容的原子提交：
Git 既成为协调机制，也成为恢复机制。
Anthropic 的长期运行工作流指导建议在每次提交前进行有意义的提交和测试，因为可恢复的历史可以防止长时间代理运行变成一个难以理解的工件。
不要优化每分钟的行数。优化每小时已验证的单元数。
高生成吞吐量与不断增长的集成队列相结合是负面进展。
编译器输出创建了结构化的工作。
按所有权单元或依赖层对错误进行分组，删除重复的级联效应，并在解决表面症状前修复根本原因。
除非合同明确允许，否则禁止走捷径，包括：
allow 属性以逐步扩大的范围运行测试：
将失败输出保留为测试产物。仅凭最终通过的运行记录而无历史数据，可能掩盖开发过程中反复削弱检查标准的问题。
在可行条件下，将测试编写与功能实现分离。
可由一名智能体从契约与旧实现中推导边界案例，另一名智能体编写移植代码。锁定已批准的兼容性测试，使实现人员无法修改。新审查者应评估代码是否因正确原因通过测试。
Bun 的生产回归缺陷揭示了绿色测试套件与语义完整性之间的差距。
某次仅在生产环境出现的 HMR 异常源于 debug_assert! 内的副作用。奇数长度的 UTF-16 崩溃则反映了不同的切片处理行为。每个被消除的缺陷都应同时成为永久性回归测试与新的语义映射规则。
对旧版与新实现运行相同的测试语料库。
对比指标：
构建边界值生成器，覆盖：
持续对解析器与协议边界进行模糊测试。
据 Bun 报告，其覆盖率引导的模糊测试器执行了约 1,000 亿次解析器代码，并生成了约 15 个修复拉取请求。具体数字取决于工作负载。可复用的模式在于：将崩溃发现与可复现测试、智能体建议的修复方案、以及人工审核的拉取请求相连接。
当用户依赖性能表现时，性能即构成行为的一部分。
基准测试指标：
比较分布特征而非平均值。在迁移前设定性能预算，防止团队在投入重写后为回归缺陷寻找理由。
同时执行浸泡测试。内存泄漏、描述符泄漏、队列增长、分配器碎片化及罕见竞态条件可能需要数小时乃至数日才能暴露。
具备更强内存安全保证的语言可消除整类缺陷，但仍可能引入不同的内存分配、调度机制或性能行为。
将以下类别作为独立审查类型分别处理：
unsafe 代码块根据源报告数据，Bun 约 78 万行 Rust 代码中约有 2.7 万行位于 unsafe 代码块内，其中大部分与 C/C++ 集成相关。
此类代码区域需要比常规代码审查更严格的处理。
要求在每个不安全边界附近添加不变量注释：
哪个线程拥有该值？
将重复的不安全模式分组到经过审查的包装器后面。按所有者跟踪不安全的代码行和代码块，而不是将总数视为虚浮指标。
使用：
Bun 的 11 轮安全审查证明了持续加固的过程，而非缺陷不存在的证据。
自动化安全审查应补充领域审查，尤其是在身份验证、沙箱逃逸、机密信息和供应链变更方面。
审查迁移机制本身。代理会执行仓库内容、构建脚本和工具输出。受损的依赖项或源代码中的隐藏指令可能影响运行。
文件系统隔离、网络限制、作用域令牌和不可变 CI 检查可降低此风险。
合并不等于发布。
从已知提交、工具链、依赖锁定和证据清单中构建版本化工件。保持旧实现可构建。
如果新旧二进制文件可以共存，添加运行时开关或路由层，
而不是不可逆地替换路径。
当副作用可以隔离时，从影子执行开始。
然后按以下顺序进行金丝雀发布：
为以下内容定义自动回滚阈值：
即使自动阈值未触发，人类必须保留停止扩展的能力。
演练回滚。
确认：
从未执行过的回滚文档只是假设。
每次缺陷泄露后，更新合约、语义映射、测试语料库和风险模型。
Bun 的 19 个已知回归很有用，因为它们暴露了重复的翻译风险。当新实现可运营且团队从中学习后——而非生成的差异合并后——迁移才算完成。
以下 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 可以缩短实施时间，同时提升规范质量。这是良好的权衡，而非自动化失败。
衡量每个被接受的单元对应的模型、计算和工具总成本。
动态工作流可能比普通会话消耗更多令牌。并行化在能减少高价值工作的等待时间且不造成更大验证积压时是合理的。
追踪：
一个快速交付但对团队仍显不透明的移植项目，只是转移了技术债务而非真正消除它。
选择一个具有实时参考实现且界限明确的迁移任务，例如：
编写一个
单一页面行为合约及三个聚焦风险的试点案例。
将实施与审查拆分为独立的智能体任务，使其上下文保持独立。
实施前：
保留完整运行记录：
该记录使团队能对比工具链版本并追溯缺陷，无需猜测智能体所见内容。
采用简单的授权规则：
自主权必须靠实力赢得。
持续产生通过验证单元的工作流可获得更广的文件范围或更长的无人值守运行时间，但不会自动获得部署权限。
能力、证据与授权始终分离。
Bun是一个非典型项目。
其创建者主导了迁移工作，对代码库有深入了解，并拥有直接架构决策权。旧实现拥有庞大测试套件，Rust提供强编译器反馈，项目可利用大规模并行计算。
多数团队无法同时具备这些优势。
该案例由Anthropic提供，原始文章指出工作使用了预发布的Claude Fable 5模型。这是有价值的一手证据，但并非独立供应商对比。
关于人工团队所需时长的论断属于反事实估算。团队不应仅凭一次成功迁移就做出采购决策。
报告的19个回归问题为已知缺陷，不保证完整统计。模糊测试执行和安全审查轮次衡量的是工作量，而非缺陷的不存在性。
最有依据的结论相对谨慎：
当与强确定性反馈和专家编排结合时，大型AI驱动迁移是可行的，但在代码生成完成后，其风险仍是工程问题。
该结论仍有意义。团队可尝试此前因成本而搁置的现代化项目，前提是为规格说明、验证和受控部署分配与实施规模相当的预算。
模糊测试、消毒器及性能检查。
unsafe、FFI、认证、解析器及持久性边界。Bun 将此前用 Zig 编写的主要实现迁移到了 Rust 中。已发布的内容大致描述了约 78 万行 Rust 代码及高度并行化的 AI 辅助工作流程，随后进行了广泛的测试、安全审查、模糊测试及生产环境加固。
不。人工编写的迁移规则、手动制品审查、隔离的工作流程、编译器反馈、独立的审查代理、安全审查、模糊测试及生产发布控制都发挥了重要作用。这一案例更适合理解为 AI 加速的工程实践，而非无人值守的代码转换。
现有测试通常只覆盖了部分观察到的行为。它们可能遗漏仅存在于发布版本的语义、平台差异、性能回退、不安全边界、遥测变化或测试套件中从未编码的边缘情况。
差分测试使用相同的输入运行新旧两种实现，并比较它们的可观察输出及副作用。当旧系统可信但缺乏完整的正式规范时，该方法尤为有用。
新的审查者不太可能继承编写代理的假设和推理错误。审查者可以专注于契约、差异、证据及反例，而非维护产生变更的实现路径。
unsafe Rust 代码？每个 unsafe 块或 FFI 边界都应有指定的负责人、文档化的不变式、针对性测试，以及关于指针有效性、生命周期和线程所有权的清晰说明。静态分析、消毒器、模糊测试、依赖审查及人工安全审查应与常规代码审查分开进行。
跟踪已验证单元的吞吐量、不匹配项的闭合速度、逃逸缺陷、人工投入、计算成本、发布健康度及迁移后的可维护性。生成的代码行数和代理数量是容量指标，而非正确性的证明。
可以。从单一有界组件、书面行为契约、三个以风险为重点的试点、独立的实施与审查上下文、确定性的 CI 门控以及经过测试的回滚路径开始。仅当工作流程反复产生可验证的结果后再扩展规模。
本操作手册。
unsafe 边界。Bun 的 Rust 重写证明，AI 编码代理能够大幅压缩实现时间，同时也说明了为何验证必须成为第一等工程体系。契约、语义映射、隔离工作单元、独立审查、差异测试、模糊测试、性能预算及分阶段发布，是将生成代码转化为可信迁移证据的关键。
实际经验绝非简单复制智能体数量或代码行数，而是将迁移拆分为有边界的断言，为每一项断言提供确定性证明，只有当工作流反复产生可靠结果后，才逐步扩大自主性。
大规模 AI 辅助重写的完成节点，并非生成代码被合并之时，而是新系统通过验证、可操作、可恢复、可理解之日。
从一句话开始，几分钟内拿到完整网站。
