鐵人檔案
AI 讓過度設計的產生速度追上了按 Enter 的速度，人眼逐行 review 已經追不上。這系列用一組相同的驗收測試，對照乾淨版本與過度設計版本，示範「測試通過」不等於「設計正確」，並探討 Review 在 AI 時代該審的不再是程式碼本身，而是產生程式碼的規則（測試紀律、架構契約、複雜度預算）。
前言：「反正有 AI，程式碼多寫一點也沒關係吧？」 這句話你大概率聽過，甚至自己講過。邏輯聽起來很合理：以前工程師手動寫程式碼很貴，一行都要斤斤計較；現在 AI...
前言：「我需求講得很清楚啊，AI 亂加東西干我什麼事」 這是很多人第一次看到 AI 生出的過度設計程式碼時的直覺反應：明明只交代了一句話，AI 卻自己加了一堆...
前言：「CI 全綠，還要 review 什麼？」 這句話幾乎是每個團隊都講過的話。測試涵蓋了主要情境、CI 顯示全綠、PR 描述寫得清清楚楚——這時候要求「再花...
前言：「這根本是 AI 才有的新問題吧？」 看完前兩天用 ai-news-test 示範的 21,727 行怪物，很容易得到一個結論：這是 AI 時代才有的新現...
前言：「這系統本來就很複雜啊，業務邏輯本來就多」 每次質疑一份程式碼是不是過度設計，很容易得到這句回應：業務本身就複雜，程式碼複雜是應該的。這句話有時候是對的—...
前言：「感覺寫得太複雜」不是一個可以放進 checklist 的標準 前幾天講了本質複雜度跟意外複雜度的區別，但這種區分方式有一個實務上的問題：它終究要靠「感覺...
前言：「多找幾個人 review 不就好了？」 這是很多團隊面對「AI 產出太快、review 跟不上」這個問題時的第一個直覺解法：加派人手、要求更仔細的 re...
前言：「這種對照案例，是不是特意做出來嚇人的？」 看到「87 倍行數落差」「92% 死碼」這種數字，很自然會懷疑：這是不是刻意做出一個極端案例，用來製造戲劇效果...
前言：「業務邏輯這麼簡單，隨便寫都差不多吧？」 看到「新聞發佈系統」這幾個字，你腦中浮現的畫面可能是：一個 Article 資料表、幾個 CRUD API，隨便...
前言：「多包幾層架構,應該只是比較『穩健』吧？」 Day 9 看完版本 A 的 3 個檔案之後,你可能會想:好,這是刻意做的極簡示範,實務上系統當然會需要多一點...
