中断成本应纳入排期

很多排期失败，并不是任务估时过短，而是把“被打断”当成了零成本事件。临时会议、消息确认和顺手修改通常只占用几分钟，但真正的损耗还包括中断前的上下文保存、恢复时的重新定位、判断反复以及由此产生的返工。对于内容自动化、站点运营和 AI 工具开发，这类隐性成本足以让核心交付在下班前仍未完成。

因此，排期不应只记录任务本身需要多久，还要记录任务对连续专注时间的要求，以及可能出现的响应型工作。需要深度思考、连续操作或多轮验证的事项，应被视为“不可随意切割”的工作块；线上异常、阻塞协作的问题和确有决策内容的会议，则应单独列入响应安排。其余描述模糊、影响范围未确认的插入需求，不宜直接挤入当前工作。

先确定不可被挤走的交付

当天最好只设定一项核心交付，而且必须能验收。例如，“完成一篇教程初稿并进入审核”比“写文章”更适合作为排期对象；“确认自动发布流程在测试环境可完整运行”也比“研究发布问题”更清楚。判断标准可以是：不完成是否会延误发布或后续协作，是否需要连续思考时间，完成后是否留下可复查结果。满足其中两项，就应优先保护。

排期时还要为插入任务预留处理窗口，而不是让通知随机决定顺序。可以在开始核心工作前、推进一段时间后和收工前集中查看消息。非处理时段收到的需求，先记录需求内容、提出者、期望结果和再次判断时间；只有线上异常、当天发布受阻或关键协作无法继续时，才适合立即打断。

把中断写进待办

每次被打断，先记录核心任务停在哪里、下一步是什么。待办不只是任务收集器，更应成为上下文恢复记录。回复他人时，也应明确当前交付和预计处理顺序，而不是只说“收到”。如果新需求必须当天完成，就应把它将要挤占的原定工作公开说明，由相关人员共同决定优先级。

这样排期管理的就不只是小时数，而是注意力、恢复成本和交付风险。临时任务仍会发生，但它们不再隐性吞掉核心工作，而会以可见的代价进入取舍。