最近有個案子讓我想記一下這個思路。

一個朋友在律師事務所跑 IT，老闆說「預算不是問題，幫我搞一套本地 AI 系統」，然後就開始研究要買哪張卡、哪個模型。我一聽就知道，這個路子走下去大概三年內要後悔。

問題不是預算，是選型順序搞反了。

他的邏輯是：先選定一個模型 → 買硬體 → 建系統。這個順序看起來很合理，但其實在法律場景裡，這是最危險的路。原因是：

1. 模型能力在快速進化。今年覺得 70B 夠用，明年可能發現完全不夠，但硬體折舊沒辦法退。
2. 法律場景的核心不是模型選誰，是資料治理。哪些文件可以進系統？誰可以查？操作日誌怎麼保存？這些問題不設計好，模型再強也沒用。
3. 本地部署 ≠ 安全。很多人以為「本地」就等於「安全合規」，但如果 access control 沒做好，反而比用 SaaS 更難稽核。

我給他的建議是：先做 POC，用前沿模型（API 方式）驗證流程，等你搞清楚你的 workflow 長什麼樣子、哪些步驟真的能被自動化、哪些地方需要人工介入，再決定要不要本地化。

整個架構設計要讓模型可以被替換掉。OpenClaw 的 skill 系統其實很適合做這件事——把 LLM 呼叫抽象成一層，底層換模型只要改 provider config，不用動 skill 邏輯。

# 在 skill 裡用 model 參數而不是寫死模型名稱
actions:
  - call_llm:
      model: "${env.REVIEW_MODEL}"  # 可以是 API 或本地端點
      prompt: "..."

這樣你做 POC 的時候用 Claude 或 GPT-4，等之後要換本地模型，workflow 完全不用改。

關於本地硬體，我有個 caveat：200 萬台幣買本地 GPU 跑大模型，這筆帳要仔細算。同樣的錢，跑三年的 API 費用加上工程師時間去做真正有價值的整合，通常報酬率更高。本地部署的優勢是資料不出境、長期邊際成本低——但這兩個好處，只有在流量夠大、資料管制夠嚴格的場景才明顯。一個 20 人以下的律師事務所，不一定到了那個量級。

總結我的做法：

• Phase 1：用 API + OpenClaw 搭出 workflow，驗證哪些任務真的能自動化（預算可以放在工程時間，不在硬體）
• Phase 2：跑 3-6 個月，收集使用量和模型呼叫次數，算出邊際成本
• Phase 3：如果數字到了，再評估本地化。這時候你知道需要什麼規格，也知道 workflow 穩不穩

先把流程搞對，再決定基礎設施。順序不能反。