Codex 大型任務中斷後，別只說「繼續」：一個非常實用的續接提示詞

| Application program | 2 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/1372

最近在讓 Codex 執行大型任務時，我遇到了一個很現實的問題：

任務明明還遠遠沒有完成，但 Codex 的使用額度已經快耗盡了。

例如：

  • 目前剩餘額度：1%

  • 預估完成整個任務還需要：20% 以上

這種情況下，一旦額度歸零，目前正在執行的任務就有可能被中斷。

不過，真正麻煩的其實不是「中斷」本身。

因為 Codex 已經寫入 workspace 的修改通常還會保留下來。

真正重要的問題反而是：

額度恢復之後，要怎麼讓 Codex 正確地接著做？

很多人的第一反應可能只是輸入：

繼續。

但對於大型任務而言，這其實不算是特別穩妥的做法。

為什麼一句「繼續」不太夠？

大型任務執行到一半時，workspace 往往已經處於一個很複雜的中間狀態。

例如 Codex 可能已經：

  1. 閱讀需求文件

  2. 修改多個檔案

  3. 完成部分實作

  4. 執行測試

  5. 發現一些問題

  6. 正準備進一步修正

然後任務突然被中斷。

這時候，下一輪 Codex 如果單純依靠上一輪對話中的上下文和記憶繼續工作，就可能發生：

  • 重做已經完成的工作

  • 忽略目前已存在的修改

  • 把正常的中間狀態誤認為異常

  • 覆蓋已經完成且正確的修改

  • 重新產生已存在的內容

  • 不必要地回退尚未 commit 的成果

因此，恢復大型任務時有一個很重要的原則：

磁碟上的實際狀態，比模型對上一輪工作的記憶更可靠。

推薦使用的 Codex 續接提示詞

我現在比較推薦在大型任務中斷之後使用以下提示詞：

繼續上一個未完成任務。

在進行任何新的修改之前，先檢查目前 workspace 的實際狀態，包括：

  • git status

  • git diff

  • 已新增／已修改的檔案

  • 上一輪已完成的工作

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

  • 是否存在測試失敗、暫存檔案、未完成實作或其他中間狀態

以目前磁碟上的實際內容為準，不要僅依賴上一輪對話中的記憶。

確認目前進度後，從實際中斷位置繼續完成原任務。

不要：

  • 重做已經完成的工作

  • 回退或覆蓋現有正確修改

  • 因為目前狀態與原先預期不同就擅自重置 workspace

  • 使用 git reset、git checkout --、git restore 等方式丟棄現有修改，除非已確認該修改確實錯誤且需要移除

如果發現上一輪停在不完整狀態，直接在目前成果上修復並繼續。

最後仍然按照原任務的驗收條件完成檢查與測試。

這段提示詞真正有價值的地方

最重要的其實不是：

繼續上一個未完成任務。

真正有價值的是後面的限制條件。

1. 先檢查 workspace

要求 Codex 在修改任何東西之前先查看：

git status
git diff

以及目前新增和修改過的檔案。

這樣 Codex 會先重新建立對目前真實現場的理解，而不是只依賴模型記憶。

2. 明確區分已完成與未完成內容

大型 Agent 任務中斷之後，一個很常見的問題就是重複工作。

因此最好讓 Codex 先確認：

  • 哪些內容已完成

  • 哪些內容尚未完成

  • 哪些內容只做到一半

這樣續接的可靠度會高很多。

3. 明確禁止隨意回退修改

這一點尤其重要。

Codex 有時候看到目前 workspace 與自己的預期不同，可能會認為需要「整理」環境。

例如使用：

git restore
git checkout --
git reset

將 repository 恢復到較乾淨的狀態。

問題在於：

大型任務執行到一半時，那些尚未 commit 的修改，很可能正是上一輪 Codex 已經完成的成果。

所以最好直接告訴它：

不要因為 workspace 與你的預期不同，就擅自丟棄目前的修改。

更進一步：大型任務可以維護 HANDOFF.md

如果一開始就知道這是一個非常大的任務，我認為還有一個更可靠的方法。

可以直接要求 Codex 在專案中維護：

HANDOFF.md

或者：

PROGRESS.md

內容記錄：

  • 任務目標

  • 已完成工作

  • 目前正在處理的內容

  • 尚未完成的內容

  • 重要設計決策

  • 已發現問題

  • 測試結果

  • 下一步應該做什麼

這樣即使發生：

  • Codex 額度耗盡

  • 會話中斷

  • Codex crash

  • 手動停止任務

  • 切換模型

  • 換到新的 Codex 會話

新的 Agent 都可以先閱讀 HANDOFF.md，再查看 git diff，快速還原目前工作狀態。

總結

如果只是非常小的 Codex 任務，一句：

繼續。

通常就夠了。

但如果任務已經執行很久、修改大量檔案，或者涉及複雜分析、實作、測試和驗證，那麼恢復方式最好更加謹慎。

我現在比較推薦這樣的流程：

讀取目前 workspace
↓
檢查 git status / git diff
↓
確認已完成工作
↓
確認未完成與中間狀態
↓
保護目前正確修改
↓
從真正的中斷點繼續
↓
重新執行最終驗證

核心原則其實只有一句：

不要讓 Codex 靠記憶猜自己做到哪裡，而是讓它先看看 workspace 現在到底變成什麼樣。

對大型 Agent 任務來說，這個很小的習慣，往往可以避免大量重複工作，也能降低中斷之後「越接越亂」的風險。

This article was last edited at