同事离职时怎么收尾：无独立登录的聚合站上，共用 key 的权限清理

先弄清一件事：这里可能没有“删掉这个人”的按钮

很多团队的第一反应是进后台找人、点删除。但在以 API key 为核心的聚合站上，账号体系通常只有“注册用户”和“key”两层，没有把每个人做成独立子账号。

原因很直接：扣费发生在 key 上，不发生在人身上。所以只要团队是多人共用同一把 key，后台就看不到“谁用了多少”，也没有“成员列表”可以删除。离职收尾的对象不是“这个人的账号”，而是“这把 key 以及它背后的凭证”。

先确认你们属于哪种情况：

• 每人一把独立 key，只是集中充值：处理起来简单，吊销那一把即可。
• 多人共用一把 key：这才是本文的重点，需要轮换加排查。
• 有人把 key 写在自己的代码、脚本、CI 变量或个人笔记本里：即使吊销主 key，也要检查残留。

共用 key 的真实代价：用量归属断档

共用 key 时，账单只能告诉你“这把 key 这个月花了多少”，无法拆到人。平时这影响不大，离职时会变成两个具体问题。

问题一：无法判断离职前是否有异常消耗

如果这个人手上拿着 key，或者能从某个共享位置取到 key，你无法从账单反推他的行为。总量曲线里没有他的分量，异常只能靠时间点、调用模式和日志去猜。

问题二：追溯记录接不上

离职之后，他经手的调用还会混在新 key 的账单里吗？不会，但旧 key 的历史和数据仍挂在同一个 key 上。等你需要核对某段时间的调用来源时，会出现“人已经走了、调用还在账上”的断档。

这些都是共用 key 的结构性后果，不是谁操作失误。想彻底解决，只能靠轮换和拆分，而不是事后找补。

收尾的正确顺序

顺序错了会给自己制造麻烦。建议按下面的次序走。

第一步：先盘点这把 key 出现在哪里

在动手之前，把所有可能持有 key 的位置列出来，至少包括：

• 团队代码仓库里的配置文件、示例脚本、测试用例
• 环境变量、CI/CD 密钥、部署平台的环境配置
• 本地开发机的 shell 配置、.env 文件
• 共享文档、聊天记录、工单里贴过的片段
• 第三方工具或 SaaS 里填过的自定义 API 地址与 key

这一步不需要精确，但要覆盖全。审计一遍的成本，远低于轮换后发现还有地方在用旧 key。

第二步：确认余额和结算状态

共用 key 意味着余额是共享的。离职前先看清当前用量和剩余额度，避免在轮换过程中因为余额归属不清产生争议。如果团队是按贡献 key 抵扣、按官方价 ×1.1 或 ×1.2 返 USDC 的模式运作，也要把这一期的贡献和消耗对齐，别让离职变成一笔糊涂账。

第三步：轮换，而不是“等它不用了”

正确的做法是新建一把 key，把所有该用的地方切过去，然后吊销旧 key。不要反过来先吊销再慢慢换，那样会直接打断线上调用。

轮换时注意：

• 新 key 不要沿用旧 key 的命名习惯，起一个能看出用途和归属的名字，方便下次收尾
• 切换窗口尽量选在低峰，切完立刻验证一条真实调用
• 吊销旧 key 后，观察一段时间是否还有报错，有报错说明某个位置漏改了

第四步：处理残留凭证

不只是 key。离职人员可能还持有：

• 平台登录用的邮箱或密码
• 充值相关的钱包地址或转账记录
• 贡献 key 的绑定关系（如果他把自己的 key 贡献给了团队）

如果团队走的是无 KYC、用 USDC 充值的模式，充值侧通常没有实名绑定，这意味着凭证更多是以“谁能操作”为准。该改的密码、该解绑的贡献关系，一并处理。

为什么“按人删除”在这里不成立

把这个逻辑讲清楚，能避免团队在收尾时反复纠结。

聚合站的计费单位是 key，一个 key 对应一份余额和一条用量记录。人不是计费对象，所以系统没有理由维护“人 → 权限”的映射。你看到的“账号”，本质上是“能登录后台、能创建和管理 key 的身份”。

于是会出现两个结果：

• 如果离职的人自己注册过账号，你能做的是改密码、收回登录，而不是从某个团队空间里移除他。
• 如果他从没注册过、只是用了团队的 key，那后台根本不存在他，能清理的只有 key。

理解了这一点，收尾的目标就从“删人”变成“让旧凭证失效”，这才是真正有效的动作。

事后防复发：把共用 key 拆开

一次离职收尾做完，最值得做的是降低下一次的成本。

• 按用途拆 key：不同项目、不同环境各一把，出问题时能精确定位
• 按人拆 key：至少让每个直接调用的人有独立 key，用量归属不再断档
• 建立登记表：key 名称、用途、持有人、创建时间、最近轮换时间，收尾时照着表走
• 定期轮换：把轮换做成例行操作，离职就只是提前触发一次

拆分之后，你仍然是一个 API key 调多个模型，只是从“一把大 key”变成“多把有归属的 key”。成本结构不变，可管理性完全不同。

一份可以照着走的收尾清单

离职当天按这个顺序执行：

1. 盘出旧 key 的所有出现位置
2. 核对当期用量与余额，结清贡献与消耗
3. 新建命名清晰的 key，切换所有调用方并验证
4. 吊销旧 key，观察报错确认无遗漏
5. 收回后台登录凭证，解除贡献绑定
6. 更新 key 登记表，记录本次轮换

共用 key 的团队，收尾从来不是“删个人”那么简单，但也不复杂：把不可见的归属问题，用一次干净的轮换解决掉。