Claude Code 辅助设计数据库表结构并生成迁移文件

去年年底，我给一个电商 SaaS 团队做技术咨询。他们的核心痛点是：每次新增业务模块，数据库设计和迁移文件编写至少要消耗一名后端工程师 1-2 天时间。更致命的是，不同开发者对命名规范、字段类型、索引策略的理解完全不一致，导致迁移文件质量参差不齐，上线后频繁出现隐式类型转换、缺失索引引发的慢查询问题。

我给他们看了我在 Claude Code 里用一个结构化 prompt 完成订单拆单模块数据库设计的完整过程，从需求描述到生成 TypeORM 迁移文件，总共用了 17 分钟。那个技术总监的第一反应是：“这东西生成的代码能直接用吗？”

这个问题本身就是个陷阱。因为它暗含了一个错误假设：AI 辅助设计的价值取决于“能否直接使用”。今天我就要把这件事讲透：Claude Code 辅助数据库设计的关键不在于替代人工思考，而在于将重复性的规范遵循工作交给 AI，让人把精力真正放在业务抽象和设计决策上。

一、核心结论：AI 辅助数据库设计的真正价值点

在进入具体操作之前，我必须先把这个结论讲清楚。因为过去一年我在团队内部推行这套方法时发现，绝大多数人对 AI 辅助编程的不满，都源于对它的错误期待。

我反复验证后的核心结论有三条：

第一，AI 最适合承担的是“规范翻译器”的角色。 你把业务需求用自然语言讲清楚，把命名规范、索引策略、字段类型选择规则用 prompt 定义明白，Claude Code 可以稳定地将这些规则应用到具体的表结构设计中。这不是“AI 帮你设计数据库”，而是“AI 帮你严格执行你定义的设计规范”。

第二，迁移文件生成是 AI 辅助的最大效率杠杆。 手写迁移文件是一件高度机械但容错率极低的事情，up 方法要写建表逻辑，down 方法要写回滚逻辑，字段类型、默认值、注释一个都不能错。Claude Code 在这个环节可以将效率提升 5-10 倍，而且规范性反而比人工更高。

第三，人必须保留的决策权：业务抽象。 哪些实体需要独立成表、关系是一对多还是多对多、要不要做冗余字段设计、读写分离场景下的索引策略，这些决策依赖业务理解和经验判断，AI 只能提供建议，最终必须由人来拍板。

我见过太多开发者把“用 AI 设计数据库”理解为“把需求丢给 AI，拿到迁移文件直接跑”。结果不是字段类型选错导致上线后数据截断，就是索引设计不合理引发性能问题，然后反过来说“AI 不行”。这不是 AI 的问题，是使用方式的问题。

二、真实场景还原：我是如何用 Claude Code 完成一个订单拆单模块的

为了让你真正理解这套方法，我不讲虚构的博客系统，而是拆解我实际做过的一个案例：电商系统的订单拆单模块。

2.1 业务背景

场景是这样的：用户在提交订单时，如果购物车里有来自不同供应商的商品，或者有预售商品和现货商品混在一起，系统需要将原始订单拆分成多个子订单，每个子订单对应一个供应商或一种发货策略。

这个模块的表结构设计有几个难点：

• 拆单规则是可配置的（按供应商拆、按库存状态拆、按发货仓库拆），规则本身需要存成配置数据。
• 拆单后的父子订单关系需要清晰可追溯。
• 不同拆单策略产生的子订单可能有不同的状态流转逻辑。
• 系统需要支持拆单失败时的回滚和重试。

如果是纯手工设计，我需要先画 ER 图，再逐个定义字段类型和约束，然后手写 TypeORM 的 migration 文件。整个流程大概需要 3-4 小时，前提是中间没有反复修改。

2.2 我给 Claude Code 的结构化 Prompt

下面是我实际使用的 prompt 结构。注意，它不是一段“帮我设计订单拆单表”的简单描述，而是一个分层的、包含约束和规范的指令集。

我在 Claude Code 中是这样组织 prompt 的：

第一层：角色与上下文设定

你是一名资深后端架构师，精通电商系统数据库设计。
当前项目使用 TypeORM + PostgreSQL，迁移文件遵循 TypeORM Migration API 规范。

数据表的命名遵循以下约定：

表名使用 snake_case，复数形式

主键统一使用 uuid 类型，默认值 uuid_generate_v4()

时间戳字段统一使用 created_at 和 updated_at，类型为 TIMESTAMP WITH TIME ZONE

