M1-02 热管理项目管理与主机厂—供应商协同

课程代码 M1-02 · 板块 M 项目、质量、成本与合规 / M1 研发流程与项目管理 时长 约 3.5 小时（5 讲 + 1 次 RACI／问题清单实操） 适合对象 项目经理／技术负责人／系统工程师；管理岗必修，技术岗选修 前置 M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑 汽车研发流程（APQP/IATF16949）与热管理里程碑（建议先修） 本讲义定位 讲师授课蓝本 / 学员自学讲义，是 M1-02 大纲的完整展开版

---

引言：没有写进哪一格的工作，最后都会落到热管理头上

一个热管理项目出了接口问题，复盘会通常是这么开的。某个总成的进出水嘴位置与管路走向对不上，或者压缩机的通信协议版本与整车控制器不一致，会上各方各自拿出文件：电驱侧说接口控制文件上写的就是他们那一版；座舱侧说需求变更早就通知过；供应商说工作说明书里根本没有这一项。三份材料在各自的范围内都成立，谁也说不出对方哪里违规。会开到最后，改动落在热管理这一侧——不是因为责任判清了，是因为改这里最快。

这不是运气不好，是位置决定的。热管理在整车里同时接着五个专业——制冷回路、流体管路、结构布置、电子控制、标定软件；这五个方向上的供应商还常常不是同一家，压缩机、板式换热器、电子膨胀阀、传感器分属不同厂家是常态；而它几乎从不定义整车的架构主线，却要为所有与热相关的后果负责。⇒ 三条同时成立：跨专业接口多、供应商多头、话语权弱而责任重。这三条叠起来产生一个稳定的方向，本课把它当作重力来处理。

钉子 A —— 责任的边界由文件划定，不由常识划定；没有写进哪一格的工作，默认落到被集成方，也就是热管理这一侧。项目里最危险的一类句子恰恰是「这个大家都知道该谁做」——它说的是此刻在场的这几个人知道，而一个项目要跑很久，人会换、平台会派生、供应商会增补，到那时口头共识不具备可执行性。真出了争议，裁决方式只有一种：翻文件。文件上没有的那一格，最后由「改起来最快的那一方」承担，而在热管理项目里那几乎总是自己。全课每一讲都在同一个位置敲这一钉：第 1 讲说清这个重力方向从哪来；第 3 讲把它变成工作说明书（SOW）的条款与责任矩阵（RACI）的一格一格；第 4 讲把它变成接口控制文件（ICD）与开发接口协议（DIA）两份文件，并回答哪些接口两份都不覆盖；第 5 讲把它推到极端形态——供应商断供的那一刻，谁有权放行替代料。

钉子 B —— 一份管理制品要「活着」才算数，而活着的判据只有三样：有决策人、有时限、有触发条件。三样缺一，它就退化成一次记录动作：写了、存了、没有人被要求在某个时刻据它做判断。这一钉能解释本课几乎全部的失效形态，而这些形态表面上互不相干——问题清单由主机厂单边维护（缺的是供应商侧的响应时限）；风险登记表建完就归档（缺的是「什么条件下要翻出来对照预案」这条触发）；变更在群里说一句就往下走（缺的是「谁批」）；进度汇报写「完成 80%」（缺的是可核对的对象：它既不是一次决策，也不是一份证据）。⇒ 判一份管理制品有没有用，不看它写得多完整，看这三样在不在。第 2 讲会给出把「完成 80%」换成可核对量的做法（挣值法的进度与成本绩效指数），第 3 讲给问题清单补上双方共维的口径，第 5 讲给风险登记表补上触发条件。

两钉的关系：钉 A 管边界写在哪里（责任的空间维），钉 B 管它到时候会不会真的被执行（责任的时间维）。⛔ 把两者合成一句「把流程做规范」，正是本课要拆开的那个结——规范的是文件的样子，而项目要交付的是到点有人做判断，两者之间隔着这两根钉子。

⚠ 顺带把本课在数上的立场先交代清楚：本课一个项目周期、一个变更代价倍数、一个安全库存周数、一个供应商家数都不给。这些量取决于平台、客户体系、供应商结构与各类件的交付周期（lead time），须按本项目实际情况确定；本课给的是可迁移的口径——这笔代价由哪几项构成、缓冲该按谁的交付周期分档、风险该按什么排序。⚠ 标准侧同理：本课涉及的 IATF 16949 与 AIAG APQP 参考手册均未独立核对过原文，故一律只写标准号与去向，⛔ 不写条款内容、不写条款号、不写具体要求等级；版次与年份以现行目录为准，引用前须核。

先打一针预防针。本课最容易被读反的一句是：「热管理是被集成方，接口是别人定的，配合就好；话语权不够是客观事实，管理上没什么可做的。」前半句是事实（第 1 讲会把它讲成一个结构问题，而不是一句抱怨），后半句是从这个事实推出的错结论。读反之后的错误动作有两个，方向正好相反。

