可能是 Java 得项目都比较大，感觉现在其他语言得小项目 AI 能接近 100% 的完成。但是打开一个 Java 的 cloud 项目，看到那无数并列的 controller. AI 都能扫到 token 耗尽。然后，实际上，他真的有很多功能么？很多业务么？
我在想，为了 AI 阅读方便，我们是不是应该将所有 crud 都纳到框架层，或者是放到独立的包。业务层只有存逻辑。提升信息密度。这样才对 AI 友好，各位觉得呢，Java 是不是需要这样子的框架。
我个人最近好久没做 Java 了，不喜轻喷。
 |
1
xtreme1 Nov 13, 2025  3
对 ai 不友好还是对钱包不友好
什么代码结构易于 llm "理解" Java 的 orm 问题 这是几个独立的问题 |
 |
2
2018yuli OP 👍
|
 |
3
wysnxzm Nov 13, 2025
说的多不一定说的明白,说的少一定说不明白(谜语人)
|
 |
4
triplephon Nov 13, 2025
倒反天罡了，代码最后还是给人看的，用 ai 也是为了给人省事，这样 ai 是省 token 了，增加了开发者 review 的精力成本
|
 |
5
1daydayde Nov 13, 2025
你知道 AI 是训练出来的吗？它就是在这个复杂的环境下生长的，你还担心它吃不习惯？
|
|
6
2018yuli OP @usal2271988404 有道理。但是现实是，我想表达的意思是：人能把规整的积木搭成迷宫，也能把无形的沙子做成沙画。我觉得少更好。
|
 |
7
penisulaS Nov 13, 2025
ai 可是喜欢冗余的，冗余信息越多，越不容易出错。当然也越贵
|
 |
8
ZeroDu Nov 13, 2025
是的，对 AI 不友好，一层层嵌套，再加上公司的各种私有封装，简直让 AI 懵逼
|
 |
9
rb6221 Nov 13, 2025
你可以发明一个新概念，AI Native Framework 。
|
|
10
2018yuli OP 做为中级 Javaer ，还从来没自己写过完整框架。/_ \
|
 |
11
johnnyyeen Nov 13, 2025
java 不是大，是肿
|
 |
12
Ketteiron Nov 13, 2025
对 token 消耗确实很不友好
经典的 oop 就是这样的，浪费至少一半代码用于封装面向过程的核心函数。 创建一个对象、互相依赖，仅仅是为了执行必要的几个函数，而 AI 不得不先理解对象是如何抽象的，顺着依赖拓扑结构深入检查接口的实现是什么，有什么变量，有什么内部逻辑，等梳理清楚了 token 都快干没了。 |
|
13
2018yuli OP @Ketteiron 哈哈，你这一番其实把 OOP 的优点都夸了一遍——
抽象、依赖关系、拓扑结构、核心行为、接口机制、封装内部逻辑…… 这些都是 OOP 引以为傲的地方啊。🤣 不过我也说说它的槽点： 想扩展个行为，动不动就要加类、加继承、加接口，一层套一层。 编译的时候各种引用链、依赖关系、接口跳转都得被解析一遍， 对人和对 AI 都不算友好。 所以 OOP 的确好用，但也确实“啰嗦”——写的时候要啰嗦，读的时候也要啰嗦， AI 消费 token 的速度更是“嗖嗖地”上去了。 |
 |
14
visper Nov 13, 2025
上下文爆炸。那哪个语言会好一点？ go ？感觉不错，简介简单。rust?表达能力强，但是符号过多，训练资源不够丰富，感觉有时候 ai 都搞不定编译器。
|
 |
15
iyaozhen Nov 13, 2025
你说的问题是小项目和大项目的问题。和 java 没关系
现在 AI 在屎上雕花的时候，确实不太好用。从 0 到 1 的项目好很多 |
 |
16
user1284 Nov 13, 2025
用 spring 再臃肿也不怕, 因为 ai 品鉴得太多, 你拉一坨它一闻就知道哪儿不对.虽然我不写 Java, 但大概是这么个道理吧, ai 会高概率事件压缩成一个公式
|
 |
17
8355 Nov 13, 2025
越是工程化的对 ai 越友好，java 只是 token 量大，对于 ai 来说文本材料和代码训练量以及最佳实践方案都十分充分，相对来说更容易获得正确的结果，只是运行时间比其他语言长。
|
Select Language