最近半个月，Rust圈连着出了三件事，单看每件都上热搜，放在一起看才真正有意思。
第一件：Bun完成了一次从Zig到Rust的大型移植，靠AI辅助，11天，花了大约16.5万美元，还顺手修复了大量内存问题。哔哩哔哩这种规模的重写放在过去，预算单位是"年"。
第二件：8月5日，Rust官方Inside Rust博客发文，rust-lang/rust仓库的编译器、标准库、类型系统、rustdoc、bootstrap五个核心团队联合通过了一份LLM使用政策，一句话总结：AI可以帮你问问题、分析、检查、评审，但不能替你"创造"代码。这份政策不是拍脑袋出来的，背后是一场持续了一个多月、在Zulip上产生了三千多条消息的激烈内部辩论。知乎
第三件：Rustikon 2026大会上，RTB House的两位工程师用一场叫《Blazingly Fast or Blazingly Hyped?》的演讲，给喊了三年的"Rewrite It In Rust"（RIIR）meme做了一次数据体检。知乎有真香的部分，也有bat在管道模式下比cat慢60倍这种翻车现场。
一边是AI把重写成本打到了地板，一边是Rust官方给AI代码设了比人写代码更高的门槛。这两件事不矛盾吗？还真不矛盾，它们说的是同一件事：代码生成变便宜了，但"理解代码"从来没有这么贵过。
AI为什么特别擅长重写Rust：编译器成了最好的监工
先说那个反直觉的部分：Rust不是出了名的"人类写起来痛苦"吗，怎么到了AI时代反而成了最容易重写的目标？答案藏在编译器里。看这个循环：AI生成代码→cargo check→编译器报错→AI照着错误改→再编译。C++或者Python项目里，很多错误要等运行时、看日志、靠猜；而Rust的错误是显式的、局部的、结构化的，发生在编译期，错误信息还特别详尽。对人类来说这是折磨，对AI Agent来说这简直是完美的训练反馈——错误信息就是提示词，编译器就是阅卷老师。一句话：Rust编译器原来是折磨人类的，现在变成了监督AI的严格教练。知乎
Bun这次移植的体量值得细看：原有Zig代码约535,496行，完整重写按传统估算意味着至少一年的人力投入。知乎
官方的策略不是借机重新设计，而是尽量像把Zig代码机械地翻译成Rust，先保持相同架构、功能和行为——这等于把既有的TypeScript测试套件变成了跨语言的验收契约。知乎
于是整个迁移在11天内通过大约50个持续运行的工作流推进完成。知乎要知道Bun CLI目前每月下载量超过2200万，这种量级的项目敢用这种方式换心脏，本身就说明官方对行为等价的验证有足够信心。
所以现在的分工变成了：人负责提需求和验收，AI负责生成和修错，编译器负责挑错，测试负责兜底。以前"谁来重写"是最大的障碍——没有哪个团队愿意派一批工程师花几年去啃几十万个编译错误；现在这个问题从"人力成本"变成了"token+算力成本"，性质完全不同：AI可以不知疲倦地跑几百轮cargo check。Rust本身并没有让重构变得轻松，是AI把Rust重构所需要的人力成本打下来了。知乎
这也是为什么过去一年重写突然密集起来：微软、Meta、Cloudflare等公司纷纷把核心代码库重写为Rust，而推动这一浪潮的关键并非Rust本身的变化，而是AI大幅降低了重写成本。哔哩哔哩Meta的Flow类型检查器从OCaml移植到Rust后性能大约翻倍。JS工具链那边更夸张：Next.js的SWC、Vite 8的Rolldown、Tailwind v4的Oxide，全是Rust写的。
Rust官方为什么反手给AI立规矩：1300个PR教做人
再看另一面。如果AI写Rust这么顺，Rust官方为什么要限制？因为他们最先感受到了洪水：rust-lang/rust仓库里积压了1300个尚未关闭的PR。知乎过去开源社区有个隐含的信任：一份格式工整、测试齐全、描述详细的PR，说明背后有人花了大量时间理解代码——所以维护者不愿意轻易关PR，评审也是慢慢讨论。现在呢，这样的PR几十分钟就能生成一份，甚至可能是个没人值守的Agent提交的。
还有更糟的：有人收到评审意见后，直接把意见复制给LLM，再把AI的回答原封不动贴回来。政策起草者说得很直白：维护者如果想知道LLM怎么回答，完全可以自己去问。知乎
所以这份政策的边界划得很清楚：可以用LLM来回答问题、分析、提炼、精炼、检查、建议、评审，但不能用来「创造」。知乎具体拆开看：
允许：用LLM回答问题、分析RFC、提炼信息、润色、检查代码、参与评审——AI当参谋可以；
限制：AI直接生成代码进仓库，必须事先安排、非关键路径、高质量、测试充分、充分审查，外加披露。AI 生成的代码，需要达到比普通人类代码更高的门槛。知乎
红线：涉及soundness（健全性）的关键改动，除非作者本人就是该领域专家，否则不许LLM生成，就算专家也强烈不建议；
程序：评审员可以直接关掉违规PR，但"代码风格本身不能构成使用LLM的证据"，不许凭风格指控。
横向对比一下更有意思：Go核心团队前几个月因为一条"Co-Authored-By: Claude"的提交说明吵了一架，结论倾向于不接受AI署名、代码必须有人负全责；Zig则走得更彻底，在其行为准则里直接写明严格禁止一切LLM/AI生成内容。知乎Linux内核相对宽松，但要求AI辅助必须打Assisted-by标签。Rust走的是中间路线：不禁，但用披露和更高的门槛把责任钉在具体的人身上。
政策原文里有一句话值得所有技术团队抄下来：Review本质上由一连串决策组成。知乎AI压缩了"实现"的成本，但需求判断、架构选择、代码审查、责任归属这些没法规模化的环节，反而被暴露得更彻底了。
重写账单里那些meme不会告诉你的数字
热度归热度，Rustikon 2026那场演讲把账算得很诚实。先说真香的部分：uutils的sort靠并行，比原版GNU coreutils快了近4倍。知乎
安全账更硬：Google Android的官方数据显示，内存不安全语言的代码行数与内存安全漏洞数量之间存在明显的线性相关——少写一行不安全代码，就少一分CVE。知乎
但翻车清单同样真实：
bat在非交互模式（也就是纯管道输出、不涉及终端渲染）下，实测比cat慢了整整60倍，这个坑后来才修好。知乎
Linux的binder驱动出过Rust代码的首个CVE（unsafe块里的竞态条件），async-tar的解析错误甚至造成过远程代码执行漏洞，Cloudflare的机器学习评分组件出过unwrap问题，sudo-rs出过密码超时回显；
重写工期统计：小型几个月，中型1到2年，大型2到5年，最要命的是最后5%到10%的进度，把所有细节对齐到和原版一模一样，这一段往往决定值不值；
学习曲线是真的：谷歌的调查里，大约三分之二的开发者接触Rust代码库两个月后才觉得"有信心提交代码"。
演讲援引的工期统计更扎心：小型重写通常需要几个月，中型项目要1到2年，大型项目可能耗时2到5年。知乎而且几乎所有团队的预估最后都要超2到3倍——你以为在算加法，其实是在算乘法。
学习曲线也是真金白银：大约2/3的开发者在接触Rust代码库约两个月后会感到"有信心贡献代码"，而这还只是平均值。知乎也不是每个项目都撑到了终点：有Linux内核这样的标杆级成功，也有Prisma、LogLog这样体面退场的案例。
还有一个本月刷屏的案例，把"AI重写一切"的极限和代价都摆上了台面：有开发者让AI用Rust重写Postgres，短短几个月，两个人就生成了180万行Rust代码，而且几乎没有一行是手写的。知乎
账单便宜得惊人：他最后只花了大约十万美元和几个月时间，就得到了一个能通过全部官方测试的克隆版本，还通过了超过4.6万个回归查询。知乎
但真正该记住的是翻车点：Postgres里一条冷门的范围查询SELECT numrange_subdiff(1,1);，在pgrust上会让整个进程直接段错误。知乎性能账也没法看：pgrust的吞吐量约为每秒728笔交易，只有原版Postgres的九分之一，原版在同样的pgbench负载下能跑到每秒6365笔。测试全绿和段错误同时为真，这就是行为等价性的残酷之处。
这说明AI把生成180万行代码的成本压到了十万美元级别，但它没有、也暂时不能为"等价"兜底。最近一个正面示范值得学：有人用72小时把一个Python解析器移植到Rust，交付时摆出的不是"快了N倍"，而是20,041个differential fuzz用例、0分叉、连续600秒，外加unsafe块为0。知乎编译器能消灭use-after-free、数据竞争这一整类内存错误，但它不知道"退款接口调两次会不会真的退两次钱"——业务等价性只能靠测试矩阵来证。
一句话：先定义什么叫等价，再谈快。知乎
这笔账到底怎么算：一份四问清单
把这些信息摞在一起，"要不要用Rust重写"就从一句meme变成了一道可以算的题。给你一份检查清单。
值得认真考虑，最好四条同时满足：
项目当前用内存不安全语言编写，属于关键性软件，对性能和可靠性有明确要求，同时有大量并行代码——这种情况才值得认真考虑。知乎
瓶颈是真的：只有当内存安全、尾延迟、资源占用或跨平台约束已经成为真实瓶颈时，Rust的收益才可能覆盖团队学习和迁移成本。知乎
有基线测量数据，瓶颈定位到了语言层面，而不是"感觉慢"；
团队接受几个月的学习曲线和以年计的迁移周期，或者能用AI把人力成本压下来、同时把验证标准提上去。
建议先别动手：
如果模块只是普通CRUD、性能充足且维护稳定，继续使用团队熟悉的语言往往更划算。知乎
没做过profiling，只想靠重写解决"感觉慢"——很多系统变慢，原因其实是错误的数据库索引、过多网络往返或不合理缓存；
动机是"blazingly fast"这个梗本身。
如果决定动手，三个动作建议：
别整体重写。通过稳定的C ABI或其他FFI边界，Rust可以作为Node.js、Python、Go或移动端应用的性能模块，而不必重写整个系统，失败了损失也有限。知乎
先立oracle。把上游测试迁过来、搭differential测试，"什么叫等价"写在前面，性能数字写在后面；
用AI辅助没问题，但参考Rust官方那份政策的精神：AI生成的代码默认要过比人写代码更严的审查，soundness相关的改动交给真正的专家。
接下来值得盯的三个信号
最后给几个继续观察的线索：
Rust的LLM政策只是v1，只覆盖一个仓库，团队甚至在考虑成立一个专门负责LLM政策的子团队。知乎政策未来放宽还是收紧，取决于真实数据——AI贡献者是不是在学习、是不是会留下来做长期贡献；
下一代Coding Agent的比拼点，可能不再是"一天生成多少代码"，而是给人类增加多少审核负担：能够自动测试、提供修改依据、解释关键设计决策、控制任务范围、主动降低Reviewer的认知负担，可能会成为下一阶段Coding Agent更重要的能力。知乎
榜单只是滞后指标：2026年8月TIOBE编程语言排行榜，Go语言排名第14，Rust语言排名10。知乎真正该看的是Rustikon这种开始拿实测数据说话的场合越来越多——meme退潮，工程判断进场。
Rewrite It In Rust走到2026年，最大的变化不是Rust本身，而是AI把这道题从"要不要投入一个团队几年"变成了"要不要投入一笔token预算"。分子变小了，分母——审核、验证、责任——一分没少。算清楚这道题的关键从来不是AI有多强，而是你的问题到底是不是语言造成的。