会做错的第一个具体动作：在接口冻结的时间表上主动弃权——等相邻专业都冻完了再接，然后在既成事实上做补偿设计。为什么这是读反：冻结时序不是排期问题，是依赖问题。热管理夹在中间，它既有必须等的上游（电池包的产热与布置、电驱总成的接口位置），也有必须先冻别人才能往下走的下游（管路走向占用的空间、前端模块的进风面积、控制器的信号清单）。弃权的一方不只是「少做了一件事」，它把自己的下游一起卡住了；而卡住的代价最终仍会以补偿设计的形式回到自己身上，只是那时已经没有便宜的解法了。

会做错的第二个具体动作，方向正好相反：知道「要争话语权」之后，把力气全花在要求别人先冻上，自己该冻的迟迟不冻——SOW 里的交付物清单、供应商侧的接口输入、RACI 里属于自己那几格，理由永远是「上游还没定」。为什么这也是读反：接口谈判里的话语权不来自嗓门，来自谁能先把自己那一侧写死。写死的一侧才可能被别人当作输入引用，永远待定的一侧只会被当成变量绕过去——绕过去的结果就是别人按自己的假设往下走，而那个假设不需要你同意。⇒ 两个动作同源：都把接口冻结当成一次时间点上的博弈，而它其实是一张依赖关系的拓扑。第 4 讲会把这张拓扑正面画出来，并给出「谁先冻、谁后冻」的判据，以及接口一旦变更该怎么评连带影响。

⚠ 还有一条次级的、同样容易读反的话，这里先备个案，第 5 讲正面拆：「多寻源就是再找一家供应商——有备份就不会断供。」它把多寻源看成一个可以随时按下的开关，看不见启用它所需要的东西（新源的产能、重新做产品批准与量产节拍验证所需的周期、两家是不是共用同一个上游单点）恰恰在断供发生的那一刻都还不具备。本课的案例节讲的就是这个形态的代价。

再把边界划清，因为本课与周边几门课贴得很近，不在开篇写死，必然重叠或者整段落空。本课给的是五样：热管理项目额外复杂度的三条来源与它们的叠加方式 · 铁三角权衡在变更请求上的落地形式（评估要素与变更控制委员会 CCB 的决策闭环）· 把责任边界写成可执行条款的方法（SOW 的五块结构、RACI、联合项目组、问题清单的双方共维口径）· 接口管理的两份文件（ICD 与 DIA）与冻结时序的判据 · 风险登记表的活用口径与断供后的处置序列（含安全库存缓冲按谁的交付周期分档）。

只给去向的是：APQP 阶段与门禁、里程碑表怎么排（M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑）；验证计划本身怎么编、DVP&R 那张矩阵怎么写（M1-03 DVP&R 与验证计划管理）；技术协议的条款层与商务谈判（Q2-02 主机厂—供应商技术对接与商务谈判）；跨部门协同的具体工作法与会议形态（Q2-04 跨部门（整车/电子/结构/软件）协同工作法）；功能安全相关件的 DIA/SEooC 与热管理控制软件跨企业交付边界的本体（K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署）；重新做产品批准（PPAP）与量产节拍验证的做法（M2-01 质量工具：PPAP/8D/SPC/MSA）；供应商侧的遏制措施与来料控制（M2-03 供应商质量与来料控制）；关键零部件的国内外供应商格局（A5-04 关键零部件与国内外供应商格局）。不在射程的是：各类热管理零部件与回路的技术方案、选型与计算（各技术板块的产品课），本课一条都不重讲；以及成本报价的拆解与商务条款本身。

⇒ 学完这门课，你应当能做到三件事：拿到一份 SOW 或一张接口清单，说得出哪一格没写、以及那一格空着时这份工作默认会落到谁头上；拿到一条变更请求，说得出它动的是铁三角哪一角、谁是有权批的人、以及「不批」这一支的代价写在哪里；拿到一份风险登记表或一次真实断供，说得出下一个动作是什么、由谁在什么时限内做完。

五讲按「从处境到文件、再到预案」这条线推进：第 1 讲立处境（三条来源怎么叠加成「被集成方」，以及它为什么是结构问题不是情绪问题）；第 2 讲立权衡与闸门（进度／成本／质量的三角怎么互相压、关键路径上的总时差怎么读、挣值法怎么把「完成 80%」换成可核对量，以及一条变更请求走到 CCB 的完整闭环）；第 3 讲把边界写成条款（SOW 的五块结构、责任矩阵、联合项目组的周例会与共同里程碑表、问题清单为什么必须双方共同维护）；第 4 讲把边界写成接口（ICD 覆盖什么、DIA 补的是哪一类、两份为什么要一起冻、接口变更的连带影响怎么评）；第 5 讲把边界推到最坏情况（风险登记表怎么活着用、概率与影响怎么排序、多寻源的成立前提、断供后的处置序列与每一步的决策人与升级时限）。第 1 讲就从那句最容易被当成抱怨、其实完全可以结构化的话开始——「我们是被集成方」。

