延期原因实操方法：项目经理提升延期管理效率的入门指南方法与模板

2021 年秋天，我接手一个已经延期 47 天的制造行业 MES 实施项目。复盘会上坐了 12 个人，讨论了 3 个小时，最后写进系统「延期原因」字段的只有四个字：需求变更。三个月后，同一批人、同一类项目，又延了 33 天，原因字段依然是「需求变更」。那一刻我才真正意识到，延期原因这件事，我们一直在做「记录」，从来没有做「设计」。记录是被动的，设计是主动的：前者只能在事后收集说法，后者能在事前埋下信号。

这篇指南讲的是后者，一套我从十几个延期项目里磨出来的采集口径、分类字典、判断逻辑和模板，包括我在 100 人以上组织里落地时踩过的具体坑。

一、核心结论：延期原因不是复盘出来的，是设计出来的

先把结论摆在前面，后面再用场景和数据把它拆开。如果你的团队每次复盘都能得出「需求变更」「人力不足」「测试环境不稳定」这三句话，问题不在团队不认真，而在你的原因采集体系从设计上就只能产出这三句话。

1. 三个反常识结论

第一，延期原因的最大价值不在事后，而在事中的发现时点。一个延了 5 天但第 1 天就被发现的项目，比一个延了 2 天但交付前一周才暴露的项目健康得多。前者还有腾挪空间，后者只能砍范围或者让全员加班。

第二，「需求变更」这类高频原因，本质是分类体系失效的信号，不是真相。我在自己的样本里做过统计：当某一个原因分类的占比超过 30%，这个字段的信息量基本归零。它变成了一个垃圾桶，谁都能往里扔，扔完谁都不用负责。

第三，延期原因要能翻译成「天」，否则它没有管理价值。「需求变更」不是原因，是现象。真正可管理的原因是「变更在第 3 次评审后才提出，此时已完成 60% 的设计工作，返工需要 9 人天」。前者只能用来抱怨，后者可以用来排优先级。

2. 我只看一个核心指标：延期健康度

大部分人统计的是「延期项目数」「平均延期天数」「延期率」。这三个指标都是结果指标，等项目结束才知道，对下一个项目没有任何帮助。我更关心一个过程指标：

延期健康度 = 发现延期时剩余的浮动天数 ÷ 计划总工期 × 100%

浮动天数就是你原本留的缓冲。举个具体数字：一个计划 60 天的工作项，你留了 9 天缓冲。如果第 12 天就发现进度落后，此时剩余缓冲 8 天，健康度约等于 13%，属于「观察区」，还有机会靠调配资源追回来。如果第 48 天才发现，剩余缓冲 0 天，健康度 0，这就不是延期管理问题了，是救火问题。

我给自己定的判断阈值是：健康度大于 20% 为可控，10% 到 20% 需要项目经理介入，低于 10% 必须升级到项目集层面决策。这个指标的好处是它能在项目还没结束时告诉你风险，而不是在结项报告里告诉你遗憾。

3. 原因数据的「三可用」标准

一条延期原因记录，必须同时满足三个条件才算可用，我在内部叫它「三可用」：可归类、可归因、可干预。

• 可归类：能落进一个不超过 12 个叶子节点的分类字典，且不落进「其他」。
• 可归因：能定位到具体的工作项、具体的责任方、具体的发生时间点，而不是「某个阶段」。
• 可干预：能对应到一个具体的动作，比如加一次需求冻结评审、把接口联调提前两周、给某个模块加 15% 缓冲。

三条缺一条，这条数据就只是文字，不是资产。我见过太多团队把延期原因填得很满，但一条都过不了「可干预」这一关，结果第二年复盘时说的还是去年那几句话。

二、真实场景：为什么你的延期复盘永远停在「需求变更」

要解决问题，先看清楚数据是在哪一步失真的。我把延期数据在组织里的流转拆成四段，每一段都有典型的失真方式。

1. 一个 47 天延期的复盘现场还原

回到开头那个项目。我把当时的复盘记录翻出来，12 个人给出的原始说法是这样的：

• 开发负责人说：需求改了三次，接口文档到第四周才定稿。
• 测试负责人说：提测版本比计划晚了 11 天，压缩了我们的测试窗口。
• 实施负责人说：客户那边的网络割接窗口排不上，环境迟迟开不出来。
• 销售说：客户中途换了对接人，新对接人对验收标准理解不一样。
• 项目经理说：我每周都在追，但没人告诉我到底能不能按时交。

