Codex 长任务怎么接着跑？500k 更新后，这份交接模板值得留

让 Codex 改一个牵涉前后端的 Bug，代码还没改完，聊天里已经塞满了文件、报错和试过的方案。第二天继续，最烦的往往是重新解释那句「这里昨天已经查过了」。

10 月 12 日早上，Tibo 的公开说明给这类长任务带来一个好消息。GPT-6.1 Sol 在 Codex 和 Work 中的默认上下文，从 272k 提到了 500k。他给出的直接理由，是减少上下文压缩，让需要长期保留大量细节的任务更容易继续。

对经常跨文件改需求的人，我更关心多出来的空间怎么花。这篇附一份可以交给 Codex 的任务交接模板，适合改到一半要收工、换会话，或者准备把需求交给同事的时候。

这里没有新旧窗口的效果实测，也不承诺少花多少时间。下面的数字来自官方说明，模板和使用判断是我的整理。

这次扩容，帮的是哪一段工作

上下文可以理解为模型这一轮能同时参考的工作材料。用户的要求、工具返回的内容、此前的讨论，都会占用其中的空间。token 是模型处理文字的单位，500k 不能直接换算成五十万汉字。

假设你在改一个订单导出的 Bug。排查过程先经过页面按钮，再经过接口参数、数据库查询，最后定位到日期范围。每一步都有理由，后面的修改又依赖前面确认过的事实。

这时，保留那段「为什么日期条件不能直接删」的讨论，就很有价值。否则模型虽然看见最新文件，也可能重新建议一个被你否掉的方案。更大的默认窗口，给这些来龙去脉多留了一些位置。

Tibo 的说明只说减少压缩发生，没有给出压缩次数能降多少，更没有公布这次调整对某类 Bug 的修复成功率。把窗口增幅直接写成效率增幅，跨度太大。

扩容首先改变的是能保留多少材料，实际收益要看任务是否依赖这些材料。 如果你只让它改一段文案，几轮就结束，窗口未必是当前瓶颈。跨文件修改、反复排查、需要照顾多个约束的任务，更值得观察变化。

这里还有一个容易混的数字。官方帖说的是客户端默认 500k，并提到可以手动覆盖；API 模型文档列出的总窗口则是 1,050,000 token。这两个数描述的层次不同，不能拿 API 总窗口推断每个客户端默认用了多少。

我也不建议仅凭这条消息，把自己所有配置都调到最大。先用默认值完成一个真实任务，看看中途是否仍要反复解释约束，得到的信息比盯着那个最大数字更有用。

API 的计费另有规则，走 API 的项目仍需看对应模型文档，不能从客户端更新推导账单。

把当前状态留成一份记录

窗口变大之后，一个诱惑是继续往对话里堆材料。完整日志、旧版本文件、几次已经推翻的方案，一股脑都放进去，感觉总比漏掉强。

但接手工作的人看见全部聊天，也未必知道现在该干什么。

昨天说要换方案，今天又决定保留；测试一度通过，后来改了另一个文件；一条报错已经修复，下一条还没有定位。信息都在，却需要重新判断哪一条仍然有效。

这个问题可以先用一份小文件解决。文件名不重要，叫 TASK-HANDOFF.md 就行。它只记录当前任务，不写成整个项目的百科，也不假装是 Codex 会自动识别的特殊文件。继续工作时，明确让它读这份记录。

下面这段可以在一个阶段结束时发给 Codex。路径换成你的实际位置；如果项目已经有类似记录，就更新原文件，避免同时维护两份互相冲突的状态。

请把当前任务的交接记录写到 TASK-HANDOFF.md。

只记录可核验的当前状态，不复述整段聊天。

任务目标：这次要解决什么，什么情况算完成。
当前结论：已确认的原因、尚未确认的假设，分开写。
相关位置：文件路径与关键符号，注明为什么相关。
已做修改：已经改了什么，还有什么未做。
验证结果：实际执行的命令、结果与对应代码状态。
未验证项：没跑的检查、失败的检查、缺失的条件。
下一步：从哪个文件或哪个检查继续，预期看到什么。

不确定的内容写明不确定。
没有运行的测试，不写成通过。
如果现有记录与代码不同，以重新检查的结果更新记录。

这份模板故意把「当前结论」和「验证结果」分开。模型提出一种解释，不等于已经找到原因；修改了代码，也不等于修复已经被验证。

交接记录里如果只剩一句「问题已解决」，下一次仍然得从头找证据。

文件路径也比一大段泛泛的总结好接手。写「导出模块有时区问题」太模糊；写清相关函数、输入条件和还没覆盖的情况，下一次就能直接打开那个位置。

行号可能随着改动漂移，关键符号和原因可以一起留。

还要留意记录的时效。测试是在最后一次改动之前跑的，就写清楚。否则昨天真实的「通过」，到了今天也可能成为误导。交接文件不是写完永久可信的证明，只是一个帮助你快速找到证据的入口。

第二天继续时，让它从记录走回代码

假设还是那个订单导出任务。你昨天确认日期条件有问题，但只改完后端，还没验证前端传参。今天继续时，如果只发「接着做」，模型需要自行猜测接的是哪一个阶段。

可以换成下面这段。它让交接记录提供方向，同时要求回到当前文件确认，避免把过期记录当成事实。这里仍是使用示例，没有实际执行订单项目，也没有虚构修复结果。

继续当前任务。先读 TASK-HANDOFF.md，
再检查它引用的文件与当前改动。

用简短的话告诉我：
当前目标是什么；
哪些结论有代码或运行结果支持；
还有哪一步没完成。

如果记录与当前代码冲突，指出冲突并更新记录。
然后从下一步继续，保留已经确认的约束。
结束时更新验证结果和剩余工作。

比如，记录写着后端已改，当前代码却没有那段修改。合理的下一步是确认分支、工作目录和改动状态，而不是顺着记录假定修复存在。更长的上下文也无法替你消除这种代码与叙述的差异。

再比如，记录写「端到端检查没跑，因为测试账号不可用」。第二天账号仍不可用，就应继续保留未验证状态。不能因为会话换了，最后的交付说明就把这句话消失掉。

同事接手时，这份记录也能直接使用。对方不必先读完你的聊天，更不必知道你用的是哪一档模型。他需要的是目标、相关位置、已验证的结果，以及哪一步还悬着。这也是我愿意把记录留在项目里的原因。

不过，小改动不必做成仪式。改一处拼写、调整一个明显的常量，已经有清楚的 diff 和检查结果，就没必要额外写一页交接说明。它最适合的是工作确实跨了阶段，而下一次恢复需要重新组织信息的任务。

怎么知道扩容对你有没有帮助

找一个你本来就要完成的长任务，保留问题描述和最终结果。观察过程中，你是否仍要重申已经确认的约束，是否出现重复排查，交接记录里的下一步能否直接接上。

这些比单看「上下文还剩多少」更接近使用感受。但一次任务变顺，也不能全归功于 500k。需求写得更清楚、仓库更熟悉、工具返回更简洁，都可能产生影响。想做严格比较，需要同样的任务和起始状态；本文没有做这个实验。

我对这次更新的期待很具体。那些还没结束的推理、刚查清楚的细节，可以在对话里多待一会儿；已经完成的工作，则能在项目里留下一个别人也看得懂的接手点。

你用 Codex 做长任务时，最常重新交代的是目标、改过的文件，还是已经跑过的验证？