所有表和字段必须包含 COMMENT 注释

外键命名格式：fk_当前表名_关联表名_关联字段

索引命名格式：idx_表名_字段名

第二层：业务实体与关系描述

业务需求：设计订单拆单模块的数据库表结构。
核心实体及关系：

拆单规则（split_rules）：定义拆单的策略类型和参数。

规则类型包括：按供应商拆分、按发货仓库拆分、按库存状态拆分

每条规则包含优先级字段，支持规则排序

拆单记录（split_records）：记录每次拆单操作的元数据。

关联原始订单 ID

记录使用的拆单规则 ID

包含拆单状态（处理中、成功、失败）

拆单失败时需要记录失败原因和重试次数

订单与子订单的关系通过订单表自身的一个 parent_order_id 字段来维护，
不单独建关系表。原始订单的 parent_order_id 为 NULL，

拆分出的子订单 parent_order_id 指向原始订单。

第三层：具体字段定义

各表详细字段要求：
split_rules 表：

name：规则名称，VARCHAR(100)，NOT NULL

rule_type：规则类型枚举（supplier, warehouse, stock_status），VARCHAR(50)，NOT NULL

config：规则配置参数，JSONB 类型，用于存储不同类型规则的个性化参数

priority：优先级，INTEGER，默认 0，数字越大优先级越高

is_active：是否启用，BOOLEAN，默认 true

split_records 表：

original_order_id：原始订单 ID，UUID，外键关联 orders 表

rule_id：使用的拆单规则 ID，UUID，外键关联 split_rules 表

status：拆单状态枚举（processing, completed, failed），VARCHAR(20)，默认 processing

result_summary：拆单结果摘要，JSONB，存储拆分出的子订单 ID 列表

error_message：失败原因，TEXT，可为 NULL

retry_count：重试次数，INTEGER，默认 0

max_retry：最大重试次数，INTEGER，默认 3

orders 表需要新增字段：

parent_order_id：父订单 ID，UUID，可为 NULL，自关联外键

第四层：迁移文件输出要求

请生成 TypeORM 格式的完整迁移文件，要求：

类名使用 SplitOrderModule + 时间戳格式
必须包含完整的 up 和 down 方法
up 方法中先创建 split_rules 表，再创建 split_records 表，
最后使用ALTER TABLE 给 orders 表添加 parent_order_id 列
down 方法按相反顺序回滚
所有 SQL 使用 TypeORM Migration API 的 queryRunner.query() 方法
每个外键必须显式指定 ON DELETE 行为

第五层：约束与检查清单

在生成迁移文件前，请确认：

所有枚举类型字段是否使用了 CHECK 约束或注释说明了可接受的值范围

是否为外键字段创建了索引

是否考虑了 JSONB 字段的 GIN 索引（如需要）

down 方法是否能完整回滚 up 方法的所有操作

是否遵循了本项目的时间戳命名约定

2.3 Claude Code 的初次输出与我的修正

Claude Code 根据这个 prompt 生成的迁移文件，整体结构是对的，但有三处需要修正。

第一处：订单表的自关联外键。 AI 初始输出给 orders 表添加了 parent_order_id 列的迁移，但漏掉了外键约束的 ON DELETE 行为定义。我追加了一条指令：“parent_order_id 的外键需要定义 ON DELETE SET NULL，当父订单被删除时，子订单保留但解除关联。”Claude Code 立即修正了这部分。

第二处：JSONB 索引。 split_rules 表的 config 字段和 split_records 表的 result_summary 字段都是 JSONB 类型，初始输出没有创建 GIN 索引。我追问了一句：“这两个 JSONB 字段后续会有查询需求，请加上 GIN 索引。”AI 在迁移文件中补充了 CREATE INDEX idx_split_rules_config ON split_rules USING GIN (config) 这样的语句。

第三处：状态字段的约束。 rule_type 和 status 这类枚举值字段，初始输出只用了 VARCHAR 类型但没有 CHECK 约束。我要求 AI 补充了类似 CONSTRAINT chk_split_records_status CHECK (status IN ('processing', 'completed', 'failed')) 的约束定义。

整个修正过程不到 5 分钟，三次对话，迁移文件就能进入可审查状态。

三、常见误区的拆解：为什么你总觉得 AI 生成的表结构有问题

在帮助多个团队落地这套方法后，我总结了四个最高频的误区。这些误区背后反映的，其实是对 AI 能力边界和数据库设计本质的认知偏差。

