原则：一个项目一个 Key，一个环境一个 Key，一个用途一个 Key。不要让一个 Key 同时承担测试、生产、批处理和外部代理。
一、命名结构
示例
org-product-env-purpose-owner tb-docbot-prod-summary-li-ning tb-crm-test-classify-zhang-wei tb-etl-prod-embed-wang-qiang
建议字段至少包含项目、环境、用途、负责人。不要用日期做主标识，改名会让用量统计断裂。
二、为什么要拆
- 发现异常时能马上知道是哪个项目。
- 避免测试任务和生产业务抢同一个限流。
- 便于按项目给预算和报价。
- 轮换某一个用途时，不影响其他项目。
- 不同负责人可以有不同的审批链和限额。
三、每个 Key 的基本元数据
| 字段 | 示例 | 用途 |
|---|---|---|
| owner | li-ning | 出现问题时直接找到负责人 |
| project | docbot | 项目归属和成本中心 |
| env | prod / staging / test | 控制告警级别 |
| purpose | summary / embed / classify | 判断是否刷量 |
| rate_limit | 1000 req/h | 限制意外循环 |
| budget | $80/month | 月度预警 |
| expires_at | 2026-12-31 | 强制轮换 |
四、生命周期
- 创建：先在内部登记，然后生成 Key。
- 验证：先运行 50-100 次实际请求，看格式命中率和失败率。
- 接入：设置监控、告警和预算。
- 旁观期：上线后 72 小时里必须有更频繁告警。
- 轮换：提前 7 天发新 Key，业务双 Key 并行 24-48 小时。
- 停用：确认旧 Key 无流量后再删除。
五、常见问题
- 几个项目共用一个 Key：出问题时无法定位。
- 测试和生产同 Key：测试任务引起生产限流。
- 只记录在某人电脑里：人员离职后无法审计。
- 用真实业务名以外的东西命名，如 test1、new、final，导致后续无法管理。
六、给团队的落地建议
先做三件事，不要一上来就做复杂系统：
- 把现有 Key 按项目列一张表，填上负责人。
- 把测试与生产的 Key 分开，禁止 test key 进生产。
- 给新 Key 统一命名模板，旧的可以慢慢改。
七、审计方法
- 过去 7 天请求数、tokens、金额三个量都要有记录。
- 对没有负责人或没有项目归属的 Key 设置为待观察，七天后停用。
- 同一项目重复用途超过两个时，确认是否真的需要。
- 每次人员变动后检查其名下 Key，及时移交或停用。
八、实际例子
如果只有两个 key：tb-prod 和 tb-test，当某个项目消耗突然翻三倍时，很难从 key 名称判断是谁出了问题。拆成下面这样：
示例
tb-docbot-prod-summary-li-ning tb-docbot-prod-embed-li-ning tb-crm-prod-classify-zhang-wei tb-crm-prod-response-zhang-wei tb-internal-test-summary-li-ning
就能按项目、环境、用途、负责人直接报警。
九、命名原则
记住一句话：命名不是为了 descriptive 而已，而是为了出问题时能在 1 分钟内找到对应人和项目。一个能准确定位异常的 key 名称，比一个语义很精细但没人维护的命名更有价值。