你的 AI 剛剛大量製造了技術債。
AI 本應讓你的程式碼庫變得更好，但它卻讓情況更糟。
自從版本控制發明以來，團隊首次出現交付速度更快、但問題也更多的現象。
AI 為工程團隊帶來三件事：更快地撰寫程式碼、更早地發現缺陷、以及完成當前團隊無法獨力建構的東西。
整個產業把賭注全押在第一項——速度，更多的程式碼，更快地產出。
但沒有人問過：當一個團隊原本就已經不瞭解自己半數以上的程式碼庫，然後產出量又暴增 3 倍時，會發生什麼事？
來源： https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
這種情況，我以前就看過了。我們都看過。
在 1990 年代末期，企業級 Java 承諾了「一次編寫，到處執行」。公司將整個產品線押注在它上面。J2EE、EJB、中介軟體堆疊。
到了 2005 年，在一般的企業級 Java 應用程式中，要改變一個按鈕的顏色，需要修改橫跨 6 個套件的 14 個檔案。Martin Fowler 稱之為「企業病」。公司無法交付，也找不到任何瞭解這個系統的人來聘用。他們無法重寫，因為他們無法記錄舊系統的運作方式。
這個問題花了十年才解決：輕量級框架、TDD、CI、Agile。整個產業必須圍繞著技術重建管理層。
而 AI 正在以更壓縮的時間線，重演同樣的事情。
我們讓每個開發者每天都能產出數千行程式碼。但撰寫提示詞的開發者，無法解釋 AI 建構了什麼；核准程式碼審查的人，沒有讀過它；而接手維護的下一個開發者，會把它當成黑盒子來處理——因為它實際上就是個黑盒子。
我在既有的老舊程式碼庫以及全新的示範專案中都觀察到這種情況，它們以同樣的方式崩壞。
以下是我們在實際接案中看到 5 種失敗模式。
AI 在真實程式碼庫中的 5 種失敗模式
1. AI 生成的程式碼量，成了新的「用人力淹沒問題」。
每位 CTO 都買了 Cursor 的授權。每個董事會都在問 ROI。這個炒作週期在不到一年內就走完了全程。
但更多的程式碼從來就不是問題所在。
70% 的財星 500 大公司仍在運行超過二十年的軟體。那些程式碼庫之所以慢，不是因為開發者打字太慢，而是因為公司裡已經沒有人能完全理解所有編碼在程式碼中的商業規則。
讓一個 AI Agent 存取那個程式碼庫。它會產出能通過測試、卻違反了沒人記錄下來的合約規範的「可用」程式碼。
DORA 的 2026 年報告指出：AI 工具在乾淨的全新專案上能帶來 35-40% 的效能提升。但在老舊程式碼庫上，同樣的工具，效能提升只有 10% 或更少。這是一個 4 倍的差距。
瓶頸一直是理解能力。而 AI 讓它變得更糟。
2. 理解債，是新的技術債。
GitClear 分析了 6.23 億次程式碼變更。自 2023 年以來，重構老舊程式碼的工作量下降了 74%。AI 工具傾向於生成新程式碼，而不是重複使用現有的程式碼。一個通過的測試，一個關閉的工單。沒有與現有系統進行整合。
Google 的 Addy Osmani 將它命名為「理解債」：也就是現有程式碼量，與任何人類能理解的程式碼量之間的差距。
在一個 6 個月大的程式碼庫上，你還能補救。但在一個有 10 年歷史、充滿未記錄的整合與商業邏輯，且邏輯散落在數百個檔案中的單體式應用程式上，你做不到。
技術債，是你知道它很爛的程式碼。理解債，是你根本無法評估的程式碼。AI 是第一種能夠大規模產生第二種程式碼的技術。
3. 審查表演，是新的橡皮圖章。
在 Faros AI 的 22,000 名開發者資料集中，未經任何審查就合併的 PR 數量增加了 31%。中位數審查時間增加了 5 倍，因為審查者無法跟上程式碼的產出量。
更多的產出，更少的品質控管，沒有人有權力讓這件事慢下來。在 AI 出現之前，我們已經看過這種組織模式一百次了。現在它以機器速度在運行。
Anthropic 發現，使用 AI 進行被動委派的開發者，在理解力測試中得分低於 40%。而主動提問的開發者得分則高於 65%。同樣的工具，變數在於人。
大多數團隊正在使用 AI 來避免思考。這會在正式環境中反噬你。
4. 最瞭解系統的人，最沒有動力把它餵給 AI。
我與一家私募股權支持的軟體公司工程主管交談過，該公司年營收約 1500 萬美元。他的團隊在內部嘗試了 Claude。他的原話是：「它做了一堆蠢事。」
他的懷疑是對的。
福特汽車讓經驗豐富的工程師在他們的知識能被用來訓練品質系統之前就離職了。三年後，他們付出了數十億美元的保固成本，然後重新聘請了 350 名資深工程師。這些工程師重新訓練了 AI，重建了品質流程。福特現在 16 年來首次在 JD Power 2026 年新車品質調查中名列前茅。
他們的硬體工程副總裁說：他們原本以為，輸入設計需求就能產出高品質的產品。但並沒有。領域專業知識必須優先。
那些掌握機構知識的人，已經看過上一輪的「效率」計畫。他們知道在流程被記錄下來之後會發生什麼事。中世紀的行會對他們的技術保密，也是基於同樣的理由。
5. 最需要 AI 的程式碼庫，正是 AI 表現最差的地方。
中型 SaaS 平台、醫療保健系統、物流後端、以及由多年前就離職的開發者所建立的金融服務產品。
這些公司有付費客戶、真實的營收、以及值得保存的商業邏輯。它們擁有最大的表面積讓 AI 來加速。
現在銷售的每個 AI 編碼工具，都假設程式碼庫是乾淨的、架構是模組化的、並且開發者能提供給 Agent 足夠的上下文。這個假設，在一個有 10 年歷史、充滿未記錄的整合與沒人記得是誰寫的商業規則的單體式應用程式內部，就會破滅。
根據 Gartner 的數據，74% 的 AI 計畫無法在試點階段後擴大規模。模型本身運作正常。是程式碼庫還沒準備好。
真正能解決這個問題的方法
我們在一個真實的接案中證明了這一點。兩位工程師在一個老舊的物流平台上工作。6 個月內合併了 330 個 PR。大約 90% 是 AI 生成的程式碼。客戶稱他們為表現最好的團隊。他們拿到了兩次酌情獎金。
這個結果來自於準備工作，而不是更好的模型。在 AI 碰觸任何一行程式碼之前，有三件事必須先做。
先文件化，再下提示詞。 我們稱之為「第零步」。在任何 AI Agent 接觸老舊程式碼庫之前，你必須掃描現有程式碼，產出 AI 可讀的文件，讓系統對工具來說是易於理解的。Agent 無法對它看不見的東西進行推理。福特的轉變就是從這裡開始的。他們找回那些瞭解系統的人，記錄下他們所知道的東西，然後才重新訓練 AI。
定義區域。 80/20/0。80% 的樣板程式碼（CRUD、測試、設定、文件）：讓 AI 自由生成。20% 的商業邏輯與整合：協作模式，AI 起草，工程師重寫。0% 的驗證、金流、加密、架構決策：不讓 AI 碰觸。這個紀律可以防止理解債不斷累積。
先衡量，再擴大規模。 每次提交的成本、模型使用模式、AI 程式碼佔比、每個團隊的 DORA 指標。在引入 AI 之前建立基準線，之後再進行衡量。沒有這些數據，你就像在黑暗中飛行，最終會撞上 Faros 資料集中那 22,000 名開發者所經歷的相同加速衝擊波。
未來走向
微軟投入了 25 億美元。亞馬遜投入了 10 億美元。Anthropic 籌集了 15 億美元。OpenAI 籌集了 40 億美元。所有這些都針對同一個問題：讓 AI 在現有公司內部真正發揮作用。
市場聚焦於全新專案，因為示範效果看起來比較好。但最大的工程影響力，將來自那些程式碼庫最醜陋、產品最老舊、以及管線在還沒人聽過 LLM 之前就已建置的公司。
瓶頸始終是模型底層的工程系統。
P.S. 這就是我們 @ Limestone Digital 在做的事。 我們將 AI 原生工程團隊嵌入到現有程式碼庫中。第零步、區域紀律、衡量基礎設施。如果你的 AI 試點計畫在老舊程式碼庫上卡住了，歡迎私訊我。
聯絡我們： limestonedigital.com