3.1 误区一：把 Prompt 当许愿池

最常见的做法是写一句“帮我设计一个订单系统的数据库表结构”，然后期待 AI 吐出完美的建表语句。这种做法的问题在于：AI 对“好”的表结构没有统一标准，你对“好”的定义也没有传达给它。

数据库设计中的很多决策是没有唯一正确答案的。比如：

• 用户地址信息是存成独立表还是作为订单表的 JSON 字段？
• 商品价格的快照策略如何设计？
• 逻辑删除用 deleted_at 时间戳还是 is_deleted 布尔值？

这些决策依赖于具体的业务场景、查询模式、团队规范。如果你不在 prompt 中给出约束，AI 就会按照它训练数据中的“主流做法”来生成，而这个“主流做法”不一定适合你的场景。

专业判断：Prompt 的本质是设计规范的外化。 你需要把自己的经验、偏好、团队的编码规范翻译成 AI 能理解的指令。这不是增加了工作量，而是把你脑子里的隐性知识显性化，这件事本身就有长期价值，新成员入职时也能直接复用这些 prompt 模板。

3.2 误区二：跳过人工审查环节

有些开发者把 Claude Code 生成的迁移文件直接跑在开发环境，发现能跑通就认为没问题。这是一个危险的信号。

AI 生成的内容必须经过人工审查，原因是：

• 字段长度的选择可能不合理。 AI 可能默认把 name 字段设为 VARCHAR(255)，但实际业务中产品名称限制在 100 字符以内。多出来的长度表面无害，但在某些数据库引擎中会影响索引效率。
• 索引策略可能不符合实际查询模式。 AI 倾向于给所有外键加索引（这是对的），但可能漏掉那些虽然没有外键关系但经常出现在 WHERE 条件中的字段。
• 迁移文件的 down 方法可能不完整。 AI 有时会忘记写回滚逻辑，或者回滚顺序不正确。每次审查迁移文件时，我至少要在脑子里模拟一遍 up 和 down 的执行顺序，确认不会出现回滚失败的情况。

3.3 误区三：忽视数据库方言的差异

Claude Code 能生成多种数据库的 SQL，但它对特定数据库版本的新特性并不总是准确的。我在实际使用中遇到过这些情况：

• 生成 PostgreSQL 迁移时使用了 MySQL 特有的 AUTO_INCREMENT 语法。
• 在应该使用 PostgreSQL 的 TIMESTAMPTZ 的地方生成了 TIMESTAMP。
• 对 MySQL 8.0 新增的 CHECK 约束支持不了解，用了触发器来实现约束逻辑。

专业判断：你不能假设 AI 生成的 SQL 完全符合你的目标数据库版本。 在 prompt 中明确指定数据库类型和版本是个好习惯，比如“PostgreSQL 14+”或“MySQL 8.0+”。同时，日常积累一份“AI 容易出错的数据库特性清单”非常有价值。

下面是我目前积累的部分清单：

3.4 误区四：把 AI 输出当作最终设计而不是讨论起点

这个误区的表现是：开发者拿到 AI 生成的表结构后，不经过团队讨论就直接落库。数据库设计是一个需要团队共识的过程，AI 的输出应该是技术评审的起点而不是终点。

在我主导的一个项目中，AI 建议把商品 SKU 的属性值存成 JSONB 字段，但团队讨论后发现，某些高频属性（如颜色、尺码）需要独立查询和索引，最终决定把这些核心属性拆成独立字段，只把低频属性留在 JSONB 里。这个决策 AI 做不出来，它需要业务判断。

核心认知：AI 的角色是“加速器”而不是“决策者”。 它帮你快速生成一个结构化、规范化的设计草案，让你和团队可以在此基础上讨论和优化。这比从零开始画 ER 图效率高得多，但最终的架构决策权必须保留在人手里。

四、专业判断逻辑：如何评估 AI 生成的表结构质量

既然 AI 的输出需要审查，那就需要一个系统化的评估框架。我在审查 AI 生成的数据库设计时，会按以下五个维度逐项检查。

4.1 业务语义完整性

这是最重要的维度。你需要确认：

• 所有业务实体都识别到了吗？有没有遗漏的实体需要独立成表？
• 实体之间的关系建模正确吗？（一对一、一对多、多对多）
• 如果有多对多关系，是否正确地使用了中间表？

