简介：面向IPD产品开发流程的项目经理、产品经理及研发、注册办、质量部等跨部门成员，这份docx文档系统梳理了从Phase0立项到TR6批量试制各评审阶段的关键要素。内容以表格形式逐项列出评审点、对应文档或交付物，并明确资料提供部门与评审负责人。例如TR1概念评审覆盖需求描述、专利评估、法规注册评估、竞争性分析、生产可行性等；TR2规格评审聚焦法律法规与关键设计参数；TR4设计成果评审细化到图纸审核、工装检具确认；TR5样品测试评审则关系到样品检验、测试报告与批量试制启动，逻辑完整。资源仅含1个docx文件，压缩包约29KB，轻量便携，适合作为评审会议准备清单或IPD流程模板。目前已有2374人学习浏览，可帮助团队快速对齐各阶段交付物与责任分工，减少评审遗漏。

1. TR1到TR6评审关口，是产品开发里最容易被做成形式主义的东西

先说一个让我印象深刻的翻车现场。某硬件项目在样机阶段发现设备在高温环境下反复宕机，追查之后才知道，需求文档里从头到尾没有人定义过工作温度范围，原因是最初的评审清单里只写了“需求完整、明确”六个字。评审会开了两小时，没人觉得有问题，最后项目改结构、换材料，硬生生延期三个月。根子不在技术，而在评审要素写得太粗。

TR1到TR6是产品开发里常见的六个技术评审关卡，把产品从概念到量产的过程切成逐级收敛的节点。每个关口想清楚三件事：确认什么、看什么证据、达到什么标准才放行。这篇文章把每个TR阶段的评审要素拉出来拆一遍，讲清单怎么写、怎么用，以及最容易折在哪几个坑。适合正在搭评审流程的研发主管，也适合被评审会折磨过的工程师——看懂它，至少知道该在会上追着要什么证据。

2. TR1-TR6评审体系：六个技术关口各自的定位与输出物

2.1 TR1-TR6在开发流程里的位置

TR是Technical Review的缩写，也就是技术评审。它和DCP（Decision Check Point，决策评审点）是两条线：DCP回答“该不该继续投入”，是商业决策；TR回答“能不能安全进入下一阶段”，是技术把关。在一套完整的软硬结合产品开发流程里，TR1通常在概念阶段结束后触发，TR6在量产放行前触发，中间四个关口按照“需求→设计→样机→验证”的顺序依次排布。

把六个关口放在一条时间线上看，各自的位点就非常清楚：

这套关卡是递进式的。前一个TR不通过，后一个TR可以启动，但遗留风险必须被明确记录并且有处理计划。很多团队把这个原则执行成了“带着问题往下走”，最后所有问题在TR6集中爆发，场面很难看。我的经验是，越早的关口越值得严格，TR1阶段改一个需求偏差的成本，通常不到TR5阶段改同一个偏差的十分之一。这话说起来像套话，但我是看项目翻车之后才真正信服的。

每个TR其实也都有自己的气质。TR1和TR2要拒绝一切“模糊”，需求里不能有说不清的词；TR3要警惕“没有任何风险的方案”，那多半是没把风险挖出来；TR4要核查“没有经过验证的参数”，尤其是新平台上的新数据；TR5要较真“不能复现的缺陷”，不复现的问题等于没解决；TR6要追问“说不清的良率”，良率数字背后必须有产线数据支撑。

2.2 评审要素的核心构成：问题、证据、标准、结论

评审要素说明文档里最容易被误读的是“要素”这个词。要素不是一句口号，更不是评审会的议程标题。一份真正能落地的要素，应该是一个四段式结构：问题描述、证据清单、通过标准、结论记录。

以TR5阶段的“高低温可靠性”为例。问题描述是“确认样机在高温和低温环境下功能是否稳定”；证据清单是“环境试验报告、原始测试记录、失效分析材料”；通过标准是“在-20°C到60°C之间完成100次循环后，整机功能无异常，如有个别异常项，必须提供根因分析和已验证的临时对策”；结论记录是“通过、有条件通过或失败，有条件通过时必须列出遗留问题清单”。

四个构成部分里，证据和标准是灵魂。证据决定评审有没有抓手，标准决定结论有没有客观依据。没有证据的要素，评审人会靠印象打分，同一条要素在不同评审人手里可能得出完全相反的结论；没有标准的要素再长也没用，“性能良好”这类措辞，放到评审台面上几乎没有任何约束力。我见过团队写要素只写“评估可制造性”，结果评审会上每个人对可制造性的理解都不一样，讨论到最后也没有结论。

2.3 评审要素和DCP决策评审的边界

