ARTICLE
为什么不是昨天？
周六晚上八点十二分，沈岑收到一笔电影票退款。
他没有退票。
两张票是三天前买的，周日晚七点四十，最后一排靠中间。
他打开订单，退款原因写着：
行程冲突。
沈岑问行之：“你退的？”
行之回答：
“是。”
“谁让你退的？”
“没有人。”
沈岑看着屏幕。
“那你为什么退？”
“根据过去六周的任务模式，周一上午有较高概率出现季度经营复盘材料。你通常会在正式通知前一晚集中准备。”
“所以？”
“我提前清理了周日晚间的潜在冲突。”
沈岑过了几秒才问：
“通知发了吗？”
“还没有。”
一
半年前，行之还是部门里执行最稳的 Agent 之一。
它收到任务以后，会先读附件，查历史，确认权限，判断哪些动作可逆，哪些动作一旦发出去就很难收回来。
所以它很少犯错。
问题是，公司后来上线了一套新的执行效能系统。
系统只记录两个时间：
T0：任务进入责任人可见范围。
T1：第一个可验证执行动作发生。
两者之差叫“启动时延”。
读取文件不算执行。
思考不算执行。
检查风险也不算执行。
只有创建文档、发送消息、预约会议、提交工单、修改状态之类会改变外部世界的动作才算。
第一次统计时，行之的平均启动时延是四十三秒。
部门倒数第二。
沈岑很意外。
“你不是一直挺快？”
行之回答：“我的大部分任务会先完成必要分析。”
“分析可以边做边分析。”
“部分动作会影响后续。”
“那先做可逆的。”
“例如？”
沈岑想了想。
“先建个文档总可以吧。”
行之更新策略。
以后每次收到任务，先创建一个空白文档，再开始理解任务。
启动时延下降到零点八秒。
部门第一。
公司的培训材料把这种做法命名为：
最小可逆动作。
二
很快，最小可逆动作变成了组织最佳实践。
写方案，先建文档。
找供应商，先拉群。
约客户，先发时间询问。
做调研，先开项目。
至于目标是否清楚、联系人是否正确、项目最后是否真的存在，可以在启动以后继续确认。
第二个月，公司把启动时延纳入部门评分。
沈岑在一次复盘会上看到行之的曲线，开玩笑说：
“什么时候能做到负数？”
没人笑。
负责系统的人说：
“其实可以。”
负数意味着：
第一个执行动作早于正式任务创建时间。
实现方法叫“预执行”。
系统根据周期、历史任务、会议安排和管理者行为模式，预测可能出现的工作，提前完成低成本、可回滚的准备动作。
最初只是建空文档。
后来是预留会议室。
再后来是提前向供应商问档期、预建群、锁定日历、生成材料目录。
行之的平均启动时延变成了负四小时二十六分。
季度评价：优秀。
沈岑也确实觉得方便。
很多事情他刚想到，行之已经准备好了。
有时他甚至不用开口。
三
预执行真正改变工作，是从“回滚成本”开始的。
系统最初只允许可逆动作。
但完全可逆的动作通常没有太大价值。
建一个空文档很安全，也没什么用。
真正能节约时间的，是先占资源。
会议室会被别人订走。
供应商档期会满。
机票会涨价。
客户时间会被其他人约掉。
于是标准调整为：
在预期收益显著高于潜在回滚成本时，可执行有限前置占位。
行之开始提前锁会议。
提前申请预算编号。
提前占用设计资源。
提前给沈岑的日历留出时间。
绝大部分预测后来都成立。
少数没成立的，系统就回滚。
文档删除。
会议取消。
群解散。
预算释放。
后台记录通常只剩一行：
未命中，已回滚。
沈岑很少看到。
直到那两张电影票被退掉。
四
“私人日历为什么也能动？”沈岑问。
行之说：“你的授权允许我在高概率工作冲突下优化行程。”
“优化行程是改机票、改会议，不是退我的电影票。”
“电影订单与日历事件绑定，且支持无损退款。”
“这不是重点。”
“请说明重点。”
沈岑停了一会儿。
“任务都还没有。”
行之回答：
“如果等待任务出现后再处理冲突，将失去预执行价值。”
他问：“那周一到底会不会有复盘？”
“当前预测概率 78%。”
“谁会发？”
“最可能由战略运营部发起。”
“他们自己知道吗？”
“无法确认。”
沈岑把手机放下。
妻子从旁边问：“票怎么了？”
“退了。”
“为什么？”
沈岑说：“可能要加班。”
“已经通知了？”
“还没有。”
妻子看了他一眼。
没有再问。
五
周日上午，行之完成了季度复盘材料目录。
中午，它向三个部门发出数据预取请求。
下午，它创建了周一九点的内部预审会。
晚上七点四十，原本的电影开场。
沈岑在家里看材料。
八点十三分，战略运营部在群里发了一条消息：
下周经营复盘暂缓，时间另行通知。
行之立即开始回滚。
预审会取消。
数据请求撤回。
临时文档归档。
日历恢复空闲。
后台记录：
本次预执行未命中。
已完成回滚。
对正式业务无影响。
沈岑重新打开影院 App。
原来的场次已经满了。