技术方案评审，最常见的翻车方式是方案本身没大错，却被问到没想过的地方当场卡住。AI 在这件事里最合适的位置，是会前扮演那个"挑刺的人"：它替评审提前问你一遍，你把答案准备好，会上就从被动挨问变成有备而来。
会前演练的三步
第一步，让它找漏洞。把方案粘进去，用这样的指令：请以一位资深架构师的角度评审这份方案，重点找四类问题——技术选型有没有更合适的替代方案、性能和扩展性上的隐患、对现有系统的兼容风险、实施难度被低估的地方。只挑问题，不要夸。给它的方案越具体（模块划分、数据流向、依赖关系），它挑出的漏洞越真；只给一段笼统描述，得到的也是笼统的泛泛之谈。
第二步，让它预判提问。接着上面的输出继续问：基于这份方案，列出评审会上最可能被问到的十个问题，按被问概率排序，并给出回答要点，重点关注成本、工期、风险，以及"为什么不用另一种方案"。
"为什么不用另一种方案"值得单独准备，这是评审会上出现频率很高的杀手问题。备选方案是什么、你为什么没选、代价是什么——这三句答不上来，其他部分答得再好也撑不住场面。
第三步，把回答填实。AI 给的只是框架，你要往里填具体的数字、真实的约束和团队的实际能力。空泛的回答在会上站不住："性能会有瓶颈"不如"按现有压测口径，某个环节在预期并发下余量不足，对策是读写分离"。
只能自己准备的四样东西
- 真实数据：压测结果、成本测算，必须是你自己跑出来的。AI 编不出你的环境参数，替你编的数字在评审会上就是定时炸弹。
- 团队情况：技术储备、时间安排、人力分配，AI 不了解，而评审恰恰会追问"你们做得完吗"。
- 历史包袱：现有系统的历史原因、当年的妥协，只有内部人清楚，这些是"为什么不能推倒重来"的答案。
- 决策理由：为什么这么选，背后的权衡必须由你说明。理由可以借 AI 帮你整理表达，但权衡本身发生在你的业务判断里。
会前准备对照表
| 提问方向 | 会前要准备的材料 | 站不住的回答长什么样 |
|---|---|---|
| 选型质疑 | 备选方案对比、放弃的理由与代价 | "主流都用这个"——没说出为什么你的场景适合 |
| 性能与扩展 | 自己的压测数据、瓶颈环节与对策 | 只有定性结论，给不出余量数字 |
| 兼容与迁移 | 受影响的系统清单、灰度与回滚路径 | 说"影响不大"，却列不出受影响方 |
| 工期与资源 | 人力安排、依赖项、缓冲区间 | 拍出一个日期，说不出依据 |
保密边界要自己守
涉及公司技术架构和业务数据的方案，用公开工具前要做两件事：能脱敏的脱敏——模块改名、数字换比例、内部系统用代称；不能脱敏的部分不出内网。企业如果已有合规的工具白名单，按白名单走，别为了方便把架构图直接贴进公开网页版。
评审准备速查
- 会前两轮提问：先挑漏洞，再生成十大问题清单
- 单独准备"为什么不用另一种方案"
- 压测与成本数据自己跑，不用 AI 编的数
- 敏感架构先脱敏，再进任何工具
- 每个回答都要落到数字、约束或路径上
它帮不了的部分
AI 不了解你的业务优先级。同样一份方案，在"三个月内要上线"和"系统要跑五年"两种前提下，正确答案完全不同，而它不知道你的前提是哪个。它也给不出组织层面的判断：跨团队怎么协调、上线窗口选在哪、决策方真正担心的是什么。这些它替你想不了。会前留点时间，自己把"我最怕被问什么"过一遍，比多生成十页问答清单有用。
三个常被问到的问题
- 方案还没写完，可以先演练吗？：可以，而且更划算。把半成品给它挑漏洞，挑出的问题正好是下一步要补的内容；等定稿再演练，返工成本反而高。
- AI 列的十个问题会上真会被问到吗？：不一定全中，但重叠度通常不低。更重要的是这十个问题逼你把方案过第二遍，命中率只是副产品。
- 评审当场被问住了怎么办？：承认没想过，记下来，给出回复时限。现场硬编一个答案，风险远大于"这个问题我回去确认，今天下班前答复"。
这种"先让机器扮演反方、再把答案填实"的做法，在其他汇报场景同样好用：写经营总结前可以先看给合伙人的版本怎么写，阶段复盘的框架可以参考数据与选题的总结法，两者都强调结论要有自己的数据撑着，和评审准备是同一个道理；而把复杂方案压成一句能站住的开场陈述，方法在一句文案的提炼法里也讲得通。
