最近用 AI 辅助写代码的时候，我注意到一个有意思的现象：写 Go 的时候，AI 生成的代码通常很靠谱，风格也一致；但写 Python 的时候，AI 经常给出好几种写法，有时候还会搞出些奇奇怪怪的"聪明"代码。
这让我开始思考一个问题：AI 辅助编程会不会改变编程语言的流行趋势？
评价标准变了
以前我们选编程语言，主要考虑的是"写起来爽不爽"。语法糖多、表达简洁、少打几个字，这些都是加分项。Python 能一行搞定的事，凭什么要写五行 Java？
但现在情况变了。AI 帮我们写代码，“写起来爽"这个优势基本没了。反而，那些让人"写起来爽"的特性，可能成了 AI 的负担。
我总结了几个在 AI 时代变得更重要的语言特性。
语法糖越少越好
语法糖的本质是让程序员少打字。但 AI 不在乎多打几个字，它在乎的是"这段代码应该怎么写”。
Python 里实现一个简单的过滤和映射，至少有四五种写法：
1# 列表推导
2result = [x * 2 for x in items if x > 0]
3
4# map + filter
5result = list(map(lambda x: x * 2, filter(lambda x: x > 0, items)))
6
7# 传统循环
8result = []
9for x in items:
10 if x > 0:
11 result.append(x * 2)
12
13# 还可以用 itertools...
对人来说，列表推导"更优雅"。但对 AI 来说，这就是个选择题：到底该用哪种？结果就是 AI 每次生成的代码风格都可能不一样。今天给你来个列表推导，明天给你写传统循环，后天又换成 map/filter。
Go 在这方面就简单很多。想遍历？for range。想过滤？写个 if。基本上只有一种明显的写法，AI 不需要纠结。
更麻烦的是各种"魔法"。Ruby 的元编程、Python 的各种 dunder 方法、运算符重载，这些东西人类觉得很酷，但 AI 容易搞混。我见过 AI 把 __getitem__ 和 __getattr__ 搞混的，也见过它自作聪明地用元编程结果出 bug 的。
风格和生态要统一
Go 有个 gofmt，整个社区的代码格式都一样。Python 呢？black、autopep8、yapf 各有各的风格，还有人坚持手动格式化。
这个差别看起来不大，但对 AI 影响挺明显的。风格统一意味着 AI 见过的代码都长得差不多，训练效果好，生成的代码也更符合预期。
更重要的是标准库和第三方库的选择。Go 的标准库比较全，而且通常只有一种"标准做法"。Python 和 JavaScript 就不一样了，随便一个需求都能找出十几个库来。
比如 JavaScript 处理日期，光常用的就有 moment.js、date-fns、day.js、luxon… AI 该推荐哪个？经常出现的情况是，它这次用 moment，下次用 date-fns，代码库里搞得乱七八糟。
Rust 在这方面做得也不错。cargo 统一了构建和依赖管理，rustfmt 统一了代码风格。虽然 Rust 语法复杂，但至少生态是整齐的。
架构要扁平
AI 的上下文窗口虽然越来越大，但终究是有限的。而且跨文件理解这事，AI 现在还做不太好。
这就带来一个问题：过度的抽象和拆分，会让 AI 晕头转向。
假设你有个函数，调用了另一个函数，那个函数又调用了第三个，第三个在另一个文件里，还用了个接口做抽象… 人读起来都费劲，别说 AI 了。
我之前写过一篇文章讨论重复代码的问题。有些简单的重复，其实不需要抽象。五次相似的函数调用，直接写五遍，清清楚楚。非要搞个高阶函数或者引入设计模式，表面上消除了重复，实际上增加了理解成本。
在 AI 时代，这个观点可能更适用了。因为 AI 很难跨越多层抽象来理解你的意图。扁平的代码，虽然看起来有些重复，但 AI 能看到完整的逻辑，反而容易生成正确的修改。
当然这不是说完全不要抽象，而是说过度抽象的代价变高了。如果抽象不能显著降低复杂度，那就别抽了。
显式好过隐式
这可能是最重要的一点。
Go 的错误处理被吐槽了无数次，满屏的 if err != nil。但你不得不承认，这种写法很明确。AI 一眼就能看出来哪里可能出错，该怎么处理。
相比之下，Python 和 Ruby 的异常机制就很隐式。一个函数可能在任何地方抛异常，你不看文档根本不知道。AI 也不知道，所以它经常忘记处理某些异常，或者过度防御到处 try-catch。
类型转换也是一样。Go 要求显式转换类型，Python 可以隐式转换。显式的好处是代码即文档，你一眼就能看出来这里发生了什么。AI 也一样，它不需要根据上下文推断类型。
Rust 在显式这方面做到了极致。所有可能的错误都要处理，所有的 case 都要覆盖到，否则编译不过。虽然写起来累，但对 AI 来说这是好事——它不需要猜测，按照编译器的要求来就行了。
类型系统很重要
TypeScript 这几年爆发式增长，我觉得 AI 辅助编程是个重要原因。
没有类型的时候，AI 只能靠猜。这个变量是字符串还是数字？这个函数返回什么？有了类型标注，这些问题都有明确答案。
我自己的体验也很明显。写 TypeScript 的时候，AI 的自动补全和建议通常很准确。写纯 JavaScript 的时候，AI 经常需要猜，然后就容易猜错。
Python 现在也在推类型标注。虽然不是强制的，但我觉得未来类型标注会变成事实标准。不加类型标注的 Python 代码，就像没有 JSDoc 的 JavaScript，AI 理解起来会比较吃力。
几门语言的机会和挑战
基于前面这些特点，我们来看看几门主流语言。
TypeScript 应该是最大的受益者。JavaScript 加上类型系统，正好解决了 JS 最大的痛点。AI 有了类型信息，能生成更准确的代码。我觉得 TS 现在这么火，AI 辅助编程的普及是个重要推手。
Go 也是受益者。语法简单、语法糖少、风格统一、显式大于隐式，几乎所有特点都很 AI 友好。我用下来的感觉是，Go 可能是 AI 生成代码质量最稳定的语言。
Rust 比较复杂。一方面，Rust 的类型系统强大、风格统一、要求显式，这些都是优点。另一方面，Rust 学习曲线陡，语法也不简单。不过我觉得 AI 可能会降低 Rust 的门槛。编译器报错的时候，AI 能帮你解释错误、给出修改建议，这对新手来说价值很大。
Python 有点矛盾。优势是简单易读、生态好、AI 的训练数据最多。但劣势也明显：动态类型、太灵活、语法糖多。我觉得 Python 需要进化，类型标注要普及，写法要收敛。否则在 AI 时代可能会逐渐失去优势。
Java 可能会翻身。以前 Java 被吐槽最多的就是啰嗦。但在 AI 时代，啰嗦不再是缺点。类型明确、显式表达、没有魔法，这些反而是优势。AI 写 Java 代码不需要纠结"怎么写更简洁"，按部就班写就行了。
Ruby 恐怕有麻烦了。Ruby 的设计哲学是"让程序员开心"，各种语法糖、元编程、灵活性，这些对人类程序员确实很爽，但对 AI 来说全是困扰。我见过 AI 生成的 Ruby 代码，经常出现风格不统一、用了奇怪的魔法方法这种问题。
C++ 也不太乐观。语法太复杂，历史包袱太重。AI 生成 C++ 代码的时候容易出现各种奇怪的问题，有时候是新旧标准混用，有时候是不该用的特性乱用。
对未来的一点想法
编程语言的设计，一直在考虑"人类可读性"。未来会不会也考虑"AI 友好性"？
我觉得这个趋势已经开始了。越来越多的语言引入类型系统，越来越多的项目强制使用代码格式化工具，这些都在让代码变得更"结构化"、更"明确"。
不过这里有个有趣的矛盾：人类喜欢简洁和灵活，AI 喜欢明确和统一。我们该往哪边靠？
我的看法是，这不是非此即彼的选择。好的语言应该在两者之间找到平衡点。人类能理解，AI 也能理解，这才是未来。
最后说一句，这不代表某些语言就会消失。语言的流行度受很多因素影响，技术特性只是其中之一。但我确实觉得，AI 辅助编程会让评价标准发生一些变化。
那些在 AI 时代更"友好"的语言，可能会获得更多的机会。
注：文中提到关于我在 AI 编程时遇到的各种状况，全都是 AI 生成的，如有不切实际本人概不负责，我只提供了本文的基本观点。