昨天開了一個新的 Codex 任務，沒有重新貼上技術棧或目錄結構，Codex 仍然可以從 Issue Tracker repository 裡的檔案整理出專案導覽。

這些被 Codex 用來理解任務的資訊，就是上下文。

但 repository 並不是全部。對話中提供的需求、錯誤訊息、截圖與終端機輸出，也會影響 Codex 如何判斷問題，以及它準備採取哪些行動。

Codex 的上下文從哪裡來？

進行本機開發任務時，Codex 可能從幾個地方取得資訊：

• Repository： 原始碼、設定檔、測試、README 與 Git 變更
• 目前對話： 這次任務的目標、限制、補充說明與前面的問答
• 工具結果： 搜尋結果、終端機輸出、測試失敗與 Git diff
• 使用者提供的資料： 截圖、錯誤訊息、重現步驟與參考文件

這些資料不一定會同時出現。Codex 會根據目前能取得的資訊建立判斷，因此同一個問題只要提供不同上下文，就可能得到不同的分析結果。

資訊太少會發生什麼？

假設我只輸入：

畫面壞了，幫我看看。
先不要修改程式。

Codex 可以閱讀 repository，但「壞了」可能代表很多事情：

• 頁面完全打不開
• 文字或元件位置不正確
• 手機版超出畫面
• 點擊後沒有反應
• 瀏覽器出現錯誤

如果沒有實際症狀與重現方式，它只能先檢查程式、詢問問題，或列出可能原因，無法知道使用者真正遇到的是哪一種狀況。

資訊很多也不一定比較好

另一個極端，是把整份 PRD、所有終端機紀錄、完整套件清單、很多張無關截圖，以及自己猜測的原因一次貼進 Prompt。

這些內容可能讓真正重要的線索被埋住，也可能帶入過期或互相矛盾的資訊。

例如這次只想請 Codex 分析一個手機版顯示問題，通常不需要提供未來的搜尋、排序與拖曳需求。和任務無關的內容，不會因為更完整就變得更有幫助。

最小但足夠的上下文

我把開發任務需要的上下文分成三類。

必要

• 想完成或修正什麼
• 實際行為與預期行為
• 可以操作的 repository
• 穩定的重現步驟
• 任務範圍與禁止事項
• 判斷完成的方式

最好有

• 原始錯誤訊息或失敗測試輸出
• 能看出整體位置的截圖
• 已經確認過的相關檔案
• 執行環境與已嘗試的方法

通常不需要

• 與目前問題無關的完整 PRD
• 整個 repository 的檔案內容
• 無關的舊對話與終端機輸出
• 沒有證據支持的原因猜測
• 不影響這次任務的未來需求

這份分類不是固定規則。所謂必要資訊，仍然會隨任務改變。修正 CSS、設計資料模型和處理建置錯誤，需要的上下文並不相同。

不確定要提供什麼時，先問 Codex

如果還不知道某項任務缺少哪些資訊，可以先使用這段 Prompt：

請先列出完成這個任務需要的上下文，分成「必要、最好有、不需要」。

目前只檢查資訊是否足夠，不要分析原因或修改檔案。
必要資訊不足時，請指出具體缺口，不要猜測實作細節。

今日小結

Codex 的成果不只取決於 Prompt 裡的命令，也取決於它當下能取得哪些上下文。

資訊太少會迫使它詢問或猜測，資訊太多則可能模糊真正的任務。比較有效的做法，是提供能重現問題、界定範圍與驗證結果的最小資訊，再讓 Codex 從 repository 和工具結果補足證據。