模型路由命名规范：别让用户猜哪个模型能用

当一个产品接入多个 AI 模型时，最容易让用户困惑的不是模型太少，而是名字太乱。

后台可能同时有本地模型、云端模型、视觉模型、审核模型、编码模型和备用模型。运营人员知道每个别名是什么意思，但前端用户不应该靠猜来判断哪个能用。

这份命名规范适合给模型路由和 API 面板使用。

1. 名字先说明用途

模型名称最好先表达用途，再表达技术来源。

例如 audit 比一串底层模型名更适合审核入口，vision 比硬件编号更适合图片理解入口，coder-heavy 比内部机器名更适合代码任务入口。

底层模型可以在后台记录，但前端显示应该优先服务用户选择。

2. 状态要和名字分开

不要把 prod、test、fallback 全塞进展示名里。

更清晰的做法是：名称负责说明用途，状态字段负责说明是否可用、是否灰度、是否维护中。这样用户看到的是稳定入口，管理员看到的是运行状态。

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

如果后台没有配置、没有验证、没有额度或没有通过健康检查，就不要展示给用户。

让用户在一长串模型里试错，会把平台显得像调试工具，而不是可用产品。API 运营平台应该展示“我们已经接好并承诺可用的模型”，而不是展示所有理论上存在的模型。

4. 别名要能长期保留

底层模型会升级，别名应该尽量稳定。

例如今天 audit 后面是一个本地模型，明天可以换成更强的审核模型。只要接口能力一致，用户的 API key 和调用路径就不应该被迫改名。

5. 管理端保留映射证据

前端显示可以简洁，管理端必须完整。

每个别名应该能看到底层 provider、模型 ID、上下文长度、限流规则、健康检查结果、最近失败原因和负责人。这样出了问题时，运营人员能定位，不需要靠聊天记录猜。

好的命名规范会把复杂性收在后台，把确定性留给用户。用户看到的是少量可用入口，管理员看到的是完整映射和状态，这才是模型路由从工程配置走向产品能力的关键一步。