01 · 單一 gateway
所有呼叫，統一經一道閘。
所有模型流量——無論係 OpenAI、Anthropic，定係運行喺你自家硬件上嘅 open-weights 模型——都經由單一 gateway 處理，每個應用程式配一條 virtual key。更換供應商只需修改 config；你亦可以為每個團隊設定開支上限，或者撤銷個別 key，毋須重新部署。只要有兩個服務各自直接呼叫唔同 SDK，你就會失去監察、預算控制同切換能力。
AI 整合指南
順暢整合 AI。
我哋整合 OpenAI、Anthropic 同內部模型嘅方法，可以避免原型同正式上線之間嘅落差。
大多數 AI 功能都卡喺示範同部署之間。模型從來唔係難點，真正困難嘅係周邊基建。以下係我哋每個項目必做嘅檢查清單，並按實際執行次序排列。
02 · grounding
讓答案建基於您自己的事實。
冇事實根據嘅 chatbot，可能會先亂作你嘅定價，之後先道歉。Retrieval 先行：將你嘅手冊、文件同政策分塊、嵌入，並喺每個答案附上出處。Guardrails 守住最前線，確保對話唔離題、唔越界。如果 context 冇答案，正確回應係「我唔確定」，而唔係即場作故仔。
03 · 沉悶的部分
為 retry、timeout 與 rate limit 預留工夫。
原型只在 happy path 上運作正常；生產環境考驗的卻是其餘所有路徑。帶 backoff 與 jitter 的 retry、硬性 timeout、按用戶計的 rate limit，以及在串流中斷時能優雅回退的 streaming 機制。這些都不適合拿來做示範，卻全都承重 — 它們正是「一宗事故」與「一次無人察覺的重試」之間的分別。
04 · 審計與 rollback
像管理程式碼一樣為 prompt 做版本控制。
Prompt 存放於 git，而非儀表板上的文字框。每個 completion 都連同產生它的模型、prompt 版本與 context 一併記錄。當供應商更新模型、行為隨之改變 — 這是必然會發生的事 — 您可以在幾分鐘內 diff 出改動並 rollback，還附有一條合規團隊真正讀得懂的審計紀錄。
05 · evals
先講 eval，後談感覺。
用真實問題同預期行為組成 golden set，每次修改 prompt 或模型時自動運行。呢個唔係學術 benchmark，而係你嘅問題、edge case 同語氣。「感覺好咗」唔算迴歸測試；失敗時真正會截停部署嘅 eval 先算。
06 · 退場機制
掌握自己的退場之路。
如果託管 API 起步最快，就從它開始 — 但要保持接縫乾淨，讓日後遷移至自家硬件上的 open-weights 模型時，只是改一次 config，而非重寫。我們自己正以同一套 gateway 模式，在自託管模型上運行生產工作負載；我們構建的一切都不會綁定任何供應商。一如我們交付的其他成果：它完全屬於您。