让 Codex 连续干几天，靠的不是一条超长 Prompt

过去我让 AI 改代码，任务通常很短：修一个报错、补一个接口、写几条测试。上下文不够就再解释一遍，改坏了就回滚，半小时内总能收尾。

现在不一样了。一次任务可能横跨内容、代码、构建、浏览器、部署和线上验证，中间还会插入新的要求。它会跑过午饭，跨过晚上，第二天继续。此时最危险的错觉，是觉得只要把 Prompt 写得足够长，Codex 就能一直沿着正确方向跑下去。

长 Prompt 只能把起跑线画得更细，不能替任务保存状态，也不能证明终点已经到了。

2026 年 6 月，OpenAI 发布了 27 页的《Codex-maxxing for long-running work》，把 durable threads、steering、memory、thread automations、goals 和人工复核串成一套长任务方法。白皮书里有一句很关键：强目标要给 Codex 一个可以测试的标准，而不只是叫它“执行计划”。这和我最近一次从设计一直跑到联调的工程任务得到的结论基本一致。

本文把真实过程抽象成一场统一授权系统的虚拟工程演练。假设一个产品原本只有网页登录，现在需要同时支持服务端 Web、SPA、本地 CLI、WSL、远程服务器和后台任务，还要统一身份、权限、Token、审计与用量。系统名称、域名、仓库和业务数据全部虚构，保留的只是工程步骤、失败模式、测试方法和 Codex 运行统计。

主案例：统一登录不是加一个按钮

最初的要求听起来很短：做一套统一登录，让网站和命令行都能使用同一个账号。真正展开后，任务至少穿过七层：

任务还在进行中不断增加约束：远程服务器不能依赖本机浏览器；Agent 访问资源 API 要使用受 audience 和 scope 限制的 JWT；用量必须能追溯到用户与客户端；数据库迁移要先完成；多个代码模块要按依赖顺序提交；review 发现阻塞问题后必须回到设计层修正。

这不是“写完 OAuth endpoint”就结束的功能。授权中心签出了 Token，只能证明一条局部路径成立。要宣布完成，还必须证明：老调用没有被误伤，错误配置会尽早失败，CLI 能在真实运行边界中完成授权，资源服务器会拒绝错误 issuer、audience、scope 和过期 Token。

长 Prompt 为什么撑不住

假设开头写一条三千字的指令，把协议、表结构、接口、路径、命令和注意事项全部塞进去。第一轮通常表现很好。问题从第二轮开始：

• 用户追加了新的边界，初始 Prompt 已经过时。
• 某个命令失败，后续步骤必须改变。
• 单元测试通过，但多副