AI 工具的平台綁定風險

我呢排見到好多人話「Claude Office 轉 DeepSeek 好簡單咋，改下 API endpoint 同 model name 就得」。然後佢哋發現某啲 function call 嘅 response format 唔同咗，某啲 system prompt 嘅 behavior 偏差咗，某啲 streaming 嘅 chunk 結構斷咗。仲有啲人直接食 404。呢個現象唔係 bug，而係一個結構性問題嘅縮影：你以為你用緊開放 API，其實你用緊嘅係一個個唔完全相容嘅封閉生態。

相容性嘅幻象

AI 工具呢行有個好有趣嘅現象：絕大部分供應商都用 OpenAI-compatible API 做 default interface。理論上你只要改 base URL 同 model name，成個 stack 就可以搬過去。但現實係，每一次移植你都要面對一籮筐嘅微細偏差——embedding 嘅 dimension 唔同、tokenizer 嘅 behaviour 唔似、streaming 嘅 event format 有出入、甚至簡單如 max_tokens 嘅上限值都唔同。

我試過將一個用咗半年嘅 Claude Office workflow 遷去 DeepSeek，結果係 function calling 嘅 output 結構完全唔同——DeepSeek 嘅 tool call response 用咗另一種 JSON schema，令到我嗰邊嘅 parser 全部爛晒。之後再試 ModelGate 嘅 relay API，雖然表面上做到 OpenAI-compatible，但 latency 嘅波動同 timeout 嘅臨界值又係另一個故事。每次「簡單嘅 migration」最後都變成幾日嘅 integration work。

呢啲唔係陰謀論，而係自然嘅市場結果。每個 vendor 都有自己嘅 optimization 同 interpretation，而呢啲差異累積起嚟就變成咗 switching cost。

API 中轉市場嘅出現

當 switching cost 開始困擾開發者，第三方 relay / proxy 就自然出現咗。ModelGate、GPT55、eth-connect 呢類服務提供 unified API layer，幫你 abstraction 底下嘅各家差異。你 Write once，佢哋幫你 translate 去各個 backend。

表面上呢個係完美解——你一條 API key 就 access 到十幾個 model provider。但呢個 pattern 帶嚟咗一個更深層嘅風險：你唔單止綁住咗一個 vendor，而係綁住咗一個中間層。中間層嘅 business model、pricing、甚至存在本身都係變數。我見過唔少 relay service 突然改 terms、突然加價、甚至突然停運。你嘅成個 toolchain 嘅 resilience 就靠呢個中間人。

另一個問題係 auditing。當你經 relay 去用 Gemini 或 Claude，你點知你嘅 prompt 去咗邊個 model、邊個 region？有啲 relay provider 做咗模型蒸餾——你以為你 call 緊 GPT-4，實際上係一個 fine-tune 咗嘅 Llama 3，output quality 同 latency 完全唔同。呢種「你唔知你俾咗咩錢買咗咩 service」嘅 opacity，對 knowledge worker 嚟講係一個好嚴重嘅問題。

生態系統鎖定

講到呢度，我要講一個更根本嘅嘢：AI 工具嘅平台綁定唔淨止係 API 層面嘅事。你喺某個 platform 上面 build 得愈多，你嘅 workflow、你嘅 prompt engineering pattern、你嘅 evaluation pipeline、你嘅 tool use 習慣——全部都係建基於嗰個 platform 嘅假設之上。

用 Claude 嘅人寫 system prompt 嘅方式同用 GPT 嘅人好唔同。用 Gemini 嘅人對長 context 嘅用法又另一種玩法。你成個 mental model 同 best practice 係同一個 ecosystem 共同演變出嚟嘅。當你要轉平台時，你要重新學習嘅唔係 API call 點寫，而係「點樣先令呢個 model 發揮得最好」。

我見過有人喺某個 platform 上面寫咗 2000 幾個 prompt template，入面充滿咗針對嗰個 model quirks 嘅 workaround。當 platform 一換，成個 library 廢咗一半。

點樣避免被綁死

我唔係叫大家唔好用 AI tools，而係要 conscious 咁管理 lock-in risk。以下係我喺呢個領域跌過幾次之後歸納出嚟嘅實戰建議。

第一，用 abstraction layer 但要明白 abstraction 嘅代價。LangChain、ModelGate 呢類嘢確實有用，但要清楚佢哋本身都係風險點。用 open-source、你可以 self-host 嘅 solution（例如 LiteLLM）會比用 proprietary relay 安全好多。

第二，core workflow 要做 cross-platform validation。你覺得你最叻嗰個 prompt 好犀利？試下將佢搬去另一個 platform，睇下 output quality 跌幾多。呢個 process 強迫你分清楚「乜嘢係 platform-specific 嘅技巧」同「乜嘢係真正嘅 insight」。

第三，maintain 一個 platform-agnostic 嘅 evaluation set。你可以用任何一個 model 去 generate，但你評估 output 質量嘅標準應該係 neutral 嘅、唔 depend on 任何一個 vendor 嘅特性。咁樣當你要轉 platform 時，你係用客觀 metric 去比較，而唔係靠感覺。

最後，要 keep an eye on 開放生態嘅動向。OpenAI 同 Anthropic 嘅 API 係事實 standard，但 Llama、Mistral、DeepSeek、Qwen 呢類 open-weight model 嘅生態正喺度加速追緊。邊間 company 可以將 open model 嘅體驗做到同 closed API 一樣 smooth，嗰間就會贏到 developer 嘅長線信任。

而家呢個 moment，最好嘅策略唔係揀一個 winner，而係保持自己嘅 mobility。做到「隨時可以搬走」，先係真正嘅 freedom。