简介：面向产品研发、项目管理及IPD流程落地人员的评审要素参考文档，聚焦集成产品开发中DCP与TR各阶段“评什么、看哪些交付物、由谁提供和负责”的问题。资源包内含1个docx文件，约33KB，以表格化清单组织，便于直接查阅并裁剪为团队模板。内容覆盖Phase0-1至Phase0-13的项目立项、任命书、原始需求、技术概念、法规注册、市场分析、技术/生产可行性、风险管理、概念与规格及总体方案评审，并延伸至TR1～TR6、概念评审、计划评审和发布评审。每项要素对应相关文档或交付物、资料提供部门及评审负责人，可帮助读者建立阶段门评审检查表，统一研发、注册、质量、产品与财务等角色的评审口径，也可用于内训和流程审计。已有2700人学习。

1. 一张评审地图：IPD 的八十多条查核要点是怎么串起来的

IPD 集成产品开发里最容易背混的，是把“阶段”和“评审点”当成同一条线。把这份各阶段评审要素说明摊开，其实是三条线拧在一起：Phase 0 到 Phase 3 是时间轴，TR1 到 TR6 是技术评审卡点，概念评审、计划评审、发布评审这三场 DCP 是投资决策卡点。每一条查核要点后面都挂着三样东西——对应的文档或交付物、资料提供部门、资料评审负责人。所以真正要记的不是编号，而是“哪一关、看什么、谁交、谁判”这个四元组。适合已经上手带项目、却被评审表压得抬不起头的人，拿它当一张自查地图。

2. TR 六道门槛：从概念到量产的查核要点与交付物

2.1 每个 TR 的通用骨架：交付物打底，要素提问，记录收口

把 TR1 到 TR6 并排看，会发现它们长着同一副骨架。左边是一个 Phase 编号，指向一份或多份具体交付物，比如 Phase0-3 对应原始需求报告、Phase2-19 对应图纸；中间是一串查核要点，也就是评审要素表里的“查核要点”列；右边是评审结论与评审记录。

评审当天的动作顺序是固定的：提供部门先把交付物交上来，评审负责人对着要素逐条问，问完留下评审记录和遗留问题清单，再决定放行、有条件放行还是打回。要素本身不产生结论，要素只是把“你觉得这个方案行不行”这种主观判断，拆成一条条能回答是或否的问题。

这里有个很容易被忽略的结构特征：同一条要素，它的交付物可能来自很早的阶段。比如 TR2-1 法律法规评审，用的还是 Phase0-5 那份法规注册评估报告，只是在规格评审时更新了一版。所以看要素表不能只看 TR 编号，要顺着“评审点对应的文档或交付物”这一列往回找源头，否则评审会上就会出现“资料还没出”的尴尬。

2.2 TR1：三十一条要点按责任部门切成七组

TR1 是整张表里最厚的一关，三十一条要点横跨产品、研发、注册、制造、财务多个口子。硬背编号几乎不可能，按责任部门分组之后就好记多了。

这张表的价值在于：它把“概念评审要准备什么”变成“七个部门各交一份东西”。实际开会时最常见的拖延，是产品经理把七份材料全揽在自己身上，结果法规和制造两块永远缺。按分组去催，比按编号去催有效得多。

另外注意 TR1-1 到 TR1-7 这七条共用同一份原始需求报告，说明需求评审内部是有层次的：先看定位对不对（TR1-1），再看人群规模够不够（TR1-2），再看创新性和时效性（TR1-3、TR1-5），最后才是 $APPEALS 这种结构化拆解（TR1-6）和需求要素能不能落到产品上（TR1-7）。顺序反了，就会变成拿着 $APPEALS 表格硬套一个还没想清楚卖给谁的产品。

2.3 TR2 与 TR3：把需求翻译成参数，把方案翻译成计划

TR2 规格评审只有八条，但它是整条链上性质变化最大的一关——从“要不要做”转成“做成什么样”。

前七条集中在规格上：TR2-1 法律法规评审（沿用 Phase0-5 更新版）、TR2-2 注册计划评审、TR2-3 产品型号设计及关键设计参数、TR2-4 外观设计、TR2-5 包装规格、TR2-6 材料规格、TR2-7 灭菌规格，统一由研发部门提供、研发经理负责，交付物是 Phase1-15。TR2-8 单独拎出来，要求“关键产品特点的测试方法、测试标准及关键指标予以说明”，交付物是 Phase1-16，责任落在研究院。

