技术方案评审被卡，多半卡在评审要的四个答案，方案里一个都没写。你写的是实现路径，评审问的是这事做得成吗、要花多少、会出什么问题、还有没有别的选择。AI 在这里的用法很明确：把你的方案按评审的关注点重排一遍，把没回答的问题提前暴露出来。
评审的四个关注点，方案里逐个给答案
可行性、成本、风险、替代方案，这四项是评审者心里的一张清单。写方案时按这四项各设一节，比按实现顺序平铺直叙更容易过。可行性要给证据：依赖的系统有没有接口、团队的技能栈覆盖不覆盖，逐条列。成本要给区间和假设：人力投入按什么估算、外部依赖按什么计价，假设变了成本怎么变。风险和替代方案后面单说。
AI 的用法是自查：把成稿丢给它，让它按这四个关注点逐项检查哪些没写、写得含糊。它挑出来的空洞，往往就是评审现场会被追问的地方。
对比表：至少两套方案，选择才有依据
只给一套方案，评审只能回答行或不行；给两套以上，讨论才能从「做不做」转向「选哪个」。对比表至少写四列：成本、工期、风险、适用条件。适用条件这一列最容易被漏掉，它回答的是「什么情况下该选另一个」，这恰恰是评审判断你思路成熟度的依据。
备选方案不用写得和主方案一样细，但前提和代价要写准。让 AI 帮忙生成对比初稿时，把两套方案的关键参数都给它，要求只列差异不编数据——对比表里出现一个没有出处的数字，整张表的公信力都会被质疑。
把「为什么不用 X」提前写成小节
评审最常见的追问就是这句。与其等被问，不如主动写一节备选方案的排除理由。写法有讲究：不写「X 不成熟」这种定性结论，写「X 在我们的数据量级下需要额外维护一套同步逻辑，当前人力覆盖不了」这种带前提的理由。理由带前提，评审才能判断你的取舍在他们的约束下是否成立。
被排除的方案也分层次：完全不可行的、可行但代价高的、可行但时机不对的。分类写出来，评审会看到你不止考虑了一个方向。
风险后面必须接应对动作
只列风险不给应对，等于把问题原样丢给评审席。每条风险后面接一个动作：触发条件是什么、由谁做、做什么。比如「第三方接口在联调期不稳定」后面接「提前两周申请测试环境，联调排期避开其发版窗口」。有触发条件和责任人的风险，才叫已经评估过的风险。
分级也有讲究。概率高影响大的，写应对预案；概率低影响大的，写兜底方案；概率高影响小的，写进已知代价。三类混在一张列表里不分层，评审会认为你没想清楚。风险的来源要讲证据，售后数据的归因那篇讲的「先分环节再定责任」思路，同样适用于线上问题的归因。
场景对照：不同方案类型的追问点
| 方案类型 | 评审最常追问的 | 提前准备的材料 |
|---|---|---|
| 架构调整 | 迁移期新旧并行怎么保障 | 切换步骤与回退条件清单 |
| 引入新组件 | 多一套依赖多一份维护成本 | 维护责任人与学习成本估算 |
| 性能优化 | 瓶颈判断的依据是什么 | 压测口径与两次测量的对比 |
| 数据迁移 | 迁错了怎么办 | 校验规则与回退演练记录 |
这张表按方案类型对号入座，材料栏没备齐，就先别约评审会。
AI 帮不上忙的部分
AI 编不了你们系统的现状。哪些服务有历史包袱、哪个团队上半年被同类项目拖过工期、评审席上谁对某个方向有保留意见，这些上下文都在人脑子里，它拿不到。所以它的产出定位是结构与查漏：帮你按评审关注点重排内容、检查有没有漏答的问题、把口语化的理由改写成带前提的表述。取舍本身必须你来做，因为承担后果的也是你。
另一个边界是成本估算。它给出的数字只能当占位符，人力、周期、资源这类数据，用它的初稿之前先按团队历史数据校准一遍，带假设区间的估算比单点数字安全。
方案评审速查
- 可行性、成本、风险、替代方案，四项各设一节
- 对比表至少两套方案，写清适用条件
- 「为什么不用 X」提前写，理由带前提
- 每条风险接应对动作：触发条件、责任人、动作
- AI 只做结构重排与查漏，数字先校准再入稿
三个常被问到的问题
- 方案很短也需要写备选吗？：篇幅不是免写备选的理由，三行说明「考虑过什么、为什么没选」就能挡掉一次追问。备选写多细跟方案体量走，写不写跟评审机制走。
- 评审临时加问题答不上来怎么办？：当场别硬答。记录问题、承诺补充期限，会后把答案补进方案并同步评审人。当场编的答案，二次评审时会被翻出来对照。
- AI 生成的方案结构会不会千篇一律？：会。它的价值在查漏不在表达，终稿的叙述顺序、取舍侧重要按你们团队的评审习惯调。读起来像模板的方案，评审头一个反应就是没花心思。
方案的后续动作同样有方法可循。评审通过后定期回头记录当时的取舍依据，用 AI 做年度复盘那篇的总结法可以直接套用；把模糊的目标改写成可考核的表述，用 AI 写商品标题的关键词思路是同一个道理，把含糊的诉求翻译成明确的字段；汇报对象是管理层时，给合伙人的年度经营总结里那套「先结论后依据」的结构，比技术细节的堆砌更有效。
