百度优化服务：合同内任务和临时救火任务怎样分别排期
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b1506882df9f.html
📄
百度优化服务：合同内任务和临时救火任务怎样分别排期
先给结论：合同内任务按“交付物依赖顺序”排，临时救火任务按“影响面×恢复成本”排，两者共用同一份资源日历，但临时任务只在触发条件成立时才插队。判断依据不是谁催得急，而是这件事卡住了哪条链路、不处理会损失什么。下面用你手里的项目排期表或任务清单，一步步把它变成可执行的分流方案。
先把现有任务分成三类，而不是两类
很多人只分“合同内”和“临时”，结果临时任务一多，合同内全部停摆。更实用的做法是在这两类之外加一类“合同内但被临时任务阻断的依赖项”。
- 合同内固定交付：站点结构梳理、栏目页内容补充、内链调整、数据监测配置这类有明确验收物的任务。
- 临时救火：收录异常、流量骤降、页面报错、批量内容被删这类需要当天响应的事件。
- 被阻断的依赖项：本身属于合同内，但必须等某个临时问题解决后才能继续，例如模板报错没修完，内容就发布不了。
分类动作：打开你现在的任务表，给每条任务标上它属于哪一类，并写清“它卡住了谁”。这一步做完，你会发现真正需要插队的临时任务通常只占少数，其余可以排队。
合同内任务的排期依据：交付物依赖顺序
合同内任务不该按“先来后到”或“客户催得紧”排，而应按交付物之间的依赖关系排。判断方法很简单：问一句“如果这条没做完，哪条任务无法开始”。
假设一个场景：合同约定三个月内完成一批栏目页优化。任务包括关键词归类、页面结构模板确定、内容撰写、发布与内链、数据回收。这里的依赖链是：关键词归类 → 模板确定 → 内容撰写 → 发布 → 数据回收。模板没定，内容写了也可能返工，所以模板任务优先于内容任务，即使内容任务量更大。
实际动作：在排期表里为每条合同内任务加一列“前置任务”。当前置任务为空时，这条才可以进入本周执行队列；前置任务未完成时，它只能排在等待区。这样排出来的顺序天然稳定，不会因为某天临时任务多就全乱。
临时救火任务的插队条件与优先级
临时任务不能一律插队，否则合同内永远做不完。给临时任务设两个判断维度：影响面（影响多少页面或多少业务环节）和恢复成本（不处理会持续恶化，还是一次性损失）。
- 影响面大且持续恶化：例如核心栏目页大面积无法访问，属于最高优先级，立即暂停合同内非依赖任务。
- 影响面大但已稳定：例如某批页面收录下降但不再继续掉，可以排进当天或次日的固定时段处理，不必打乱整周计划。
- 影响面小但会扩散：例如个别页面出现错误跳转，若不处理可能被大量复制，按半天内响应处理。
- 影响面小且不扩散：例如单个页面标题重复，进入合同内任务队列，不单独插队。
关键动作：为每条临时任务记录“触发时间”和“当前是否仍在恶化”。如果一条临时任务连续两次检查都没有继续恶化，就把它降级为合同内任务处理，释放出的时间回到原计划。
用同一份资源日历合并两类任务
合同内和临时任务争的是同一批人、同一段时间，所以必须放在同一份日历上排，而不是两张表各排各的。做法是：日历以半天为最小单位，每天预留固定比例的“救火窗口”，其余时间锁定给合同内任务。
假设你每天可用工时为 8 小时，可以预留 2 小时作为救火窗口，剩下 6 小时按依赖顺序分配给合同内任务。如果某天临时任务超过 2 小时，超出部分从当天的合同内任务中扣除，并顺延到下一个可用窗口；如果连续三天临时任务都超过预留量，说明预留比例需要调整，而不是继续压缩合同内任务。
这个动作的结果会直接影响下一步：当救火窗口连续被占满，你要做的不是加班，而是重新评估临时任务的来源——是监测配置不完整导致反复发现同类问题，还是交付流程缺少检查环节。找到反复救火的共同原因，把它转成一条合同内任务，才能减少下一轮的插队次数。
什么时候该改变排期策略
有两种情况需要改变原有排法。第一种：临时任务连续出现且原因相同，说明它不是“救火”，而是合同范围漏掉的基础工作，应把它正式列入合同内任务并重新排依赖顺序。第二种：合同内任务的前置条件长期无法满足，例如模板确定一直拖延，导致后续内容任务全部堆积，此时应暂停内容排期，把资源集中到前置任务上，而不是继续按原顺序推进。
判断标准可以落到一个具体信号：如果同一类临时任务在一周内出现三次以上，或者某条合同内任务连续两周都因为前置未完成而无法启动，就触发策略调整。调整后的排期表要重新标注前置任务和救火窗口，再按上面的方法执行。
最后提醒一点：排期表本身不是承诺，它只是当前信息下的资源分配方案。每次临时任务处理完，把实际耗时和影响回填到表里，下一次排期才有依据。没有回填，你永远只能凭感觉决定谁先谁后。
