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