人多起来之后，Key 往往是一人一把、谁配的谁记得，等到有人离职或者设备丢了，才发现根本说不清哪些 Key 还在用、该先停哪个。这篇不讲安全大道理，只给一条可执行的时间线：怎么给 Key 分级、轮换按什么节奏走、交接时逐项对什么、吊销按什么顺序做。原则部分请配合 key-safety 一起看，这里负责动作和清单。
人多起来之后，Key 往往是一人一把、谁配的谁记得。等到有人离职、笔记本丢了或者微信群里那张截图传开了，才发现根本说不清哪些 Key 还在跑、该先停哪个。真正麻烦的不是没制度，而是没人能立刻说出「这个人名下还有几把、分别绑在哪」。
这篇不讲安全大道理，只给一条能照做的时间线：怎么分级、按什么节奏轮换、交接逐项对什么、吊销按什么顺序。原则层面（什么内容本来就不该发出去）配合 /ai-dict/category/safety 的 key-safety 那批术语一起看，这里只负责动作和清单。
先分级：每把 Key 对应一个用途，而不是一个人
分级的目的不是分类好看，而是决定出事时先动哪一把。按用途分三档：个人调试、项目或服务端、生产关键路径。越靠后，拿的人越少、申请越麻烦、轮换越谨慎。同一个服务别多人共用一把 Key，否则后台只看到「有人超标」，分不清是谁在跑。
| 档位 | 谁可以拿 | 权限给法 | 出事时怎么动 |
|---|---|---|---|
| 个人调试 | 个人自己 | 只给读或小额度 | 直接吊销，不影响别人 |
| 项目/服务端 | 该项目负责人少数几人 | 按调用需要开，限模型限额度 | 先降额观察，再换新 |
| 生产关键路径 | 运维或值班少数人 | 只开必要能力，能限来源 IP 就限 | 冻结、切新、回滚一起走 |
- 给每把 Key 记一条台账：用途、归属人、创建时间、绑在哪台机器或哪个服务、上次轮换时间
- 权限按最小给：只读任务就别发带写入和扣费权限的 Key
- 平台能限模型、限额度、限来源 IP 的，能限就限，别只靠自觉
- 台账放在团队都能看的地方，别只存在某个人的笔记软件里
- 不适用的情况：单人自用且所有 Key 都在自己机器上，分级可以简化成「常用」和「临时」两档
轮换节奏：按暴露面定，不按日历定
很多人喜欢定「每月一换」，但真正该看的是这把 Key 有多少人见过、有没有离开过受控环境。写在服务端环境变量里、只有运维能碰的，周期可以长；发在群聊、贴进客户端配置、多人共享的，周期必须短。触发式轮换永远优先于日历。
- 先定触发条件有人离职、设备丢失或转卖、Key 曾经进过公开仓库或截图、用量突然异常，满足任意一条立刻换。
- 再排例行节奏按暴露面分两档：受控环境放长周期，半公开或共享的放短周期，写在台账里。
- 轮换时同步分流常用路径一把、临时测试一把。出问题时先停临时那把，不牵动主链路。
- 换完必须验证新旧 Key 各发一次最小请求，确认新 Key 通、旧 Key 已经不通；只在后台点禁用不算验证。
想确认自己理解的暴露面划分对不对，可以到 /ai-dict/category/safety 查术语对照，再到 /price-watch 看不同通道在异常用量上的表现差异，具体数字以当时页面为准。
交接清单：换人时逐项对，别口头说
交接最怕的是「你懂我懂」的口头交接。真正管用的是一张能打勾的清单，接的人照着走一遍，交的人签字确认。清单里不只放 Key，还要放账号成员权限、用量后台登录、账单归属，否则人走了账还挂在他名下。
- 列出这个人名下所有 Key 与其绑定的服务、机器、仓库、CI/CD 变量、第三方平台，逐项打勾
- 同步交接账号成员权限、用量后台登录、账单归属
- 入口侧一起改：环境变量、密钥管理服务、客户端配置文件、协作文档里的明文片段
- 留一份交接记录：谁交、谁接、哪些已吊销、哪些待观察、下次复查时间
- 用 /usage 一类页面把交接前后的用量对一遍，确认没有漏网的调用方
- 不适用的情况：如果整个环境靠共享账号跑、没有个人归属，这套清单会失效，先解决归属问题
吊销顺序：先断新增，再清存量，最后收尾
吊销最容易犯的错是一上来就删。删掉之后旧副本还在发请求，你只会看到一连串 401，却分不清是吊销生效了还是别的地方炸了。顺序上，先断新增、再清存量、最后收尾，比一次删干净更稳。
- 先冻结而不是直接删禁用或降额，观察一段时间，确认没有业务报错再彻底吊销，避免误伤线上任务。
- 按风险从高到低处理能扣费的、权限最宽的、暴露时间最长的先动。
- 清衍生痕迹缓存里的旧 Key、日志里打印过的请求头、截图和文档里的明文，能删就删。
- 回归验证用旧 Key 发一次请求，应该是明确的鉴权失败；还能通说明还有副本，参考 /tools/verify#probes 的思路自己构造探测请求。
真出事了：留证、止损、复盘三步走
真出事时，大多数人第一反应是赶紧改配置，结果证据也没了。正确做法是留证在前、止损在中、复盘在后。证据不用多复杂，异常时段的用量记录、请求日志、后台截图，先存本地再动手。
| 阶段 | 要做什么 | 产出去哪 |
|---|---|---|
| 留证 | 导出异常时段用量、日志、截图，存本地 | 复盘材料 |
| 止损 | 按吊销顺序执行，同时把业务切到新 Key | 链路恢复记录 |
| 复盘 | 只问暴露路径、为什么没发现、下次靠什么机制提前发现 | 台账字段与触发条件 |
- 复盘只问三个问题：这把 Key 是怎么暴露的、当时为什么没人发现、下次靠什么机制提前发现
- 结论沉淀成台账字段和轮换触发条件，而不是写一篇没人看的总结
- 原则层面什么内容不该发出去，见 /ai-dict/category/safety 的 key-safety 部分，这篇只负责时间线
常见问题
轮流换 Key 会不会把线上服务搞挂？
会，如果换的时候没有过渡。稳妥做法是双活期：先建新 Key 并让服务逐步切过去，确认新 Key 有流量、旧 Key 流量归零，再禁用旧的。禁用到吊销之间留一段观察期，期间盯一眼错误率，确认没有遗漏的调用方再删。
小团队就三五个人，也值得搞台账吗？
值得，但可以极简。一张表格就够：Key 名、用途、归属人、绑定位置、上次轮换时间。真正省事的是「一把 Key 一个用途」，出问题时你能一眼看出该停哪把，而不是把所有人的工作一起停掉。人数再少，离职和换设备这两个场景都躲不掉。
怎么知道旧 Key 真的已经失效了？
不要只看后台状态。用旧 Key 发一个最小请求，期望结果是明确的鉴权失败而不是超时或网络错误；两者含义不同，后者说明你连错了地址，等于没验证。另外要检查副本：环境变量、CI 配置、客户端配置文件、文档和聊天记录里的明文，都清完才算真的断了。
