前幾天讓 Codex 做的事情雖然越來越接近真正的開發流程，從看專案、找問題、修改程式到跑測試都有碰到，但仔細想想，這些任務大多還是可以把範圍縮在幾個檔案裡，只要找到問題發生的位置，後面的修改通常不會擴散得太遠。

可是真正維護一個已經存在一段時間的專案時，常常會碰到另一種很麻煩的工作，例如某個欄位命名要統一、共用方法準備搬位置，或是一個資料結構改掉之後，Controller、Service、Model、前端和測試全部都會被影響，這種事情單看每一個修改都不難，麻煩的是要確定自己沒有漏掉任何地方。

所以 Day 8 我想測的，就是把這種跨檔案修改直接交給 Codex，看它能不能在修改範圍變大的情況下，還記得整個專案之間的關係。

先不要急著讓它改

這次我沒有一開始就下「幫我全部改掉」這種指令，因為修改一旦牽涉到十幾個甚至二十個檔案，如果 Codex 一開始理解錯方向，後面就可能整片一起改錯，到時候我要看的就不是幾行程式，而是一大堆 diff。

我先要求它做的事情只有一個：

先搜尋整個專案，整理這次修改可能影響哪些檔案
說明每個檔案為什麼需要修改
目前先不要動程式

這一步其實滿有意思，因為我可以先看到 Codex 對專案的理解範圍。

假設今天要把原本散落在不同地方的 user_id 命名統一成 userId，表面上很像只是搜尋再取代，但真的往下找之後，可能會碰到 Model 裡的欄位、API 傳輸格式、JavaScript 讀取方式、測試資料，甚至文件裡的範例，如果 Codex 只找到其中幾個地方，就代表它雖然會修改程式，卻還沒有真的掌握這次變更會往哪裡擴散。

Change Plan 比直接修改更重要

等它搜尋完，我再讓它整理一份簡單的 Change Plan，例如：

預計修改：
Models/User.cs
Services/UserService.cs
Controllers/UserController.cs
Scripts/user.js
Tests/UserTests.cs

修改原因：
欄位命名需要保持一致

可能風險：
API JSON 格式改變
前端仍使用舊欄位
測試資料尚未同步

看到這份東西之後，我才比較敢讓它開始動手，因為至少在修改以前，我已經知道它準備碰哪些地方，也能先發現它是不是漏掉某個明顯相關的檔案。

這跟我以前使用一般聊天型 AI 的感覺差很多，以前通常是我自己先找到檔案，再把程式貼給 AI 修改，現在則是讓 Codex 自己找出「這次修改到底有多大」，人還是要確認方向，只是原本很花時間的搜尋工作可以先交出去。

真正麻煩的是漏改

開始修改之後，我第一個看的其實不是程式寫得漂不漂亮，而是它有沒有漏。

因為這種跨檔案 Refactor 最怕的就是九成地方都改好了，只剩下一個舊欄位藏在某個角落，結果專案可以 Build，某個比較少用的功能卻在之後才突然出錯，所以 Codex 修改完成後，我又要求它重新搜尋一次舊名稱。

修改前：搜尋 user_id
修改後：再次搜尋 user_id

如果還有搜尋結果，就要一個一個確認它到底是合理保留，還是真的漏改。

這個步驟很簡單，卻讓整個修改比較像真正的工程流程，因為我不需要相信 Codex 說「已經全部完成」，而是可以用搜尋結果和測試去驗證它。

改完二十個檔案之後才是重點

檔案全部修改完成不代表任務就結束，我還是讓它照前幾天建立的方式跑 Build 和 Test，如果失敗就先看是哪一層出問題，再回頭修正，而不是看到錯誤就開始到處亂改。

這次我也特別去看 Git diff，因為跨檔案修改很容易出現另一個問題：Codex 順手整理了我根本沒有要求它整理的東西。

例如原本只要求改命名，它卻順便重新排版、改註解，甚至把其他 function 一起重構，單看那些修改可能沒有錯，可是全部混在同一個任務裡之後，Review 會變得非常痛苦，也很難判斷之後出問題到底是哪一個變更造成的。

所以我現在反而會希望它「少做一點」，任務是改命名就把命名改完整，其他看起來可以順便優化的地方先留下來，下一次再處理。

我開始在意的是它能不能顧到整個專案

做到 Day 8 之後，我對 Codex 的觀察點已經慢慢變了。

一開始很容易注意它產生的程式碼好不好、語法對不對，但當任務開始跨檔案之後，更重要的是它能不能找到完整的影響範圍、修改前先規劃、修改後重新搜尋，再用 Build、Test 和 diff 把結果確認一次。

這些事情單獨看都不複雜，可是全部串起來之後，才比較接近我平常真的會遇到的開發工作。

今天這次修改最後到底碰了幾個檔案、漏了幾個地方，我都會一起記下來，因為後面我想看的已經不只是「Codex 能不能改」，還包括當任務越來越大之後，我到底需要介入多少次，才能讓它安全地把事情做完。

Day 8 紀錄
任務：跨檔案 Refactor
預計影響檔案：＿＿個
實際修改檔案：＿＿個
修改前是否產生 Change Plan：是 / 否
是否漏改：＿＿
是否出現額外修改：＿＿
Build：Pass / Fail
Test：Pass / Fail
人工介入：＿＿次

今天最大的感覺是，大型修改真正難的地方並不是每一行程式有多複雜，而是改完之後整個專案還能不能保持一致，Codex 如果要真的進到日常開發流程裡，這種能力可能比一次寫出漂亮的 function 更重要。