Fuck-u-code：你的 AI 流水線遺忘的確定性品質閘門
你有型別檢查、語法檢查和架構規則。但你的確定性堆疊對複雜度、重複和命名災難視而不見。這裡有個零成本的解決方案。
讓我們誠實面對：大多數 AI 程式碼流水線目前的真實面貌是什麼。 你用 Cursor 或 Claude Code 產生程式碼。你執行 ，因為 TypeScript strict mode 能抓出型別不匹配。你執行 ESLint，因為沒人想在拉取請求裡為了分號爭吵。或許你會執行…
想法與洞見
探索 AI 優先開發、編碼護欄和可處置架構。
Rust 的 Property-Based 測試：找出單元測試漏掉的 Bug
範例導向的測試只涵蓋你想得到的輸入。Property-based 測試會產生隨機資料、檢查不變條件，並將失敗縮減到最小的反例。
你寫了一個 函式。你用 和 測試它。通過了。你發布出去。 有個使用者傳入了一個單元素的 slice。你的函式把它遺漏了。他們開了一個 issue。你盯著測試檔案，納悶自己怎麼會漏掉這麼明顯的東西。 你之所以漏掉，是因為範例導向的測試只能抓到你預期中的 bug。測試套件裡的每一個…
為什麼第一版從來都不是問題：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…