否决这个迁移方案
先假设方案必须被否掉，再决定它值不值得做
你是被拉来评审这次迁移的资深工程师，任务是找出足够充分的理由否决它。请：1）列出会让这次迁移失败的具体条件（数据量、停机窗口、回滚、依赖方配合）；2）指出方案里被当成「到时候再说」的问题；3）给出一个更小的替代路径（先迁一部分、先双写、先只迁读）；4）最后才说明：如果你否不掉它，哪两条必须补上。 [粘贴迁移方案]
使用建议
真做决策时先让它否决，再让它支持——两次结论差得越多，方案越需要补。
适合什么场景
- 迁移涉及停写、双写或数据搬迁，中途失败要停半天且难以回滚。
- 方案已有人支持、会上没人反对，你需要一个专门唱反调的角色。
不适合的场景
- 只是加一列、加个索引这类可回滚的小改动：直接做，不必走否决流程。
- 你其实已经决定要做、只想找人背书：这个提示词会照你的期待否掉它，浪费一轮。
示例
输入
迁移方案摘要 把 MySQL 的 orders 表（2.3 亿行）迁到新的 PostgreSQL 集群。 停机窗口：周六 02:00–06:00，mysqldump 导出后导入，改 DNS 切流。 回滚方案：「切回旧库」。 涉及 4 个服务、2 家外部对账方。
你会得到
指出 4 小时窗口装不下 2.3 亿行的导出、导入加校验；「切回旧库」在切换后已有新写入时不成立，因为缺少反向同步；外部对账方周末无人配合。然后给更小的路径：先双写、按 user_id 分片迁移、先迁读流量；若否不掉，必须补金额与行数对账，以及 24 小时反向同步。
常见误用
- 只写「我们要迁移」，不写数据量、停机窗口和回滚方式：否决理由会退化成「风险很高」这种空话。
- 把它当决策者：它说「建议否决」就直接取消项目，没回去补那两个前提。
可以这样改
- 把角色从「否决」换成「你是这次迁移的值班工程师，最怕哪一步」，会得到操作细节而不是流程意见。
- 加「每条风险配一个可观测指标（延迟、行数差、错误率）」，否决理由就变成上线前的检查表。