「資料匯入貼標程式」從讓 Codex 讀懂專案、修正缺陷、執行測試，一路走到權限控管與 Git 交付，最後得到的結論是：Codex 能完成「讀、改、測、回報」的執行迴圈，但前提是我先劃清範圍、驗收條件與外部操作邊界，並用差異與測試重建判斷過程。接下來的案例「日報服務」不再是一個規格相對完整的新專案，而是一套已上線約兩年、歷經多位維護者的既有系統；客戶每天早上八點收到 PDF 報表，程式內部卻累積了耦合、測試不足與文件落差。我打開專案後沒有立刻寫程式，而是先確認它現在如何運作。

第一印象：就問你敢不敢動

排程與報表產製邏輯寫在同一個服務類別裡，讀資料、算數值、排版、寄信全部擠在一條呼叫鏈上，沒有任何一段可以單獨抽出來測試。PDF 是三年前導入的套件，樣式靠字串拼接組出來，想加一個欄位就得在一大串字串運算裡找位置插入。自動化測試的覆蓋範圍也很有限：只有數值計算的部分邏輯被寫進單元測試，排程什麼時候被觸發、信件內容怎麼組裝、檔案怎麼產生出來，這些完全得靠工程師事後盯著正式環境的信箱，用肉眼確認信有沒有寄到。專案說明檔停留在舊版的啟動參數，跟目前實際的部署方式已經對不上。

沒人寫下來的問題，不代表不存在

現況說明裡還藏著兩個沒人正式處理的舊帳。其一，隨著訂閱的客戶越來越多，系統偶爾會撐到接近發送時間才動手產製報表，結果就是有些信箱收到信的時間比預期晚。其二，套件供應商先前發過一則更新公告，內容跟系統目前使用的版本有沒有關係，到現在都還沒有人去查證。這兩件事沒有工單、沒有負責人，純粹是「維運多年下來大家都知道，但沒人排進行事曆」的那種問題。遺留程式碼最危險的地方，往往不是寫得爛的那部分，而是這種沒人正式承認、卻確實存在的空白。

業務端這時候丟來新需求

就在我還在消化現況的時候，業務端提出新一輪需求：報表頻率從每日擴增為日、週、雙週、月，客戶可以自選 PDF、Word、Excel 三種輸出格式，而且製作時間要提前到發送前一小時開始，不能再卡在發送當下才動手。這句話講起來很順口，落到這套耦合的舊系統裡卻不簡單——排程模組要重新設計觸發邏輯，格式輸出要跟糾纏在一起的 PDF 產製邏輯解耦，數值計算範圍在週、雙週、月報表底下也還沒定義。

我沒有立刻動手改程式，也沒有急著把新需求塞進舊架構。接手遺留系統的第一步，是先誠實描述現況與新需求之間的落差，而不是假裝這套系統本來就準備好迎接這些改動。

小結：先承認落差，再談怎麼補

今天沒有動一行程式碼，只把接手這套日報服務的第一印象、既有現況與新需求之間的落差寫清楚：耦合的呼叫鏈、陳舊的 PDF 套件、偏低的測試覆蓋率、兩筆沒人處理的舊帳，加上四種頻率與三種格式的新要求。Day 18 會把這些落差交給 ChatGPT 先規劃，再由 Codex 接手執行，示範怎麼用任務契約把規劃與動手接起來。

參考資料

• 日報服務——需求書（現況＋新增需求）