模型路由命名規範：別讓用戶猜哪個模型能用

當一個產品接入多個 AI 模型時，最容易讓用戶困惑的不是模型太少，而是名字太亂。

後台可能同時有本地模型、雲端模型、視覺模型、審核模型、編碼模型和備用模型。營運人員知道每個別名是什麼意思，但前端用戶不應該靠猜來判斷哪個能用。

這份命名規範適合給模型路由和 API 面板使用。

1. 名字先說明用途

模型名稱最好先表達用途，再表達技術來源。

例如 `audit` 比一串底層模型名更適合審核入口，`vision` 比硬體編號更適合圖片理解入口，`coder-heavy` 比內部機器名更適合程式碼任務入口。

底層模型可以在後台記錄，但前端顯示應該優先服務用戶選擇。

2. 狀態要和名字分開

不要把 `prod`、`test`、`fallback` 全塞進展示名裡。

更清晰的作法是：名稱負責說明用途，狀態欄位負責說明是否可用、是否灰度、是否維護中。這樣用戶看到的是穩定入口，管理員看到的是執行狀態。

3. 前端只顯示已接入模型

如果後台沒有配置、沒有驗證、沒有額度或沒有通過健康檢查，就不要展示給用戶。

讓用戶在一長串模型裡試錯，會把平台顯得像除錯工具，而不是可用產品。API 營運平台應該展示「我們已經接好並承諾可用的模型」，而不是展示所有理論上存在的模型。

4. 別名要能長期保留

底層模型會升級，別名應該盡量穩定。

例如今天 `audit` 後面是一個本地模型，明天可以換成更強的審核模型。只要介面能力一致，用戶的 API key 和呼叫路徑就不應該被迫改名。

5. 管理端保留映射證據

前端顯示可以簡潔，管理端必須完整。

每個別名應該能看到底層 provider、模型 ID、上下文長度、限流規則、健康檢查結果、最近失敗原因和負責人。這樣出了問題時，營運人員能定位，不需要靠聊天記錄猜。

好的命名規範會把複雜性收在後台，把確定性留給用戶。用戶看到的是少量可用入口，管理員看到的是完整映射和狀態，這才是模型路由從工程配置走向產品能力的關鍵一步。