这五句话里，其实藏着五种完全不同性质的原因：需求侧、执行侧、环境侧、决策侧，以及一条被所有人忽略的「信息反馈失效」，项目经理每周追问却拿不到准确进度，这才是 47 天里最致命的那个原因。

但最后填进系统的只有「需求变更」。为什么？因为系统里的原因字段是一个单行文本框，没有分类、没有必填校验、没有关联工作项，填写成本最低的选项永远是那个最笼统的词。

2. 延期数据在系统里的三种失真

（1）字段失真：原因字段是自由文本

自由文本听起来最灵活，实际上是数据质量的头号杀手。同一件事，十个人能写出十种表述：「需求变更」「客户改需求」「范围调整」「甲方加了功能」。做统计时它们分属四个类别，做归因时一条都对不上。

（2）时点失真：只记录延期天数，不记录发现时点

大部分项目管理工具里，延期体现为「完成日期晚于计划日期」，这是一个只有两个时间点的记录：计划完成日、实际完成日。中间那几十天发生了什么，完全没有留痕。于是你永远不知道这个项目是「一路都在预警但没人管」，还是「一直正常，最后一周突然崩了」。这两种情况的改进动作完全相反。

（3）归属失真：原因挂在项目上，不挂在工作项上

一个 60 天的项目延了 20 天，原因写在项目层级，于是所有人都觉得「是整个项目的问题」。但真实情况往往是：三个工作项各延了 7 天，其余 40 个工作项准时完成。把原因下沉到工作项层级，你才能看到「哪一类工作最容易延」，而不是笼统的「这个项目管理不善」。

3. 不同规模组织的延期特征完全不同

我服务过的组织从十几人的创业团队到近千人的集团 IT 部门，延期原因的分布差异极大，这一点很多方法论文章不会讲。

• 20 人以下：延期原因高度集中在估算侧。因为人少、沟通链路短，需求变更能在半小时内同步到所有人，反而是「这个功能到底要几天」永远估不准。
• 20 到 100 人：需求侧和估算侧各占一半。这个阶段开始出现专职产品经理，需求变更有了正式流程，但流程本身成了新的延迟源。
• 100 到 500 人：依赖侧原因快速上升，通常能占到三成。跨部门、跨产品线的接口联调成为主要瓶颈，单个团队再努力也没用。
• 500 人以上：决策侧原因占比显著抬升。资源在多个项目集之间调配，优先级一周一变，一线团队频繁做无用功。

所以我不建议任何团队直接抄别人的原因分类表。分类字典必须和你的组织规模、项目类型匹配，否则你统计出来的是别人的问题。

三、常见误区：八个把延期管理做废的动作

下面这八个误区，我在不同公司反复见到。它们单看都不算错，组合在一起就会让延期管理彻底空转。

1. 误区一：把原因字段当成复盘结论

复盘会开了三小时，最后产出是一个下拉选项。这等于把一场讨论压缩成一个字，投入产出比极低。原因字段应该记录的是「结构化标签」，复盘纪要应该记录的是「为什么这个标签会被打上」。两者不能互相替代。

2. 误区二：分类层级做得太深

我见过一个团队的原因分类有三层，叶子节点 47 个。结果是：填报人平均要花 90 秒找一个选项，最后大家都选第一层的第一个。分类越细，数据越假。我的经验值是叶子节点控制在 8 到 12 个，最多两层。需要更细的信息，用标签和备注补充，不要往主分类里塞。

3. 误区三：只统计延期天数，不算延期成本

延期 3 天和延期 3 天是不一样的。一个是三个人的小模块，一个是二十人的联调窗口。不看成本，你排不出改进优先级。

我用的简化成本公式是：延期成本 = 延期天数 × 直接影响人数 × 日均人天成本 + 赶工成本 + 机会成本。赶工成本指加班、加人、加采购的额外支出；机会成本可以粗略用「该延期导致后续被推迟的工作项数量」代替。

4. 误区四：拿延期率做个人考核

这是最危险的一条。一旦延期率和个人绩效挂钩，最理性的做法就是把计划日期往宽了报，而不是把项目做准。数据会立刻变好看，交付能力一点没变。这就是典型的指标异化。

