Buu 如何命名 AxonHub 的 API Keys 和 Profiles
Decision（决策）
当前命名规则分两层：
- API Keys（API 密钥）按客户端 / 软件命名
- API Key Profiles（配置文件管理）按能力策略命名
Context（背景）
Buu 发现自己在 AxonHub（AxonHub）里的 API Key（API 密钥），其真实使用边界往往不是抽象功能，而是具体客户端。
例如：
- 沉浸式翻译（Immersive Translate）
- 闪电说
这些客户端虽然用途不同，但底层可能复用同一套模型与渠道策略。
因此，API Key（API 密钥）名称和 API Key Profiles（配置文件管理）名称不应该混在一起。
Criteria（判断标准）
命名需要同时满足：
- 一眼能看出是谁在请求
- 一眼能看出这套规则是干什么的
- 当多个客户端复用同一套规则时，不会把 profile（配置文件管理）名字绑死在某个单一客户端或单一动作上
- 后续查 Request Logs（请求日志）和排查费用时足够直观
Facts（事实）
- 当前数据库里，这把 key 的名字已经是：沉浸式翻译。
- 当前它的 activeProfile 仍然叫：翻译。
- API Key Profiles（配置文件管理）本质上是每把 API Key（API 密钥）内部的规则层，主要承载 allowed models、allowed channels、model mappings 等限制。
- 同一种快、稳、便宜的文本模型策略，完全可能同时服务沉浸式翻译和闪电说。
Interpretation（解释）
所以：
- “沉浸式翻译”这种名字，很适合给 API Key（API 密钥）
- “翻译”这种名字，不适合继续作为 profile（配置文件管理）名字，因为它把规则误写成了单一用途
如果同一套规则后面还会服务字幕翻译、语音转录文本纠正、轻量文本清洗，那 profile（配置文件管理）应该写成更抽象但仍可读的策略名。
Current Rule（当前规则）
- API Keys（API 密钥）用客户端 / 软件名命名，比如：
- 沉浸式翻译
- 闪电说
- API Key Profiles（配置文件管理）用能力策略命名，比如：
- 轻量文本处理
- 快速低成本文本
- 快稳文本
- 如果多个客户端共用同一套模型和渠道规则，profile（配置文件管理）名称保持一致思路，不再按单个客户端重新起名。
Exceptions（例外）
- 如果某个客户端虽然名字一样，但后面用了完全不同的模型 / 渠道 / 限额规则，可以为它单独再起一个 profile（配置文件管理）名字。
- 如果某个 profile（配置文件管理）只服务一个非常专门的固定工作流，也可以用更具体的名字，但仍应描述策略而不是只描述客户端。
Review Trigger（复查触发条件）
出现以下情况时，应重新评估这条规则：
- 一个客户端内部开始同时使用多套明显不同的模型策略
- profile（配置文件管理）名称越来越抽象，已经看不出用途
- 查 Request Logs（请求日志）时，已经不能从名称快速判断流量来源或策略