AI 会写代码后，为什么还默认选 Python？
# 导语
过去十年，Python 和 TypeScript 的胜利并不主要来自运行性能，而来自“快”：生态成熟、招聘容易、Demo 能很快做出来。Rust、Go、C++ 等语言虽然性能高得多，却常被学习曲线、工程复杂度和人才成本挡在门外。文章的核心判断是：当 AI 代理已经能较好驾驭这些“困难语言”时，语言选择的底层账本正在重写。
# 核心内容
作者认为，AI 编程能力的跃迁首先改变的是系统语言的可用性。到 2026 年，多家大模型在 SWE-bench Verified 上快速突破，且越来越擅长并发、竞态、架构缺陷等系统工程问题。Rust 的强类型、编译器报错和快速反馈循环，反而让模型更容易自我修正；Go、Swift 也享受类似优势。过去对人类而言“不够顺手”的语言，对代理而言可能更像是带自动纠错的轨道。
文章列举了几个标志性案例。微软将 TypeScript 编译器迁移到 Go，TypeScript 7.0 beta 获得约 10 倍性能提升，理由是 Go 提供了足够大的性能收益，同时工程成本低于 Rust 或 C++。Anthropic 研究员 Nicholas Carlini 调度 16 个 Claude 代理，用 Rust 写出约 10 万行的生产级 C 编译器，能启动 Linux、编译 QEMU、FFmpeg、SQLite、PostgreSQL、Redis，甚至运行 Doom，总成本不到 2 万美元。Rust 资深开发者 Steve Klabnik 借助 Claude 两周写出约 7 万行 Rust 的新系统语言 Rue；Ladybird 浏览器作者 Andreas Kling 则在两周内用 Claude Code 和 Codex 将 JavaScript 引擎从 C++ 迁到 Rust，约 2.5 万行代码通过 6.5 万多个测试且无回归。
与此同时，Python/JavaScript 生态的“护城河”也在变化。pydantic 的核心、Polars、Hugging Face tokenizers、orjson、ruff、uv、ty、Rolldown-Vite 等关键工具或库都由 Rust 承担底层性能工作。也就是说，很多 Python 和 JS 开发者实际已经在使用“戴着解释型语言帽子”的 Rust 生态。随着 OpenAI 收购 Astral、Anthropic 收购 Bun，AI 公司也把高性能工具链视为 AI 主导软件工程的基础设施。
# 深度解读
这篇文章真正讨论的不是“Python 要死了吗”，而是软件工程的约束条件改变了。过去语言选择的核心约束是人类开发者的速度：人类写低层语言慢、调试难、犯错成本高，所以行业宁愿牺牲运行效率，换取更短的上市时间。现在如果 AI 代理承担大量编码、迁移和样板工作，人类的角色更多变成架构设计、验收测试、代码审查和产品判断，那么“好写”这件事的重要性就会下降，“好检查、好运行、好部署”的权重会上升。
这也解释了作者强调的另一个趋势：贡献单位可能从“补丁”转向“移植”。Flask 作者 Armin Ronacher 用代理将 Rust 库 MiniJinja 移植到 Go，总运行 10 小时，其中人类投入约 45 分钟，API 成本 60 美元。他由此指出，代码本身的价值可能下降，而测试和文档的价值上升。因为如果移植一个库的边际成本极低，开发者可能不再依赖原生态上游，而是直接 fork、port、重构。这会冲击 PyPI、npm 等生态长期以来靠补丁和共享维护形成的正反馈循环。
当然，作者也承认迁移不是万能答案。Prisma 反而移除了 Rust 查询引擎，转向 TypeScript/WASM，获得更小体积和更好 serverless 适配；PyTorch 在深度学习研究中的地位也不会因为语言偏好轻易动摇。AI 对 Zig、Haskell、Gleam 等较小生态语言的支持仍受训练数据限制。换句话说，Rust 和 Go 不是因为“哲学上更高级”而赢，而是因为它们既有足够训练语料，又有强反馈工具链。
# 启示与展望
对开发者和团队来说，新的问题不是“Python 还能不能用”，而是“下一个项目是否还应无脑默认 Python”。如果项目核心瓶颈在性能、并发、部署体积、工具链效率或长期运行成本，那么 AI 辅助可能已经足以抵消 Rust、Go 等语言过去的学习和开发成本。更现实的策略是：保留 Python/TypeScript 在原型、数据科学、研究和业务编排中的优势，同时在性能敏感层更大胆地直接采用系统语言。
长期看，编程语言的竞争可能从“对人类最友好”转向“对代理最友好”：类型系统清晰、编译器反馈强、测试容易自动化、文档结构明确的语言会更占优势。Python 不会消失，但它不再天然是所有新项目的默认答案。AI 让团队重新计算“开发速度、运行效率、维护风险”之间的平衡，而这可能是未来几年软件栈重组的真正起点。