第 1 讲　热管理项目难在哪：接口按组合数长、责任落在缝里、边界由别人给

把一个热管理项目管砸，通常不是因为谁偷懒。复盘会上最常见的画面是：每个专业的进度条都是绿的，每一家供应商的零件级报告都是合格的，每一次评审都签了字，而系统装到车上就是不达标，或者某个接口在总装线上才发现对不上。这时候追问「是谁的责任」，会得到一串在逻辑上都站得住的回答——制冷侧说自己的循环匹配没问题，结构侧说自己按数模布置的，控制侧说信号按矩阵收发的，供应商说自己的件按规格做的。⇒ 于是问题变成了一个更不舒服的形态：每个人都对，合起来是错的。

本讲要做的是把这个形态拆开，说清热管理项目相比一个单一专业的项目，额外多出来的复杂度具体是什么、从哪来。它不是「更难一点」这种程度上的差别，而是三个结构性的来源：接口的数量按组合数增长而不是按专业数增长（1.1、1.2）；关键件分属多家供应商，于是系统级的责任落在几份合同之间的缝里（1.3）；热管理在整车里通常是被集成方，边界条件的定义权在别人手上而结果的追责权指向自己（1.4）。最后把这三个来源与本课后面四讲对上号，并收成三句可以在任何一次项目例会上当场去问的自检问句（1.5）。

⇒ 这一讲不给任何管理工具的操作方法——SOW 怎么写、RACI 怎么画、ICD 怎么冻、风险登记表怎么排序，全在后面四讲。本讲只负责一件事：让你在动手用那些工具之前，先说得出自己在对付的是哪一类复杂度。工具选错的最常见原因不是不会用，是没认出问题属于哪一类。

1.1 五个专业不是五个部门，是五套各自成立的设计语言与冻结节拍

是什么。一套整车热管理系统的设计工作，横跨五个内部专业，每一个都有自己的输入输出、自己的验证手段、自己的变更代价与自己的冻结节点：

专业	它交付的东西	它的设计语言	改一版的典型代价形态
制冷回路	压缩机、冷凝器／水冷冷凝器、蒸发器／Chiller、电子膨胀阀、气液分离器、充注量与冷冻油	循环状态点、压焓关系、部件匹配	重新做部件匹配与充注量标定，重跑焓差与环境舱验证
流体管路	水泵、多通阀／阀岛、板式换热器、散热器、膨胀水壶、水路拓扑	流阻—流量特性、各支路流量分配、除气与灌注	重新核流阻与流量分配，重做灌注与排气工艺验证
结构布置	管路走向、支架与固定点、密封与接头、装配可达性、前端进风、包络	三维数模、间隙与包络、振动与固定点	动数模轮次，可能动工装甚至动模具
电子控制	控制器落点、执行器驱动、总线报文与信号矩阵、诊断与故障处理	信号矩阵、状态机、时序	改软件版本并重跑相关的在环与整车验证
标定软件	控制策略参数、模式切换阈值、阀位与风门映射、能耗与舒适性权衡	标定表、工况谱、主观评价	刷写一版标定，重跑受影响的工况

⚠ 表里的「设计语言」与「改一版的典型代价形态」两列是本课归纳的读法，⛔ 不是任何标准或体系文件里的既有分类；它的用处是把「跨专业」这句抽象的话，翻译成「这五套东西各自按什么规矩演进」这个可以逐条去问的问题。各专业本身的技术内容不在本课射程：制冷循环与部件匹配见 C1-01 汽车空调制冷系统原理与部件匹配，电机水冷见 E1-01 电机水冷（机壳水道）设计与换热强化，电池产热见 D1-01 动力电池产热机理与产热速率建模，控制软件架构见 K4-01 热管理嵌入式软件架构与 AUTOSAR 基础，诊断与降级见 K5-01 OBD/UDS 诊断与故障码（DTC）设计、K5-02 热管理故障处理与降级策略。

为什么必须按「五套设计语言」读，而不能按「五个部门」读。因为跨专业问题最典型的形态是各自都对。举一个具体的：控制策略要求某个阀在某工况下保持一定开度，以便回路里的工质或冷却液不在低点滞留；而结构侧为了避开一根线束、把这个阀的位置往下挪了一段——挪完之后布置图上的间隙都够、干涉检查全过、结构侧的判据一条没违反。两侧各自的评审都会通过，因为每一侧的判据里都没有对方那一条。这类问题不会在单专业评审里暴露，它只会在接口评审里暴露，而接口评审要成立的前提是：这条接口先被写下来过。

