群里又在问“这条慢SQL是谁写的”?教你一招,日志直达代码行
前言: 只要你做过 Java 后端,绝对在工作群里经历过这种让人窒息的时刻: DBA 或者运维甩出一截张牙舞爪的慢 SQL:“这 SQL 谁写的?把库跑挂了!” 全组人陷入死寂,你默默打开 IDEA,开始了痛苦的“案发现场排查”。
前言: 只要你做过 Java 后端,绝对在工作群里经历过这种让人窒息的时刻: DBA 或者运维甩出一截张牙舞爪的慢 SQL:“这 SQL 谁写的?把库跑挂了!” 全组人陷入死寂,你默默打开 IDEA,开始了痛苦的“案发现场排查”。
最近半年,我越来越频繁地使用 Cursor、Claude Code、Codex 这类 AI 工具开发 Java 项目。
有一个现象让我印象特别深。
以前大家讨论 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 自己的。
生产环境慢SQL日志只告诉你哪条SQL慢,不告诉你谁执行的。MyBatis/JPA/JdbcTemplate全缺业务调用栈,DLZ-DB用一行配置自动打印调用方,5分钟定位到代码行。