AI 代理正在重塑语言选型

过去十年选语言有一套很稳定的算法：默认 Python 或 TypeScript， 用生态和开发速度换性能。要极致性能再考虑 Rust、C++，但得接受陡峭的学习曲线和更慢的交付节奏。

这套算法正在失效。原因不是 Rust 变简单了，而是学习成本这一项被外部化了 —— 它可以由代理承担。当"写出第一版能跑的代码"变得便宜，选型的约束条件就整个换了。

"语言税"是什么

引入一门新语言，团队付出的成本远不止语法。至少有四层：

• 语法层 —— 最浅的一层，也是最容易被误认为全部的一层
• 生态层 —— 标准库形状、包管理、常用库的成熟度与文档
• 构建层 —— 编译流程、产物分发、CI 集成、跨平台打包
• 调试层 —— 报错怎么读、内存/并发问题怎么定位、有哪些惯用工具

代理显著降低的是第一层和第三层的起步成本：它能产出一个可编译的骨架， 告诉你怎么写构建脚本。但第二层和第四层几乎没被降低 —— 这两层恰好是决定项目能不能长期维护的部分。

为什么静态类型语言成了受益方

一个反直觉的现象：代理最擅长的不是最简单的语言，而是反馈最明确的语言。

Rust 编译器以严苛著称，对人的体验是"难"，对代理的体验却是"信号密集"： 每条错误信息都指明了类型不匹配的位置和期望形式，代理可以据此自我修正， 不需要人去猜。Go 同理 —— 编译器严格、工具链统一、gofmt 消除了格式争议， 几乎没有"多种正确写法"的模糊地带。

已经发生的事

这不是推测，2026 年已经能看到具体的迁移案例。最受关注的是 TypeScript 编译器本身用 Go 重写 （见另一篇文章的分析）：团队选择 Go 而非其他方案， 理由是它在拿到大部分性能收益的同时，工程成本低得多 —— 而这一权衡之所以可行， 与代理能承担大量机械性移植工作直接相关。

其他公开案例包括：用多个代理并行工作的方式产出一个能启动 Linux、 编译 SQLite 与 Redis 的 C 编译器（约十万行）；把 JavaScript 引擎从 C++ 移植到 Rust 并在数千个测试上保持零回归；以及用代理把 Rust 库移植到 Go 这类原本耗时数周的工作压缩到小时级。

风险去了哪里

有人认为代理生成的代码更容易出安全问题。这个判断有一个容易混淆的地方： 引用最多的数字（"AI 代码的漏洞数量是人工的 2.74 倍"）来自特定实验设置， 不能直接当成普遍结论。更可靠的说法是： 代理会自信地写出看起来正确但边界处理错误的代码。

典型的失败模式在系统层尤其危险：

• 内存管理看似正确，但所有权转移的语义理解错了
• 网络代码没处理分包边界与半包情况
• 密码学代码"能跑通"，但用了不该用的模式或错误的随机源
• 硬件相关代码忽略了时序与并发假设

这些问题有个共同特征：编译通过、单元测试通过、评审时也读得通。 它们只在真实负载、真实数据、真实硬件上暴露。

可行的做法：把目标变成可测量的

目前被验证有效的模式，是把"让代理写代码"改造成"让代理在约束下优化一个可测量的目标"。 流程是固定的：

1. 定义目标        延迟 < 8ms / 产物 < 200KB / 内存 < 40MB
2. 建立基准        写一个可重复运行的 benchmark，固定输入与机器
3. 让代理改一处    单次只允许改动一个模块，便于归因
4. 跑测试 + 基准   不通过就回退，不接受"略有下降"
5. 人工评审        重点看 unsafe 块、边界条件、错误处理
6. 合并            基准与代码同仓，防止后续悄悄退化

这套流程的价值不在于"用了 AI"，而在于它强制把模糊的"更好"变成了数字。 一旦有了数字，代理的产出就变得可证伪 —— 而这正是它此前最缺的东西。

一个具体的检查清单

如果你要用代理尝试一门团队不熟悉的语言，至少先准备好这些：

• 可运行的测试套件 —— 没有就别开始，这是前置条件而非可选项
• 基准测试与基线数据 —— 否则无法判断改动是改善还是退化
• 模糊测试与内存检查 —— 针对系统层代码，unsafe 边界逐个审
• 跨平台验证 —— 在支持的所有平台上跑，而不只是开发机
• 一位懂这门语言的人 —— 哪怕每周只能投几小时。没有这个人，风险不可控

生态论据也在松动

为高层语言辩护的最强理由一直是生态：FastAPI、Django、PyTorch、React。 但一个容易被忽略的事实是，这个生态本身越来越建立在更快的语言之上：

• Python 里的 pydantic 核心是 Rust
• polars（pandas 的替代品）用 Rust 写
• Hugging Face 的 tokenizers 用 Rust
• Ruff、uv、Bun 全部用 Rust 实现

JetBrains 的调查显示，Python 项目中用 Rust 写二进制扩展的比例在一年内从 27% 上升到 33%。 也就是说，你继续用 Python 写业务逻辑没问题，但性能敏感的底层早就不是你选的那门语言了。

结论：更便宜的实验，更贵的判断

语言选型不会因为代理而变得无关，但试错的成本结构变了。 以前"要不要试试 Rust"这个问题，答案往往是"学习成本太高，算了"； 现在可以更低成本地试一次 —— 前提是你能验证结果。

所以真正的分界线不是会不会用代理，而是有没有能力判断代理的产出对不对。 有测试、有基准、有懂行的人，代理让你能更快地探索更多方案； 没有这些，代理只是让你更快地积累看不懂的代码。

工具降低了进入门槛，判断力没有降低。 这两件事之间的距离，就是接下来几年工程师价值所在的位置。