3. 评审准备：如何定义评审范围、选择评审团队、准备评审检查单

好，咱们进入正题。评审准备做得好，评审就成功了一半。这话不是我说的，是吃了好几次亏之后悟出来的。今天聊聊怎么把准备工作做扎实。

3.1 定义评审范围：别贪多，嚼不烂

很多团队一上来就想把整个架构文档从头到尾审一遍。结果呢？三个小时过去了，连第一章都没看完。大家累得不行，关键问题一个没抓住。

我个人习惯，先问三个问题：

• 这次评审的核心目标是什么？是验证功能安全？还是确认接口一致性？
• 哪些模块风险最高？新开发的？还是变更频繁的？
• 时间预算有多少？两小时？半天？

举个例子。我在做ADAS域控制器项目时，架构文档有200多页。如果全审，一周都不够。我们只聚焦了三块：感知融合模块的接口定义、功能安全ASIL D的分解策略、以及供电架构的冗余设计。其他部分走快速浏览，有问题单独提。

3.2 选择评审团队：找对的人，而不是找所有人

评审团队不是人越多越好。你想想看，一个会议室坐十几个人，真正能发言的就那么三四个。其他人要么刷手机，要么打哈欠。

我建议，评审团队控制在5-7人。核心角色包括：

角色	职责	人数建议
架构师（作者）	讲解设计思路，回答问题	1-2人
领域专家	从专业角度挑毛病（比如功能安全、通信协议）	1-2人
测试代表	从可测试性角度提要求	1人
项目经理	把控进度和资源	1人
独立评审员	保持客观，不受项目压力影响	1人

避坑指南： 我曾经犯过一个错——把客户代表也拉进评审会。结果客户对技术细节不熟悉，问了一堆无关紧要的问题，浪费了半小时。后来我学乖了，客户的意见单独收集，不在技术评审会上讨论。

3.3 准备评审检查单：把经验变成清单

检查单这东西，说白了就是把踩过的坑变成文字。我每次做完一个项目，都会更新检查单。久而久之，它就成了团队的“避坑宝典”。

下面是我常用的架构评审检查单模板，你可以直接拿来用：

# 架构评审检查单（示例）

## 1. 功能架构
- [ ] 所有功能需求是否都有对应的架构元素？
- [ ] 功能之间的依赖关系是否清晰？
- [ ] 是否存在冗余或缺失的功能模块？

## 2. 软件架构
- [ ] 模块划分是否遵循高内聚、低耦合原则？
- [ ] 接口定义是否完整（包括数据类型、范围、时序）？
- [ ] 是否存在循环依赖？

## 3. 硬件架构
- [ ] 处理器选型是否满足性能要求？
- [ ] 内存和存储容量是否留有裕量？
- [ ] 供电和散热方案是否合理？

## 4. 功能安全
- [ ] ASIL等级分配是否合理？
- [ ] 安全机制是否覆盖了所有故障模式？
- [ ] 安全状态定义是否明确？

## 5. 通信架构
- [ ] 网络拓扑是否满足延迟要求？
- [ ] 总线负载率是否在安全范围内？
- [ ] 信号周期和抖动是否满足控制需求？

3.4 评审前的最后一步：预审

嗯，这里要注意。正式评审前，我强烈建议做一次预审。把文档提前2-3天发给评审员，让他们自己先看一遍。

为什么？因为正式评审会上，没人愿意花时间读文档。大家应该直接讨论问题。预审阶段，评审员可以标注出疑问点，正式会上直接开聊。

我曾经遇到过一个项目，预审时发现架构文档里有个严重的时序冲突。如果直接开正式评审会，大家现场读文档，至少得花半小时才能发现这个问题。预审帮我们省了半小时，也避免了正式会上的尴尬。

3.5 总结一下

评审准备，说白了就是三件事：

1. 定范围——聚焦高风险、高价值的部分
2. 选对人——5-7个关键角色，别搞成“群众大会”
3. 备清单——把经验变成可执行的检查项

准备工作做到位，评审会就能高效推进。下一章咱们聊聊评审过程中的引导技巧——怎么让评审员开口说话，怎么控制节奏。到时候见。