為什麼第一版從來都不是問題：AI 程式開發與長期維護
AI 程式開發工具擅長生成第一版。真正的工程挑戰從第四版開始——當團隊需要在不破壞其他一切的情況下修改某些東西。
每個 AI 程式開發的展示都遵循相同的弧線。有人對模型下達提示。一個能運作的應用程式就這樣出現了。觀眾印象深刻。 他們確實該如此。速度是真的。能力是真的。有 AI 參與時，第一版確實交付得更快。 問題是，第一版從來都不是困難的部分。 軟體工程的成本不集中在初始創建。它集中在第四、第五、第六次迭代：…
想法與洞見
探索 AI 優先開發、編碼護欄和可處置架構。
AI 生成程式碼與可替換性原則
衡量 AI 生成程式碼品質的真正標準，不在於第一天是否能運作，而在於第三十天你能否替換它，而不需要 rewrite 其他所有東西。
大多數關於 AI 生成程式碼品質的討論，都聚焦在生成當下的正確性。輸出能編譯嗎？能通過測試嗎？符合規格嗎？ 這些只是基本門檻。它們無法告訴你真正的成本。 真正的衡量標準是可替換性：當需求改變時，你能以多低的成本刪除這個 module 並在相同的 contract 背後重新實作？ 如果答案是「輕而易舉」，AI…
AI Codebase 的確定性防護機制
人工審查不一致。AI 審查更糟。AI 生成 codebase 唯一可擴展的防禦是確定性 enforcement：讓建置失敗的規則，而非被忽略的建議。
對 AI 生成程式碼的標準建議是「仔細審查它」。 這建議正確但在規模化時毫無用處。 開發者在警覺、熟悉領域且沒有時間壓力時，審查 AI 輸出能發現問題。在其他所有情況下——也就是大多數情況——問題會溜過去。 用 AI 審查者抓 AI 生成的問題更不可靠。你在要求一個機率系統驗證另一個機率系統的輸出。失敗模式是相關的。…
你的單元測試過了。你的正式環境程式碼還是壞的。
程式碼覆蓋率指標製造了虛假的安全感。以下是單元測試為何總是漏掉那些讓你睡不著的 bug，以及你該改測什麼。
你有 90% 的程式碼覆蓋率，凌晨兩點還是被 on-call 警報吵醒。 單元測試全過了。CI 也是綠燈。bug 還是進了正式環境。覆蓋率沒有說謊，但也沒有說出真相。它只衡量了哪些行被執行過，沒衡量哪些行為真的被驗證過。…
Rust Runtime Contracts 在 Release Build 中可以零成本，但編譯器不會幫你做到
Rust 會自動剝除 debug assertions，但真正的 design-by-contract 需要的遠不止 debug_assert!。以下說明如何建立零成本的 runtime contracts，讓它們從你的 release binary 中完全消失。
Rust 可以在開發階段強制執行 runtime contracts，並在 release build 中將它們完全抹除。但書在於，這門語言並未將 contracts 視為 first-class concept。你拿到了積木，但得自己動手組裝。 是最顯而易見的起點。它在 debug build 中執行，在…
零個、一個，還是十二個：一個 production function 到底需要多少 assertion
開發者要不是把 assertion 灑滿整份程式碼，就是完全避開它們。這裡有一個決策框架，能幫你區分出有用的 invariant 與會導致 production crash 的觸發條件。
大多數 production codebase 可以分成兩大陣營。A 陣營把 當成裝飾調味料，每隔幾行就撒上一點，直到 function 讀起來像偏執律師寫的法律合約。B 陣營把 assertion 當成只在開發階段用的輔助輪，在 build 時全部拿掉，然後祈禱程式在 production…
你的驗證層比業務邏輯還龐大
手動驗證讓 codebase 膨脹，卻還是漏掉邊界情況。以下說明如何透過宣告式 schema 來 enforce runtime contracts，讓它們不干擾你的開發流程。
每次你的 API 收到請求，你就會驗證它。每次函式收到來自外部系統的參數，你就會檢查它。如果用手動方式處理，單一 endpoint 累積的驗證程式碼可能比業務邏輯還多。 這就是 runtime contracts 的隱藏代價。你需要它們，因為 type system 會說謊：透過 HTTP 傳來的…
TypeScript strictNullChecks 是編譯時守門員，不是執行時防護罩
strict 模式抓得到你寫出來的 null，卻抓不到執行時從 API、DOM 查詢和 JSON.parse 傳進來的 null。型別系統到此為止，接下來就是你的防線。
你在 裡把 設成 ，修掉了每一條紅色波浪線，信心滿滿地發佈到正式環境，以為 和 已經不再是問題。 結果後端回應改了格式、DOM 查詢什麼都沒拿到， 在 TypeScript 認定絕對安全的那行程式碼上拋出了 。到底發生了什麼事？ TypeScript 的 strict null checks…
在 AI 時代，程式碼審查會變成規格審查
當 AI 能從規格產生實作、測試與 contracts，槓桿最高的人類工作就會往上游移動。最需要被仔細審視的東西，其實是規格本身。
如果你已經用 AI 出貨超過幾個星期，你大概很熟悉這種感覺。 你打開一個 PR。程式碼夠乾淨。命名還不錯。測試也有。看起來沒有任何明顯壞掉的地方。但你就是覺得哪裡怪怪的。 也許邊界有點模糊。也許 contract 只是被暗示，卻沒有被明確寫出來。也許 happy path…
AI 安全棧: types、contracts、property tests 與 mutation gates
如果你想讓 AI-generated code 能在正式環境站得住，光靠 code review 不夠。你需要一套從 type constraints 到 mutation testing 與 runtime containment 的分層安全棧。
AI-generated code 最大的危險，不是它總是錯的。 真正危險的是，它經常「看起來已經對得足夠可以 merge」。 這正是風險所在。明顯有問題的 code 往往會被擋住。真正會進正式環境的是那種看起來合理、能過幾個 happy-path tests、卻悄悄削弱關鍵 boundary 的實作。…