这一条最容易被当成附属品。规格评审真正要回答的是：你写下的每个参数，将来用什么方法、按什么标准、测到多少算合格。参数没有配套的测试方法，TR5 样品测试那天就一定翻车——测试做不出来，或者做出来了但没人认。

TR3 总体方案评审八条，重心从“东西长什么样”转到“怎么把它做出来、要花多少钱、要多久”。TR3-1 各个工程要素整合能力的评审、TR3-2 研发成本预算、TR3-3 外协计划、TR3-4 资源投入计划、TR3-5 明确的进度计划、TR3-6 开发周期风险评估、TR3-7 开发成本风险、TR3-8 设计需求、包装需求和设计参数的风险控制计划，交付物是 Phase1-17，责任人是项目经理和产品经理。

把 TR2 和 TR3 放一起对照，区别就清楚了：

TR3-1“各个工程要素整合能力”是这八条里最抽象的一条，也是最难糊弄的一条。它问的是结构、电子、软件、工艺、注册这些口子的方案能不能拼成一个整体，而不是各自都成立。评审时如果只让每个模块负责人自述本模块，这条基本等于没审。

2.4 TR4 到 TR6：图纸、样品、量产，三级放大

下半场的三个 TR，本质是同一个东西在三种放大倍数下的检查。

TR4 设计成果评审十一条，交付物集中在 Phase2-19 图纸、Phase2-20 样品生产工艺、Phase2-21 样品、Phase2-18 样品、Phase2-22 器械采购申请表或委托加工单。要点分两段：TR4-1 到 TR4-4 是设计口径的（是否满足概念设计要求、关键尺寸和部件、图纸审核、设计变更历史记录是否完整），TR4-5 到 TR4-9 是工艺口径的（工具刀具检具工装的设计审核、设计方案工艺确认、工序设备工艺装置是否明确、工艺重点难点是否解决、生产计划与刀具等采购计划是否清晰可行），TR4-10 详细测试计划由研究院出，TR4-11 器械加工需求由产品经理确认。

TR4-4“设计变更历史记录是否完整”是一条常被跳过的要素。它不产出任何新东西，只查旧账，所以最容易被“这次先过、下次补”打发掉。但变更记录一旦断链，后面 TR5 测出问题时就无法回溯是哪一版改坏的，这就是典型的没有后悔药。

TR5 样品测试评审九条，画风完全变了——从“设计对不对”变成“数据说话”。TR5-1 收集工厂对样品的加工意见（Phase2-23 样品加工意见反馈表）、TR5-2 样品质量检验结果（样品质检报告，质量部）、TR5-3 样品测试报告、TR5-4 测试实施标准、TR5-5 测试数据、TR5-6 测试设备使用状况（以上四项均由研究院出）、TR5-7 批量试制任务确认（批量试制订单，产品部）、TR5-8 注册计划更新（Phase0-5 更新版，注册办）、TR5-9 批量试制计划与采购计划确认（Phase2-24 批量试制采购计划书）。

TR5-4 和 TR5-5 要连起来看：测试标准是尺子，测试数据是读数。标准没定就出数据，数据再漂亮也没法判合格。TR5-6“测试设备使用状况”更细，它问的是设备本身的状态是否可信——设备没校准，前面所有数据都要打问号。

TR6 批量试制评审八条，落点是钱和产能：TR6-1 收集批量试制意见（Phase2-26）、TR6-2 批量试制质量检验结果（质检报告，质量部）、TR6-3 临床测试结果（Phase2-27 临床评估报告，产品部）、TR6-4 费用和预算平衡（Phase2-28 项目成本核算表，财务部门）、TR6-5 人力资源等成本核算、TR6-6 批量生产的生产工艺（Phase2-29 量产生产工艺）、TR6-7 量产计划与外购件采购计划（Phase2-30）、TR6-8 量产确认（Phase2-31、Phase2-32，产品部）。

TR6 里第一次出现财务经理作为评审负责人（TR6-4、TR6-5），这是个信号：到了这一关，技术已经不是主要矛盾，能不能赚钱才是。很多团队在 TR6 还在纠结工艺细节，把成本核算放到发布评审再说，结果发布评审直接卡在收益评估上。

