每次”迁移把表锁住了”的事故都从 reviewer 说”看着行”开始。好的迁移审查 Prompt 要指出表大小档位、锁模型、回滚，禁止把 schema + 数据 + 行为变更塞一个迁移里。
适合哪些场景
review 迁移的任何人：DBA、后端 lead、上线前的创业团队、做 forward-only 发布验证的值班。
什么时候不建议这样写 Prompt
别用来审 greenfield schema——那是设计问题。也别在不知道表大小的情况下用。
Prompt 结构公式
每个迁移审查 Prompt 都要带这六个要素：
- 角色：AI 扮演谁（SRE / Release Captain / staff 工程师 / QA Lead）。
- 上下文：技术栈 / 分支 / 失败日志 / diff / dashboard URL。
- 目标：一个具体可交付物——根因、checklist、计划、ticket 列表、runbook。
- 限制：AI 不能做什么（别自动修、别瞎造文件路径）。
- 输出格式：编号清单、markdown 表格、JSON、unified diff、可运行代码。
- 示例 / 信号：1-2 条”好输出”示例，或反例。
这套 Prompt 适合用在哪
- 合并前迁移安全审查
- 十亿行更新的 backfill 计划
- 并发部署 hazard 检查
- forward-only 验证
- 回滚方案生成
12 个可直接复制的 Prompt 模板
1. 迁移安全 triage
Review this migration: {migration}. Output: (1) Lock duration estimate based on table size class (S < 100k, M < 10M, L > 10M), (2) Concurrent-deploy compatibility — does old code break against new schema? (3) Required backfill, (4) Rollback recipe, (5) GREEN / YELLOW / RED verdict.可替换变量： migration
2. 大表加 NOT NULL
Plan to add NOT NULL to a table with {rowCount} rows. Steps: (1) Add nullable column, (2) Backfill in batches of N with idle waits, (3) Verify zero NULLs, (4) Add CHECK NOT VALID, (5) VALIDATE CONSTRAINT (Postgres) / convert to NOT NULL. Specify batch size + downtime estimate.可替换变量： rowCount
3. DROP / RENAME 风险检查
This migration DROPs / RENAMEs `{columnOrTable}`. List which application code reads / writes it (file:line). Compute the deploy-order risk: if old code reads after new schema applies, you have downtime. Output: deploy-order plan or "block — old code still active".可替换变量： columnOrTable
4. 大表加索引
Plan to create an index on a {rowCount}-row table. Decide: (1) CREATE INDEX CONCURRENTLY (Postgres) or pt-online-schema-change (MySQL)? (2) Estimated time + lock impact, (3) Disk space needed, (4) How to verify no duplicates blocking, (5) Plan B if cancelled mid-way.可替换变量： rowCount
5. Backfill 批处理
Backfill {nRows} rows of column `{col}`. Plan: (1) Batch size + sleep, (2) Idempotency (resume on failure), (3) Progress tracking, (4) Lag monitoring on replicas, (5) Abort criteria. Output as a runnable script outline.可替换变量： nRows, col
6. forward-only 验证
This migration is forward-only (no rollback DOWN). Verify the migration is recoverable forward: (1) If applied partially, can the next deploy re-run safely? (2) Is the new schema observable by old code (NULLABLE / DEFAULT)? (3) Are we feature-flag-protected? Output GO/NO-GO.7. 回滚配方
Write a rollback recipe for this migration: (1) Revert SQL (or compensating writes), (2) Data restore strategy if rows were transformed, (3) Order vs application revert, (4) Deadline for safe rollback (after which data drift makes it unsafe).8. 锁感知 DML 改写
This UPDATE will lock {tableName} for hours: {sql}. Rewrite as batched UPDATEs with a lock-friendly WHERE clause. Use cursor-based iteration over PK. Show the rewritten SQL + a runner skeleton.可替换变量： tableName, sql
9. 并发迁移协调
Two migrations are landing this week: {migA} and {migB}. Check: (1) Do they touch the same table? (2) Will they serialize on the same lock? (3) Is the deploy order specified? (4) Are they both idempotent if one fails? Output a coordination plan.可替换变量： migA, migB
10. 迁移测试计划
Generate a test plan for this migration: (1) Run on a copy of prod-shaped data, (2) Time the migration with realistic concurrency, (3) Assert post-state matches expected (row counts, constraints, indexes), (4) Run app smoke tests against the migrated DB. Output a runnable checklist.11. RLS / 策略迁移审查
This migration adds / changes row-level security policies on `{table}`. Verify: (1) Existing queries still authorise correctly (no accidental lockout), (2) Service-role queries unaffected, (3) Policy ordering — first-match vs combined, (4) Tests cover both authed and anon paths.可替换变量： table
12. 迁移事故复盘
A migration caused incident: {incidentSummary}. Write a brief post-mortem: (1) What lock / write pattern caused the outage, (2) Why review didn't catch it, (3) One process change (e.g., require row-count in PR description), (4) One automated check we should add. 200 words max.可替换变量： incidentSummary
容易踩的坑
- 一条语句给大表加 NOT NULL。
- 改名字时老代码还在读老列。
- 热表上 CREATE INDEX 没加 CONCURRENTLY。
- 没回滚配方——首次失败变长时间事故。
- schema 变 + 数据 backfill + 行为变更塞一个迁移里。
- 跳过”多少行”这个问题——所有判断都依赖它。
- 只在 staging 测，看不出规模 bug。
优化技巧
- PR 描述里写清楚表大小档位。
- expand → migrate → contract，一个 PR 一阶段。
- backfill 必带批次、sleep、断点续跑。
- Postgres 索引用 CONCURRENTLY，MySQL 用 pt-online-schema-change。
- 在生产形状数据上测，不要只用 seed。
- 每个迁移 PR 都要回答”周五 3 点上会怎么样？”。
- 回滚和迁移同一个 PR，写不出回滚就说明不安全。
实操加深
使用这些 prompt 时，不要只替换一个主题词就直接交付。围绕「数据库迁移审查 Prompt：安全变更模板」先补齐受众、渠道、长度、语气、参考样例、禁止样式和成功标准，再让模型输出 2 个不同版本做横向比较。好的结果应该能被另一个人直接复用，而不是只有顺滑但空泛的表达。
如果输出看起来像通用模板，下一轮要增加一个真实场景、一个反例和一个可检查指标，例如点击率、转化动作、字数、平台限制或品牌禁区。这样改出来的内容才更像可用资产，而不是一次性的灵感草稿。
FAQ
- 什么级别小到可以跳过审查？: 永远不行——MySQL 加默认值都能锁表。
- 简单迁移让 AI 自动通过？: 别——AI 提建议，人签字。
- 怎么准确估算迁移成本？: 行数 + 平均行宽 + 并发 QPS。
- 上班时间能跑迁移吗？: 小幅 additive 可以；schema 变 / 大 backfill 走低峰。
- 新 schema 需要 feature flag 吗？: 行为依赖新列填充时需要。
- 写不出回滚怎么办？: 把迁移拆开。写不出回滚就是隐藏风险。