正确的做法是：延期率用于团队级改进，个人层面看「延期是否及时上报」和「改进动作是否执行」。奖励早暴露，不奖励零延期。

5. 误区五：混淆触发原因和结构性原因

触发原因是「这次为什么延」，结构性原因是「为什么这类事总是发生」。前者是事件，后者是系统。比如「接口文档第四周才定稿」是触发原因，「我们从来没有接口先行的约定」才是结构性原因。只记录触发原因，你明年还会开同样的复盘会。

6. 误区六：忽略依赖方延期

跨团队项目里，一个团队的准时交付率 95%，五个团队串起来，整体准时率可能只有 77%（0.95 的五次方）。这不是谁不努力，是链路结构决定的。如果你的延期分析只看自己团队的工作项，你会永远低估依赖风险。

7. 误区七：用一次性补救代替机制

延期之后加人、加班、砍范围，这是补救。补救能让这个项目过关，但不会改变下一个项目的概率。判断标准很简单：这次复盘产出的动作，能不能写成一条规则放进流程里？写不进去的，就是补救。

8. 误区八：工具里没有区分「计划日期」和「承诺日期」

这两个日期混在一起，是很多延期数据失真的根源。计划日期是团队内部的工作安排，可以调整；承诺日期是对客户或上级的对外承诺，调整需要走变更流程。混用之后，团队为了不改承诺日期，会悄悄改计划日期，于是延期从来没有发生，只是计划一直在变。

这种情况在数据上表现为「计划完成日期变更次数」异常高，而「延期工作项数」异常低。如果你的团队是这种特征，先别急着表扬，去查一下改期记录。

四、专业判断逻辑：四象限定位加五步归因

有了数据，接下来是怎么判断。我的判断逻辑分三层：先定位性质，再做归因，最后翻译成时间。

1. 第一层：用可预测性和可控性做四象限

任何一个延期原因，都可以用两个正交维度来定位：这个原因事前能不能预测到？这个原因我们能不能控制？

• 可预测且可控：估算偏差、遗漏任务、评审延迟。这类原因应该被彻底纳入改进闭环，通过估算校准、检查清单、流程卡点解决。
• 可预测但不可控：客户审批周期、第三方接口交付、行业监管窗口。这类原因不该追求消除，而应该在计划阶段就预留明确缓冲，并写进合同条款。
• 不可预测但可控：关键人员突然离职、临时优先级调整。这类原因靠冗余设计（双人备份、模块解耦）和决策机制（变更需评估影响）来降低伤害。
• 不可预测且不可控：政策变化、上游公司战略调整。这类原因只做一件事：留一笔管理储备，不做过度分析。

四象限的真正用途是分配管理精力。很多团队把 80% 的复盘时间花在第四象限的原因上，讨论得很激烈，但什么都改变不了；真正该花时间的第二、第一象限反而一笔带过。

2. 第二层：五步归因法

5Why 这个方法大家都知道，但在延期场景里直接问「为什么」很容易变成追责。我改成了五步结构化的问法，每一步都有固定输出物：

1. 定位偏差：实际与计划的差值是多少？精确到天和具体工作项，不允许写「整体进度滞后」。
2. 定位时点：这个偏差最早在什么时候可以被发现？实际是什么时候被发现的？两者之差就是你的反馈延迟。
3. 定位决策：从发现到采取行动，中间隔了多久？是谁在等谁？这一问最容易挖出流程卡点。
4. 定位结构：这个原因在过去 6 个月出现过几次？如果是第 3 次以上，它就不是偶发事件，是结构性缺陷。
5. 定位动作：写出一条可以放进流程的规则，格式必须是「在什么节点、由谁、做什么检查、不通过怎么办」。

这套问法的关键在第二步和第三步。我跟踪的样本里，延期从「发生」到「被发现」的平均延迟是 6.3 天，从「被发现」到「采取行动」的平均延迟是 4.1 天。也就是说，一个 10 天的延期里，有超过 10 天是纯粹的信息流转损耗。

3. 第三层：设计一个能用两年的原因分类字典

下面是我在多个 100 人以上组织里验证过的一版字典，两层结构，12 个叶子节点。它在某项目管理平台里可以直接落成下拉字段的选项组。

