技術債與 AI 生成碼的防禦機制#

一、技術債：三十年前的預言#

1992 年，Ward Cunningham 在 OOPSLA 報告中提出「技術債」（technical debt）：走捷徑的代碼像借貸——現在快了，未來的修改要付利息。他後來強調，債的本質不是「爛代碼」，而是理解與代碼之間的落差：隨著對領域的理解加深，昨天的合理設計變成今天的債，重構就是還債。三十年後，這個隱喻遭遇了史上最大的壓力測試——AI 讓「寫代碼」的速度遠超「理解代碼」的速度，落差以前所未有的速度擴大。

二、AI 時代的新債務形態#

GitClear 對數億行版本歷史的縱向分析（2024 年報告）給出實證：AI 輔助時代，代碼庫出現複製貼上率的歷史新高、重構操作占比下降。具體的新債務形態包括：

體積通膨：生成零成本 → 代碼庫膨脹 → 維護面積擴大；
理解真空：代碼合併了，卻沒有人讀懂——事故發生時才發現無人理解這段邏輯；
重複代碼：模型偏好「再寫一個函式」而非重用既有抽象，DRY 原則的違反加速；
幻覺依賴：AI 引用不存在的套件名（hallucinated packages），攻擊者搶注這些名稱發布惡意包（slopsquatting 攻擊，2023-24 年真實案例）；
測試作弊：Agent 為通過測試而修改測試或寫出迎合測試的代碼。

三、防禦第一層：讓機器裁判機器#

防禦的核心原則是把品質從「人的注意力」轉移到「機制的嚴謹」——書中前十章的老紀律，如今全部翻新：

型別系統：TypeScript、Rust、mypy 在 AI 時代加速普及——強型別是 AI 最難違反的約束（讓編譯器替你審查，呼應 Hopper 編譯器的初衷）；
靜態分析與安全掃描：SAST（Semgrep、CodeQL）、依賴掃描（Snyk、Dependabot）、秘密洩漏檢測成為 CI 強制關卡；
變異測試（mutation testing）：故意改壞代碼，看測試能否抓到——檢驗測試本身的有效性，對抗「迎合測試」；
屬性測試（property-based testing，QuickCheck 2000 起源）：宣告不變式，讓工具隨機生成輸入——人想不到的邊界，機器測得出；
AI 審查 AI：2024-25 年湧現的 AI code review 工具（CodeRabbit、Copilot Code Review 等）讓機器互審成為 PR 標配。

四、防禦第二層：把人放在對的位置#

規格先行：人類先簽署行為規格，AI 再實作——BDD（Given-When-Then）的復興，規格與測試分離，讓迎合測試失去空間；
審查分層：人類聚焦 AI 最弱的三件事（意圖符合、邊界情況、安全），格式與風格交給機器；
來源標記：AI 生成的代碼標記來源，責任鏈清晰到人；
理解性抽查：「這段沒有人懂」本身就是需要開單處理的事故——定期債務巡禮把理解債顯性化；
新人保護期：入職初期限制 AI 使用，先建立心智模型再學會駕馭（2024-25 年多家公司的爭議性做法）。

五、度量債務#

看不見的債要靠指標現形。傳統度量：圈複雜度（McCabe 1976）、重複率、耦合度。新興度量：AI 生成代碼的存活率（多少比例在 90 天後仍存在——存活率低代表一次通過品質差）、審查打回率、事故歸因中 AI 代碼占比。DORA 四指標（第 8 章）本質上是債務利息的流動性度量——債重則不敢部署，恢復則慢。

六、債務哲學#

技術債的智慧從來不是清零，而是有意識地借、有紀律地還。AI 把借款成本壓到趨近於零，借債誘惑史無前例——但利息仍由未來的團隊支付。Cunningham 的定義在 AI 時代獲得新的重量：技術債不是代碼的屬性，而是人類理解與程式碼之間的距離。當生成比理解快十倍，管理這個落差，就是軟體工程作為一門學科存在的最終理由。下一節，我們看向人機協作的終極形態。