Anthropic 收購 Stainless 的 platform trap：indie developer 點樣避免 SDK lock-in

2026年5月，Anthropic 收購咗 API SDK 生成平台 Stainless。消息一出，好多用緊 Stainless 嘅 startup 即刻背脊一涼。你以為用第三方工具生成 SDK 係節省時間，但當呢間公司俾人收購咗，政策一轉、定價一改、甚至成個產品 roadmap 被吞併，你嘅 codebase 就突然多咗一個唔受你控制嘅 dependency。呢個就係 platform trap：你以為用緊工具，其實係工具用緊你。

Platform trap 嘅本質：你 build 嘅唔係你嘅

Platform trap 呢個概念喺 developer tool 領域特別常見。你揀咗一個平台嚟 simplify 你嘅 workflow，但隨住時間推移，你對佢嘅依賴愈嚟愈深，直到你發現自己根本走唔到。Stainless 呢類 SDK 生成工具嘅問題在於，佢生成嘅 code 通常直接嵌入你嘅 codebase，但個生成邏輯同 template 係封閉嘅。Anthropic 收購之後，萬一佢哋決定將 Stainless 嘅免費 tier 取消、或者改變生成嘅 API 規格、甚至成個產品整合到 Anthropic 內部而唔再對外開放，你用 Stainless 生成嘅所有 SDK 就會變成孤兒。你呢個時候有兩個選擇：一是繼續俾錢，二是重新人手寫過晒所有 SDK adapter。無論邊個選項，你都輸咗。

獨立開發者嘅情況更差。大公司有多餘嘅 engineering bandwidth 去 absorb 呢種轉變，但 indie developer 團隊可能得兩三個人，一旦核心工具被收購或 pivoted，成個產品嘅開發節奏就會被打斷。你花咗幾個月 build 嘅 integration 可能一夜之間變成 technical debt。更恐怖嘅係，呢種 lock-in 效應係漸進式嘅——你初期覺得「用住先，遲啲再諗抽象層」，但當 codebase 擴大到某個程度，refactor 嘅成本高到你不會想郁佢。呢個就係平台 trap 最陰濕嘅地方：佢唔係一次過綁死你，而係用方便同速度引誘你一步一步走入死胡同。

Abstraction layer：你嘅第一道防線

要避免 SDK lock-in，最直接嘅方法係喺你嘅 code 同第三方 SDK 之間加一層 abstraction。呢層 abstraction 嘅作用好簡單：將你嘅 business logic 同具體嘅 SDK implementation 解耦。當你用 Stainless 或者任何 SDK 生成工具嗰陣，唔好直接將生成出嚟嘅 client 四散喺你嘅 codebase 各處。相反，你應該定義一個自己嘅 interface，然後用 adapter 去 wrap 住個 generated SDK。

舉個例，你寫緊一個 AI agent 平台，用咗 Anthropic 嘅 API。正常做法係喺每個 file import Anthropic 嘅 SDK client，直接 call anthropic.messages.create()。但如果 Anthropic 改咗 SDK 版本、或者你決定要支援埋 OpenAI 同 Google Gemini，呢啲 direct call 就變成災難。正確做法係先定義一個 LLMClient interface，裡面有 generate()、embed()、stream() 呢類屬於你 domain 嘅方法，然後再寫一個 AnthropicAdapter 去實現呢個 interface。將 Anthropic SDK 嘅 idiosyncrasies——例如佢嘅 rate limit 機制、error code mapping、streaming format——全部封裝喺 adapter 裡面。

呢層 abstraction 嘅成本係初始開發時間多咗 10 至 20%，但回報係當 platform trap 爆開嗰陣，你嘅 migration cost 可以降低 90%。對於 indie developer 嚟講，時間就係你唯一嘅稀缺資源，呢個 trade-off 絕對值得。你慳唔係慳 initial development，你慳係慳 future crisis response。

Adapter pattern 嘅實戰設計

Adapter pattern 唔係新嘢，但喺 SDK lock-in 嘅 context 裡面，關鍵係你點樣設計個 interface。太多人將 adapter 變成一個 thin wrapper，機械式咁將每個 method pass-through，咁樣嘅 adapter 冇意義。一個好嘅 adapter 應該 abstract away 嘅係個 SDK 嘅 行為語義，而唔係 API 結構。

Stainless 生成嘅 SDK 可能用咗某種 retry logic、某種 error handling pattern、某種 streaming 機制。你嘅 adapter 應該將呢啲 implementation details 全部封裝，然後 expose 一個乾淨、穩定、屬於你自己 domain 嘅 interface。例如，你嘅 LLMClient 唔應該 throw AnthropicAPIError 或 OpenAIError，而係 throw 你嘅自訂 error type。你嘅 business logic 層永遠唔需要知道底層係用緊邊間 provider。

對於 indie developer，我建議用一個集中嘅 adapters/ 或者 infrastructure/ 目錄去放晒所有 external dependency 嘅 wrapper。每次引入一個新嘅第三方 SDK，第一件事就係喺呢個目錄開一個新 file，寫好 interface 同 adapter，先至開始寫 business logic。呢個習慣初期會覺得煩——尤其係當你趕住 ship MVP 嘅時候——但當你嘅 product 有五六個 external integrations 嗰陣，你就會慶幸當初嘅 discipline。另外，記得為每個 adapter 寫 integration test，用 mock server 去測試 adapter 嘅行為，而唔係 mock 個 SDK 本身。咁樣當 SDK 升級嗰陣，你嘅 test 會直接 catch 到 breaking changes。

結語：控制權係你最大嘅資產

Anthropic 收購 Stainless 只係冰山一角。呢類 platform trap 喺 developer tool 生態圈不斷重複：Heroku 被 Salesforce 收購後嘅邊緣化、AppGyver 被 SAP 收購後嘅停滯、Figma 被 Adobe 收購嘅不確定性。每一次大型 M&A，都有一班 indie developer 被 collateral damage。作為獨立開發者，你嘅最大競爭優勢唔係用最新嘅工具，而係 agility 同 independence。用工具係應該嘅，但要保證任何時候你都有能力走人。

具體行動建議三個。第一，每次引入 SDK 前先定義 interface，唔好為咗快而 skip 呢步。第二，用 adapter pattern 封裝所有 external dependency，將 vendor-specific code 限制喺最小範圍。第三，每季 review 你嘅 dependency tree，主動淘汰高風險嘅 platform dependency，同埋衡量每個工具嘅 switching cost。記住：你 build 嘅嘢，應該永遠係你嘅。唔好為咗一時方便，將自己嘅 product destiny 交俾人哋嘅 M&A department。