前幾天一直在討論怎麼把 Prompt 寫清楚，但就算使用了完整模板，也不代表第一次一定會成功。

其實這個系列已經出現過一次很明顯的失敗。

Day 2 原本想比較 ChatGPT 和 Codex，所以我準備把下面這段 Prompt 交給 Codex：

請閱讀目前 repository 中和 Issue Tracker 有關的文件，分析「新增任務」功能。

請列出：
1. 現有文件已經確定的需求
2. 文件之間是否有不一致
3. 實作前仍需要確認的問題
4. 預計會影響的檔案或模組

目前只做分析，不要修改任何檔案。每項結論都附上檔案路徑作為依據。

這段 Prompt 看起來很完整，有任務、有輸出項目、有範圍限制，也要求提供證據。

但它有一個根本問題：當時根本還沒有建立 Issue Tracker repository。

問題不一定是 AI 沒看懂

我原本預期 Codex 會閱讀專案文件，分析新增任務會影響哪些地方。

實際上，工作區裡只有鐵人賽文章，沒有 Issue Tracker 的程式碼，也沒有可以分析的專案架構。

這時候不論 Prompt 寫得多詳細，Codex 都不可能從不存在的 repository 找到真正的檔案。

它只能：

• 指出目前缺少專案
• 誤把文章規劃當成產品文件
• 猜測可能存在的檔案和模組

其中只有第一種結果符合真實狀態。

所以這次失敗不是 AI 沒有理解指令，而是 Prompt 本身放入了錯誤前提。

先記錄預期和實際狀況

遇到不符合預期的結果時，如果只是重新換一句話，很容易越改越長，最後也不知道是哪個修改真的有用。

我先把問題整理成下面這張表：

這一步的目的，是先分辨問題來自哪裡。

常見原因可能包括：

• 指令不清楚： AI 不知道這一輪要分析、規劃還是實作
• 上下文不足： 缺少需求、檔案、錯誤訊息或環境資訊
• 前提錯誤： Prompt 認為某個檔案、功能或專案已經存在
• 限制衝突： 同時要求 AI 採取互相矛盾的動作
• 無法驗收： 只要求「做好一點」，卻沒有判斷方式
• 能力或權限不足： AI 沒有工具、檔案或操作權限完成工作

第一次修正：拿掉不存在的前提

既然還沒有 Issue Tracker repository，就不能要求 Codex 直接分析它。

修正後的 Prompt 改成：

請檢查目前工作區是否已經存在 Issue Tracker 專案，以及是否有足夠的程式碼可以分析「新增任務」功能。

請列出：
1. 目前實際存在的相關檔案
2. 現在能從檔案確認的資訊
3. 因為缺少專案而無法回答的問題
4. 開始實作前還需要準備什麼

目前只做檢查，不要建立或修改任何檔案。
每項結論都附上檔案路徑作為依據；如果找不到證據，請直接說明，不要猜測檔名或專案架構。

這次沒有要求 Codex 一定要找到專案，而是先檢查專案是否存在。

另外加入了兩個重要限制：

• 找不到證據時要直接說明
• 不要猜測檔名或專案架構

修正後的成功條件也跟著改變。現在正確答案不再是列出一堆可能修改的檔案，而是誠實指出目前沒有足夠資料可以分析。

修正 Prompt，不是把它一直加長

第一次結果不理想時，很容易在原本 Prompt 後面一直補規則：

請仔細一點。
請完整分析。
不要出錯。
請重新確認所有內容。

但這些句子沒有指出真正的問題。

這次有效的修改不是要求 AI 更認真，而是把「專案已存在」改成「先確認專案是否存在」，再說明找不到證據時應該怎麼處理。

一個簡單的 Prompt 迭代流程

這次經驗可以整理成五個步驟：

先定義預期結果
→ 保存原始 Prompt 與實際結果
→ 找出最可能的落差原因
→ 做最小幅度的修改
→ 用相同目標重新檢查

如果修正後仍然沒有改善，再進行下一輪，而不是一次同時改掉目標、背景、格式和模型。

不是所有失敗都要靠 Prompt 解決

這個案例還有另一種處理方式：先建立 Issue Tracker repository，再執行最初的 Prompt。

如果任務本身缺少必要資料，再漂亮的 Prompt 也不會讓資料憑空出現。有時候應該補充上下文，有時候應該調整任務順序，有時候則是目前根本還不能執行。

因此，遇到失敗時不能立刻認定「Prompt 寫得不夠好」，也可能是：

• 任務交得太早
• 需要的檔案還不存在
• 工具沒有權限
• 需求本身尚未決定
• 要求超出目前能驗證的範圍

先找出原因，才能決定要改 Prompt，還是先補上其他條件。

今日小結

Prompt 不是輸入後就保證得到正確答案的咒語，而是一個需要觀察結果、找出落差並持續調整的工作介面。