同一个道理还有一个更隐蔽的版本：五个专业的冻结节拍不同。结构侧要早冻（因为下游是工装与模具，越晚改代价越陡），标定侧可以晚冻（因为它可刷写）。这个差异本身没有问题，问题在于：节拍不同的几件事被同一个里程碑名字盖住了。项目计划上写着「设计冻结」，五个专业理解的是五个不同强度的「冻结」——结构侧理解成「此后动一次要走变更评审」，标定侧理解成「此后正常迭代」。等到有人拿着一份变更请求去问「这算不算变更」，才发现两边说的不是一回事。接口冻结的先后与强度怎么谈，是第 4 讲的正题；本讲只要求你认出：「冻结」不是一个统一的动作，它在五个专业里含义不同。

工程量级与典型值。⛔ 本课不给接口条目数、不给各专业的工作量占比、不给冻结节点之间的时间间隔——这些取决于系统架构（是否用集成阀岛、控制器是独立还是集成进整车控制器、有没有热泵）、平台年代与组织形态，须按本项目的架构方案与项目计划确定。⚠ 尤其不要拿别的项目的接口清单条目数来反推自己这份清单全不全：条目数与覆盖完整性之间没有稳定关系，一份两百条的清单完全可能整类漏掉标定侧的接口。本讲能给的是与平台无关的两样东西——复杂度怎么长（1.2）与接口怎么清点（先画全集，见下面易错点②）。

易错点（三条）。

① 把「跨专业」理解成「多开几个会」。会开得再多，没有被写成条目、没有版本号、没有签署人的共识，会一散就不存在了——下一次有人问起，两边各自记得的是不同的版本，而且都很确信。⇒ 跨专业协同的产物必须是条目不是纪要；纪要记的是「我们讨论了什么」，条目记的是「结论是什么、谁负责、什么时候生效」。

② 沿着自己最熟的那条线索去数接口。做制冷出身的人数出来的接口清一色是工质侧的：压缩机转速、EXV 开度、压力传感器信号……而风门与鼓风机、电子节温器、水泵调速、除气与灌注工艺、标定表的版本管理这几类会整类不出现。⚠ 危险的地方在于：整类漏掉不会以「清单里少了一条」的形式暴露——清单看起来是完整的，因为数的人正是沿着那条线索在数。⇒ 正确做法是先把五个专业的全集摆出来（上表就是这个全集的第一层），再逐对核，而不是沿着一条线索往下列。

③ 把标定当成万能的兜底。前四层留下的问题，最后几乎都会以「标定再调调看」的形式压到最后一层，因为它是唯一还能改的一层。但标定能动用的只有它自己那一层的自由度——回路选错了部件、管路走向导致某处滞留、传感器装错了位置，这些在标定表里没有对应的旋钮。⇒ 一旦项目里开始频繁出现「这个靠标定解决」，那不是一个解决方案，那是一个前面某一层的问题被推迟到了改不动的时候的信号。

1.2 接口按组合数长，不按专业数长——所以「再拉一个专业进来」的代价不是加一条

是什么。把每一个参与方看成一个节点，接口就是节点之间的连边。n 个参与方两两之间的接口对数是一个组合数：

接口对数 = C(n,2) = n(n−1)/2

这个式子可以当场手算，而且不依赖任何平台参数。代三个数进去：

• 只看 1.1 里的五个内部专业，n = 5 ⇒ 5×4/2 = 10 对；
• 再把热管理必须对外打交道的四个方向算进来——电池、电驱、座舱、整车布置，n = 9 ⇒ 9×8/2 = 36 对；
• 项目中途又把「高压与充电」作为一个独立参与方拉进来，n = 10 ⇒ 10×9/2 = 45 对。

从 9 到 10，参与方只多了一个，接口对数却从 36 涨到 45，多出来的是 9 对。一般地，第 n 个参与方进来时新增的接口对数是 n−1，而不是 1。这就是热管理项目「额外复杂度」的第一个来源，也是它与一个单一专业项目在结构上的第一处不同。

⚠ 上面那份「五个内部专业 + 四个外部方向」的名单是本课归纳的一个起点，⛔ 不是全集，也不是任何体系文件的既有划分。真实项目里还可能有独立成方的参与者：电子电气架构与整车网络、整车能耗与续航目标的分摊方、NVH、售后与服务、生产制造工艺。⇒ 建自己项目的这份名单时，判据不是「这个专业重不重要」，而是「它会不会向热管理提出或接受一条需要双方共同签署才能定下来的约定」——会，它就是一个节点。

