為什麼這個問題現在會跑出來
你最近可能已經很習慣把 IDE 裡的一段需求丟給 AI：幫我把這個功能改成新的資料格式、順手整理命名、把相關測試也修一下。它看起來真的能動，一次開好幾個檔案，還會自己解釋改了什麼。可是等你拉 diff 一看，常常會發現一件尷尬的事：它改了主檔案，漏了呼叫方；修了型別，漏了測試；畫面跑得起來，但某個舊路徑還在吃舊欄位。先停一下。 這篇要講的核心判斷很短：要 AI 改一個跨多個檔案的功能，怎麼避免它只改一半，關鍵不是一開始就叫它動手，而是先叫它說清楚「這次改動會影響哪些檔案，以及每個檔案為什麼要改」。你要先 review 它的判斷，再 review 它的程式碼。順序很重要。 我最近看一位同事做 refactor，簡單講就是在不改變主要行為的前提下整理程式結構。他原本只想把一個回傳欄位從 userName 改成 displayName，AI 很快改了 4 個檔案，看起來很漂亮；結果實際跑到列表頁才發現，還有 2 個地方用舊欄位做 fallback，測試也只改到其中一個。這就是跨檔案改動最容易漏的地方。不是只有那行程式。 現在的 AI coding 功能看起來比半年前更強，常見編輯器也開始讓 AI 自己讀檔、改檔、跑測試。這讓很多工程師自然會把任務丟得更大：以前只請它改一個 function，現在會請它順手把資料流、型別、元件與測試一起整理。問題也跟著放大。任務變長了。
真正的原因不在表面
真正的原因通常不在「AI 寫不出那段程式」。多數情況下，它其實會寫單一檔案裡的修改，也能模仿既有風格；出問題的是它太快把任務理解成「修眼前這段」，而不是「判斷整個改動會碰到哪些責任範圍」。也就是說，它進入施工太早。這才麻煩。 跨檔案功能改動有一個特性：錯誤不會平均分散，它會集中在接縫處。像資料從 API 進來、經過 mapper、塞進 store、丟給 component、再被 test 驗證，中間任何 1 個地方沒跟上，就會出現一種很討厭的狀態：大部分看起來都改好了，但某個頁面、某個狀態或某個舊資料還是壞。這種壞法很花時間。 很多人會誤判成「那我把需求寫更長就好」。但需求寫長，不等於工作範圍講清楚。你可以把目標描述得很完整，AI 仍然可能只抓到最顯眼的 3 個檔案，因為它沒有被要求先做影響分析。影響分析，簡單講就是先問：這次改動會牽動哪些檔案、哪些呼叫方、哪些測試與哪些資料假設。要先問這題。 還有一個限制很現實：context window，用白話文講就是 AI 一次能看進腦中的文字量。就算工具可以開檔案、搜尋、讀專案，它也不等於真的把整個 codebase，簡單講就是整份專案程式碼，穩穩放在腦中形成完整地圖。它常常是邊看邊猜、邊改邊補。猜得準時很快，猜漏時很隱形。這就是風險。 所以你要檢查的第一件事，不是它的程式碼漂不漂亮，而是它的工作範圍判斷像不像一個真的熟悉專案的人。它有沒有提到入口檔？有沒有提到共用型別？有沒有想到測試與 mock data？有沒有提醒某個相依模組可能受影響？如果這些在動手前都沒出現，後面 diff 再漂亮也要小心。先看地圖。
現在先做什麼
現在先做的事很簡單：不要一開始說「幫我改完」。改成先說：「先列出這個改動會影響的所有檔案，加上每個檔案各自要改什麼；先不要修改，等我確認後再從第一個開始。」這句話的重點不是禮貌，而是把 AI 從寫程式模式拉回判斷模式。先盤點。 你要它列的不是一份漂亮清單，而是一份可以被挑錯的工作範圍。比較有用的格式通常包含 4 件事：檔案路徑、為什麼受影響、預計改什麼、如果不改會壞在哪。這裡可以少量條列，因為你要 review 的是判斷，不是文章。看得懂最重要。 例如你要把某個訂單狀態從字串改成 enum，enum 簡單講就是一組被限制好的固定選項。你不只要看 AI 有沒有改 type 檔，還要看它有沒有找到 formatter、filter、表格欄位、測試資料、錯誤訊息與舊資料轉換。它列出 6 個檔案不代表完整，但它如果只列 1 個檔案，通常就該追問。數量會說話。 確認範圍時，不要急著檢查每一行實作，先檢查它漏掉哪一類位置。你可以問：「有沒有任何呼叫方、測試、mock data、story 或文件也需要同步？」mock data，用白話文講就是測試或開發時拿來假裝真資料的範例資料。很多跨檔案錯誤都藏在這裡。它們很安靜。 等你覺得範圍差不多，再讓 AI 從第一個檔案開始改，而且一次只改一小段關聯性高的檔案。這不是要把速度拖慢，而是讓你每次 review 都知道自己在看什麼：這一段是在改資料結構，下一段才是改 UI，再下一段才是補測試。diff 一有主題，漏改就比較容易被看見。眼睛才跟得上。
常見的陷阱跟誤解
第一個陷阱，是把「AI 有改很多檔案」誤以為「AI 有理解整個改動」。檔案數量看起來很有氣勢，但如果它改的是相鄰檔案，卻沒碰真正的呼叫鏈，那只是大範圍局部修改。別被場面騙了。 第二個陷阱，是讓它一口氣改完 10 個檔案，然後你才開始看。這時候 review 會變成考古：你不知道哪一段是必要修改、哪一段是它順手整理、哪一段是為了修自己剛剛造成的錯。成本會疊上去。 第三個陷阱，是只用測試結果決定要不要收。測試很重要，但跨檔案 refactor 最怕的是未覆蓋路徑、舊資料格式與人眼才看得出來的產品假設。綠燈是訊號，不是結案章。還要看合約。 第四個陷阱，是把「請你也檢查相關檔案」當成範圍規範。這句太模糊，AI 容易用自己的猜法補完。比較穩的是直接要它列出檔案、理由與不改的後果，讓你可以反問它漏了什麼。要可檢查。
下次再遇到時可以怎麼判斷
下次再遇到跨檔案改動，可以先用一個小框架判斷：這次是在改單點實作、改共用合約，還是改資料流。單點實作通常可以直接請 AI 改；共用合約最好先盤點呼叫方；資料流一旦跨過 API、狀態、畫面與測試，就該分段處理。先分類。 這裡沒有單一正解。小改動先盤點可能顯得慢，大改動不盤點又容易在後面花 30 分鐘找漏。比較實際的做法是：只要你心裡出現「應該還有別的地方要改吧」這個念頭，就先叫 AI 把影響檔案攤開，再決定要不要讓它動手。讓判斷先出現。 AI 現在很適合當會寫程式的搭檔，但跨檔案任務要先讓它像工程師一樣說明改動範圍。你不是只要它產生程式碼，你要它先暴露自己的理解。下一次，就從這句開始：先列出會受影響的檔案與各自要改什麼，我確認後再改第一個。這句很管用。
