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

[Leon6868]

我认为 ORM 是有存在价值的，原因如下：

• ORM 提供了标准的数据库迁移脚手架
• 能在一定程度上规避 SQL 注入攻击（不知道现在大模型写的代码是否容易出现这些漏洞）
• 提供标准的数据库操作方法
• 能通过 LSP 将数据库操作纳入大模型调试闭环
• 高性能的操作也可以手写 SQL ，有一定的灵活性

大家在开发中是否用 ORM 呢？用的都是哪些 ORM ？

[xiuming]

一直在用 gorm

[yidinghe]

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

[rubi]

一直用的，ent

[xiaomushen]

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

[mach4101]

二者冲突吗

[yiplee]

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

[kakki]

不用 orm 是嫌 token 费用太便宜

[cc9910]

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

[lujiaosama]

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

[kulove]

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

[alamaya]

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

[nc]

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

[bwnjnOEI]

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

[vz685]

AI 说用啥就用啥

[hashtome]

我用 ees

[Leon6868]

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

[Leon6868]

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

[nc]

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

[git00ll]

代码是给人看的

[IvanLi127]

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

[cheng6563]

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

[UB]

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

rawsql + dataclass 也不错

[Lockroach]

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

[iDelicious]

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

[spike0100]

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

[fj24911]

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

[chendy]

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

[james122333]

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

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

[msg7086]

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