为什么这对项目管理是结构性的，而不只是「数字大一点」。因为常规的项目分解方式是按 WBS 把工作切给各专业，而接口不属于任何一个专业的 WBS——它落在两个 WBS 之间。于是接口天然是无主的：不是没有人愿意管，是分解方式本身没有给它分配位置。这一条直接决定了后面几讲的工具为什么长成那个样子：责任矩阵（RACI）的用处正是给这些「之间」的事指派一个 A（第 3 讲）；接口控制文件（ICD）的用处是把「之间」的约定变成一份有版本、有双方签署的条目（第 4 讲）。⇒ 不是先有工具再有问题，是 WBS 这种分解方式必然留下接口这个空档，工具是来补这个空档的。

工程量级与典型值。⛔ C(n,2) 给出的是接口对数，它是一个上界性质的结构量，⛔ 不得被拿去反算本项目应该写多少条 ICD 条目——一对专业之间可能只有一条接口，也可能有几十条（几何、热、流量、信号、时序、诊断各成一类）。每一对之间到底有几条，取决于系统架构与需求粒度，须按本项目的接口清单逐对确定，本课不给条目数区间。⚠ 这条限制要认真对待：把一个只反映「参与方两两组合」的数当成工作量估算的输入，会得到一个看起来很有依据、实际上什么也没度量的数。

易错点（三条）。

① 把 C(n,2) 当条目数用。如上；它只回答「复杂度按什么规律长」，不回答「我要写多少条」。

② 只数内部五个专业，不数对外的四个方向。n 从 5 到 9，接口对数从 10 到 36，翻了不止一倍——而热管理项目里最难谈的接口，恰恰绝大多数落在对外那一侧（原因见 1.4）。只清点内部接口的项目，会在很晚才发现自己漏掉的正是最贵的那一批。

③ 以为「减少参与方」就能降低复杂度。把水泵、多通阀、板换、Chiller 集成成一个模块，确实把好几条外部接口对合并掉了——但那些接口并没有消失，它们被搬进了模块内部，并且被搬给了一家供应商。⇒ 复杂度是转移不是消失：转移之后它变成那一家的内部问题（你看不见了，但它还在），同时给你留下一个单点依赖。集成度提高与断供风险上升是同一个动作的两面，第 5 讲会从风险侧再回到这一点。

1.3 供应商多头：系统性能是几家合成的，而合同是逐家签的——责任落在缝里

是什么。热管理系统的关键件常常分属不同供应商，最典型的四类是：压缩机（电动压缩机通常还自带变频器与控制软件）、板换即板式换热器（水冷冷凝器与 Chiller）、电子膨胀阀 EXV（含驱动与步数标定）、传感器（压力与温度）。除这四类外，水泵、多通阀／阀岛、管路总成、PTC 加热器、风扇模块、控制器与其软件也各有各的来源。⇒ 也就是说，一套系统里最影响性能的那几个件——压缩机、板换、EXV、传感器——往往分属不同供应商，这是热管理项目在供应端的常态而不是例外。

它们之间的商务关系还不止一种，这一点比「家数多」更要紧：

供货形态	谁选的、谁签的合同	系统集成方手上有什么杠杆
自主采购件	集成方自己选、自己签	价格、份额、更换权都有
定点直供件（directed buy）	主机厂指定供应商甚至指定价格，由集成方去签与采购	有采购动作，⛔ 基本没有更换权与价格杠杆
客供件	主机厂自己签、送到集成方产线	⛔ 既无价格杠杆也无更换权，但装配与系统结果仍算集成方的

⚠ 这张三分表是本课归纳的读法，⛔ 不是某个体系文件的既有分类；具体项目里的叫法与边界以合同与采购策略为准。产业侧的供应商格局与关键件的国内外分布见 A5-04 关键零部件与国内外供应商格局。

为什么这是管理问题而不是采购问题。因为一条链上有两个东西的粒度对不上：

• 性能是合成的——制冷量、制热能力、系统 COP、快充时电池包的温升与温差、噪声，这些量没有一个是某一个零件单独决定的，它们是几家零件在一个具体工况下合成出来的结果；
• 合同是逐家签的——每一份合同的标的是零件级规格：这个压缩机在这个转速与压比下排量多少、这个板换在这个流量下换热多少、这个 EXV 的流量特性曲线是什么样。

⇒ 于是就有了那个让所有人都难受的形态：零件全部合格、系统不达标，而没有任何一份合同被违反。每一家都能拿出自己的零件级试验报告，每一份报告都是真的。这不是谁不讲理，是系统级指标没有主人——它落在几份合同之间，而「之间」不是任何一份 SOW 的覆盖范围。这与 1.2 里接口落在两个 WBS 之间是同一个结构，只是换到了商务这一侧。

定点直供件与客供件让这个结构再多一层麻烦：集成方要对系统结果负责，却对这个供应商既无价格杠杆也无更换权。如果 SOW 没有单独写清「指定件不满足系统需要时走什么路径、谁来决策、什么时限内给答复」，集成方就会同时承担全部责任与零手段——而这一条几乎总是在出事那一天才被发现没写。

