VIBE CODING 时代，应用开发是否应该使用 ORM ？

一直在用 gorm

最起码 mybatis 这类轻量 orm 是必须用的，因为 AI 已经用得很熟练了

一直用的，ent

当然用啊，可以减少上下文 token 。不然那么多 SQL ，模型也受不了。
熵越少，LLM 处理起来越高效，这点，和人脑一样

二者冲突吗

继续 Raw SQL 。现在有 AI 辅助，Raw SQL 难维护和手写效率低的问题基本被抹平了。配合 sqlc 这种代码生成工具，既能享受原生 SQL 的极致性能和掌控感，又能自动生成强类型的代码，体验非常舒服。

不用 orm 是嫌 token 费用太便宜

orm 强制用吧，不然自己做防注入，校验那些?

为什么不用，手拼 SQL 只有在追求极致效率的时候用。

用啊 大部分场景够了 小部分手写呗

这么说的话，vb 是否有必要用高级语言，直接汇编不是更极致

Go 后端，rawsql 性能更好更好优化特别是对于数据量大的应用。第二，是否使用 ORM 对安全性影响不大，这个是开发人员习惯的问题，我的经验里 codex 没有写过有注入漏洞的查询。第三这个和语言生态有关，Go 开发者一般不喜欢用 Orm ，但写 ruby 的特别喜欢用 active record ，因为是真的好用。

看标题我还以为 outcome reward model 现在程序员都这么深入了吗

AI 说用啥就用啥

我用 ees

@yiplee #6 请问 Raw SQL 是怎么处理数据库迁移的呢？

@bwnjnOEI #13 说明是比较年轻，接触互联网开发比较潜

@Leon6868 github.com/golang-migrate/migrate/

代码是给人看的

不用的话，修改/重构数据库相关的地方，会很痛苦吧。
ORM 能防呆，编译时就能提前发现问题，不用就亏了。
RAW SQL 也是让 ORM 框架用强大的编程语法在编译时生成静态 SQL ，同样享受健壮性。
LLM 确定性太差了，和人一样，工程化手段还是得上。

rawsql 自己按功能稍微封装一下
数据库迁移靠 flyway 这类东西
验证靠单元测试，而且用 testcontainer 这种工具做尽量真实的测试，刚好配合 flyway 。
把业务层拍平到一层，不单独写数据处理层。
这样 AI 直接靠 SQL 判断业务，而不是靠 ORM 的方法名，不需要去推断 ORM 展开的 SQL

https://mkennedy.codes/posts/raw-dc-the-orm-pattern-of-2026/

rawsql + dataclass 也不错

学习和使用 orm 其实收益不是很大，每个语言生态都有 orm ，难道每个都学一遍吗。用 rawsql 可以抹平不同的语言鸿沟，ai 也更好修改。

Vibe Coding 的时代，开发是否应该直接使用汇编语言？

现在 ai 想怎么写就怎么写，只要最终结果是我要的，我已经不太在乎是怎么实现的了。感觉人快废了。

如果对 orm 框架不熟悉或者基于减少程度调用链路的考虑，可以让 ai 封装一个简单的 orm ；

Vibe Coding 的时代，是否应该使用穿孔纸带

第一 能的话尽量不要使用 sql 语法真的很烂 orm 目的是为了减少以上麻烦
第二 不能的话尽量自己写自己的 orm 实现起来并不困难 也少了一堆小坑需要踩 还有 db 栏位与 type 栏位不同名称是烂设计 一致性非常差 虽然我也实现过这样的
第三 rawsql 和 orm 哪个好我觉得除了长 sql 以外差不多 orm 只是再套一层省点拼写错误 拼写参数的麻烦 长 sql 再套层会比较好维护 至于注入倒是还好 毕竟预编译再输入参数是 db 本来就有的功能 与你是否使用 orm 无关 顶多再弄个正则也就完事了

放弃过渡设计的东西不用浪费时间

不用 ORM 的结果就是 AI 帮你写半个类似 ORM 的东西勉强用着。既然勉强用着为什么不直接用成品 ORM 。

要用的吧