3. 评审流程与角色定义：评审发起人、评审专家、记录员、决策者的职责与协作模式
文档评审不是走过场。我见过太多团队把评审会开成「批斗会」或者「沉默大会」——要么大家互相甩锅，要么全程没人说话。说白了，问题出在角色没定义清楚。
今天咱们就把评审流程拆开揉碎，看看每个角色到底该干什么、不该干什么。
3.1 评审的四个核心角色
一个完整的评审团队，需要四类角色。少一个，评审就容易跑偏。
| 角色 | 核心职责 | 典型人选 |
|---|---|---|
| 评审发起人 | 提交文档、组织会议、跟踪闭环 | 文档作者 / 模块负责人 |
| 评审专家 | 审查内容、发现问题、提出建议 | 相关领域资深工程师 |
| 记录员 | 记录问题、跟踪决议、归档结论 | 项目助理 / 轮值工程师 |
| 决策者 | 裁决争议、批准发布、把控质量 | 架构师 / 技术经理 |
关键原则：发起人和决策者不能是同一个人。这是为了制衡——写文档的人自己拍板，很容易放过问题。
3.2 评审发起人：文档的「项目经理」
发起人通常是写文档的那个人。但很多人以为写完文档就完事了，其实评审阶段的工作量一点不比写文档少。
发起人的具体职责：
- 准备评审包：文档正文、相关参考材料、评审 checklist、上次评审遗留问题清单
- 选择评审专家：根据文档内容，邀请 3-5 位相关领域的专家。人太少容易漏问题，人太多会议效率低
- 发送预审材料：至少提前 2 个工作日发出，给专家留足阅读时间。我习惯在邮件里标注「重点审查章节」，帮专家快速聚焦
- 主持评审会议：控制节奏，确保每个议题都有结论，避免跑题
- 跟踪问题闭环：会后整理问题列表，推动修改，确认所有问题都关闭后才能进入下一阶段
我的经验：发起人最好在评审前做一次「自检」。我曾经提交了一份接口文档，结果评审会上被专家发现时序图里的信号名和代码不一致——这种低级错误特别影响信任感。后来我养成了习惯：发出去之前，自己先按 checklist 过一遍。
3.3 评审专家：文档的「质检员」
评审专家是评审质量的核心。但很多专家把评审当成「找茬」，这其实是个误区。
评审专家的正确姿势：
- 预审先行：拿到文档后先通读一遍，标记疑问点和潜在问题。不要等到会上才看
- 关注「为什么」：不只是看技术细节对不对，更要看设计决策是否合理。比如「为什么选这个 MCU？」「为什么用这个通信协议？」
- 区分「硬伤」和「建议」：硬伤（比如时序错误、资源冲突）必须改；建议（比如换个写法更清晰）可以讨论
- 给出具体意见：不要说「这里有问题」，要说「第 3.2 节的时序约束不满足 setup time，建议把时钟频率降到 50MHz」
避坑指南：我曾经遇到一位专家，每次评审都提 50 多个问题，但一半都是「我觉得这个变量名不好看」之类的风格问题。结果评审会开了 4 小时，真正有价值的问题反而没时间讨论。记住：评审专家的精力是稀缺资源，要花在刀刃上。
3.4 记录员：评审的「活历史」
记录员这个角色最容易被忽视。很多人觉得「记个会议纪要而已，谁都能干」。但记录员做得好不好，直接决定评审结论能不能落地。
记录员的核心工作：
- 实时记录问题：每个问题都要记清楚「问题描述」「提出人」「涉及章节」「严重等级」
- 记录决议：每个问题的处理结论——是「修改」「讨论后定」还是「驳回」
- 跟踪状态：会后更新问题状态（待处理 / 处理中 / 已关闭），直到所有问题闭环
- 归档评审记录：评审记录是项目资产，后续追溯、审计都要靠它
我推荐用表格来记录，结构清晰，方便追踪：
| 编号 | 问题描述 | 提出人 | 涉及章节 | 严重等级 | 决议 | 状态 |
|---|---|---|---|---|---|---|
| #001 | SPI 时钟极性配置与从机不匹配 | 张工 | 3.2.1 | 严重 | 修改为 CPOL=1 | 已关闭 |
| #002 | 内存占用估算未考虑 DMA 缓冲区 | 李工 | 4.1 | 中等 | 补充 DMA 缓冲区计算 | 处理中 |
| #003 | 建议增加看门狗复位后的恢复流程 | 王工 | 5.3 | 建议 | 讨论后采纳 | 待处理 |
3.5 决策者：评审的「最终拍板人」
决策者通常是架构师或技术经理。这个角色不需要参与每个细节的讨论，但要在关键分歧上做裁决。
决策者的职责边界：
- 把控评审节奏：当讨论陷入僵局时，及时叫停，给出方向性意见
- 裁决争议：专家之间意见不一致时，决策者根据项目整体目标做最终决定
- 批准发布：确认所有「严重」和「中等」问题都已关闭后，签字批准文档发布
- 承担质量责任：决策者要对评审结果负责。如果文档发布后出了大问题，决策者要承担管理责任
重要提醒：决策者不要过早表态。我见过一些架构师，专家还没发言自己先拍板了，结果其他人都不敢再提意见。决策者的正确做法是：先听，再问，最后拍。
3.6 评审流程：从提交到闭环
流程不复杂，但每一步都不能省。我把它总结成 6 个步骤：
- 提交预审：发起人提交评审包，专家在 2 个工作日内完成预审
- 召开评审会：发起人主持，记录员记录，专家逐条讨论问题
- 形成问题列表：记录员整理所有问题，标注严重等级和决议
- 修改文档：发起人根据决议修改文档，关闭已处理的问题
- 复审确认：决策者或指定专家确认修改是否到位
- 批准发布：决策者签字，文档进入受控状态
嗯，这里要注意：复审不是必须的。如果问题都是「建议」级别的，发起人改完直接给决策者确认就行。但如果涉及「严重」问题，最好让提出问题的专家再确认一次。
3.7 协作模式：四个角色如何配合
角色定义清楚了，协作模式就顺理成章。我画了一张图，把整个协作关系展示出来：
3.8 常见协作问题与应对
理论说完了，聊聊实战中经常踩的坑。
| 问题 | 表现 | 应对方法 |
|---|---|---|
| 角色重叠 | 发起人同时当决策者，自己写自己批 | 强制分离，架构师不能评审自己写的文档 |
| 专家不预审 | 会上才看文档，效率极低 | 发起人提前 2 天发材料，会上先问「预审了没」 |
| 记录员漏记 | 会后发现重要问题没记录 | 使用标准化模板，逐条确认 |
| 决策者过早表态 | 专家不敢提反对意见 | 决策者最后发言，先听专家意见 |
| 问题跟踪不到位 | 修改后没人确认，问题悄悄消失 | 记录员定期跟踪，决策者确认关闭 |
我的习惯：每次评审结束后，我会让记录员在 24 小时内发出评审纪要，包含问题列表和责任人。然后每周跟踪一次状态，直到所有问题关闭。这样做的好处是——出了问题有据可查，不会出现「我记得当时说了要改」这种扯皮情况。