向 AI Reader 問一個具體的行為

「解釋一下這個專案」能換來一份概覽，但很少能告訴你某個分支為什麼執行了、某次改動安不安全。想讓 AI Reader 幫上忙，就問一個具體的行為，並說清楚要它查什麼。

說清發生了什麼、預期是什麼

一個好的開場問題包括三點：你做了什麼，發生了什麼，原本預期是什麼。知道相關的檔案或選區就加上；不知道的話，描述你看到的提示或操作，讓 AI Reader 先找到入口。

例如：

環境變數是 REPORT_LIMIT=4，報表輸出了四條，但設定檔案寫的是六條。請從輸入追蹤到輸出，說明哪個來源生效了，以及環境變數為空字串時會怎樣。

這個問題有明確的終點：選中了哪個來源，在哪裡校驗，最後在哪裡使用。它還順帶引出一個小測試。設定追蹤案例展示了一個完整的回答應該講清哪些事。

選擇起始上下文

上下文	適合	仍需自己確認
選區	解釋一個表示式或分支	呼叫方的假設、周圍的條件
檔案	行為分散在好幾個方法裡	import 和外部狀態
資料夾	知道是哪個子系統，但不知道入口	實際參與的是哪些檔案
Git 對比	審查指定提交之間的改動	base 和 head 的方向、歷史上下文

加進去的上下文只是起點。AI Reader 會在你授權的專案裡開啟其他檔案、追蹤依賴，所以請求裡可能不止你加的那個檔案。如果涉及保密程式碼，先看看哪些內容會被髮送。

提問示例

非同步介面問題：

先選 A 再選 B，有時介面上還是 A 的內容。請跨過每個 await 追蹤這兩次請求，列出成功、catch 和 finally 裡的狀態寫入，並說明是什麼阻止了舊請求改動目前介面。

JavaScript 非同步競態教程重現了這個呼叫順序，再用請求序號保護正文、錯誤提示和載入狀態。下載文中的示例，即可執行附帶的測試。

修補程式審查：

審查這次對比中快取失效相關的改動。每個可能的回歸都請給出改動位置、真實可能發生的事件順序、使用者會看到什麼，以及一個能區分新舊行為的測試。原來就有的問題請單獨列出。

架構問題：

這份快取歸哪個元件管，誰能讓它失效，哪些呼叫方共用同一個項目？請引用建立它和修改它的程式碼，並標出取決於執行階段設定的部分。

每個問題都寫明瞭好的回答必須包含什麼：一個事件順序，一個能區分新舊版本的測試，或者建立和修改快取的程式碼。

先核對一個結論，再往下問

在程式碼快速預覽裡開啟關鍵引用，需要的話再看完整檔案。檢查引用裡的條件對你的輸入是否真的成立，以及有沒有別的呼叫方、覆蓋規則或錯誤分支會推翻結論。

回答有缺口時，把問題縮小了再追問：

你找到了兩個實作。這次請求是在哪裡選中其中一個的？如果光看程式碼確定不了，還缺哪個執行階段的值？

AI Reader 不能執行專案裡的測試，所以它給出的測試還沒有跑過。請自己執行，再把結果貼回對話裡。

連續追問與另開話題

下一個問題是在同一條線上繼續深挖，就留在目前對話裡。想換個方向調查，可以在已完成的回答上選擇Fork into New Chat，帶著到這條回答為止的上下文開一個獨立的對話，原來的線索保持不變。

只有在某一輪開啟Allow Edits後，AI Reader 才會修改檔案；之後的執行和分出來的對話都會回到唯讀。Git 對比對話始終唯讀。編輯完成後，看一遍 diff，再執行覆蓋這次改動的檢查。