Schema 错误是最贵的一类 bug。它一存活就好多年，每次回填都让它更难修，而真正能救它的那次迁移，恰恰没人愿意排期。下面这些 Prompt 让 AI 站在未来工程师的视角看 schema：负载下怎么查、并发写下怎么迁、量级涨 10 倍怎么扩。它们专门盯那些过了 review 才暴露的失败：什么都用 TEXT、JSON 列没有明文形状、cascade 规则跟业务意图对不上、产品真正在跑的查询缺组合索引。配合 API 契约评审 Prompt 一起用，让 schema 与 API 不漂离。
一句话总结
- 把 DDL 或 ORM schema 粘进去，选对应 Prompt，要求逐项给结论而不是写大段文字。
- 上线前先跑 1、2、4 号；每次生产
ALTER TABLE前都跑 7 号（迁移安全）。 - 用推理强的模型：Claude Opus 4.7 和 Sonnet 4.6 在跨 join 的关系推理上最强，两者都是 1M token 上下文（2026 年 6 月），200 张表的 schema 一次粘得下。GPT-5.5 与 Gemini 3.1 Pro 同样可用。
- AI 只负责标风险，不会替你跑迁移。它给的每个”安全分阶段”方案，都要拿下面表里的 Postgres 锁规则核对一遍。
这套 Prompt 适合用在哪
- 上线前 schema 设计
- 在线表的迁移准备
- 性能审计
- 生产 DB 评审
- ORM (Prisma / Drizzle) → SQL 审计
用哪个模型
Schema 评审很吃推理：模型得同时把表关系、查询形状和锁语义都装在脑子里。截至 2026 年 6 月：
| 模型 | 上下文 | 最擅长 | 备注 |
|---|---|---|---|
| Claude Opus 4.7 | 1M token | FK 关系图、级联、多表 join 的最深推理 | SWE-bench Verified 最高（87.6%）；可在 Claude Code 里跑 |
| Claude Sonnet 4.6 | 1M token | 日常 schema 评审的主力 | API 更便宜（$3/$15 每 1M token）；含在 Claude Pro 里 |
| GPT-5.5 | Plus 应用内约 320 页（$200 Pro 才到 1M） | 写出修正后的 SQL | 选 Thinking/Pro 档做迁移安全评审 |
| Gemini 3.1 Pro | 1M token | 粘超大数仓 schema（200+ 张表） | API $2/$12 每 1M token |
这里 1M 上下文窗口很关键：把整份 schema 加上你最热的 10 条查询一次性粘进去，而不是一张表一张表喂——后者会让模型丢掉跨表的全局视角。
1. Schema 设计异味
下面是我的 schema（DDL 或 Prisma / Drizzle）。请列 top 5 设计异味：(a) 范式不足；(b) 过度范式；(c) 类型错（全 TEXT）；(d) 约束缺失；(e) 隐含假设。每条 1 行修复。
[粘贴 schema]2. 索引评审
下面：schema + 最常见 10 条查询。逐条：(a) 哪些索引命中；(b) 哪些走全表扫描；(c) 建议索引（单 / 组合）；(d) 写入代价的取舍。标出哪些索引应该用 CREATE INDEX CONCURRENTLY 建。
[粘贴]3. 外键 & 级联审计
下面 schema 含外键。逐个评估：(a) 级联（CASCADE / SET NULL / RESTRICT）是否正确；(b) 是否符合业务意图；(c) 生产环境删父行会发生什么。标出问题。
[粘贴]4. 可空性审计
下面 schema。每个可空列问：(a) NULL 是否有语义还是占位；(b) 查询是否要分支处理；(c) 是否应有默认值。标出应改 NOT NULL + DEFAULT 的字段。
[粘贴]5. 软删策略
下面 schema。请评估软删策略：(a) 跨表是否一致；(b) deleted_at 索引；(c) 通过 FK 级联软删；(d) 隐藏已删行的视图。提议统一方案。
[粘贴]6. 审计字段完整性
下面 schema。每张表检查：(a) created_at；(b) updated_at；(c) created_by / updated_by；(d) version。标出缺字段的表并提议默认。
[粘贴]7. 迁移安全
下面是一个针对 Postgres 16+ 的迁移 SQL 文件。评估安全性：(a) 是否有语句拿 ACCESS EXCLUSIVE 锁、堵住读写；(b) 并发写下顺序是否安全；(c) 是否可回滚；(d) backfill 是否分批而非单条语句。把它改写成不锁表的分阶段迁移，并给每一步加上 SET lock_timeout。
[粘贴迁移]这条是每次生产 ALTER TABLE 前都该跑的 Prompt。模型给的方案，再对照下面的锁安全表核一遍。
8. 多对多关联表评审
下面是多对多 join 表。评审：(a) 复合 PK vs surrogate；(b) 顺序 / 唯一性；(c) join 行上的时间戳；(d) 级联规则；(e) 双向索引。
[粘贴]9. 多态关系评审
下面 schema 使用多态关系（例如一对 commentable_type + commentable_id 字段）。请评估：(a) 与拆表的取舍；(b) FK 强制不足；(c) 查询模式；(d) 何时该迁回各类型独立表。
[粘贴]10. JSON / JSONB 列审计
下面 schema 有 N 个 JSON / JSONB 列。逐个评：(a) 形状是否隐式无文档；(b) 是否按路径查询；(c) 是否有 GIN 索引；(d) 是否值得改回关系化。每列给结论。
[粘贴]11. 扩容就绪评审
下面 schema。评估按 10x 容量扩容就绪度：(a) 易膨胀的表；(b) 分区候选；(c) 热点索引；(d) 触发器 / FK 引发的写放大。输出 5 行报告。
[粘贴]12. ORM → SQL diff
下面是我的 Prisma / Drizzle schema 与生成 SQL。请找出：(a) ORM 字段缺少对应 SQL 约束；(b) ORM 丢失的 SQL 功能；(c) ORM 隐藏的假设。提议手写补丁。
[粘贴]不锁表的迁移基本功（Postgres）
AI 擅长看出一条迁移有危险，却记不准每条语句到底拿什么锁。把下面这张表放在 7 号 Prompt 旁边，模型给的每个”安全”改写都拿它核一遍。锁行为依据 PostgreSQL ALTER TABLE 文档 核对（2026 年 6 月）。
| 操作 | 默认行为 | 不锁表做法 |
|---|---|---|
加带常量 DEFAULT 的列 | Postgres 11 起不重写表，很快 | 直接安全；避免 now() 这类易变默认，它仍会重写整表 |
给已有列加 NOT NULL | ACCESS EXCLUSIVE 锁下全表扫描 | 先加 CHECK (col IS NOT NULL) NOT VALID，VALIDATE 后再 SET NOT NULL |
| 建索引 | SHARE 锁在构建期间堵写 | 用 CREATE INDEX CONCURRENTLY（要在事务外跑；失败会留下 INVALID 索引，需复查） |
| 加外键 | ACCESS EXCLUSIVE 锁下扫两张表 | ADD CONSTRAINT ... NOT VALID，再 VALIDATE CONSTRAINT（校验只用 SHARE UPDATE EXCLUSIVE，不堵写） |
| 回填新列 | 单条 UPDATE 锁住每一行、撑爆 WAL | 每批 1,000 到 10,000 行，批间短暂 sleep |
| 删列 | 只改元数据，很快 | 安全，但要先删掉应用里对它的引用，否则读会出错 |
每个迁移开头加 SET lock_timeout = '5s';，让慢语句尽快失败，而不是排在其他所有查询后面堵着。大表上走 expand-contract（并行变更）模式：先加新结构、双写、分批回填，再在另一次部署里删掉旧结构。
这些工具能补模型的盲点
- Squawk 是 Postgres 迁移 SQL 的静态 linter。放进 CI 拦下那些拿
ACCESS EXCLUSIVE锁、或会破坏现有客户端的语句（最新版 2.54.0，2026 年 5 月）。把它当 AI 评审之外的确定性兜底，而不是替代品。 - pgroll 把 expand-contract 模式自动化，同时对外提供两个 schema 版本，让发布过程不锁表。
- ORM 优先的团队跑完 12 号 Prompt 后，应用前先用
prisma migrate diff或 Drizzle 的迁移输出核对生成的 SQL。
常见问题
评审数据库 schema 用哪个 AI 模型最好？ 论跨 join、跨级联规则的关系推理，截至 2026 年 6 月是 Claude Opus 4.7 和 Sonnet 4.6 领先，它们的 1M token 上下文让你一次粘下整份 schema。GPT-5.5 和 Gemini 3.1 Pro 也很强，Gemini 的 1M 窗口对超大数仓 schema 尤其顺手。做迁移安全那条 Prompt 时，把 GPT-5.5 从默认的 Instant 切到 Thinking/Pro。
能不能直接让 AI 替我写迁移？
把它当资深评审，而不是操作员。它能稳定标出 ACCESS EXCLUSIVE 锁、缺 NOT VALID 分阶段、一把梭的回填。但它仍会在锁细节上瞎编，所以每个改写都拿上面那张表核一遍，跑生产前再用 Squawk lint 一遍 SQL。
加一个 NOT NULL 列会锁表吗？
加带常量 DEFAULT 的列在 Postgres 11 及以后不重写表，很快。给已有列加 NOT NULL 会在 ACCESS EXCLUSIVE 锁下全表扫描；安全路径是先加 CHECK ... NOT VALID 约束，再 VALIDATE，最后 SET NOT NULL。
该粘整份 schema 还是一张表一张表来？ 把整份 schema 加上最热的 10 条查询放进一个 Prompt 里。Schema 问题大多是跨表的——缺组合索引、错级联、本该 join 却反范式塞进去的字段——模型只有看到完整关系图才看得出来。当前模型的 1M token 窗口让这种做法很实际。
怎么评审 Prisma 或 Drizzle 的 schema？
先用 1 号 Prompt 在 ORM schema 上找设计异味，再用 12 号把 ORM 定义和生成的 SQL 做 diff。ORM 会悄悄丢掉部分索引、check 约束和 ON DELETE 规则，意外大多藏在这个 diff 里。
容易踩的坑
- 什么都用
TEXT，而不是有类型、有长度上限的列 - 不加
NOT NULL，让 NULL 渗进每个查询分支 - 产品真正在跑的过滤组合，却缺对应的组合索引
- 跨表软删策略不一致
- 迁移在生产环境拿
ACCESS EXCLUSIVE锁 - JSON 列形状隐式、无人记录