如果 AI 为你写代码，为何还要用 Python？

# 如果 AI 替你写代码，为什么还要用 Python？ 来源：https://medium.com/@NMitchem/if-ai-writes-your-code-why-use-python-bf8c4ba1a055 按 Enter 或点击查看全尺寸图片 现代 Python 技术栈。### **在过去十年里，“快速交付”胜过“快速运行”。但时代变了。** 过去，为新项目选择编程语言通常是一个简单的决定。你会选择 Python 或 TypeScript，因为它们的生态系统巨大，人才储备深厚，而且你能在周五之前做出令人印象深刻的演示。Rust、Go、C++ 等语言能为你提供 10 到 100 倍的性能提升，但你需要为此付出代价：半年的上手时间、更小的人才市场，以及一个处处与你作对的构建系统。于是，你发布了 Python 版本，卖给了客户，并自我安慰说“以后再做性能优化”。你很少真的这么做，但这没关系，因为其他人也没这么做。 **这种交易已经结束，结束的原因是因为 AI 变得擅长处理那些难懂的语言。** ## 难懂的语言最先变得简单 两年前，GPT-4 在编写 Rust 函数时还经常幻觉出虚构的 crate（包）名称。到了 2026 年 4 月，Claude Opus 4.7、GPT-5.5、Gemini 3.1 和 DeepSeek V4 都在彼此相差几周内，在 SWE-bench Verified 基准测试中达到了 80% 以上的通过率。各大实验室正公开针对系统级工作进行优化：解决并发 bug、竞态条件，并在规划阶段识别架构缺陷。 CtrlAltDwayne (http://twitter.com/CtrlAltDwayne) 上个月给出了一条最精炼的解释： > “2026 年支持 Rust 的最佳理由不再是内存安全或性能。而是 AI 编写的 Rust 代码比它编写的 C++ 更好。编译器反馈循环如此紧密，使得模型能够实时自我纠正。每条错误信息都是一个免费的训练信号。Rust 在设计之初就无意中为 AI 辅助开发铺平了道路，而这比任何人意识到这一点的重要性早了 10 年。” 来自 X.com (https://x.com/CtrlAltDwayne/status/2032388050584736157?s=20) 同样的逻辑，在不同程度上也适用于 Go 和 Swift。强类型系统加上快速的编译-检查循环，为智能体（Agents）提供了最紧密的迭代周期。那些对人类来说最难掌握的系统级语言，事实证明对智能体来说反而最容易。 ## 实际交付的成果 看看在一个季度内落地了多少成果。 **微软用 Go 重写了 TypeScript 编译器。** 背后团队发布了 **TypeScript 7.0 beta** (https://devblogs.microsoft.com/typescript/announcing-typescript-7-0-beta/)，上周上线，速度比 6.0 版本快约 10 倍，这是通过将十年历史的 TypeScript 代码库移植到 Go 实现的。Anders Hejlsberg 的理由是 (https://thenewstack.io/microsoft-typescript-devs-explain-why-they-chose-go-over-rust-c/)：Go 以极低的工程成本提供了大部分的性能收益。地球上最大的 JS/TS 团队为其旗舰工具选择了一种更困难但更快的语言，而且他们之所以这么做，是因为努力的计算方式发生了改变。 Anthropic 的研究员 Nicholas Carlini **编排了 16 个并行 Claude 智能体** (https://www.anthropic.com/engineering/building-c-compiler)，用 Rust 编写了一个生产级的 C 编译器。10 万行代码。它在 x86、ARM 和 RISC-V 上引导 Linux 6.9。它编译了 QEMU、FFmpeg、SQLite、PostgreSQL 和 Redis。它甚至能运行 Doom 游戏。总成本：在近 2,000 次 Claude Code 会话中，总费用略低于 20,000 美元。 **用 Rust 编写 C 编译器曾经是硕士论文的课题。现在不是了。** Steve Klabnik，一位拥有 13 年经验的 Rust 老兵，也是《The Rust Programming Language》的共同作者，在两周内利用 Claude 构建了一种名为 Rue (https://www.theregister.com/2026/01/03/claude_copilot_rue_steve_klabnik) 的新系统级语言。大约 70,000 行 Rust 代码。他亲口说道： > “这次工作两周内取得的进展，比我上次花了一个或两个月取得的进展还要多。” Ladybird 浏览器的创建者、职业 C++ 工程师 Andreas Kling，**在两周内将 Ladybird 的 JavaScript 引擎从 C++ 移植到 Rust** (https://ladybird.org/posts/adopting-rust/)，他是通过向 Claude Code 和 Codex 发出数百个小型提示来完成的。大约 25,000 行 Rust 代码，与原始 C++ 代码实现逐字节等效，在超过 65,000 个组合的 test262 和 Ladybird 测试中零回归。 > “如果由我手工完成同样的工作，需要花费数月时间。” 2024 年这一切都不可能实现。2025 年这只是边缘案例。到了 2026 年初，这正变得司空见惯。 ## “但是生态系统呢？”这种说法站不住脚 支持 Python 和 JavaScript 的最强有力论点从来不是语言本身。而是生态系统：FastAPI、Django、PyTorch、React、Next.js、npm 上的 400 万个包。“我们的团队能在几天内交付功能，因为生态系统已经解决了 90% 的问题。”在过去 10 年里，这是决定性的因素。但在过去两年里，这种优势正在悄然侵蚀。 当你 `import pydantic` 时，整个验证核心其实是一个 Rust 库。Pandas 的替代品 Polars 是 Rust 写的。Hugging Face 的分词器是 Rust 写的。orjson 是 Rust 写的。**JetBrains 2025 年 Python 调查** (https://blog.jetbrains.com/pycharm/2025/08/the-state-of-python-2025/) 捕捉到了遥测数据：用于 Python 二进制扩展的 Rust 使用率在一年内从 27% 跃升至 33%。 **Python 生态系统越来越像一个戴着 Python 帽子的 Rust 生态系统。** 基础设施工具也遵循相同的轨迹。由 Charlie Marsh 于 2022 年创立的 Astral 公司发布了 ruff、uv 和 ty。这三个工具全部用 Rust 编写，而且全部从零增长到每月数亿次下载。2026 年 3 月 19 日，OpenAI 收购了 Astral (https://openai.com/index/openai-to-acquire-astral/)；内部理由是 uv 每周为 Codex 节省约一百万分钟的算力。十周前，Anthropic 收购了 Bun (https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone)（每月下载量 700 万，GitHub 星标 89,000），并将其定位为“AI 驱动软件工程的关键基础设施”。Evan You 的 VoidZero 发布了 Rolldown-Vite (https://voidzero.dev/posts/announcing-rolldown-vite)，这是一个 Rust 打包器，将 GitLab 的 2.5 分钟构建时间缩短至 40 秒，内存占用减少了 100 倍。 Vercel 产品副总裁 Lee Robinson 表示：“我们在 JS 方面已经达到了优化的峰值。” “但是生态系统”剩下的唯一论点是：你在 Python 和 JavaScript 中导入的包，越来越多地是围绕用你被告知无法交付的语言编写的代码所做的包装器。现在你可以直接用那些语言进行交付，而这个包装器开始显得像是多余的开销。 ## 既然可以移植，何必打补丁？ 旧的开源交易有一个正反馈循环。你选择 Python 因为它简单。你在依赖项中发现了一个 bug。你修复它。你将修复方案上游合并。生态系统变得更加健康。 智能体以特定方式打破了这一循环：**贡献的单位从“补丁”转移到了“移植”。** Flask 的创建者 Armin Ronacher 在一月份利用智能体将他的 Rust 库 MiniJinja 移植到了 Go (https://lucumr.pocoo.org/2026/1/14/minijinja-go-port/)。整个过程持续了 10 小时，其中 3 小时有人监督，7 小时无人值守。他实际投入的人工时间仅为 45 分钟。API 成本为 60 美元。如果跨语言移植一个库只需要 45 分钟，那么向上游合修复他人库的修复方案的理由每月都在减弱。既然可以移植，为什么还要打补丁？ 他本人的观察： > “对我来说，价值正从代码转移到测试和文档。一个好的测试套件实际上可能比代码更有价值。” 构建 PyPI 和 npm 的那个循环今天仍然有效。但不明显的是，它在 2028 年是否还能有效。 ## 这个论点哪里会失效 这并不是全面胜利。有几件事值得承认。 首先，有时正确的答案仍然是旧答案。**Prisma 移除了其 Rust 查询引擎** (https://www.prisma.io/blog/from-rust-to-typescript-a-new-chapter-for-prisma-orm)，转而采用 TypeScript/WASM 核心：包大小减少了 85%，查询速度提高了高达 3.4 倍。原生 Rust 二进制文件对无服务器运行时不友好。PyTorch 仍然占据约 85% 的深度研究学习领域，这不会改变，因为模型权重并不关心你用什么语言包裹它们。 其次，AI 并非在所有系统级语言上都同样出色。像 Zig、Haskell 和 Gleam 这样较小的语言，在 AI 生成（目前）时并没有相同的质量。 训练数据决定了模型能帮助你什么。Rust 和 Go 中了彩票，因为它们足够流行，淹没了 GitHub。Zig、Haskell 和 Gleam 仍然处于该曲线的劣势一侧。 ## 转变之所以是永久性的原因 过去对 Python 和 TypeScript 的辩护，实际上是对开发者体验的辩护。选择这些语言是因为它们最小化了人类想法与交付产品之间的摩擦。Rust 在运行时从未更慢；它在凌晨 2 点你需要发布时更慢。 **智能体现在做艰难的部分。** 人类的工作从“编写代码”转变为“设计系统和审查输出”。在这种工作流程中，Python 的人体工程学优势每个季度都在减弱，而更难的语言的运行时优势随着你在生产中运行服务的每一天而复合增长。 Armin Ronacher 在他 2 月的文章《为智能体设计的语言》(https://lucumr.pocoo.org/2026/2/9/a-language-for-agents/) 中提到： > “新语言可能奏效的最大原因是，编码成本正在急剧下降。结果是，生态系统的广度重要性降低了。” 过去二十年的语言选择受到一个单一约束的影响：人类编写代码，而人类在低级语言上很慢。这个约束已经消失。Stack Overflow 2025 年调查显示，Rust 连续第十年成为最受尊敬的语言，占比 72%，Gleam 占 70%，Elixir 占 66%，Zig 占 64%。这种偏好一直存在；工具终于赶上了这种偏好。 Karpathy 在 2 月描绘了更广阔的图景 (https://x.com/karpathy/status/2023476423055601903)： > “LLM 完全改变了软件的整个约束格局。这已经初现端倪，例如 C 向 Rust 移植的趋势日益增强。”他补充说，“甚至 Rust 作为 LLM 的目标语言也远非最佳。” 今天的赢家只是开局的一步，终局还要看得更远。 4 月 24 日，@RealRichomie 在 X 上给出了对新制度最清晰的表述 (https://x.com/RealRichomie/status/2047509168442196230?s=20)： > 编程的未来不属于对人类最容易的语言。它将属于对智能体最容易的语言。我们刚刚交付了一个 Mac 应用，我们的工程师在此之前甚至不知道一行 Rust（或 Tauri）代码。结果：大小约为 Electron 版本的 1/10... 高性能。智能体是新的程序员。 一个已交付的应用，使用团队中无人知晓的语言，大小是 Electron 版本的十分之一，运行时更快。人类根本不需要学习 Rust 就能达到这个结果。 你下一个启动的项目不必默认使用 Python。