表结构设计全扔给AI？先看看这三个翻车现场，再谈正确的用法
把数据库表结构的初稿交给AI生成，是很多独立开发者和小团队最近在做的事。方向没错，但实践里翻车的比例高得惊人。这篇文章先讲三种常见的失败做法，再给出一条我踩完坑之后沉淀下来的正确路径——让AI出初稿、人来做评审，两者各司其职。
一、用户痛点：为什么大家开始让AI设计表结构
独立开发者和小团队的处境很相似：
- 一个人当十个人用。产品、前端、后端、DBA都是你，表结构设计这种“基础但费脑”的活往往被压缩到深夜。
- 改表成本极高。业务跑起来之后再改表结构，意味着写迁移脚本、改代码、处理存量数据，一次失误的代价可能是几天的返工。
- 经验不对称。小团队里往往没有真正懂数据库的人，索引怎么建、字段类型怎么选、要不要冗余，全靠拍脑袋。
于是AI出现了，大家兴奋地把需求一股脑丢给它。然后，翻车开始了。
二、三个真实的翻车现场
翻车一：一句话需求，直接要完整DDL。
“帮我设计一个电商订单库表”，AI很配合，唰唰唰给你二十张表的DDL。看起来专业，字段齐全、注释工整。但仔细看：金额字段用了FLOAT、没有软删除和审计字段、订单和商品是多对多却没建中间表的唯一约束、所有查询字段一个索引都没有。这种表结构上线三个月后，你就会在慢查询日志里见到它。
翻车二：把AI输出当成品，跳过评审。
有人生成完直接复制进migration文件执行。问题在于AI看不到你的业务上下文——它不知道你的订单要支持部分退款，不知道你的用户表将来要对接第三方登录，更不知道你们团队“所有表必须有created_at/updated_at”的约定。缺的这些东西，会在业务迭代时一个个爆出来。
翻车三：让AI反复自我修改，人只当传话筒。
“再优化一下”、“加个字段”、“这个改改”，来回十几轮，人对整体结构已经失去掌控，AI也在多轮对话中逐渐“漂移”——前面定好的命名规范后面忘了，删掉的字段又悄悄加回来。最后产出一份连你自己都说不清设计意图的表结构。
这三个翻车的共同点是：人把自己的判断完全让渡出去了。AI擅长的是“生成”，而表结构设计的核心风险在“决策”。
三、正确路径：AI出初稿 + 人主持评审
我的做法是把这件事拆成两个阶段，每个阶段给AI不同的角色。
阶段一：结构化输入，要方案不要DDL。
不要直接要建表语句，先要一份“设计说明”：实体清单、关系图、每张表的字段与理由、索引建议、可预见的扩展点。这个阶段的产出是人类可读的，方便你快速判断对错，DDL是最后一步才生成的东西。
阶段二：AI当评审员，人当裁判。
初稿定下来之后，开一个新对话，让AI切换成“挑剔的评审者”角色，从性能、扩展性、命名规范等维度逐项挑刺。它提出的每一条意见，由你裁决采纳与否。这比让同一个对话里的AI“自己改自己”有效得多——评审视角和生成视角分离，能发现更多盲区。
一个可复用的提示词模板，直接改业务描述即可：
你是一位有10年经验的数据库架构师，请为以下业务设计表结构。
【业务描述】
（这里写你的业务，越具体越好，包括：核心流程、用户角色、
预估数据量级、已知的未来扩展方向）
【约束条件】
- 数据库类型：（MySQL 8.0 / PostgreSQL 15 等）
- 命名规范：（如：表名小写下划线、字段前缀规则）
- 团队约定：（如：所有表包含 id/created_at/updated_at，
逻辑删除用 deleted_at）
- 特殊要求：（如：金额用 DECIMAL，禁止外键约束，
由应用层保证一致性）
【输出要求】
1. 实体与关系清单（文字版ER描述）
2. 每张表的字段设计及选择理由（先不输出DDL）
3. 索引建议及对应的高频查询场景
4. 潜在风险点与扩展性分析（至少3条）
5. 你不确定、需要我补充业务信息的地方
完成后停下来等我确认，不要自行生成建表语句。评审阶段的提示词：
你是独立的数据库设计评审员，请严格审查以下表结构设计，
逐项检查：字段类型是否合理、索引是否覆盖高频查询、
是否存在过度设计或遗漏实体、并发写入场景是否有隐患、
是否符合我给出的团队约定。每条意见标注严重程度
（阻塞/建议/可选），不要客套，直接指出问题。四、用AI前后的对比
用AI之前：一个中等复杂度的业务（十来张表），我从画ER图到定稿大约需要一个完整工作日，而且因为是一个人闷头做，经常上线后才发现遗漏了退款流水表这类关键实体。评审更是没有——小团队里找不到第二个人看你的表结构。
用AI之后：同样的业务，结构化输入加两轮评审，初稿到定稿大概两小时。更重要的是质量上的变化：AI在评审阶段会主动问出“订单取消后库存怎么回滚”这种我没想到的问题，等于多了一个不知疲倦、不给人面子的技术搭档。我的角色从“画图的”变成了“拍板的”，这恰恰是人该待的位置。
工具选择上，各家主流模型在结构化输出和长上下文上都已经够用，具体选型与费用以官网价格页为准，按自己的预算和偏好来即可。
五、最后
AI没有让表结构设计这件事消失，它改变的是分工：机械的部分（画图、写字段、查规范）交出去，判断的部分（取舍、裁决、担责）留下来。想清楚这一点，AI才真正帮你提效，而不是埋雷。
如果你还没有顺手的AI接口来跑这套流程，可以试试 https://api.thistoken.ai/register ，注册即用，把上面的模板直接丢进去试一轮，感受一下“AI初稿 + 人评审”的工作流。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。