这张表我建议直接当作模板用，但一定要根据自己的组织特征调整。比如纯乙方交付型项目，「客户决策链」应该单独拆成一类；纯内部系统建设项目，「审批等待」的权重会更高。

4. 把原因翻译成时间：缓冲与浮动管理

原因分析完之后，必须落到时间上，否则它不会影响任何人的行为。我的做法是给每个关键工作项显式记录三个日期和两个数值：计划开始、计划完成、承诺完成，以及总浮动和剩余浮动。

关键路径上的工作项总浮动为 0，这类工作项一旦延，项目整体必延。非关键路径上的工作项有浮动，延一点不影响交付，但会消耗浮动。当你把「延期原因」和「浮动消耗」放在一起看，会得到一个很有用的判断：真正危险的不是延期本身，是浮动已经在消耗但原因分类还是「其他」。

5. 可直接落地的字段定义（模板）

下面这份字段定义，可以直接作为工作项配置的参考。我在落地时把它放在某项目管理平台的自定义字段里，配合必填校验和下拉字典使用。

# 延期记录工作项字段定义 v1.2
fields:

delay_type: # 延期类型

五、案例与数据观察：在一款国产项目管理平台里把这套方法跑起来

方法讲完了，接下来是落地。我最近两年在 100 人以上的组织里做这套体系，主力选型是 PingCode。选择理由和踩过的坑都写在下面，不做泛泛推荐。

1. 为什么这类体系需要平台支撑

这套方法有三个硬性要求，用表格工具很难满足：一是原因字典要能联动（选了一级自动出二级）；二是字段要能算公式（健康度、成本）；三是延期数据要能按多个维度下钻（按团队、按项目集、按原因、按时点）。

PingCode 的自定义工作项和字段引擎能覆盖这三点：下拉字段支持选项组联动，数值字段支持公式计算，度量看板可以按任意自定义字段做透视。对 100 人以上、多项目并行的组织来说，这种「字段可配置、视图可下钻」的能力，比功能数量重要得多。

2. 落地的四类工作项

我把体系拆成四个工作项类型，彼此通过关联关系串起来，避免所有信息塞在一个需求里：

• 需求 / 用户故事：承载业务目标和承诺日期，承诺日期的变更需要走审批流。
• 任务 / 子任务：承载具体执行，记录计划开始、计划完成、剩余浮动。
• 延期记录：独立工作项类型，一条延期对应一条记录，必须关联到具体任务，包含上面那份字段定义的所有项。
• 改进动作：每条结构性原因对应至少一条改进动作，有负责人和验证日期，结项时检查是否闭环。

把「延期记录」做成独立工作项，是我觉得最有价值的一个设计决定。它带来两个变化：一是延期数据可以独立统计，不会被任务状态淹没；二是延期本身有了负责人和关闭条件，不再是复盘会上的口头承诺。

3. 从 Jira 迁移时的字段对齐

很多 100 人以上的组织是从 Jira 迁过来的，PingCode 支持平滑迁移，这也是我推荐它作为国产替代方案的主要原因之一。但迁移过程中有个坑必须提前处理：历史数据里的原因字段是自由文本，直接迁过来等于把垃圾数据原样搬到新系统。

我的做法是分三步：

1. 导出历史延期记录的原始文本，做一次词频统计，人工归并出 8 到 12 个高频表述。
2. 用这 12 个表述反向映射到新的两级字典，映射不上的统一归入「历史未归类」，单独留存不做分析。
3. 迁移完成后，新产生的延期记录一律强制走下拉字典，自由文本字段只保留「备注」。

这三步做完，历史数据的可用率大概在 60% 到 70%。剩下的不用纠结，历史数据的作用是提供基线，不是提供真相。

4. 私有化部署带来的额外收益

制造业、金融、能源这类客户对数据出境非常敏感，PingCode 支持私有化部署，这一点在选型时是硬门槛。延期数据里往往包含客户名称、项目金额、交付节点，这些信息一旦放在公有云上，法务那一关就过不去。

私有化部署还有个副作用，是我一开始没料到的：数据可见范围可以做到很细。跨部门项目里，各团队只看到自己相关的延期记录，但项目集层面能看到全量。这解决了一个长期矛盾，大家愿意填真实原因，因为不会被全公司围观。

5. 我观察到的数据变化

