用 Codex 修 bug：給報錯原文、復現步驟和約束，讓它先復現再改，最後重跑復現和測試，附 4 段提示詞

本文根據 Codex 官方文檔《Prompting Codex》和斜槓命令頁整理，資料核對於 2026-11-05。配圖為本站整理的示意圖，不是軟件截圖。本站（bigolab.com）不是 OpenAI 官方網站。安裝與配置見 /guides/codex-getting-started，本文只講怎麼描述 bug。

適用於誰

• 代碼跑出報錯，自己卡住了，想讓 Codex 幫忙定位和修復的人；
• 提示詞總是寫成“這裏有 bug，幫我修一下”，結果越修越亂的人；
• 修好之後不知道怎麼確認的人。

結論先說

1. 官方說，復現步驟和約束比高層描述更重要。 “登入頁有問題”遠不如“點擊登入後，控制檯報 Cannot read properties of undefined，期望跳轉首頁”。
2. 要給四樣東西：復現步驟、懷疑的文件、約束、驗證方式。
3. 讓它先復現再修。 官方示例寫的是：先在本地復現 bug，然後提出補丁並運行檢查。
4. 約束寫明白。 官方示例的約束包括不改 API 的形狀、最小修復、可行時補一條迴歸測試。
5. 修完讓它重跑復現，並運行 lint 和最小相關的測試套件，報告用了什麼命令、結果如何。

圖：本站根據 Codex 官方文檔《Prompting Codex》 整理的示意圖

一、先把線索收集好

動手前，先備齊下面這些，哪怕只有一部分：

• 報錯原文：完整複製，不要截取半句，更不要自己轉述；
• 復現步驟：從哪個頁面或命令開始，做了什麼，看到什麼，期望看到什麼；
• 出現條件：是總是出現，還是特定數據、特定環境才出現；
• 最近改了什麼：如果是某次提交之後才出現的，告訴它大概的時間或提交；
• 懷疑的文件：知道就用 @ 指給它，不知道就寫“我不確定”。

官方在命令行裏的做法是在倉庫根目錄啟動 Codex；在 IDE 裏，則是打開可能出問題的文件和最近的調用方。

二、4 段可以直接複製的提示詞

方括號裏是要你自己填的內容。

1. 標準格式：復現、定位、修復、驗證

有個 bug 需要修復。
現象：[點擊“提交訂單”後頁面白屏]
報錯原文：
[粘貼完整報錯]
復現步驟：[1. 打開 /cart；2. 選擇一個商品；3. 點擊提交]
期望：[跳轉到訂單確認頁]
懷疑的文件：@[文件路徑]
約束：不改接口的返回格式；改動盡量小；可行的話加一條迴歸測試。
請先在本地復現，確認能看到同樣的報錯；再解釋原因，然後提出補丁；最後重新跑一次復現步驟，再運行相關的 lint 和最小範圍的測試，告訴我命令和結果。

2. 只有報錯，不知道從哪查

我在運行 [命令] 時遇到下面的報錯，不知道原因。請先只讀不改：
1. 解釋這個報錯通常是什麼原因；
2. 在代碼裏找出最可能觸發它的位置，說明理由；
3. 列出 2 到 3 種可能的原因，每種怎麼驗證。
先不要改文件。
[粘貼完整報錯]

3. 偶發問題：先加日誌，不亂改

這個問題只是偶爾出現，我沒有穩定的復現步驟。請不要直接改邏輯。
請先幫我在 [相關函數] 附近加幾處臨時日誌，記錄關鍵變量的值，告訴我怎麼運行和觀察。拿到日誌後我再發給你一起分析。
改動完成後列出你加了哪些日誌，方便我之後刪除。

4. 修完後讓它自我覆盤

請總結這次修復：1. 根本原因是什麼；2. 改了哪些文件、各改了什麼；3. 你運行了哪些命令，結果分別是什麼；4. 還有哪些相關的地方可能有同樣的問題；5. 我還應該手動檢查什麼。

如果想讓它再做一遍代碼審查，官方斜槓命令頁寫明 /review 會對未提交的改動或與基礎分支的差異啟動審查模式，詳見 /guides/codex-code-review。

三、修完之後，你怎麼判斷

圖：本站根據 Codex 官方文檔《Prompting Codex》 整理的示意圖

• 用你自己的復現步驟再走一遍，不要只看它的總結；
• 看改動範圍：用 Git 查看改了哪些文件，和 bug 無關的改動要讓它撤銷；
• 看測試：是新增了迴歸測試，還是為了讓測試通過而放寬、刪除了原有測試；
• 上線前：涉及支付、權限、數據刪除的改動，自己逐行審查，並先在測試環境驗證；
• 失敗了就回退：先確認工作區狀態，改壞了用 Git 退回，再用更小的請求重試。

命令被拒絕或需要審批時的處理見 /guides/codex-permissions-sandbox。

四、幾種常見 bug 怎麼描述

下面是本站按開發經驗整理的描述要點，不是官方清單：

• 頁面白屏或點擊沒反應：給瀏覽器控制檯的完整報錯、點擊了哪個按鈕、是否每次都出現。只說“沒反應”，它只能猜；
• 接口返回錯誤：給請求的地址、參數（去掉密鑰）、返回的狀態碼和響應內容，以及你期望的返回；
• 數據不對：給一條具體的輸入和實際輸出、期望輸出，比“數據有問題”有用得多；
• 命令行或腳本報錯：給你運行的完整命令、完整輸出，以及運行環境，比如系統和語言版本；
• 只在線上出現：線上日誌先去掉用戶資訊再給它，並說明本地能否復現；不能復現時，先按第 3 段提示詞加日誌，不要讓它盲改。

描述得越具體，它越不需要猜，越不容易改到不該改的地方。同一個 bug 描述清楚之後，也可以順手讓它檢查有沒有別處存在同樣的寫法，但這類批量修改要分開確認，不要和修復混在一次改動裏。

常見問題

Q：它說修好了，但我的問題還在？

把你的復現步驟和現在的現象告訴它，並要求“先復現，再說明為什麼上一次的修復沒有覆蓋這個情況”。

Q：報錯訊息裏有密鑰、內部地址怎麼辦？

先去掉。貼日誌前的檢查見 /guides/ai-privacy-data-safety-checklist。

Q：需要選更強的模型嗎？

複雜 bug 可以提高推理強度，見 /guides/codex-switch-model-reasoning-effort。Codex 隨 ChatGPT 套餐提供，額度以官方頁面為準，需要更多額度可以看看 /chongzhi/chatgpt-plus 裏的說明。

參考資料

• Codex 官方文檔：Prompting Codex — https://learn.chatgpt.com/docs/prompting
• Codex 官方文檔：Slash commands — https://learn.chatgpt.com/docs/reference/slash-commands