AI生成480个文件，改一个字段却要改多处

AI 帮你写了 480 个文件，然后你发现加一个字段要改好几个地方

---

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

先来看一个标准的 MyBatis-Plus 项目结构，一张 user 表，常规需要这些文件：

 复制代码UserEntity.ja va       → 实体类
UserDTO.ja va          → 传输对象
UserMapper.ja va       → Mapper 接口
UserMapper.xml        → SQL 映射文件
UserService.ja va      → 业务接口
UserServiceImpl.ja va  → 业务实现

6 个文件，AI 一口气帮你生成，速度确实快。80 张表就是 480 个文件，AI 几分钟就能搞定。

但真正的问题在后面等着你。

产品经理一句“用户表加个 remark 字段”，就能让你忙活好一阵：

 复制代码1. UserEntity.ja va — 加字段 → AI 能帮你改
2. UserDTO.ja va — 加字段 → AI 也能帮你改，但你得告诉它
3. UserMapper.xml — 检查 SQL 是否用到 select *
4. UserServiceImpl.ja va — 检查是否手动拼接了字段

更麻烦的是，同样的改动在其他 79 张表的关联查询里也要走一遍——因为可能有 JOIN user 表的 SQL 散落在各张表的 Mapper.xml 里。

AI 帮你生成代码的时候，你省下了时间。但 AI 不帮你维护代码一致性的时候，你之前省下的时间，全得加倍还回去。

所以，问题的核心不在于“AI 写的代码质量如何”，而在于代码的变更面究竟有多大。一个字段分散在 6 个文件里，你改就得改 6 个文件——不管这 6 个文件是谁写的，AI 还是你自己。

---

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

有人可能会说，“这不能怪 MyBatis 设计不好，用 JPA 会不会好点？” 我们来做个对比：

方案	一个表最少几个文件	加一个字段要检查几处
MyBatis 手动写	4-6 个	Entity + DTO + Mapper.ja va + Mapper.xml + 手工拼接处
MyBatis-Plus 代码生成	4-6 个	Entity + DTO + Mapper + Service（生成器可能漏改）
JPA / Hibernate	2-3 个	Entity + DTO + 自定义 @Query
jOOQ 代码生成	1-2 个	Entity 由数据库驱动，但 DTO 和业务层仍需手动

每个方案里，文件数最少也是 2 个。原因在于，“数据定义”和“数据传输”长期被当作两件独立的事来处理。

但仔细想想，对于一张只做增删改查的表来说，你定义 UserEntity 和 UserDTO 时，90% 的字段其实是重复的。你等于在维护双份信息。

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

文件越多，耦合越分散，AI 就越难帮上忙。因为 AI 不理解“你改 Entity 的时候应该同步改 DTO 吗？”——它不清楚你的项目约定，它只看到当前打开的这个文件。

---

三、如果一张表只有一个文件

现在回到同一个需求，看看如果一张表只对应一个文件会怎样：

 复制代码// UserService.ja va —— 一个表只写这一个类
public class UserService {
    // 查一个
    public User getById(Long id) {
        return DB.Pojo.select(User.class).eq("id", id).queryBean();
    }    // 查列表
    public Page list(String keyword) {
        return DB.Pojo.select(User.class)
                .like("name", keyword)
                .page(1, 20)
                .queryBeanPage();
    }    // 增
    public User add(User user) {
        return DB.Pojo.insert(user);
    }    // 改
    public User modify(Long id, User user) {
        return DB.Pojo.updateById(User.class, id);
    }
}

现在加 remark 字段，流程就变成了：

1. 数据库加一列：ALTER TABLE user ADD COLUMN remark VARCHAR(255);
2. user 表对应的这个类——什么都不用改。

原因很简单：DB.Pojo.select(User.class) 自动从数据库表结构拿到列信息，DB.Pojo.insert(user) 把 JSON 里的 remark 字段自动映射到数据库列。没有 Entity 要改，没有 DTO 要同步，没有 Mapper.xml 要检查。

变更面从 6 个文件压缩到 1 个文件。当 AI 在这个基础上来帮你改代码时，错误率就会从“大概率漏改”直接降到“基本不出错”。

---

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

操作	MyBatis-Plus	JPA	此方案
加一个字段	Entity + DTO + Mapper.xml + ServiceImpl + 前端DTO ≈ 5 处	Entity + DTO + @Query检查 ≈ 3 处	数据库 1 处（框架自动映射）
改字段类型	同上 5 处	同上 3 处	数据库 1 处
加一个查询条件	Mapper.ja va + Mapper.xml + ServiceImpl ≈ 3 处	Repository + Service ≈ 2 处	改 Service 的方法参数即可
新增一张表	生成 4-6 个文件	生成 2-3 个文件	1 个文件

这里比的不是“谁的代码写得更短”，而是“加一个字段，要改几个地方”。因为工作中，不是每天都需要加新表，但可能每天都在被产品经理要求加字段。

---

五、为什么文件少会让 AI 的准确率翻倍

这其实很容易理解，不是什么复杂的推测。

当你让 AI 改一个字段时，它需要同时理解 Entity、DTO、Mapper.xml、ServiceImpl 这四个文件的上下文。上下文越长，AI 的注意力越分散，漏改的概率就越高。

而当你只有一个 UserService.ja va 时，上下文是高度内聚的。AI 在这个文件里改代码，它不需要跨文件猜测影响范围。

少文件 = 少上下文 = 少出错。这已经不只是代码风格问题了，这是 AI 辅助编程时代里一个实实在在的工程成本问题。

换句话说：你项目的文件结构，正在直接决定 AI 帮你写代码的质量上限。

---

六、AI 生成 480 个文件 vs AI 用此方案管理 80 个文件

做一个最终的对比：

 复制代码项目规模：80 张表的业务系统
MyBatis-Plus + AI：
  生成 480 个文件（80表 × 6文件）
  加一个字段平均改 5 个文件
  AI 漏改概率：你每次都要人工检查 4-5 个文件
此方案：
  维护 80 个 Service 文件（80表 × 1文件）
  加一个字段：数据库 1 处
  AI 漏改概率：一个文件前后一读就看清了

这里的关键差距不是 480 个文件和 80 个文件代码量的区别。而是变更时你需要排查 5 个文件还是 1 个文件的区别。而这个差距在 AI 写代码的时代被放大了——文件越多，AI 越容易漏改，你越需要花时间去人工做校验。

---

七、什么时候这样不行

当然，这个方案并不是万能的。

它的边界很清楚：

• 标准 CRUD 表：80% 以上的业务表只做增删改查，单文件方案最合适

• 单表查询为主：按 ID 查、按条件查、分页查，这类需求很常见

• 字段和数据库列一一对应：不需要复杂的映射转换，这种场景下效率最高

• 复杂多表关联 + 聚合查询：该写 SQL 还是要写，该建专门的查询 Service 也必须建

• 需要和第三方 API 做字段转换：DTO 层的存在依然有意义，不能为了省文件而硬省

• 对缓存、事务有复杂编排的业务：单文件只负责数据访问，业务编排逻辑另起一个 Service 来处理

这里的“单文件”省的是重复定义，而不是业务编排。你仍然可以有 OrderBizService 来编排订单流转逻辑——它不需要再对应一个 OrderMapper.ja va + OrderMapper.xml。

---

八、如果只记一句话

下次你用 AI 写 CRUD 的时候，别只盯着它生成代码有多快。数一数它一口气生成了几个文件。文件数就是你下一次产品改需求时，需要人工排查的范围。