具体做法： 我会拿 AI 生成的表列表和自己在脑子里画的概念模型做对比。如果 AI 遗漏了某个实体，我会分析原因，是我的 prompt 没有清楚描述这个实体，还是这个实体确实不容易从需求中推断出来？前一种情况我改 prompt，后一种情况我手动补充。

4.2 字段类型选择合理性

这个维度的检查清单包括：

• VARCHAR 字段的长度设置是否与业务约束一致？过长浪费空间并可能影响索引效率，过短则可能截断数据。
• 数值类型的选择是否合适？用 INT 还是 BIGINT？用 DECIMAL 还是 FLOAT？金额字段绝对不能用浮点类型。
• 时间相关字段是否考虑了时区问题？
• 枚举类字段是否有 CHECK 约束或使用了数据库原生 ENUM 类型？

一个我反复遇到的典型问题： AI 倾向把所有文本字段都设成 VARCHAR(255)。这来自训练数据中的惯性，255 是一个“安全”的默认值。但在实际业务中，用户名字段可能只需要 50 个字符，产品描述可能需要 TEXT 类型。我会逐字段检查长度设置，对于需要存储较长文本的字段，明确改为 TEXT 或指定更大的 VARCHAR 长度。

4.3 索引策略与查询模式匹配

索引设计不能脱离查询模式。同一张表，在 OLTP 场景和 OLAP 场景下的索引策略完全不同。审查 AI 生成的索引时，我问自己三个问题：

• 这个索引支持了哪些查询？是我的业务中会真实出现的查询吗？
• 有没有应该建索引但没有建的字段？特别是 WHERE、JOIN、ORDER BY 中高频出现的字段。
• 有没有不应该建索引却建了的字段？每个额外的索引都会拖慢写入性能。

专业判断：索引不是越多越好。 对于写多读少的表，要严格控制索引数量；对于读多写少的表，适度的索引冗余是可以接受的。这个权衡 AI 无法帮你做，因为它不知道你的读写比例和查询频率。

4.4 迁移文件的可维护性

迁移文件是数据库变更的版本控制，它的质量直接影响团队协作效率和回滚能力。审查要点：

• up 和 down 方法是否成对且逻辑对称？ 如果 up 方法创建了三张表，down 方法必须按相反顺序删除它们。
• 迁移是否可重复执行？ 一个健壮的迁移文件应该在重复执行时不报错。
• 是否包含了必要的注释？ 复杂字段的业务含义、索引的创建原因，都应该在注释中说明。

4.5 与实际 ORM 框架的兼容性

不同 ORM 对数据库 schema 的约定不同。Claude Code 生成的迁移需要与你使用的框架兼容：

• TypeORM 的 migration 使用 queryRunner.query() 执行原生 SQL，需要确保语法完全符合目标数据库。
• Laravel 的 migration 使用 Schema Builder，AI 需要生成 PHP 代码而不是原生 SQL。
• Sequelize 的 migration 使用自己的 API，需要确认生成的代码能够正确运行。

实操建议： 在 prompt 中明确指定 ORM 框架和版本，同时提供一段你项目中已有的迁移文件作为格式参考。我会把项目里一个典型的迁移文件内容粘贴到 prompt 中，告诉 Claude Code “请严格遵循这个格式”。

五、Prompt 工程的黄金模板：从“能用”到“好用”的关键

前面反复提到结构化 prompt 的重要性，这一节我把自己经过多次迭代沉淀下来的 prompt 模板完整分享出来，并解释每个模块的设计逻辑。

5.1 模板全景

我的 prompt 模板分为六个模块，每个模块解决一个特定的沟通问题：

5.2 每个模块的编写技巧

角色设定模块

不要只写“你是一名数据库专家”。角色设定越具体，AI 的输出越符合预期。对比：

• 差：你是一名数据库专家。
• 好：你是一名有 10 年电商系统后端开发经验的资深架构师，精通 PostgreSQL 数据库设计和 TypeORM 迁移文件编写。你注重索引策略对查询性能的影响，习惯在表设计中优先考虑数据完整性约束。

技术栈与规范模块

这个模块要具体到命名约定、字段类型偏好、注释规范。示例：

项目技术栈：

ORM: TypeORM 0.3.x

数据库: PostgreSQL 14+

迁移方式: TypeORM Migration API（非原生 SQL）

命名约定：

表名：snake_case，复数形式（如 orders, order_items）

主键：统一命名为 id，类型 UUID，默认值 uuid_generate_v4()

