AI API 成本失控，很多时候不是因为模型太贵，而是因为没人知道谁在用、用在哪里、什么时候开始异常增长。等月底账单出来才发现翻了三倍，往回查连是哪个脚本跑的都说不清。经验规则很简单：团队一旦超过三个人，就不应该再共用一个 API Key。这篇把团队 Key 结构、预算分层、巡检指标和异常处理流程完整讲一遍，照着做就能把账单从黑盒变成看板。
为什么不能共用一个 Key
共用 Key 看起来省事，但会带来四个结构性问题：
- 查不了账：无法知道具体是谁、哪个项目产生了消耗
- 停不了机：Key 泄露或异常时只能全员一起停用，业务连坐
- 分不清人机：自动化任务和人工使用混在一起，用量曲线没法解读
- 限不了额：无法给不同成员、不同用途设置独立预算
当账单变高时，你只能看到总数，看不到原因；想止损时，只能全停，不能精准熔断。这两点在事故现场都是致命的。
推荐 Key 结构
一个清晰的团队按“用途”而不是按“省事”来拆 Key：
| Key 类型 | 用途 | 预算建议 |
|---|---|---|
| 成员 Key | 每个成员日常开发（Claude Code、Codex 等） | 月预算，宽松 |
| 项目 Key | 每个线上项目/环境单独使用 | 月预算 + 告警 |
| 自动化 Key | CI、脚本、批处理任务 | 日预算，严格 |
| 临时 Key | 外包、试用、短期任务 | 小额，到期即停 |
配套一个命名约定，让 Key 列表自解释。可以在团队文档里固定这个模板：
# 命名约定：{类型}-{归属}-{用途}
member-zhangsan-dev # 张三的日常开发 Key
project-webapp-prod # Web 应用生产环境
project-webapp-staging # Web 应用测试环境
auto-ci-nightly # 每晚 CI 回归任务
temp-outsourcing-202607 # 外包临时 Key，7 月底停用不同 Key 的预算和权限应该不同：临时 Key 到期就关，自动化 Key 设置最严格的日预算——脚本跑飞比人工误用危险得多，人会累，循环不会。
预算怎么设：三层结构
预算不要只设一个总额，最好分三层，各管一件事：
- 团队月预算：控制整体成本上限，对应财务口径
- 成员预算：避免个人误用或超强度使用，新人和实习生设得更紧
- 项目/Key 预算：避免单个业务或脚本异常放大
三层的关系是漏斗：任何一层被击穿都会先触发告警或熔断，问题被限制在局部。如果只能先做一层，优先给自动化任务设日预算。
预算数值怎么定？先跑两周不设限但全量统计，拿到基线后按“基线的 1.5 到 2 倍”设置，之后每月根据用量排行微调。凭空拍的预算要么天天误报，要么形同虚设。
每周看哪些指标
团队管理不需要每天盯，但每周要固定看一次，五个指标十分钟看完：
- 成员用量排行：谁的消耗突然进入前三，问一句在做什么
- 模型用量排行：最贵的模型是否被用在了低价值任务上
- 失败请求和重试次数：失败率上升往往先于成本上升出现
- 单位任务平均成本：同类任务的均价变化，反映提示词或上下文膨胀
- 僵尸 Key：长期不用但仍启用的 Key，直接停用，减少泄露面
这些指标专治“成本慢慢变高”——突增靠预算熔断，缓涨靠每周巡检。
异常处理流程
发现异常消耗时，不要第一时间删 Key，更不要停总账户。推荐流程：
- 在用量看板定位异常 Key（看小时级曲线，找拐点）
- 暂停这一个 Key，止血
- 找到对应成员或项目，确认是误用、bug 还是泄露
- 修复脚本、轮换 Key 或调整配置
- 重设预算后恢复，继续观察一个周期
如果怀疑是 Key 泄露，多做两步：作废旧 Key 而不是暂停，检查泄露渠道（提交历史、日志、截图）。日常写代码时用环境变量注入 Key，避免硬编码：
# .env 只存在于本机和部署环境，进 .gitignore
OPENAI_API_KEY=sk-project-webapp-prod-xxxx
OPENAI_BASE_URL=https://zivv.pro/v1
# 代码里永远从环境读取，不写死这就是独立 Key 结构的价值：问题可以局部处理、精准熔断，全团队其他人毫无感知。
从共用 Key 平滑过渡到独立 Key
已经共用了一个 Key 的团队，不需要停机切换，按四步走：
- 先建新不动旧：按上文结构给每个成员和项目建好新 Key，旧共用 Key 保持可用
- 分批迁移：先迁自动化任务（配置集中、改动最快），再迁成员本地工具，最后迁线上项目
- 观察一周：旧 Key 的用量曲线应该逐步归零；降不下去，说明还有没登记的调用方——这本身就是一次资产盘点
- 停用旧 Key：归零后停用，保留记录。今后任何“不知道哪来的调用”都不可能再挂在公共 Key 下面
整个过程业务无感，一般一到两周走完。最大的收获往往不是账单，而是第 3 步盘出来的那些“没人记得的脚本”。
Zivv 团队模式能做什么
上面的做法需要平台侧能力支撑，Zivv 团队模式 把这些动作产品化了：
- 邀请成员，成员各自持有独立 Key
- 共享余额：统一从 Owner 余额扣费，成员不用各自充值绑卡
- 多维预算：按成员、按 Key 设置上限
- 用量分析：按成员、Key、模型三个维度查看消耗
- 单 Key 停用与恢复，不影响其他成员
充值汇率 ¥1 = $1，按量计费，Owner 不需要手工收账。预算和扣费口径可以配合 计费说明 一起看；成员日常用的 Claude Code、Codex 接入方式见 接入文档。
把 Key 管理写进团队流程
工具配好之后，还要落到流程里才能长期有效。三个节点各加一条固定动作：
- 入职：新成员报到清单里加一项“创建成员 Key、设默认预算、发接入文档”，十分钟完成，从第一天起用量就有归属
- 新项目立项：立项模板里加一项“创建项目 Key（区分环境）、设预算、登记负责人”，避免新项目临时借用别人的 Key
- 离职/结项：清单里加一项“停用对应 Key”，和回收仓库权限放在同一步
流程化的意义在于不依赖任何人的记性。三个月后团队换了一批人，Key 结构依然是清晰的，而不是回退到“谁有 Key 用谁的”。
月度复盘：预算之外的第二道防线
预算和周巡检解决“不失控”，月度复盘解决“花得值”。每月末花半小时回答三个问题：
- 结构合理吗：最贵的模型是否花在了最有价值的任务上？如果发现高价模型大量消耗在固定格式抽取这类任务，说明该做模型路由了，可参考 多模型路由策略
- 单价在降吗：同类任务的单位成本环比变化。提示词优化、上下文精简、摘要缓存这些工程手段的效果都会体现在这个数上
- 预算要调吗：连续两个月用量只有预算一半的 Key 调低，贴着上限的 Key 弄清原因后调高或优化
复盘产出直接写进下月预算，形成“设定—执行—复盘—调整”的闭环。做到这一步，AI 成本就从每月的意外变成了可规划的常规支出。
常见误区
误区 1：等出了问题再拆 Key。 拆 Key 的成本在第一天最低，出事后再拆等于边救火边改水管。
误区 2：预算设了就不管。 预算是根据基线动态调的，三个月不动的预算大概率已经失真。
误区 3：只看总额不看结构。 总额正常不代表健康，可能是核心项目用量下降掩盖了某个脚本的异常增长。
误区 4：把预算当成对成员的不信任。 预算的作用是兜住误操作和脚本 bug，不是监控谁“用多了”。把这层意思讲清楚，团队推行阻力会小很多。
常见问题 FAQ
Q1：小团队（三五个人）有必要搞这么细吗？ 按最小集来：每人一个 Key、自动化单独一个 Key、自动化设日预算，十分钟配完。三层预算和周巡检可以等团队变大再补。
Q2：成员离职或外包结束，Key 怎么处理？ 直接停用对应 Key 即可，不影响任何其他人——这正是不共用 Key 的意义。建议把“停 Key”写进离职/结项清单。
Q3：预算触顶后请求会怎样？ 超出预算上限的 Key 会被拦截，业务侧收到明确的错误响应。所以给生产项目 Key 设预算时要留缓冲，并配合告警提前处理，而不是让熔断成为第一道防线。
Q4：一个成员同时用 Claude Code 和 Codex，要几个 Key？ 建议两个，分别对应两个工具。用量能分开统计，也能单独停用。Key 本身没有额外成本，拆细只有好处。
Q5：Owner 怎么控制整体充值节奏？ 共享余额模式下，Owner 按月充值一次即可，充值汇率 ¥1 = $1。建议充值额度按上月实际消耗的 1.2 到 1.5 倍准备，余额低于一周用量时提前补充，避免余额见底导致全团队请求被拦。
结论
团队 AI 成本管理的核心不是“少用”，而是“分清楚谁在用”。从第一天开始按成员、项目、自动化任务拆 Key，配上三层预算和每周十分钟的用量巡检，绝大多数账单失控都能在发生前被拦住。如果你的团队还在共用一个 Key，现在就可以 创建 Zivv 团队，把 Key 结构和预算一次配好——这半小时的投入，会在第一次异常发生时全部赚回来。