下面这组数字来自我参与落地的三个组织（规模分别在 120 人、260 人、480 人左右），统计周期是上线前 6 个月与上线后 6 个月。样本不是随机抽取，只能作为经验参考，不能当作行业基准。

• 延期原因的「其他」占比：从 34% 降到 7%。
• 偏差从发生到被发现的平均延迟：从 6.3 天降到 2.1 天。
• 二次延期率（同一工作项改期两次及以上）：从 29% 降到 13%。
• 延期成本可量化比例：从不足 20% 升到 85% 以上。
• 延期项目占比：从 41% 降到 33%，降幅远小于前三项。

最后一条我特意放在这里。延期率只降了 8 个百分点，但反馈延迟降了三分之二。这说明这套体系首先改善的是「信息的及时性」，而不是「交付的准时性」。准时性需要更长时间才能改善，因为它依赖估算能力的积累。如果你的老板问这套体系的效果，别拿延期率说事，拿反馈延迟说事，那个数字更能说明管理水平。

六、不同情况下的行动建议

同一套方法，在不同组织里落地的深度完全不同。下面按五种典型情况给出具体建议，可以直接对照自己的处境挑一条。

1. 十人以下小团队：只做两件事

不要上体系，成本大于收益。只做两件事：

• 在每个任务的备注里强制写一行「如果延期，最可能卡在哪」，相当于事前埋信号。
• 每周五花 15 分钟过一遍所有任务的剩余浮动，浮动小于 3 天的标红。

小团队的优势是信息流转快，瓶颈永远在估算能力。所以真正该投入的是「完成任务后回填实际工时」，坚持三个季度，估算准确度自然会上来。

2. 二十到一百人：建字典，别建流程

这个阶段最容易犯的错是流程做得比人还重。建议只做两件事：一是把原因字典定下来（两级、12 个叶子），二是在工具里把延期记录做成独立工作项。

流程先别碰。审批流、变更委员会这类东西，在 100 人以下往往变成新的延迟源。等到延期数据积累到 50 条以上，你会自然发现该在哪个节点加卡点，那时候再加，阻力最小。

3. 一百人以上多项目组合：需要平台和治理机制

到这个规模，Excel 和简单的看板已经撑不住了。核心诉求变成三个：跨项目的原因聚合、跨团队的依赖可视化、以及数据权限的分层可见。

这也是 PingCode 这类平台真正发挥价值的地方。100 人以上组织的典型特征是项目多、依赖多、干系人多，靠人工汇总延期数据基本不可能。平台提供的能力不是「记录得更漂亮」，而是「让同一个原因在 20 个项目里能被一次识别出来」。

具体建议是按这个顺序推进：先在 1 到 2 个试点项目集跑通字段和字典，再横向复制到其他项目集，最后再接度量看板。顺序反了，你会得到一个数据全空看板很漂亮、但没人看的系统。

4. 乙方交付型项目：把不可控原因写进合同

外包和乙方交付的延期原因里，依赖侧和决策侧占比通常超过一半，这两类原因你控制不了。所以重点不是改进，是界定。

• 在合同里明确客户侧输入的响应时限，超时自动顺延交付日期。
• 把「可预测但不可控」的原因单独列成风险清单，每个风险对应一个缓冲天数，写进项目章程。
• 延期记录里加一个「责任方」字段，只用于界定，不用于考核。

我见过太多乙方团队把客户的审批延迟记成自己的「估算失误」，结果内部复盘永远在检讨自己，外部风险永远没人管。

5. 强监管与私有化场景：先解决数据合规，再谈分析

金融、能源、军工类客户的项目数据不能出内网，这时候选型的第一道门槛就是部署方式。PingCode 支持私有化部署，这在同类国产平台里是比较明确的优势。

落地顺序建议是：先确认数据存储位置和权限模型，再配置字段，最后才做度量。我见过一个团队花两个月设计了一套极精细的原因分析模型，结果因为数据不能出内网，看板根本跑不起来。

七、不同情况下的取舍

方法的价值不体现在「全都要」，而体现在「知道放弃什么」。下面五组取舍，是我在落地过程中反复权衡过的。

1. 精度换录入成本

字段越多，数据越准，但录入成本越高。我的判断标准是：如果一条延期记录的平均录入时间超过 3 分钟，数据质量一定会崩塌。因为没人愿意在已经很忙的时候填表。

