AI 辅助编程把一个老问题重新推到桌面上：新项目为什么还要默认选 Python 或 TypeScript？
过去这个答案很顺。生态大，招人容易，Demo 出得快。可如果大量代码由 AI 生成，再由编译器、测试和 CI 反复纠错，语言选型的重心就会移动。
问题不再只是“人写起来快不快”。
更关键的是：机器写完后，系统能不能快速发现错误，团队能不能长期维护，生产环境跑起来贵不贵。
过去赢的是交付速度，现在要重算验证成本
Python 和 TypeScript 过去十年的优势，不主要来自语法漂亮。
它们赢在现实工程里。FastAPI、Django、PyTorch、React、Next.js、npm、PyPI，把产品从 0 拼到 1 的成本压得很低。团队要做原型、后台、前端、数据脚本，默认选它们很自然。
这就是原文里那句核心对比：fast-to-ship 曾经胜过 fast-to-run。先发货，先验证需求，性能问题后面再说。
AI 改变的是这笔账的成本结构。
Rust、Go 这类语言过去的劣势，是人写起来更慢，门槛更高，调试和构建也更费心。现在，代理能补一部分样板代码和局部重构成本。强类型、编译器错误、测试套件，反而能给代理更明确的反馈。
这不等于“硬语言”突然没有成本。只是以前最贵的那一项，开始被 AI 打折。
| 选型问题 | 过去更常见的答案 | AI 介入后的变化 | 对新项目的含义 |
|---|---|---|---|
| 首版交付 | Python / TypeScript 更快 | 代理能降低 Rust / Go 的编写成本 | 不能只按 Demo 速度定语言 |
| 错误反馈 | 动态语言靠测试和运行暴露问题 | 编译器能给代理即时纠错 | 类型系统变成协作工具 |
| 生产成本 | 性能问题常后置处理 | 高性能语言收益更早进入决策 | 服务规模越大越要早算账 |
| 生态依赖 | PyPI / npm 是默认优势 | 底层高性能库越来越多由 Rust / Go 承担 | 包装层可能变成额外开销 |
我更在意的是“验证成本”。
AI 写代码越快，错误扩散也越快。能不能被编译器拦住，能不能被测试锁住，能不能被代码审查看懂，会比“这门语言我熟不熟”更早影响项目质量。
迁移案例能说明风向，但不能当万能药
原文提到几个案例：TypeScript 编译器迁往 Go、用 Rust 写 C 编译器、Ladybird 的 JavaScript 引擎迁 Rust、MiniJinja 做跨语言移植。
这些案例共同说明一件事：重写、移植、换底层语言，不再只是少数大团队才敢碰的工程动作。AI 让局部迁移的试错成本下降了。
其中，TypeScript 编译器迁 Go 最有象征意味。它不是普通业务系统，而是 JavaScript 生态的核心工具链之一。如果这类项目愿意为性能和可维护性付出迁移成本，说明“继续用原来的语言写一切”已经不是唯一默认项。
但这里要收住。
原文涉及一些 2026 年事件和具体数字，正式采信前需要逐项核验。即便案例属实，也不能推出“所有业务都该改用 Rust 或 Go”。个案迁移能成功，通常有几个前提：边界清楚、测试足够强、旧行为可对照、团队有人能做架构判断。
AI 不能替代这些东西。
它能加速样板代码、局部重构、接口适配。它不能自动决定系统边界，也不能替团队承担安全审查、错误预算和长期维护。
这里有一个很现实的限制：生态仍然重要。
PyTorch 在深度学习研究和模型原型里仍然强，Python 还是很难绕开。Serverless 环境可能不喜欢复杂的原生二进制包。WASM 部署也会改变语言选择。已有团队如果没有 Rust 维护能力，贸然迁移只会把交付风险换成维护风险。
所以判断不能写成“Python 要被淘汰”。
更准确的说法是：Python 和 TypeScript 的默认优势在下降，但它们在 AI 研究、数据科学、前端生态、快速原型里仍然有硬位置。
技术负责人要做的不是换语言，而是换评估表
受影响最大的，是两类人。
一类是技术负责人和架构师。新项目立项时，不该再只问“团队最快能用什么写出来”。还要问：核心路径会不会很早碰到性能瓶颈？生成代码有没有足够强的类型和测试约束？线上运行成本是否会随规模放大？
另一类是正在做语言选型的工程团队。动作可以更具体一点：
- 如果项目是原型、数据实验、模型研究，Python 仍然是高性价比选择，不必为趋势焦虑。
- 如果项目是长期运行的服务、工具链、网关、编译器、边缘组件，就应该把 Go / Rust 放进候选，而不是最后才想起性能。
- 如果团队准备用 AI 大量生成代码，先补测试、CI、类型约束和审查流程，再谈迁移。
- 如果现有系统跑得稳定，别为了“AI 友好”重写；先找边界清楚、收益可量化的模块试点。
这对采购和工具链选择也有影响。
团队不必急着押某一门语言，但可以延后一些“只服务旧流程”的决策。例如，只围绕动态语言优化的内部平台，可能要给 Go / Rust 的构建、测试、制品发布留位置。开发者也可以调整学习顺序：不用放弃 Python，但要补类型系统、编译器反馈、性能剖析和测试设计。
接下来最该看的不是哪门语言登顶。
要看三个条件是否同时成立：AI 编程工具对 Rust / Go 的修复质量是否稳定提升；企业测试体系能否跟上代理生成代码的速度；Python / JS 生态里的高性能底层是否继续向 Rust / Go 下沉。
如果这三项都成立，Python 的默认位置会继续松动。
不是退出舞台，而是不再自动坐主位。