技术评审会怎么开——我见过最有效率的技术评审是什么样的
技术评审会怎么开——我见过最有效率的技术评审是什么样的
适读人群：参与过技术评审但觉得总是没什么效果的工程师和 Tech Lead | 阅读时长：约14分钟 | 核心价值：一套高效技术评审的方法，让每次评审真正产出决策，而不是变成扯皮会
大多数公司的技术评审会，是这样的：
主讲人花了三天时间做了一个PPT，介绍方案A和方案B，详细讲了两种方案的技术细节。开会之后，有人问了几个问题，大家讨论了一会儿，最后没有明确结论，散会。下周再开，重复上述流程。
这不是技术评审，这是技术展示。
我做技术管理这几年，亲自组织过和参与过几十次技术评审。我见过最低效的评审，也摸索出来了我认为有效的评审应该怎么开。
今天把我的经验整理出来，说说技术评审这件事。
技术评审的真正目的是什么
很多人对技术评审的目的理解是偏的。他们认为技术评审的目的是"展示方案"或者"让大家了解我的设计"。
但这些都不是核心目的。技术评审的核心目的只有一个：在实施之前，找出方案里的问题，并做出决策。
注意这里有两个关键词：
- 找出问题：不是展示，是挑战、质疑、找漏洞。
- 做出决策：评审的产出应该是一个明确的决定，不是"大家听了一遍"。
如果一场技术评审结束之后，没有找到任何问题，也没有做出任何决策，那这场评审大概率是在浪费大家的时间。
会前：决定成败的准备工作
我见过很多技术评审失败，失败的原因大多发生在会议开始之前。
问题1：方案文档没有在评审前发出去
有些主讲人是把 PPT 带到会议室现场讲，这基本上注定评审质量低下。因为评审者没有时间提前思考，只能被动接受信息，很难提出有深度的问题。
规范的做法：方案文档要在会议开始前至少24小时发出去，让每个参与者都有时间提前阅读和思考。如果文档没有提前发出，这场评审就应该推迟。
问题2：方案文档格式太自由
有些工程师的方案文档就是流水账：先说背景，再说方案，最后贴一堆代码或者架构图，没有明确说明"我需要评审者做什么决定"。
好的方案文档应该有固定结构：
- 背景：为什么要做这个，解决什么问题
- 约束条件：有哪些不能动的约束（比如不能停服、要兼容现有 API）
- 方案：你的建议方案是什么（如果有多个选项，列清楚每个选项的权衡）
- 风险：这个方案已知的风险和未知的风险
- 需要评审者决定的问题：明确列出，你希望评审会上解决哪几个具体问题
最后一项最重要，也最容易被忽视。明确提出"我需要大家帮我决定的问题"，会让评审者在读文档的时候带着目的去读，评审会上的讨论也会更聚焦。
问题3：参会者选错了
技术评审不是人越多越好。人多的评审往往变成"大家都在旁听，没有人真正参与"。
我的建议：一场技术评审，核心参与者（有发言权的）控制在5-7人。包括：方案负责人、直接实施这个方案的工程师（2-3人）、有相关领域经验的专家（1-2人）、决策者（1人）。
如果有人只是"需要了解情况"，可以在会后同步文档和会议纪要，不需要占用评审会的时间。
会中：主持人是关键
一场好的技术评审，主持人是最关键的角色。主持人不是主讲人，主持人的职责是：
1. 控制时间和节奏
评审会容易跑题——讨论着讨论着就跑到"我们当年是怎么解决这个问题的"或者"你的方案 A 让我想到了另一个完全不相关的问题"。主持人要及时把讨论拉回来：
"这个话题很有价值，我们记录下来，本次评审先专注在XX决策上，等我们把核心问题解决了，再来讨论这个。"
2. 确保每个问题都有结论
每个被提出的问题，在离开之前要有一个明确的处理方式：
- 要么当场解决（"方案是X"）
- 要么有后续行动（"这个问题由老张在本周五之前调研清楚，下次评审带结论"）
- 要么明确不在本次评审范围内（"这个问题超出了本次评审的边界，记录在 parking lot"）
没有结论的讨论是浪费时间。
3. 主动挑战方案
评审会上最常见的问题：大家都在点头，没有人提出实质性的质疑。
主持人要有意识地从不同角度提出挑战，比如：
- "如果并发量是现在的10倍，这个方案还 work 吗？"
- "如果方案里依赖的第三方系统挂了，我们的系统会怎么样？"
- "这个方案有没有回滚方案？如果出问题了，我们能不能在30分钟内恢复？"
- "这个方案三个月后扩展的时候，最难改的地方在哪里？"
这些问题不是为了否定方案，是为了让方案在实施之前被充分检验。
4. 抓出假设
方案里通常有很多隐含假设，评审者没有意识到，主讲人自己也没意识到。主持人要有识别假设的敏感度：
"你说这个查询会很快，这个假设的依据是什么？在数据量增长10倍的情况下，这个假设还成立吗？"
"你假设用户不会同时在多个设备登录，这个假设有业务保证吗？"
把隐含假设显式化，是避免上线后遭遇意外的最有效手段之一。
我见过最有效率的技术评审是什么样的
我在一家做金融科技的公司做 Tech Lead 的时候，跟着首席架构师开了大概一年的架构评审会，那是我见过的最高质量的评审。我把它的特点总结出来：
特点1：每个决策都有"决策理由"记录
不只记录"做了什么决策"，还记录"为什么做这个决策，排除了哪些其他选项，依据是什么"。这个记录叫 ADR（Architecture Decision Record）。
这样做的价值是：三个月后新来一个工程师，他在看代码时看到了一个"奇怪"的设计，不会因为看不懂原因而随手改掉它。他可以查 ADR，了解背景。
特点2：评审结束时明确总结
每场评审结束的最后5分钟，主持人会逐一总结：
- 今天做了哪些决策？
- 有哪些遗留问题？谁负责，什么时候给结论？
- 方案的下一步是什么？
这5分钟极其重要，能让所有参与者带着明确的行动项离开，而不是"开了一场会，好像讨论了什么，但说不清楚结论是什么"。
特点3：专家提前被安排好
如果方案涉及数据库性能，会在评审前就安排 DBA 参加，让他提前看方案，准备问题。如果涉及安全，安全团队的人会参加。不会临时拉人，也不会"等会结束了再问XX专家"。
这个细节很重要，但常常被忽视。
特点4：明确区分"意见"和"阻塞"
参与者提出问题时，要说清楚这是：
- 一个意见（我觉得这样可能不太好，但不影响方案推进）
- 一个建议（这样改可能更好，但可以先做再改）
- 还是一个阻塞项（这个问题不解决，方案不能推进）
混淆三者，会导致明明只是个人喜好，却拖延了整个项目进度。
几个导致技术评审失败的场景
场景1：评审变成了个人秀
主讲人花了大量时间介绍方案的优点，说这个方案有多好，但没有人质疑，没有挑战。大家都点头，评审结束，什么问题都没发现。
上线后出了问题，大家说：当时评审的时候没发现啊。
场景2：讨论陷入技术细节死循环
两个人开始争论"Redis 的 hash 结构好还是 string 结构好"，或者"用 MySQL 存这个数据还是 MongoDB"，越争越细，越争越偏，主要问题根本没有讨论到。
主持人要及时介入：这个问题我们记下来，先解决更重要的架构决策。
场景3：没有决策权的人主导讨论
有人提出了一堆质疑，说方案不行，要换方案，但他实际上没有最终拍板的权力，结果会议陷入无休止的争论，最后不了了之。
解决方法：在会议开始时明确"谁是本次评审的决策者"。
场景4：评审文档没有被认真对待
大家把评审文档当 PPT 来写，追求"好看"而不是"清晰"。评审文档应该是一个工作文档，逻辑清晰比排版好看重要一百倍。
最后说一个不那么主流的观点
有一种声音说："技术评审会流程太重了，会降低团队速度，小团队根本不需要这么正式。"
我部分同意这个说法。对于小团队、简单功能、低风险改动，可以用更轻量的方式做评审（比如一对一的 Code Review，或者简短的技术同步）。
但有几种情况，无论团队规模大小，我都建议做正式的技术评审：
- 影响多个服务的架构改动
- 对数据库 schema 的重大变更
- 引入新的技术栈或第三方依赖
- 任何上线后难以回滚的改动
这类改动的风险太高，花一两个小时做认真的评审，能避免的问题往往远超评审成本。
技术评审的异步化：不是每次都要开会
技术评审一定要开会吗？未必。
有时候，发一份方案文档，让相关人员异步 Review，在文档里留评论，能达到和开会同等的评审效果，而且不占用所有人同一时间段的时间。
异步评审适合：方案相对清晰、主要决策点不多、不需要即时头脑风暴的情况。
仍然需要开会的情况：方案复杂、存在多个相互竞争的选项、需要即时讨论来收敛决策、参与者背景差异大需要同步信息。
区分这两种场景，能显著减少不必要的会议，把时间花在真正需要开会的地方。
技术评审文化的建设
从"没有技术评审"到"有效的技术评审"，不是一蹴而就的事，需要文化的建设。
我见过的从零到有建立技术评审文化的团队，通常经历以下几个阶段：
第一阶段：形式化。先把评审流程固定下来，哪类改动需要评审，评审文档的格式，参会人员的要求。这个阶段的评审质量可能不高，但先把流程跑通。
第二阶段：质量提升。随着团队熟悉了流程，开始关注评审的质量：主持人开始主动提问，参与者开始提出有价值的建议，改进措施开始被真正执行。
第三阶段：内化。评审不再是"必须执行的流程"，而是团队自然认可的工程实践：大家在写设计文档时会主动考虑"这个设计如何向其他人解释清楚"，在评审时会主动提出深度问题，在评审后会主动跟进改进措施。
这个过程通常需要6个月到1年，需要管理者的持续推动和身体力行。