一個應用程式可以順利上線、運作完美、通過所有測試，然後因為別人改了一個字串而停止運作。

不是你的程式碼。不是你的部署。是 API 呼叫裡的一個模型名稱。端點還在，但背後那個模型已經退役，而 API 很有禮貌地回了一個 404，包在 JSON 信封裡，好像你的請求從一開始就格式錯誤。

這不是罕見的邊緣情況。這是一個模型會按著你無法控制的時間表推出、取代與下架的市場的正常節奏。而它落到一人開發者身上的方式和落到一家公司身上完全不同：公司會收到一封供應商通知，轉到平台團隊變成遷移工單。一個人收到的則是用戶訊息，說這個功能「壞掉了」。

你可以把函式庫收進自家，卻不能把模型收進自家

被依賴關係燒過的人，本能會伸手去拿標準做法：鎖定版本，或自己維護一個分支。

這兩招在開源上有效，在這裡都無效。

函式庫                            模型端點
原始碼公開              是        否
可以自己執行            是        否
可以自己修補            是        否
可以分支出去自己走      是        否
版本可以一直存在        是        否——版本就是一個被服務的端點

你依賴的不是一個套件。你依賴的是一個由別人營運、定價、也可能撤走的服務，而它的版本號不是你能按住不動的。pin 給你的是請求的可重現性，不是他們回應的可得性。

這個區別就是整篇文章的重點。你搭的 harness 確實是你的。裡面的那個大腦是租來的，而租約可以結束。

沒有人編列預算的退場成本

每一個 AI 建置都有兩張帳單。你持續追蹤的是運行帳單——token、請求數、每月那一行。真正會痛的是退場帳單，它只出現一次，而且總是在最糟的時候出現。

退場成本，是指在模型或供應商消失的那一天，為了讓產品活下來你必須做的所有事：

偵測      在使用者告訴你之前知道它壞了
定位      找出每一個呼叫點——不只最明顯的那一個
改寫      讓提示、參數、輸出結構重新適配新模型
重測      證明新模型在「你的」案例上沒有變差
上線      部署，然後處理你沒預測到的品質漂移

這張帳單不隨你用多少 AI 而變，而是隨你在多少地方用了它、以及有多少你根本沒記下來而變。一個只有單一呼叫的玩具腳本，退場成本是五分鐘。一個有六個呼叫點、每個點都有專屬提示、卻沒有任何評估集的已上線應用，退場成本是好幾天——而且它不會事先通知就到期。

陷阱在於：退場成本在到期以前是看不見的。正常運作不會告訴你它會是多少。它是一種更低一層的技術債：你沒辦法靠讀程式碼量出它，只能靠試著離開來量。

真正讓退場變便宜的五件事

依節省時間多寡排序。每一件現在做都很便宜，以後做都很貴。

一、呼叫點只留一個，不留六個。 讓所有模型互動都走同一個內部函式——你自己的薄包裝層。這樣「模型換了」就是改一個地方，而不是做一次搜尋。這是清單上槓桿最大的一項，也是一人建置最常跳過的一項，因為當下多寫第二個稍微不同的呼叫比較容易。

二、把模型名稱寫進設定，不要寫死在程式裡。 模型識別字散落在各個檔案裡就是部署隱患：你找不到的東西，就改不動。一個設定值，讀一次。

三、留一組十個真實案例的評估集。 不是跑分基準，而是十個來自你真實使用者的輸入，加上你當初認可的輸出。這是把「新模型有沒有變差」從感覺變成差異比對的關鍵。沒有它，每一次遷移都是信仰之躍，而對那一躍的恐懼，正是人們把自己釘在一個已死端點上的原因。

四、把提示當產品程式碼看待。 版本控管它、審查它、放在它所屬的呼叫旁邊。只存在於供應商後台裡的提示不是你的，也無法遷移。

五、留意下架，不要假設它會永遠在。 一個每月檢查一次的模型清單端點或變更日誌，是一年三十分鐘的保費。失敗模式不是「供應商消失了」，而是「供應商下架了其中一個模型，而你從使用者那裡才知道」。

不太舒服的結論

以上沒有一項是「不要用 API 建置」的理由。另一條路——自己訓練與部署模型——對大多數任務而言，一個人做不到，假裝做得到只是另一種虛張聲勢。

重點更窄、也更有用：模型變成大宗商品，並不代表你對它的依賴就變便宜。 大宗定價與退場成本是兩個獨立的變數。供應商可以把價格砍九成，同時讓你的產品所依賴的那個端點退役。你優化的那張帳單，和終結你產品的那張帳單，是兩張不同的帳單。

所以在建置時就把退場成本算進去，趁它還只值一個下午。這是這一整套技術堆疊裡你真正能去風險的一塊，因為這個失敗並不罕見——它是排定好的，而且不論你有沒有準備，它都會到。

這個問題還有一個更難的版本，而它不會用 404 通知你。當你租的那一層不是模型，而是關於「什麼值得你注意」的判斷時，失敗會以沉默的形式降臨：當 AI 替你做決定，什麼才真的需要你注意。