這是這個系列最容易被挑戰的一句話。前面 23 天，我一直拿一個只有 4 條業務規則的新聞發佈系統當案例——標題不可空、不可重複發佈、下架回草稿、已發佈需先下架才能編輯。有經驗的讀者心裡大概都在想：這種玩具規模的系統，當然可以 3 個檔案、249 行就搞定；真的專案有分類、有留言、有權限、有審核流程，複雜度預算這一套還能用嗎？
這是一個公平的質疑，值得認真回答，而不是迴避。今天這篇不打算真的把 ai-news-test 改成一個功能完整的系統再重寫一次——那需要的時間跟前面 23 天完全不成比例——而是用推演的方式，誠實檢驗這套框架在功能變複雜之後，哪裡還撐得住、哪裡開始吃緊。
先看「文章加上分類」。這條需求跟素材裡估算過的「加一個欄位」在本質上很接近：分類是一個附加在文章上的屬性，頂多多一張 categories 表、一個外鍵欄位。用 Outside-In TDD 的角度，先寫一條驗收測試「發佈文章時可以指定分類，列表可以依分類篩選」，這條測試會逼出的東西大概是：Article 多一個屬性、ArticleRepository 的 SQL 多一個 join 或 where 條件、可能新增一個 Category 值物件。
如果套用乾淨版本的邏輯去估算，改動範圍應該落在 4-5 個檔案之譜，跟原本估算的「加欄位」需要 3 個檔案量級接近，不會突然跳到兩位數。這正是複雜度預算這套框架設計時的假設：改動範圍應該跟需求的本質複雜度成正比，而分類這種需求的本質複雜度確實很低。 如果这时候 AI 生成的版本冒出 CategoryAggregate、CategorySpecification、AssignCategoryCommand/Handler/Validator 這種六件套，複雜度預算依然是有效的警報——多出來的不是分類本身的複雜度，是 AI 對「分類」這個簡單屬性套用了跟核心聚合根一樣重的模板。
留言就不一樣了。留言不是文章的附加屬性，它是一個有自己生命週期的子實體：一則留言可以被新增、被留言者本人編輯、被管理員刪除、可能需要審核才能顯示、可能有巢狀回覆。這條需求的本質複雜度，跟「加一個分類欄位」完全不是同一個量級。
如果照抄「改一個欄位只能動 3 個檔案」的預算數字去卡留言功能，會卡出錯誤的警訊——留言合理需要的檔案數,本來就會比加欄位多,因為它是一個新的聚合、有自己的業務規則、有自己的存取控制。這裡要誠實承認複雜度預算這個指標的邊界：它衡量的是「改動幅度跟需求幅度是否成比例」，不是「改動幅度是否小於某個絕對數字」。 用絕對門檻卡不同性質的需求，本身就是一種新的過度簡化。
具體怎麼調整？合理的做法是把預算跟「這條需求牽涉幾個獨立的業務概念」綁在一起，而不是跟「改幾行程式碼」綁在一起——分類只牽涉一個概念（文章的一個屬性），留言至少牽涉兩個（留言本身的生命週期、留言跟文章的關聯）。如果留言功能的實作動到的檔案數，遠超過「這是一個新聲明週期的實體」所需要的範圍——比如同時冒出審核工作流引擎、留言快取多後端切換、巢狀回覆的遞迴查詢優化器——即使需求本質確實比加欄位複雜，複雜度預算依然可以抓出「複雜歸複雜，但這裡明顯又多長了一層不必要的東西」的訊號，只是判斷的基準線要跟著需求性質往上調，不能一刀切。
今天這個推演最重要的產出，不是「分類簡單、留言複雜」這個結論本身，而是一個對複雜度預算框架的誠實補充：這個指標的可靠性，建立在「先分清楚需求的本質複雜度」這個前提上，它本身不會自動幫你分辨一條需求到底該有多複雜。 分辨本質複雜度依然需要人的判斷——這也是為什麼系列後面 Day 25 要接著誠實討論「這套方法論解決不了什麼」。
回到系列主題句：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。 今天的推演證明了一件事：規則要跟得上更複雜的功能，本身也需要隨需求本質調整刻度，而不是一套數字用到所有情境。
如果你的專案裡曾經新增過一個「表面上簡單、實際上牽涉多個業務概念」的功能（例如留言、審核、通知），你們當時的 code review 有沒有意識到「這條需求的本質複雜度比看起來高」，還是直接套用了跟簡單需求一樣的改動幅度期待？
Day 25 會正面回答一個更根本的問題：這套方法論解決不了什麼？規則之外，還有哪些地方非得靠人的判斷力不可。
寫這篇推演的時候，我一直很想偷懶，直接說「規則放大一點就好了」。但誠實面對留言這個例子之後，我發現如果講得太輕巧，等於是在騙讀者這套框架萬用。它不是。它是一個很有用的警報器，但警報的門檻要人先設好，這件事沒辦法外包給任何規則本身。
iThome鐵人賽
看影片追技術