把TR评审要素和DCP决策要素混在一张表里，是很多项目组都会犯的错。DCP要素关心“项目值不值得继续投钱”，典型的问题是市场规模、竞争格局、投资回报周期；TR要素关心“技术方案是否准备好了”，典型的问题是设计验证是否完成、风险是否受控、测试是否充分。两者混合的后果，就是TR会上花大量时间讨论商业价值，真正的技术风险反而没人深入看。

我的做法是准备两份清单，物理隔离。TR会上如果冒出来商业层面的问题，比如“这个市场到底有没有空间”，我会当场记录并转给产品负责人走DCP渠道，不在TR会上展开辩论。把边界划清楚之后，TR会时长至少缩短三分之一，技术细节也因为不被商业话题抢占时间而更可能被认真看。如果你手里的评审要素说明文档里混着商业条目，建议直接标出来剔除，只保留技术属性明确的要素。

3. 把评审要素落成可执行的清单：从解读文档到动手制定

3.1 从产品类型出发，先定评审要素范围

拿到一套评审要素说明文档，第一件事不是逐字读，而是判断这份清单适不适合当前产品。纯软件、纯硬件、软硬结合这三类产品，评审重心差别很大。纯软件在TR3阶段更关注架构演进性，在TR4阶段盯接口契约和数据结构；纯硬件在TR3阶段重点审查结构和热设计，在TR4阶段盯原理图和PCB的可制造性；软硬结合产品最复杂，每个关口都要同时覆盖软硬两条线，还要单独给软硬件接口留出评审空间。

通用模板往往因为要兼容所有产品类型，每条要素都写得比较笼统，直接照搬很容易漏掉关键点。我见过一个做高密度电源模块的项目直接套用公司通用清单，TR3阶段没有人把“热设计”单独列出来，评审通过之后在样机测试时才发现散热严重不达标，不得不重做结构件。后来我在每个阶段评审前都会先做一轮风险识别，列出当前产品最容易出事的几个领域，比如新平台、新工艺、高密度布局、极限环境等，然后把这些领域单独展开成多条具体要素。

同一家公司的不同产品线，评审要素不该完全一样。读评审要素说明文档的正确姿势，是先看它的底层逻辑，再针对当前产品做裁剪和加厚。通用清单在“法规认证”“需求可追溯”这些共性的地方可以用，在“关键路径时序”“特定工况可靠性”这类和产品强相关的地方，必须单独补要素。

3.2 评审要素清单的四个必填字段和一套填写规范

一份能执行的评审要素清单，至少包含四个字段：要素编号、要素描述、评审证据、通过标准。实际使用里我还会加一列“责任人”和“优先级”。要素编号按TR阶段加序号，比如TR4-08，这样评审遗留问题可以直接引用编号，追踪起来毫不费力。

要素描述建议用“确认XXX是否YYY”的句式，但YYY必须具体。“确认系统在最大并发用户数下是否满足响应时间要求”就比“确认系统性能是否达标”要好。评审证据写评审人需要查阅的具体材料，比如“压测报告、测试环境配置、监控采样记录”，不能笼统写“测试报告”。通过标准要满足可测量、可复现、有人负责三个要求。

下面这组对比能直观看出好坏的差别：

优先级字段我建议从一开始就建立。高优先级要素是关口的底线，有一条不满足，整体评审结论就不能是“通过”。中优先级要素允许有条件通过，但必须带处理计划。低优先级要素在时间紧张时可以直接抽查。没有优先级划分的清单，看起来都是重点，实际等于没有重点。

3.3 一份可复用的评审要素模板

下面就以TR5阶段为例，给一份可以直接抄的模板。这个结构同样适用于其他五个TR，改掉描述和标准就行：

提示：一个TR阶段的要素条数控制在10到15条比较合适。如果超过20条，先检查是不是把下一阶段的要素提前挪进来了。关口评审要素讲究“够用”，不是“越多越好”，要素太密集，评审人反而没法逐条看深。

用这套模板时有个细节：每轮评审开始前先发证据清单，让评审专家提前看材料，而不是在会场花半小时翻文件。评审会的时间应该花在核对证据和讨论问题上，而不是花在找材料上。这个习惯能让同样的评审时间产出翻倍的结论质量。

4. TR1到TR6逐关过：各阶段评审要素的关键清单

4.1 TR1和TR2：把需求和规格锁死

TR1阶段的评审要素，核心是“产品定义是否真实、完整、可行”。典型的关键要素有四条：目标用户和主要使用场景是否被明确记录；市场需求是否能追溯到产品概念，是否存在未经证实的核心假设；产品在法规、安全、环保方面有没有需要提前处理的硬约束；当前技术储备和资源条件下，这个概念是否具备可实现性，关键技术缺口是否已经识别出来。

