评审角色与职责：架构师、评审员、记录员、决策者的职责划分
说到评审，很多人第一反应就是「一群人坐在一起挑毛病」。其实没那么简单。我在几个项目里都见过评审会开成批斗会，或者变成走过场。为什么会这样？说白了，就是角色没分清楚。
今天咱们就聊聊评审会上四个关键角色：架构师、评审员、记录员、决策者。每个人该干什么，不该干什么，我踩过的坑也一并分享给你。
架构师：你是被评审的对象，不是辩护律师
架构师这个角色，我见过两种极端。一种是「我的设计就是最好的，你们别BB」，另一种是「你们说改哪我就改哪」。嗯，这两种都不对。
架构师的核心职责是呈现设计思路，而不是捍卫设计。我个人习惯在评审前先做一件事：把设计文档里的「为什么」写清楚。比如为什么选这个通信协议，为什么用这种分区方式。你想想看，如果评审员连你的设计初衷都不清楚，他怎么给你提有价值的意见？
架构师在评审中的具体职责：
- 准备评审材料：架构文档、设计图、关键决策记录
- 清晰阐述设计思路和约束条件
- 记录评审中提出的问题和建议
- 对合理的意见给出改进承诺
- 对不合理的意见给出专业解释
我曾经犯过的错：有一次评审会上，我花了半小时跟评审员争论一个接口设计。后来发现人家说的确实有道理，但我面子上挂不住，硬是没改。结果项目后期那个接口成了最大的瓶颈。从那以后我学乖了——评审会上，面子是最不值钱的东西。
评审员：你不是来找茬的，是来帮忙的
评审员这个角色，很多人理解成「找bug的」。其实不对。评审员的核心价值是提供不同视角的洞察。你想想看，架构师一个人做设计，难免有盲区。评审员就是来补这些盲区的。
我建议评审员在评审前做三件事：
- 通读文档：至少花半小时看一遍架构文档
- 标记疑问：把看不懂、觉得不合理的地方标出来
- 准备建议：不只是提问题，最好带上解决方案的思路
评审会上，评审员要避免两种行为：一是「我觉得这样不好，但我也说不出哪里不好」，二是「你这个设计完全错了，应该按我的来」。说白了，评审不是让你来展示自己有多牛的。
我的一个小技巧：评审时我会用「我有个疑问」代替「你这里错了」。比如「我有个疑问，这个模块的故障响应时间为什么设成100ms？是不是考虑过更严格的场景？」这样既表达了问题，又不会让对方产生防御心理。
记录员：别小看这个角色，它决定了评审的成败
很多人觉得记录员就是打字员，随便找个人记记就行了。我告诉你，这是大错特错。记录员做得好不好，直接决定了评审结论能不能落地。
记录员的核心职责是把讨论转化为可执行的行动项。不是记流水账，而是提炼出关键信息。
| 记录内容 | 好的记录 | 差的记录 |
|---|---|---|
| 问题描述 | 模块A的故障处理流程缺少超时机制 | 模块A有问题 |
| 建议方案 | 建议增加超时计数器，超时后触发安全状态 | 建议改一下 |
| 责任人 | 张三负责修改，李四负责复核 | 相关人员跟进 |
| 截止时间 | 下周三下班前完成修改 | 尽快 |
我个人习惯用模板来记录，这样不会漏项。模板里至少包含：问题编号、问题描述、建议方案、责任人、截止时间、状态。嗯，这个模板我用了好几年，确实好用。
决策者：你是最后拍板的人，不是来旁听的
决策者这个角色，我见过最典型的错误就是「我来听听大家的意见」。拜托，你是来拍板的，不是来听报告的。如果所有问题都要讨论到所有人都同意才做决定，那评审会开三天都开不完。
决策者的核心职责是在有限时间内做出最优决策。注意我说的是「最优」不是「完美」。在汽车软件架构设计中，很多时候没有完美的方案，只有权衡后的最优解。
决策者需要做的三件事：
- 设定评审边界：明确哪些问题必须讨论，哪些可以会后处理
- 控制评审节奏：当讨论陷入细节时及时拉回主线
- 做出最终裁决：对争议性问题给出明确结论
我曾经踩过的坑：有一次评审会上，两个评审员对一个接口设计争论了四十分钟。我当时作为决策者，觉得让他们充分讨论是好事。结果呢？评审会超时一小时，其他问题都没来得及讨论。后来我学到一个原则：如果一个问题讨论超过十分钟还没有结论，决策者就要介入，要么给出方向，要么搁置到会后专题讨论。
四个角色的协作关系
这四个角色不是孤立的，他们之间有一个清晰的协作流程。我画个简单的图给你看：
架构师呈现设计 → 评审员提出意见 → 记录员记录要点 → 决策者给出结论
↑ |
└────────────────── 闭环反馈 ──────────────────────────┘说白了，这是一个输入-处理-输出的过程。架构师是输入方，评审员是处理方，记录员是输出方，决策者是控制方。任何一个环节出问题，评审效果都会打折扣。
我记得有一次评审，架构师讲得特别好，评审员提的问题也很有价值，但记录员记了一堆废话，关键决策点全漏了。结果会后大家各说各话，谁都不记得当时到底达成了什么共识。从那以后，我每次评审都会专门指定一个有经验的记录员。
避坑指南
最后，我总结几个常见的坑，你评审时注意避开：
- 角色混用：一个人同时担任评审员和决策者，容易导致一言堂
- 角色缺失：没有明确的记录员，评审结论无法落地
- 角色越界：评审员试图替决策者做决定，或者架构师试图替评审员回答问题
- 角色懈怠：决策者不参与讨论，评审员不提前看文档
我的建议：评审开始前，花两分钟明确每个人的角色和职责。别觉得这是浪费时间，这恰恰是保证评审效率的关键。我曾经在一个项目里试过，效果立竿见影——评审时间缩短了30%，结论落地率提高了50%。
好了，关于评审角色与职责，今天就聊到这儿。记住一句话：角色清晰，评审高效；角色混乱，评审白干。下次评审前，先问问自己：我今天的角色是什么？我该做什么？不该做什么？想清楚了再开始。