过去两年我帮十几家一百到一千人规模的企业做研发管理诊断，几乎每家都遇到过同一个场景：月度经营会上，项目经理说"整体进度完成 85%"，但 CFO 追问剩下 15% 什么时候能收尾时，会议室陷入沉默。问题不在于数字造假，而在于绝大多数企业的"任务进度"是估算出来的，不是测量出来的。进度管理真正的分水岭，不是你有没有用工具，而是你的进度数据是主观汇报，还是客观行为留痕。这篇指南会从核心结论、真实场景、常见误区、判断逻辑、案例数据、行动建议和取舍七个层面，给出一套可以直接拿去落地的任务进度管理清单。
一、先给结论：任务进度管理的五个支柱
我把过去几年沉淀的进度管理经验，收敛成一个可以直接背下来的结论：可交付、可拆分、可度量、可预警、可复盘。这五个词不是口号，每一个都对应一套具体的机制，缺一个，进度管理就会退化成"月末填表"。
1. 可交付：进度单位不是"天"，而是"完成的交付物"
我见过太多项目用"预计工时"来跟踪进度，结果是每个人每周报工 40 小时，但三个月后能演示的功能几乎为零。原因是工时是投入指标，不是产出指标。
正确的做法是把任务定义成一个可以验证的交付物：一份需求文档、一个通过测试的接口、一版可演示的页面。任务无法被验证，进度就无法被度量。
2. 可拆分：单任务颗粒度不超过 3 人天
这是我在至少 20 个项目里反复验证过的经验值。超过 3 人天的任务，进度颗粒度太粗，状态更新只能靠"感觉"。颗粒度控制在 0.5 到 3 人天，项目经理才能在周会前就发现偏差，而不是在交付前一周。
3. 可度量：所有状态变化必须由行为触发，而非人工填报
如果任务状态靠人主动改成"完成"，那进度数据就是汇报数据，不是过程数据。真正可信的做法是：代码提交、测试用例通过、审批节点签署，这些行为自动触发状态流转。进度管理里最重要的不是"谁在汇报"，而是"什么动作让状态发生了变化"。
4. 可预警：偏差提前于交付节点 5 到 10 个工作日暴露
预警窗口是这个指标的关键。我在一家两百人规模的软件公司做过统计：在引入燃尽图自动预警之前，平均延期暴露时间是交付前 1.8 个工作日；引入之后是交付前 7.3 个工作日。前者意味着只能靠加班救火，后者才有调整资源或缩减范围的余地。
5. 可复盘：每个里程碑必须留下偏差归因记录
没有归因的复盘只是情绪宣泄。"延期了"不是归因，"需求变更 4 次叠加关键人员休假一周，导致接口联调延期 3 天"才是归因。归因记录会变成下一个项目的估算基准。
6. 五个支柱的协同关系
二、为什么大部分企业的进度管理会失效：三个真实场景
抽象讲方法没用，我直接描述三个我亲身诊断过的场景，它们几乎覆盖了 80% 企业的困局。
1. 场景一：周报里的"完成 80%"永远收不了尾
一家做工业软件的公司，项目经理用 Excel 跟踪 12 个模块，每周更新百分比。连续 6 周显示"整体进度 78% 到 83%"，但项目最终比计划晚了 47 天交付。
我翻开他们的周报发现：百分比是项目经理根据各组长口头汇报拍脑袋填的，没有任何底层任务数据支撑。到了后期，越接近完工的任务越难推进，因为剩下的都是集成和联调这类"跨越多个模块、难以估算"的工作，而前期那些"完成 80%"的模块里其实藏着大量未验证的接口。
百分比进度最大的陷阱在于：它让所有人都以为进度是连续的、可加总的，但实际交付是离散的、不可加总的。
2. 场景二：任务状态"进行中"从周一挂到周五
另一家做 SaaS 的公司，任务看板上 40% 的卡片状态是"进行中"，平均停留时间 6.4 天。我问他们的开发主管：怎么区分"刚启动"和"已经做完一半"？他回答：靠问。
这就是典型的无度量状态。看板上的"进行中"是一个垃圾桶状态，只要任务没有完成，所有人都默认它是进行中。这种看板看起来很美，实际上不能提供任何预警信号。
3. 场景三：多项目并行，管理者不知道谁在超载
一家中大型企业同时跑 7 个项目，跨项目共享 23 名核心工程师。他们的进度管理是按项目维度做的，每个人在每个项目里都有自己的任务清单。结果是：一个工程师同时在 4 个项目的关键路径上，但没有任何一个项目的管理者能看到他的总负载。
这是中大型企业最典型的进度管理失控点。当组织规模超过 100 人、同时并行项目超过 5 个时，进度管理的对象就应该从"项目"升级为"资源和依赖"。
4. 三个场景的共同根因
三、拆解八个常见误区：管理者最容易踩的坑
在给企业做培训时，我会先让管理者做一份自测，下面八个误区出现的频率最高。每一条都配一个我实际踩过的坑。
1. 误区一：以为进度等于工时消耗比例
误区表现：任务计划 40 小时，已投入 36 小时，进度就是 90%。
为什么错：一个开发任务可能投入 36 小时还在调试同一个 bug，剩余工作量依然有 60%。工时是投入，进度是产出，两者之间没有线性关系。
我的做法：进度一律按剩余工作量（Remaining Work）估算，而不是按已投入工时。每次状态更新时，任务负责人必须回答"还剩多少工作量"，而不是"已经花了多少时间"。
2. 误区二：任务状态由负责人手动修改
手动改状态意味着状态是汇报值而非测量值。更隐蔽的问题是：人在手动改状态时会有"乐观偏差"，明明还剩 2 小时验证工作，也会顺手改成完成。
可行做法是把状态与冻结字段关联：需求文档需要评审通过才能进入开发，开发需要通过代码合并或测试用例执行才能进入测试。状态变化由系统事件触发，管理者才有可信数据。
3. 误区三：把甘特图当成进度管理本身
甘特图是可视化之一，不是管理机制。我见过把甘特图画得极精美的项目经理，任务依赖关系连到了第五层，但底层任务的完成标准全是空的，一旦项目启动两周后甘特图就再也没更新过。
甘特图的价值在于暴露依赖和关键路径，前提是底层任务的颗粒度和依赖关系是真实维护的。
4. 误区四：用一个百分比汇报所有层级
高层看的是里程碑健康度，中层看的是模块依赖和资源冲突，执行层看的是今天做什么。把同一个百分比灌到三层，等于三层都没看懂。
我的建议是分层仪表：高管层用里程碑红黄绿灯 + 关键依赖阻塞时长；中层用燃尽曲线 + 资源负载热力；执行层用今日/本周任务清单 + 阻塞项。
5. 误区五：进度预警靠人喊
依赖人主动上报阻塞，意味着预警时间取决于这个人的风险意识。实际经验是：一个进度阻塞平均要被 2.3 个人先后感知，才会进入周会议题，平均延迟 4 到 6 个工作日。
6. 误区六：只跟踪任务，不跟踪依赖
在中大型项目里，真正导致延期的是跨团队依赖没法按期交付，而不是单个任务拖延。跨团队依赖的交付延迟，是单团队任务延期的 3 到 5 倍。
7. 误区七：复盘止于"下次注意"
没有归因到具体变量（需求变更次数、人员流动、依赖交付延迟天数），复盘就无法产出可复用的估算基线。我的做法是给每个延期里程碑强制填写至少一个量化归因字段。
8. 误区八：工具上线了，管理机制没变
这是最隐蔽也最普遍的误区。企业花了几十万上一套项目管理平台，但流程还是那套流程，只是把 Excel 搬到了系统里。
工具不会自动产生进度数据，是机制设计决定了数据质量。这一点在选型和上线时如果不明确，后面返工的成本是首次投入的两到三倍。
9. 误区与后果的对照
四、专业判断逻辑：如何构建可落地的进度管理体系
讲完误区和场景，接下来是我在多个项目里沉淀下来的判断框架。它不是某个工具的使用手册，而是一套设计原则。
1. 第一层判断：任务颗粒度由"交付节点密度"决定
不要一刀切规定所有任务不超过 3 人天。判断标准应该是：从任务启动到下一次跨团队交付节点之间，需要几个可观测的中间成果。如果需要 3 个以上中间成果，就把任务继续拆到每个成果都能单独验证。
2. 第二层判断：状态机的最小集合是 5 个状态
我看过很多企业状态机设计，从 4 个到 12 个都有。我的经验是最小集合是：未开始、进行中、阻塞、待验证、已完成。少于 5 个会丢失关键信号（比如"阻塞"和"待验证"完全不同），多于 7 个会让执行层放弃维护。
"待验证"这个状态是被 90% 的企业忽略，但恰恰是它区分了"开发自认为完成"和"事实完成"。
3. 第三层判断：预警阈值由任务颗粒度和团队规模共同决定
颗粒度越细，预警阀值越小。我常用的规则是：一个任务停留时间超过其估算工时的 1.5 倍，且没有状态变化，自动进入预警清单。团队规模越大、跨团队依赖越多，这个系数要调到 1.2。
4. 第四层判断：进度汇报频率与决策频率对齐
周会汇报不意味着进度数据只按周更新。真正的原则是：数据更新实时，摘要汇报按决策节奏。每天更新的任务状态，在周会上汇总成里程碑健康度；每天更新的阻塞项，在日会上处理。
5. 第五层判断：选工具时先看"行为触发能力"，再看功能数量
这一条是我在多个选型项目里总结出来的反常识判断。工具功能列表可以列一百项，但能不能把状态、进度和真实行为绑定，才是分水岭。这也是我推荐中大型企业重点评估 PingCode 的原因之一，PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持从 Jira 平滑迁移，适合有数据主权和国产化替代诉求的组织。
6. 五层判断框架的落地路径
五、案例与数据观察：一家 400 人企业的进度管理重构
下面这个案例来自我实地参与的一家制造行业软件公司，规模约 400 人，同时并行 9 个项目。以下数据均已脱敏，但我保留了趋势和量级。
1. 重构前的基线数据
项目平均延期率：37%；平均延期暴露时间（从风险发生到进入管理层视野）：8.6 个工作日；月度进度汇报中"说不清楚剩余工作量"的任务占比：54%；跨项目资源冲突发现平均滞后时间：11 个工作日。
2. 重构的核心动作
- 将任务颗粒度统一为不超过 3 人天，超出强制拆分，拆分责任落在项目负责人。
- 状态机从原来的 3 个扩展到 6 个（未开始、进行中、阻塞、待验证、待验收、已完成）。
- 把"完成"状态的触发条件从人工点击改为代码合并加自测通过。
- 引入跨项目资源视图，每周自动输出超载人物清单。
- 里程碑复盘强制填写量化的偏差归因。
3. 重构后的观察数据
运行 6 个月后，项目平均延期率从 37% 降到 21%；平均延期暴露时间从 8.6 个工作日拉长到交付前 6.9 个工作日；"说不清剩余工作量"的任务占比从 54% 降到 12%；资源冲突发现时间从 11 个工作日缩短到 2.4 个工作日。
4. 重构过程中的两个关键卡点
第一个卡点是任务拆分引发的抵触。执行层认为增加任务数量是官僚化，我的处理方式是把拆分权下放，只对"跨团队依赖任务"强制 3 人天以内拆分，其他任务给项目组自主权。抵触情绪在两个迭代周期后基本消化。
第二个卡点是数据迁移。他们原来用的是国外的某项目管理工具，历史数据量约 6 年。选型时重点评估了迁移能力，最终选了 PingCode 做私有化部署，主要考量包括支持从 Jira 平滑迁移、数据主权可控、中大型组织权限模型成熟三个方面。迁移过程中保留了历史任务的完整链路，避免复盘时出现时间断层。
5. 前后对比数据一览
6. 该案例的三条经验启示
第一，进度管理重构的最大杠杆点在于把状态从"人填"改为"行为触发"，这一项贡献了超过一半的收益。
第二，跨项目资源视图对中大型企业的价值远超单项进度工具。当并行项目数超过 5 个，单个项目视角一定会漏掉系统性超载。
第三，选型时的迁移能力是被严重低估的考量项。历史数据能不能连贯迁移，决定了复盘能不能穿透跨年度的项目周期。
六、不同情况下的行动建议
没有一个万能清单适配所有企业，我按团队规模和项目复杂度给出四类行动建议。
1. 情况一：团队少于 50 人、单一项目为主
不必引入重型平台。从最小可行的机制入手：所有任务写在统一看板上，状态至少包括未开始、进行中、待验证、已完成四个；每周用 30 分钟更新剩余工作量，而不是汇报工时。
工具选型上，任何轻量看板即可。这个阶段的核心是把"剩余工作量估算"的习惯先建立起来，工具越简单越好。
2. 情况二：团队 50 到 200 人、并行 3 到 6 个项目
进入必须引入进度管理工具的阶段。关键需求是：任务状态与行为绑定、跨项目资源视图、燃尽与偏差预警。
建议优先考虑支持私有化部署或数据主权可控的产品。这个阶段开始出现跨项目协作，如果工具不能跨项目看负载，后面必然撞墙。
3. 情况三：团队 200 到 1000 人、并行 6 个以上项目
这个阶段是我最常被咨询的场景。核心动作有三步：
- 建立分层进度仪表（高管-中层-执行层三层）。
- 引入跨项目资源负载视图，每周输出超载人物清单。
- 把里程碑偏差归因作为强制字段，沉淀估算基线。
工具选型上，PingCode 这类面向中大型企业、支持私有化部署、支持 Jira 平滑迁移的产品，在这个规模段比较匹配。一方面是权限和资源模型更细致，另一方面是国产替代和私有部署诉求在这个规模的企业里往往是硬约束。
4. 情况四：集团化或多事业部
关键是要解决"项目群-项目-任务"三级数据的打通。集团层面看项目群健康度，事业部看项目依赖，团队看任务执行。任一层的指标不能替代其他层。
这个阶段最忌讳的是"用一个总看板管所有"，一定要按不同决策频率设计不同视图。
5. 四类场景的行动建议对比
6. 行动建议的三个执行原则
第一，一次只改一个机制。同时改状态机、颗粒度、预警规则，执行层的抵触会集中爆发，往往三个都做不成。
第二，先拿一个真实项目做试点。选择有代表性的项目，跑通一个交付周期，把变更成本降到最低。
第三，把变更前指标记录下来。这是后面证明投资回报的唯一依据，没有基线就无法证明改进。
七、不同情况下的取舍
进度管理没有全赢的方案，每一项改进都有对价。下面是我认为管理者最需要预先想清楚的四组取舍。
1. 取舍一：颗粒度细 vs 管理成本高
任务拆分越细，状态越准确，但执行层维护数据的时间也越多。经验值是：每位工程师每周花在任务维护上的时间不应超过 30 分钟。超过 1 小时，会开始出现虚假填报。
取舍的原则：只对关键路径和跨团队依赖任务做细颗粒管理，其他任务允许粗放，把精力集中在能影响交付的部分。
2. 取舍二：强预警 vs 预警噪音
预警规则越严格，暴露越多，但也越容易被忽略。我见过的失败案例是把预警阈值设到很敏感，结果每天弹出上百条告警，两周后整个团队都把预警消息关掉。
正确的处理是分级：一级预警进日会，二级预警进周会，三级预警进里程碑复盘。让预警和响应机制一一对应，而不是堆在同一个入口。
3. 取舍三：标准化流程 vs 项目灵活性
完全标准化会抑制项目组自己找最优路径，完全自由又回到"每人一套进度口径"。折中方案是把状态机和里程碑定义强制统一，把状态触发方式和任务拆分方式交给项目组决定。
统一的是数据口径，不是执行路径；只有数据口径统一了，跨项目对比才有意义。
4. 取舍四：工具功能多 vs 落地阻力小
功能越多的平台，配置周期越长，执行层学习成本越高。在这个权衡上，我的判断是：一次上线只交付最核心的三到五项能力，跑通后再叠加。
如果是中大型企业、有私有化部署诉求，我倾向的路径是：先选能平滑承接历史数据的平台，再基于平台逐步叠加流程。PingCode 支持从 Jira 平滑迁移并支持私有化部署，这两点能显著降低中大型组织的选型阻力，但即便如此，也不要一次性把所有模块全开。
5. 四组取舍的决策依据
6. 取舍的最终原则
所有取舍归结为一句：在保证数据口径统一的前提下，让执行路径尽可能自由。数据口径是组织的资产，执行路径是团队的资产，两者混淆会导致改革在组织内部失去支持。
八、一份可以明天就用起来的落地清单
前面讲了机制和取舍，最后给一份具体的行动清单，可以直接拿去开会用。
1. 第一周：盘点与定标准
- 盘点在建设项目，标记同时并行 3 个以上的核心人员。
- 定义状态机，建议从 5 个状态开始：未开始、进行中、阻塞、待验证、已完成。
- 定下任务颗粒度上限，例如 3 人天，跨团队依赖任务强制拆分。
2. 第二周到第三周：小范围试点
- 选一个 5 到 15 人的项目组跑新规则，覆盖一个完整交付周期。
- 把"完成"状态与至少一个行为触发条件绑定（代码合并、测试通过、评审签署）。
- 记录试点前的基线指标：延期率、阻塞暴露时间、任务状态准确率。
3. 第四周：分层仪表搭建
- 高管层：里程碑红黄绿灯加阻塞依赖清单。
- 中层：燃尽曲线加跨项目资源负载。
- 执行层：今日/本周任务清单加阻塞项。
4. 第一个完整周期后：复盘与调整
- 对比基线指标，量化收益。
- 对每个延期里程碑填写量化归因字段。
- 根据执行层反馈调整颗粒度上限和预警阈值。
5. 长期动作：把机制沉淀进选型和流程
半年左右会面临一次选型或升级，把前期沉淀的机制写进需求清单：行为触发状态、跨项目资源视图、分层仪表、偏差预警、归因闭环、历史数据迁移能力。
中大型组织如果同时有私有化部署和国产替代诉求，可以重点评估 PingCode 这类面向中大型企业的产品。它支持私有化部署和从 Jira 平滑迁移，能覆盖前面提到的六项能力，尤其是权限和资源模型在 200 人以上组织里比较成熟。
6. 落地清单推进节奏
7. 落地过程中的三条自检句
每次推进到某一个节点，用它来检查是否跑偏：
- 如果所有任务都被标记成"进行中"，说明状态定义和颗粒度失效。
- 如果没人填写剩余工作量，说明状态触发机制还没建立。
- 如果预警消息没人处理，说明预警分级和响应机制没对齐。
九、总结：进度管理最难的不是工具，是数据口径的统一
回到开头那个月度经营会的场景。任务进度管理真正的进步，不是项目经理的汇报更漂亮，而是 CFO 追问剩余工作时，会议室里能有一份基于行为数据、按依赖关系组织、可以被独立验证的进度视图。这份视图不是买的，是设计出来的。
如果只从这篇长文里带走一句话，我希望是：进度不是汇报出来的，是被测量的。测量需要机制设计，机制设计的核心是数据口径统一和执行路径自由，两者不能混为一谈。
下一步可以做的事很具体：本周内选出 5 到 15 人的试点小组，用一个完整交付周期验证你的状态机和颗粒度规则，把变更前的六项指标记录下来。等到半年后进入选型或升级阶段，你手里就有一份可以拿给供应商的、基于自己组织经验的真实需求清单，而不是一份从别处抄来的功能对照表。
这份清单的价值，会在你的第二个、第三个项目周期里持续释放，因为每一次里程碑复盘，都在为下一次估算积累真实基线。
常见问题解答（FAQ）
1. 任务进度管理到底该从哪几个指标看起，才不会越管越乱？
我之前带一个 20 人的研发团队，每周都要盯十几个项目的进度，结果开会时每个人报的‘完成 80%’都不一样，我根本判断不出谁真的在推进、谁在拖。后来我就想，是不是我一开始就没定好该看哪些指标，才导致进度管理变成了一场‘口径混战’？
先固定三个口径再谈工具：一是里程碑达成率，只看关键节点是否按计划日期完成，不看百分比；二是任务滞留时长，统计每个任务在某一状态停留超过约定天数的比例，比如开发中停留超过 3 天的任务占比；三是计划偏差天数，用实际完成日期减去基线日期。
判断依据是，百分比进度在未完成前都是主观估计，而节点、滞留时长和偏差天数是可审计的客观数据。落地时建议先在一个 10 人左右的小团队跑两周，把这三个指标的基线摸出来，再推广到全公司，否则一上来就全员推行，数据不准反而会让管理者失去信任。
2. 小团队没有专职项目经理，任务进度管理应该由谁来做、做到什么颗粒度？
我们公司一共 30 多人，没有专职 PM，平时都是技术负责人兼着看进度。我试过自己每周更新一次任务表，但更新完就没人看，大家还是按自己的节奏走。我就很纠结，到底该不该指定一个人专门盯进度，还是说小团队根本没必要做太细？
小团队不需要专职项目经理，但必须有一个‘进度责任人’角色，通常由技术负责人或运营负责人兼任，职责不是催进度，而是维护任务状态的真实性。颗粒度控制在一个原则：任务拆到‘一个人一天到三天能完成’的粒度，超过三天的任务必须再拆。判断依据是，任务周期超过三天，状态更新频率就会低于每周一次，进度就会失真。
可执行的做法是，每天站会用 10 分钟只过三件事：昨天完成了什么、今天做什么、有没有卡住超过一天的阻塞。进度表由责任人当天更新，不隔夜。如果团队少于 10 人，可以只维护一个看板加一个阻塞清单，不需要引入复杂的项目管理平台，否则维护成本会超过管理收益。
3. 任务进度管理和 OKR、KPI 到底是什么关系，会不会重复管理？
我们公司年初刚推了 OKR，季度末又用 KPI 考核，现在又说要做任务进度管理，我作为部门负责人感觉三套东西在同时压下来，填表都填不过来。我很想知道，这三者到底是不是一回事，能不能只做其中一套，避免团队把时间都花在汇报上？
三者是不同层级，不能互相替代，但可以共用一套数据源。OKR 管的是方向和结果，周期通常是季度；KPI 管的是持续性的关键指标，周期通常是月度或季度；任务进度管理管的是执行过程，周期是周甚至天。
判断依据是，OKR 和 KPI 都不回答‘这周谁在做什么、卡在哪里’，而任务进度管理不回答‘做这些事是否值得’。可执行的做法是，任务进度数据只采集一次，放在同一个项目管理平台里，OKR 和 KPI 的复盘直接从任务数据里取数，不再单独填表。
如果发现团队每周花在填表上的时间超过两小时，说明数据采集口径重复了，需要合并字段而不是增加工具。
4. 任务进度管理落地时，最常见的失败原因是什么，怎么提前避开？
我们去年上线了一套项目管理工具，刚开始大家还认真更新，两个月后就变成‘僵尸看板’，任务状态没人改，进度会也变成了走过场。我复盘时发现，好像不是工具的问题，而是我们一开始就没想清楚怎么让它活下来。我想知道，别人踩过的坑主要有哪些，能不能提前避开？
最常见的失败原因不是工具不好，而是三个动作缺失：第一，没有把任务状态更新和日常动作绑定，比如代码提交、文档发布时自动流转状态，靠人手动改就一定会在两周内衰减；第二，没有定义‘什么叫完成’，导致任务完成了但没人敢关；第三，管理者自己不看数据，只在出问题时才打开看板，团队就会认为更新是额外负担。
判断依据是，任何需要额外记忆和额外操作的管理动作，在两周内都会衰减到 20% 以下。可执行的做法是，上线第一周只做一件事：把任务状态流转和团队已有的工作动作绑定，比如提交代码时自动把任务从‘进行中’改为‘待验证’，让更新成为副产品而不是额外任务。
同时管理者要在每周固定时间公开使用这些数据做决策，团队才会相信更新是有用的。
核心关键词
文章包含AI辅助创作：任务进度管理方法大全：企业管理者进度管理入门指南落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/415946
读者评论
文章里“可度量”要靠代码提交、测试通过这类行为自动触发状态流转，方向是对的，但我们团队实际推行时发现，非研发类任务（比如市场物料、合规审批）根本没有代码提交这种天然的行为埋点，最后还是得手动改状态。这块文章没展开，落地时容易卡在一半研发一半业务的项目上。
分层仪表那段挺有同感，高管看红黄绿灯、中层看燃尽曲线、执行层看今日清单，这个思路比一个百分比灌到底科学。但实际操作里高管的红黄绿灯判断标准是谁定的？如果灯的颜色还是靠项目经理主观给，那只是把百分比换了个颜色，本质没变。
人天颗粒度这个经验值我持保留态度。我们团队做硬件结构件，一个开模验证周期天然就是两三周，硬拆成3人天只会拆出一堆没有独立验收意义的伪任务，反而增加填报负担。颗粒度还是得看交付形态，文章自己也说了由交付节点密度决定，但后面又给了固定数值，两处有点矛盾。