用 TRAE Work CN 生成后端表结构，我把 30 分钟的活压缩到了 5 分钟

用 TRAE Work CN 生成后端表结构，我把 30 分钟的活压缩到了 5 分钟

手写建表 SQL、对着规范文档逐条检查、再手动写一遍 Java 实体类……这些重复劳动，AI 5 分钟就能搞定。关键是——怎么让 AI 生成的东西能直接用，而不是生成一堆"看着像那么回事、实际一跑就报错"的半成品。

---

一、为什么我要把建表这件事交给 AI？

说实话，刚接触 AI 编程工具的时候，我也试过直接丢一句"帮我生成订单表"给 AI，结果生成的东西字段类型随意、缺注释、索引乱命名，根本没法直接上生产。

后来我换了一个思路：不是让 AI 替我思考，而是让 AI 替我执行。我把业务建模、规范把控这些核心判断留在自己手里，把重复性的 SQL 编写、实体类生成、注释补全这些模板化工作交给 TRAE Work CN。

效果怎么样？直接看数据：

指标	手写方式	使用 TRAE Work CN
初始 DDL + 实体产出	~30 分钟	5 分钟（含 Prompt 编写）
规范符合度检查	靠人工评审	AI 前置约束 + 自动审查
索引遗漏率	约 10%	< 2%（Prompt 明确要求）
新人上手成本	需熟悉规范文档	Prompt 模板直接内嵌规范

下面我把整套方法论拆开讲，从 Prompt 怎么写，到代码怎么落地，到踩过的坑怎么解决，全部交底。

---

二、整体流程：4 步走完，从需求到生产级代码

看着简单，但每一步都有讲究。下面逐步拆解。

---

三、第 1 步：结构化需求输入（Prompt 是灵魂）

这是整套流程最关键的一步。Prompt 写得好不好，直接决定 AI 输出的质量。

我的原则是：把 AI 当成一个刚入职的资深开发——能力很强，但不知道你们团队的规矩。 所以你要做的不是教它写代码，而是告诉它你们团队的"铁律"。

我的标准 Prompt 模板

你是一个资深 Java 后端架构师。请根据以下业务需求，生成 MySQL 8.0 的 DDL，
并对应给出 Java 实体类（使用 Lombok，遵循阿里 Java 开发手册）。

业务需求：
- 实体：订单主表 t_orders、订单明细表 t_order_item、支付记录表 t_order_pay
- 关系：t_orders 1:N t_order_item，t_orders 1:1 t_order_pay
- 字符集 utf8mb4，引擎 InnoDB，表名 t_ 前缀，字段下划线命名

强制规则：
- 所有字段必须加 COMMENT
- 主键用 BIGINT 自增
- 每张表必须包含 create_time / update_time / deleted（逻辑删除）字段
- 金额字段统一 DECIMAL(12,2)

索引要求：
- 订单号建唯一索引
- 用户 ID 建普通索引
- 状态 + 创建时间建联合索引（用于列表页查询）

请同时输出 MyBatis-Plus 和 Spring Data JPA 两种实体类版本。

看到没？我把命名规范、字段约束、索引策略、技术栈选型全部写死了。AI 在这个框架里生成，就不会跑偏。

Prompt 编写的 3 个核心技巧

1. 角色设定：开头直接定义"资深 Java 后端架构师"，让 AI 进入专业模式
2. 约束前置：把团队规范写成"强制规则"，比事后修改效率高 10 倍
3. 场景驱动索引：不是笼统说"加索引"，而是告诉 AI 查询场景，让它自己推导索引设计

---

整理了面试真题、每日技术知识点、系统学习路线，都汇总在个人网站 [www.javadashen.com] 有需要的同学自取。

公众号「Rain的Java大神之路」每天拆一个知识点，陪你悄悄变强，有空来坐坐。

---

四、第 2 步：AI 架构拆解与初稿生成

用 TRAE 的 SOLO 模式发起任务后，AI 会自动拆解需求，先输出 ER 关系图做架构校验，再生成完整的建表 SQL 初稿，同时同步生成 Java 实体类。

一站式完成表结构 → 代码的映射，这步基本不需要人工干预，重点看生成的 ER 关系是否合理。

---

五、第 3 步：人工校验（3 个维度必须过）

AI 生成的东西不能直接用，人工校验这步不能省。我重点看 3 个维度：

维度 1：实体关系是否正确