三级放大串起来看就是一句话：TR4 看图纸和工艺能不能对上，TR5 看数据和标准能不能对上，TR6 看产能和成本能不能对上。

3. DCP 三场决策评审：IPMT 到底在批什么

3.1 DCP 与 TR 的分工：一个判技术，一个判投不投

TR 和 DCP 最容易被混为一谈，因为它们的资料大量重叠。概念评审的第一条就是“对 TR1 评审结果的审查”，计划评审的前两条是 TR2、TR3 评审结果的审查，发布评审的前三条是 TR4、TR5、TR6 评审记录的审查。

这个设计说明 DCP 不是重新做一遍技术评审，而是拿技术评审的结论去做投资判断。TR 的评审负责人是各部门经理（研发经理、产品经理、注册办副经理、质量部经理、财务经理），DCP 的评审负责人统一是项目经理和 IPMT。人换了，问题也就换了——TR 问“这个方案技术上站不站得住”，DCP 问“这笔钱还投不投、投多少、什么时候要回报”。

理解这一点，准备材料的方式就完全不同。TR 材料要往细里做，参数、图纸、测试数据越实越好；DCP 材料要往整合方向做，一页纸说清技术结论、市场结论、财务结论三者的关系。

3.2 概念评审十一条：把技术结论翻译成投资结论

概念评审十一条（编号概念评审-1 到概念评审-11）大致可以分成四块。

第一块是承接：概念评审-1 对 TR1 评审结果的审查，交付物是概念评审的记录，责任人项目经理与 IPMT。第二块是产品与知识产权：概念评审-2 产品相关介绍（性能、产品标准）是否明确、概念评审-3 涉及到的知识产权问题是否确定解决办法。第三块是市场与效益：概念评审-4 需求目标、客户、需求量是否明确，概念评审-5 市场情况分析，概念评审-6 研究与开发的技术、资源、竞争对手情况是否明确，概念评审-7 生产线及生产能力确认，概念评审-8 是否制定了切实可行的市场营销策略，概念评审-9 市场经济效益评估认定。第四块是风险与立项可行性：概念评审-10 是否识别了风险、制定了风险响应计划，概念评审-11 概念阶段评估项目立项可行性（项目概算、沟通计划、里程碑事件、产品开发团队及职责是否确认）。

概念评审-11 是这一场的收口条，它把五样东西一次性问完：概算、沟通计划、里程碑、团队、职责。这五样里最容易缺的是沟通计划和里程碑——大家都在算钱和排人，没人写“出问题找谁、什么时候必须汇报”。这也是后面项目延期时最常被追责的一项。

注意概念评审-2 到概念评审-7 的资料，很多是 TR1 阶段各组的汇总，不是新写的。所以概念评审的准备重点不是“再写一遍”，而是“把 TR1 七组交付物浓缩成 IPMT 能看懂的版本”。

3.3 计划评审五条与发布评审十二条：一次比一次更看钱

计划评审只有五条，但每条都直指资源：计划评审-1 对 TR2 评审结果的审查、计划评审-2 对 TR3 评审结果的审查、计划评审-3 规格对供应链成本的影响评审、计划评审-4 投资组合管理、计划评审-5 开发资源匹配的优化。除前两条是承接，后三条全部是资源配置问题，责任人均为项目经理与 IPMT。

计划评审-3 值得单独说。它要求评审“规格对供应链成本的影响”，用的还是 Phase1-15 那份规格文件的更新版。含义很直接：你在 TR2 定下的每个规格，都会变成采购价格。规格定得过严，供应商找不到，成本飙升；定得过松，产品竞争力不够。这一条把技术决策和财务后果第一次明确绑定在一起，是整套评审里最有含量的一条。

发布评审十二条是整张表里最杂的一场，从审查到销售全覆盖：发布评审-1 至 -3 分别审查 TR4、TR5、TR6 评审结果（交付物为对应的评审记录，项目经理与 IPMT）；发布评审-4 成本核算与收益评估（项目成本核算表更新版，财务经理）；发布评审-5 资源使用情况评价（Phase3-33）；发布评审-6 市场营销战略和营销策略（Phase3-34 新品市场推广培训计划，产品部）；发布评审-7 预估销售额、发布评审-8 宣传资料、发布评审-9 培训计划；发布评审-10 发布产品验收标准（Phase3-35，产品开发部）；发布评审-11 销售任务（Phase3-36 销售任务书，产品部）；发布评审-12 产品上市后跟踪计划（Phase3-37 产品上市跟踪计划，产品部）。

