有時我們知道問題，卻不知道檔案在哪裡。把檔名直接告訴 Codex，能加快一個任務，卻測不到它是否理解專案。今天只提供 Issue 與重現步驟，觀察它如何搜尋、追蹤資料流，再決定該改哪裡。

這次的 Issue

「任務被標記完成後，切換到『未完成』篩選仍看得到它；重新整理頁面後結果偶爾不同。」這段描述故意不給檔名。可能是畫面上的篩選邏輯、快取狀態、伺服器回應或資料更新順序。若一開始就指定某個元件，反而可能把調查鎖在錯的地方。

可重現步驟要具體：建立一筆任務，確認它出現在未完成清單；標記完成；切換篩選；重新整理；記錄每一步畫面與回應。若問題只是「偶爾」發生，還要寫下環境、操作順序與頻率，避免把無法重現的描述硬當成穩定 Bug。

交給 Codex 的探索任務

「請先不要修改。根據 Issue 找出任務狀態從畫面操作、伺服器處理到資料讀取的路徑。列出你閱讀的關鍵檔案、每一步的證據、至少兩個可能原因與可以區分它們的最小檢查。不要因為某個檔名像 filter 就直接判定根因。」

我會特別看它是否先用搜尋縮小範圍，再打開相關檔案；是否分得清讀取與寫入路徑；是否用現有測試或執行結果排除假設。若它只憑一段程式碼就給出結論，我會要求它補上資料流證據。這篇的評分重點是調查品質，不是最快打出修補程式。

一份好的探索紀錄長什麼樣

我希望看到的不是「我檢查了程式，應該是快取問題」，而是一條可以回放的路徑：哪個畫面事件觸發狀態更新、哪個請求送出完成狀態、伺服器如何寫入、篩選資料又從哪裡讀回。每一步都連到真實檔案、測試或執行觀察。若中間有一段目前無法確認，就標成未知，並提出最小的下一個檢查。

搜尋效率也值得記錄。先找使用者看得到的文字、路由或狀態欄位，通常比把整個 Repository 全讀一遍更可控；但搜尋字串可能漏掉別名或抽象層，因此找到候選後仍要沿呼叫路徑往上、往下追。評價探索能力，不能只數讀了多少檔案，還要看每個檔案是否幫助排除假設。

找到位置之後再動手

探索結束後，才把假設最可能的原因轉成修改任務。修改前先保存重現案例；修改後用同一套步驟驗收，並確認全部、未完成與已完成三種篩選沒有回歸。若問題無法穩定重現，文章會保留診斷過程與未決狀態，不能用一次成功操作宣稱已修好。

今天的結果與限制

今天產出的是一份不透露檔名的 Issue、重現步驟與調查驗收規則。尚未把 Codex 放入實際 Repository，因此沒有可信的根因、閱讀檔案數或修正結果。後續補實測時，會把走錯的搜尋路徑一起保留，因為那比只展示最終答案更能說明能力邊界。

今天學到什麼？

在陌生專案裡，先知道「哪些事還不知道」比先選一個看似合理的檔案更重要。明天把一段簡短 Issue 轉成實作計畫，再比較規劃品質。