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

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

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

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

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

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

真正的问题开始变成：

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

这不是又一篇"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 年却没回答宽容应该到哪一步。提出有界宽容原则：对缺失和形式宽容，对内容严格。

AI 学的是项目不是提示词。如果代码库风格混乱，AI 会随机学习并混用。提出让代码库更 AI 友好的 4 条建议。

AI 生成代码的质量取决于底层 API 的表达密度。对比 Python 和 Java 处理嵌套 JSON 的差异，提出 4 条 API 设计原则。

AI 生成代码的质量取决于底层 API 的表达密度。展示如何用 JSONMap 将 30+ 行判空样板压缩为 1 行链式调用，让 AI 生成的代码更简洁。