2023 年我参与复盘过一个 40 人规模的智能硬件研发项目：团队用 6 个月时间把需求拆成了 4800 条子任务，项目经理每周在这套子任务体系上花掉 11 个小时做进度维护，项目最终仍然延期了 3 周。更刺眼的是另一组数字，同期一个只有 9 人、子任务总量不到 400 条的小团队，交付按期率反而高出 14 个百分点。
这个反差说明了一件事：子任务全流程的难点从来不在“拆”，而在“拆完之后数据能不能自动向上聚合、能不能回答项目经理真正要做的决策”。大多数团队把子任务当成待办清单的层级缩进，少数团队把它当成一套可度量的数据底座，这两者的管理效率差距在 100 人以上的组织里会被放大到几倍。
下面我把任务管理子任务的全流程拆开讲：从颗粒度口径、依赖建模、状态机设计，到汇总逻辑、指标定义、看板搭建，再到不同规模组织该怎么取舍。所有数据来自我在 2021，2025 年间参与复盘的 30 余个研发与交付项目，其中涉及多个项目管理平台的迁移与替换，为保护商业信息做了脱敏处理。
一、核心结论：子任务的本质是可聚合的最小统计单元
先把结论摆在前面，后面再讲为什么。
1. 子任务的第一性目标是“可统计”，不是“可执行”
很多人下意识地把子任务当成“最小工作单元”，所以判断标准是“一个人能不能独立做完”。这个标准没错，但不够。真正决定子任务体系成败的，是它能不能在父任务、迭代、项目、部门四个层级上被自动汇总。
如果你的子任务只是描述文本框里的一个复选框，那它对项目经理的价值接近于零。它只有变成带估时、带状态、带负责人、带依赖、带完成定义的结构化记录，才具备被统计的可能。
我见过一个团队，子任务写得非常详细，每条都有三段式的执行步骤，但全部塞在描述里。结果迭代中期要回答“这个模块还剩多少工作量”时，项目经理只能拉着 4 个开发开了 50 分钟会。这就是典型的“可执行但不可统计”。
2. 两级结构覆盖 80% 场景，三级是上限
我的经验判断是：父任务 + 子任务的两级结构，可以覆盖绝大多数软件研发和交付项目的管理需求。只有在硬件、集成、多供应商协作这类强外部依赖的场景下，才需要引入第三级。
超过三级之后，每增加一层，汇总口径的歧义大约增加 40%。因为不同的人会开始争论“哪个层级才算完成”“第三级的进度要不要计入第二级”。这种争论消耗的时间，往往超过它带来的洞察价值。
3. 项目经理真正要看的不是完成率，是偏差信号
完成率是一个滞后指标。当你看到父任务完成率只有 40% 时，已经晚了。
更有价值的是三类领先信号：阻塞时长中位数、估时偏差趋势、子任务状态停留时长分布。一个子任务在“进行中”状态停留了 6 天却没提交过一次代码，这比完成率更能预警风险。
二、真实场景复盘：一个 32 人团队的子任务事故
抽象结论讲完了，讲一个我亲身参与的复盘。
1. 事件经过
这是一个 32 人的研发团队，做工业设备的控制系统，项目周期 7 个月。团队从项目启动就建立了子任务规范，要求所有开发任务必须拆分，且每条子任务不得超过 2 人天。
执行到第 4 个月时，项目经理发现一个尴尬的情况：看板上的整体完成率是 78%，看起来健康，但三个关键模块的实际联调一直无法开始。深挖后发现，这三个模块的父任务完成率之所以是 78%，是因为大量“准备工作类”的子任务被提前关闭了，而真正阻塞联调的那 6 条核心子任务，每条都停留在进行中超过 9 天。
2. 四周数据复盘
我们把那 4 周的数据导出来做了一次归因分析，折算成工时损失，结果如下：等待上下游依赖确认 42 人时/周，子任务返工 28 人时/周，进度口径对账 19 人时/周，重复同步会议 15 人时/周，工具切换与重复录入 11 人时/周。
合计每周约 115 人时，按 32 人团队计算，相当于每个成员每周有 3.6 小时消耗在“管理摩擦”上。这 3.6 小时不是被工作量吃掉的，是被过程设计缺陷吃掉的。
3. 我们改了什么
改动其实不复杂，一共四条：把子任务的验收标准从描述文本提升为独立字段；给子任务增加“阻塞于”关系，让阻塞可以双向追溯；把状态从 11 个压缩到 6 个；父任务进度改为按子任务估时加权自动计算，禁止手工修改。
改完之后第 2 个迭代，等待依赖确认的工时从 42 人时/周降到 17 人时/周。这个改善不是靠更努力，是靠更少的模糊。
三、拆解六种常见误区
下面这六种误区，我在不同团队身上反复见到，它们的破坏力并不相同，先修最贵的。
1. 把子任务当成“打勾清单”
最普遍的一种。子任务只有标题和完成状态，没有估时、没有负责人、没有完成定义。这种体系在 5 人团队里能跑，到了 30 人团队就会崩。因为它无法回答“这个父任务还剩多少工作量”这个最基本的问题。
2. 状态机设计过度
我见过一个有 13 个状态的任务流：待评审、评审中、评审通过、待排期、已排期、开发中、待自测、自测中、待联调、联调中、待验收、验收中、已关闭。
设计者的初衷是“精确反映现实”，实际结果是回填完整率从 92% 掉到 61%。因为开发在提交代码时根本记不清该点哪个。状态超过 7 个之后，数据质量会断崖式下降。
3. 没有建模依赖关系
依赖关系是子任务体系里最被低估的能力。没有它，阻塞只能靠口头沟通、群里喊话、周会上暴露。而一旦依赖被结构化建模，系统就能自动算出关键路径、自动预警下游任务、自动把阻塞时长统计出来。
4. 谁都能改父任务状态
这一条很隐蔽。当父任务状态可以被任何人手工拖动时，它就不再是数据的聚合结果，而变成了各方的“表达工具”。团队为了让看板好看一点，会顺手把父任务拖到“已完成”。一旦允许手工覆盖自动汇总，整套数据就失去了可信度。
5. 不同小组口径不统一
A 组认为代码合并就算完成，B 组认为必须通过测试才算完成，C 组认为必须部署到预发才算完成。三组数据汇总到项目层面时，完成率是没有任何意义的数字。
6. 只增不减的子任务
很多团队只会新建子任务，从不清理失效的子任务。半年下来，一个父任务下挂着 30 条子任务，其中 12 条已经被证明不需要做了，还留在那里拖着完成率。
四、专业判断逻辑：怎么拆、怎么连、怎么算
前面讲了结论和误区，这一节讲具体判断方法。
1. 按交付物拆，不按动作拆
这是最重要的一条口径。子任务应该是一个“可以独立验收的产出”，而不是一个“动作”。
“写接口代码”是动作，“用户登录接口可用且通过联调”是交付物。按动作拆出来的子任务，天然无法定义完成，也天然无法验收。按交付物拆出来的子任务，完成定义是自带的。
实操判断方法很简单：如果这条子任务的标题里出现“编写、处理、优化、调整、跟进”这类动词而没有宾语产出物，它大概率需要重写。
2. 颗粒度的三个约束条件
我用的颗粒度判断不是单一的“多少小时”，而是三个条件同时满足：单条子任务的估时在 0.5，2 人天之间；单条子任务的完成定义可以用一句话写完；单条子任务只对应一个负责人。
三个条件里只要有一条不满足，就应该考虑拆分或合并。0.5 人天以下的下限比上限更重要，因为过细的拆分会让估时噪声淹没有效信号，也会让周维护成本急剧上升。
3. 依赖建模的三种关系
我建议至少建模三种关系：完成，开始（最常见，A 做完 B 才能开始）、阻塞于（等待外部输入，比如等硬件到货、等第三方接口）、关联（双向信息关联但无顺序约束）。
有了这三种关系，系统就能自动算出关键路径，并在一条子任务的阻塞时长超过阈值时主动预警。这比周会上逐个问“你这个卡在哪”高效得多。
4. 汇总口径必须自下而上且不可手工覆盖
父任务进度 = Σ（已完成子任务估时）/ Σ（全部子任务估时）。这个公式看起来简单，但有两个隐藏决策：无估时的子任务怎么算？被取消的子任务怎么算？
我的建议是：无估时的子任务默认按该类型的历史中位数填充，并在数据质量看板上单列；被取消的子任务从分母中剔除，但保留取消记录用于事后分析。
5. 一个可直接落地的子任务字段结构
下面是我在多个项目中验证过的子任务字段结构，可以直接作为 schema 参考：
{
"subtask_id": "ST-2024-0187",
"parent_id": "TASK-0421",
"title": "用户登录接口可用且通过联调",
"deliverable": "可调通的 POST /auth/login 接口",
"estimate_hours": 12,
"owner": "user_1024",
"status": "in_progress",
"acceptance_criteria": "返回 200 且 token 可被鉴权中间件解析",
"depends_on": ["TASK-0418"],
"blocked_by": [],
"work_type": "backend_api",
"iteration": "Sprint-24",
"actual_hours": 9.5
}
注意其中 deliverable 和 acceptance_criteria 是分开的两个字段。交付物描述“产出什么”，验收标准描述“怎么算合格”。混在一起写，评审时必然扯皮。
五、以 PingCode 为例：子任务全流程的落地与数据观察
讲完方法论，讲落地。这几年我在中大型组织里参与过多次研发管理平台的选型与迁移，其中一个比较有代表性的案例是从 Jira 迁移到 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持 Jira 平滑迁移，在国产替代场景里是被反复提到的选择。
1. 为什么这个案例值得讲
这是一家 180 人规模的研发组织，12 个迭代小队，原来的 Jira 里积累了 6 年的项目数据，约 21 万条 issue。迁移的难点不在于数据量，而在于原有子任务体系本身就存在前面提到的六种误区，直接平移只会把问题一起搬过去。
所以我们在迁移前先做了一轮口径清理：把 13 个状态压缩到 6 个，把散落在描述里的验收标准提取为独立字段，把原先靠标签模拟的依赖关系改为结构化关联。
2. 迁移过程中真正的坑
第一个坑是历史状态映射。原系统里“待联调”和“联调中”两个状态在新的 6 状态模型里没有对应位置，我们最终把它们合并进“进行中”，但保留原状态作为只读标签，用于历史数据分析。
第二个坑是估时字段单位不一致。历史数据里有一部分是小时、一部分是人天、还有一部分是故事点。直接迁移会导致父任务进度计算出错。我们的处理方式是统一转换为小时，并对缺失值用该工作类型的历史中位数回填，同时打上“推算值”标记。
第三个坑是自动化规则的顺序。迁移后我们配置了父任务进度自动汇总、阻塞超 8 工作小时自动提醒、子任务关闭时强制校验验收标准字段三条规则。最初顺序配错，导致进度汇总先跑、验收校验后跑，出现了“还没验收就计入完成”的数据污染。调整顺序后问题消失。
3. 迁移前后 90 天的数据对照
我们用迁移前后各 90 天、共 12 个完整迭代的数据做了对照。需要说明的是，这里面有平台能力的贡献，也有口径清理本身的贡献，两者无法完全剥离。
4. 子任务全流程的六个转化节点
迁移完成后，我们统计了某一个完整迭代内 1000 条子任务的端到端流转，得到了一条很有信息量的漏斗。
5. 几条可以直接抄的自动化规则
落地过程中，我认为性价比最高的三条规则是：子任务关闭时校验验收标准字段非空，否则不允许关闭；子任务进入阻塞状态超过 8 工作小时自动通知上下游负责人；父任务下所有子任务关闭后自动流转父任务状态并通知项目经理。
这三条规则覆盖了前面提到的口径不统一、依赖不可见、汇总靠人工三个核心问题，配置成本大约在半天以内。
六、度量体系：项目经理该盯的 8 个指标
有了结构化数据，接下来就是定义指标。指标太多会让团队失去焦点，我一般建议控制在 8 个以内。
1. 指标定义表
| 维度 | 指标 | 计算口径 | 健康阈值 | 异常信号解读 |
|---|---|---|---|---|
| 交付 | 子任务按期完成率 | 按期关闭子任务数 / 应关闭子任务数 | ≥ 85% | 低于 70% 通常指向估时失真或依赖未建模 |
| 质量 | 子任务返工率 | 返工子任务数 / 关闭子任务总数 | ≤ 10% | 高于 15% 说明验收标准定义不清 |
| 过程 | 阻塞时长中位数 | 从进入阻塞到解除的中位工作时长 | ≤ 8 工作小时 | 超过 16 小时说明上下游协同断裂 |
| 数据 | 状态回填完整率 | 有完整状态流转记录的子任务 / 子任务总数 | ≥ 95% | 低于 80% 时所有过程指标都不可信 |
| 结构 | 子任务颗粒度中位数 | 全部子任务估时的中位数 | 0.5，2 人天 | 低于 0.5 人天意味着管理开销正在吃掉收益 |
| 预测 | 估时偏差率 | |实际工时 − 估时| / 估时 | ≤ 20% | 连续三个迭代上升说明拆分口径出了问题 |
| 流转 | 子任务跨迭代顺延率 | 被顺延到下一迭代的子任务数 / 迭代子任务总数 | ≤ 15% | 高于 25% 说明迭代容量规划失真 |
| 协同 | 无人认领时长 | 子任务从创建到被认领的中位时长 | ≤ 24 小时 | 超过 48 小时说明排期机制失效 |
2. 一个真实团队的健康度差距
下面这组对比来自我 2024 年做过一次诊断的团队，8 项指标里有 5 项偏离阈值。这张图的意义在于，指标之间是有关联的，不能孤立地修单项。
3. 看板搭建的三层结构
我建议看板分三层：项目层看里程碑与关键路径的偏差；迭代层看阻塞分布与估时偏差趋势；个人层看自己的子任务状态停留时长。三层的数据同源，但视角不同。
不要试图用一张看板满足所有人，那只会让所有人都看不到重点。
七、不同情况下的行动建议
方法讲完了，接下来给不同情况的具体动作。
1. 10 人以下团队
不要建立复杂体系。父任务 + 子任务两级结构足够，状态控制在 4 个以内，估时字段可以省略但完成定义必须有。这个阶段最大的风险是过度管理，把有限的精力消耗在维护系统而不是交付上。
2. 10，50 人团队
开始需要结构化。建议引入估时、负责人、验收标准、依赖关系四个字段，状态控制在 5，6 个，父任务进度改为自动汇总。同时开始建立基础的自动化规则，至少覆盖阻塞提醒和关闭校验。
3. 50，200 人团队
这是子任务体系收益最明显的区间。需要跨团队统一口径，建立指标看板，并开始考虑平台能力是否支撑私有化部署、权限隔离、跨项目汇总。如果组织有信创或数据合规要求，私有化部署会成为硬性条件，这也是很多中大型企业选择 PingCode 这类平台的主要原因。
4. 200 人以上组织
重点关注三点：口径治理机制（谁来定义、谁来仲裁）、数据链路完整性（任务与代码、测试、发布是否打通）、历史数据迁移策略。这个规模下最大的风险不是工具不够强，而是各团队各建一套口径。
八、不同情况下的取舍
任何管理动作都有成本，关键是知道自己在拿什么换什么。
1. 颗粒度：拿管理开销换风险可见性
子任务拆得越细，风险越早暴露，但项目经理的维护成本越高、团队的填报负担越重。我的判断是把 0.5 人天作为绝对下限，除非该任务的执行动作高度标准化，比如测试用例执行。
如果你所在的团队每周维护成本已经超过 8 小时，优先做的是合并过细的子任务，而不是引入更多工具。
2. 字段数量：拿录入成本换分析能力
每增加一个必填字段，录入成本上升，但可分析的维度也上升。判断标准是：这个字段会不会被用在至少一个月度级别的分析里？会，就加；不会，就用标签或描述替代。
我见过给子任务加了 17 个必填字段的团队，结果是大量字段被填成默认值，分析价值归零，反而增加了录入时间。
3. 状态数量：拿流程精度换数据连续性
6 个状态是一个经验拐点。超过这个数，回填完整率会明显下降。如果你确实需要更细的过程跟踪，用子状态或标签做补充，而不是继续切分主状态。
4. 工具选型：拿迁移成本换长期能力
工具替换从来不是零成本的。一次涉及 20 万条数据的迁移，前期口径清理加上迁移验证通常需要 4，8 周。但如果现有平台的私有化能力、跨项目汇总能力或国产化合规能力已经无法满足组织要求，这个投入是值得的。
我的取舍建议是：先清理口径，再评估工具。口径不清的情况下换工具，等于把混乱搬到新地方，通常 3 个月后问题会原样复现。
九、常见问题与下一步行动
最后回答几个我在咨询里被问得最多的问题，并给出下一步动作。
1. 子任务做到什么程度算“够用”
判断标准不是子任务写得多漂亮，而是：项目经理能否在不召集任何会议的情况下，回答“这个模块还剩多少工作量”和“最大的阻塞在哪”这两个问题。能回答，就够用了。
2. 团队抵触子任务填报怎么办
抵触的根源通常是“填了没用”。解决办法是让填报数据立刻可见地反哺团队：自动生成周报、自动提醒阻塞、自动计算迭代燃尽。当团队发现不填反而更麻烦时，抵触会自然消退。
3. 应该先修口径还是先换工具
先修口径。口径清理的投入通常只有迁移投入的三分之一，但它决定了迁移后的数据能不能用。
4. 下一步怎么落地
给你一个可以这周就启动的四步动作：
- 抽出当前在跑的 50 条子任务，逐条检查是否符合“有交付物、有验收标准、有单一负责人、估时在 0.5，2 人天”四项条件，统计不符合的比例。
- 统计最近一个迭代的六个转化节点数据：创建、认领、开工、首次提交、评审通过、验收关闭，找出损耗最大的那一段。
- 只修最贵的那一个问题，不要同时改五件事。如果状态回填完整率低于 80%，就先修状态数量，其他都往后放。
- 两周后复查同一个指标，用数据确认改善是否真实发生。
我复盘过这么多项目，最后发现一个规律：子任务体系做得好不好，差异不在于团队有多勤奋，而在于项目经理有没有把“拆任务”当成一次数据结构设计，而不是一次文档整理。把它当结构设计的人，会先想清楚字段、口径、汇总规则；把它当文档整理的人，会先追求写得多、写得全。前者越跑越轻，后者越跑越重。
如果你的团队现在每周花在子任务维护上的时间超过 6 小时，那大概率不是团队执行力的问题，而是这套结构本身需要重新设计了。
常见问题解答（FAQ）
1. 任务管理里的子任务到底拆到多细、拆几层才算合适？
我带项目的时候踩过两个极端：一开始要求大家把子任务拆得特别细，一条任务下面挂了二十多条，结果每天光更新状态就花掉半小时，真正干活的时间反而被挤掉了。后来又偷懒只写一句“开发完成”，周会上完全看不出到底卡在哪一步。所以我一直想找一个能落地的拆分标准，而不是“看情况”这种废话。
给三条硬标准来判断一条子任务是否该存在：一是有唯一责任人，二是有明确的完成定义（交付物或验收标准），三是能在1到3天内闭环。三条全部满足才拆，缺一条就说明拆得不对或者不该拆。层级上控制在三层以内，也就是项目，任务，子任务，再往下拆基本只是在增加维护成本。
团队5到8人、双周迭代的场景下，单人活跃子任务建议控制在6到15条，超过20条通常说明拆过头了。拆过头的典型信号是出现“改代码”“写注释”“开会讨论”这类动作型条目；拆得不够的信号是某条子任务连续3天以上状态不变，而且没人说得清它到底做到哪了。
粒度不是一次定死的，迭代回顾时统计一下“平均每条子任务的实际耗时”，如果普遍低于半天就该合并，普遍超过4天就该再拆一层。
2. 父任务的进度百分比，到底该按子任务加权计算还是人工填写？工时又该怎么汇总？
我们周报上某条父任务显示80%完成，结果周五要发布时发现核心模块根本没联调，我被老板追问得说不出话。从那以后我就特别想知道，这个进度数字到底怎么算才不骗人，工时统计又该记在哪一层才不重复。
按子任务个数平均计算是最容易失真的做法，因为“改一句文案”和“重构支付链路”权重完全不同。推荐用工作量加权：父任务进度等于已完成的子任务预估工时之和，除以全部子任务预估工时之和。团队如果没有工时预估习惯，退一步用故事点或T恤尺码映射成权重也能用，关键是权重口径在整个项目里保持一致。
但更重要的是不要只看百分比，要同时看关键路径：如果一条父任务下存在关键路径子任务未完成，这条父任务即使在数学上算到90%，也应该标黄而不是标绿，因为它不具备可交付性。
工时口径上有个具体建议：预估工时和实际工时只允许记录在子任务层级，父任务的工时一律由子任务汇总生成，不允许人工填写，否则父子两层都记工时会直接导致重复计算，后面所有产出效率分析全部作废。
判断这套口径是否生效，可以看一个反向指标：如果某个迭代里父任务的进度和它子任务加权进度的偏差超过10%，说明还有人在手工覆盖进度。
3. 怎么从子任务的数据里提前发现项目要延期？该盯哪几个指标？
我以前都是等到里程碑当天才发现来不及了，那时候除了加班没别的办法。后来我琢磨能不能从子任务的更新记录里提前看出苗头，但打开报表一看全是数字，不知道该看哪个才算数。
建议只看三个指标。第一是状态停滞时长：统计所有未完成子任务距离最后一次状态变更的天数，超过迭代长度的25%（双周迭代就是3.5天）且仍是进行中的，直接列为观察项，这是最早能拿到的信号。
第二是完成节奏偏离：把迭代周期内的预期完成曲线和实际累计完成子任务数做对比，连续两个统计周期低于预期曲线15%以上，基本可以判定这个迭代要延期，此时还在迭代中段，调整范围或砍需求的成本都很低。
第三是返工率：子任务从已完成被退回进行中的比例，超过10%说明前期评估或验收标准有问题，后面同类任务大概率还会返工，需要立刻补评审而不是加人。执行上，这些做成一份周度固定报表就够了，不需要每天看，看得太勤只会被噪声带偏。
有一个前置条件必须守住：子任务的状态变更要自动记录时间戳，否则停滞时长和完成节奏都算不出来，这套预警就是空谈。
4. 任务系统里的子任务数据，能不能用来做团队复盘甚至个人绩效？
老板让我拿任务数据统计谁干得多谁干得少，我心里挺犹豫。一方面确实想量化一下，另一方面又怕一公布大家就开始刷数据，把任务拆成一堆鸡毛蒜皮的小条目。这种顾虑我没法直接跟老板说清楚，想找个更靠谱的用法。
可以用来复盘流程，不建议直接拿来考核个人。原因很实在：子任务数量、工时填报都是人手工录入的，一旦和绩效挂钩就会被优化，任务被拆碎、工时被普遍上浮、简单任务被抢着认领，数据几周之内就会彻底失真，最后你手里的报表既不能反映真实工作量，也不能反映真实产出。
相对安全的口径有三个：一是周期维度的计划完成率，按子任务数量和工作量分别看一遍，两者差异大就说明拆分粒度有问题；二是需求前置时间，也就是从子任务创建到完成的中位数，用它定位瓶颈发生在评审、开发还是测试环节，而不是用来定位人；三是返工率和阻塞时长，用来发现流程缺陷。
如果确实需要评估个人，建议换成“承诺与交付”的迭代目标达成情况，再叠加同岗位横向对比，同时明确告知数据用途、允许当事人对异常数据做说明。把口径和用途摊开讲清楚，比偷偷统计更能守住数据的可信度。
核心关键词
文章包含AI辅助创作：任务管理子任务全流程：项目经理数据分析与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/345083
读者评论
父任务进度按估时加权自动汇总这条，我实践下来有个前提被忽略了：估时本身准不准。我们团队估时偏差中位数在30%上下，加权之后只是把误差重新分配了一遍，看着精确，判断时还是照样偏。后来改成每周重估剩余工时，反而更接近真实。另外禁止手工改父任务状态我认同，但最好留个补正入口，不然数据明显错了也没人敢动，最后大家干脆不看。
颗粒度那条倒U形我有不同看法。我们做客户现场交付，子任务平均3到5人天，偏差率并没比1到2人天差多少，因为现场变更多，拆太细基本当天就作废。文章样本偏软件与硬件混合交付，可能把外部依赖型任务的权重放大了。我更倾向于按工作类型定颗粒度基准，而不是先框一个统一最优区间。
依赖建模我换过两套项目管理平台，功能都在，但真正建起来的团队很少。问题不在工具，而是拆任务的人得先知道上下游是谁，可很多项目拆的时候根本没排过接口对接顺序。我现在的做法是先让开发口头讲一遍前后依赖，再录进系统，不然录进去的是假依赖，关键路径和阻塞预警都不会准。