表结构一版就翻车？先别急着让AI直接生成SQL——聊聊我用AI评审表结构的正确姿势
一、先说失败案例：三种常见的翻车做法
我自己就踩过坑。第一次用AI设计数据库表结构时，我把一句话需求丢给它：「帮我设计一个电商订单系统的表结构」。AI很配合，唰唰唰吐出一堆建表语句，字段齐全、注释工整。我直接复制到数据库里跑通了，心满意足。
三周后问题来了：
翻车一：字段类型想当然。 订单金额用了float,对账时精度丢失；手机号存成了int,前导零直接消失。AI生成的时候我一句都没看。
翻车二：缺少业务约束。 用户表没有软删除标记，测试环境删了一条数据，关联的订单全成了孤儿记录。AI不知道我的业务里有“注销后数据保留180天”这条合规要求——因为我根本没告诉它。
翻车三：让AI一次性交付，不做对抗性评审。 有一次我让AI“优化”表结构，它建议把订单明细表合并进订单主表，理由是“减少JOIN提升性能”。我照做了，后来一个订单要支持拆包发货，主从结构改起来痛不欲生。
这三种做法的共同点是：把AI当成代码生成器，而不是设计伙伴。独立开发者和小团队最容易掉进这个坑——人手不够，恨不得AI一口气把活全干完，跳过了最关键的“评审”环节。
二、正确路径：AI当设计师，更当红队
后来我调整了流程，核心思路是：AI先出方案，再用AI当红队挑刺，最后人来拍板。整个流程分四步。
第一步：喂背景，而不是喂需求
不要只给一句需求，要把业务背景、数据规模、特殊约束一起交代。比如我会告诉AI：这是给独立开发者用的SaaS,单租户数据量预计在十万级，用户手机号需要支持海外格式，历史数据不允许物理删除。
第二步：让AI输出设计文档，而不是SQL
我明确要求AI先不要写DDL,而是输出字段清单、类型理由、索引设计思路和已识别的业务边界。这样做的好处是：文档比SQL更容易发现逻辑问题，而且逼着AI“解释自己”，解释不出来的地方往往就是坑。
第三步：开一个新对话，让AI扮演评审员
这是整个流程里性价比最高的一步。开一个全新对话(避免AI偏袒自己的方案)，把设计文档贴进去，让它扮演一个“挑刺的DBA”,专门找：类型隐患、索引滥用、扩展性风险、遗漏的业务场景。AI对抗AI,经常能挖出我自己完全想不到的问题——比如它曾提醒我“如果后续要做按月归档，主键最好带上时间语义”，这种细节单靠我自己想很难周全。
第四步：人工拍板，再生成SQL
评审意见整理后，由我决定采纳哪些，最后才让AI输出带注释的DDL和ER图说明。到这里，SQL只是水到渠成的产物。
三、可复制的提示词模板
这是我沉淀下来的评审提示词模板，直接复制改需求就能用：
你是一位有10年经验的后端架构师兼DBA,现在负责评审一份MySQL表结构设计。
【业务背景】
- 系统类型:(如:面向小团队的工单管理系统)
- 预估数据量:(如:单表百万级以内,增长缓慢)
- 特殊约束:(如:数据需软删除;需支持多时区;手机号含国际格式)
【待评审的设计方案】
(在此粘贴字段清单/设计文档/DDL)
【评审要求】
请从以下维度逐项挑刺,按严重程度排序输出:
1. 字段类型与长度是否合理(重点检查金额、手机号、时间戳、枚举值)
2. 主键与索引设计是否存在隐患(含写入放大、索引失效场景)
3. 业务边界遗漏:哪些真实场景下这套结构会出问题?
4. 扩展性风险:半年后如果新增XX需求,哪里会最先崩?
5. 给出修改建议,每条注明理由和改动的代价。
不要客套,直接指出问题;如方案整体可行,也要列出最值得警惕的前三个风险点。设计阶段的提示词类似，把「评审要求」换成「先输出字段清单、类型理由、索引思路和业务边界清单，暂不生成SQL」即可。
三、用AI前后对比
流程耗时： 以前手工设计一套十张表的工单系统结构，查资料加画图大概要一天；现在用这套流程，两三个小时能走完设计加评审，而且质量更高。
返工成本： 以前直接让AI生成SQL,平均每个项目要为表结构返工两到三次；引入“AI红队评审”后，上线后的结构级返工基本消失——问题都在纸面上被拦住了。
认知收益： 这点最容易被忽略。AI的评审意见会解释理由，比如为什么decimal比float适合金额、为什么软删除要配唯一索引的绕行方案。看多了这些解释，我自己的设计判断力也在涨。对独立开发者来说，这是低成本请了个随时在线的资深DBA带教。
成本方面： 整个流程一轮下来大约消耗几万到十几万token,具体费用取决于所用模型，以官网价格页为准。相比省下的返工时间，这笔投入基本可以忽略。
四、几点提醒
- AI的评审不能替代真实压测。 索引是否真的有效，最终还是要靠执行计划和真实数据说话。
- 涉密数据不要直接贴。 表名、字段语义做脱敏处理后再喂给AI。
- 重要决策永远自己拍板。 AI给的是候选方案和风险清单，不是圣旨。
工具方面，这套流程对模型能力有一定要求——设计阶段的推理质量直接决定方案上限，评审阶段则更看重模型能否“不顺着说”。如果你在找一个稳定的模型调用渠道，可以看看 https://api.thistoken.ai/register ,注册即用，适合把这类设计-评审流程跑成日常习惯。
表结构是系统的地基。让AI画图容易，让AI帮你把关地基，才是它真正值钱的地方。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。