週六早晨。手機開始震動。又一次。然後 47 次。你瞇著眼看螢幕——凌晨 3 點以來累積了 $12,000 的 LLM API 帳單。你團隊裡的某個人，在週五晚上 11 點把一把 API key 推進了公開的 GitHub repo。等 AWS 標出異常時，那把 key 已經在三個 region 跑著挖礦推論。你不是第一個出這種事的開發者。你甚至不是第一百個。
2025–2026 年間，LLM API 錯誤讓工程團隊燒掉了超過 $500M。一個沒有 failover 的團隊，在 OpenAI 故障期間掛了 47 分鐘——每個請求都恰好打在同一支 endpoint 上。一家新創的「無上限」評測預算，因為一支永遠停不下來的 eval 腳本，一個週末就默默吞掉 $3,200。這些都不是假設。每一件都能避免，通常只靠一個設定變更。
這篇文章是檢查清單，不是教學。23 個錯誤的每一項都有：發生什麼事（真實事故）、修法（一句話）、以及完整實作指南在哪。其中幾項直接對應LLM 應用程式的 OWASP Top 10——LLM 安全的業界標準風險框架。把最後的檢查清單印出來。貼在你的螢幕上。
安全錯誤（1–5）
1. 原始碼裡寫死 API key。
真實事故：2025 年 6 月，LiteLLM 供應鏈內一個被攻陷的 PyPI 套件從每月 9,500 萬次安裝中竊走 API key。.env 檔、設定檔、原始碼裡的金鑰全都暴露在風險下。
修法：把金鑰存進機密保險庫（AWS Secrets Manager、HashiCorp Vault、Doppler）。執行期注入。絕不在建置時。
完整實作——LLM API 安全最佳實務
2. 所有環境共用同一把 API key。 修法：每個環境（dev/staging/prod）各用一把金鑰，帶每把 key 的模型白名單與預算上限。被攻陷的開發金鑰不該碰到生產模型。
3. API key 沒有預算上限。 真實事故：2026 年 3 月，一家公司用一把沒有支出上限的 API key，一個月燒掉 $500M。 修法：在供應商與平台兩個層級都設硬性預算上限。80% 警示。100% 硬拒絕。
4. 金鑰暴露在用戶端程式碼。 修法：所有 LLM 呼叫都透過後端代理。供應商 API key 絕不送達瀏覽器或行動 App。用戶端認證用短期虛擬金鑰。
5. 沒有金鑰輪替時程。 修法：每 90 天輪替一次金鑰。成員離職或疑似暴露時立刻輪替。藍綠輪替：生成新金鑰——與舊金鑰並行部署——監控——撤銷舊金鑰。
這五項共通的主軸：API key 是零階憑證。用你對雲端 IAM 的同樣嚴謹度管理它——保險庫、輪替、最小權限、硬上限。
成本錯誤（6–10）
6. 什麼都用 GPT-5.5。 真實資料：$875/月（全用 GPT-5.5）——$39.50/月（簡單任務用 DeepSeek V4 Flash＋複雜任務用 Claude Sonnet）。省 95%。終端用戶零品質損失。 修法：模型分層。簡單任務——便宜模型。複雜任務——前沿模型。 完整實作——成本優化策略
7. 忽略 reasoning token 成本。
真實事故：一支團隊在 2025 年 8 月把客服機器人遷移到 reasoning 模型。日成本一夜翻四倍——同樣的 prompt、同樣的流量、同樣的終端用戶體驗。元兇：每個 query 約 3,200 個看不見的 reasoning token，按輸出費率計費，在他們的使用儀表板上從未浮現。
修法：監控 API 回應裡的 reasoning_tokens。這些看不見的 token 按輸出費率計費，能讓你的實效成本膨脹 2–5 倍。設定 reasoning 預算上限。
8. 沒用 prompt 快取。 修法：快取系統 prompt、工具定義、few-shot 範例。Anthropic：快取輸入省 90%。DeepSeek：快取命中 $0.0036/M。OpenAI：省 50%。 完整實作——prompt 快取指南
9. 離線工作沒用 batch API。 修法：OpenAI、Anthropic、Google 對非同步批次處理（24 小時回轉）提供約 50% 折扣。所有非即時工作負載都該用 batch。
10. 沒有每用戶成本追蹤。 修法：每個用戶或每個功能各建一把虛擬 API key。把每個 API 呼叫歸屬到特定用戶。成本飆升時，你馬上知道為什麼。
共同模式：LLM 成本是消耗型成本，不是固定基礎設施。每一次沒被計量的呼叫、每一筆沒快取的 prompt、每一支多餘的前沿模型都會累積。把 API 帳單當雲端帳單經營——能計量的都計量、能分層的都分層、能批次化的都批次化。
可靠性錯誤（11–15）
11. 沒設定 fallback 模型。 修法：兩行的 try/except fallback 鏈。主力模型失敗——自動試備援。 完整實作——rate-limit 處理指南
12. 忽略 rate limit 標頭。
修法：在每個 200 回應上讀取 x-ratelimit-remaining-*。把剩餘預算顯示成量表。<20% 警示。<10% 降速。
13. 沒有帶指數退避的重試邏輯。
修法：指數退避＋隨機抖動。絕不用固定間隔重試——那會造成 thundering herd、保證更多 429。用 tenacity（Python）或 llm-retry-kit（Node.js）。
14. 用模型別名而不是帶日期的 ID。
真實事故：一家 fintech 團隊的交易分類器，在供應商把模型別名更新到新 snapshot 時默默壞掉。更新改變了每個回應的 JSON 欄位順序。三小時的誤分類交易、$4,600 的付款處理沖銷，值班工程師才發現。
修法：鎖定帶日期的模型 ID（gpt-5.5-2025-06-15）。gpt-5.5 這類別名會默默升級到可能意外改變你 prompt 行為的新 snapshot。
15. 沒有 circuit breaker。 修法：停止把流量導向持續失敗的供應商。冷卻期後探測。簡單的狀態機：closed——open（N 次失敗後）——half-open（探測）——closed（探測成功時）。
重點：LLM API 以可預測的方式失效——rate limit、供應商故障、模型默默變更。單一 endpoint、單一模型的架構，本質上就是脆弱的。fallback、退避、circuit breaker，把脆弱的依賴變成有韌性的依賴。
品質錯誤（16–19）
16. 沒有系統 prompt。 修法：系統 prompt 設定行為。沒有它，模型只能猜你想要什麼。「你是程式碼審查員。專注於安全漏洞與效能問題」比完全沒有系統 prompt 有效 100 倍。
17. 創意任務用 temperature = 0。 修法：temperature 指南：程式碼 = 0–0.3、聊天 = 0.7–1.0、創意寫作 = 1.0 以上。在 temperature=0 跑創意任務，會產出機械化、重複的輸出。
18. 長對話忽略 token 上限。
修法：追蹤訊息陣列的總 token。接近模型的上下文上限時，修剪舊訊息或摘要它們。絕不默默讓 API 回傳 context_length_exceeded 錯誤。
19. 不驗證結構化輸出。
真實事故：一條帳單 pipeline 假設 amount 永遠是數字。一次格式錯誤的 LLM 回應把 amount: "null" 以字串傳回。下游付款處理器把它解讀成零美元。47 張客戶發票以 $0 寄出，才有人標出這個錯誤。
修法：在對回應採取動作前，永遠驗證 JSON schema。就算開了 Structured Outputs 也要驗證——它會抓出邊緣案例，給你清楚的錯誤訊息，而不是下游一串連鎖失敗。
品質不是魔法——是設定。系統 prompt、正確的 temperature、token 意識、輸出驗證——這四個旋鈕設對了成本是零，忽略了卻會默默劣化你的產品。
架構錯誤（20–23）
20. 設計上就綁死供應商。
修法：用可設 base_url 的 OpenAI SDK 模式。供應商的選擇是設定決策，不是架構決策。
完整範例——多模型路由模式
21. 獨立任務用同步呼叫。
修法：十個獨立查詢＝十個並行 API 呼叫，不是十個循序呼叫。Python 用 asyncio.gather、Node 用 Promise.all。延遲從 20 秒降到 2 秒。
22. 沒有可觀測性。 修法：用統一 schema 記錄每個 API 呼叫：時間戳、模型、token、成本、延遲、用戶 ID。當 CFO 問起 API 帳單，你 30 秒就能回答，而不是花 3 小時。
23. 管理供應商而不是用聚合。 修法：一把 API key。一支 endpoint。內建 fallback、內建成本追蹤、內建 rate-limit 管理。別再每月花 8–12 小時維護供應商儀表板。 完整論述——開發者為什麼改用聚合
架構的教訓：LLM API 整合不是功能——是基礎設施。從第一天就為供應商獨立、並行執行、完整可觀測性、單一整合面設計。這些事後才補，成本是當初就內建的 10 倍。
可列印檢查清單
| # | 錯誤 | 嚴重度 | 修復時間 | 深入探討 |
|---|---|---|---|---|
| 1 | 寫死的 API key | 重大 | 30 分鐘 | [#18 安全] |
| 2 | 跨環境共用金鑰 | 高 | 15 分鐘 | [#18 安全] |
| 3 | 沒有預算上限 | 重大 | 5 分鐘 | [#18 安全] |
| 4 | 用戶端程式碼裡的金鑰 | 高 | 1 小時 | [#18 安全] |
| 5 | 沒有金鑰輪替 | 中 | 30 分鐘 | [#18 安全] |
| 6 | 什麼都用 GPT-5.5 | 高 | 10 分鐘 | [#15 成本] |
| 7 | 忽略 reasoning tokens | 中 | 5 分鐘 | [#15 成本] |
| 8 | 沒用 prompt caching | 高 | 30 分鐘 | [#17 快取] |
| 9 | 沒用 batch API | 中 | 15 分鐘 | [#15 成本] |
| 10 | 沒有逐使用者成本追蹤 | 中 | 1 小時 | [#15 成本] |
| 11 | 沒有 fallback 模型 | 重大 | 10 分鐘 | [#16 速率限制] |
| 12 | 忽略 rate limit headers | 高 | 15 分鐘 | [#16 速率限制] |
| 13 | 重試沒有退避 | 高 | 10 分鐘 | [#16 速率限制] |
| 14 | 使用模型別名 | 中 | 5 分鐘 | — |
| 15 | 沒有熔斷器 | 中 | 1 小時 | [#16 速率限制] |
| 16 | 沒有 system prompt | 中 | 5 分鐘 | — |
| 17 | 錯誤的 temperature | 低 | 1 分鐘 | — |
| 18 | 忽略 token 上限 | 中 | 30 分鐘 | — |
| 19 | 沒有驗證輸出 | 高 | 15 分鐘 | [#14 函式呼叫] |
| 20 | 供應商綁定 | 中 | 2 小時 | [#12 多模型] |
| 21 | 平行任務用同步呼叫 | 中 | 30 分鐘 | [#12 多模型] |
| 22 | 沒有可觀測性 | 高 | 2 小時 | [#12 多模型] |
| 23 | 手動管理供應商 | 中 | 5 分鐘 | [#8 為何轉換] |
數一下「還沒修」的項目。排優先：Critical——High——Medium。一天修一個。三週內，你的 API 基礎設施就達到生產等級。印出這張檢查清單。貼在螢幕上。你現在花 20 分鐘用這 23 項審計你的技術棧，會省掉那通誰都不想接的電話——有人告訴你 API 帳單剛幹了什麼事的那通。
常見問題
哪個錯誤最花錢？
沒有預算上限（錯誤 3）。一個缺失的設定可能花掉數百萬。一家公司因為一把沒上限的金鑰，一個月損失 $500M。每一層都設硬上限——供應商層、平台層、每把 key。實作：LLM API 安全最佳實務。
哪個錯誤最好修、ROI 最高？
什麼都用 GPT-5.5（錯誤 6）。把簡單任務切到 DeepSeek V4 Flash 或 Gemini Flash。成本降 70–95%。十分鐘就能做一支基本路由器。完整策略：12 招砍掉帳單。
我怎麼知道團隊是不是在犯這些錯誤？
跑一遍上面的檢查清單。每個沒勾的框，都是你正在犯的錯誤。依序排優先：Security——Cost——Reliability——Quality——Architecture。一次安全事故花的錢，超過任何優化省下的錢。
那件 $500M 的事故不是什麼精密攻擊。它是一份缺失的設定——一個沒人設的預算上限。在 LLM 工程裡，安全與成本是同一門紀律。這張清單上的每個安全錯誤——寫死的金鑰、共用的憑證、無上限的支出——同時也是成本錯誤。業界正在慢慢覺醒：隨著 LLM API 成為應用程式預設的資料層，API key 管理會承擔與資料庫憑證管理同等的重量。今天就用這種態度對待它的團隊，不會是寫下明年警世故事的那群人。
審計你的技術棧——預算上限、虛擬金鑰、fallback 路由、成本追蹤——讓安全與成本管理變成同一件事的基礎設施。