进度偏差实操方法：PMO提升进度管理效率的效率提升方法与模板

进度偏差这个词在 PMO 的日常里出现的频率极高，但真正管住它的团队少之又少。我在过去八年里先后在制造业、金融科技和一家三百人规模的 SaaS 公司做过 PMO 负责人，经手过立项评审到交付验收的全过程。见过最离谱的一次是：一个预算八百万人力成本的项目，在里程碑评审前两周才发现关键路径已经延迟了三十七天，而工具里的进度条还显示"完成度 78%"。那次事故之后，我把进度偏差的管理方式彻底推倒重来。

这篇文章不讲教科书定义，只讲我实际用过、踩过坑、并且在三种不同规模组织里验证过的操作方法、阈值模板、指标口径和工具配置方案。

一、先给结论：进度偏差管不住，八成不是算法问题

很多 PMO 在进度偏差上投入了大量精力，做偏差率计算、画挣值曲线、出周报、开例会，但项目的按期交付率并没有明显改善。我复盘过自己在三家公司推行过的四套方案，最后得到的结论是：绝大多数团队卡住的不是"怎么算偏差"，而是"偏差从发生到被人看见之间隔了多久"。

1. 真正的瓶颈是反馈延迟

进度偏差有两个时间戳：一个是偏差实际发生的时间，另一个是它被管理层知晓的时间。这两个时间戳之间的间隔，我称之为偏差发现延迟。在手工周报驱动的组织里，这个数字通常是 7 到 10 天；在配置了自动化触发的组织里，可以压缩到 1 天以内。

关键在于，偏差一旦发生，它会持续累积，而不是保持恒定。一个被推迟 3 天的接口联调，如果第 9 天才被发现，那时它往往已经拖着三个下游任务一起延期了。所以 PMO 真正要优化的目标，是把发现延迟从"周"压缩到"天"甚至"小时"，而不是把偏差率算到小数点后两位。

2. 偏差管理的最小闭环只有四步

我在内部推行时把它总结成四个动作：定义阈值、自动触发、强制归因、指定收敛动作。这四步缺任何一步，整个机制都会退化成"填表运动"。阈值决定谁需要被提醒；触发决定提醒是否及时；归因决定提醒是有价值还是噪音；收敛动作决定偏差是被消除还是被记录。

我见过太多团队只做了第一步和第三步，也就是定义了阈值、要求写归因，但没有触发机制也没有收敛动作，结果就是每周产出一堆没人处理的偏差清单。

3. 模板解决的是判断标准，不是填表动作

这是我特别想强调的一点。很多人做进度偏差模板，做出来的是"填表模板"，要求项目经理每周填写任务名称、计划完成时间、实际完成时间、偏差天数、原因说明。这种模板的价值极低，因为它只收集数据，不输出判断。

真正有用的模板应该是"判断模板"：什么样的偏差需要上报、什么样的偏差可以自行消化、什么样的偏差需要升级到项目集层面协调资源。模板的核心是分级判断规则，而不是字段越多越好。

4. 效率提升来自减少搬运，不是增加报表

PMO 的工作时间花在哪里，是我特别喜欢统计的一件事。我曾经连续六周记录自己团队的时间分配，发现 54% 的时间花在"从各个来源收集进度数据、整理成统一格式、再复制到报表里"这类搬运工作上。这类工作不产生任何管理价值，但它吃掉了 PMO 一半的人力。

所以进度管理效率提升的第一优先级，是把这类搬运工作自动化掉。如果你的团队能把这 54% 压缩到 15%，相当于凭空多出半个 PMO 的人力。

二、三个真实现场：进度偏差管理是怎么失效的

抽象的方法论讲再多，不如看三个具体现场。这三个现场分别代表了我见过的三种典型失效方式，它们的问题不在同一层，所以解法也完全不同。

1. 现场 A：周报驱动的 PMO，数据永远是上周的

这是我接手的第一家公司，一家做工业设备的制造企业，IT 部门大约 60 人，同时跑着七八个系统项目。PMO 的工作模式是：每周四下午发模板给各项目经理，周五收集，周一整理，周二例会上汇报。

问题出在时间差上。项目经理周四周五填的数据，反映的是那一周的情况；但等到周二例会讨论时，已经是下一周了。如果周三出现了新的阻塞，这个阻塞要等到下下周的例会才会被讨论。整个组织的偏差感知能力，天然滞后了一周半。

