前言： 只要你做过 Java 后端，绝对在工作群里经历过这种让人窒息的时刻： DBA 或者运维甩出一截张牙舞爪的慢 SQL：“这 SQL 谁写的？把库跑挂了！” 全组人陷入死寂，你默默打开 IDEA，开始了痛苦的“案发现场排查”。

最近半年，我越来越频繁地使用 Cursor、Claude Code、Codex 这类 AI 工具开发 Java 项目。

有一个现象让我印象特别深。

以前大家讨论 AI 编程，关注的是：

• AI 会不会写代码
• AI 能不能写复杂系统
• AI 会不会取代程序员

但实际使用下来，我发现这些问题正在慢慢失去讨论价值。

因为现在的大模型已经足够强了。

真正的问题开始变成：

AI 当然能做出来，但它要付出多大的代价？

Claude Code 写 Spring Boot、MyBatis、JPA 已经越来越像一个高级开发。

但只要换成公司的内部框架、私有 SDK、自研中间件，它立刻开始一本正经地胡说八道。

最近我在维护自己的 ORM 框架 DLZ-DB 时，就遇到了这个问题。于是我尝试用 Claude Code Skill 给 AI 填了一份”教材”。

结果很有意思：

没有微调模型，没有训练数据，只靠一套 Markdown 文档，Claude 就能稳定写出它从未见过的 DLZ-DB 代码。

我维护了一个自研 ORM 框架 DLZ-DB，核心代码不到 7000 行，跑在公司十几个项目里。问题是：AI 不认识它。于是我做了一套 Claude Code Skill，让 AI 能像用 MyBatis-Plus 一样流畅地写 DLZ-DB 代码。本文分享整个思路和实践。

这不是又一篇"XX 框架最好"的软广。这是一份选型笔记——记录我在不同项目里用过 MyBatis-Plus、Spring Data JPA、JOOQ 之后，为什么最后还是决定自己造了一个 7000 行的 ORM。

文章里所有代码都能跑，所有缺点都不掩饰，包括 DLZ-DB 自己的。

企业微信、飞书、钉钉Webhook接入后代码越写越丑的根源：事件解析和业务逻辑混在同一层。用JSONMap分层处理，Controller只做解析，Service只做业务，代码瞬间清爽。

生产环境慢SQL日志只告诉你哪条SQL慢，不告诉你谁执行的。MyBatis/JPA/JdbcTemplate全缺业务调用栈，DLZ-DB用一行配置自动打印调用方，5分钟定位到代码行。

写了20年Java，受够了MyBatis的4个瞬间：SQL日志定位难、CRUD样板代码多、动态数据源配置死板、JSON字段解析繁琐。DLZ-DB用7000行代码给出轻量级解决方案。

Excel 是扁平的，数据库是多表的。如何让字段位置从代码里消失，变成 Bean 的元数据？用 @SetValue 注解将变更成本从 O(N) 降到 O(1)。

Postel 定律统治软件工程 45 年却没回答宽容应该到哪一步。提出有界宽容原则：对缺失和形式宽容，对内容严格。