鐵人檔案
AI 讓過度設計的產生速度追上了按 Enter 的速度，人眼逐行 review 已經追不上。這系列用一組相同的驗收測試，對照乾淨版本與過度設計版本，示範「測試通過」不等於「設計正確」，並探討 Review 在 AI 時代該審的不再是程式碼本身，而是產生程式碼的規則（測試紀律、架構契約、複雜度預算）。
前言：「複雜度預算不就是事後補救嗎？」 昨天講完複雜度預算，可能有讀者已經在心裡吐槽：這套機制還是「等 AI 寫完，我再去檢查改了幾個檔案」，本質上還是事後補救...
前言：「道理我都懂，但每次都要重講一遍很累」 昨天講完怎麼引導 AI 先跑一次 Outside-In 流程，很實際的問題馬上浮現：如果每一次開新對話、每一個新功...
前言：「所以到底 Code Review 該由誰做？」 這是第三部的最後一篇，也是這系列問到現在最直接的一個問題：如果程式碼是 AI 產生的、規則是架構測試在驗...
前言：「你的案例太簡單了，複雜系統不適用吧？」 這是這個系列最容易被挑戰的一句話。前面 23 天，我一直拿一個只有 4 條業務規則的新聞發佈系統當案例——標題不...
前言：「照著規則做，就不會過度設計了吧？」 如果前面 24 天讓你覺得「只要把複雜度預算、架構測試這些機制都建好，過度設計問題就解決了」，今天這篇要來澆一盆冷水...
前言：我曾經也覺得「多寫一點防禦性程式碼比較安全」 這篇不打算再講案例數字，想單純誠實地講一段自己的心路歷程。因為如果不誠實面對自己曾經站在哪一邊，這整個系列講...
前言：「你們現在也有一堆沒人敢刪的 lint 規則吧？」 這是一句很難反駁的質疑,也是這個系列該正面回答的問題。前面用了好幾天篇幅講「把期待寫成可執行規則」——...
前言：「這是 AI 帶來的新問題」——真的嗎？ 這句話在這個系列裡已經反覆出現過，今天想把它講得更完整。Day 4 講過「過度設計不是 AI 帶來的新病」，引用...
