@bitmin 哈哈哈，笑死我了。非常在理！

基本使用，第二种。

只有在新项目使用第一种。感觉生成的代码有冗余、太多了 无法掌握。review 的时候，会指导 AI 做一些 clean up 。我的经验是，要用第一种，一定要控制生成的代码量。逐步 review ，review 完了 才能进行下一步。而且累积几步后，要及时的进行 clean up 指导。

@minami 当然不是我期待着。 但是技术演进，是不以人的意志为转移的。假定真的出现这种技术，我们也拦不住。

@minami 执着于大一统的原因在于现在的 app 开发成本高了。适配不动了。

一直值得深思的话题 。

我妄言，这其中有各平台圈地垄断的原因，也有 web 表现力、性能不足的原因。

@irisdev 有各种背调机构啊。。。

楼上说的 OD 骗人能转正确实很狗。

但是仅从内容上看，这是很正常的。不接受也没办法，这是现实。

从公司角度来讲，要管理人事风险。人员变动大，还怎么做事情。

对于公司来讲计划之外的离职，会影响项目。你说这个作者在“批评”这些主动离职的人吧？似乎也没有。只是就事论事的站在其利益角度讲要如何规避。开公司的人要规避风险，你总不能拦着人家吧？

对于文中提到，计划之内的离职，也就是所谓“主动管理”式的辞退。那些例子，我感觉没有什么不妥的。

我前天还跟同学调侃，这玩意用不错，但是当“传家宝”肯定是不行。

我们各自都买了很多小米的产品，感受就是：小米是入门好选择，但是质量跟稳定性一般般。

什么？ kaniko 这玩意归档了啊？

https://github.com/GoogleContainerTools/kaniko/issues/3348#issuecomment-2935160773

> This was never an official Google product. This is dead, time to move to buildkit or buildah.

坐等一个替代品建议。求有用过大佬分享一下替代品的使用体验。

怎么的？来个 Leader 就要换语言、换框架、换代码风格？

理解不来这种技术 leader 。纯纯的招聘事故。

楼上还有喷 Java 的。人家公司招聘你去做技术 leader ，是让你创造价值，而不是给你刷简历用的。“系统是 Java 写的”，这是一个客观已存在的事实。不了解情况，就先批判这样写不好，那样写麻烦。这是典型的 “没调查就发言”。

PDD 还是可以的。小程序竟然也能联系客服，整个下单都是闭环的。我用小程序下单了。

话说，可以直接➕v 购买吗？没安装 PDD 。

顶一顶，同样是产茶区的娃。

下单两样试喝支持下～

@seers 很精辟了。我总觉得原因就是 OP 说的 第二点，这就是个伪需求。

k8s 所描述的层面偏“底层”了一点，真要用不太可能是 “让开发者无需关心 K8s 底层”。与其学习你们用 UI 封装后的平台工具，为什么不直接学习 k8s ？

@Romic 想法本身就有问题。 不要以为有“好心”，就觉得做什么事情都是能成功的、是神圣正确的。

@zieglar 那是不是 prisma query 出来的数据，再装载到自己实现的实体 class 上？

也尝试使用 prisma ，说说我觉得的痛点与疑惑，希望有经验的解答下：

1. prisma 不生成 class ，如何进一步跟 class-validator 以及 swagger 结合？
2. 不生成 class ，如果我有很简单的 computed field ，就不知道怎么实现。虽然官方有 [Client extension]( https://www.prisma.io/docs/orm/prisma-client/queries/computed-fields#using-a-prisma-client-extension) 方案，但是 extend 后的 model 类型获取不直接。虽然可以通过类型体操获取。
3. 个人对滥用 DSL 很反感。DB 的 schema 真的到了需要叠一层 DSL 的程度了吗？ 我个人认为还没必要，这样做的收益不高。为了“无缝”切换 DB 类型吗？正常项目开发不会频繁切换 DB 类型，况且也无法做到无缝。 想要降低使用 DB 的门槛吗？熟悉一个 DB 真的是后端的基础门槛，你虽然可以暂时欠着，但是终究要还上，借助 DSL 会很被动，学的都是人家嚼碎了喂你的东西。prisma 用 DSL 描述 schema 的理由，我能想到的唯一理由应该就是他们的野心是实现一个跨语言的 ORM 。