Codex 大型任务中断后，别只说“继续”：一个非常有用的续接提示词

| Application program | 1 Reads

Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license. If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1370

最近在让 Codex 执行大型任务时，我遇到了一个很现实的问题：

任务还远远没有完成，但 Codex 的使用额度已经快耗尽了。

比如：

  • 当前剩余额度：1%

  • 预计完成整个任务还需要：20% 以上

这种情况下，一旦额度归零，当前任务很可能会被中断。

真正麻烦的其实不是“中断”本身。

因为 Codex 已经做过的修改通常还保存在 workspace 里。

真正危险的是：

额度恢复之后，应该怎么让 Codex 正确地继续？

很多人的第一反应可能只是输入：

继续。

但对于大型任务来说，这其实并不是一个特别稳妥的做法。

为什么一句“继续”不够？

大型任务执行到一半时，workspace 往往已经处于一个复杂的中间状态。

例如 Codex 可能已经：

  1. 阅读了需求文件

  2. 修改了多个文件

  3. 新增了一部分代码

  4. 执行了测试

  5. 发现了一些问题

  6. 正准备继续修复

然后任务突然被中断。

这时候，下一轮 Codex 如果仅仅依赖上一轮对话中的上下文继续工作，就可能出现几个问题：

  • 重复已经完成的工作

  • 忘记某些已经做过的修改

  • 把当前 workspace 状态误认为异常

  • 覆盖已经完成且正确的修改

  • 重新生成已经存在的内容

  • 在不必要的情况下回退文件

因此，恢复大型任务时，一个非常重要的原则是：

磁盘上的实际状态，比模型对上一轮任务的记忆更可信。

推荐使用的 Codex 续接提示词

我现在更推荐在任务中断后使用下面这段提示词：

继续上一个未完成任务。

在进行任何新的修改之前，先检查目前 workspace 的实际状态，包括：

  • git status

  • git diff

  • 已新增／已修改的文件

  • 上一轮已完成的工作

  • 尚未完成或做到一半的工作

  • 是否存在测试失败、临时文件、未完成实现或中间状态

以目前磁盘上的实际内容为准，不要仅依赖上一轮对话中的记忆。

确认目前进度后，从实际中断位置继续完成原任务。

不要：

  • 重做已经完成的工作

  • 回退或覆盖现有正确修改

  • 因为与原先预期不同就擅自重置 workspace

  • 使用 git reset、git checkout --、git restore 等方式丢弃现有修改，除非确定该修改是本任务产生的错误且确实需要修正

如果发现上一轮停在不完整状态，直接在现有成果上修复并继续。

最后仍然按照原任务的验收条件完成检查与测试。

这段提示词真正有价值的地方

最关键的并不是“继续上一个任务”这句话。

真正有价值的是下面几个约束。

1. 先检查 workspace

让 Codex 在继续修改之前先执行：

git status
git diff

并检查已经新增和修改的文件。

这样它首先建立的是对当前真实现场的认识，而不是单纯依赖模型记忆。

2. 区分“已完成”和“未完成”

恢复大型任务时，非常容易出现重复劳动。

如果强制 Codex 先确认：

  • 什么已经完成

  • 什么还没完成

  • 什么只完成了一半

恢复任务的可靠性会高很多。

3. 明确禁止随意回退

这一点尤其重要。

有时候 Codex 会发现 workspace 和自己原先预期的不一致。

如果没有额外约束，它可能会选择：

git restore
git checkout --
git reset

试图把环境恢复到它认为“干净”的状态。

但对于一个执行了一半的大型任务来说，那些未提交修改很可能正是上一轮 Codex 已经完成的成果。

所以最好明确告诉它：

不要因为当前状态与你的预期不一致，就擅自丢弃已有修改。

更进一步：给大型任务准备 HANDOFF.md

如果一个任务本身就非常大，我现在认为还有一种更稳的方法。

在任务刚开始的时候，就要求 Codex 在项目里维护一个类似：

HANDOFF.md

或者：

PROGRESS.md

的文件。

里面记录：

  • 当前任务目标

  • 已完成内容

  • 当前正在处理的内容

  • 尚未完成内容

  • 关键设计决定

  • 已发现的问题

  • 测试结果

  • 下一步应该做什么

这样即使发生：

  • Codex 使用额度耗尽

  • 会话中断

  • Codex 崩溃

  • 手动停止任务

  • 切换模型

  • 换到新的 Codex 会话

新的 Agent 也可以先阅读 HANDOFF.md，再检查 git diff，快速恢复现场。

总结

对于很小的 Codex 任务，一句：

继续。

通常没什么问题。

但如果任务已经执行了几十分钟，修改了大量文件，或者包含复杂分析、测试和验证流程，那么恢复方式最好更加谨慎。

我现在更推荐这样的恢复逻辑：

读取当前 workspace
↓
检查 git status / git diff
↓
确认已经完成的内容
↓
确认未完成和中间状态
↓
保护现有正确修改
↓
从真实中断点继续
↓
重新执行最终验证

核心原则只有一句：

不要让 Codex 根据记忆猜自己做到哪里了，让它先看看现场到底变成什么样了。

对于大型 Agent 任务来说，这个小习惯可能会省掉大量重复工作，也能显著降低任务中断之后被“越修越乱”的概率。

This article was last edited at