（沈安）
2026年11月6日，掘金上一篇開發者長文流傳開來，題目問得很直白：那些「每個決定都正確」的專案，最後是怎麼爛掉的。作者從自己接手一個目錄整整齊齊的專案講起，三個月後逢人就吐槽。這篇文章整理其中的核心觀察，並補上它與當下 AI 開發工具的關聯。
目錄乾淨得像樣品屋，卻沒有一個資料夾叫「下單」
作者描述的場景很多工程師不陌生：components 放元件，hooks 放 Hook，services 放請求，utils 放工具，每個檔案都在「它該在的地方」。直到產品經理要求下單流程加一個「企業採購」選項，看似加個欄位，實際動手才發現「下單」這件事的零件散落在六個目錄：表單、狀態、校驗、請求、型別、格式轉換各自住在不同的地方，沒有一個目錄叫「下單」。
結果是上線當晚出事。utils 裡躺著一個兩年前寫的老校驗器，也在管下單，作者根本不知道它存在。新表單允許的欄位，被一個沒人記得的老程式否決了。作者的結論很誠實：漏改不是因為不認真，而是無法確定自己沒漏。
這種困境在 輸入法耗電爭議那類討論裡也常出現：使用者只看到結果（電量異常、企業客戶下不了單），看不到的是系統裡好幾套機制同時在管同一件事。
「架構決策退化」：沒有戲劇性崩潰，只有緩慢爬行
文章引用一個醫療 CRM 團隊的複盤，他們把問題稱為「架構決策退化」（Architecture Decision Degradation, ADD），定義是：透過累積妥協逐漸侵蝕架構品質，沒有戲劇性崩潰，只有緩慢爬行。
這和一般說的「技術債」不同。技術債是主動借的，先上線、回頭還；ADD 是團隊每一個決定在當下都站得住，但十幾個站得住的決定疊在一起，就把架構推向沒人想去的方向。
那個醫療團隊的例子：最初用 Redux-Toolkit 集中狀態、createAsyncThunk 處理非同步、樂觀更新支援拖拽，每一步都正確，程式碼看起來很乾淨。然後需求來了，WebSocket 即時更新、衝突檢測、按醫師篩選，3 個 slice 變成 10 個，一個拖拽操作要觸達 4 個 slice。開發者在 Slack 問的問題變成「我該 dispatch 哪個 action」。第 12 個月，41% 的 bug 與狀態管理有關；第 16 個月才開始討論重寫，那時已經需要三個月重構才能恢復。
沒有人做錯什麼。作者說，這才是最讓人背後發涼的地方。
「搬家」不等於「收斂」
文章還引用一份審計報告裡的說法：一個專案剛完成大規模遷移，舊結構整體搬進新的五層骨架，ESLint 規則和邊界測試都配好了。但報告寫得很直白：遷移只做了搬家，沒做收斂。143 個舊元件原樣搬進新結構，巨型檔案一個沒拆，雙錯誤體系、樣式複製、各自為政的 localStorage 全部帶進新家。
最典型的是一個 5647 行的 SessionWorkspace.vue，同時管著 6 個 store 的裝配、執行時狀態分桶、訊息投影合併、SSE 流編排、輸入佇列、審批、附件、面板拖拽和 ResizeObserver。它跑得起來，只是變成一個沒人敢拆的東西。
還有一個更隱蔽的問題：依賴方向存在真實的反向 import 環，apis 依賴 identity，identity 又反過來依賴 apis，靠在函式體裡延遲呼叫暫時沒爆棧。報告的措辭值得記下來：屬於結構性隱患，而非結構性錯誤。暫時沒爆和沒問題，是兩件完全不同的事。
AI 讓「新建」變便宜，收斂反而更難
文章後半段把話題接到 2026 年的現況。AI 讓元件生成速度上了一個臺階，但要它做一張卡片，它大概率直接生成一個新元件，而不是先問專案裡是不是已經有一個。它的預設目標是先滿足當前頁面，而非維護元件體系的長期秩序。
於是出現一個微妙的反轉：以前傾向複用，是因為自己重寫一套不便宜；現在 AI 幾分鐘就能就地生成一個差不多的版本，複用的動機反而變弱。結果是同一個展示卡片，專案裡能找到四五個版本，基礎元件的 props 越堆越多，最後誰都不敢動。
這和 Meta 遷移 Jetpack Compose 的經驗可以對照著看。Meta 那篇遷移分享的核心教訓是，規則寫得再多，AI 還是會繞過去，重點在讓架構本身承擔約束。換句話說，當生成變便宜，約束就不能只靠文件和自覺，得長在結構裡，讓「另起爐竈」這條路本身就走不通。
一般團隊能帶走什麼
這篇文章的價值在於它把一種模糊的挫敗感命名了。專案爛掉未必有明確的兇手，往往是一串當下都合理的決定疊出來的結果。幾個可以操作的方向：
一是按「業務能力」而不只按「技術層」組織程式碼，讓「下單」相關的東西有地方聚攏，改一個需求時不必掃過六個目錄。
二是把重構的重點從「搬家」放到「收斂」：遷移完成後，先拆巨型檔案、清重複實作、斷掉反向依賴，這些比新骨架本身更花時間，也更有回報。
三是在 AI 參與開發的工作流裡，明確要求它先查現有實作再生成新的，並用 lint 規則或相依邊界把這個要求變成機器會擋下的硬限制。
專案的死亡很少是某一天的爆炸，多數時候它只是安靜地，一天比一天更沒人敢動。能早點認出這個過程的名字，就多一點在它不可逆之前動手的機會。