这一节只指出三个必须做的动作，做法在后面。

① 系统级指标必须落到某一方的 SOW 上，并连同测试口径一起写死：在哪测（台架还是整车、哪个实验室）、什么工况（环境温度、湿度、载荷、车速谱、电池荷电状态）、什么判据（被测量、阈值、方向）、谁签署。⚠ 不写口径的系统指标等于没写——同一个「制冷量」在不同工况定义下不是同一个数，双方各按自己的口径测，两份报告都是真的、结论相反。SOW 该写哪五块内容，是第 3 讲的正题。

② 每一条零件级规格要标注它是从哪条系统级指标分解下来的，否则「零件合格」与「系统达标」之间的关系不可追：系统不达标时，你无法回答「该收紧哪个零件的哪一条规格」。需求怎么逐级分解见 B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件，分解关系怎么被工具维护住见 M1-04 需求管理与追溯（DOORS 等）。

③ 指定供应商件在 SOW 里单列一节，写清异常时的升级路径、决策人与答复时限。来料侧的质量控制手段见 M2-03 供应商质量与来料控制，供应商变更后要不要重新 PPAP 见 M2-01 质量工具：PPAP/8D/SPC/MSA。

工程量级与典型值。⛔ 本课不给供应商家数、不给关键件的分包比例、不给自主采购与定点直供的占比——它们取决于整车厂的采购策略、系统集成度与平台年代，须按本项目的 BOM 与采购策略确定。⚠ 也不要用「一般几家」去判断自己这个项目是不是「供应商太多」：家数本身不是风险指标，真正的指标是「有几条系统级指标没有落到任何一份 SOW 上」——这个数是可以在项目启动时就数清楚的，而且它与家数没有稳定关系。

易错点（三条）。

① 把「系统集成责任」写成一句口号。合同里写「乙方负责系统集成并保证系统性能满足要求」，读起来责任很清楚，实际上一条也判不了——「要求」是哪几条、按什么口径测、谁签署，一个都没写。⇒ 判据很简单：这句话能不能被判成「不满足」？不能，它就不是一条责任条款。

② 零件级规格谈得极细，系统级指标反而没有主人。这是最常见的形态，而且很不容易被发现——因为技术评审的注意力天然落在有数、有曲线、有报告的那一层，而系统级指标往往只在项目立项文件里出现一次，此后再没被分派过。

③ 把定点直供件当成「主机厂的事」。件是主机厂指定的，出了问题被追责的仍然是系统集成方——因为对用户和对整车而言，交付系统的是集成方。⇒ 无杠杆不等于无责任，正因为无杠杆，才更要在 SOW 里把升级路径写死。

1.4 被集成方：边界条件的定义权在别人手上，而结果的追责权指向自己

是什么。热管理在整车里通常处于一个特定的位置——本课把它叫作被集成方：它的边界条件几乎全部来自别人，而结果几乎全部记在自己账上。这不是一句抱怨，它是一条可以逐项核对的结构判断。先看输入这一侧，热管理的主要边界条件来自：

输入来自谁	具体是什么	去哪门课看它本身
电池	产热速率与分布、允许温度窗口、包内温差要求、快充倍率曲线	D1-01 动力电池产热机理与产热速率建模
电驱	损耗与散热需求、冷却液进口温度上限、工作点分布	E1-01 电机水冷（机壳水道）设计与换热强化
座舱	舒适性目标、降温与升温时间、风量与噪声约束	C1-01 汽车空调制冷系统原理与部件匹配
整车布置	可用空间、前端进风面积、管路走向与离地间隙	结构布置侧（见 1.1）
整车能耗与续航目标	分摊给热管理的能耗预算	B1-01 整车热平衡与全工况热负荷谱分析
电子电气架构	控制器落点、总线带宽、供电与唤醒策略	K4-01 热管理嵌入式软件架构与 AUTOSAR 基础

而热管理能反向定义这些的机会很少。它通常是在这些输入被别人定完之后才拿到它们，然后在给定的空间、给定的能耗预算、给定的温度窗口里想办法。

再看输出这一侧。整车层面被用户与法规真正感知到的那些量——续航（尤其低温续航）、快充时间、座舱舒适性、噪声、可靠性投诉——它们的根因链每一条都会穿过热管理。低温续航差，第一个被问的是热泵与加热策略；快充慢，第一个被问的是电池冷却能力；座舱不舒服、有异味、有噪声，直接就是热管理的事。

⇒ 把两侧放在一起，就得到本讲最重要的一个结构判断：输入的定义权在别人，输出的追责权指向自己。这个不对称是「接口话语权弱但责任重」这句话的精确形式，也是热管理项目管理与一个自成闭环的专业项目在管理上最根本的差别。