十二场评审收尾的动作写在最后一行：发布阶段产品文档归档移交，责任人项目经理。这一行没有编号，却决定了整个项目能不能被下一个产品复用。评审记录、变更历史、测试数据、成本核算表如果散落在各人手里，下一个项目基本等于从零开始。

三场 DCP 连起来看，重心迁移非常清楚：

4. 要素表四个字段：交付物、提供部门、评审负责人怎么落

4.1 交付物字段：评审能不能开成的入场券

要素表里“评审点对应的文档或交付物”这一列，实际作用远超一个备注。它决定了评审会能不能按时开。

判断方法很简单：开会前一天，把当次评审涉及的所有交付物列一遍，逐个确认是否已出、是否是最新版。TR1 对应 Phase0-3 到 Phase0-10 一共八份，TR5 对应 Phase2-23、样品质检报告、样品研究院的四份报告、批量试制订单、Phase0-5 更新版、Phase2-24，谁缺一份，对应的要素就无法回答。

更要命的是“更新”两个字。表里明确标了更新的至少有四处：TR2-1 用 Phase0-5 法规注册评估报告（更新）、计划评审-3 用 Phase1-15（更新）、计划评审-4 用 Phase0-12（更新）、计划评审-5 用 Phase1-17（更新），TR5-8 用 Phase0-5（更新）、发布评审-4 用项目成本核算表（更新）。更新版没交，等于这条要素用的是半年前的旧结论。

提示：把带“更新”的交付物单独列一张小表，标上原始 Phase 编号和本次更新的触发原因，评审时逐条对照，能省掉大量来回。

4.2 部门与负责人：谁交和谁判是两个字段

“资料提供部门”和“资料评审负责人”看着像同一件事，其实是两个独立维度。部门是可以换人的，责任人不能换。

举个表里能直接看到的例子：TR1-27 到 TR1-29 的提供部门是产品开发部，评审负责人是产品开发部部门经理；TR1-22 到 TR1-26 的提供部门是研发部门，负责人是研发经理。这两组在技术上高度相关（可制造性和加工成本是一体两面），但责任主体完全分开。如果评审时只叫了研发经理，制造那三条就没人能签字。

再看注册相关的几条：TR1-12 到 TR1-16、TR2-1、TR2-2、TR5-8，提供部门都是注册办，负责人都是注册办副经理。这是一个贯穿四个阶段的角色，从概念一路跟到样品测试。这类“跨阶段同一负责人”的要素，实际执行时最容易断——人在 TR1 参与了，到 TR5 换了岗，交接没做，资料就断了。

表里还有一类特殊条目：Phase0-1 项目立项任务书和 Phase0-2 产品开发任命书，标注的是“非评审内容”。意思是这两份东西是流程的起点输入，不作为评审要素被逐条追问。但它们依然是交付物，缺了它们，TR1 就失去了立项依据。把“非评审内容”理解成“不用准备”，是这张表里最典型的误读。

4.3 把要素表变成可校验的结构

要素表条目多、跨阶段引用多，靠 Excel 手工维护很容易出现“某条要素没写交付物”或“某条没写负责人”。用一段结构化的定义加一个自检函数，能把这类问题在开会前筛出来。

# 一条评审要素 = 编号 + 所属评审点 + 交付物来源阶段 + 交付物 + 提供部门 + 评审负责人 REVIEW_ITEMS = [ {"id": "TR1-1", "gate": "TR1", "phase": "Phase0-3", "deliverable": "原始需求报告", "dept": "产品部", "reviewer": "产品经理"}, {"id": "TR1-12", "gate": "TR1", "phase": "Phase0-5", "deliverable": "法规注册评估报告", "dept": "注册办", "reviewer": "注册办副经理"}, # 同一份交付物在后续评审点被复用，用 revision 记录版本，不另开新行 {"id": "TR2-1", "gate": "TR2", "phase": "Phase0-5", "revision": 2, "deliverable": "法规注册评估报告", "dept": "注册办", "reviewer": "注册办副经理"}, {"id": "TR6-4", "gate": "TR6", "phase": "Phase2-28", "deliverable": "项目成本核算表", "dept": "财务部门", "reviewer": "财务经理"}, ] def check_before_review(items, gate): """开评审会前的自检：返回该评审点里字段缺失或交付物重复挂靠的条目""" problems = [] for it in items: if it["gate"] != gate: continue # 缺交付物或缺负责人，评审当天一定卡住 missing = [k for k in ("deliverable", "dept", "reviewer") if not it.get(k)] if missing: problems.append((it["id"], "缺字段:" + ",".join(missing))) return problems print(check_before_review(REVIEW_ITEMS, "TR1"))

