7月初，一个有十年经验的后端工程师在Twitter上发了一条推文，被转发了七千次："我今天Code Review了三个人写的代码，分别是我的同事、实习生，和一个从未见过面的外包。三份代码的风格完全一样。不是'很像'，是'一样'。"

不是他们训练了同一种风格，是他们用了同一个AI。

这位工程师翻出自己三年前写的代码做对比。三年前的代码里有他的痕迹：变量命名偏好驼峰，错误处理习惯把日志写在return之前，抽象层喜欢用中间层而不是直接依赖注入。现在的代码里这些痕迹全部消失了，取而代之的是整洁、规范、但毫无辨识度的代码。

代码开始失去口音，就像千万人开始说同一种不带任何方言的普通话。

AI代码的核心秘密：统计平均值

AI编程工具的底层是一个语言模型。语言模型的工作原理，是用统计学方法预测下一个最可能出现的Token。这个"最可能"不是"最好"，是"出现次数最多"。

当你让AI写一个用户认证模块，它生成的代码本质上是GitHub上几百万个用户认证模块的统计平均值。不是最优解，是最大公约数。

这个机制带来的第一个后果是代码质量的安全——AI生成的代码不会偏离主流写法太远，不太可能写出那种天才但难维护的奇葩架构。

第二个后果就没那么美好了：所有AI生成的代码都像从一个模子里刻出来的。

最近一篇在Hacker News首页挂了整天的博客分析了这个问题。作者让Claude、GPT、Gemini分别写同一个需求——一个带分页的REST API列表接口。三个模型生成的代码，除了变量名有细微差异，整体架构和实现路径完全重合。不是它们互相抄袭，是它们都在逼近同一个统计平均值。

当所有开发者的AI编程工具都在逼近同一个统计平均值，代码就正在变成一个没有作者面貌的工业产物。

风格不是装饰，是决策轨迹的化石

有经验的程序员读代码时，读的不只是逻辑。他们读的是写代码的人的决策轨迹——为什么这里用Strategy模式而不是简单if-else，为什么这个字段被标记为lazy load，为什么这个异常不是catch而是让它向上冒泡。

这些决策轨迹构成了代码的风格。风格不是装饰，是一系列上下文相关、经验驱动的微观决策的总和。当你看到一个Python开发者用了大量的类型注解和dataclass，你能判断出他大概率有过大型重构的经历。当你看到一个JavaScript开发者把每个异步调用都包装成Result类型而不是裸Promise，你能猜到他被线上异步Bug折磨过。

AI编程消灭的就是这些东西。它不读上下文，不承痛痒，不做经验驱动的微观决策。它做的是最大公约数决策。

Alec Scollon，一位在AI编程工具领域活跃的开发者，在自己的博客里写了这样一句话："我已经严重LLM倦怠了。不是因为技术太强让我没事做，而是因为技术太平均让我每次看到的都是同一套东西。"

这个倦怠的根源，是审美的消亡。

3D渲染领域有一个概念叫"一致性退化"。当渲染引擎为了性能把场景中的所有材质都做近似化处理，最终画面会失去材质间的差异感——金属不像金属，木材不像木材，所有东西看起来都像同一种哑光塑料。

AI编程带来的代码风格趋同，本质上就是一种"一致性退化"。不同的项目、不同的团队、不同的领域，产出的是同一种"材质"的代码。

这个问题的严重程度在开源社区里正在量化。GitHub上一个数据挖掘项目分析了2025年和2026年同期各10万个公开仓库的代码，发现AI生成代码的不同仓库之间的余弦文本相似度，比手写代码高出了47%。47%不是小数，这意味着将近一半的代码独特性在两年内被抹平了。

更有趣的是另一个发现：那些强制使用AI编程工具的企业内部仓库，代码风格差异实际上在缩小，但bug率并没有降低。也就是说，代码更"一致"了，但并没有更"正确"。"一致"和"正确"之间的差距，就是统计平均值和最优解之间的差距。

非程序员用户让审美问题变成了规模问题

如果说一个团队的代码趋同是审美问题，那么ChatGPT Work、Claude Cowork、Cursor Sand这类面向非程序员的产品涌入后，这个问题就升级为了规模问题。

这些新用户没有代码风格的概念。他们不在意变量命名。他们不关心架构设计。他们想要功能，任何功能，只要能跑就行。

这些用户输入的Prompt是纯粹结果导向的——"帮我做一个能分享笔记的页面"。AI生成的代码也是纯粹结果导向的——功能实现了，但风格上全部朝着统计平均值收敛。

一个月后，全球多了几百万行"风格一致"的AI生成代码。它们分散在不同的GitHub仓库、不同的公司项目、不同的开源框架里，但读起来像同一个人写的。

这听起来像是代码规范化的乌托邦。但规范化是统一了最佳实践，统计平均值统一的是最常见实践。两者不一样。最常见实践里包含了那些"能跑但不够好"的写法、那些"大家都在用但其实是十年前最佳实践"的模式、那些"方便但没有长期考虑"的设计。

7月初还有一个被开发者社区反复讨论的事件：一家中型科技公司的CTO在内部邮件中强制要求所有代码不得由AI生成超过30%，原因不是代码质量差，而是他读不懂不同人写的代码了。以前读代码他能分辨出哪个模块是老张写的（防御式编程，到处是null check）、哪个模块是小李写的（极简风，信任上层校验）。现在所有代码都是同一种AI风格，他做Code Review时丧失了80%的信息维度。这个CTO的要求是"保留30%的人工手写部分以维持代码可追溯性"——不是为了质量，是为了人还能读代码。

失去口音的代码，失去灵魂的工程

代码里那些不规范的"口音"，曾经是软件工程的生态多样性。一个Python开发者写Django用了大量的函数式风格，另一个开发者写Java用了大量的链式调用，这些偏离主流的写法不是错误，是经验的痕迹。

当一个社区所有的代码都开始说同一种话，这个社区失去了什么？

失去了质疑标准答案的能力。当每个人都用通用解法，没有人会问"这个方法对吗"。

失去了从边缘创新进入主流的路。历史上很多编程范式——函数式编程、响应式编程、事件驱动架构——都是从某个开发者"别扭"的代码风格开始的。如果AI编程在十年后统一了代码风格，下一个范式革命从哪里诞生？

也失去了读代码的乐趣。对很多工程师来说，读别人写的代码是理解另一个大脑运作方式的过程。当所有人大脑的AI部分运作方式完全一致，这个过程就不再有趣了。

AI编程给了全世界同一支笔。但笔迹是最容易识别的人的身份。当所有人的笔迹一模一样，签名就不再有意义了。