美国政府 + 开源组织立项，计划在 2030 年前，转换 1 亿行关键 C/C++ 为 Rust

本文翻译自 Edd Gent 于 2026年1月28日撰写的文章，原文发表在 IEEE Spectrum。其中 DARPA（美国国防高级研究计划局）是美国国防部下属的军事科研机构，成立于1958年。曾主导互联网、GPS、无人机等颠覆性技术的开发。

译者轻微剧透，应该是 Rust 程序员基数太少，因此是使用 AI 工具将 C/C++ 翻译转换为 Rust。但这翻译转换后的 Rust，真实的 Rust 程序员维护起来应该很困难吧……

Ferris the crab, known as the unofficial mascot for Rust's programming language, against an abstract background of code.

“大重构”计划：用 AI 加固关键代码 >（当前）内存安全漏洞占全部漏洞的70%

原文标题：Great Refactor Initiative Looks to AI to Harden Critical Code > Memory-safety exploits account for 70 percent of vulnerabilities

全球大量关键 IT 系统仍充斥着很多漏洞，而 AI 工具，正在让利用这些漏洞变得前所未有的容易。但 AI 也可能成为解决方案的一部分：一项新计划——旨在将脆弱代码自动转换为以安全为核心的 Rust 语言代码，此举有望消除绝大多数的已知软件漏洞。

AI 编码工具的飞速进步，使得处理那些过去因成本过高，或耗时过长而被搁置的软件工程任务变得空前容易。智库“进步研究所”（Institute for Progress）发起了“大重构”（Great Refactor）计划，利用这些工具将 C/C++ 编写的开源软件转换为 Rust。与前者不同，Rust 从语言层面就旨在防范一类被称为内存漏洞（memory exploits）的危险缺陷。

内存安全问题（Memory safety issues）发生在软件，其以非预期方式访问或操作内存之时。这类缺陷在一些老旧（译注：原文用的是older）语言中极为普遍，这些语言为开发者提供可内存手动控制权的权限。大多数较新的语言都加入了防护机制来阻止此类问题，但这通常以牺牲性能为代价。因此，像 C/C++ 这类内存不安全（memory-unsafe）的语言仍被广泛使用，而内存安全漏洞，估计仍占全部软件漏洞的70%。

Rust 的内存安全角色

2015年首次发布的 Rust，旨在提供媲美 C/C++ 的性能，同时实现内存安全。亚马逊、谷歌、微软等急于加固自身代码的科技公司，迅速接纳了该语言。但将旧版软件转换为 Rust，仍是一个费力且昂贵的过程。

项目负责人、剑桥大学博士生 Herbie Bradley 表示，“大重构”的成功，押注于一个信念：AI 工具已改变了成本效益的计算公式。

该计划提议建立一个由美国政府资助的“聚焦研究组织”（Focused Research Organization），利用 AI 驱动的编码工具，到2030年，将关键开源软件库中的 1 亿行代码转换为 Rust。Bradley 估算，1 亿美元的投资，有望阻止数百次的网络攻击——累积损失约 20 亿美元。

Bradley 表示：“我非常看好 AI 彻底改变软件开发方式的潜力，这显然包括有能力完成那些过去被认为成本或时间上过于高昂的事情。五年后，如果人们想要任何主流库的 Rust 版本……他们都能造出来。”

Bradley 指出，这种方法极具吸引力，其关键在于：它有潜力一次性解决一大片漏洞，而不必沿用逐个修补的老办法。这对于那些常由少数疲惫志愿者维护的、数量庞大的小型开源库尤其有价值。

手动将一个小型 C 代码库转换为 Rust，通常需要经验丰富且稀缺的 Rust 工程师耗费数千小时人力。但 Bradley 表示，最新的 AI 编码工具现已能可靠地完成少于 1000 行程序的翻译，几乎无需监督；在少量监督下，处理多达 5000 行的程序也已触手可及。而且这些能力正在快速提升。

