AI 帮你写了 480 个文件接着你发现加一个字段要改好几处

作者：袖梨 2026-06-27

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

一、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 字段。」

你做下面这件事：

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

然后同样的事，在其他 79 张表的关联查询里再做一遍——因为可能有 JOIN user 表的 SQL 散落在各张表的 Mapper.xml 里。

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

核心矛盾不在「AI 写的代码好不好」，在代码的变更面有多大。 一个字段散落在 6 个文件里，你改就要改 6 个文件——不管这 6 个文件是谁写的。

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

有人会说这是 MyBatis 的设计问题，用 JPA 就没这事。来看：

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

每一个方案，文件数至少是 2 个。因为「数据定义」和「数据传输」长期被当成两件事。

但仔细想想：对一张只做 CRUD 的表来说，你定义 UserEntity 和 UserDTO，它们 90% 的字段是一样的。你在维护双份信息。

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

文件越多，耦合越散，AI 越帮不上忙。因为 AI 不理解「你改 Entity 的时候应该同步改 DTO 吗？」——它不知道你的项目约定，它只知道当前打开的文件。

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

回到同一个需求。一张表只需要一个类：

 复制代码// UserService.java —— 一个表只写这一个类
public class UserService {
    // 查一个
    public User getById(Long id) {
        return DB.Pojo.select(User.class).eq("id", id).queryBean();
    }    // 查列表
    public Page<User> 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 字段：

数据库加一列：ALTER TABLE user ADD COLUMN remark VARCHAR(255);
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.java + Mapper.xml + ServiceImpl ≈ 3 处	Repository + Service ≈ 2 处	改 Service 的方法参数即可
新增一张表	生成 4-6 个文件	生成 2-3 个文件	1 个文件

不是在比「谁的代码写得更短」。在比**「加一个字段，要改几个地方」**。因为你不是每天都在加新表，但你可能每天都在被产品要求加字段。

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

这不是推测。有一个简单的解释：

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

而当你只有一个 UserService.java，上下文是高度内聚的。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 越容易漏改，你越需要花时间人工校验。