为什么这个不对称会具体地伤到项目。它有三个可以直接观察到的后果：

① 输入一变，热管理要重做，而这份重做的工作量不在对方的变更评估里。电池侧把快充倍率曲线往上调一档，对电池侧而言是一次参数更新；对热管理而言可能意味着换一个冷板方案、重新核算 Chiller 能力、重跑整套快充热试验。而对方在提交这次变更时，评估的是自己的影响。⇒ 这正是第 4 讲「接口变更的连带影响评估」要解决的问题，它的成立前提是这条接口已经被登记为一条有双方的条目——没登记过的输入，变更时不会有人想起来通知你。

② 热管理要求别人改的成功率低。在跨专业裁决里，能压过别人的理由通常只有安全与法规；热管理的诉求（多要一点前端进风面积、多要一点布置空间、把某个温度窗口放宽一度）在这类排序里天然靠后，因为它换来的收益是能效与体验，而付出的代价往往落在别人那一侧的硬约束上。这不是沟通技巧问题，是排序规则问题。

③ 冻结顺序上热管理往往靠后，于是承接的是既成事实。先冻的一方把自己的方案定死了，后冻的一方只能在剩下的解空间里找解；而热管理夹在电池、电驱、座舱、布置中间，几乎总是那个「后冻」的。第 4 讲会正面处理这件事，本讲先把话放在这里：冻结顺序是可以谈的，而且它比任何一条单独的参数值都值钱——谈赢了一个参数，你多了一点余量；谈赢了顺序，你多了整个解空间。

⚠ 这一节要防一个读反。把「被集成方」读成「所以热管理项目管不好不怪我们」。读者会做错的那个具体动作是：在项目例会上把延期与不达标归因为「上游输入迟迟不定」，然后停下来等输入——等电池给最终的产热数据、等布置给最终的空间、等整车给最终的能耗分摊。为什么这是读反：被集成方这个地位改变的是你要管什么，不是你要不要管。等来的输入仍然带着同样的不对称落到你头上，而这段等待的时间已经从你的关键路径上花掉了，且花掉的这一段没有任何证据留下——复盘时你说不清它是怎么没的。⇒ 正确动作是把还没定的输入当成有版本的假设条目登记下来，每一条写清四件事：假设值是多少、这个假设是谁提的、由谁在哪个节点确认成真值、如果它变成另一个值我这边哪些设计与哪些试验要重做。⛔ 假设条目不许只在口头存在，它必须与真实输入用同一套版本与签署规则管理——因为它最终会被替换成真值，替换那一刻要能追出「哪些东西建立在旧假设上」。这就是接口条目与变更影响评估的前身（第 2 讲讲变更评审闭环，第 4 讲讲接口条目本身）。

工程量级与典型值。⛔ 本课不给「输入平均延迟多久」「跨专业诉求的通过率」这类数——它们取决于组织形态、项目阶段与整车厂的决策机制，且没有可核对的公开统计，给一个数出来就是编。本课给的是结构判断，而这个判断在项目启动时就能问清楚，只要两个问题：我这门专业的边界条件由谁定义？整车层面哪些结果的根因链会穿过我？两张名单列出来，不对称的形状就摆在眼前了，不需要任何统计数据。

易错点（三条）。

① 把上游输入当成「已知条件」接收，不登记版本与提供方。输入被写进自己的设计文档就当成事实用了，没有记「它是谁给的、是哪一版」。⇒ 后果是输入变了没有人通知你，而你也无法证明自己当初是按当时的输入做的。

② 把「接口话语权弱」当成既定事实接受，不去争取冻结顺序。参数值谈不赢很正常，顺序却常常是可谈的——因为顺序对别人而言往往只是排期偏好，对热管理而言是解空间大小。⇒ 谈判要谈在别人成本低而自己收益高的那一项上，顺序恰好是这样一项。

③ 只登记数值型输入，漏掉时间型与状态型输入。温度、功率、流量这类数值型输入大家都记得登记；而「这个数据什么时候给」「给的是仿真值还是实测值」「是哪一轮样件上测的」这三类同样是输入，而且它们出问题的后果一点不轻——拿仿真值当实测值排试验计划、拿早期样件的数据去定量产判据，都是实撞得到的形态。⇒ 每一条输入条目至少带三个属性：值、来源性质（仿真／台架实测／整车实测／上一代沿用）、样件轮次。

1.5 三个来源不是三件事，它们决定了后面四讲各对付哪一段

是什么。把 1.1 到 1.4 收一下，热管理项目相比一个单一专业的项目，额外多出来的复杂度有三个来源，而它们各自要求一类不同的管理动作：