所以我的取舍是：核心字段（原因两级、三个时点、剩余浮动）必填，成本估算和结构性原因选填。前者靠系统保证，后者靠复盘会补充。宁可要 80% 完整度的真实数据，也不要 100% 完整度的应付数据。

2. 统一换自治

大组织里，各业务线的项目类型差异很大，强行统一字典会导致「大类对得上、小类全错」。我的做法是一级分类强制统一，二级分类允许各业务线自定，但总数不超过 6 个。

这样跨项目聚合时能按一级分类对齐，业务线内部又能保留自己的语义。代价是二级分类的横向对比做不了，但这个代价我认为值得付。

3. 追责换学习

这一组取舍没有中间地带。只要延期原因被用于追责，数据就会立刻失真，而且是不可逆的失真，信任一旦破坏，重建成本极高。

我的立场很明确：延期原因数据只用于改进，不用于考核。如果要考核，考核「是否在健康度低于 10% 时上报」，这个指标和数据的真实性是一致的，不会互相冲突。

4. 自建换采购

自建的好处是字段可以随便加、流程可以随便改；坏处是每次改都要排开发资源，半年才能上线一个字段。

我的经验分界线在 100 人：100 人以下，用现成工具加少量自定义就够了；100 人以上，自建的成本反而更高，因为你要维护的不只是字段，还有权限、审计、跨项目聚合、移动端适配。这个规模上，选择像 PingCode 这样支持深度自定义又支持私有化的成熟平台，通常比自建更划算。

5. 实时换准确

实时看板看起来很爽，但延期数据有个特殊性：偏差刚发生时，原因往往还没定性。这时候填进去的原因，多半是猜测。

所以我的取舍是：时点字段（trigger_time / detect_time）要求实时填，原因字段允许在 48 小时内补充完善。系统层面用「待定性」状态标记，看板上单独统计这部分占比。如果「待定性」超过 30%，说明你的复盘节奏太慢，而不是数据有问题。

八、总结：把延期当成信号，而不是罪证

回到开头那个 47 天的项目。如果今天再让我做一次，我不会先开复盘会。我会先做三件事：把原因字段换成两级字典，加上三个时点字段，然后在每个关键任务上显式记录剩余浮动。这三件事加起来，配置时间不超过一个下午。

我在这套方法上最独特的一个判断是：延期管理的核心指标不是延期率，而是反馈延迟。延期率受外部因素影响太大，短期根本动不了；反馈延迟完全由内部机制决定，改一个字段、加一条提醒，两周就能看到变化。而反馈延迟一旦降下来，延期率早晚会跟着降，因为你能提前两个月看到问题，而不是在交付前一天。

另外一个常被忽略的点是：不是所有延期都值得管。四象限里左下角那批「不可预测且不可控」的原因，投入再多分析也不会改变结果。真正值得投入的是右上角，估算侧和环境侧，这两类原因可控、可预测，改进动作直接、见效快，而且不需要动组织结构。

下一步怎么做，我给一个具体的七日计划：

1. 第 1 天：把过去 12 个月所有延期记录的原始文本导出来，做词频统计，看看你的「垃圾桶原因」占比是多少。
2. 第 2 天：基于词频结果，定一版两级、12 个叶子的原因字典，一级分类尽量对齐上面那六类。
3. 第 3 天：在工具里把「延期记录」建为独立工作项类型，加上三个时点字段和剩余浮动字段。如果用的是 PingCode，直接照第四节的字段定义配置即可。
4. 第 4 天：选一个正在进行的项目做试点，只覆盖关键路径上的 20 到 30 个工作项，不要全量铺开。
5. 第 5 天：给试点项目的所有人讲清楚一件事，延期数据不用于考核，只用于改进。这句话不讲透，后面所有数据都是假的。
6. 第 6 天：跑一遍第一次延期健康度计算，把低于 10% 的工作项标出来，看它们的原因分布。
7. 第 7 天：写第一条改进规则，格式必须是「在什么节点、由谁、做什么检查、不通过怎么办」。

一周之后你会得到一份不太好看但真实的数据。那份数据比任何一次复盘会都有价值，因为它第一次告诉你：你的项目到底是在哪里、以什么方式、在什么时间点开始滑向延期的。

延期不是罪证，是信号。把信号采集好，比追责有用得多。