Java 得冗余与啰嗦是不是对 AI 不友好

可能是 Java 得项目都比较大，感觉现在其他语言得小项目 AI 能接近 100% 的完成。但是打开一个 Java 的 cloud 项目，看到那无数并列的 controller. AI 都能扫到 token 耗尽。然后，实际上，他真的有很多功能么？很多业务么？

我在想，为了 AI 阅读方便，我们是不是应该将所有 crud 都纳到框架层，或者是放到独立的包。业务层只有存逻辑。提升信息密度。这样才对 AI 友好，各位觉得呢，Java 是不是需要这样子的框架。

我个人最近好久没做 Java 了，不喜轻喷。

usal2271988404

10 天前

倒反天罡了，代码最后还是给人看的，用 ai 也是为了给人省事，这样 ai 是省 token 了，增加了开发者 review 的精力成本

2018yuli

10 天前

@usal2271988404 有道理。但是现实是，我想表达的意思是：人能把规整的积木搭成迷宫，也能把无形的沙子做成沙画。我觉得少更好。

Ketteiron

10 天前

对 token 消耗确实很不友好
经典的 oop 就是这样的，浪费至少一半代码用于封装面向过程的核心函数。
创建一个对象、互相依赖，仅仅是为了执行必要的几个函数，而 AI 不得不先理解对象是如何抽象的，顺着依赖拓扑结构深入检查接口的实现是什么，有什么变量，有什么内部逻辑，等梳理清楚了 token 都快干没了。

2018yuli

10 天前

@Ketteiron 哈哈，你这一番其实把 OOP 的优点都夸了一遍——
抽象、依赖关系、拓扑结构、核心行为、接口机制、封装内部逻辑……
这些都是 OOP 引以为傲的地方啊。🤣

不过我也说说它的槽点：

想扩展个行为，动不动就要加类、加继承、加接口，一层套一层。

编译的时候各种引用链、依赖关系、接口跳转都得被解析一遍，
对人和对 AI 都不算友好。

所以 OOP 的确好用，但也确实“啰嗦”——写的时候要啰嗦，读的时候也要啰嗦，
AI 消费 token 的速度更是“嗖嗖地”上去了。

visper

9 天前

上下文爆炸。那哪个语言会好一点？ go ？感觉不错，简介简单。rust?表达能力强，但是符号过多，训练资源不够丰富，感觉有时候 ai 都搞不定编译器。

iyaozhen

9 天前

你说的问题是小项目和大项目的问题。和 java 没关系

现在 AI 在屎上雕花的时候，确实不太好用。从 0 到 1 的项目好很多

yb2313

9 天前

用 spring 再臃肿也不怕, 因为 ai 品鉴得太多, 你拉一坨它一闻就知道哪儿不对.虽然我不写 Java, 但大概是这么个道理吧, ai 会高概率事件压缩成一个公式

8355

9 天前

越是工程化的对 ai 越友好，java 只是 token 量大，对于 ai 来说文本材料和代码训练量以及最佳实践方案都十分充分，相对来说更容易获得正确的结果，只是运行时间比其他语言长。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1172476

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.