更麻烦的是，项目经理填的"预计完成时间"往往是乐观估计。他们知道这个数字会进周报，会进例会，所以会稍微往好看的方向写一点。当填报行为被考核绑定，填报数据就会失真，这是几乎所有手工周报体系的通病。

2. 现场 B：Excel 甘特图专家，一个人维护两千行

第二家公司是一家金融科技公司，PMO 有一位非常专业的同事，用 Excel 做了一套极其精细的进度管理模型，包含两千多行任务、五级 WBS、自动计算关键路径、自动计算偏差率。这套表做得非常漂亮，我第一次看到时是真心佩服。

但它有一个致命问题：只有他一个人会维护。他休假的那一周，整个进度管理就停摆了。而且这套表的更新依赖每周从各团队收集进度，收集一次要花掉他两天时间。他的时间几乎全部消耗在维护这套表上，而没有余力去做真正的协调和风险干预。

这件事让我形成了一个判断：任何只有一个人能维护的进度管理体系，都是脆弱的。体系的价值在于它能在组织里持续运转，而不是在于它有多精密。

3. 现场 C：工具先进，但没人定义偏差阈值

第三家公司采购了项目管理平台，任务、工时、迭代、看板都搬上去了，数据量比前两家都丰富得多。但我进去之后发现，这个平台上的数据几乎没人看，因为它不产生任何提醒，也不生成任何管理视图。

项目经理完成任务后随手更新状态，PMO 也不做巡检。表面上所有数据都在，实际上没有任何机制把这些数据转化成"需要干预的信号"。这就是最典型的"有数据、无信号"状态。

我在第二季度做了一次抽样：随机抽取 30 个已延期的任务，逐个追溯它在平台上留下状态更新的时间。结果是：从计划完成日到任务状态真正被改为"延期"，平均间隔 11 天，最长的一个隔了 26 天。

4. 从三个现场抽出的共同规律

把三个现场放在一起看，规律就非常清楚了。现场 A 的问题在数据滞后，现场 B 的问题在维护成本，现场 C 的问题在缺少阈值和触发。它们最终指向的还是同一件事：偏差从发生到被看见之间的时间，从未被当作核心指标来管理。

而这三个现场还有另一个共同点：偏差的根因分布高度相似。我把三年内记录过的 47 个延期事件做了归因分类，结果如下。

三、五个常见误区，我几乎在每个组织都见过

在给出方法之前，必须先清理掉几个反复出现的错误做法。这些误区不是理论问题，是我在真实组织里见过并且付出过代价的。

1. 误区一：把进度偏差率当成考核指标

这是危害最大的一个。我见过一家公司把"项目进度偏差率不超过 5%"写进了项目经理的绩效指标。执行一个季度后，出现了两个明确的行为变化：第一，偏差上报量骤降；第二，上报的偏差普遍变小。

原因很直接：如果上报偏差会被扣分，理性选择就是不上报，或者把大偏差拆成几个小偏差。任何被用于考核的偏差指标，都会在三个月内失去真实性。进度偏差是诊断工具，不是评价工具，这个边界必须守住。

2. 误区二：用完工百分比衡量一切

"这个模块完成 80%"是项目会上最常见也最没有信息量的一句话。80% 是什么口径？是代码写完，还是自测通过，还是联调完成？不同的人给同一个任务打百分比，结果可能相差 30 个百分点。

我的做法是用可验证的完成标准替代百分比。比如把"接口开发完成 80%"换成"12 个接口中 9 个通过契约测试"。前者是主观判断，后者是可核验的事实。这个替换看起来简单，但它能让进度数据的可信度提升一个量级。

3. 误区三：阈值一刀切，所有任务都是 ±10%

有些团队为了简化，给所有任务设同一个偏差阈值，比如超过 2 天就报警。结果是关键路径上的一天延迟和边缘任务的一天延迟被同等对待，告警泛滥，真正重要的信号被淹没。

合理的做法是按任务的关键性和浮动空间分档。关键路径任务可能需要零容忍（偏差 0.5 天即触发），而浮动时间充足的非关键任务可以容忍 3 到 5 天。这个分档逻辑我在后面会给出具体模板。

4. 误区四：只报偏差，不报收敛路径

