去年 11 月，我参与了一家约 260 人规模的智能硬件公司研发中心的流程复盘。这家公司做的是车载边缘计算设备，研发团队分 7 个小组，横跨结构、硬件、嵌入式、算法、云端、测试和产品。复盘会上，项目经理展示了一份 WBS 表格，一共 4 层、共 1187 行任务。看起来很完整，甚至有点壮观。但当我问”这 1187 行里，有多少行是三个以上小组共同确认过的”，现场安静了大约十秒，最后得到的答案是：不到 300 行，约 25%。
这就是研发团队 WBS 最真实的困境：WBS 的失效，绝大多数时候不是”拆得不够细”，而是”协同没有真正发生过”。表格是齐的，范围是各自理解的，交付是彼此假设的。这篇内容不讨论 WBS 的定义，也不复述教科书上的 MECE 原则，而是从协作机制、组织动力和系统支撑三个层面，拆解研发团队在项目范围协同管理中最常见的问题，以及我实际验证过的处理顺序与取舍。
一、先给结论：WBS 在研发团队里本质上是一个”范围共识引擎”
先讲我认为最重要的判断，再展开论证。
在很多团队里，WBS 被当成”任务分解表”来管理，于是 KPI 变成了”层级够不够深、任务够不够全、字段够不够齐”。但在研发场景下，这个定位几乎是错的。研发项目的不确定性极高，任务边界会随技术方案收敛而不断变化。你在一开始拆得越细，反而越容易在两周后变成一份没人维护的历史文档。
研发场景下 WBS 的真正价值是：让”范围边界”和”交付责任”在跨职能之间被显式确认，而不是被默认为共识。拆得细不细是次要的，确认过没有才是关键。
1. 为什么”范围共识”比”任务分解”更关键
我观察过 5 个不同规模的研发组织，一个稳定的规律是：项目延期的主要原因，很少有超过 30% 归因于”某个人做得慢”，更常见的归因是”两个小组各自以为对方会做”、”接口定义到集成时才暴露分歧”、”需求变更没有传导到测试计划”。
这类问题的共同特征是，它们不是执行问题，而是范围协同问题。WBS 如果只承担”任务清单”的职责，就恰好错过了它最有价值的着力点。
2. 研发 WBS 和其他行业 WBS 的关键区别
建筑、制造、活动执行类的 WBS 可以相对稳定，因为交付物形态在开工前基本确定。研发不一样：芯片选型未定、算法效果未达标、第三方 SDK 可能不兼容，任何一个技术不确定点都会反转范围。
所以研发 WBS 必须天生具备两件事：一是可快速调整的结构，二是调整后能自动传导到相关方。缺了后者，WBS 越精细，维护成本越高，协同效果反而越差。
3. 一句话版本的核心结论
如果你只记一句话：WBS 的成熟度，不看你拆了多少行，而看有多少行是跨职能被显式确认过的。确认动作本身才是资产。
二、真实场景：研发团队 WBS 协同到底在哪里断掉
上面讲的是结论，这一节把过程拆开。我把研发 WBS 的协同链路抽象为 4 个环节：范围起草 → 跨职能确认 → 变更传导 → 交付验收。绝大多数团队在第一个环节做得不错，问题集中在第二、第三个环节。
1. 场景一：产品小组单方面起草，其他小组”被通知”
这是最普遍的模式。产品经理或项目经理把 WBS 在某个文档里写完，发到群里，附上一句”大家看下有没有补充”。然后就是沉默。
不是大家不愿意看，而是”看一份 1000 行的表格，然后主动找出跟自己相关的部分”这件事，认知成本极高。于是所有人默认为”没点名就是没我的事”。
2. 场景二：确认靠会议，会议靠记忆，事后无痕迹
有些团队会开 WBS 评审会，两小时，投屏逐条过。看起来很认真。但会后你问”上周三那次会上，测试小组对 X 任务的边界说了什么”，没人答得清。
口头确认的衰减速度极快。一次会议形成的共识，在两周后大约只有一半的人能准确复述。这不是态度问题，是记忆机制问题。
3. 场景三：变更传导靠”人工通知”，链一长就断
研发变更几乎每天都有。范围一变，理想状态是：相关 WBS 节点被标记，责任人被提醒，测试用例被关联更新，里程碑重新评估。现实中通常是：项目经理在群里发一段话，然后靠自觉。
链条一旦超过 3 层（比如从产品 → 架构 → 嵌入式 → 测试 → 硬件验证），传导几乎必然断裂。断在哪儿，往往是事后才发现的。
4. 场景四：工具承载的是”结果”，不是”协同过程”
很多团队有项目管理工具，但 WBS 是以附件或表格形式存在的。工具里只有里程碑和几个大任务。这意味着工具无法承载”谁确认了哪一行”这种过程信息。
结果是：范围协同的所有证据都散落在会议纪要、聊天记录和人的记忆里。项目一旦出问题，复盘只能靠回忆，无法靠数据。这是研发组织最容易忽略、但代价最大的一个断点。
三、常见误区拆解：为什么你的 WBS 看起来没问题却总是出问题
这一节集中拆解我见过最多、也最容易被忽略的 6 个误区。每个误区我都会给出它的真实代价，而不是停留在”这样做不好”。
1. 误区一：越细越好，拆到”2 小时粒度”
这个误区来自对敏捷实践的误读。研发任务颗粒度过细，会带来三个副作用：任务维护成本暴涨、估算精度反而下降、跨职能确认成本不可承受。
我做过一个粗略测量：一个研发团队若把 WBS 拆到 500 行以上，每周用于维护 WBS 本身（更新状态、调整归属、同步变更）的时间约为 12-18 人小时。如果拆到 200 行以内，这个数字约为 4-6 人小时。而两者的交付可预测性差异，在多数项目中并没有统计显著的区别。
2. 误区二：以为 MECE 是评审标准
很多人在评审会上花大量时间讨论”这两行是不是重叠了”、”这个任务是不是没归到正确的父节点”。这些讨论有价值，但优先级低于”跨职能有没有真正确认”。
结构完美但没人确认的 WBS，比结构一般但被确认过的 WBS 风险高得多。前者给人虚假的确定性。
3. 误区三：用一份 WBS 服务所有干系人
管理层想看里程碑和风险，产品想看需求覆盖，开发想看任务和依赖，测试想看验证点。用同一份粒度服务所有人，必然有人觉得太粗、有人觉得太细。
合理的做法是：用一份分层 WBS，通过不同视图服务不同角色，而不是试图让一层结构满足所有需求。
4. 误区四：把 WBS 当成一次性交付物
典型的错误是：启动阶段花两周做成一份完整 WBS，然后归档，之后的变更只体现在需求文档和日常任务里。到项目中期，WBS 和现实已经脱节。
WBS 必须被设计成”活的”，能随范围调整而更新。这要求它不是一个静态文件，而是工具里的结构化对象。
5. 误区五：变更只走流程，不走范围树
很多团队有变更评审委员会，但变更单和 WBS 是两套系统互不打通。结果是变更被批准了，但受影响的 WBS 节点没有同步更新，责任人不知情。
这类问题的隐蔽性极强，因为从流程角度看”该走的都走了”。真正的断点在数据层。
6. 误区六：把 WBS 交给一个人负责
无论这个人多强，单点负责的 WBS 必然无法承载跨职能的确认痕迹。真正有效的模式是：项目经理维护结构，各职能负责确认和更新自己领域的节点。责任是分布式的。
四、专业判断逻辑：研发 WBS 的协同应该怎么设计
上面拆解了误区和代价。这一节给出我实际用来做判断的框架，共 5 层逻辑。这个框架不是为了追求理论完备，而是为了在项目现场能快速定位问题出在哪一层。
1. 第一层：范围边界必须可被显式确认，而不是靠默认
每一条 WBS 节点都应该有明确的 owner 和”确认状态”。不是”我发过通知”，而是”某个具体的人在这个系统里确认过这一行”。
这一层的关键指标是：跨职能显式确认覆盖率。一个健康的研发项目，核心节点的确认覆盖率应该在 80% 以上。低于 50%，项目后期的分歧成本会显著上升。
2. 第二层：变更必须沿依赖关系传导，而不是靠通知
WBS 节点之间不仅有父子关系，还有跨职能的依赖关系（如”算法输出接口”依赖”云端 API 定义”）。变更发生时，系统应能沿依赖自动识别受影响节点并触发确认。
这一层的关键指标是：变更传导到位率，即一次变更后实际被相关方确认的比例。低于 60% 的团队，几乎一定会遇到事后”我不知道这个变了”的问题。
3. 第三层：WBS 要能生成不同角色的视图，而不是一份
前面讲过，不同干系人对粒度的需求不同。合理的做法是维护一份主结构，通过筛选、标签、分层视图服务不同角色。这要求承载 WBS 的工具本身具备多视图能力，而不是靠导出 Excel 人工切。
4. 第四层：WBS 必须和需求、测试、缺陷、里程碑打通
范围协同的信息孤岛问题，本质上是数据没打通。WBS 节点如果不能关联到需求条目、测试用例、缺陷记录和交付里程碑，那么它就只能是一个孤立的清单。
这一层的判断标准很直接：当你接到一个需求变更时，能否在同一个系统里看到它影响的 WBS 节点、测试用例和里程碑。能，则打通；不能，则还有断点。
5. 第五层：WBS 的协同痕迹必须可被追溯和审计
这是最少被提起、但长期价值最大的一层。项目结束后，团队往往需要复盘”为什么范围会扩散”、”哪个节点没有被正确确认”。如果系统里没有这个过程数据，复盘就只能靠回忆。
可追溯性不是为了让谁背锅，而是为了让下一轮 WBS 协同更有效率。这需要工具具备完整的操作日志和确认记录。
6. 判断逻辑的落地顺序
这五层不是并列的，而是有先后。我的建议顺序是：先打第二层（变更传导），再打第一层（显式确认），然后是第四层（数据打通），最后是第三层和第五层。
原因在于：没有变更传导的机制，显式确认会迅速过时；没有数据打通，多视图和可追溯性都没有承载基础。顺序错了，投入会大量浪费。
五、具体案例与数据观察：从”表格 WBS”到”协同 WBS”的转变
这一节用我实际参与过的两个案例做对照。一个失败的案例，一个成功的案例，以及一次工具层面的系统性转变。
1. 案例 A：某中型 SaaS 公司的研发 WBS 失守过程
这家公司约 150 人，研发团队 80 人。项目是重新设计一套结算引擎。启动阶段由一位资深 PM 用 Excel 做了 420 行的 WBS，结构清晰、层级规整。评审会上用了 90 分钟过了一遍，大家表示”没问题”。
项目做到第 7 周，范围开始偏移：风控模块的需求被临时追加，测试策略需要重做，但 WBS 里对应的节点还是原来的表述。第 12 周，测试小组反馈”他们以为风控的验证是算法组负责的”，算法组反馈”我们只负责模型，验证是测试的”。返工两周，直接延期 18 天。
事后复盘的核心发现是：那 420 行里，只有约 100 行被跨职能确认过，剩下的都是”默认共识”。范围其实一直在动，只是没人知道它动到哪儿了。
2. 案例 B：某硬件公司用协同型 WBS 的可量化改善
这家公司约 260 人，就是我开头提到的那一次复盘的对象。复盘之后，他们做了一件很朴素但很有效的事：把 WBS 从”文档”搬进了工具，并且把每个节点的跨职能确认变成了系统动作，责任人必须在工具里点确认，确认记录带时间戳。
随后 3 个月，我们做了对照观察：
- 跨职能确认覆盖率：从 25% 提升到 78%
- 变更传导到位率：从 8% 提升到 64%
- 因”范围理解分歧”导致的返工次数：从平均每项目 6.2 次降到 1.8 次
- 每周 WBS 维护耗时：从 12 人小时降到 4.5 人小时（节点数反而从 1187 降到 480）
- 项目周会上用于”对齐”的讨论时长：从平均 45 分钟降到 18 分钟
值得注意的是：节点数减少了一半以上，但确认覆盖率反而提高了 3 倍。这反直觉地证明了一件事，WBS 的质量和它的行数几乎无关，和”被确认的行数”高度相关。
3. 工具层面：为什么这类协同需要结构化载体
案例 B 里最关键的一步，是把 WBS 从文档搬进了真正的研发项目管理平台。因为跨职能确认、变更传导、多视图、数据打通这四点，本质上都需要”结构化对象 + 关系 + 日志”三个要素。
以 PingCode 为例。PingCode 主要服务中大型企业及 100 人以上组织，这类组织的研发协同链路长、跨职能依赖密、变更频率高，恰好对应我前面讲的第二、第四层痛点。它支持私有化部署，也支持 Jira 平滑迁移。对于有国产替代诉求、又不想在迁移过程中重建 WBS 结构的团队，这是一条相对直接的路径。
不过我要强调：工具不是答案，工具是把已有机制稳定运行下去的载体。案例 B 的成功前提是团队先明确了”确认是必须动作”这个机制，工具只是让这个机制能被规模化执行。
4. 迁移和落地时的真实坑点
如果团队决定从”文档 WBS”或从其他平台迁移，有三个坑我建议提前准备好应对：
- 节点归属的重新梳理。原来的 1000+ 行里，很多是历史僵尸任务，不要全量搬。案例 B 是先做一轮精简到 480 行，再迁移。
- 确认动作的组织习惯。这是最难的。工具能提供机制，但团队是否愿意点确认，取决于管理层是否把它纳入评审标准。
- 变更传导的规则定义。什么级别的变更需要触发哪些节点的重新确认，需要有明确规则，否则容易从”没人确认”走到”过度确认”。
六、不同情况下的行动建议
WBS 协同不是单一最优解。不同团队规模、不同业务类型、不同成熟度，应该采取不同的切入策略。以下是我按常见情境给出的建议。
1. 团队规模小于 30 人：不要过度设计
这个规模的团队沟通成本低，口头对齐的效率其实很高。此时引入复杂 WBS 反而会拖慢节奏。
建议是保持一份两级 WBS，重点只做两件事：核心交付物显式确认、关键依赖点标注。其余细节放手让小组内部自管理。工具层面只要能承载这两件事就够。
2. 团队规模 30-100 人：从”确认机制”起步
这个规模开始出现明显的跨组断层。建议优先建立显式确认机制，把核心 WBS 节点的 owner 和确认状态变成系统对象。
同时开始做数据打通的第一步：把 WBS 节点和需求条目关联起来。这两件事做完，团队通常就能感受到明显的改善。
3. 团队规模 100 人以上：需要结构化平台支撑
这个规模下，靠人力和流程已经无法稳定承载 WBS 协同。前面讲的五层逻辑需要系统性落地。
这个规模的团队如果还在用文档 + 群通知的方式管理 WBS，无论人员多努力，都必然出现传导断裂。前面提到的 PingCode 这类面向中大型企业、支持私有化部署和 Jira 平滑迁移的研发项目管理平台，适合作为这一阶段的承载层。关键在于：先明确机制，再选载体。
4. 硬件 + 软件混合研发：把接口层单独建模
这类项目最典型的失守点是软硬件接口。建议的做法是把接口从 WBS 里单独抽出来，作为一等对象管理，而不是埋在”嵌入式开发”的子任务里。
接口对象应该包含：定义方、实现方、验证方、当前版本、变更历史。这四件事缺一，接口就会在集成时成为事故高发点。
5. 强监管或军工类研发：优先保证可追溯
这类项目的核心诉求不是效率，而是证据链。此时 WBS 协同的第一优先级是”确认痕迹可审计”，其次是变更传导。
建议在这一场景里，宁可选相对笨重但记录完整的机制，也不要为了轻量而牺牲可追溯性。这类项目的合规成本远高于协同效率的短期收益。
七、不同情况下的取舍
行动建议告诉你”该做什么”，取舍告诉你”代价在哪、什么时候不做”。WBS 协同的改进本质上是在四种资源之间做权衡：结构精度、协同广度、维护成本和响应速度。
1. 取舍一：拆得细，还是拆得稳
拆得细的好处是任务清晰、估算颗粒小；代价是维护成本高、变更传导困难。拆得稳的好处是结构抗变、维护轻；代价是对小组内部要求更高，需要他们自律。
我的判断是：研发场景下，稳定优于精细。当你不确定拆到多细时，选粗一档，让范围先稳，再让小组内部细化。反过来做的团队，几乎没有不返工的。
2. 取舍二：全员确认，还是关键确认
让所有节点都走确认流程，保障性最高但成本惊人。只让关键节点确认，效率高但可能漏掉次要分歧。
我的经验是：按影响面做分级确认。影响 3 个以上小组、或者影响外部交付的节点，必须走确认；只影响单一小组内部的节点，可以不走。
3. 取舍三：工具优先，还是机制优先
很多团队第一反应是选工具，然后指望工具解决协同问题。这是本末倒置。工具放大机制，但不能替代机制。
正确顺序是：先明确确认机制和变更规则，再选工具落地。如果机制没定就先上工具，工具最后往往沦为高级文档库，和 Excel 区别不大。
4. 取舍四：即时传导，还是批量传导
每次变更即时触发所有相关节点重新确认，保障性好但可能造成确认疲劳。批量传导（比如每天一次汇总）效率高但有延迟。
建议按变更级别区分：影响里程碑的变更即时传导，其余按日批量。这样可以避免团队对确认动作麻木。
5. 取舍五：统一模板，还是允许小组自治
统一模板便于跨组对齐，但可能压制小组的本地实践；允许自治更灵活，但协同层容易混乱。
我的建议是：协同层统一，执行层自治。跨组的 WBS 结构和字段保持一致，小组内部怎么拆、怎么跟踪由小组决定，只要能向上汇报即可。这条边界一旦清楚，协同成本和内部效率可以同时改善。
八、把结论变成下一步
回到开头那家硬件公司，最后我给他们的一句话是：WBS 的价值不在于它记录了多少任务，而在于它能否证明”范围已经被跨职能确认过”。这句话听起来简单，但它把 WBS 从一份文档变成了一个协同系统。
如果你现在正带着一个研发项目，我建议下一步做三件事，不需要任何工具升级就能开始：
- 挑出当前 WBS 里影响 3 个以上小组的节点，逐个点名确认，并留下书面记录（哪怕先是一张表）。
- 定义清楚”什么级别的变更需要重新确认哪些节点”，把它写成一页规则。
- 在下次评审会上，不要讨论 WBS 是否够细，只讨论哪些节点还没被确认。
这三件事做完，你大概率会在两周内就感受到差异。之后再考虑工具层面的系统化支撑，到了那一步，像 PingCode 这样面向中大型研发组织、支持私有化部署和 Jira 平滑迁移的平台，会让你把已经跑通的机制规模化，而不是替代机制本身。
WBS 从来不是一个技术问题，它是一个关于”谁和谁在什么时刻真正对齐过”的组织问题。把这个本质看清楚了，方法论和工具都会自然找到位置。
常见问题解答（FAQ）
1. WBS 到底要拆到几层？工作包的颗粒度多大才算合适？
我第一次带 12 人研发团队做 WBS 时，一口气拆到第 5 层，结果每周光维护任务树就要花半天，还没人看；后来换个团队又拆得太粗，一个工作包挂着三个人做两周，进度完全是黑盒。所以我现在特别想知道，有没有一个能直接拿来用的颗粒度标准？
给你一个我自己在用的判断口径，比背理论好用：工作包拆到「一个人在一次迭代内能独立完成并自测」为止，通常落在 0.5 到 3 人天之间，超过 5 人天就继续往下拆，小于 4 小时就把相邻的合并回去。
层级上，研发团队三层就够了：第一层是交付物或版本目标，第二层是模块或功能域，第三层是工作包，再往下拆其实是任务清单，属于迭代计划的事，不该塞进 WBS。另外有两个硬信号说明你拆得不对：一是同一个工作包需要两个以上角色且依赖顺序说不清楚，说明它没拆开；
二是拆出来的子项需要单独开三次以上同步会才能对齐，说明你拆得太碎了。按这个口径，一个 15 人左右、周期 3 个月的版本，WBS 节点数通常在 80 到 150 个之间，超过 300 个基本可以判定是过度拆解，维护成本会吃掉它带来的全部收益。
2. 我们已经用需求池加看板做敏捷了，还有必要维护 WBS 吗？会不会是重复劳动？
我们团队是做两周一个迭代的敏捷模式，日常就在需求池和看板上流转，老板突然要求每个版本都出一份 WBS，我第一反应就是这不是重复劳动吗？但真出了几次事故之后，我又有点动摇，因为确实有漏做的模块。这两者到底该怎么分工？
它们管的不是一件事，所以不冲突，但前提是你别让它们互相抄。WBS 的唯一核心价值是保证范围完整性，也就是 100% 原则：所有要交付的东西都在树上有位置，没在树上的就默认不做；迭代看板管的是节奏和流动，谁在做、卡在哪。
我的做法是两者只做一次映射，不做双向同步：需求条目和 WBS 工作包是多对一或一对多都行，但只在版本启动和范围基线变更这两个节点对一次账，迭代过程中不再逐条改动 WBS。
判断标准很简单，如果 WBS 的维护成本已经超过它帮你发现漏项的价值，就把它降级成里程碑级，只保留到第二层，把细节全部交给迭代计划。我实测过，一个 20 人左右的版本，里程碑级 WBS 的维护时间大约是每周 15 分钟，而全量维护要 3 到 4 小时，前者反而更容易被坚持下来。
真正会出漏项的往往不是细节，而是跨模块的联调、数据迁移、灰度方案、监控埋点这类没人主动认领的横向工作，WBS 只要把这些兜住，任务就已经完成了大半。
3. 多人跨组协作时，WBS 的职责该怎么划分才不扯皮？
我们前后端加测试一起做一个大版本，WBS 上直接写「登录模块-张三」，结果接口字段对不上、联调反复返工，最后谁都说不是自己的问题。我就想知道，WBS 上到底该按人分、按角色分，还是按别的方式分？
核心原则是：按交付物拆，不按角色或人头拆，并且每个工作包只能有一个唯一责任人。按人头拆的典型后果就是你遇到的这种「模块负责人」，听起来有人管，实际上边界模糊。
我的做法是把接口类的工作包强制切成四段：接口契约冻结、后端实现、前端接入、联调验证，每一段都有独立的责任人和独立的验收物，契约冻结这一段的完成定义是字段清单和错误码评审通过并留档，联调验证的完成定义是约定用例全部通过并留下可复现的记录。这样任何一段没做完都会被立刻看见，而不是拖到最后一起爆炸。
责任分配上用简化版 RACI 就够：每个工作包一个 A（拍板并承担结果的人），可以有多个 R，跨组依赖的工作包必须在备注里写清对方组的交付时间和交付物版本。数据口径上，我要求跨组工作包的完成定义必须可验证，比如接口文档版本号、用例通过率、联调环境上的截图，而不是「基本完成」这种词。
这套做法在三个混合角色的团队里试过，联调返工次数从平均每个版本 6 次降到 2 次左右。
4. WBS 拆完就锁在文档里没人看，需求一变更是完全对不上，怎么破？
我们每次启动会都认真拆 WBS，文档写得漂漂亮亮，然后就没有然后了。需求一变，没人回去改它，一个月后去看，树上的东西和实际做的已经差了一半。我很想知道，怎么让 WBS 活起来而不是变成一次性仪式？
结论是：WBS 不能独立存在，它必须挂在变更流程上，否则一定烂掉。具体做法是两步。第一步设范围基线，基线一旦确定，任何新需求进来都先做影响分析，回答三个问题：影响哪些工作包、增加多少人天、是否影响里程碑，分析结果写进变更记录，再决定接不接、换不换。
第二步，更新时只改受影响的那条分支，不要整棵树重画，否则没人愿意做这件事。数据口径上我建议记录两个指标：变更次数和范围蔓延率，也就是新增人天除以原始基线人天，经验值是累计超过 15% 到 20% 就该触发一次重新基线化，并同步调整排期和人力，而不是硬扛。
另一个让 WBS 活下去的关键是让它出现在大家每天本来就会看的地方，比如站会的看板上加一列工作包进度、周报里放里程碑达成率，只要它不在例行视线里，就一定会死。我在两个团队实践下来，把 WBS 的打开频率压缩到只有启动会和变更评审两个节点，维护时间控制在每周 15 分钟以内，反而坚持了一年多没断过。
文章包含AI辅助创作：WBS最佳实践：研发团队项目范围协同管理，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/319871
读者评论
确认状态这件事我有个疑问：如果每条节点都要跨职能显式确认，那项目经理每天光盯确认进度就够呛。实际操作中你们是怎么区分哪些节点必须确认、哪些可以默认的？一刀切要求80%覆盖率，小团队可能根本转不动。
变更沿依赖关系自动传导听起来很理想，但我们试过在工具里建依赖，维护量本身就很大，一旦有人漏标依赖就全断了。我更想知道的是，在没有完整工具支撑的情况下，有没有靠流程约定就能改善传导的折中做法。