API Key 安全清单
无论使用 Claude Code、Codex 还是 OpenAI 兼容 API，API Key 都应按项目、环境和成员拆分，避免把高权限密钥散落在多个客户端。
上线前检查
- 个人测试 Key 与生产 Key 分离。
- 每个 Key 设置日预算、月预算或速率限制。
- CI、服务器和本地开发机使用不同 Key。
- 日志只保留必要计费与错误信息，避免记录敏感 prompt。
- 离职、外包结束或泄露风险出现时立即轮换 Key。
Key Pool 风险：为什么不要所有工具共用一个 Key
很多团队一开始图省事，会让 Claude Code、Codex、Cursor、Cline、Roo Code、自动化脚本都共用一个 Key。这样短期方便，长期风险很高：
- 你无法判断到底是谁在消耗额度；
- 某个扩展配置错误，会把所有链路一起拖挂；
- 一旦 Key 泄露，你得一次性影响所有项目和环境；
- 很难做预算上限、最小权限和按团队审计。
更稳妥的做法是按 项目 / 环境 / 成员 / 客户端类型 分组，例如：
dev-claude-codedev-codexci-botprod-apiroo-agent
预算、轮换与日志脱敏
预算
- 为个人测试、CI、生产服务设置不同预算。
- 对高成本模型和自动化任务单独限额。
- 429 和余额问题不要只看“服务波动”，先看是不是你自己把预算打满了。
轮换
- 新成员加入时新发 Key，不复用旧 Key。
- 成员离职、外包结束、截图泄露、仓库误提交后立即轮换。
- 轮换时保留短期观察窗口，确认旧 Key 没有残留流量。
日志脱敏
- 只记录必要字段：时间、模型名、状态码、耗时、token 用量。
- 不在长期日志里保存完整 prompt、源代码、客户数据、密钥原文。
- 排查工单里只展示 Key 前后少量掩码字符，不贴全文。
敏感代码边界
不是所有代码都适合直接交给第三方模型或代理线路。尤其是：
- 生产密钥、证书、私钥；
- 客户数据库结构与敏感业务规则；
- 尚未公开的漏洞、补丁、合规材料；
- 涉及个人隐私、支付、身份认证的核心逻辑。
更稳妥的做法：
- 先删掉或替换敏感变量名和常量。
- 只给最小复现片段，不直接给整个仓库。
- 对高风险仓库单独使用隔离 Key 和更严格预算。
- 长期保留“哪些仓库可以进模型、哪些绝对不进”的团队规则。
模型真实性与降级自测清单
判断一个 AI API 中转站是不是“真模型”、有没有明显降级，不要只看一句“能回复”。更有用的是可复现自测。
| 检查项 | 你要看什么 | 异常信号 |
|---|---|---|
| 模型名映射 | 返回的模型名是否与控制台/文档一致 | 文案写一种，实际返回另一种 |
| 长上下文 | 长输入后是否明显截断、遗忘或异常压缩 | 短任务正常，长任务突然失真 |
| tool calling | 工具调用参数、结果结构是否稳定 | 能聊天，但一到文件/函数调用就坏 |
| JSON / structured output | 结构化输出是否稳定、字段是否乱飘 | 同样提示词每次结构都崩 |
| streaming | 流式输出是否自然、是否频繁中断 | 经常半截断流或长时间卡住 |
| 延迟 | 同模型同任务延迟是否长期异常波动 | 轻任务也持续高延迟 |
| 429 / 余额 | 限流、余额、套餐提示是否一致 | 明明有额度却频繁异常 429 |
| 日志留存 | 是否能解释日志、计费、请求追踪边界 | 只会宣传，不说日志策略 |
推荐自测顺序
- 短回复测试：只验证 Key、Base URL、模型名是否通。
- 长上下文测试：给较长输入，检查是否异常截断。
- 结构化输出测试：要求稳定 JSON 或固定字段。
- tool calling 测试：让支持工具的客户端读取文件、列目录、执行最小动作。
- 流式测试：观察是否频繁中断或异常卡顿。
- 余额 / 429 测试：确认错误提示和额度变化是否可解释。
如果某条线路“能聊天但工具总坏”“短任务正常但长任务明显缩水”，更像是兼容层不足、模型降级、路由不稳定，或能力边界没说明清楚。
团队接入建议
- 为 Claude Code、Codex、Cursor、Cline、Roo Code 等客户端单独分组。
- 定期查看请求统计、余额和异常错误码。
- 高峰期准备备用模型或线路，但不做绝对可用承诺。
- 让安全规则先落文档，再落到实际预算、轮换和日志策略里。