一条只有"某任务延期 5 天"的报告，对管理层几乎毫无价值，因为它不包含任何可决策的信息。真正有用的偏差报告必须包含三件事：影响面（是否影响关键路径和里程碑）、归因（为什么会这样）、收敛方案（准备怎么做，需要什么支持）。

我后来在模板里强制要求：任何上报的偏差，必须附带至少一个收敛动作和一个决策请求。没有收敛动作的偏差，一律不进入管理例会。

5. 误区五：以为买了工具偏差就自动消失

工具解决的是数据采集和信号触发的效率问题，但阈值定多少、归因怎么看、收敛动作怎么选，这些依然是人的判断。我见过不止一个团队上了平台之后，把原来的 Excel 表格原封不动搬上去，然后抱怨"工具没什么用"。

工具的收益，取决于你用它替换掉多少人工搬运和多少延迟感知。工具不会自动带来管理能力，它只会放大你已有的管理能力。

四、归因逻辑：一个项目的偏差是怎么累积起来的

要做出正确的干预，必须知道偏差是从哪一层长出来的。我把进度偏差的成因拆成四层，这个模型是我在多个项目集复盘时逐步归纳出来的，它的价值在于给出一个固定的排查顺序。

1. 第一层：估算与承诺偏差

这一层发生在计划阶段。任务的估算工期本身就偏乐观，或者承诺的时间点是被外部压力"压"出来的，而不是基于历史数据推出来的。这类偏差的特点是：它在任务开始那一刻就已经存在了，只是要到任务接近尾声才暴露。

识别方法是做估算校准：把过去半年同类任务的实际工期和估算工期做对比，算出每个团队的估算系数。我见过的一个团队，估算系数稳定在 1.6，也就是说他们报 10 天的任务实际平均要 16 天。知道这个系数之后，排期时就能提前修正。

2. 第二层：依赖与资源偏差

这一层是跨团队协作的产物。你的任务没延期，但你等的那个接口没交付，或者你要的那位测试工程师被临时抽调到另一个项目。这类偏差的特点是：它发生在你的控制边界之外，所以你很难通过自己的努力消除它。

对付这一层，唯一的办法是在计划阶段把依赖关系显性化，并且为每个外部依赖指定一个明确的责任人和承诺时间。承诺时间必须是对方主动给出的，而不是你替他填的。

3. 第三层：范围与变更偏差

需求变更、追加功能、合规要求调整，都属于这一层。它的危险在于变更本身往往被快速批准，而工期的同步调整被忽略。我在复盘时发现，超过三分之一的重大延期，都能追溯到至少一次"改了需求但没改工期"的事件。

我的做法是建立一条硬规则：任何范围变更必须同时提交工期影响评估，没有工期评估的变更不予受理。这条规则会拖慢变更审批速度，但它能挡住绝大多数隐性延期。

4. 第四层：反馈延迟偏差

这一层不产生偏差，它放大偏差。前三层的偏差本来可能只有 3 到 5 天，但因为发现得晚，实际造成的延误变成了 15 天甚至更多。这一层是 PMO 最应该优先治理的对象，因为它完全在管理机制的可控范围内。

5. 判断顺序：先找反馈延迟，再找前三种

我给自己团队定的排查顺序是：先看这个偏差是什么时候被发现的，再看它为什么发生。如果发现延迟超过 3 天，那么首要问题就是发现机制，而不是变更管理或估算能力。因为如果连及时发现都做不到，改善其他三层的能力就没有意义，你永远在事后补救。

五、可直接使用的指标、阈值与模板

前面讲的是判断逻辑，这一节给出可以直接抄走使用的东西。所有指标口径和模板都是我在实际项目里跑过至少两个季度的版本，你可以根据自己组织的情况调整数值。

1. 五个必看指标

我不建议 PMO 看太多指标，五个足够覆盖进度偏差管理的全链路。指标太多会导致注意力分散，反而不如聚焦。

其中偏差发现延迟是我认为最被低估的一个指标。绝大多数团队从来不统计它，但它直接决定了其他所有指标的上限。如果你的发现延迟是 9 天，那么闭环周期不可能压到 5 天以内。

2. 阈值分级模板

阈值的设计要同时考虑两个维度：任务是否在关键路径上，以及任务还有多少浮动时间。我用的分级规则如下，你可以直接套用。

