AI 写代码时，我为什么越来越少用 Python

最近我在项目里越来越明确一个判断：

当 AI 开始大量参与写代码之后，我选语言的标准，已经变了。

以前很多人选 Python，是因为它写得快、上手快、生态成熟。

这些优点到今天依然成立。

但如果场景变成“我让 AI 持续参与实现一个要长期维护的系统”，那我现在通常不会先让它用 Python 起手。

不是因为 Python 不好。

而是因为我越来越在意另一件事：

AI 写出来的代码，到底能不能被尽早约束住。

这篇文章，我想只聊一个问题：

为什么在 AI 编程越来越普及之后，我反而更倾向于让 AI 去写 TypeScript，甚至在一些关键场景里考虑 Rust，而不是默认先写 Python。

一、我遇到的核心问题，不是 AI 会不会写，而是它会不会“悄悄写错”

这两年很多人都感受到一件事：

AI 写代码，确实快。

一个页面。一个接口。一个管理后台。一个数据处理脚本。

以前可能要写一天的东西，现在几个回合就能跑起来。

但我在实际项目里越来越警惕的，不是“它写得慢不慢”，而是：

它写得太顺了。

很多代码第一次看上去都没问题：

• 结构完整
• 命名正常
• 逻辑看起来也合理
• 甚至本地还能跑通

可一旦进入真实业务环境，问题就出来了。

比如：

• 某个字段本来允许为空，AI 当成一定有值
• 某个参数本来是订单 ID，AI 混成了用户 ID
• 某个状态只允许按固定顺序流转，AI 直接跳步骤
• 某个权限判断本来必须保留，AI 为了“让代码先跑起来”绕过去了

这些问题最麻烦的地方，不是语法错。

而是它们看起来像对的。

如果没有很强的约束，它们往往不会在生成代码那一刻暴露，而是会拖到运行时、测试阶段，甚至线上才出问题。

这也是我这段时间越来越明确的一点：

AI 最危险的时候，不是不会写，而是能写出“表面正常、实际带坑”的代码。

二、为什么这个问题在 AI 时代会变得更严重

因为 AI 放大的，不只是开发速度。

它同时也放大了错误实现的速度。

以前是人慢慢写错。现在是机器高速写错。

如果你做的是简单脚本，这个问题还没那么严重。

但如果你做的是这些东西，风险会立刻上来：

• 企业内部系统
• 有权限控制的后台
• 带订单、支付、审批的流程
• 老系统改造
• 多人协作、要长期维护的项目

这些场景有一个共同点：

真正重要的，往往不是“功能有没有写出来”，而是边界有没有守住。

什么字段能传。什么状态能改。什么角色能操作。什么情况必须报错。什么数据绝对不能混。

这些约束，如果只放在文档里、注释里、或者人的脑子里，AI 很容易忽略。

因为 AI 的天然倾向是：

先给你一个看起来能工作的答案。

但工程落地不一样。

工程落地不是比谁先把代码生成出来。而是比谁能更早发现“这段代码其实不该这样写”。

三、我为什么越来越看重强类型语言

我现在越来越把编程语言看成两层东西。

第一层，当然是开发工具。

第二层，在 AI 编程场景里，它其实还是一种约束工具。

这也是我越来越偏向 TypeScript 的原因。

因为 TypeScript 做了一件对 AI 很重要的事：

它把很多原本要靠人脑记住的约束，提前变成了编译器可以检查的规则。

这个概念如果用普通话讲，其实不复杂。

你可以把类型系统理解成：

先把“什么东西可以传进来、什么东西必须传出去、什么值不能乱用”写清楚。

而编译器，就像一个不会累的审核员。

AI 每写一版代码，它都会立刻检查：

• 这个字段是不是可能不存在
• 这个返回值是不是和承诺的不一样
• 这个对象结构是不是对不上
• 这个参数类型是不是传错了

这件事为什么重要？

因为它把很多错误，从“线上事故”往前推到了“写代码当下”。

这不是小优化。

这在 AI 编程里，几乎是工作方式级别的变化。

以前你让 AI 写一段动态语言代码，它更像先把东西拼出来，再靠你和测试慢慢兜底。

现在如果你让它在更强约束的环境里工作，它就像被放进了一条有护栏的轨道。

它依然会犯错。

但很多低级错误、边界错误、契约错误，会更早暴露。

四、我现在怎么选：不是“哪个语言更高级”，而是“哪个语言更适合约束 AI”

我现在的做法其实很务实。

1. 如果只是一次性脚本、数据处理、小实验，Python 依然很好用

这一点我不会为了“立场”去否认。

Python 在很多场景里仍然非常高效：

• 快速验证一个想法
• 写临时工具
• 跑数据处理
• 接模型、调 API

如果东西本身生命周期短，风险也低，那我不会为了形式感硬上强约束。

