最近圈子里被一个标题刷屏了“微软要‘消灭 C/C’靠 AI 每月写 100 万行 Rust”。当时我正好在帮团队做 C 音视频模块的 Rust 改造预研看到这个话题的第一反应是媒体标题又替微软放大话了。但当我把微软研究院开源的 Verne 项目、Azure CTO 此前的表态、以及那份 AI 辅助迁移 C 代码到 Rust 的技术论文串起来看之后发现这事情比“消灭”和“翻车”两个词要复杂得多。作为一个在 C/C 堆里摸爬滚打了十几年的老开发又亲自试过用 LLM 辅助迁移代码我想把这件事掰开聊聊微软到底在做什么每月 100 万行 Rust 是怎么个写法以及这究竟是史诗级重构还是史诗级翻车现场。1. “消灭 C/C”这个说法从哪来又夸大在哪标题里最刺激眼球的两个词是“消灭”和“每月 100 万行”。先说结论微软从来没有在任何官方场合说要“消灭 C/C”这个说法是媒体对一系列动作的归纳性转述转述过程中丢掉了大量上下文和技术前提。1.1 真实事件时间线从 Mark Russinovich 发声到 Verne 项目落地这事的源头可以追溯到 2022 年 9 月Azure CTO Mark Russinovich 在公开场合讲过一句话新项目应该优先考虑 Rust而不是 C/C。这句话在当时引发过一波讨论但并没有立刻变成什么“消灭”行动。真正让事情推进到实质阶段的是 2024 年微软在 GitHub 上开源的一个叫 Verne 的项目。这个项目的目的很具体用 Rust 逐步替换 Windows 安全关键组件里的 C/C 代码。微软官方给出的迁移目标大约是三万六千多个内部函数这些函数大多集中在权限校验、加密、身份认证、句柄管理这类一旦出 bug 就可能导致系统级漏洞的模块。而我看到的英文报道里提到的“每月 100 万行 Rust”指的是 Verne 项目借助 AI 辅助翻译工具链在高峰期达到的一个产出速度指标不是人类程序员手写的速度也不是微软所有业务线 Rust 代码的总和。所以“消灭 C/C”这句话浓缩了几层意思微软要用 Rust 重写一部分关键代码、AI 在其中承担了翻译初稿的重体力活、产出速度确实惊人。但“消灭”这个词完全放大了适用范围。Windows 那么大一个系统加上 Office、Azure、游戏部门等C/C 代码总量以亿行为单位就算每年写 1000 万行 Rust替换完也要十年以上。而且微软内部大量的 C 代码依然在正常迭代没有任何一条指令说“C/C 开发者明天就要转岗”。1.2 “每月 100 万行”是什么样的工程概念我以自己用 LLM 辅助做代码迁移的经验来类比。一个普通熟练的 C 工程师手写 Rust 代码一天能产出的可用代码大约在 200 到 400 行之间这还得是需求明确、架构清晰的情况。一个月下来也就是几千行。如果是大型遗留系统迁移需要先理解旧逻辑、再设计 Rust 的所有权结构、然后手动翻译、编译修错、测试一天能提交 100 行高质量的 Rust 代码就算不错了。所以 100 万行这个数字靠人肉堆是堆不出来的。但在 AI 辅助翻译场景下逻辑就不一样了。LLM 读一个 C 函数生成对应的 Rust 代码速度快到毫秒级瓶颈不在生成而在验证。如果一套流水线能自动完成编译检查、单元测试对比、静态分析并且把人工审查集中在高风险函数上那么一百万行代码的量级确实不是天方夜谭。后面我会详细拆解这套流水线是怎么设计的因为这才是理解“每月 100 万行”到底有多少水分、多少真实含量的关键。1.3 真正的内在逻辑微软不是在消灭语言而是在消灭内存安全漏洞把镜头拉远一点看微软这几年最头疼的安全问题不是逻辑漏洞而是内存安全漏洞。这个问题的严重性不是拍脑袋想出来的而是有真实漏洞数据支撑的。微软安全响应中心在 2019 年到 2025 年间发布的多个年度报告中反复提到在微软产品被修复的漏洞里内存安全问题长期占六到七成。这里面最典型的是 CWE-787越界写入、CWE-416释放后使用、CWE-125越界读取这几类。这类漏洞的共同特点是攻击者可以利用它们实现远程代码执行、权限提升甚至在不需要任何用户交互的情况下在系统层面大打出手。Rust 能解决这些问题吗从语言设计上说是的。Rust 的所有权模型和借用检查器在编译阶段就能拦截掉绝大多数悬垂指针、重复释放、数据竞争和越界访问。这不是靠开发者自觉也不是靠代码评审而是从编译器层面堵住了路。理解了这个背景你再看微软的行为逻辑就很清晰了这不是一次浪漫主义的重写而是一次围绕安全风险的资产置换。微软要消灭的不是 C/C 这个语言符号而是那 70% 的安全漏洞。2. 为什么偏偏是 Rust内存安全这笔账微软算是算得最清楚的我不会花大篇幅吹 Rust 的语言特性因为网上教程太多了。但从微软的视角去看“为什么是 Rust 而不是 Go、Java、或者继续用 C 加 sanitizer”能看到更深的决策逻辑。2.1 托管语言解决不了系统级痛点Java、Go 这类带垃圾回收的语言确实能解决内存安全问题但它们在系统级场景下有天然限制运行时要自带 GC对实时性要求高的场景比如内核驱动、网络包处理、加密计算不友好和 C ABI 的互操作需要 JNI 或 cgo代价高昂。微软要重写的是 Windows 内核附近的安全关键组件这些代码对性能、内存布局、系统调用的控制要求极高托管语言在这种场景下基本出局。Go 虽然编译型语言但它的 GC 停顿和 runtime 依赖在内核级代码里是致命的。2.2 为什么不是“更现代的 C”也有不少人觉得既然 C 积累已经那么深继续用现代化 C智能指针、span、concepts不也能解决问题吗这个观点有一定道理现代 C 的安全水平比二十年前高多了。但微软的决策层看得更远C 的内存安全是“靠规范约束人”Rust 的内存安全是“靠编译器约束代码”。只要是人写的 C就总会在某个凌晨三点的加班时刻写下一个裸指针拷贝让整条防线失守。而 Rust 的借用检查器不讲情面规则是硬性的。另外一个客观事实是微软每年要花费巨额的漏洞奖励和修复成本内存安全漏洞是其中最大的一块支出。如果语言层面能把这些漏洞的路堵死长期节约的成本不是一个小数目。2.3 零成本抽象与 C ABI 互操作是压舱石Rust 还有一个容易被忽略的优势它对现有系统的侵入性可以做到非常低。Rust 支持 extern C 接口可以直接和 C/C 代码共享结构体和函数指针这意味着迁移不需要一次全部推倒重来。你可以把系统想象成一个老房子Rust 像是一批预制好的新构件一块一块替换墙体而不用把整个房子拆了重建。这个特性对 Windows 这种超大系统来说是生死攸关的。Verne 项目的迁移策略恰恰不是“全部重写”而是以 C ABI 边界为分割线把一个个 C 函数翻译成 Rust 函数保留接口不变然后整体替换实现。这种渐进式策略如果换成其他语言互操作成本会高到难以执行。2.4 语言级“安全默认值”改变了工程红线我还想提一个实际工程中感受特别明显的差异Rust 的 unsafe 关键字让“不安全代码”从一个模糊地带变成了一个显式的、可被审计的标记。在 C/C 项目里一个指针解引用满天飞的项目很难快速定位“哪些代码是风险密集区”因为整个文件看起来都是正常的。而 Rust 项目里unsafe 块会被反复审查、被工具扫描、被特殊标注形成了“默认安全 局部豁免”的工程文化。这个差异在代码评审中的价值极大。微软做安全关键组件迁移时一条很核心的指标就是“unsafe 代码占比”目标是把 unsafe 控制在极低水平让每一处潜在风险暴露在聚光灯下。这事在 C 里根本做不到——你不能在 C 里标注“这个地方可能不安全”因为默认就不安全。3. AI 真正参与的不是“写代码”而是“翻译代码”现在回到最吸引人的话题AI 怎么做到每月 100 万行 Rust。如果你以为的“AI 写代码”是给 ChatGPT 一个需求描述然后它凭空生成一百万行业务代码那是不现实的。微软 Verne 项目里 AI 的工作方式和大多数人想象的不一样它做的事情本质上是一个高难度的“代码翻译器”加“自动验证流水线”而且是在极高的工程约束下运行的。3.1 先拆解 C 到 Rust 的翻译难点很多人没做过 C 到 Rust 的翻译不知道这里面的坑有多深。C 代码里充满了宏、指针操作、union、位域、goto、全局可变状态。这些特性没有一个能直接对应到 Rust 的安全抽象上。比如一个典型的 C 函数可能会这样写typedef struct { int status; char *data; size_t len; } Buffer; int process(Buffer *buf) { if (buf-status ! 0) { return -1; } char *tmp buf-data; for (size_t i 0; i buf-len; i) { tmp[i] 1; } return buf-len; }翻译成 Rust 时首先要解决的是指向 Buffer 内部 data 字段的裸指针 tmp在 Rust 所有权模型里这可是一个绕不开的坎。你需要决定是用切片、用索引、还是用指针加生命周期来建模。如果函数内部又把这个指针传给了另一个函数那生命周期标注会让你头大。AI 在这里的价值恰恰不是“自动化魔法”而是能基于大量训练数据给出一个“大多数情况下合理”的翻译模式然后由后续流程去验证正确性。这就很像让一个英语八级的翻译去翻译技术文档译文能看懂但专业术语和上下文歧义还需要一个懂技术的人过一遍。3.2 Verne 项目采用的 AI 辅助迁移流程我根据公开资料和微软研究院那篇关于 AI 辅助 C 到 Rust 迁移的论文还原一下这套流水线的核心步骤。整个过程大致分五个阶段第一阶段是预处理与解析。C/C 源码先经过编译器的前端解析展开所有宏生成抽象语法树。这一步非常关键因为 LLM 直接读源码里的宏定义很容易产生幻觉而展开后的代码对模型更有辨识度。第二阶段是逐函数翻译。LLM 拿到一个 C 函数的展开后源码、函数签名、依赖的类型定义、以及一些注释生成对应的 Rust 代码。这里模型不会看到整个大系统而是像手术刀一样只处理一个函数单元避免上下文过长导致输出混乱。第三阶段是自动编译修复。生成的 Rust 代码会进入编译流程编译器报出的错误和警告会反馈给模型让它根据错误信息修改代码。这个过程在 Verne 的流水线里是循环进行的有时一个函数要迭代几十轮才能编译通过。第四阶段是测试验证。系统会自动为用户生成的 Rust 函数绑定测试桩对比改造前后行为是否一致。如果测试覆盖率低流水线会提示“该函数需要额外的人工关注”。最后一步才是人工审查。只有测试覆盖率不达标或者包含高风险管理特性的函数才会流转到人类工程师手里。从这里可以看出每月 100 万行的统计是流水线全速运转时的“过程量”不是“经过完整验证后的交付量”。有一点可以确认的是AI 在这个过程中是“翻译初稿的生产工具”不是“决定性的审查者”人依然保留在关键路径上。3.3 我在自己的项目里复刻了一个简化版看了这套流程之后我自己也在一个私有 C 网络模块上做了一次简化复刻。我没有 Verne 那么庞大的工程基础设施但我可以把核心思路搬过来先用 clang 输出 AST 和宏展开后的源码然后用脚本把函数按依赖关系排序逐个丢给 LLM 翻译再用 cargo 编译、用自定义的测试数据对比输入输出行为。实测下来纯函数输入结构体、输出计算结果类的翻译成功率非常高基本十几轮编译修复之后就能跑通但涉及全局状态、回调函数、复杂指针链表的函数就非常痛苦经常出现“能编译但行为不对”的情况。印象最深的是一个几十行的 C 函数里面用了一个全局链表做缓存翻译出来的 Rust 代码看起来逻辑完全一致但漏掉了一个关键的锁操作导致并发场景下直接翻车。这种问题自动化测试如果覆盖不到就只能靠人工审查发现。所以我对“每月 100 万行”的真实看法是它是个很有雄心的工程效率目标但离“安全可交付”还有一条很长的质量验证链条。3.4 AI Agent 在其中的角色边界现在圈子里流行谈 AI Agent微软这套东西看起来也很像 Agent 在工作。但我在实际操作中的体会是目前的 LLM 更适合做一个“高配合度的执行者”而不是“有判断力的工程师”。它可以忠实地按照指令翻译函数但它很难判断“这个 C 函数里的某段代码是否有历史包袱、是否依赖于某个未记录的编译器行为”。这个判断力来自对系统全貌的理解而 LLM 每次只能看到一小块代码片段。所以 Verne 项目里真正的 Agent 能力其实是集中在流程调度上哪个函数需要优先处理、哪次编译错误需要回滚、哪个函数测试覆盖不够需要人工介入。这种“流水线调度型 Agent”和“自主写码型 Agent”是很不一样的。微软没有让 AI 去大规模自主设计架构而是让它在一套严格边界内做翻译和修正这个边界本身就是防翻车的第一道保险。4. 真正会翻车的地方unsafe、FFI、宏和架构迁移网上对这个计划的质疑主要集中在“AI 翻译靠不靠谱”上但在实际做迁移的人看来有些坑比 AI 的幻觉更危险。这些坑不会因为你用的是人工还是 AI 而消失它们是 C/C 和 Rust 两种内存模型根本差异带来的结构性难题。4.1 unsafe 泛滥名义上的 Rust 实际上的 C最典型的翻车方式是翻译后的 Rust 代码用了大量 unsafe 块把 C 的裸指针操作原样搬进了 Rust。这种情况下Rust 的安全保证形同虚设代码的安全水平跟原版 C 几乎没有区别。Verne 项目的核心指标之一是控制 unsafe 密度但在很多真实函数里C 代码天生就是一堆指针传递不用 unsafe 根本实现不了。我的经验是面对这种函数不能指望 LLM 自动设计出一套安全的抽象。你得手动重构把 C 函数对裸指针的操作改成在 Rust 边界处把指针转换为引用或切片然后把所有内部逻辑放在安全代码里完成最后再把结果传回 C 边界。这个过程需要开发者对所有权模型有直觉AI 目前做不好。如果在大型迁移项目中放纵 unsafe得到的不是“更安全的 Rust 重写”而是“语法换成 Rust 的 C 代码”这比不迁移还糟糕因为会给大家一个虚假的安全感。4.2 FFI 边界谁把不安全的 C 世界和安全的 Rust 世界缝合在一起第二个大坑是 FFI 边界的设计。Rust 和 C 互操作时跨语言边界的数据传递必须使用 C ABI 兼容类型这意味着所有穿过边界的数据都处于“不安全状态”。一个常见的 bug 是Rust 侧拿到的 C 指针没有生命周期信息如何保证指针指向的数据在调用期间不被释放如果 C 侧的回调函数在持有 Rust 引用时重新进了 Rust 代码就可能触发双重借用。这些边界上的微妙问题编译器只能屏蔽一部分另一部分得靠仔细的 unsafe 文档约定和运行时检查来兜底。我在做项目时专门给自己定了一条规则所有 FFI 边界上的函数必须写成薄封装内部不做任何业务逻辑业务逻辑全部放在安全 Rust 代码里。这样即使 C 侧出了问题影响范围也能被限制在薄封装里。Verne 项目处理 C/Rust 符号边界时本质上也是这个思路只是他们把边界提取成了自动生成的 FFI 层。但自动生成 FFI 不是万能的有些跨边界的生命周期协议比如“Rust 向 C 注册一个回调C 稍后调用这个回调”很难通过现成的 bindgen 工具正确表达需要人工设计状态机和生命周期管理。4.3 宏展开翻译的隐形工作量炸弹C/C 里的宏是一个让 AI 和人类都头疼的东西。预处理把宏展开后源代码体积可能膨胀两三倍而且展开后的代码可读性极差充斥着 _builtin、编译器内部细节。我见过一个只有一百行的 C 头文件展开后生成两千多行代码的极端情况。LLM 翻译这种展开后的代码输出结果会非常庞大而且很可能隐含冗余逻辑。更麻烦的是有些 C 项目里宏被用来实现“伪泛型”用宏模板定义一组结构体和函数然后分别实例化到不同类型上。翻译 Rust 时如果用泛型替代设计工作会非常大但如果按宏展开后的每一个实例逐个翻译代码量会膨胀到不可维护。我在实践中采用的办法是先分析哪些宏可以用 Rust 泛型重写再分析哪些宏只是简单的常量定义或函数包装最后才把真正复杂的、领域相关的宏留给人工翻译。这个过程说起来简单但做起来非常耗时而且需要极深的领域理解。Verne 项目的预处理步骤在技术上能解决“展开”但解决不了“展开后的代码要怎么重新抽象”这个问题。4.4 架构级迁移C 的“传指针共享一切”和 Rust 的所有权哲学冲突最后一个翻车点是系统设计层面的。很多大型 C/C 系统的基本模式是大量模块共享可变全局状态模块之间通过指针互相传递修改权。这种“传指针共享一切”的风格在 Rust 里几乎是对所有权模型的正面挑衅。如果只是逐函数翻译你会发现每个函数都要把输入参数变成可变引用函数之间互相借用最终会撞上借用检查器的墙壁。我做过一个小实验把一个一百多行的 C 状态机翻译成 Rust状态机内部有十几个全局变量、几个回调指针、还有一些模块间共享的队列。逐函数翻译后编译错误铺天盖地。最终我不得不重构了整体设计把共享状态装进一个结构体把回调改成 trait 对象把队列改成用 ArcMutex 包装。这是整个迁移过程中最花时间的部分占掉了大约七成的工作量。微软的 Verne 项目同样绕不开这个难题他们的对策不是靠 AI 硬翻译而是人工介入做架构层面的重构规划把大函数拆小、把全局状态收敛、把接口调整为更适合 Rust 表达的形式。这个过程没法自动化也不可能每月完成一百万行因为每一个拆分决策都需要领域知识和系统观。4.5 构建系统与生态宏大的战略会败给日常的蛋疼还有一个很少被媒体提起、但实际迁移时必然踩坑的点构建系统和生态工具链。C/C 项目通常用 CMake、MSBuild 管理而 Rust 用 Cargo。两大构建系统的集成不是一句“支持 Rust”就能搞定的。我的一个同事在公司里引入 Rust 模块时光是把 cargo build 集成到 CI 流水线里、解决 MSVC 链接器和 LLVM 后端的差异、处理符号导出就折腾了两周。热搜词里有个“rust cargo 不用 msvc”明显是不少人在配置 Windows 环境时卡住了。Rust 默认在 Windows 上使用 MSVC 工具链但也有人愿意用 GNU 工具链避开一些链接问题这里的选择会直接影响后续与 C 模块的互操作方式。用 MSVC 的话Rust 生成的对象文件能和 MSVC 编译的 C 对象文件直接链接但符号修饰规则、异常处理机制、结构体对齐这些细节很容易出幺蛾子。我自己遇到过的坑包括Rust 结构体的 repr(Rust) 布局不能直接传 C 接口必须显式标注 repr(C)C 的 bool 类型和 Rust 的 bool 在 ABI 层面有差异不能想当然等价。如果你打算把一个大型 C 项目混合编译这些细节会成为日常消耗你时间的地方。生态方面也不用回避Rust 在嵌入式、服务端、命令行工具有较好支持但在音视频处理、游戏引擎、GUI 等领域成熟的库还没有 C 生态那么丰富。像我们音视频领域做推流、转码、渲染很多底层库要么是 C/C 实现的要么是 FFmpeg 那一套。你用 Rust 重写业务层可以但底层还得接 C 库。这意味着 FFI 边界会非常密集安全迁移的工作量比微软在 Windows 安全关键组件上的场景更大。热搜词里“音视频c/c开发教材”长期热度不减也从侧面说明这个领域最稳的存量还在 C不可能一夜之间被 Rust 取代。5. 对还在写 C/C 的人意味着什么别慌但这几点值得动手聊完微软的宏观动作接下来要落回每个人最关心的问题这事对我有没有影响我现在该做什么我的判断是C/C 不会被消灭但增量空间会被压缩而“懂 C/C 会 Rust 会用 AI 工具”的复合型开发者会在未来几年获得明显优势。5.1 C/C 的底盘并不会消失C 语言在嵌入式、内核、驱动、硬件抽象层的位置短期内没有任何语言能替代。C 在游戏引擎、高频交易、浏览器内核、数据库引擎、大型音视频处理框架里积累了海量代码和生态重写成本高到不现实。你去看招聘市场C/C 岗位并不少但要求普遍在提高要么是行业资深、理解底层要么是熟悉现代 C 实践、能做安全加固。如果你只会“C with Class”式写法确实会越来越难。最现实的影响是新增的底层基础设施项目尤其涉及安全关键场景会越来越多地选择 Rust。这意味着今后五到十年的新项目池子里Rust 的份额会持续增长而 C/C 的存量虽然大增量会放缓。对刚入行的开发者来说只押注 C 而不碰 Rust风险在变大。5.2 用好 Rust 国内源和加速配置把环境门槛先干掉我的建议是如果你决定要开始学 Rust先把环境配好。很多国内开发者在首次安装 Rust 时被各种网络问题劝退其实配置镜像源并不复杂。Rust 官方工具链 rustup 支持配置环境变量RUSTUP_DIST_SERVER和RUSTUP_UPDATE_ROOT指向国内镜像这样安装和更新工具链的速度会快很多。Cargo 的依赖下载则通过修改~/.cargo/config.toml把crates.io索引替换为镜像地址来加速。这一步做完你能省下大量卡在下载环节的时间把精力集中在语言本身。我个人的建议是Rust 的学习路径不要从语法书开始啃。先装好工具链用 Cargo 新建一个命令行小工具比如一个批量文件重命名器或一个 JSON 解析器。在写这个小工具的过程中你会自然触及所有权、生命周期、模式匹配、Result 错误处理这些核心概念。等把这些概念揉顺了再去读《Rust 权威指南》里对应的章节效果比死记硬背语法好得多。热搜词里有“rust权威指南第二版pdf下载”说明这本书还是很多人的首选入门读物但我的体会是“项目驱动 阅读查漏”比“阅读驱动 项目验证”更高效。5.3 把 AI 当“外籍实习生”用而不是当“自动编码机”回到 AI 这个话题。不少开发者担心“AI 都能写代码了我还要学什么”但参与过实际迁移项目之后我的心态反而是AI 让我把精力从“怎么拼语法”转移到“怎么设计架构”上。这正好呼应了 Verne 项目给我们展示的范式AI 负责高重复性的翻译初稿人负责判断“翻译得对不对、这个翻译是否值得保留、底层架构是否需要调整”。我自己现在的工作流已经固定下来先让 LLM 把 C/C 函数翻译成 Rust 初稿然后我把初稿当作“一个外籍实习生写完的第一版”逐行做 code review重点关注所有权边界、错误处理、并发安全。很多函数在 review 阶段会被我大改甚至重写。这个流程下一个一百行函数从开始到验证完大概需要一到两个小时比纯手写快了大概三分之一到一半。虽然不如“每月一百万行”那么梦幻但比传统的“手动重写”已经高效太多。关键是我自己的设计判断力在这个过程中没有退化反而因为需要频繁审视 AI 输出而变得更强了。5.4 现在动手的优先级建议如果你问我现阶段最值得做的事我会给这样一张优先级清单第一优先级掌握 Rust 的所有权和借用检查器。这不是“会写语法”的程度而是能准确预判“这段代码在什么时候会被 move、什么时候只能借用、什么时候需要 clone”。这个能力是后续所有工作的基础。第二优先级用 Rust 重写一个你手头曾经写过的 C/C 小工具。重写时不要逐行翻译而是重新思考数据流和状态管理。这个过程会让你体会到 C 和 Rust 的“思维方式差异”比任何教程都直观。第三优先级把 C/C 和 Rust 的互操作跑通。用一个 cbindgen 或 bindgen 做一个小 demoC 暴露接口、Rust 调用或反过来。这是未来在真实项目里渐进式引入 Rust 的基本功。第四优先级了解 AI 辅助迁移工作流的基本套路。不需要搭一整套 Verne 那样的大规模流水线只要学会用 LLM 输出初稿、用编译器和测试去验证、然后人工审查修复就已经能显著提升你处理遗留代码的效率。6. 我的结论既不是史诗级重构也不是史诗级翻车而是一场注定艰难但方向正确的长征把整件事看下来我自己的判断是“消灭 C/C”这个说法完全站不住脚但“用 Rust 替换安全关键组件 AI 辅助提升迁移效率”这件事技术方向是明确的执行过程会异常艰难。所谓“史诗级重构”高估了短期效果所谓“史诗级翻车现场”低估了这套工程体系的真实约束力。微软的 Verne 项目本质上是一场“长期主义的资产置换”用数年的高投入换未来几十年内存安全漏洞数量的大幅下降。这个决策对一家拥有海量关键基础设施的公司来说是在算长期账。而 AI 在这其中扮演的角色是让置换速度提升了几个数量级但并没有消灭迁移过程中那些深层的架构难题。unsafe 边界、FFI 契约、宏抽象、构建系统集成的坑依然需要人来填。所以对整个行业来说这不是一场“AI 取代程序员”的叙事而是一场“AI 放大人类工程师能力”的示范。对我个人而言这件事最大的影响是坚定了我继续深入 Rust 的决心。过去几个月我一边用 AI 辅助迁移手头的 C 音视频模块一边啃 Rust 的异步网络编程虽然过程里有无数次被借用检查器教育到怀疑人生但每次熬过去之后都能明显感受到自己的工程判断力在往上走。倒不是因为我写 Rust 写得有多好而是因为 Rust 逼着我在动手前把数据流、所有权、错误路径全部想清楚这种思考习惯反过来让我在写 C 时也变得更加克制和安全。这可能才是这场声势浩大的“Rust 化”运动给所有行业人带来的最有价值的间接影响。