TR2的任务是把需求展开成工程规格，评审要素要细得多。常见检查点包括：每条需求是否拥有唯一编号、来源和负责人；功能需求是否分解到了系统级和子系统级，并且最终落到可以验证的规格参数；每条需求的验收方法和验收标准是否已经定义；需求之间是否存在冲突，发现冲突后是否解决了并且留在记录里。

实操时我习惯用三步快速核验TR2清单。第一步，拿需求清单里的需求数量，去对照已识别的用户场景，看有没有场景没有被任何需求覆盖。第二步，随机抽查20%的需求，看它的验收标准能不能直接拿来设计测试用例——如果抽到好几条都写不出验收方法，这份需求规格就不够扎实。第三步，查变更记录，确认每条需求都能说清楚来源、变更了什么、谁批的。

TR1和TR2还有一个共同的评判原则：不允许出现“笼统表述”。如果评审要素描述里出现“尽量”“基本”“合理”这类词，我会直接要求改写。需求和规格是后面所有设计工作的输入，输入是模糊的，输出必然走偏。这两关把得严，后面TR3到TR6的评审才会顺。

4.2 TR3和TR4：把方案和设计钉牢

TR3评审的是总体技术方案，要素集中在架构可行性和风险控制上。关键要素包括：系统架构是否满足全部功能和非功能规格；关键技术选型是否有验证数据支撑，有没有备选方案；技术风险清单是否完整，高风险项有没有具体的规避策略；软硬件接口定义是否受控，接口文档是否是最新版本并且发给了所有相关方。

TR4是详细设计评审，要素要下沉到模块级别。硬件部分要看：原理图设计是否遵守设计规则，关键信号上有没有计算和仿真支撑；PCB布局布线是否满足信号完整性和电磁兼容要求。软件部分要看：每个模块是否按照接口设计完成实现，单元测试覆盖率是否达到项目设定阈值。供应链部分要看：BOM是否经过可采购性核查，关键物料有没有合格的替代供应商。

很多团队在TR4阶段只盯“功能对不对”，忽略“能不能量产”，这是比较大的隐患。我建议在TR4的评审证据里单独放一份可制造性检查表，由结构和工艺人员逐条确认后再签字。TR4是量产前最后一个修改成本可控的关口，拖到TR5再改设计，往往要动模具或者动产线，成本完全不是一个量级。

在评审现场，TR4容易被以下几类表面现象带偏：一是原理图和PCB贴图很多，但没有计算书和仿真报告支撑；二是软件代码量很大，但单元测试结果拿不出来；三是BOM表一长串，但关键器件的生命周期状态没人确认过。评审要素清单里必须有对应的条目把这几件事锁住。

4.3 TR5和TR6：把验证和量产确认完

TR5的评审要素围绕“样机是否满足规格、问题是否闭环”。核心要素包括：功能测试和性能测试的用例通过率是否达到计划设定值；测试覆盖矩阵是否完整，未执行的用例是否有明确原因和评估记录；缺陷清单是否按严重程度分级，阻断性问题是否有解决方案和已验证的修复记录；可靠性测试是否完成，高低温、湿度、振动、寿命等条件下的结论是否明确；剩余风险是否有明确的接受记录和接受人。

TR6是量产放行前的最后一关，要素的关注点要从“设计行不行”转向“产线能不能行”。需要确认的要素包括：试产中暴露的可制造性问题是否完成改善并验证；整机良率与直通率是否达到设定阈值，低良率项有没有根因分析；供应商是否完成量产前审核，关键物料的产能能否支撑交付计划；认证报告、合规文档、使用说明书是否齐全；售后维修和备件策略是否已经定义完毕。

这里要特别强调一个观点：TR6的通过标准不是“零问题”，而是“已知问题全部有应对，剩余风险全部有记录”。我看到过不少项目卡在TR6放不了行，原因是负责人追求完美，想把所有小问题都清零。实际上对于量产环节，更关键的是确认每个问题都有明确的影响评估和处置决策，具体是否在发布前解决，要按问题的严重程度来定。这个原则应该写进TR6的评审要素里。

我在每个TR评审通知里都会附带一份“证据包清单”，提前告诉所有评审专家要准备哪些材料，避免现场临时翻找。以TR5为例，证据包至少包含：按模块分类的测试报告、缺陷管理系统导出的缺陷清单、环境试验原始记录、覆盖矩阵表格、以及上一次评审遗留问题的处理记录。这个习惯让评审会从“听PPT讲故事”真正变成“对着材料查问题”，效率完全不一样。

5. TR评审避坑指南：五个让评审流于形式的常见问题

5.1 评审要素写得太粗，评审会变成聊天会

现象：清单里的要素描述停留在“确认需求是否合理”“评估设计是否符合要求”这种层面。评审会上大家凭印象发言，会议开了两小时，最后结论只有一句“基本没问题，建议修改部分细节”。

原因：“合理”“符合要求”这类词不可证伪，评审人的判断只能依赖个人经验和当时的状态，要素之间没有形成可核对的具体抓手。