2. 一旦进入正式业务系统，我会优先考虑 TypeScript

尤其是这些情况：

• 要多人协作
• 要长期维护
• 需求还在持续演化
• 前后端接口多
• 有权限、状态、流程约束

这时候我更看重的是：

AI 写出来的东西，能不能被持续校验。

TypeScript 的价值，不只是“类型安全”这四个字。

更实际一点说，它会让很多本来靠经验防守的问题，变成工具层面的常规检查。

这对 AI 编程特别重要。

因为你不可能指望每一次提示词都写得极其完美。但你可以尽量把规则沉淀到代码结构里。

3. 我会尽量把业务规则写进类型里，而不是写在注释里

这是我现在很看重的一点。

如果一个系统里最关键的规则，只存在于注释、需求文档或者口头说明里，那 AI 很容易“看过就忘”。

但如果这些规则被写进类型定义里，情况就不一样了。

比如：

• 哪些状态允许流转
• 哪些字段是必填，哪些是可选
• 哪两类 ID 不能混用
• 哪些输入必须先校验再落库

这些东西一旦进入类型系统，AI 的发挥空间就会变小，但正确率会更高。

我越来越相信一句话：

在 AI 编程里，好的类型定义，本质上就是高质量约束。

4. 如果是高风险、高性能、底层组件，我会认真考虑 Rust

我不会说 Rust 适合所有团队。

但如果场景是这些，我会很认真地看它：

• 对稳定性要求极高
• 对并发和性能要求高
• 容错空间很小
• 希望把很多潜在问题尽量前移

Rust 的学习成本当然高。

但从 AI 编程的角度看，它有一个很现实的优势：

它对“不严谨的实现”容忍度很低。

这意味着，AI 生成的代码如果想进入可运行状态，必须先过一轮非常严格的检查。

从工程管理角度看，这反而不是坏事。

因为很多原本会拖到后面爆炸的问题，会被提前卡住。

五、这套选择带来了什么变化

它没有让我彻底告别 bug。

真实项目里，也不存在这种神话。

但它确实让我在几个方面更稳了。

第一，AI 输出更容易收敛。

以前我经常会遇到一种情况：同一个需求，AI 每改一轮，都像在重新发明一次实现。

现在如果类型边界先搭好，AI 的修改空间会小很多，输出也更稳定。

第二，代码评审更聚焦。

以前 review 时，我经常要花不少时间盯那些本来不该晚发现的问题，比如字段对不上、空值没处理、结构不一致。

现在这类问题有相当一部分会在前面就被拦下来。我能把更多精力放在真正重要的地方，比如业务规则是不是合理、边界是不是完整。

第三，系统更适合长期维护。

这点在企业软件和遗留系统改造里尤其明显。

因为这类系统最怕的，不是短期开发慢一点。而是后面每改一次都担心牵一发动全身。

强约束语言不一定让你一开始最快。但它往往会让你后面少踩很多“看起来不大、实际上很贵”的坑。

六、有哪些经验我觉得可以直接复用

如果你也在用 AI 写代码，我觉得下面几条很值得尽早调整。

第一，不要只按“人工写代码的爽感”选语言。

AI 时代，语言不只是给你自己用的。它也在决定 AI 犯错时，谁能最先发现。

第二，不要把提示词当成唯一控制手段。

提示词当然重要。但真正稳定的约束，最好落在类型、接口、测试和编译检查里。

第三，不要把“能跑”当成“适合上线”。

AI 特别容易把系统推到一个“看起来差不多了”的状态。但企业系统真正贵的，往往不是做出来，而是做稳。

第四，不要一上来就争论“Python 还是 TypeScript 谁更好”。

更有价值的问题是：

你当前这个项目，最需要的是生成速度，还是可验证性。

如果是前者，Python 没问题。如果是后者，我会更倾向于把约束做重一点。

结语

这也是我想在 AI开发下一站 持续讲清楚的一件事：

AI 编程真正改变的，不只是“写代码更快了”。

它还逼着我们重新思考：

什么才是软件交付里最值钱的能力。

在我看来，答案已经越来越清楚了。

不是把代码更快地敲出来。而是把系统边界更早地定义清楚，把错误更早地拦下来，把后期返工尽量消灭在前面。

所以如果你问我，AI 时代我最大的语言选择变化是什么，我的答案会很直接：

我不是突然不喜欢 Python 了。

我只是越来越不愿意在需要长期负责的项目里，把“约束不足”当成一种自由。

后面在这个号里，我还会继续写这类更偏实战的内容，比如：

• AI 写出来的代码，怎么做工程化接手
• 遗留系统改造里，AI 到底适合做什么
• 企业项目里，怎么给 AI 建可执行的约束

如果你现在也在做 AI 编程落地，或者你手上正好有一个“原型跑得很快，但系统越来越不稳”的项目，欢迎关注 AI开发下一站。