时间戳：created_at 和 updated_at，类型 TIMESTAMPTZ，默认 NOW()

外键：{关联表单数名}_id 格式（如 user_id, order_id）

索引：idx_{表名}_{字段名} 格式

唯一约束：uq_{表名}_{字段名} 格式

字段类型偏好：

短文本（≤200字符）：VARCHAR(具体长度)

长文本：TEXT

金额：DECIMAL(12,2)

状态/类型枚举：VARCHAR(50) + CHECK 约束

配置/元数据：JSONB

业务实体描述模块

用结构化的方式描述实体和关系，不要写自然语言段落。AI 对结构化信息的解析更准确：

实体列表：
订单（orders）

核心属性：订单编号、用户ID、订单状态、总金额、支付方式

关系：属于一个用户（多对一），包含多个订单项（一对多）

订单项（order_items）

核心属性：商品ID、商品名称快照、单价快照、数量、小计

关系：属于一个订单（多对一），关联一个商品（多对一）

拆单规则（split_rules）

核心属性：规则名称、规则类型、配置参数、优先级

关系：被多条拆单记录引用（一对多）

字段细节定义模块

这部分最耗时间但价值最大。每个字段都要明确类型、约束和业务含义：

split_rules 表字段明细：

id: UUID, PK, 默认 uuid_generate_v4()

name: VARCHAR(100), NOT NULL, 规则名称

rule_type: VARCHAR(50), NOT NULL, CHECK (rule_type IN ('supplier', 'warehouse', 'stock_status'))

config: JSONB, NOT NULL, DEFAULT '{}', 规则参数，结构因类型而异

priority: INTEGER, NOT NULL, DEFAULT 0, 优先级（越大越优先）

is_active: BOOLEAN, NOT NULL, DEFAULT true

created_at: TIMESTAMPTZ, NOT NULL, DEFAULT NOW()

updated_at: TIMESTAMPTZ, NOT NULL, DEFAULT NOW()

输出格式要求模块

明确要求生成什么、以什么格式呈现：

请生成以下内容：

TypeORM Migration 文件（完整的类定义，包含 up 和 down 方法）
up 方法中按外键依赖顺序创建表（先创建被引用的表）
down 方法中按相反顺序删除表
所有 SQL 使用 queryRunner.query() 方法
不要输出解释性文字，只输出可运行的代码

约束与检查清单模块

这个模块的作用是要求 AI 在生成前进行自我检查。虽然 AI 不一定会严格执行每一条，但这个清单显著降低了遗漏的概率：

生成前请确认：
□ 所有外键字段都创建了索引

□ 所有金额字段使用了 DECIMAL 而非 FLOAT

□ JSONB 字段是否需要 GIN 索引

□ 所有时间戳字段使用了 TIMESTAMPTZ

□ down 方法能够完全回滚 up 方法的操作

□ 枚举类字段添加了 CHECK 约束

六、不同场景下的策略取舍

数据库设计没有银弹。同一个电商系统，创业期的设计策略和成熟期的设计策略完全不同。这一节我讨论四种典型场景下的取舍逻辑。

6.1 场景一：创业验证期项目

特征： 业务模型还在频繁调整，需求变更速度很快，用户量和数据量都不大。

策略：优先保证灵活性，不必过度设计。

• 表结构可以偏向“宽表”设计，适当使用 JSONB 字段存储不稳定的属性，避免频繁的 schema 变更。
• 索引策略保守，只为明确的高频查询建立索引，避免过早优化。
• 迁移文件可以简化，甚至暂时不写 down 方法的完整回滚逻辑，因为在验证期，正向迭代远比回滚能力重要。

用 Claude Code 的方式： 在 prompt 中明确要求“保持表结构简洁，对于不确定的属性使用 JSONB 存储，索引仅在外键和主键上创建”。AI 会生成一个轻量级的、易于修改的初始设计。

6.2 场景二：业务稳定增长期

特征： 业务模型已经相对稳定，用户量和数据量在持续增长，查询性能开始成为关注点。

策略：从“够用”转向“规范”。

• 对 JSONB 中高频查询的字段进行提取，独立成列并建立索引。
• 检查已有索引的使用情况，根据慢查询日志补充缺失的索引，删除未使用的索引。
• 迁移文件必须包含完整、可测试的 down 方法，因为此时已经承受不起回滚失败的风险。

