2026-04-11 AxonHub API Key / Profile 命名讨论摘录

Context（背景）

讨论 AxonHub（AxonHub）里 API Keys（API 密钥）与 API Key Profiles（配置文件管理）的命名边界。

Key points from the discussion

• Buu 认为 API Key（API 密钥）的名称完全可以按具体软件 / 客户端来命名，因为实际调用边界就是客户端边界。
• 当前“翻译”这把 API Key（API 密钥）其实只给沉浸式翻译（Immersive Translate）这个 Chrome 扩展使用，因此更适合直接叫“沉浸式翻译”。
• 接下来 Buu 还会创建一个 API Key（API 密钥）给闪电说使用，用于语音转录后文本纠正。
• 闪电说的需求和沉浸式翻译类似：都希望又快又稳、质量不错、价格便宜，因此两者完全可能复用同一套 profile（配置文件管理）规则。
• 既然一套 profile（配置文件管理）可以服务多个客户端，那 profile 的名字就不应该继续按单个客户端或单个动作（如“翻译”）来命名。

Checked facts during the discussion（讨论中已核对事实）

• 当前数据库里 API Key（API 密钥）名称已经是：沉浸式翻译。
• 当前这把 key 的 activeProfile 仍然叫：翻译。
• 这把 key 当前限制的模型是 gemini-3-flash-preview，并指定了一组可用 Channel（渠道）。
• AxonHub（AxonHub）的 API Key Profiles（配置文件管理）是嵌在每把 API Key（API 密钥）里的规则层，不是一个全局共享对象。

Practical conclusion from the discussion（讨论中的实际结论）

• API Key（API 密钥）名称更适合按客户端 / 软件命名。
• API Key Profiles（配置文件管理）名称更适合按能力策略命名。
• 如果沉浸式翻译和闪电说都要复用同一套快、稳、便宜的文本模型规则，那么 profile（配置文件管理）应改成能同时覆盖两者的名字，而不是继续叫“翻译”。