2026 年 10 月 26 日，掘金上一篇工程長文被社羣反覆轉發。作者描述的場景很日常：讓 Agent 做一個看起來很小的需求，例如「幫取消訂單加上審計日誌」。Agent 改了十幾個檔案，測試也過了。作者打開 diff 看了二十分鐘，最後只確定一件事：它能跑。至於系統結構被改成了什麼樣子，說不上來。
這篇文章把這種狀態命名為「架構漂移」，並指出它才是 AI 編程裡真正的隱性成本。
diff 看得見行，看不見結構
程式碼 diff 回答的問題是「哪幾行變了」。但工程師在審查時真正想問的，往往是另一組問題：有沒有新增模組？有沒有新的跨層依賴？某個實體是不是從訂單模組被挪到了支付模組？這個改動是臨時補丁還是長期結構？
行級 diff 很難回答這些。來源文給了一個很具體的例子：Agent 為了讓取消訂單能寫審計日誌，可能在訂單模組裡直接引用審計模組、把審計實體放進訂單模組、順手把發送審計事件的邏輯塞進訂單服務。每一行單看都合理，測試也可能過。但結構上，訂單模組多了一條對審計的直接依賴，職責邊界也變了。下次有人想在別的模組複用審計能力，才發現它已經和訂單綁死了。
這和 開發者對規格驅動開發的反彈 談到的問題有共通底層：AI 讓「產出程式碼」變快之後，瓶頸移到了人這一端，注意力和理解力跟不上產出速度。
漂移的三種樣貌
來源文把架構漂移整理成三種型態。依賴漂移：本來 orders 只該依賴 domain，為了省事直接依賴了 payment，分層被穿透。邊界漂移：一個工具函式在三個模組各複製一份，本該 internal 的實體被跨模組引用。語義漂移：模組名字沒變、職責變了，orders 開始處理通知，notifications 開始拼訂單查詢。
這三種漂移的共同點是：測試不一定報錯，人工 code review 也未必看得見。
至於為什麼 Agent 會這樣寫，來源文的解釋很樸素：AI 不是故意亂寫，它在局部做最合理的決策，就近使用當前檔案裡已有的東西。問題在於它沒有一個穩定的全域結構參照，每個局部最優加起來，就成了整體漂移。
提示詞管不住這件事。「不要改支付模組」「保持現有架構」這類指示是軟性約束：上下文一長，早期約束會被稀釋；而且 Agent 往往根本不覺得那叫「改架構」，它只是在讓程式碼跑通。提示詞能表達意圖，但無法形成可檢查的結構事實。
一個可行的思路：讓結構變成顯性事實
來源文介紹了一個名為 Jin 的做法，核心概念可以比喻成裝修房子前先畫平面圖。專案維護兩層小型架構描述：L0 記錄系統、模組、分層與依賴約束；L1 記錄每個模組裡的實體、位置與關係。Agent 想改結構時，不能直接動正式架構，而是先提一份提案、編輯目標快照，再由校驗機制比對真實程式碼：模組路徑是否存在、實體位置是否屬實、跨層依賴是否違反約束、有沒有出現未登記的公開符號。校驗通過、使用者批準，才寫入正式架構描述。
用日常話講，這就像家裡請了裝修師傅，不讓他邊敲牆邊決定格局，而是要求先交一張改造後的平面圖。你看不懂每一根管線怎麼接，但你能先看懂「哪面牆被拆了」。
來源文也誠實畫出了邊界：Jin 的漂移檢查是宣告級的，能抓出宣告的符號不存在、實體跑到模組目錄外這類問題，但它不能證明實現符合業務意圖、沒有效能問題、沒有安全漏洞。它是針對「結構變化不可見」這個窄而煩人的問題，不是 code review 的替代品。
所以呢
這篇文章值得記住的訊息有兩層。工具層：AI Agent 產生的 diff 越長，人對結構的掌握越需要另一種媒介，提案、架構快照、依賴圖，而不是更認真地讀 diff。流程層：這與 AI 生成開發省下的時間花到哪裡去 是同一筆帳的兩面，AI 省下寫程式碼的時間，省下的時間遲早要花在理解與審查上，差別只在於你把它花在事前的結構確認，還是事後的除錯現場。
對正在把 Agent 納入日常開發的團隊，比較務實的第一步或許是：在 review 流程裡，把「結構有沒有變」放在「每一行對不對」之前。行級審查可以交給工具和測試，結構審查目前仍只能靠人，而人的注意力，正是這波工具變革裡最稀缺的資源。