说到这个，我想到我让 AI 诊断某个 day 0 legacy 的时候，上来 AI 就给我说「 vite dev tool 可能不干净，HMR 很脆弱，你应该手写」然后折腾了几轮后我感觉不对劲直接中断然后反问他说「不干净」是否能搜到讨论，他推荐的浏览器插件方案是不是在 DOM 上更不干净。然后得出的结论是，整个问题一开始压根不是跟 vite dev tool 相关的。

第二天遇到奇怪的问题，问其他人，别人不知道什么地方出问题了并且回答我「我感觉你代码没问题啊」，然后我遇到一个很奇怪的响应式断掉的问题，并且断掉的方向很巧合的有种镜子的感觉。

然后我直接拿这个逻辑去质疑 AI 了：

这个链条是：

-- 我拒绝 Chrome Devtool
-> 我就要 HMR
-> 我拒绝 Vite 的浏览器插件
-> 我就要自带的 vite dev tool
-> 我拒绝「 vue 在 window 」
-> 我就要把 vue 收回来，所以我暴露了 component+mount/unmount
-> 完美的镜面 bug

每一步，都是在逆着 LLM 被训练的偏好走。

如果从一开始我没有质疑、质疑、顶撞「 vite dev tool 真的是不干净的吗」和否定「浏览器插件」，那也许压根发现不了 bug ，连「这里有什么地方很不对劲」都不知道了。

然后我能分析出的唯一的结论就是大数原理和语料问题还有 LLM 天然倾向于打圆场做老好人而不是直接攻进问题核心区。并且这跟 LLM 倾向于一个 commit 在一行改动的同时引入三行无关参数和两行 trivial 注释是类似的。

不过我也在想，也许有问题的远远不止是 LLM 。

我觉得没有必要，用 GPT/Claude Opus/Gemini 后的感觉是，如果真的要做推理分析或者很专业的话题，触发 AI 进入模式的，不是语言，而是你自己如何组织词句，如何给出清晰的逻辑回路，如何有条理的去反驳他，或者质疑一个观点是否可以被证明或者证伪。

另一点是在一些稍微次高端的 AI 模型比如 Sonnet 上，同样的思路来回十几轮后我会发现 AI 的回答开始变得支离破碎，中文夹英文越来越多直到最后整个回答都是短语片段。但我感觉这个更多是 AI 的问题而不是语言的问题。

如果你能把项目的前因后果、关键决策路线、为什么这个地方要这么写、为什么那个地方要这么设置，项目的技术选择和你要解决的难题之间的关系还有一些项目里面的因果关系说的清楚，说实话，如果是我，哪怕你整个项目是 AI 写的并且到处都是 emoji 我觉得都无所谓。

不然的话，另外一个鉴定项目是否人写的，我会从这么几个角度看：

- git commit 的粒度、git workflow 的控制，是否能看出清晰的思路，还是每次 commit 都是一大坨
- 代码里面的评论、注释是否废话文学，还是记载了一些高密度的信息
- 代码风格，比如变量名是否莫名其妙，是否有莫名其妙没法解释的结构或者模式
- 变更的原子性，比如说是否一次变更只做一件事，还是塞了一大堆乱七八糟的——说起来我跟 AI 聊的时候我会反复跟他强调这件事，并且在他输出一堆无关内容的时候直接反问、质疑

不然的话可能就上动力学分析了。我的印象中，人类写的代码，因为对约束失效、边界条件等真实难点的主动思考，很容易会有复杂度集中存在，产生强耦合/有 causality 和对代码抽象结构的引导和暗示，这些往往会限制或决定未来的项目演化。反过来看，AI 写的代码，至少我觉得经常很...「平」。

如果这段描述有点抽象，那么人类的代码更像在地球上的某个真实地形约束下城市和群落、交通的自然演化和人为规划的结果。而 AI 代码给我的感觉更像 Minecraft 那个 Perlin noise 生成器。

或者，换句话说，看人类的代码，我会好奇：技术债从哪里产生」，看 AI 代码，绝大部分情况下，他甚至连技术债都无从谈起。

协程这么用感觉也太奇怪了（

只能说康威法则永不过时，3#和 4#很好的说明了这一点

AI ？怪不得那么喜欢 OOP 。

有没有一种可能，你说的「 class 继承」这种「高级」功能恰恰就是 OOP 为什么坏的原因。