复杂度来源	它的机理	它要求的管理动作	在本课的哪一讲
① 接口按组合数长	接口落在两个 WBS 之间，天然无主	给「之间」的事显式指派责任人；把接口变成有版本、有双方签署的条目并谈好冻结顺序	第 3 讲（责任矩阵）、第 4 讲（接口控制文件与冻结）
② 供应商多头	性能是合成的、合同是逐家签的，粒度对不上	把系统级指标连同测试口径落到某一方的工作说明书上；建双方共同维护的协同机制与问题清单	第 3 讲
③ 被集成方	输入的定义权在别人、输出的追责权指向自己	输入变化时要有能判、能算代价、能拒绝的变更评审闭环；供应端出事时要有事先定好决策人与时限的预案	第 2 讲（铁三角权衡与变更评审）、第 5 讲（风险与断供应急）

⚠ 这张对应表是本课归纳的组织方式，⛔ 不是任何标准或体系文件的既有框架。它的用处不是分类本身，而是选工具：碰到一个具体麻烦时，先判它属于哪一个来源，再去用对应那一类的工具。用错的典型是——把一个属于来源②（系统指标没主人）的问题，当成来源①（接口没定义清楚）去处理，于是接口文件越写越厚，而那条系统指标依旧没有人负责。

为什么要先分类再动手。因为这三类问题看起来很像：它们都表现为「出了事没人认」。但它们的修法方向不同——来源①要补的是属主与条目，来源②要补的是SOW 的覆盖范围与测试口径，来源③要补的是变更来临时的评估与决策机制。⛔ 三者不能互相替代：给系统指标补一份再详细的 ICD，也不会让它有主人；给接口补一条再严的 SOW 条款，也不会替代冻结顺序的谈判。⇒ 分类是为了不把力气花在不解决问题的那一侧。

工程量级与典型值。⛔ 本课不给「三类问题各占多少比例」这样的数——没有可核对的统计来源，且它必然随组织形态与项目阶段变化。可以给的是一条与平台无关的清点方法：拿本项目的问题清单（第 3 讲会讲它怎么建），把每一条已经发生过的争议按上表的三个来源归一次类，归不进去的单独放一堆。⚠ 归不进去的那一堆值得单独看——它要么说明本课这张三分表在你这个项目上不完整（那就补一行，并写明它是你补的），要么说明那几条根本不是协同问题而是技术问题，该退回技术侧解决。

本讲的三句自检问句。它们可以在任何一次项目例会上当场问出口，而且答不出来时缺的是什么非常具体：

① 这条接口的属主是谁、版本是几、冻结在哪个节点？——三个里答不出一个，它就还不是一条接口条目，只是一次口头共识；口头共识在变更时不会触发任何通知。（对应来源①）

② 这个系统级指标写在谁的工作说明书里、按什么口径测、谁签署？——答不出来，就意味着当所有零件都合格时，它没有主人。（对应来源②）

③ 这条输入是谁给的、是哪一轮的哪种值、它变了我这边要重做什么？——答不出第三问，说明这条输入还没有被当成接口来管，它只是被抄进了你的文档。（对应来源③）

⚠ 这三问的共同点值得单独说一句：它们问的都不是「做到了没有」，而是「说得出来吗」。项目例会上「做到了没有」这类问题的答案几乎总是「在推进中」，而「说得出来吗」这类问题只有两种答案——说得出或者说不出，⛔ 没有中间态。这是本课挑选管理动作时反复用到的判据：一个管理动作有没有用，看它有没有把某件事从「主观评价」变成「可以当场判定」。第 2 讲讲变更评审时，第一件事就是把「这个变更影响大不大」这个主观问题，换成一组可以逐项作答的问题。

本课与相邻课的分工，先在这里划清。研发流程本身的阶段划分与里程碑门禁不在本课射程，见 M1-01 汽车研发流程（APQP/IATF16949）与热管理里程碑；验证计划的编制与管理见 M1-03 DVP&R 与验证计划管理；需求怎么逐级分解见 B1-02 需求逐级分解：整车 VTS → 系统 SSTS → 零部件、分解关系怎么被工具维护见 M1-04 需求管理与追溯（DOORS 等）；跨部门协同的沟通与工作方法见 Q2-04 跨部门（整车/电子/结构/软件）协同工作法；技术协议与商务条款的谈法见 Q2-02 主机厂—供应商技术对接与商务谈判；控制软件跨企业交付的边界与安全工作产物的归属见 K4-09 热管理控制软件的跨企业交付边界：交付物形态、DIA/SEooC、权限分级与联合验证签署；量产阶段的变更控制与再验证范围判定见 M2-06 量产阶段变更控制：4M 变更申报、再验证范围判定与量产断点切换，变更点差异分析见 I7-05 变更点失效分析（DRBFM）与变更评审。⛔ 本课不重讲这些内容，只在需要时给去向。