别让旧时代的 ORM 拖累你的 AI 编程助手

太长不读：代码助手越来越懂你，但在写数据库操作时却总翻车。不是 AI 变笨了，是 Hibernate 的 N+1 陷阱和 MyBatis 的 XML 强耦合，让 AI 很难在一次上下文中写出零副作用的安全代码。在这篇《Jimmer in Action》前传里，我们聊聊为什么 AI 编程时代，你需要一个像 Jimmer 这样强类型的现代 ORM。

如果说这两年有什么最让我爽快的事，那就是把脏活累活丢给 AI“实习生”去干；而最让我破防的，是发现这“实习生”连个简单的联表查询都能埋几个雷。

前几天，我正惬意地喝着咖啡，敲着键盘给我的 AI 编码助手下发指令：“给我实现一个商品详情查询接口，带上关联的评价列表和用户信息。”

不到十秒，代码哗啦啦生成完毕。流畅，优雅。

“跑起来试试。”我说。

一秒后，控制台的 SQL 打印如瀑布般倾泻而下。

我咖啡差点喷出来。经典的 N+1 问题。

AI 敲码千万行，XML 里泪两行。要想不背 N+1，ORM 选对才吉祥。

这已经不是第一次了。每当我满心欢喜地以为可以提早收工时，不是被 Hibernate （或者 JPA）那隐晦的状态管理和生命周期刺杀，就是在浩瀚的 MyBatis XML 映射文件里，寻找 AI 拼错的那一个字母。

画面太美。如果你平时极其享受在 XML 里面写 <if test="name != null">，或者对 JPA 的 @OneToMany 各种抓取策略倒背如流，那么现在点左上角退出还来得及，这篇文对你来说大概率是一记暴击。

旧方案：给 AI 埋的“坑”¶

在没有 AI 的时代，我们靠堆人力、靠开发者的肌肉记忆去规避 ORM 的各种陷阱。Hibernate 就像一辆手动挡跑车，开得好能上天，开不好一脚离合就熄火（比如臭名昭著的 Lazy Initialization Exception）；MyBatis 则像一套精密的乐高，灵活是真灵活，但你得自己一块块拼。

现在时代变了。

当我们把代码生成权交给 AI 时，这些框架的短板被无限放大了。

用 Cynefin 框架来看，业务代码大多处于繁杂（Complicated）域，需要专家知识。AI 是个好专家，但它的上下文短时记忆有限。

Hibernate 的黑盒危机：它高度依赖“隐式”操作（脏检查、延迟加载、Session 范围）。AI 一次性吐出一堆代码，它很难判断当前对象脱管（Detached）了没有。遇到嵌套查询，AI 很容易写出看似无懈可击、跑起来引发海量 Query 的漂亮废话。
MyBatis 的视线割裂：Java 是一层，XML 又是另一层。你给 AI 喂上下文，得同时把这两部分喂给它。稍微错位一点，编译不报错，运行时直接抛 BindingException。你还得反过去写一段冗长的 Prompt 纠正它。

根本矛盾在于：旧时代的 ORM 都在通过各种“魔法”（动态代理、反射、XML 解析）在运行时解决问题，而 AI 编程需要的是在敲代码（生成期）和编译期就能验证正误的强类型约束。

这就好比老张手写了一堆动态类型的 JS，扔给 AI 改；而我用 TypeScript，接口定义摆在那里，AI 哪怕闭着眼睛生成，只要tsc不报错，基本就稳了。

新方案：类型安全，拯救 AI 实习生¶

在被各种折磨后，我换上了 Jimmer。

它也是一个 ORM 框架，但它的核心哲学完全不同。看看它是怎么写查询的：

List<User> users = sqlClient
    .createQuery(UserTable.class)
    .where(UserTable::name).eq("Zhang San")
    .and(UserTable::age).gt(18)
    .select(UserTable::all)
    .execute();

发现了吗？完全类型安全（Type-Safe Query Builder）。

对 AI 来说，这简直是瞌睡送枕头。AI 天然能理解类和方法，只要把实体定义清楚，由于 Java 的类型约束，AI 根本不可能把 UserTable::name 写成一个不存在的字段。

更绝的是它的对象抓取器（Fetcher）：

List<Book> books = sqlClient.createQuery(BookTable.class)
    .select(
        BookTable.class,
        BookFetcher.$
            .allScalarFields()
            .store(StoreFetcher.$.name())
            .authors(AuthorFetcher.$.firstName().lastName())
    )
    .execute();

想要什么关联数据，就像点菜一样在强类型接口上声明。没有 OpenSessionInView，没有延迟加载报错。你查出什么形状，返回就是什么形状。并且，Jimmer 会在底层自动将这堆复杂需求优化成最优的 SQL 发送给数据库，彻底告别 N+1 问题。

把这个工具交给你的 AI 助手，它生成的代码不仅稳如老狗，而且性能有托底。就算你想搞出 N+1 查询，Jimmer 也会想方设法拦住你。

Jimmer 并不是要打压谁（毕竟 Hibernate 依然是复杂域模型之王，MyBatis 依然是遗留系统的救星），但在如今“意图即代码”、让 AI 干脏活的技术出海或全栈迭代场景下，我们需要一种对 AI 工具更加友好的基座。

这能省去你无数个排查 SQL 性能问题的深夜。

把能力变成交付¶

看到大家在各种群里吐槽“AI 写后端数据层就是个玩具”时，我实在忍不住想喊一句：换个工具吧！

为了不让大家停留在“光听我在这吹牛”的阶段，我把这段时间用 Jimmer 重构几个实际业务的踩坑经验，以及如何用它进行前后端极速开发的完整流程，全部整理成了一本手册。

📚 没错，我弄了个《Jimmer In Action》。

它不是干巴巴的官方文档翻译，而是带着实战温度的落地指南。不管你是为了技术出海做全栈，还是想让你的 AI 助手发挥 120% 的威力，都能从中找到答案。

👉 点击这里直达：Jimmer in Action

（在线开源，欢迎白嫖，如果觉得有用，顺手在 GitHub 点个 Star 就是对我最大的鼓励。）

技术的世界就是这样，新工具总会伴随着新的开发范式而来。

你以为选对了 ORM 故事就结束了吗？

下期，我们聊聊在强类型体系下，如何让前端也能享受到这张红利网……待って，我是不是剧透太多了？