前四篇把"谁来评、评什么、在哪评、怎么走"讲完了。一场评审跑完，到底留下什么？这篇把评审的三份核心记录——评审任务、问题清单、评审报告——摊开讲清楚：它们是什么关系、各自要管住哪些要素、怎么在数字化工具里跑完整个生命周期。文末是本篇的核心交付：评审全流程分阶段清单，从创建评审任务到报告产出，每个环节要准备什么、产出什么、用什么工具，一次查清。

一、先立数字化前提：文档是数据，不是纸张

写这篇之前，先交代两个前提，也是我们编制规范时的两个立场：

第一，管理要素与工具解耦。 这篇只讲"管理需要哪些必要属性、要向工具提什么要求"，不绑定任何具体工具、不写字段怎么配置：用哪家的项目/问题管理平台都能落地，换工具不换思路。

第二，数字化质量管理的三个"取消"。 在数字化背景下，我们默认：

• 取消纸质报告：签名与签核由工具内的状态流转记录承担，不再打印、不再签字；
• 取消手动发邮件：材料分发、评审提醒、逾期升级全部由系统自动通知（消息/邮件由系统代发，不靠人手动转抄）；
• 取消电子表格流转：检查表、问题清单、统计报表全部由工具维护——**不是取消"表"，而是取消"Excel 传来传去"**。检查表作为组织资产在工具里版本化维护，人人都看同一张，谁也别再私藏一份"最新的"。

一句话：文档是数据，不是纸张。 评审记录全部结构化地活在工具里，任何人任何时候打开，看到的都是同一个真相。

二、先摆账本：三份记录，一个模型

一场评审跑完，我要求留下三份东西——但在数字化视角下，它们不是三份独立文档，而是同一数据模型的三张视图：

图 1｜三份记录一个模型：评审任务是容器，问题是明细，报告是聚合

• 评审任务 = 容器（档案袋）：一次评审的全部背景信息，评审任务定义了 20 个评审要素；
• Issue Log = 明细（一条一档）：评审中发现的问题，每个问题一条记录，定义了14 个字段；
• Review Report = 结论（聚合页）：任务字段 + 问题统计聚合而成的评审决定页，5 组字段。

三份记录回答三个不同的问题：

三者之间有一条数据血缘：任务下挂 N 条问题（哪怕 0 问题也要建一个空关联），报告由任务字段与问题统计自动聚合生成。

记住一句话：报告不是"写"出来的，是"长"出来的。 评审记录全部结构化之后，报告只是系统按模板做的一次汇总——这就是"文档是数据"的直接推论。

三、评审任务：一次评审的档案袋

我们在规范中定义了20个评审要素，除了管理评审任务本身，也为后续评审绩效评估打基础。这20个要素按管理目可归成五组：

三处特意要备注的"易混点"：

1. 迭代评审 ≠ Re-reviewed。同一评审对象升版之后再评，是"迭代评审"，必须重新提交评审任务（拿新的评审ID）；Re-review 是本次评审结论为 Reworked and re-reviewed 之后的复评。
2. 0 问题也要建一个空关联。我在规范里特意写了这句："哪怕是0问题也要建一个空关联，供PQA审计"。评审任务必须关联问题清单——这是 PQA 审计"这场评审真的评过了"的抓手，空关联也是证据。
3. SC/PR 不设记录员。自查和同行评审的问题记录由工具流承载；WT/TR 由主持人指定记录员；MR 默认项目经理。

• Planned → In-Review → Reported → Closed /Canceled /Waived；
• Closed 的前置条件：评审结论为 Used as is / Updated and used，且关联问题全部关闭——这条联动由系统校验，问题没关完，任务就关不掉；
• Waived：Critical 问题全部关闭，未关闭的 Major/Minor 经签核确认可 Waive，并指定预期完成时间；
• Canceled：经领域技术负责人和研发负责人签核确认。

四、Issue Log：问题的 14 个字段，一条一档

问题清单是评审体系里信息密度最高的记录。我们给每个问题定了 14 个字段，按"谁提的、谁改的、怎么判的"分成三组：

有三个细节需要注意：

第一，字段是分阶段填的，不是提交瞬间填完的。 "问题严重度、问题状态、问题责任人一般在【问题沟通与分析】活动阶段完成，而其余信息通常在【个人评审】活动阶段完成。"——个人评审阶段只记"发现了什么"，沟通与分析阶段记录"接不接受、谁负责"。把填字段的时机和流程对齐，工程师就不会觉得表单是负担。

第二，严重程度三档对应三档处置节奏：Critical 确认后 3 个工作日内整改、阶段准出前必须关闭；Major 10 个工作日内关闭或形成处置方案；Minor 记录备查、下版本处理。这样系统能自动排优先级、自动升级。

第三，状态机加自动化点（图 2 右半）：

• Open →Accepted →Resolved →Closed；Open → Rejected/ Waived；Open → Accepted → Waived；
• 关闭日期：状态置 Closed 时系统自动填写，不手填；
• 问题确认人：默认为问题提出人——谁提的谁验，天然形成闭环责任；
• 逾期升级：预期完成日期 + 严重程度触发提醒，连续 2 次逾期自动升级至研发负责人——升级不靠人催，靠系统。