这段代码逻辑有三处值得说明。gate对应 TR1～TR6 或三场 DCP，用来按评审点切片；phase指向交付物产生的阶段，允许同一个 phase 被多个 gate 引用，这正是“更新版”的建模方式；revision只在复用时出现，没有就是首版。check_before_review返回的是问题清单而不是真假值，因为实际使用中你需要的不是“能不能开”，而是“缺哪几条、谁去补”。

参数的取法也有讲究：dept和reviewer必须分开存，不能用部门名字符串去匹配负责人，否则一旦换人，全表都要改。

4.4 用 Phase 编号做主键做归档

发布评审的最后一行动作是产品文档归档移交。归档最容易犯的错是按评审点建文件夹（TR1、TR2、TR3……），结果同一份 Phase0-5 法规注册评估报告在 TR1、TR2、TR5 三个文件夹里各躺一版，谁也说不清哪版是最新的。

正确的组织方式是以 Phase 编号为主键：Phase0-5 下面挂版本，TR1 里放引用，TR2 和 TR5 里放的是同一个 Phase 的新版本加变更说明。这样任何一次评审要查资料，只需要知道 Phase 号，不用记是第几次评审用过它。变更历史也就自然串起来了——TR4-4 要求的设计变更历史记录完整，靠的正是这套以 Phase 为主键的目录结构，而不是各人手里的备忘录。

5. 五个易错点：评审要素表最容易被用歪的地方

5.1 易错点一：把“风险分析”当成“风险管理计划”

易漏点：TR1-10 概念设计中的风险及应对措施、TR1-25 技术的风险分析管理计划、TR1-30 全方面风险分析及控制计划、TR1-31 风险管理负责人确认，这四条在很多人眼里是一件事，于是只交一份风险清单就草草了事。

为什么漏：四条要素分属三个不同交付物——TR1-10 在 Phase0-4、TR1-25 在 Phase0-8、TR1-30 和 TR1-31 在 Phase0-10 风险管理计划，责任人从研发经理一路换到项目经理。当成一件事做，就只会有一个人在做。

怎么补：按“识别—分析—控制—责任”四段拆。识别和分析可以分散在各阶段的交付物里，但控制和责任人必须收敛到 Phase0-10 那一份风险管理计划，并且 TR1-31 明确要求“风险管理负责人确认”，这一条没有签字就不算完成。

5.2 易错点二：跳过标注“非评审内容”的立项任务书与任命书

易漏点：Phase0-1 项目立项任务书、Phase0-2 产品开发任命书，表里标注“非评审内容”，于是被理解成不用准备。

为什么漏：字面意思容易被读成“不需要评审”，实际含义是“不作为查核要点被逐条追问”。但它们是 TR1 全部三十一条的立项依据——没有任务书，TR1-17“产品是否符合整体产品组合规划”就没有判断基准；没有任命书，TR1-31 的“风险管理负责人确认”就无从确认。

怎么补：把这两份归到“流程前置输入”单独管理，在 TR1 材料清单里固定放在第一页，评审开始前用一分钟确认已签批。成本极低，但缺了会让整场评审的合法性受质疑。

5.3 易错点三：把带“更新”的交付物当成一次性材料

易漏点：Phase0-5 法规注册评估报告在 TR1、TR2、TR5 三次出现且都标更新，Phase1-15 规格文件在 TR2 和计划评审-3 出现，Phase1-17 在 TR3 和计划评审-5 出现，项目成本核算表在 TR6-4 和发布评审-4 出现。