• 一对多、多对多的关联关系有没有搞反
• 多对多场景是否遗漏了中间表
• 外键关联字段类型是否一致

维度 2：字段规范是否达标

• 字段类型、长度是否符合生产要求（比如金额必须是 DECIMAL，不能用 FLOAT）
• 命名风格是否统一（下划线 vs 驼峰，数据库和 Java 侧要对应）
• 注释是否完整且有意义（不是敷衍的"字段1"）

维度 3：索引设计是否合理

• 是否匹配真实查询场景（不是越多越好）
• 有没有冗余索引或重复索引
• 联合索引的字段顺序是否符合最左前缀原则

---

六、第 4 步：细节补全与 CI 集成

校验通过后，还需要补全一些生产级细节，然后把代码安全地纳入版本管理。

补全清单

• 乐观锁 version 字段（并发更新场景必备）
• 创建人 / 更新人审计字段（按团队规范选加）
• 分库分表预留字段（如果业务有扩展预期）

Flyway 迁移脚本集成

AI 生成的 DDL 不要直接跑线上库。我的做法是让它生成 Flyway 格式的迁移脚本：

db/migration/
  └── V1.0.0__create_order_tables.sql

人工审核后放入项目，走 CI 的 SQL 审查流水线（我们集成了 SQL Advisor 检测隐患），全部通过才进入版本库。既高效，又安全。

---

七、核心代码展示（可直接复用）

7.1 生产级建表 SQL

