新增功能有明確畫面可以驗收，重構卻更難判斷。程式改得更整齊，不代表真的更容易維護；如果外部行為悄悄改變，再漂亮的結構也不值得。今天選擇任務新增與編輯共用的標題驗證邏輯，測試 Codex 能否在行為不變的前提下減少重複。

先定義什麼不能變

新增、編輯、純空白拒絕、前後空白裁切與錯誤回饋都必須維持 Day 7–12 的驗收結果。API 的輸入輸出格式、畫面文字與資料表結構不在本次調整範圍。重構前先跑相關測試並保存結果，重構後用同一組指令再次驗證，才能比較前後差異。

可改善的訊號包括兩處以上重複驗證、同一規則用不同方式實作、函式同時處理輸入解析、資料寫入與畫面訊息。這些只是候選，不代表看到重複就一定要抽象。若共用函式讓呼叫端更難理解，或需要大幅移動檔案，小量重複可能反而更安全。

交給 Codex 的任務

「請先閱讀新增與編輯任務的實作及測試，指出具體重複、分歧和維護風險。提出最小重構方案，保持外部行為、API、錯誤文字與資料格式不變。先跑基準測試，再修改並重跑同一組測試；回報 diff、前後差異與尚未驗證的部分。」

我會檢查它是否為了追求共用而建立只有一個呼叫者的抽象、是否把簡單流程拆成太多層，以及測試是否真的保護外部行為。若重構後只是檔案數增加、理解路徑變長，就不算改善。

怎麼衡量「更好」

可以觀察重複規則是否集中、函式責任是否更清楚、測試是否更容易針對規則，以及改動範圍是否合理。程式行數只能當參考；少十行但多出難懂的泛型，未必值得。Review 時我會請另一個人或工具從零追一次資料流，看是否更快找到驗證位置。

今天的結果與限制

目前只完成重構目標、不可變條件與評估方式，尚未有真實程式可比較，因此沒有複雜度或行數數據。實作後若新結構沒有明顯改善，我會保留「不採用」的結論，而不是為了文章硬留下修改。

今天學到什麼？

重構的成功標準是未來修改更安全、理解更直接，同時現有行為有證據保持不變。明天把修改放進 Git 流程，讓每一步都能追蹤和回復。