一份该提案的立场概述文件指出，一个由不到 50 名安全工程师、AI 研究人员和管理员组成的团队，就有望在三至五年的时间轴内，显著改善关键开源库的安全状况。初期工作将聚焦于识别最需要加固的库，并开发用于验证 AI 翻译后代码安全性与功能的稳健工具。

AI 驱动的 Rust 翻译工具

该项目希望能借力已有的 AI 驱动的 Rust 翻译工具，最著名的是美国国防高级研究计划局（DARPA）的“将所有 C 语言转换为 Rust”（TRACTOR）计划。该计划于 2024 年启动，旨在研究如何将新兴的生成式 AI 工具与传统代码分析相结合，以实现 Rust 翻译自动化。

尽管启动以来 AI 代码生成能力飞速提升，项目经理 Dan Wallach 认为混合方法仍可能胜出。他表示，该计划资助的六个团队正采取一系列方法：从几乎完全依赖 AI，到以经典转换工具为主、仅将部分问题外包给生成模型。

他说：“AI 看起来前景广阔，但我们在编写软件来分析其他软件方面也有数十年的研究积累。TRACTOR 的全部意义就在于探索所有不同的混合搭配方式——借用一句话说——融合经典计算机科学与现代 AI。”

各团队已于12月提交首轮成果，项目评估小组正进行分析。Wallach 表示，评判的两个主要标准是正确性（代码是否按预期工作）和性能，但第三个更主观的衡量标准或许最为关键。各团队面临的挑战是创作出“地道的”（idiomatic）Rust 代码——即遵循最佳实践、以成熟方式解决问题的代码。换句话说：“代码看起来是否像熟练的 Rust 程序员从头构建的那样。”

这对于确保生成的代码易于人类工程师维护至关重要。但 Rust 项目贡献者、开源开发者 Josh Triplett 表示，这可能很棘手。“与手动翻译的代码相比，AI 翻译的代码最终很可能更难让人类维护。”

Triplett 说，这未必总是问题——他欢迎任何将更多代码转换为 Rust 的努力。如果一个项目已在使用 AI 辅助维护代码（这种情况日益普遍），那么用 AI 将其翻译成 Rust 是完全合理的。但他提醒那些尚未常规使用该技术的团队，不要为了代码转换，而临时求助于 AI。他同时认为，对于数千其他项目依赖的热门开源库，应持更多谨慎。

“你可能需要在转换时多花点心思，或许让 AI 帮你，但必须非常小心，”他说，“永远不会有万能灵药能让 AI 100%避免犯错，无论是产生幻觉还是未能理解任务。”

乔治城大学安全与新兴技术中心高级研究分析师 Jessica Ji 指出了另一个潜在挑战：尽管 Rust 人气日增，其开发者基数仍相对较小。“假设 AI 翻译一切顺利，生成的 Rust 代码仍需以某种方式维护和监控，”她在给 IEEE Spectrum 的邮件中写道，“Rust 专家数量远少于 C/C++ 专家，因此能够审视代码库的专家目光很可能也会更少。”

采用 Rust 面临的挑战

然而，Ji 认为，最大的障碍或许是说服美国政府——尤其是按设想的规模——资助该项目。她认为更现实的目标可能是从私营部门为概念验证（proof of concept）寻求资金。“我认为现在是提出此类提案的好时机，因为 AI 公司特别有动力展示其模型的能力。”

Bradley 也有类似思考。虽然他已与美国和英国政府代表进行过讨论，但他也在探索该项目作为商业项目是否更合理，因为大量可从 Rust 转换中受益的脆弱代码存在于私营公司和关键基础设施提供商手中。

注1：原文链接 https://spectrum.ieee.org/ai-code-rust-great-refactor

注2：Edd Gent 是驻印度班加罗尔的自由科学科技撰稿人，关注计算、工程、能源、生物科学等领域的新兴技术。