一个暴论：Java 在 AI 辅助编程时代会被很多人抛弃

最近几天在公司里写一个 MCP 相关的项目，因为某些原因，需要用 Python 和 Java 两种语言分别做一个相同的 demo。我拿 Cursor 分别写了两个语言的项目，过程中让我非常惊讶。

我首先写的是 Python 语言版本。我从一个可以运行的示例项目出发，描述我的需求让 Cursor 来写。整个过程非常顺利，Cursor 给出了全部的代码和示例说明。代码中有一处 bug，但是把 bug 现象描述给 Cursor 之后，它也很快修复了。

有了 Python 的成功经验之后，我又开始写 Java 的版本。代码思路整体不复杂，但是用 Java 写起来会比较啰嗦，为了方便 review 代码，我每次只让 Cursor 在当前的代码基础上修改一小部分。出人意料的是，Cursor 写的 Java 代码让我很不满意，有时是参数放错了位置，有时是出现了一个多余的参数。而且让 Cursor 把错误改正过来，它也不是很听话。

没办法，我只好手工修改 Cursor 写出来的代码。再让 Cursor 写下一部分的代码的时候，我写了一个更详细的 prompt，包括应该修改哪个文件的代码，修改成什么样子，参考哪里的代码，都交待了一遍。这样 Cursor 终于能乖乖听话写代码了。

写好代码之后我不禁思考，同样功能的项目，为什么 Cursor 在 Python 和 Java 代码上的表现不一样？虽然通过写好 prompt 也可以顺利让 Cursor 写 Java 代码，但这是否意味着 Java 的某些缺点让 Cursor 无法轻松驾驭？

思考之后，我得出一个不成熟的结论：

Java 在传统软件项目上的优点，也许恰恰是它在 AI 辅助编程上的缺点。

第一，Java 语言写起来很啰嗦。这种啰嗦换来的是写起来轻松，不容易写出奇奇怪怪的 bug。用 Java 可以很容易维护上万行代码的中大型项目。但是对于 AI 辅助编程来说，代码量大就是缺点。

大模型的命根子在 context，你有多少信息能塞进 context，大模型就能理解多少的信息。同样功能的代码，Java 的代码量要比 Python 多很多（粗略估计，我这个项目 Python 代码大概 300 行的功能，Java 代码要 1000 行）。那么大模型读同样数量的 token ，Java 代码的信息量要少很多，大模型就更难理解你的意思。

第二，Java 语言很容易出现各种「框架」，「接口」「继承」「设计模式」无处不在。这对于传统的团队协作开发当然是好事，大家遵循同样的框架，代码比较容易维护。但是这对于 AI 来说就难了，AI 要先理解你的整个代码框架，才能在框架里写合适的代码。你需要在 Cursor 里 @ 所有相关的文件。如果你忘记 @ 了，Cursor 又没有自动识别到需要参考这个文件，那它写出来的代码可能就不对了。

有一种说法其实挺有道理的：「设计模式其实是在弥补语言本身的局限性」。例如吭哧吭哧五六个类写的策略模式，Python 只需要把函数对象传进来就可以了。对于 AI 来说，Python 的方式显然更好理解，因为它需要看一个文件就可以了。而 Java 的设计模式要看五六个类，复杂度这就上了一个台阶。

有了这次的经历，后续我在项目中再选择 Java 语言就会更谨慎了。

假如我要写一个全栈项目，以前也许我会用 SpringBoot 写后端（因为最熟悉），但是现在考虑到 AI 辅助编程，我会更愿意用 Python 或者 Node.js，因为它们更适合用 Cursor 帮我写。

这就是我觉得 Java 会被很多人抛弃的原因。设想有一个初创团队，在只有几个人的时候做技术选型，考虑到 AI 辅助编程的情况下，大概率是不会选 Java 的。而等到项目规模大了的时候，也未必会迁移到 Java，因为团队如果是 Python/Node.js 技术栈，大概率和 Java 技术栈不相通。

当然，也有一种可能是团队的成员本来都是 Java 技术栈的，那么选 Java 也没有问题。这时候就需要有一个技术负责人把关整个 Java 代码的写法，不能再写出一堆看起来很酷炫，但是 AI 看不明白的代码了。还有就是要用新版本的 Java，var 关键字、多行字符串都能精简不少代码的写法，别再抱残守缺用着 Java 8 了。