-- 订单主表
CREATE TABLE `t_orders` (
    `id`           BIGINT        NOT NULL AUTO_INCREMENT COMMENT '主键ID',
    `order_no`     VARCHAR(32)   NOT NULL COMMENT '订单号',
    `user_id`      BIGINT        NOT NULL COMMENT '用户ID',
    `total_amount` DECIMAL(12,2) NOT NULL COMMENT '订单总金额',
    `status`       TINYINT       NOT NULL DEFAULT 1 COMMENT '状态：1-待支付 2-已支付 3-已发货 4-已完成 5-已取消',
    `version`      INT           NOT NULL DEFAULT 0 COMMENT '乐观锁版本号',
    `deleted`      TINYINT       NOT NULL DEFAULT 0 COMMENT '逻辑删除：0-未删除 1-已删除',
    `create_time`  DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `update_time`  DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_order_no` (`order_no`),
    KEY `idx_user_id` (`user_id`),
    KEY `idx_status_create_time` (`status`, `create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='订单主表';

-- 订单明细表
CREATE TABLE `t_order_item` (
    `id`           BIGINT        NOT NULL AUTO_INCREMENT COMMENT '主键ID',
    `order_id`     BIGINT        NOT NULL COMMENT '订单ID',
    `goods_id`     BIGINT        NOT NULL COMMENT '商品ID',
    `goods_price`  DECIMAL(12,2) NOT NULL COMMENT '商品单价',
    `goods_count`  INT           NOT NULL COMMENT '商品数量',
    `deleted`      TINYINT       NOT NULL DEFAULT 0 COMMENT '逻辑删除：0-未删除 1-已删除',
    `create_time`  DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    `update_time`  DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    PRIMARY KEY (`id`),
    KEY `idx_order_id` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='订单明细表';

设计亮点：

• 索引分层设计：唯一键保证业务唯一性，联合索引匹配高频列表查询，普通索引覆盖关联查询
• 内置乐观锁 + 逻辑删除 + 审计字段，三大生产级能力开箱即用
• DECIMAL(12,2) 精确处理金额，杜绝浮点精度问题
• 全字段业务注释，降低团队协作沟通成本

7.2 MyBatis-Plus 实体类

@Data
@TableName("t_orders")
public class OrderMain {

    @TableId(type = IdType.AUTO)
    private Long id;

    private String orderNo;

    private Long userId;

    private BigDecimal totalAmount;

    private Integer status;

    @Version
    private Integer version;

    @TableLogic
    private Integer deleted;

    @TableField(fill = FieldFill.INSERT)
    private LocalDateTime createTime;

    @TableField(fill = FieldFill.INSERT_UPDATE)
    private LocalDateTime updateTime;
}

亮点：@Version 乐观锁、@TableLogic 逻辑删除、@TableField 自动填充——MyBatis-Plus 三件套直接拉满，业务代码零侵入。

7.3 Spring Data JPA 实体类

@Data
@Entity
@Table(name = "t_orders", indexes = {
    @Index(name = "uk_order_no", columnList = "orderNo", unique = true),
    @Index(name = "idx_user_id", columnList = "userId"),
    @Index(name = "idx_status_create_time", columnList = "status,createTime")
})
@SQLDelete(sql = "UPDATE t_orders SET deleted = 1 WHERE id = ?")
@Where(clause = "deleted = 0")
public class Order {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false, length = 32)
    private String orderNo;

    @Column(nullable = false)
    private Long userId;

    @Column(nullable = false, precision = 12, scale = 2)
    private BigDecimal totalAmount;

    @Column(nullable = false)
    private Integer status;

    @Column(nullable = false)
    private Integer deleted = 0;

    @Column(nullable = false, updatable = false)
    private LocalDateTime createTime;

    @Column(nullable = false)
    private LocalDateTime updateTime;
}

亮点：@SQLDelete + @Where 实现 JPA 层面的透明软删除——业务代码完全无感，不用每个查询都手动加 deleted=0，比 MyBatis-Plus 方案更优雅。配合 spring.jpa.hibernate.ddl-auto=validate，还能自动检测实体和表结构是否一致。

---

八、踩过的 5 个坑与解决方案

实战中遇到的问题，比想象中多。以下是我踩过的坑和对应的解决方案，希望能帮你少走弯路。

坑 1：AI 生成的表结构违反第三范式

表现： 字段冗余，比如把用户信息直接塞进订单表，搞成大宽表。

解决方案： Prompt 中明确指定"遵循第三范式"；生成后先校验实体依赖关系，人工拆解冗余字段。

坑 2：索引设计两极分化——要么缺失，要么过度

表现： 要么关键查询字段没索引导致慢查询，要么每个字段都加了索引拖垮写入性能。

解决方案： 在 Prompt 中同步告知高频查询场景，让 AI 基于查询推导索引。生成后按业务查询路径逐一校验，保留核心联合索引，删除无效单列索引。

坑 3：多对多关系遗漏中间表

表现： 用户和角色的多对多关系，AI 直接在用户表里加了个角色字段，没有建中间表。

解决方案： 输入时用自然语言明确标注实体间的映射关系（1:1、1:N、N:N），生成后重点核对关联字段和中间表的联合索引设计。

坑 4：字段规范不符合团队标准

表现： AI 用 INT 做主键、金额用 FLOAT、命名风格不统一。

解决方案： 建立 Prompt 模板库，把团队的命名规则、字段规范、标准注释格式做成固定前缀注入。比如我们团队统一用 t_ 前缀、金额一律 DECIMAL(12,2)，这些铁律写进 Prompt，AI 就很少跑偏。

坑 5：生成的代码无法直接适配项目框架

表现： 实体类注解风格和现有项目不一致，导入后一堆编译错误。

解决方案： 输入时明确指定技术栈版本（SpringBoot 3.x + MyBatis-Plus 3.5 / JPA），同时把项目目录拖进 TRAE 作为上下文，让 AI 基于现有项目风格生成代码，而不是凭空创造。

---

九、一张图总结：AI 辅助建表的核心心法

---

十、写在最后

用 TRAE Work CN 生成表结构这段时间，我最大的感受是：AI 不是替我们写代码，而是替我们完成那些"有明确模式"的枯燥部分。

建表 SQL 有模式吗？有。实体类有模式吗？有。注释有模式吗？有。这些重复性的模板化工作，恰恰是 AI 最擅长的。

而业务建模是否合理、索引设计是否匹配真实查询、表结构能否支撑未来扩展——这些需要经验和判断力的部分，始终是我们的核心价值。

把重复劳动交给 AI，把思考留给业务。这才是 AI 辅助开发的正确打开方式。

---

如果这篇文章对你有帮助，欢迎点赞、收藏、转发。关于 Prompt 模板库的完整版本和 CI 集成 SQL 审查的详细配置，我会在后续文章中展开，感兴趣的可以先关注不迷路。

【别走，交个朋友】

我是 Rain ，一个喜欢把复杂技术讲透、让代码落地的实践者。

如果你厌倦了四处收集碎片化的八股文，想看看一线项目里真实的架构决策和踩坑记录，欢迎来我的公众号「Rain 的 Java 大神之路」坐坐。 在这里，我会把每一次技术复盘、每一个项目的设计源码，毫无保留地分享给你。
个人博客：[www.javadashen.com]
🔥 技术这条路很酷，我们结伴同行。
🚀Keep Coding, Keep Loving —— 与所有 Java 同路人共勉。