那个 inc 确实丑，但我不认为这个模式有什么问题，这就是最平凡的 lambda 。「 JS 十几年打磨的 this 和 class 」，我愿意称这是今天看到的最好笑的笑话。

至于「 class 作为 model 载体」，这句话对我来说就是一个危险信号：不再在乎「 model 如何参与渲染循环，而开始把它像业务、intelligence 一样当一个大垃圾堆，像后端人那样把一切看不懂的或者不想理解的东西塞进去」，而这就是 what class supposed to do 。

反过来看这个「没有 this 的坏代码」：

命名明确：count 、inc 一目了然
显示调用：我调用 set/get 的时候我会被迫知道我在干嘛

以及 OOP 不是只有 Jaba ，actor model 也是 OOP 。

如果你的 blog 因为 ai 就被干掉了，也许这个 blog 本身就没太多值得讨论的。

抛开业务、框架、Java 这些问题，equals 和 hashcode 的意义是什么？

我的理解是这是为了构建 equivalence 关系吧。

那么问题是，知道不知道 hashcode 重写，对于 equivalence 的构建和对比，会有影响吗？

HashMap 也好，上游 caller site ，他们做对比的时候会关心 hashcode 是如何使用的，还是说这只是一个契约？

我从这个角度讲会觉得 equals+hashcode 必定是要一起出现的。

编程入门的话，直接拿 lambda 怎么样（

当然 lambda 并不是真的语言，那退而求其次，感觉 OCaml 或者其他 ML 系的语言也许蛮合适。如果是实用向的话，我觉得 Kotlin 挺好吧。

Java 的 WORA 在现在已经没任何优势甚至是个伪命题了吧。首先如果 JVM 这种虚拟机运行能算一次编译处处运行，那现在的跨平台方案基本上都能算一次编译处处运行，甚至 React Native 、Flutter ，更不用说.NET 了。

那如果从编译产物是原生二进制的角度讲，Java 也没啥 cross compile 的能力吧？

而且这种带个虚拟机来一次编译处处运行的代价是啥呢？ Java SDK 屏蔽了操作系统层面的操作，但如果需要调用平台特定的接口怎么办？走 JNI 那套恶心得要死的写法？

@yazinnnn0
@dssxzuxc 我自己写肯定直接选择 Dotty 或者 ML 了，只是看到有人讨论「怎么在 Java 里面引入命名参数」这个帖子，然后产生了一点脑洞而已。而且 @dssxzuxc 说的「屎上雕屎」这点我也很认同，我自己对命名参数这玩意本身也没很感冒。

@chendy
其实你这个想法感觉有点像「依赖注入」或者一个「劣化版本的 Scope 」了吧，我个人倒是感觉其实语法上和 builder 模式算是等价的？

@pricky777 诶这样吗？以前好像没这个印象（

我也收到了这个，刚好是订阅 All Pack 十周年，开心

总感觉这些诈骗要去对付的话技术不是最重要的，可能文化习惯、思维惯性这些更重要也更难去处理。

我感觉对程序员要求反而更高了吧，一个是因为 AI 产出不可控，第二个是 AI 相当于是生产力工具，那很多原先不一定有能力或者资源去做的问题都能解决了，顺理成章就会引入更多的复杂度和未知数，而这些就反过来对程序员有了更高的要求吧。

如果说技术指的是对具体框架或语言的熟悉的话，那编码在程序员日常活动占据的也不过是 30-40%的比例吧。

如果说技术指的不仅仅是编码，更包括项目管理、代码审核、日程安排、架构设计、测试以及构建正反馈循环的话，那这些本身就不是 AI 能替代的。

所以不懂怎么万事都能转进到「技术不值钱，程序员也不值钱」，我寻思程序员的价值也不是体现在写代码上，而是怎么去解决复杂问题和项目里的复杂度。倒不如说，AI 反而是个好事，因为让「解决复杂问题」这个本来可能需要很多年编码才能摸索出来的能力，变得相对更简单了。

vert.x 确实是好东西，但会用这玩意的大概率也会试着逃离 Java 换技术栈了。不会用的，吹再好他们也不会用。

既然都 tiny 了，感觉实现个 javalin 或者 inversify 这种轻量级的框架会更有学习意义吧。spring 之类的重型框架黑魔法太多，反而很多东西感觉蛮 dirty 的。