把排班任务交给 Codex 的那个晚上上周三临下班前我把一份排班表的生成任务丢给了 Codex。需求不算复杂根据 30 人的可用时间、岗位技能标签和劳动法规定的连续工作上限自动生成下个月的值班表。但变量够多——有人只能上白班有人周末完全不行还有几个岗位必须保证同时在线人数。我预估这活儿如果手动排大概要折腾一整天而且稍不注意就会撞约束。Codex 的「自动排班」功能在文档里被描述为可以「在后台持续执行即使关闭会话也不会中断」。说实话我对这种「无人值守」的叙事已经免疫了但那天确实没空盯着心想反正晚上让它跑着第二天看结果。任务中断与恢复比想象中靠谱一点第二天早上打开 Codex第一件事是确认任务状态。界面显示「已完成」耗时 6 小时 47 分钟。中间其实发生过一次中断——我查看了执行日志发现大约在凌晨 2 点左右Codex 因为一次网络波动与服务器短暂失联大约 3 分钟后自动重连并从断点继续执行没有从头再来。这种恢复机制的关键在于 Codex 会周期性将执行状态写入本地持久化存储。具体来说它每完成一个子任务比如「处理完一个人的时间约束」就会更新一次 checkpoint而不是等到全部跑完才写盘。这意味着即使遇到更严重的故障损失的工作量能控制在最近一个子任务范围内而不是整个任务泡汤。不过我也注意到一个细节恢复后的执行策略会变得保守。原本 Codex 会尝试并行求解多个可能的排班方案以寻找最优解但中断恢复后它切换成了串行模式优先保证稳定性。这导致后半段的执行时间比预期多了大约 20%。如果你追求的是绝对速度而非可靠性可能需要在任务描述里明确偏好。状态通知别指望它主动喊你Codex 在任务执行期间的通知机制坦白说比较基础。它支持三种方式应用内推送、邮件、以及通过 Webhook 调用外部服务。我这次只开了应用内推送结果因为晚上关了电脑一条都没看到。第二天复盘时觉得对于真正需要「过夜跑」的任务至少应该配置邮件或者企业微信/钉钉的 Webhook。Codex 的通知内容倒是挺实用不是简单的「任务完成」四个字而是包含了当前进度百分比、已处理的约束条件数量、以及最近一次 checkpoint 的时间戳。如果任务失败它会附带错误类型分类比如是约束冲突不可解、还是外部 API 调用超时方便你判断是改需求还是重试。但有个坑通知的频率不能自定义。Codex 默认只在任务开始、完成、失败和恢复时发送通知中间过程除非你主动查询否则不会打扰你。对于那种「我想知道它现在排到第几个人了」的焦虑型用户这个设计可能不够友好。结果验收机器排的班人还得过一遍拿到排班表后我并没有直接用。Codex 的输出是一份 Markdown 表格外加一个 JSON 文件包含了完整的约束满足情况说明。我重点检查了三个地方硬约束是否全部满足。这是底线。Codex 会在输出里标注哪些约束是「强制满足」的哪些是「尽量满足」的。我逐一核对了连续工作天数上限和岗位最低人数要求确认无违规。软约束的妥协是否合理。比如有人 preferred 周末休息但标记为「可协商」Codex 确实安排了周末值班但分布比较均匀没有出现同一个人连续多个周末被点名的不公平情况。边界条件的处理。月底有三天是法定节假日调休我特意看了这部分。Codex 正确识别了调休日的特殊规则但把其中一天的排班密度排得偏低导致那天的在线人数刚好踩线。这个不算错但属于需要人工微调的地方。资源占用笔记本别关机但也不用太担心我这次是在 MacBook ProM3 Pro, 36GB 内存上通过 Codex 桌面端运行的。整个执行过程中Codex 的内存占用稳定在 2.3GB 左右CPU 使用率大部分时间低于 15%偶尔在求解复杂约束时跳到 40% 左右。这个资源消耗对于一台现代开发机来说完全可接受甚至不影响你同时做别的事。但有个前提Codex 的「自动排班」需要本地保持运行状态。它不是纯云端任务而是本地代理持续与云端模型交互的过程。这意味着你的电脑不能休眠合上盖子就会暂停。我后来查了下Codex 的 CLI 版本支持在远程服务器或云主机上运行那种场景下才是真正的「关机也能跑」。桌面端更适合中小规模任务或者你确实有一台不关机的工作站。无人值守的边界与兜底策略这次经历让我对 Codex 的长期任务能力有了更务实的认知。它能用但有几个边界需要提前设好任务粒度要拆细。不要把「帮我排一年的班」丢给它而是「先排下个月验证格式后再续」。Codex 的 checkpoint 机制虽然可靠但任务越庞大恢复时的上下文重建成本越高。约束优先级必须显式声明。我最初只写了「尽量满足大家的时间偏好」结果 Codex 把「尽量」理解成了软约束差点漏掉一个关键岗位的最低人数要求。后来改成「以下约束为强制……其余为优先满足」输出才稳定。预留人工复核的接口。无论 Codex 输出看起来多完美涉及人事安排的场景建议至少过一遍。我这次就在最终确认前发现它把两位有协作矛盾的同事排在了同一天——这个约束我没写进需求但人一眼就能看出来。设置超时和降级方案。Codex 允许设置任务最大执行时间超过后会返回当前最优解而非死等。我设了 8 小时实际 6 个多小时完成留有冗余。如果超时它会附带说明哪些约束是部分满足的方便你决定接受还是调整需求重跑。一点个人感受把排班这种偏行政的事务交给 AI 过夜处理体验上有点像以前写脚本跑批处理——你知道它大概率能成但第二天早上打开结果时还是有一丝忐忑。Codex 的优势在于把「写脚本」这一步也省了用自然语言描述清楚规则就能启动。劣势则是黑盒感还在尤其是当它在凌晨自动切换求解策略时你无从得知它具体做了哪些取舍。我的建议是对于规则明确、输入稳定的重复性任务Codex 的自动排班确实能省出整块时间但对于需要频繁调整规则、或者涉及人际敏感因素的场景把它当作「初稿生成器」而非「终审决策者」会更稳妥。毕竟最后签字确认的还是人。