用 Claude Code 的方式： 在这个阶段，我会把现有的表结构作为上下文提供给 Claude Code，要求它“基于现有 orders 表结构，添加拆单功能所需的表，同时分析现有索引是否需要调整”。AI 的增量设计能力在这个场景下非常有价值。

6.3 场景三：企业级遗留系统改造

特征： 要在已有的、设计可能不规范的数据库上新增功能模块，表和字段的命名可能不统一，存在技术债务。

策略：优先兼容现有结构，逐步规范化。

• 新模块的表结构可以与旧表保持不同风格，但需要在文档中明确标注设计决策原因。
• 新增的外键和索引必须遵循新的规范，但不要为了统一风格而对旧表进行大规模重命名，风险远大于收益。
• 迁移文件需要额外关注与已有数据的兼容性，特别是新增非空字段时的默认值处理。

用 Claude Code 的方式： 我会把旧表的部分结构描述给 Claude Code，告诉它“这些是已有的表，请确保新的迁移不会破坏现有数据，新增字段必须有安全的默认值”。AI 会特别注意外键引用目标的存在性和字段默认值的合理性。

6.4 场景四：多租户 SaaS 系统

特征： 同一套表结构服务于多个租户，需要在隔离性和维护成本之间平衡。

策略：在设计阶段就考虑租户隔离。

• 决定使用“每个租户独立数据库”还是“共享数据库 + tenant_id 隔离”。这个决策 AI 无法帮你做，需要基于成本、合规、运维复杂度综合判断。
• 如果选择共享数据库方案，几乎每张业务表都需要包含 tenant_id 字段，且大部分索引需要把 tenant_id 作为前缀。
• 迁移文件需要考虑存量租户数据的迁移策略，不能简单加一个 NOT NULL 的 tenant_id 列。

用 Claude Code 的方式： 在 prompt 中明确要求“所有业务表包含 tenant_id 字段（UUID，外键关联 tenants 表），所有唯一约束需要与 tenant_id 组合，迁移文件需考虑已有租户数据的兼容性”。

七、避坑清单：这些 AI 生成的问题我全都踩过

讲完策略和模板，这一节我把过去一年在实践中遇到的、有代表性的事故和改进方法整理出来。以下每一条都是我或者我辅导的团队真实踩过的坑。

7.1 字段类型陷阱：AI 把 DECIMAL 写成了 FLOAT

事故回放： 一个财务模块的迁移文件，AI 把“账户余额”字段设成了 FLOAT 类型。上线两个月后，财务对账发现金额有几分钱的偏差，排查了半天才发现是浮点精度问题。

根本原因： AI 训练数据中大量存在金额字段使用 FLOAT 的案例，它在没有明确约束时会倾向于使用更“通用”的浮点类型。

预防措施： 在 prompt 的“技术栈与规范”模块中，明确写出“所有金额相关字段一律使用 DECIMAL(12,2) 或更精确的 DECIMAL 定义，禁止使用 FLOAT 或 DOUBLE”。同时建立代码审查清单，金额字段类型必须人工确认。

7.2 索引遗漏：高并发查询下的性能雪崩

事故回放： 订单列表查询接口在数据量达到 50 万条后响应时间从 200ms 飙升到 8 秒。排查发现 AI 生成的迁移文件没有给 user_id + status 这个高频组合查询条件建立联合索引。

根本原因： AI 知道给外键单独建索引，但无法预知你的实际查询模式。WHERE user_id = ? AND status = ? ORDER BY created_at DESC 这种查询需要复合索引，AI 在没有明确告知查询模式的情况下不会主动创建。

预防措施： 在 prompt 的“约束与检查清单”模块中，列出你的核心查询模式。例如：“已知 orders 表最高频的查询是‘某用户的所有待支付订单，按创建时间倒序’，请确保存在支持此查询的索引。”同时，上线前务必用 EXPLAIN 分析关键查询的执行计划。

7.3 默认值缺失：历史数据迁移的灾难

事故回放： 对已有百万级数据的 orders 表新增 order_source 字段（VARCHAR(50), NOT NULL），迁移文件中没有设置 DEFAULT 值。结果迁移执行时直接报错，现有数据的这个字段没有值，NOT NULL 约束被违反。

根本原因： AI 倾向于给新表的新字段加 DEFAULT，但对于已有表新增字段的场景，它可能忽略 DEFAULT 的重要性。

