AI 的技術債：為什麼它寫得快但難維護
在實務中，AI 產生的程式碼所累積的技術債，大致可以歸納成五種反覆出現的模式。理解這些模式，有助於團隊在 code review 與架構治理時，知道該把注意力放在哪裡。
表面正確卻缺乏整體設計
這是最常見、也最容易被忽略的一種。AI 非常擅長「區域最佳解」：給它一個函式的需求，它能寫出這個函式最合理的實作；給它一個元件的規格，它能生出結構清晰的元件。問題在於，系統不是函式的集合，而是函式之間關係的總和。當每一個局部都是獨立生成的時候，全域的設計就會失去一致性。
具體表現包括：抽象層級混亂（有些地方過度抽象，有些地方完全沒有抽象）、職責邊界模糊（商業邏輯散落在 controller、service、model 之間）、命名慣例不一致（同一個概念在不同檔案叫不同名字）、錯誤處理策略各行其是（有的丟例外、有的回傳 null、有的回傳錯誤物件）。這些問題單看每一個檔案都不嚴重，但整體加起來，就會讓系統變成一座「每個房間都裝潢得不錯，但管線完全沒有規劃」的房子。
更麻煩的是，這種債很難透過重構一次解決。因為它不是某一段程式碼寫錯，而是「沒有整體觀」所導致的結構性問題。要修，往往需要先補一份架構文件，把既有的隱性規則顯性化，然後才有辦法判斷哪些地方該收斂、哪些地方該拆開。
重複與隱性耦合
AI 在生成程式碼時，並不知道你的專案裡「已經有」什麼。它只看得到你當下提供的上下文。因此，同一個功能很可能在三個月內被實作了四次，每次都在不同的檔案裡，每次都有細微的差異。這種重複不是因為工程師偷懶，而是因為生成它的時候，沒有人（也沒有人工智慧）知道前面已經寫過。
重複程式碼本身是古老的問題，但 AI 讓它變得更隱蔽。傳統的重複可以透過複製貼上偵測工具找到，但 AI 生成的重複往往「長得不一樣」：變數名稱不同、結構略有調整、錯誤處理多一行少一行。工具比對不出來，人的眼睛也難以在幾百個檔案中發現。直到某天要改一個規則，改了三個地方，漏了第四個，才發現原來有第四個。
另一種相反的問題是隱性耦合。AI 有時會為了讓程式碼「看起來乾淨」，而把東西抽成共用函式或工具類別，但這些抽象並不是基於真實的共用需求，而是基於「這幾行長得像」。結果就是一個工具函式被五個不相關的模組依賴，任何一個模組的需求變更，都會牽動其他四個。這種耦合在生成當下看不出來，因為它讓程式碼變短了；但它在維護時會變成噩夢，因為沒人知道改動的影響範圍有多大。
依賴幻覺與過時 API
大型語言模型是透過大量歷史資料訓練出來的，這意味著它對程式庫的認識，存在一個「知識截止點」。它可能不知道某個套件在半年前改了 API、某個函式已經被棄用、某個設定選項的預設值變了。更嚴重的是，它有時會「發明」不存在的函式或參數，因為在它的統計模型裡，那樣的命名方式看起來非常合理。
這類問題的危險之處在於「看起來會動」。很多時候程式碼確實可以執行，因為它剛好符合舊版行為，或者因為錯誤被上層的 try-catch 吞掉了。於是它通過了測試、通過了 CI、部署上線，然後在某個邊界情境下產生錯誤的結果。這種錯誤通常不會立刻爆掉，而是靜靜地污染資料，等到被發現時，已經很難回溯。
實務上的防線其實不複雜：鎖定版本、使用型別檢查、在 CI 中執行完整的建置與依賴掃描、對第三方 API 的呼叫加上契約測試。但這些防線需要被「刻意」建立，因為 AI 不會主動幫你建立，它只會生成「當下看起來對」的程式碼。
測試與註解的虛假安全感
AI 非常會寫測試，這是它最受歡迎的能力之一。但「會寫測試」和「寫出有意義的測試」是兩件事。AI 生成的測試常見的問題包括：過度使用 mock，導致測試只驗證了 mock 的行為而不是真實邏輯；斷言太過寬鬆，只檢查「沒有拋出例外」而不檢查結果是否正確；測試名稱與實際驗證的內容不符；只覆蓋了 happy path，邊界條件與錯誤情境完全缺席。
更微妙的是，這些測試會拉高覆蓋率數字，讓團隊產生「我們測得很完整」的錯覺。覆蓋率本來就是一個容易誤導人的指標，而 AI 讓這個指標更容易被操弄。當一個測試只是把程式碼跑過一遍而沒有真正驗證行為時，它的存在反而有害，因為它增加了維護成本，卻沒有提供保護。
註解也有類似的問題。AI 寫的註解通常語句通順、格式工整，但它描述的是「程式碼做了什麼」，而不是「為什麼要這樣做」。前者可以從程式碼本身讀出來，後者才是註解真正的價值所在。當一份程式碼充滿了「# 初始化變數」「// 回傳結果」這種註解時，它看起來很用心，實際上卻沒有提供任何維護者需要的資訊。
無人真正擁有的程式碼
最後一種，也是最根本的一種：責任的真空。人類寫的程式碼，通常有一個「作者」，作者知道當初的取捨是什麼、知道哪裡是權宜之計、知道哪些地方未來要改。AI 生成的程式碼，作者是「團隊中的某個人按下了接受鍵」。這個人可能只看了一眼，可能只看懂了七成，可能在當下覺得「能跑就好」。
於是系統裡開始出現一批「沒有人真正擁有」的程式碼。沒有人知道它的設計意圖，沒有人知道它的邊界條件，沒有人敢說「這塊我很熟」。它在那裡運行，直到出問題，然後一群人圍上去，花比撰寫多十倍的時間去理解它。這就是技術債最純粹的形式：不是程式碼不好，而是「理解它的人不存在」。
三、為什麼 AI 寫的程式特別難維護？
前面談的是現象，這裡要談的是成因。為什麼同樣是程式碼，AI 寫的版本似乎特別難維護？這不是因為 AI 的能力不足，而是因為它與人類工程師在「取得資訊的方式」上有根本性的差異。
缺乏上下文與跨檔案一致性
人類工程師在修改一個函式之前，會先看一下它被誰呼叫、這個模組的慣例是什麼、最近有沒有相關的 commit、團隊在 Slack 上討論過什麼。這些資訊構成了「上下文」，而上下文決定了程式碼該長什麼樣子。AI 助理能取得的上下文，通常只有你貼給它的那幾個檔案，加上它對「一般專案長怎樣」的統計印象。
這導致一個結構性問題：AI 很難維持跨檔案的一致性。它可能在 A 檔案用一種模式處理錯誤，在 B 檔案用另一種；它可能不知道專案已經有一套自訂的驗證框架，於是又引入了一個第三方套件；它可能不知道某個欄位在資料庫裡是可以為 null 的，於是寫了一個假設它一定有值的函式。這些不一致單看每個檔案都不致命，但累積起來，就會讓整個系統變得很難預測。
決策脈絡的消失
軟體開發中最有價值的資訊，往往不在程式碼裡，而在程式碼「周邊」：PR 的討論串、commit message、設計文件、會議紀錄、同事之間的口頭共識。這些東西記錄的是「為什麼這樣做」，而不是「做了什麼」。當未來有人要修改這段程式碼時，這些脈絡能讓他避免重蹈覆轍。
AI 生成的程式碼，恰恰缺少這一層。它的產生過程是一連串的統計選樣，而不是一連串的決策。沒有人問過「為什麼要用這個資料結構」，因為它是被生成的，不是被選擇的。於是當維護者打開這段程式碼時，他看到的是一個結果，而看不到任何理由。他只能從程式碼本身去反推意圖，而反推往往是錯的。
這也是為什麼，很多團隊在導入 AI 之後，會發現 code review 變得比以前更重要，而不是更不重要。因為 review 成了唯一能補上「決策脈絡」的環節。如果 review 只是走個形式、按個 approve，那麼這些脈絡就永遠不會被留下來。
可讀性與可理解性的分野
有一個很容易被混淆的概念：可讀性（readability）和可理解性（comprehensibility）不是同一件事。可讀性指的是「程式碼表面的易讀程度」：命名是否清楚、格式是否一致、函式是否簡短。可理解性指的是「讀者能否在腦中建立正確的心智模型」：這段程式碼在整個系統中扮演什麼角色、它的邊界條件是什麼、修改它會影響到誰。
AI 在可讀性上表現優異，甚至常常超越人類。但在可理解性上，它往往表現不佳。因為可理解性來自於「與系統其他部分的關聯」，而 AI 在生成時，對這些關聯一無所知。它寫出的函式可能很漂亮，但你看不出它在整個流程中的位置；它寫出的類別可能結構清晰，但你看不出它與其他類別的依賴關係。
這造成一個很現實的後果：維護工程師在閱讀 AI 程式碼時，會有一種「每個字都看得懂，但整段不知道在幹嘛」的挫折感。這種挫折感會降低修改的意願，而修改意願降低，正是技術債開始複利的起點。
四、從「生成」到「治理」：降低 AI 技術債的實務做法
談到這裡，結論不是「不要用 AI」，那既不現實也不必要。真正該問的是：如何在享受生成速度的同時，把維護成本控制在可接受的範圍內。這需要把 AI 的使用，從「個人層次的便利工具」提升到「團隊層次的治理流程」。
建立 AI 產出的驗收標準
最基本也最有效的做法，是把 AI 產出當成「外部貢獻者送來的 PR」來對待。這意味著它必須通過與人類程式碼相同的品質門檻：型別檢查要過、lint 要過、單元測試要過、CI 要綠、覆蓋率不能下降、依賴掃描不能有高危漏洞。這些機制本來就有，只是很多團隊在面對 AI 產出時，會不知不覺放寬標準，因為「它看起來沒問題」。
除了既有的門檻，建議額外加上幾條針對 AI 的檢查：第一，要求生成的程式碼必須有對應的測試，而且測試必須能在不 mock 核心邏輯的情況下驗證行為；第二，要求所有新增的第三方依賴都必須經過人工確認，確認版本、確認授權、確認是否與既有依賴衝突；第三，要求複雜度超過某個閾值的函式必須附上「設計說明」，由人類撰寫，說明為什麼這樣拆、邊界條件在哪裡。這三條看起來瑣碎，但能擋掉大部分「看起來能跑」的問題。
把架構決策留在人手上
AI 可以寫實作，但不該決定架構。模組怎麼切、資料模型怎麼設計、服務之間怎麼溝通、錯誤處理的策略是什麼——這些決策需要對整個系統的理解，以及對未來發展的判斷，而這正是 AI 最缺乏的東西。團隊應該明確劃出一條界線：架構決策由人負責，實作細節可以交給 AI。
實務上，可以用架構決策紀錄（ADR）來落實這條界線。每當團隊做了一個影響層面較大的決定，就寫一份簡短的 ADR，記錄背景、選項、決定與後果。這份文件不只是給人看的，也可以在未來把 AI 導入時當作上下文提供給它，讓它的生成結果更貼近團隊的既有慣例。這是一種雙贏：人類得到決策脈絡，AI 得到更準確的上下文。
可觀測性與文件策略
當你無法完全信任程式碼的「正確性」時，最好的策略是讓它在出錯時「容易被發現」。這意味著可觀測性必須優先於功能開發：結構化的日誌、關鍵路徑的 trace、業務指標的監控、異常行為的告警。AI 生成的程式碼往往缺乏這些東西，因為你沒有要求它，而它也不會主動想到。
文件策略也需要調整。傳統文件偏向描述「系統有什麼」，但對 AI 時代而言，更有價值的是描述「系統為什麼這樣設計」以及「哪些地方是權宜之計」。前者幫助維護者建立心智模型，後者幫助維護者判斷哪些地方可以動、哪些地方不能動。建議團隊維護一份「技術債清單」，明確列出已知的權宜之計、預期何時償還、以及不償還的風險。這份清單不需要很正式，但必須持續更新。
團隊層面的規範與文化
最後，也是最難改變的，是文化。AI 工具的導入往往從個人開始：某個工程師發現它很好用，於是開始大量使用，然後慢慢擴散到整個團隊。這個過程通常沒有對應的規範，於是每個人使用 AI 的方式都不一樣，產出的程式碼風格也不一樣。
團隊需要一套輕量但明確的規範，例如：哪些類型的任務適合交給 AI（樣板程式碼、測試生成、文件草稿）、哪些不適合（核心業務邏輯、涉及安全與金錢的流程、架構層級的改動）；AI 產出的程式碼在 commit message 中如何標記；code review 時應該特別注意哪些面向。這些規範不需要很細，但必須讓團隊成員知道「這是一個共同的議題，不是個人的習慣」。
更重要的是，要讓「理解」成為一種被重視的價值。在 AI 時代，寫得快不再是稀缺能力，讀得懂才是。團隊應該鼓勵工程師花時間閱讀自己不熟悉的模組、鼓勵在 review 時問「為什麼」、鼓勵把隱性知識寫下來。這些行為不會立刻提升交付速度，但會決定團隊在半年後還有沒有能力修改自己的系統。
五、衡量與償還：把 AI 技術債納入工程管理
技術債最怕的不是存在，而是「不可見」。當一個團隊不知道自己欠了多少債，就無從規劃償還。因此，要把 AI 技術債納入工程管理，第一步是讓它變得可衡量。
可以從幾個指標著手。第一是「變更前置時間」：從一個需求被提出，到程式碼可以安全地修改，需要多久。如果這個時間在 AI 導入後不減反增，那就表示生成速度被維護成本抵銷了。第二是「重工率」：同一個功能在短時間內被修改多次的比例，這通常反映了初始實作缺乏理解。第三是「熱點分析」：把程式碼的變更頻率與複雜度交叉比對，找出既常改又複雜的檔案，這些地方往往是技術債最集中的區域。
有了數據，償還才有依據。償還的策略大致可以分成三種：重構、隔離、重寫。重構適用於結構還可以、只是某些地方需要收斂的模組；隔離適用於沒人敢動但又必須繼續使用的模組，用適配層把它包起來，限制它的影響範圍；重寫則適用於理解成本已經高於重寫成本的部分。三種策略沒有優劣，關鍵是根據數據做判斷，而不是憑感覺。
還有一個常被忽略的做法：把技術債「預算化」。就像財務管理一樣，每個 sprint 或每個季度，撥出一部分固定的產能專門用來償債。這聽起來很基本，但在實務中，技術債永遠會被功能需求擠到最後。把它變成一個有預算的項目，才能確保它真的被處理。
六、結語：把 AI 當成需要監督的協作者
AI 寫得快，這是事實；AI 寫的東西難維護，這也是事實。但這兩件事並不矛盾，也不代表我們該放棄使用它。真正的問題在於，多數團隊只享受了前半段的好處，卻沒有為後半段的成本做好準備。
打個比方：AI 就像一位產出極快、知識廣博、但完全不了解你公司內部規則的約聘工程師。你不會讓這樣的工程師第一天就獨自負責核心系統，你會給他規範、給他範例、給他 review、給他清楚的邊界。對 AI 也應該如此。它不是取代工程師的工具，而是需要工程師監督的協作者。
技術債從來不是要完全避免的東西，它是權衡的結果。AI 讓我們可以用更低的成本做更多的權衡，但也讓我們更容易忘記自己在權衡。當生成變得毫不費力，判斷「該不該生成」「生成後該不該留」「留下來之後誰來理解」就變得更加重要。
最終，決定一個團隊能否在 AI 時代維持可維護性的，不是它用了多先進的模型，而是它是否還願意花時間去理解自己寫下的每一行程式碼。速度可以買到，理解買不到。而那些願意在速度之外，持續投資理解力的團隊，才會是這場生產力革命中真正的贏家。