技术方案评审怎么做：不是挑毛病，而是提前看见风险
摘要
技术方案评审不是为了证明谁更懂，也不是在上线前挑毛病。它的价值，是在投入实现之前，让团队看见目标、约束、方案取舍、风险和恢复路径。好的评审能减少返工，也能提高系统长期可靠性。
评审先看目标
技术方案评审第一步，不是看实现细节，而是看目标。
这个方案要解决什么问题？成功标准是什么？有没有不做的范围？如果目标不清，后面讨论架构、接口、存储和性能都会失焦。
很多技术争论，其实是目标不同。
有人在优化开发速度，有人在优化长期扩展，有人在关注稳定性，有人在关注用户体验。
目标没有说清，讨论就会变成各自正确。
约束必须摆出来
方案不是在真空里设计的。
时间、人力、已有系统、团队经验、数据量、合规要求、上线窗口，都会影响选择。
一个方案看起来更优雅，但如果团队没人能维护，可能不是当前最合适。
评审时要问：这个方案是在什么约束下成立的？
把约束摆出来，团队才能判断取舍是否合理。
否则大家只是在比较理想方案。
重点看风险路径
技术方案评审最有价值的部分，是提前看见风险。
数据会不会丢？接口失败怎么办？权限是否越界？扩展时瓶颈在哪里？回滚是否可行？日志是否足够排查？
这些问题不是消极，而是在保护未来。
好的评审不是问“你为什么没想到”，而是一起问“哪里最可能出问题”。
风险越早暴露，代价越低。
评审取舍，而不是追求完美
每个方案都有代价。
评审不是要求方案没有缺点，而是确认团队是否知道自己接受了什么代价。
比如为了快速验证，接受较简单的实现；为了长期维护，接受更长开发周期；为了降低风险，接受更多检查步骤。
关键是代价要被说出来。
没有说出来的代价，未来会变成意外。
输出明确结论
评审结束后，必须有结论。
是通过、修改后通过、需要补充信息，还是暂缓？需要谁补什么？什么时候再看？
如果评审只讨论很多意见，却没有结论，后续执行仍然混乱。
最好记录：
- 方案目标。
- 关键取舍。
- 已知风险。
- 待办动作。
- 通过条件。
这份记录会成为后续实现和复盘的依据。
保持评审气氛安全
评审要有效，必须让人愿意暴露问题。
如果每次评审都变成指责，大家会把风险藏起来，只展示最漂亮的一面。
好的评审应该针对方案，不针对人格。
问题越早被发现，越是团队收益。
评审不是挑毛病，而是一起把系统做稳。
结论
技术方案评审怎么做？先确认目标和约束，再检查风险路径、方案取舍和恢复方式，最后形成明确结论。
它不是为了阻止实现，而是为了让实现少走弯路。
好的评审会让团队更敢做，也更知道自己在承担什么风险。