• A 级（关键路径，浮动 0 天）：偏差 ≥ 0.5 天即触发预警，直接通知项目经理与 PMO。
• B 级（关键路径，浮动 ≤ 3 天）：偏差 ≥ 1 天触发预警，通知项目经理。
• C 级（非关键路径，浮动 3-10 天）：偏差 ≥ 3 天触发提醒，任务责任人自行处理。
• D 级（非关键路径，浮动 > 10 天）：偏差 ≥ 5 天触发提醒，纳入周度巡检即可。

这个分级的关键在于 A 级的严格程度。0.5 天的阈值听起来过于敏感，但关键路径上的半天延迟往往会连锁影响到后续两到三个任务。宁可多几条预警，也不要漏掉关键路径的信号。

3. 进度偏差周报模板

下面这个模板是我用了最久的一版。它的特点是把"数据"和"判断"分开，数据部分可以自动生成，判断部分必须由人填写。

注意最后一列"决策请求"。这一列是让偏差报告产生管理价值的关键。如果一份偏差报告连续四周的决策请求都是"无"，说明要么偏差确实轻微，要么项目组在自行消化本应上报的风险。

4. 偏差复盘模板

偏差闭环之后不是结束，还需要一次轻量复盘。我的模板只有四个问题，控制在 15 分钟内完成。

1. 偏差实际发生时间与发现时间分别是什么时候，间隔多少天？
2. 按四层归因模型，主因属于哪一层？
3. 如果提前 3 天发现，结果会有什么不同？
4. 需要固化到流程或工具里的一条改进是什么？

第四个问题是复盘的产出。我要求每次复盘至少产出一条可执行的改进项，并且要明确它落在流程里还是工具里。半年下来，这类改进项的累积效果远比一次大规模流程再造要明显。

六、工具落地：把模板变成自动触发的机制

有了指标和模板之后，接下来的问题是：怎么让它们在没有 PMO 人力投入的情况下自动运行。这一节我用 PingCode 作为落地案例来讲，因为它是我在中大型组织里实际配置过的平台之一，具备描述自动化触发所需的能力。

1. 为什么 Excel 撑不过 50 人

我在第二家公司经历过一次规模跃迁：团队从 40 人扩到 90 人，项目的跨团队依赖数量从 20 多个涨到 80 多个。那套精心维护的 Excel 模型几乎在一夜之间失效了，不是因为表写错了，而是因为收集数据的成本随着协作方数量的增加呈非线性上升。

40 人的时候，一个人跟进所有人是可行的；90 人的时候，这个人的时间被彻底吃满，而且他没办法同时感知到多个团队之间的依赖变化。Excel 的天花板不是功能上限，而是人工采集成本的上限，一般在 50 到 80 人之间就会撞到。

2. 以 PingCode 为例的数据模型设计

PingCode 主要服务中大型企业及 100 人以上组织，这一点和进度偏差治理的需求是匹配的，规模越大，跨团队依赖越复杂，人工感知越不可行。我在配置时遵循"三层数据模型"的思路，先定结构再配自动化。

第一层是任务层，承载计划开始日、计划完成日、实际完成日、浮动时间这几个字段。这几个字段是偏差计算的原料，必须强制填写，且不允许在任务执行中途随意修改计划日期，需要修改时必须走变更流程。

第二层是依赖层，显式记录任务之间的前置后置关系，并标注每个依赖的方向和责任人。这一层的作用是把"我等别人"这种隐性状态变成可查询的数据。

第三层是里程碑层，把关键路径上的任务挂载到里程碑上，这样任何关键路径任务的偏差都能直接反映到里程碑的健康度上。

3. 自动化规则配置示例

数据模型建好之后，核心工作是把阈值判断变成自动执行的规则。下面这段是我配置关键路径偏差预警时使用的规则结构，你可以按自己平台的规则引擎能力做等价映射。

trigger:
type: scheduled_check

cron: "0 9,15 * * 1-5" # 每个工作日 9 点和 15 点各巡检一次

conditions:

field: on_critical_path

operator: equals

value: true

field: schedule_variance_days

operator: greater_than_or_equal

value: 0.5 # A 级阈值

actions:

action: notify

targets: [task_owner, project_manager, pmo_channel]

template: "关键路径偏差预警：{task_name} 已偏差 {variance} 天"