预防措施： 在 prompt 中明确区分“新建表”和“修改已有表”两种场景。对于后一种场景，要求 AI “所有新增的 NOT NULL 字段必须设置合理的 DEFAULT 值，并在迁移文件中包含对已有数据设置该字段值的 UPDATE 语句”。审查时，在读一遍迁移文件的同时，脑子里模拟一下它在当前生产数据上执行会发生什么。

7.4 down 方法不完整：无法回滚的“单向迁移”

事故回放： 发布后发现 bug 需要回滚，执行 migration:revert 时却发现 down 方法只删除了新建的表，没有把新增的列删掉，也没有把修改过的列改回原样。结果回滚不彻底，数据库处于一个中间状态。

根本原因： AI 对“回滚”的理解停留在“删除新表”层面，对于 ALTER TABLE 类的操作，它可能忘记写对应的逆向 ALTER TABLE。

预防措施： 在 prompt 中明确要求“down 方法必须包含与 up 方法完全对称的逆向操作”。审查时，把 up 和 down 放在一起对比看，up 里每出现一次 CREATE、ALTER、ADD，down 里就必须有对应的 DROP、ALTER、REMOVE，顺序还必须相反。

7.5 外键约束的 ON DELETE 行为缺失

事故回放： 用户注销时需要删除其所有订单，结果因为外键约束的默认行为是 NO ACTION，删除操作被阻塞。而产品需求本来希望的是“用户注销时，订单保留但解除用户关联”。

根本原因： AI 在生成外键时，如果没有明确指定 ON DELETE 行为，很可能使用数据库默认值，而不同数据库的默认行为不同。

预防措施： 在 prompt 的“技术栈与规范”模块中明确规定：“所有外键必须显式指定 ON DELETE 行为，根据业务逻辑选择 CASCADE、SET NULL 或 RESTRICT，不允许使用数据库默认值。”审查时逐条检查外键定义，结合业务规则判断 ON DELETE 行为是否合理。

八、团队落地：如何把 AI 辅助设计嵌入开发流程

个人使用效果是一回事，在团队中规模化落地是另一回事。这一节我分享自己在一个 20 人后端团队中推行这套方法的实践。

8.1 第一步：建立团队共享的 Prompt 库

我做的第一件事不是培训，而是建了一个 Git 仓库，里面存放各种场景的 prompt 模板。团队成员不需要从头写 prompt，而是从模板库中选择最接近自己需求的模板，然后微调。

模板库的组织方式：

prompts/
├── database/

│   ├── new-module/           # 从零设计新模块

│   │   ├── ecommerce-order.md

│   │   ├── user-auth.md

│   │   └── content-cms.md

│   ├── alter-table/          # 修改已有表

│   │   ├── add-column.md

│   │   ├── add-index.md

│   │   └── modify-constraint.md

│   └── framework-specific/   # 特定框架

│       ├── typeorm.md

│       ├── laravel.md

│       └── sequelize.md

└── code-review/              # 审查用 prompt

├── migration-review.md

└── index-strategy-review.md

每个模板文件包含完整的 prompt 文本和一段注释，说明这个模板适用于什么场景、有什么已知局限。

8.2 第二步：建立“AI 输出 + 人工审查”的双重门禁

我们调整了代码审查流程，新增了一个检查项：如果迁移文件是 AI 辅助生成的，PR 描述中必须标注，并且附带使用的 prompt 模板路径。 审查者看到这个标记后，会额外关注上文提到的那五类常见问题。

这个机制有两个好处：第一，审查者不会因为相信“人写的代码”而放松警惕；第二，如果发现 AI 生成的代码有问题，可以回溯到对应的 prompt 模板并进行改进，形成持续优化的闭环。

8.3 第三步：定期做 Prompt 效果复盘

每个月我们会挑出 3-5 个典型的 AI 生成迁移案例，团队一起复盘：

• 这次 AI 生成的迁移质量如何？有哪些需要人工修正的地方？
• 修正的原因是什么，是 prompt 写得不够好，还是这个问题 AI 本身就不擅长？
• 如果是 prompt 的问题，如何改进模板？

经过三个月的迭代，我们团队的一次生成满意率从首次使用的 40% 左右提升到了 75% 左右。剩下的 25% 仍然需要人工修正，但都属于 AI 能力边界内可以理解的范围（主要是复杂业务逻辑和特殊索引策略）。

关键认知：不是 AI 在进步，而是团队的 prompt 工程能力在进步。 当你越来越清楚如何描述需求、如何设定约束、如何引导 AI 输出时，AI 的输出质量自然会提升。这个能力是团队可以持续积累的核心资产。