解决：强制要求每条要素至少包含证据和标准两个字段，标准写成可验证的具体条件。例如把“评估设计是否符合要求”改成“确认电源模块输出电压纹波在满载条件下不超过50mV，依据是实测波形记录”，评审时就有了具体的东西可以核对。

5.2 通用要素直接套用，高风险点漏评

现象：公司里有一套通用的TR评审要素模板，每个项目直接照搬，不根据产品特征做任何裁剪。评审会开得很顺，但产品在新引入的环节出了问题之后，回头看评审清单，恰恰没有覆盖这个环节。

原因：通用清单是按大多数产品的平均水平设计的，而新平台、新工艺、新算法这类“新”的东西，才是最容易出问题的地方，也最容易被通用清单漏掉。

解决：每次TR评审之前先做一轮风险识别，把高风险的领域单独列出来，确保这些风险在对应TR阶段都有评审要素对应。风险识别发现清单覆盖不到的地方，必须当场补要素，不要等评审会开完再补。

5.3 评审结论没有闭环，遗留问题无人跟进

现象：TR2评审发现3个遗留问题需要进一步研究，会议纪要里记了问题，但责任人和截止时间没写。三个月后项目走到TR4，回头一看，这3个问题还躺在那儿没人处理。

原因：评审会只关注“发现”问题，没有关注“推动”问题。结论记录里没有问题台账，也没有一个明确的角色负责跟踪到底。

解决：每次评审的结论记录必须附带一份遗留问题清单。每项问题写清楚责任人和计划完成日期，有条件通过的结论还要明确复查时间和复查方式。这个动作花不了五分钟，却是评审能不能闭环的关键。

5.4 评审参与人不对，技术评审变成项目汇报

现象：评审会上研发团队花一个多小时对着PPT讲进度、讲成果，评审专家基本没有机会看到原始设计文档和测试数据，只能听汇报做判断。

原因：评审流程没有约束信息的呈现方式，项目组习惯用漂亮的PPT汇报，很少把原始证据直接放到评审台面上。

解决：评审通知里直接附上证据清单，要求专家提前阅读必要材料，评审会开场只给十分钟串讲，剩下的时间逐条核对证据、讨论问题。有条件的话，把样机操作和测试演示安排进评审环节。评审会应该是检查现场，不是汇报现场。

5.5 评审要素清单不更新，用了三代产品还是老的

现象：团队里有一套从某次咨询项目中沉淀出来的评审要素，产品迭代到第三代，清单还是第一版的内容。新技术引入之后，对应的评审要素完全没有覆盖，问题到研发后期才暴露出来。

原因：评审要素被视为一次性资产，评审一通过就归档，没有人把它当作活文档去维护。每个项目的经验教训没有回流到清单里。

解决：养成每次TR评审结束后三天内修订清单的习惯。看看哪些要素没起作用，哪些要素需要补充条件，哪些新问题应该沉淀成新的要素。把清单放进版本管理里，每次修订留记录，这套清单才会随着项目变聪明。

6. 让TR评审产生价值的两个习惯：风险阈值和要素复盘

6.1 给评审要素设风险等级与通过阈值

评审要素从来不是平等的。我习惯在每个TR阶段开始前，给清单里的每条要素标上高、中、低风险等级。高风险要素是关口的命门，有一条不通过，该TR直接判定为不通过；中风险要素允许有条件通过，但遗留项必须有处理方案；低风险要素只抽查，节省评审精力。

曾经有一回，我把某个TR3阶段的所有要素都标成了中等优先级，结果评审时没有重点，每项都平均用力。后来在TR4阶段发现系统架构里的一个关键缺陷，差点让整个项目返工。从那以后，我坚持在评审会开始前拉出一份高风险要素清单，逐条过一遍再进场，这个习惯救过我很多次。

6.2 每轮评审之后做要素复盘，把教训放回清单

另一个让我长期受益的习惯是要素复盘。每次TR评审结束后，我都会抽出半小时，把这次评审中发现的问题、讨论最久的话题、以及那些“要是提前有人问一句就好了”的环节，逐一对照回要素清单。

具体做法是在复盘表里记三样东西：这次评审新发现了什么问题；是哪一条要素本该抓到但没抓到；下次评审的清单应该新增或修改哪一条要素。动作很小，但坚持做下来，清单会越来越有针对性和颗粒度，评审的拦截效率明显提升。我把这当作战时最重要的资产来维护，因为真正有价值的不是那份制度文档，而是每一轮评审里验证过的问题与标准。一个工程师能从评审里学到多少，往往就看他愿不愿意做这件事。希望你也能用得上这套方法，把TR评审做成真正拦得住风险的一道闸门。

本文还有配套的精品资源，点击获取