AI 帮你写了 个文件，接下来你发现加一个字段要改好几个地方

一、AI 写 CRUD 最大的坑：它只管生。不管养

先给你看一个标准 MyBatis‑Plus 项目的表结构。怎么说呢，一张 user 表。常规需要这些文件：

UserEntity.java → 实体类
UserDTO.java → 传输对象
UserMapper.java → Mapper 接口
UserMapper.xml → SQL 映射文件
UserService.java → 业务接口
UserServiceImpl.java → 业务实现

共6个文件。AI 帮你一次性生成，很快。80 张表就是 480 个文件——AI 也不慢，几分钟搞定。

问题出在后面。不过，

至于产品说。「使用者表加一个 remark 字段。」于是你要做下面这件事：

• UserEntity.java — 加字段
• UserDTO.java — 加字段
• UserMapper.xml — 检查 SQL 是否用了 *
• UserServiceImpl.java — 检查是否手动拼接了字段

接下来一样的检查，还要在其他 张表的关联查询里再做一次——因为可能有 JOIN user 表的 SQL 散落在各张表的 Mapper.xml 里。不过，

AI 帮你生成代码的时候。你省了时间，但 AI 不帮你维护代码一致性的时候，你花的时间全还回去了。

主要矛盾不在「AI 写的代码好不好」，而在代码变更面的大小. 一个字段散落在 个文件里你得改 个文件——不管这 个文件是谁写的。

二、不是 MyBatis 的锅。是「文件数」本身就是变更成本

有人会说这是 MyBatis 的设计问题，用 JPA 就没有这事儿。来看下不同方案下最少需要多少文件还有加字段时要检查多少处：

jOOQ code generation

方案	一个表最少几个文件	加一个字段要检查几处
MyBatis 手动写	6	≥6
MyBatis‑Plus 代码生成器	5	≈5–7
JPA / Hibernate	3	≈3–4	4	≈4

每一种方案，底层都少不了「数据定义」和「数据传输」两套结构。不过，

If you only need CRUD for a table。you’ll notice that fields in your Entity and DTO are almost identical – you’re maintaining duplicate information.

变更成本 = 文件数 × 耦合度。其实，

The more files you have,more scattered coupling becomes。and less AI can help because it doesn’t understand your project conventions across multiple files.

三、如果一张表只有一个文件？其实，

The simplest case is to collapse everything into a single service class that directly operates on POJO:

// UserService.java —— 一个表只写这一个类
public class UserService {
// 查单条
public User getById {
return DB.Pojo.select.eq.queryBean;}
// 查列表
public Page list {
return DB.Pojo.select
.like
.page
.queryBeanPage;}
// 增
public User add {
return DB.Pojo.insert;其实，}
// 改
public User modify {
return DB.Pojo.updateById;}
}

Add new column:

1. 再看数据库执行，alert table user add column remark varchar; )
2. The Java class stays unchanged—no Entity,no DTO。no XML to touch.

The framework reads table metadata at runtime ) and automatically maps any extra JSON fields to new column. No manual synchronization required.

变更面从 6 个 文件压缩到 1 个 文件。在此基础上让 AI 帮忙修改时错误率从「大概率漏改」降到「基本不出错」。

四、压力测试：同一需求，不同方案要改几个地方？

操作 / 框架	MyBatis‑Plus	JPA / Hibernate	单服务方案
新增字段（entity/DTO/mapper/xml/serviceimpl…)	≈6–8	≈4	1
修改查询条件 ，/ ， ，

...

​​​​

​​

当你要求 AI 同时更新 Entity、DTO、Mapper.xml 与 ServiceImpl 四份文档时它必须在一次对话中保持对四份内容完整且一致的记忆——上下文越长。注意力越容易分散，漏掉任意一处都可能导致运行错误。

而如果所有逻辑集中在唯一的 UserService 文件中，上下文高度内聚；AI 在该单一文档中完成修改，无需跨文件推断影响范围。

少文档 = 少上下文 = 少出错。这不是风格问题，而是 AI 辅助编程时代的新工程学命题。

换个角度你项目中的 目录结构 正直接决定了 AI 能为你把关质量的上限。

对比维度 / 场景

MyBatis‑Plus + AI • 每张表 ≈6 文件 • 总计 ≈480 文件 • 加字段平均需修改 ≈8–10 文件 • 漏改概率高，需要人工逐一核对

单服务方案 • 每张表 ≈1 文件 • 总计 ≈80 文件 • 加字段仅需 DB 脚本 • 漏改概率极低。只需阅读单一 Service 即可

​

• ✅ 标准 CRUD 表：

• ✅ 单表查询为主：

• ✅ 字段与数据库列一一对应：

• ❌ 复杂多表关联 + 聚合查询：

• ❌ 第三方 API 字段转换：

• ❌ 缓存/事务编排复杂：

\ 以上边界帮助你判断何时可以采用「单服务」模式；而不是把所有业务都强行压进同一类。

八、如果只能记一句话…​​

​ 下次使用 AI 自动化 CRUD 时请先数一下它到底产生了多少 *源* 文件——这个数字直接决定了后续需求迭代时你的排查成本。💬 你的项目里用 AI 写 CRUD 时加一个字段通常要修改几处？有没有遇到过因为 AI 漏掉 Mapper.xml 导致线上报错的经历？欢迎在评论区聊聊，让更多人少踩坑！

---

 文中提到的一些实用工具 

• 项目名的观点是，dlz-db 
• Maven 坐标：/top.dlzio:dlz-db/ 
• GitHub 地址： 
• Gitee 镜像： 

---