action: create_record

type: "偏差收敛行动项"

required_fields:

归因层级 # 估算 / 依赖 / 变更 / 反馈延迟

影响面评估

收敛动作

决策请求

due_within_days: 1

这段规则里有三个设计细节值得说明。第一，巡检频率是每天两次而不是每天一次，因为上午发现的偏差可以在当天下午就组织协调。第二，创建记录时把归因和收敛动作设为必填，避免出现"只报偏差不给方案"的情况。第三，行动项的响应时限设为 1 天，这是压缩闭环周期的关键约束。

除了偏差预警，我还配置了一条依赖承诺提醒规则：凡是跨团队依赖，如果前置任务的责任人在 48 小时内没有确认承诺时间，系统自动提醒该责任人的直线经理。这条规则把"依赖无人认领"这类问题的暴露时间从周级别压缩到了两天以内。

4. 落地节奏：三周上线的实施路径

我在 180 人的研发组织里推过一次完整落地，实际耗时三周。节奏如下。

1. 第一周：数据模型与字段标准化。统一计划日期、浮动时间、关键路径标记三个字段的填写规则，历史数据做一次批量清洗。
2. 第二周：阈值配置与规则上线。先只上线 A 级和 B 级两条规则，观察一周的告警量，避免一次性全量开启造成告警疲劳。
3. 第三周：模板嵌入与试点。把周报模板和复盘模板嵌入到平台的自动化输出中，选两个项目集试点，收集反馈后调整阈值。

关于部署方式，如果组织有数据不出内网的要求，PingCode 支持私有化部署，这一点在金融和制造业客户里是刚需。另外如果你原本使用的是 Jira，PingCode 支持 Jira 平滑迁移，包括工作项类型、字段映射和迭代历史，迁移过程中不需要重建项目结构。对国产替代有明确要求的组织来说，这是一个不需要从零开始的路径。

七、不同情况的行动建议

方法和模板不是所有组织都能照搬，规模不同、项目形态不同、合规要求不同，优先级也应该不同。下面按四种典型情况分别给出建议。

1. 20-50 人团队：先做可见性，不做精度

这个规模的组织，PMO 往往只有一到两个人，甚至是由技术负责人兼任。此时最不该做的就是上重型流程。建议只做三件事：把任务搬到统一平台上、把计划完成日期设为必填、每周做一次人工巡检。

这个阶段的目标是让进度数据"存在且可查"，而不是追求偏差率的计算精度。偏差阈值可以先设得宽一些，只关注关键路径上的重大偏差。

2. 50-200 人团队：先做阈值和触发

这是我最有经验的一个区间，也是收益最明显的区间。此时人工巡检已经不可行，但组织规模又不足以支撑复杂的度量体系。核心动作是把 A 级和 B 级两条阈值规则跑起来，先解决反馈延迟。

这个阶段不要急着做偏差率排行榜，也不要做多维度的度量看板。先把"偏差当天能被发现"这件事做扎实，一两个季度之后再考虑更复杂的度量。

3. 200 人以上或多项目集：先做统一数据模型

规模到这一层，最大的问题不再是单个项目的偏差，而是项目之间的资源冲突和依赖冲突。此时需要先把任务、依赖、里程碑三层数据模型统一，让跨项目集的依赖关系可以被查询。

这个阶段我建议 PMO 配置一个专职的"度量与工具"角色，负责维护数据模型和规则配置。这个角色不参与具体项目协调，只保证度量体系的有效性。

4. 有私有化部署和国产替代要求的组织

金融、制造、能源这类行业的组织，通常有明确的数据本地化要求，同时对工具的可控性有较高期待。这种情况下，选型的第一标准不是功能丰富度，而是是否支持私有化部署、是否有成熟的历史数据迁移路径。

PingCode 在这两个维度上是有优势的：支持私有化部署，支持 Jira 平滑迁移。对于正在做工具替换的组织来说，迁移成本往往是最大的隐性成本，而平滑迁移能力直接决定了替换周期是一周还是三个月。

八、取舍：进度管理效率提升从来不是全都要

所有方法都有代价，进度偏差管理尤其如此。这一节我把实际决策中最常遇到的五个取舍讲清楚，方便你在自己的组织里做选择。

1. 精度与频率的取舍