注3：个人建议问题字段要尽量用客观属性，少用主观分类。"问题所属模块"是客观的（有 owner、有边界），可以放心保留；而"缺陷类型"这类主观多维的枚举（接口/功耗/时序？），看着很专业，但不同工程师判断不一致，填出来的枚举是噪声不是数据——如果实在想要，可以让工程师挂"哪条检查项没过"，类型标签从检查表元数据继承，或者事后由 PQA 批量标注，别逼工程师在建单瞬间做主观判断。

五、Review Report：不是写出来的，是长出来的

如果不是车规功能安全产品审核需要，因内部质量监控而让研发工程师专门生成一份评审报告，那估计我们质量同仁会被吐槽惨了。规范定义Review Report主要目的是让内外部审计达成共识，确保流程闭环。

数字化落地就是一句话：报告 = 任务字段 + 问题清单聚合，系统自动生成，主持人只"确认"不"写"。

注4：这是工作产品的评审报告。里程碑评审会生成正式报告，走公司系统流程闭环。

六、核心交付：评审全流程，分阶段清单

这是本篇的核心交付。先说明三点：

• 分段方式：按管理动作，把一次评审分成五个阶段——创建评审任务、评审准备、评审执行、问题整理、报告产出。
• 呈现方式：一张 20 行大表在手机上没法读，所以按阶段拆成五张小清单，每张只看一个阶段；想查某个环节，直接跳到对应阶段。
• 工具列：只写工具类别，不绑定任何厂商——不同公司用不同工具实现同一管理要求。

① 创建评审任务：评审策划在这里完成

一次评审的质量，一半在创建任务时就定了。研发负责人/领域负责人在项目评审策划时，就要明确这张评审任务的六项基本信息：

工作产品名称及版本 · 评审类型 · 评审日期 · 评审者名单 · 评审目的 · 关注区域

这六项填完，19 个评审要素里最关键的"范围组"就有了。随后系统建档、指定角色、挂接检查表：

这一阶段的要点：迭代评审（对象升版本再评）必须重新建单、生成新评审ID；检查表在计划阶段商定，挂的是主检查表的投影，不是临时拼的表；评审人按视角切片或"接口使用方"原则分派。

② 评审准备：自查、分发、预审

任务建好，进入作者的"交卷"阶段——输出工作产品、完成自查，然后才是分发与预评审：

这一阶段的要点：门禁不过不准提交；时效是硬约束——PR 即时，WT 提前 1 工作日、TR 提前 2 工作日、MR 提前 5 工作日；大多数问题应该在预评审阶段被发现，而不是会上——这也是把预审放在"准备"阶段的原因：开会前问题沟通得越充分，评审会议就越高效。TR 明确要求作者提前反馈/沟通预审问题，避免会议现场"第一次听说"。

③ 评审执行：认定问题、做出决定

这一阶段的要点：WT 走查会/TR 评审会/MR 里程碑会，SC/PR 不开会（PR 靠异步反馈）；每个问题现场认定 Accepted/ Rejected/ Waived，严重度由主持人确认；PR 出现实质分歧 → 升级 WT/TR，无法处置 → Re-review。

④ 问题整理：闭环在这里驱动

这一阶段的要点：会后 1 个工作日内出正式问题清单；预期完成日期须在评审会议上达成一致；Critical 3 工作日 / Major 10 工作日，逾期自动升级（连续 2 次 → 研发负责人）；Critical 原则上不接受例外，未关闭C例外(Critical &Major)须在里程碑评审显式披露。

⑤ 报告产出：聚合、终态、回流

这一阶段的要点：Closed 的前置“关联问题全部关闭”；Waived/Canceled 需双负责人签核记录；M5 逃逸缺陷回流主检查表（升版），下轮评审自动继承——这是整套体系"越用越准"的闭环。

贯穿五个阶段的三条线索

1. 纵向看是流水线，横向看是数据流。 每一行的输出就是下一行的输入——全流程的输入源头只有四类：工作产品、检查表、基线规格、问题记录。找不到输入来源的任务，就是流程里的"凭空产生"，该砍。
2. 评审管理工具贯穿全程，是唯一的"必须在线"环节。 其他工具（配置管理、开发验证工具链、会议、报表）都可以自由组合，但评审任务、问题清单、评审报告三样东西必须在一个系统里闭环——这正是"文档是数据"对工具的硬性要求。
3. 自动化节点一共七处：任务建档自动编号、门禁结果自动带入、材料自动分发、逾期自动升级、关闭日期自动填写、报告自动聚合、状态联动校验。人只做判断，不做事务——凡是机器能干的，别让人干。

七、下期预告：评审好不好，要算账

账本立起来了，下一个问题：怎么证明这套评审体系真的在起作用？ 第 6 篇讲评审问题闭环与有效性度量：Critical/ Major/ Minor 分级怎么定处置优先级、Closed/ Waived/ Canceled 三态怎么防"问题库变垃圾场"、M1–M7 七个绩效指标怎么算账——那是把评审从"管理动作"变成"可度量资产"的一篇。我们下期见。

系列规划：① 角色定位与 V 模型框架 ② 基于工作产品类型的评审方式选择 ③ 里程碑评审怎么开 ④ 评审流程五步走 ⑤ 从评审任务到评审报告（本篇） ⑥ 评审问题闭环与有效性度量（弹性） ⑦ 常见踩坑与裁剪建议（弹性）