一個月寫出的ERP，膠水代碼漲到28%

那個周日下午，我數了數lib/文件夾里的文件：41個。一個月前，這個目錄還能在一屏MacBook里看完。

13個是第三方服務適配器——Supabase、Gmail、Brevo、Slack、Stripe、Meta CAPI、QStash、Push、PennyLane。每個120到260行，全是誠實的管道工代碼。沒崩潰，都能跑。但曾經一眼能讀完的文件夾，現在得滾動了。

「這就是管道工活」

幾周前，長期合作的IT承包商Gaspard路過辦公室。我給他看早期的lib/，帶著點炫耀。他站著滑了三秒屏幕，頭都沒抬：「C'est de la plomberie, ?a.」——這就是管道工活。

我當時點頭，像聽到一個還沒聽懂的技術點評。六周后我才明白，他用兩個詞精準命名了Sculley和那堆技術債文獻折騰十年的東西。

Sculley等人2015年在NIPS發表的論文《機器學習系統中隱藏的技術債》描述了一種特定債務：對模型真正有用的代碼只是中心一個小盒子，周圍是巨大的管道生態系統——數據攝取、歸一化、服務、監控。他們觀察到的典型比例：5%業務邏輯，95%膠水代碼。

作者沒說膠水代碼本身有罪。他們說的是：當它不被命名，就會以隱藏成本的形式償還——每次重構都像雜技，每次遷移都要跟十個本不該有關的文件談判。

LLM加速了沉積

論文的框架是機器學習，但形態遠不限于此。只要一個系統跟五六個外部服務對話，就會產生膠水。一個垂直ERP接六個第三方集成，結構上注定制造這東西。

風險不在于有膠水——肯定會有——而在于它被算作業務代碼。

我發現自己每次讓Claude Code寫新集成，都會結晶出一個這種規模的適配器文件。因為適配器太容易生成了：簽名清晰，沒有業務不變量要保護，不用寫測試。我的智能體每次都精確執行了我的請求，通過日常沉積，造出了Sculley他們描述的病理系統。

用LLM寫代碼，膠水增殖的速度比手寫更快。它 happily 生產適配器，而你不覺得在欠債。

測量腳本與CI規則

對策是測量。我寫了一個130行的腳本，計算lib/里的膠水/業務比例，然后把CI鉤子設成「非回歸」而非絕對閾值。

為什么非回歸比硬性上限更好？因為28%這個數字本身不是敵人。敵人是它在不被看見的情況下增長。一旦你有歷史曲線，任何異常跳躍都會觸發審查——是必要的新集成，還是該抽象的重復模式？

腳本邏輯很直接：識別適配器文件（第三方API封裝、格式轉換、純管道代碼），與包含業務規則的文件分開計數。CI不阻止提交，但會在比例較上周上升時標紅。

這個模式適合任何與大量外部服務對話的代碼庫。不是阻止膠水產生，而是讓它可見。

數據收束

一個月，41個文件，28%膠水代碼。Gaspard的三秒滾動和那兩個法語詞，比任何 linter 都更早指出了問題的本質。現在腳本在跑，CI在記，至少下次沉積發生時，我會知道。