为什么漏：表格里“（更新）”两个字太小，做计划时按行数排期，很容易把同一份文件当成三份不同材料分别安排，或者反过来只做一次就不再维护。

怎么补：单独建一张“跨评审点复用交付物”清单，列三栏：Phase 编号、被哪几个评审点引用、每次更新要补什么。法规注册评估报告在 TR2 要补注册计划，在 TR5 要补批量试制前的注册进度，两次更新的内容并不相同。

5.4 易错点四：DCP 材料直接拿 TR 材料顶

易漏点：概念评审-1、计划评审-1、计划评审-2、发布评审-1 至 -3 都是“对上游评审结果的审查”，于是把 TR 的全套材料原样搬到 IPMT 会上。

为什么漏：交付物确实写的是“评审记录”，看起来搬过去就满足了。但 IPMT 要做的判断和 TR 完全不同——TR 关心技术是否成立，DCP 关心投资是否继续。

怎么补：TR 记录作为附件，另外准备一页整合结论：技术结论一句话、市场结论一句话、财务结论一句话、本次请求的资源与放行条件。概念评审-11 列的五项（概算、沟通计划、里程碑、团队、职责）就是这一页的骨架，照着填不会跑偏。

5.5 易错点五：混淆“提供部门”与“评审负责人”

易漏点：TR1-27 到 TR1-29 由产品开发部提供、产品开发部部门经理评审；TR1-12 到 TR1-16 由注册办提供、注册办副经理评审。同一部门既交又判，看起来是一个人可以搞定。

为什么漏：中小团队里一人多岗很常见，写着两个字段，实际操作时合并成一个人，短期看不出问题。

怎么补：坚持两个字段分开填，并在评审记录上区分“资料提交人”和“评审结论签署人”。同一人兼任时，至少在记录上留两行，注明本次由谁代行另一职责。这个动作看着形式主义，但等到出现质量争议、需要追溯是谁判的放行时，它就是唯一的凭据。

6. 复习清单：把八十多条要素压成三遍能过完的表

真要把这套东西记牢，靠通读一遍表格没用。我的做法是把八十多条要素压成三遍能过完的清单，每遍只盯一个维度。

第一遍过“关口—交付物”。只看两列：这个评审点对应哪些 Phase 编号。目标是合上表能默写出 TR1 到 TR6 各自的主要交付物，尤其是那几个跨阶段复用的：Phase0-5 出现在 TR1、TR2、TR5，Phase1-15 出现在 TR2 和计划评审-3，Phase1-17 出现在 TR3 和计划评审-5，项目成本核算表出现在 TR6-4 和发布评审-4。这四组记不住，排期一定出问题。

第二遍过“责任部门”。按部门反向索引，看每个部门被点名几次：

这张反向表能立刻暴露短板：比如质量部第一次出现是在 TR5，意味着前四关完全没有质量口子参与，TR1 的“可测试性要求”和 TR4 的“检具设计审核”实际上是研发自己在判。意识到这一点，就会主动在 TR1 阶段把质量部拉进来。

第三遍过“易错点”。把第 5 章那五条写成五个自测问句，每句只答是或否：

• 风险相关内容，我是否分清了识别、分析、控制、责任人四个层次？
• 立项任务书和任命书，我是否已签批并放在材料第一页？
• 带“更新”的交付物，我是否列了单独清单并写明每次补什么？
• DCP 材料，我是否准备了一页整合结论而不是搬 TR 全套？
• 每条要素的提交人和签署人，我是否在记录上分了两行？

五问里有一个否，就去对应章节回查。

最后给一个我认为最省时间的动作：把要素表按“评审点 × 交付物”做一次透视，凡是同一份交付物被两个以上评审点引用的，全部标红。整张表里这样的条目不超过十份，但它们贡献了绝大部分的资料返工。把这十份管住，评审会的准备时间能砍掉一半。

这些都是实际踩过坑之后才总结出来的。最早我做评审准备，习惯从 TR1 第一条开始往下捋，一条条勾，勾到第三十条已经忘了第一条写的是什么，开会时被问到“这份资料哪一版”还得现场翻。从那以后我每次开评审会前，都强制先把当次要审的要素行按交付物去重、按部门分组、把带更新的单独拎出来，三件事做完再排会议日程。这套动作重复几次之后就变成肌肉记忆了，希望帮到你。

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