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

[2018yuli]

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

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

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

[xtreme1]

对 ai 不友好还是对钱包不友好
什么代码结构易于 llm "理解"
Java 的 orm 问题

这是几个独立的问题

[2018yuli]

👍

[wysnxzm]

说的多不一定说的明白,说的少一定说不明白(谜语人)

[usal2271988404]

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

[1daydayde]

你知道 AI 是训练出来的吗？它就是在这个复杂的环境下生长的，你还担心它吃不习惯？

[2018yuli]

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

[penisulaS]

ai 可是喜欢冗余的，冗余信息越多，越不容易出错。当然也越贵

[ZeroDu]

是的，对 AI 不友好，一层层嵌套，再加上公司的各种私有封装，简直让 AI 懵逼

[rb6221]

你可以发明一个新概念，AI Native Framework 。

[2018yuli]

做为中级 Javaer ，还从来没自己写过完整框架。/_ \

[johnnyyeen]

java 不是大，是肿

[Ketteiron]

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

[2018yuli]

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

不过我也说说它的槽点：

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

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

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

[visper]

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

[iyaozhen]

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

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

[yb2313]

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

[8355]

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