你可以每周精确统计一次，也可以每天粗略看一次。我的经验是频率优先于精度。每天看一眼大致趋势，比每周算一次精确偏差率更有价值，因为偏差管理的本质是与时间赛跑。

只有当组织进入成熟期、偏差发现延迟已经稳定在 1 天以内之后，才值得投入精力去提升统计精度。

2. 标准化与灵活性的取舍

统一的数据模型让跨项目对比和汇总成为可能，但会牺牲一部分项目特性。比如研发项目和实施项目对"完成"的定义完全不同，强行统一会让数据失真。

我的处理方式是统一字段，不统一取值规则。计划完成日、实际完成日、浮动时间这些字段必须全组织统一；但"什么算完成"可以由项目类型自己定义，只要定义是书面化的、可核验的。

3. 自动采集与人工判断的取舍

自动化能采集状态变化、时间戳、依赖关系，但它采集不到"这个任务其实还有隐藏风险"这类判断。所以我的原则是：数据自动采集，判断人工输入，两者在同一个界面上交汇。

这就是前面模板设计里把"数据字段"和"判断字段"分开的原因。如果让系统去猜归因，结果往往不可靠；如果让人去收集数据，成本又太高。

4. 强管控与自组织的取舍

严格的阈值和强制的收敛动作会提升可预测性，但也会增加项目经理的行政负担，长期可能导致抵触。我见过配置过度的团队，项目经理每天要处理十几条系统提醒，最后全部选择忽略。

解决办法是从最少的规则开始，逐步增加。先只上关键路径的预警，跑顺了再加依赖承诺提醒。每加一条规则之前，先问一句：这条规则命中时，我们真的会采取行动吗？如果答案是否定的，就不要加。

5. 自研与采购的取舍

自研的好处是贴合度高，坏处是维护成本高、依赖特定人员。前面现场 B 那位 Excel 专家的例子就是典型：他的模型很贴合业务，但只有他能维护。

我的判断标准是：如果进度管理不是你的核心业务能力（比如你不是在做项目管理软件），那就不要自研。把工程资源投在主业上，把进度管理交给成熟平台，这在中大型组织里通常是更划算的选择。

九、总结：进度偏差管理中最容易被忽略的那个变量

写了这么多方法和模板，如果只让我留一句话，那就是：进度偏差管理的核心变量不是偏差大小，而是偏差被发现的速度。我经手过的所有改善案例里，效果最明显的动作都是缩短发现延迟，而不是提高偏差计算的精度。

第二个独特判断是：偏差数据绝对不能进考核。一旦进度偏差和绩效绑定，数据的真实性会在一个季度内崩塌，你得到的所有报表都会变成"好看但没用"的东西。把偏差当作诊断信号，把收敛速度当作管理目标，这个边界要守住。

第三个判断是：模板的价值在判断，不在字段。一份好的进度偏差模板，应该让人在 15 分钟内做出"要不要升级、找谁协调、多快收敛"这三个决定，而不是让人花两个小时填写二十个字段。

下一步怎么做：30 天行动清单

如果你读到这里觉得可以试试，下面是我建议的第一个月行动路径，按周拆解，每一步都有明确产出。

1. 第 1 周：测量现状。抽取过去三个月内 30 个延期任务，逐个追溯"计划完成日"到"状态被标记为延期"的间隔天数，算出你的偏差发现延迟基线。这一步不做任何改进，只做测量。
2. 第 2 周：定义阈值。按关键路径和浮动时间把任务分成 A/B/C/D 四级，为每一级设定偏差阈值。先只上线 A 级规则，观察一周的告警量是否在可接受范围内。
3. 第 3 周：嵌入模板。把周报模板中的"归因层级、影响面、收敛动作、决策请求"四个判断字段上线，要求所有 A 级偏差必须填写，且收敛动作必须指定责任人和完成时间。
4. 第 4 周：复盘校准。统计本周的偏差闭环周期，对比第 1 周的基线数据。如果发现延迟没有下降，检查是阈值设置过宽还是触发频率过低；如果告警量过大导致被忽略，就收紧到只保留关键路径预警。

一个月之后，你会得到一个清晰的数字：你的组织从偏差发生到被发现，到底需要几天。这个数字比任何偏差率都更能说明你的进度管理能力处在什么水平。接下来的所有优化，都是围绕把这一天数继续往下压。