九、工具边界：Claude Code 做不到什么

在一片“AI 无所不能”的喧嚣中，我必须清晰地指出当前 Claude Code 在数据库设计领域的明确局限。知道做不到什么，比知道能做到什么更重要。

9.1 无法理解你的业务天花板

Claude Code 能生成一个“合理”的电商订单表结构，但它不知道你的业务明年是要扩展到跨境还是下沉到县域。这些战略级的判断会影响分库分表策略、多语言字段设计、地址字段的国际化结构，AI 完全无法预判。

你要做的： 在给 AI 下需求之前，先回答三个问题：未来 12 个月数据量可能增长到什么量级？会有哪些新的查询模式？业务模型中最可能发生变化的部分是什么？这些答案决定了你给 AI 的约束条件。

9.2 无法替代真实环境下的性能测试

AI 可以在迁移文件里创建看似合理的索引，但它不知道这些索引在 1000 万条数据、500 并发查询下的真实表现。索引的实际效果取决于数据分布、查询模式、数据库配置参数等 AI 无法感知的因素。

你要做的： 重要的索引决策必须在接近生产数据量和查询模式的环境中进行性能测试。AI 的建议是起点，不是终点。

9.3 对特定数据库版本的新特性了解滞后

Claude Code 的训练数据存在截止日期，对于数据库的最新版本特性（如 PostgreSQL 16 的 SQL/JSON 构造函数、MySQL 8.3 的新优化器特性），它的了解可能不完整或不准确。

你要做的： 如果你在使用较新的数据库版本，在 prompt 中明确告知版本号，并在审查阶段对照官方文档验证 AI 建议的特性是否存在。

9.4 无法进行复杂的范式化与反范式化权衡

数据库设计中最大的挑战往往不是“如何建表”，而是“这张表应该设计成第三范式还是适当反范式化”。这个决策需要综合考虑读写比例、查询模式、数据一致性要求、开发复杂度等多个因素，AI 无法在缺乏这些上下文的情况下做出正确判断。

你要做的： 把范式化决策权牢牢抓在手里。AI 的职责是“你告诉我怎么设计，我帮你生成规范的表结构和迁移文件”，而不是“你告诉我业务需求，我帮你做架构决策”。

十、总结与行动建议

如果要从这近万字的经验中提炼出最核心的建议，我会说三句话：

第一句：把 AI 定位为“规范执行者”而不是“架构决策者”。 数据库设计的创意、判断、权衡由人来做；命名、格式、迁移文件编写由 AI 来做。这个分工让人的精力集中在最有价值的事情上，同时让重复性工作的质量大幅提升。

第二句：在 Prompt 工程上投资的时间，会在后续的每一个迁移文件中获得回报。 花 30 分钟写好一个结构化 prompt 模板，比每次花 5 分钟写模糊 prompt 然后花 20 分钟反复修正要划算得多。而且模板可以复用、可以分享、可以持续改进。

第三句：AI 的输出质量上限，取决于你给它的约束质量。 你给的约束越具体、越结构化，AI 的输出就越接近你的预期。模糊的指令必然产生模糊的结果。

下一步你可以做的五件事

如果你读到这里，决定在自己的项目中尝试这套方法，我建议按以下顺序行动：

1. 从一个小模块开始。 不要一上来就用 AI 设计整个系统的数据库。选一个 3-5 张表的小模块，用本文的 prompt 模板做第一次尝试，感受整个流程。
2. 建立你自己的 Prompt 模板。 根据第一次尝试的结果和你的技术栈偏好，把模板调整成适合你团队规范的版本。存到项目文档里，下次直接复用。
3. 制定审查清单。 把第七节中的五类常见问题整理成你的个人审查清单，每次审查 AI 生成的迁移文件时逐项 check。
4. 记录每一次修正。 每次你修正了 AI 输出的某个问题，把修正原因记录下来。一个月后回头看，你会发现很多问题是有规律的，这些规律可以反过来优化你的 prompt。
5. 在团队内分享。 如果你觉得这套方法有效，把心得和模板分享给同事。团队中多一个人使用，就多一份 prompt 优化的经验和反馈，最终整个团队都会受益。

数据库设计这件事，本质上是在用今天的决策为未来几个月甚至几年的查询性能和数据完整性买单。AI 可以帮助你把这笔账算得更清楚、执行得更规范，但最终签字确认的，永远应该是那个理解业务、对数据负责的人。