理解債

在實踐中

普通的技術債欠在程式碼質量上：程式碼亂、走過的捷徑心裡有數，而且關鍵在於——作者通常還找得到。程式碼再差，背後總有一個能回答「這裡當初為什麼這麼處理」的人腦。AI 生成的程式碼把這個最後的兜底也抽走了：它的「作者」是一個無狀態的模型會話，生成完那一刻就不存在了，當時的判斷、權衡、取捨一點沒留下可追溯的記錄。於是團隊手上是一坨能跑、但誰都無法解釋、也無人可問的實現。本站從 2026 年起用「理解債」來點名這個特定的差別——欠的不是程式碼質量，欠的是「再也沒人能為它負責地解釋」。

這筆債帶利息，所以團隊通常在第七個月而不是第一個月遇到它。第一次改動，是一個並沒有讀懂舊程式碼的 AI「在旁邊加一塊」；第二次改動，它面對的是舊程式碼加上上次那塊沒人理解的新程式碼，於是再加一塊。每一層都疊在一層沒被理解的東西上，理解成本上升得比團隊的直覺快——曲線前期平緩、令人安心，然後在某個再普通不過的需求上陡然變陡。一份已發表的記述裡，一個用兩天搭起報銷系統的零售財務團隊，在第七個月為一次稅率調整排了三週；而 AI 順手改動的一處與抵扣無關的對賬邏輯，是在上線前評審時才被攔下的。

這種狀態不需要什麼特別的工具就能測量，因為它的症狀是行為層面的。下面五條中佔了三條，團隊就已經在積累它了：系統裡有一塊程式碼，隊裡沒人解釋得清它為什麼這麼寫；要改一處，第一反應是「這會不會弄壞別的地方」，而不是直接改；每次要改，都得先把整塊程式碼重新餵給 AI 讓它「再讀一遍」；PR 大到沒人能逐行評審，於是唯一還能查的只剩「測試過了沒」；而「改」的誠實工期估算，已經悄悄超過了「重寫」。

這套機制跟具體哪家廠商的工具無關——它只源於「實現產出的速度超過了組織吸收它的速度」，任何團隊用任何程式碼生成工具都會遇到。所以只有兩個把手：把生成放慢，或者把產物變小。ObjectStack 選第二個：讓 AI 生成帶型別的應用後設資料而不是實現，於是留存下來的是一份第七個月還讀得懂的定義，而所有人依賴的那部分實現是一個被反覆審計的執行時，不是每個應用一坨沒人讀過的新程式碼。