1. 项目概述为什么我们需要一个AI代码助手的配置切换工具如果你和我一样日常开发重度依赖Claude Code这类AI代码助手那你一定遇到过这个场景早上在公司电脑上用的是公司的API密钥和项目配置处理内部代码库晚上回到家想用自己的个人账号和配置在开源项目上练练手或者搞点个人小项目。每次切换都得手动去改环境变量、配置文件甚至重新登录麻烦不说还容易搞混一不小心用公司密钥提交了个人代码那可就尴尬了。ccuse这个工具就是为了解决这个痛点而生的。它的名字很直白就是“Claude Code Use”的缩写核心功能就是一个命令行工具让你能像nvm切换Node.js版本、或者conda切换Python环境一样快速、无缝地在不同的Claude Code配置集之间切换。这里的“配置”是一个集合概念不仅仅是一个API密钥它可能包括API端点/Base URL你可能在使用官方服务也可能部署了自托管服务。API密钥/Token不同账号、不同用途的密钥。模型偏好是优先使用claude-3-5-sonnet追求极致代码能力还是用claude-3-haiku追求响应速度和省钱。项目上下文路径为特定项目设置的默认工作目录或上下文文件。代理设置网络环境不同时所需的HTTP代理配置。其他任何与Claude Code CLI相关的环境变量或启动参数。在没有ccuse之前管理这些配置要么靠手动记忆和修改要么写一堆零散的shell脚本别名alias既混乱又难以维护。ccuse将这些配置标准化、命名化、持久化通过一个简单的命令比如ccuse work或ccuse personal就能完成整个开发上下文的切换这才是现代开发者该有的效率工具。2. 核心设计思路像管理多版本环境一样管理AI助手配置2.1 核心需求解析设计这样一个工具首先要明确它需要满足哪些核心需求。从我自己的使用经历和社区讨论来看主要有以下几点隔离性不同配置如工作、个人、测试必须完全隔离互不干扰。激活一个配置时其他配置应完全不可见避免密钥泄露或配置污染。便捷性切换操作必须极其简单最好是一两个命令就能完成并且能快速查看当前状态。持久化配置需要保存下来下次开机或打开新终端依然有效无需重复设置。可移植性配置最好能导出、导入方便在团队间共享基础配置或者在新机器上快速搭建环境。低侵入性工具本身不应该修改Claude Code CLI的核心逻辑或全局环境它应该是一个“包装器”或“管理器”通过控制环境变量和启动参数来生效。2.2 技术方案选型为什么是Shell脚本目录管理市面上已经有很多优秀的配置管理工具比如direnv管理目录级环境变量asdf管理多语言运行时。ccuse的灵感来源于它们但更专注。在技术实现上它选择了最经典也最可靠的组合Shell脚本 文件系统目录管理。为什么用Shell脚本因为配置切换的本质就是操作环境变量和进程上下文这是Shell的天然主场。用Python或Go写当然可以但会引入额外的运行时依赖。一个纯粹的Bash/Zsh脚本在任何Unix-like系统上开箱即用启动速度也最快。对于这样一个需要深度集成到Shell环境中的工具来说原生Shell脚本是最轻量、最直接的选择。为什么用目录管理每个配置集Profile用一个独立的目录来存放是最清晰、最灵活的方式。目录里可以放置env.sh专门存放需要导出的环境变量如ANTHROPIC_API_KEY,CLAUDE_BASE_URL等。config.json存放Claude Code CLI本身的配置文件如果支持的话。init.sh切换到此配置时需要执行的一些初始化脚本比如cd到特定项目目录。README.md记录此配置的用途和注意事项。 这种目录结构一目了然也方便用Git进行版本管理。注意这里有一个关键设计决策即工具不存储明文API密钥。更安全的做法是env.sh中存储的是从系统密钥管理器如macOS的Keychain、Linux的secret-tool读取密钥的命令或者提示用户交互式输入。ccuse只管理配置的“框架”和“指针”敏感信息由更专业的系统工具管理。2.3 工作流程抽象ccuse的核心工作流程可以抽象为以下几步配置创建/编辑用户通过ccuse create profile_name或ccuse edit profile_name来定义一个新的配置集工具会引导用户填写或编辑相关参数并生成对应的配置目录和文件。配置切换用户执行ccuse use profile_name。工具会 a. 记录当前配置以便后续切换回来。 b. 清理当前Shell会话中与旧配置相关的环境变量。 c. 加载目标配置目录下的env.sh等文件将新的环境变量注入当前Shell。 d. 执行目标配置的init.sh如果存在完成特定初始化。状态查看与管理ccuse list查看所有可用配置ccuse current显示当前激活的配置ccuse delete删除配置。这个流程清晰地将配置的存储、加载、应用解耦使得工具本身保持简单和稳定。3. 手把手实现从零构建一个可用的ccuse原型理解了设计思路我们来实现一个最小可行版本。这个版本将包含核心的use,list,create功能。3.1 环境准备与工具结构首先我们决定将ccuse安装在用户的~/.local/bin目录下确保该目录在PATH环境变量中所有配置存储在~/.config/ccuse/profiles/目录下。#!/bin/bash # 文件: ccuse (无后缀赋予可执行权限后可直接执行) CCUSE_HOME${HOME}/.config/ccuse CCUSE_PROFILES_DIR${CCUSE_HOME}/profiles CCUSE_CURRENT_FILE${CCUSE_HOME}/current_profile # 确保目录存在 mkdir -p $CCUSE_PROFILES_DIR3.2 核心功能实现配置切换 (use)这是最核心的功能。其关键在于在当前Shell进程中“Source”配置文件。子Shell无法修改父Shell的环境因此我们必须用.或source命令来执行。function _ccuse_use() { local profile_name$1 local profile_dir${CCUSE_PROFILES_DIR}/${profile_name} if [[ ! -d $profile_dir ]]; then echo 错误配置 $profile_name 不存在。 echo 使用 ccuse list 查看所有可用配置。 return 1 fi local env_file${profile_dir}/env.sh # 1. 取消可能存在的旧配置环境变量可选更安全 # 这里简单起见我们假设新的env.sh会覆盖旧变量。更严谨的做法是记录并unset旧变量。 # 2. 加载新配置的环境变量 if [[ -f $env_file ]]; then # 使用 source 命令在当前shell执行脚本 source $env_file echo 已加载配置 $profile_name 的环境变量。 else echo 警告配置 $profile_name 不存在 env.sh 文件。 fi # 3. 执行初始化脚本 local init_file${profile_dir}/init.sh if [[ -f $init_file ]]; then source $init_file fi # 4. 记录当前激活的配置名 echo $profile_name $CCUSE_CURRENT_FILE echo 已切换到配置$profile_name }关键点解释source “$env_file”这是灵魂命令。它使得env.sh中定义的export ANTHROPIC_API_KEYsk-xxx直接在当前的Shell会话中生效。后续启动的Claude Code CLI进程会继承这些环境变量。为什么不用bash env.sh如果这样执行env.sh会在一个全新的子Shell进程中运行其设置的变量在子进程结束后就消失了父Shell你的终端完全感知不到切换失败。将当前配置名写入CCUSE_CURRENT_FILE是为了实现ccuse current功能并可能在下次打开终端时自动恢复上次的配置需在Shell启动脚本如.zshrc中做判断和加载。3.3 配置创建 (create) 与列表 (list)创建功能需要引导用户输入并生成模板文件。function _ccuse_create() { local profile_name$1 local profile_dir${CCUSE_PROFILES_DIR}/${profile_name} if [[ -d $profile_dir ]]; then echo 错误配置 $profile_name 已存在。 return 1 fi mkdir -p $profile_dir # 交互式收集信息 echo 正在创建配置: $profile_name read -p 请输入 ANTHROPIC_API_KEY (输入跳过): api_key read -p 请输入 Claude API BASE_URL [默认: https://api.anthropic.com]: base_url base_url${base_url:-https://api.anthropic.com} read -p 请输入默认模型 [例如: claude-3-5-sonnet-20241022]: model model${model:-claude-3-5-sonnet-20241022} # 生成 env.sh cat ${profile_dir}/env.sh EOF #!/bin/bash # 由 ccuse 自动生成的配置: $profile_name # $(date) # 核心API配置 export ANTHROPIC_API_KEY${api_key} export CLAUDE_BASE_URL${base_url} export CLAUDE_DEFAULT_MODEL${model} # 你可以在此添加其他任何Claude Code CLI支持的环境变量 # export HTTP_PROXYhttp://your-proxy:port # export HTTPS_PROXYhttp://your-proxy:port # export NO_PROXYlocalhost,127.0.0.1 echo 环境变量已设置 (来自配置: $profile_name)。 EOF # 生成一个空的 init.sh 模板 cat ${profile_dir}/init.sh EOF #!/bin/bash # 切换到该配置时自动执行的脚本 # 例如 cd ~/projects/my-work-project # 或者 echo 欢迎使用工作配置 EOF chmod x ${profile_dir}/env.sh ${profile_dir}/init.sh echo 配置 $profile_name 创建成功 echo 你可以编辑 ${profile_dir}/ 下的文件进行更详细的定制。 }列表功能就很简单了function _ccuse_list() { echo 可用的 ccuse 配置 echo ------------------- for profile in ${CCUSE_PROFILES_DIR}/*; do if [[ -d $profile ]]; then local name$(basename $profile) local current_marker if [[ -f $CCUSE_CURRENT_FILE ]] [[ $(cat $CCUSE_CURRENT_FILE) $name ]]; then current_marker (当前使用) fi echo - ${name}${current_marker} fi done }3.4 主函数与命令分发最后我们需要一个主函数来解析用户输入的命令。function main() { local command$1 local profile_name$2 case $command in use) if [[ -z $profile_name ]]; then echo 用法: ccuse use 配置名 return 1 fi _ccuse_use $profile_name ;; create) if [[ -z $profile_name ]]; then echo 用法: ccuse create 配置名 return 1 fi _ccuse_create $profile_name ;; list) _ccuse_list ;; current) if [[ -f $CCUSE_CURRENT_FILE ]]; then echo 当前配置: $(cat $CCUSE_CURRENT_FILE) else echo 当前未激活任何配置。 fi ;; *) echo ccuse - Claude Code CLI 配置切换工具 echo echo 用法: echo ccuse use 配置名 切换到指定配置 echo ccuse create 配置名 交互式创建新配置 echo ccuse list 列出所有配置 echo ccuse current 显示当前配置 echo echo 示例: echo ccuse create work echo ccuse use work ;; esac } # 执行主函数 main $将以上所有代码块按顺序组合成一个完整的脚本文件保存为ccuse并赋予执行权限chmod x ccuse然后移动到~/.local/bin/。现在你就可以在终端里使用ccuse命令了。4. 高级用法与生产环境增强上面的原型已经能用但离一个健壮的生产级工具还有距离。下面分享几个我在实际使用和增强过程中总结的要点。4.1 安全增强密钥管理明文存储API密钥在env.sh里是极不安全的。我们可以集成系统密钥链。macOS (Keychain):# 在 create 命令中不再询问密钥而是引导用户存入钥匙串 # 假设使用 security 命令 security add-generic-password -a ${USER} -s ccuse_${profile_name}_api_key -w ${api_key_input} -T “” # 在 env.sh 中改为从钥匙串读取 export ANTHROPIC_API_KEY$(security find-generic-password -a ${USER} -s ccuse_${profile_name}_api_key -w)Linux (libsecret/gnome-keyring): 可以使用secret-tool命令进行类似操作。这样配置文件里只有读取命令真正的密钥存储在系统加密的仓库中。4.2 Shell集成实现目录自动切换一个非常实用的功能是当进入某个项目目录时自动切换到对应的ccuse配置。这需要结合Shell的钩子函数Hook比如Zsh的chpwd或Bash的PROMPT_COMMAND。在你的~/.zshrc中可以添加function auto_ccuse() { local dir$(pwd) # 检查当前目录或其父目录是否有 .ccuse-profile 文件 local profile_file$(find $dir -maxdepth 2 -name .ccuse-profile | head -n 1) if [[ -n $profile_file ]]; then local profile_name$(cat $profile_file) # 避免重复切换 if [[ -f ${HOME}/.config/ccuse/current_profile ]] [[ $(cat ~/.config/ccuse/current_profile) ! $profile_name ]]; then ccuse use $profile_name /dev/null 21 # 可以设置一个标志避免每次提示只在真正切换时提示 echo [ccuse] 已根据项目自动切换到配置: $profile_name fi fi } # Zsh: 每次目录变化时触发 autoload -U add-zsh-hook add-zsh-hook chpwd auto_ccuse # 启动时也执行一次 auto_ccuse然后在你的工作项目根目录创建一个.ccuse-profile文件里面只写一行配置名如work。这样只要你cd到这个项目就会自动切换到工作配置。4.3 配置的版本控制与共享~/.config/ccuse/profiles/目录下的每个配置文件夹都是独立的。你可以将某个配置文件夹如team-base初始化成一个Git仓库里面存放不包含敏感信息的模板env.sh.template、公共的init.sh脚本用于安装公共依赖等。团队成员克隆这个仓库到自己的profiles目录下然后根据模板填写自己的私有信息如个人API密钥路径。这实现了团队开发环境的标准化。4.4 与Claude Code CLI深度集成ccuse目前主要管理环境变量。如果Claude Code CLI支持配置文件如~/.claude-code/config.json我们还可以在ccuse use时动态创建或链接该配置文件。# 在 _ccuse_use 函数中增加 local claude_config_link${HOME}/.claude-code/config.json local profile_config${profile_dir}/config.json if [[ -f $profile_config ]]; then ln -sf $profile_config $claude_config_link fi这样模型偏好、主题设置等也可以通过ccuse来管理了。5. 常见问题与排查技巧实录在实际使用和分享给同事的过程中我遇到了不少问题。这里记录下最典型的几个及其解决方法。5.1 问题切换配置后启动Claude Code CLI依然提示“未设置API密钥”现象执行ccuse use work成功但运行claude-code命令时仍报错。排查首先运行echo $ANTHROPIC_API_KEY看看环境变量是否真的设置成功了。如果为空说明source过程可能有问题。检查ccuse use命令是否是在当前Shell终端中执行的。如果你是在脚本中调用ccuse或者通过某种方式启动了一个子Shell那么环境变量只在该子Shell中有效。检查env.sh文件的语法确保是export KEYvalue格式并且没有语法错误。可以在文件开头加set -e或者手动source一下看有无报错。解决99%的情况都是因为在子Shell中执行。确保你是在交互式终端里直接运行ccuse命令。对于IDE内置终端可能需要重启IDE的终端会话才能加载新的环境变量。5.2 问题配置太多忘记某个配置是干什么用的现象ccuse list出来一堆名字时间久了分不清project-a和project-a-legacy的区别。解决这是设计时可以优化的点。我们可以在创建配置时增加一个description字段并保存在配置目录的.meta文件里。然后增强ccuse list命令使其显示描述。# 在 _ccuse_list 函数中改进 for profile in ${CCUSE_PROFILES_DIR}/*; do if [[ -d $profile ]]; then local name$(basename $profile) local desc if [[ -f ${profile}/.meta ]]; then desc$(grep ^description ${profile}/.meta | cut -d -f2-) fi printf %-20s %s\n $name $desc fi done5.3 问题在脚本中无法使用ccuse切换环境现象想在CI/CD流水线或者自动化脚本中根据不同的任务切换不同的Claude配置但发现不行。根源Shell脚本执行时source命令只影响它所在的Shell进程。自动化脚本通常是一个独立的进程切换配置无法影响调用它的父进程如Jenkins Agent。解决思路对于自动化场景ccuse应该提供一个“导出”功能生成一个包含所有环境变量设置的命令片段供脚本eval执行。function _ccuse_export() { local profile_name$1 local profile_dir${CCUSE_PROFILES_DIR}/${profile_name} local env_file${profile_dir}/env.sh # 将env.sh中的export语句原样输出而不是执行 sed -n /^export/p $env_file }在脚本中这样使用eval $(ccuse export work)。这样环境变量就在脚本所在的Shell进程中生效了。5.4 问题配置删除后残留的环境变量现象用ccuse use A切换后再ccuse delete A然后创建新的ccuse use B发现某些旧变量还在。原因我们的简单实现只是source了新配置的env.sh它用新值覆盖了旧变量。但如果旧配置设置了一个变量X而新配置的env.sh里根本没有这个变量X那么X就会一直残留。解决在_ccuse_use函数中需要先“清理”环境。我们可以约定所有由ccuse管理的变量都加上一个统一的前缀比如CCUSE_或者更简单点在每次切换时先unset掉已知的可能由Claude设置的所有变量名。但这并不完美因为变量名可能变化。更工程化的做法是在激活一个配置时记录下它设置的所有变量名在切换前根据记录进行清理。这增加了复杂度但对于追求干净环境的用户是值得的。最后我想说的是ccuse这类工具的价值不在于它用了多炫酷的技术而在于它精准地解决了一个具体、高频的痛点。它的实现过程也是对一个好的CLI工具设计的思考如何定义清晰的边界、如何设计直观的交互、如何处理持久化状态、如何兼顾安全与便利。当你自己动手实现一遍哪怕只是一个原型你对工具链的理解也会深刻得多。
