两个人共用一个聚合 key 跑 Claude Code：用各自的项目级配置代替互相拷贝的 shell export

共用同一个聚合 key 本身没有问题，问题往往出在配置层：两个人分别在自己的 shell 里 export 了不同的 ANTHROPICBASEURL 或模型别名，结果在共享终端、tmux 会话或 CI 里互相覆盖。下面是一套按「仓库级 + 个人 profile」分离配置的做法，适用于 Claude Code 这类通过环境变量读取 base URL 与模型名的客户端。

先分清三层配置

把配置分成三层，作用范围从大到小：

• 全局层：聚合站分配的 key 本身、默认 base URL。这层两人可以完全一样，放在共享的密钥管理里即可。
• 开发者 profile 层：每个人偏好的模型别名、超时、日志级别。这层因人而异，但不该写入仓库。
• 仓库层：某个项目需要固定使用的模型、代理地址、MCP 配置。这层随仓库走，进版本控制。

冲突几乎总是发生在「把开发者偏好写进了全局 shell 启动脚本」。把偏好下沉到 profile 层，仓库相关配置下沉到仓库层，全局层就只剩 key 和默认地址，共用 key 不会再互相干扰。

仓库层：用项目内配置文件固定 base URL 与模型别名

Claude Code 支持在项目目录下放置配置文件（例如 .claude/settings.json 或项目级 .env，具体以你所用版本为准）。把与项目绑定的变量写在这里：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://聚合站地址",
    "ANTHROPIC_MODEL": "项目约定的模型别名"
  }
}

要点：

• 只写项目需要的值，不要在这里写 key。key 走全局层，避免进仓库。
• 模型别名用聚合站文档里给出的名称，不要用个人习惯的叫法。
• 把该文件提交到版本控制，新人 clone 后无需再问「这个项目用哪个模型」。

这样即使两人的 shell 里 export 了不同的默认值，进入项目目录后也会被项目级配置覆盖，行为一致。

开发者 profile 层：用 shell 函数切换，而不是直接 export

不要在 .bashrc 或 .zshrc 里直接写死 export ANTHROPICBASEURL=...。改成定义一个函数，按需切换：

claude_profile() {
  case "$1" in
    work)   export ANTHROPIC_MODEL="工作用模型别名" ;;
    fast)   export ANTHROPIC_MODEL="快速模型别名" ;;
    *)      unset ANTHROPIC_MODEL ;;
  esac
}

好处是：

• 切换是显式的，不会在打开新终端时悄悄覆盖项目级配置。
• 两个人即使各自定义了同名函数，也只影响自己的 shell 会话。
• 需要回到项目默认时，直接 claude_profile 不带参数即可清空。

如果两人长期在同一个共享账号下操作同一台机器，建议进一步用 direnv 或类似的目录级环境加载工具：进入目录自动加载项目配置，离开自动卸载，比手动 export 更不容易残留。

共用 key 时的几个实践

• key 只放一处：放在系统密钥环或团队共享的密码管理器里，通过启动脚本读取，不要写进任何仓库文件。
• base URL 用项目级覆盖：个人 shell 里的默认值只是兜底，项目内配置优先。
• 模型别名集中管理：在仓库里放一份「模型别名对照表」，两人都按同一份写，减少「你那边能跑我这边报模型不存在」的情况。
• 排查顺序：先看项目级配置，再看 profile 函数，最后看全局 shell 启动脚本。大多数覆盖问题在前两层就能定位。

什么时候该拆成两个 key

共用 key 适合两人信任度高、用量不敏感的协作场景。如果出现以下情况，建议在聚合站里各开一个 key：

• 需要按人区分用量和扣费；
• 一方频繁切换模型导致另一方难以复现问题；
• 需要独立的速率或配额控制。

聚合站按官方价 ×1.3 扣费，key 的拆分不影响单价，只影响账单归属。配置分离做好之后，拆不拆 key 就只是一个管理选择，而不是技术障碍。