前阵子我把自己的终端工作流彻底重写了一遍，项目名叫 CLI-Anything。名字有点狂，但用下来是真顺手：Codex CLI 负责在仓库里跑代码任务、Claude CLI 负责多文件改造和代码解释，再配合 jq、rg 这些老伙计，我在终端里能完成绝大多数日常开发，连画架构图、整理会议纪要都开始往命令行里塞。这篇文章把整个搭建过程、选型思路、踩过的坑，以及如何在 macOS 上把 Claude CLI 切换到 Qwen key 跑起来的细节，原原本本写出来，给想折腾 CLI 工作流的朋友一份可以直接照着做的参考。
CLI-Anything 没有做成一个复杂的框架，也没有用什么花哨语言，它更像是一套方法论加一组配置的组合：把 AI 编程助手、传统命令行工具、自定义脚本串成一条流水线，让终端成为所有工作的统一入口。对于每天都在跟代码打交道的开发者、运维、技术博主来说，这套东西最大的价值不是“酷”，而是省时间——省掉反复切换窗口、复制粘贴上下文、手动跑测试这些琐碎动作。
1. CLI-Anything是什么：一次对终端工作流的彻底重构
GUI 工具越来越强，为什么还要折腾命令行？我自己的答案是：命令行是唯一一个能同时覆盖“写代码、跑代码、查资料、改配置、发消息”的地方。IDE 里也能做这些事，但每多一个操作就要多点几下鼠标，上下文一多就手忙脚乱。CLI-Anything 的核心思路就是把这些动作全部收敛到终端里，用键盘代替鼠标，用脚本代替手工。
这个项目的起因其实很朴素。有一阵子我每天要重复做几件事：拉代码、安装依赖、跑测试、看日志、改 bug、提交。每次切换都要重新打开终端窗口、cd 到对应目录、敲差不多的命令。于是我开始把所有重复动作写成脚本，慢慢凑成了一个自己的~/bin工具集。后来 AI 编程 CLI 出现了，我第一时间把它们接进这条流水线，整个工作流才真正变得“万物皆可 CLI”。
CLI-Anything 这个项目适合谁来参考？如果你每天要用终端超过一小时，或者你正在找一款趁手的 AI 编程工具却不知道 Codex CLI 和 Claude CLI 怎么选、怎么装、怎么配，这篇文章就是给你写的。我尽量把每一步都写清楚，连环境变量放哪里、报错怎么查都交代明白，保证你照着敲就能跑通。
1.1 从“一堆命令”到“一条流水线”
在把 AI CLI 加进来之前，我的终端工作流是散的：git 命令是一组，node 命令是一组，部署脚本又是一组，每组的用法都不一样，记不住。CLI-Anything 的第一件事，就是把它们统一封装。
我做了三个动作。第一，把所有常用命令写成简短的 alias，比如gs代替git status，gp代替git push，t代替npm test。第二，把多个命令串成可复用的脚本，比如new-feature这个脚本会自动创建分支、拉取最新代码、装上依赖。第三，也是最重要的一步，把 AI 编程 CLI 接到这套体系里，让自然语言也能成为“命令”。
这套流水线的效果是这样的：我写下一句话“给这个项目的 README 加上安装说明”，Claude CLI 会自动读仓库、改文件、生成 markdown；我再写“跑一下测试看看有没有挂”，Codex CLI 会替我找到测试命令并执行。命令不再是固定语法，而是可以对话的流程。
1.2 为什么选择“CLI优先”而不是“IDE插件优先”
很多 AI 编程工具是 IDE 插件形态，比如各种 AI 代码补全。我也用过，但有两个点不适应：一是插件和 IDE 深度绑定，换编辑器等于换工具；二是插件对终端的控制能力弱，我想让它“跑一下测试”还得我自己去终端敲。CLI 工具则天然没有这个问题，它在终端里运行，本身就拥有执行命令的能力。
CLI 优先还有一个隐藏优势：可脚本化。IDE 插件的操作很难自动化，但命令行工具可以被脚本调用、被 CI 集成、被 cron 定时执行。CLI-Anything 的理念就是“命令可以被组合、被自动化、被复用”，这是 GUI 工具很难做到的事情。所以我宁愿多花点时间把 CLI 环境配好，也不愿意被某个 IDE 绑架。
2. 主力AI CLI选型：Codex CLI与Claude CLI怎么搭配
CLI-Anything 里最核心的两个 AI 工具是 Codex CLI 和 Claude CLI。我要先说清楚：它们不是替代关系，而是互补关系。Codex CLI 背后的模型是 OpenAI 系列，Claude CLI 背后是 Anthropic 系列，两个工具的使用场景、交互方式、权限模型都有区别，搭配起来能覆盖更多需求。
Codex CLI 给我的感觉是“行动派”。它特别适合那种明确的任务：帮我重构这段函数、给这个模块补测试、修复这个 lint 报错。你把上下文丢给它，它会主动分析仓库、修改文件、运行命令，最后给你一个可以 review 的结果。
Claude CLI 更像是“思考派”。它处理多文件、长文本、架构级问题更稳，比如“把用户认证模块从 session 改成 JWT，涉及哪些文件、改动多大”这种活，Claude CLI 会给出一套相对完整的方案，改完的代码风格比较统一。
2.1 Codex CLI：仓库里的行动派
Codex CLI 的安装命令很简单：npm install -g @openai/codex。装完之后终端里多了一个codex命令，首次运行会进入交互式界面，可以选择用账号登录或者填 API key，然后就能开始在终端里对它发号施令。
它的工作方式我很喜欢：它会像人一样“看一眼”你的项目结构，再决定改哪里。你说“把所有 console.log 改成结构化日志”，它不会直接写死一个正则，而是先找相关文件、确认改动范围、再动手。改完还会提示你哪些地方需要人工确认。配合--dangerously-bypass-permissions这类参数，还能让它连续执行命令，适合跑批量重构任务，但新手不建议上来就开这个参数，容易把仓库改乱。
我在实际项目里用 Codex CLI 做过几次比较重的重构：把旧版接口调用全部替换成新 SDK 的写法，涉及 20 多个文件。人工改大概要一个下午，它跑一遍之后我来 review，一小时就搞定了。当然它的方案不是完美，但作为初稿足够可读。
2.2 Claude CLI：方案先行的思考派
Claude CLI 的安装同样走 npm：npm install -g @anthropic-ai/claude-code，运行命令是claude。它默认接入 Anthropic 的模型，支持在对话里指定--model切换模型版本。
Claude CLI 最突出的是“方案先行”的能力。它会先拆解任务，列出大概的改动清单，再逐步实施。比如我让它“给网关加一个限流中间件”，它会先设计方案：什么算法、配置放哪、参数命名，然后才写代码。这种风格在改复杂系统时特别省心，因为它提前暴露了设计决策，我可以直接在方案层面纠正方向，而不是等它写完一堆代码再返工。
另外，Claude CLI 对长上下文的包容性更强。把它丢进一个大型 monorepo，它能记住多文件之间的依赖关系，回答问题时不会丢三落四。我自己有一个习惯用法：让 Claude CLI 先读懂项目结构，再追问具体模块的细节。它就像团队里那个“看过所有代码”的同事，问什么都能接上。
2.3 两个工具怎么选：一张表说清楚
| 维度 | Codex CLI | Claude CLI |
|---|---|---|
| 安装命令 | npm i -g @openai/codex | npm i -g @anthropic-ai/claude-code |
| 运行入口 | codex | claude |
| 默认模型 | OpenAI 系列 | Anthropic 系列 |
| 擅长场景 | 明确任务、重构、补测试 | 方案设计、多文件改造、代码解释 |
| 上下文策略 | 偏向精准定位 | 偏向全局理解 |
| 可切换模型后端 | 支持配置 API 端点 | 支持配置 API 端点和模型名 |
从 CLI-Anything 的角度看，我不建议只装一个。日常小改动用 Codex CLI 更快，碰架构级任务就开 Claude CLI。两个工具共用一套终端环境，切换成本极低，这就是 CLI 工作流的优势。后面我会讲怎么在 macOS 上把 Claude CLI 接到 Qwen key，让模型后端有更多选择空间。
3. 安装与初始化：三步跑通两个AI CLI
这一节是纯实操。我自己是在 macOS 14 的 M2 机器上做的，Linux 环境基本一致，Windows 如果装了 WSL 也可以照做。开始之前请先确认 Node.js 环境，Codex CLI 和 Claude CLI 都依赖 Node.js 运行，建议用 LTS 版本，我在 Node 18 和 Node 20 上都跑过，没问题。
第一步检查环境：终端里执行node -v和npm -v，如果提示命令不存在，先去装 Node.js。装 Node 我推荐用 nvm，不要用系统自带的旧版本。第二步安装两个 CLI，第三步配置 PATH 和鉴定信息。三个步骤做完，你的终端就具备“AI 原住民”能力了。
3.1 安装 Codex CLI：一条 npm 命令加一个验证
Codex CLI 的安装命令非常简单，但我建议先设置 npm 镜像源，不然下载可能很慢。执行：
npm config get registry如果返回的是默认官方源，可以考虑切换到国内镜像，比如阿里云的 npm 镜像。这个操作是合规的，不涉及任何外部网络访问问题，纯粹是为了下载速度。然后执行：
npm install -g @openai/codex装完后验证：
codex --version如果能看到版本号，说明安装成功。如果提示command not found，不用慌，这是 npm 全局目录没进 PATH，我后面章节会专门讲怎么处理。
首次运行codex，它会显示一个交互式引导，让你选择登录方式。这一步在终端里直接回车选择账号认证，或者粘贴 API key 即可。登录成功之后，Codex CLI 会保存一个本地配置文件，之后使用就不需要重复登录了。
3.2 安装 Claude CLI：同样的套路再走一遍
Claude CLI 的安装几乎一样：
npm install -g @anthropic-ai/claude-code安装完成后验证：
claude --version首次运行claude，它会要求配置认证信息。如果你使用默认官方接入，需要准备 API key，或者通过官方账号登录。如果你想像我一样用 Qwen key，先不要直接运行，先去做好环境变量配置（下一章详细说），配置好了再启动claude，它会直接读取环境变量里的认证信息，不会强制走官方账号流程。
这里有一个细节：安装完 Claude CLI 之后，默认模型可能是最新版本，如果你的 Qwen 兼容接口不支持最新模型名，可以在后续启动时用--model参数临时指定。这就是 CLI 工具的好处，模型名是运行时参数，随时可以换。
3.3 全局配置与鉴权：环境变量是唯一标准
我在 macOS 上把所有 CLI 的环境变量统一放在~/.zshrc文件里。Linux 上对应的是~/.bashrc，Windows WSL 里也建议放 bash 的配置文件。我常用的环境变量是这几个：
export ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/api/v2/apps/anthropic" export ANTHROPIC_AUTH_TOKEN="sk-your-qwen-api-key" export ANTHROPIC_MODEL="qwen-max"ANTHROPIC_BASE_URL告诉 Claude CLI 把请求发到哪里，ANTHROPIC_AUTH_TOKEN是鉴权凭证，ANTHROPIC_MODEL是模型名。这三项配置好之后，Claude CLI 就不再依赖官方账号，而是走你指定的模型服务商。
配置完记得执行source ~/.zshrc让配置生效，或者重启终端。然后运行env | grep ANTHROPIC检查环境变量有没有正确加载。这一步很多人会漏掉，结果启动claude之后仍然走默认配置，然后奇怪为什么 key 不生效。
3.4 npm 全局路径问题：command not found 的根治办法
我在安装时踩过一次：明明 npm 全局包装成功了，codex和claude却提示找不到命令。原因是 npm 的全局安装目录不在 PATH 里。查看方法：
npm prefix -g这个命令会输出 npm 全局目录，正常情况下 macOS 上是/usr/local或者 nvm 管理的某个路径。如果这个路径不在你的 PATH 里，就在~/.zshrc中加一行：
export PATH="$(npm prefix -g)/bin:$PATH"加完之后重新加载配置，命令就回来了。这个坑极其常见，建议所有刚折腾 CLI 的朋友先看一眼自己全局目录在不在 PATH 里，能省掉很多排查时间。
4. macOS接入Qwen key：把Claude CLI的模型后端换掉
现在进入本文最有操作价值的部分：在 macOS 上把 Claude CLI 的模型后端切换到 Qwen，用 Qwen key 跑起来。这不仅是省账号的成本问题，更重要的是让 CLI 工作流在国内网络环境下有了一个稳定、低延迟、按量付费的模型来源。整个过程只有三步：拿到 key、配环境变量、验证对话。
我先解释一下为什么可以这样玩。Claude CLI 本身是支持自定义 API 端点的，你只要通过环境变量把ANTHROPIC_BASE_URL指到任意兼容 Anthropic 协议的接口，它就能把请求发过去。Qwen 的服务商提供了 Anthropic 兼容协议，所以两者能无缝对接。这属于 CLI 工具的正常配置能力，也是服务商公开提供的标准接口，没有什么灰色操作。
4.1 我为什么要把 CLI 换到 Qwen key
原因很简单：模型选择权。Claude CLI 是个好工具，但如果只能绑死在一个模型服务商，那这个工具的灵活性就少了一半。Qwen 系列的模型，在中文理解、代码生成、成本控制上都有不错的表现，而且国内访问速度非常快，适配国产模型是很多开发者的真实需求，完全不涉及任何不确定内容。
在实际项目中，我用 Qwen 的模型跑过代码审查、文档生成、测试用例补全，效果完全可以接受。尤其在中英文混合的任务里，它的中文表达比一些国外模型更自然，生成的注释和文档更像是中文团队写的，而不是翻译腔。
4.2 获取Qwen key：控制台三步拿到密钥
第一步，打开阿里云百炼控制台，开通 DashScope 服务。第二步，在控制台左侧找到 API-KEY 管理，创建一个新的 API key，生成一串以sk-开头的密钥。第三步，把 key 复制下来，临时放在一个安全的地方。
拿到 key 之后，还要在控制台查一下你要用的模型名。Qwen 系列的模型名通常是qwen-max、qwen-plus、qwen-turbo这类，不同区域可能略有差异，以控制台展示为准。这一步很重要，因为如果你的模型名写错了，Claude CLI 启动后会报模型找不到的错误。
4.3 配置环境变量：三行命令完成切换
打开~/.zshrc，把前面说的三个环境变量加进去，注意替换成你自己的 key：
export ANTHROPIC_BASE_URL="https://dashscope.aliyuncs.com/api/v2/apps/anthropic" export ANTHROPIC_AUTH_TOKEN="sk-your-qwen-api-key" export ANTHROPIC_MODEL="qwen-max"保存后执行：
source ~/.zshrc然后验证：
env | grep ANTHROPIC看到三个环境变量都输出了，说明切换已完成。接下来启动 Claude CLI：
claude如果配置没问题，它会直接进入对话界面，不会要求你登录官方账号。我建议第一句话不要问太复杂的问题，先让它“用一句话介绍一下你自己”，确认它用的是 Qwen 模型即可。
4.4 一个小坑：鉴权字段与模型名
我第一次配置时，把鉴权字段写成了ANTHROPIC_API_KEY，结果一直返回 401 鉴权失败。这就是我前面强调ANTHROPIC_AUTH_TOKEN的原因。Claude CLI 对不同的鉴权环境变量支持优先级不一样，使用兼容接口时，ANTHROPIC_AUTH_TOKEN是更稳的选择。
另外，模型名别带多余前缀。有朋友把qwen-max写成了dashscope/qwen-max，结果接口返回model not found。直接填控制台上显示的模型 ID 就好，不要自己脑补前缀。
5. 终端实战：让CLI读代码、改代码、替你跑命令
配置好环境，CLI-Anything 才真正开始发挥作用。这一章我不聊理论，直接展示我在日常开发里高频使用的几个实战场景，每一个都是真实跑过、反复调教过的用法。
先说读代码。拿到一个不熟悉的老项目，我现在的习惯不是从头翻文件，而是直接开 Claude CLI，让它“先读一遍 src 目录，告诉我这个项目是干什么的、模块之间怎么依赖”。它会快速扫完文件，给我一个结构化概览，比人肉翻快太多。
再说改代码。Codex CLI 在这个场景更顺。我会把需求写成一句明确的话，比如“把 utils/date.js 里的所有日期格式化函数改成 dayjs 实现”，它会在仓库里定位相关调用、完成替换、跑测试，最后把 diff 列出来给我看。
5.1 用自然语言指挥CLI读代码
读代码是 AI CLI 最被低估的能力。以前我接手一个 Python 后端项目，光理清路由和数据库表的关系就花了两天。后来我用 Claude CLI，让它从入口文件开始，一层层往下追踪，最后把它对系统架构的理解画成文字描述输出。
我给的指令模板大概是这样的：“你是这个仓库的资深维护者，请按以下顺序分析：入口文件、路由注册、数据库模型、中间件、异常处理。输出一段适合新人的架构说明。”Claude CLI 的输出质量很高，因为它真的读了文件，而不是凭经验猜。我自己再用rg去抽查几个关键点，确认没有理解偏差。
这个场景的关键是任务拆得足够小。不要一上来就“给我解释整个项目”，那是很耗上下文的任务。拆成“先看入口，再看路由，最后看模型”的三轮对话，效果会好很多。
5.2 用CLI批量改代码，然后人工review
批量改代码是 Codex CLI 的保留节目。我最近做过一次全仓库的“旧的 mock 函数替换成新 mock 框架”，涉及 40 多个测试文件。手动改至少要一天，而且容易遗漏。
我的做法是先在仓库里跑一遍搜索，确认边界：
rg "oldMock" --count | sort把统计结果丢给 Codex CLI，然后说：“按这个范围，把 oldMock 替换成 newMock，保持测试逻辑不变。只改测试文件，不改生产代码。”它会逐个文件处理。改完之后，我不会直接信任结果，而是用git diff过一遍关键文件，再跑一轮全量测试。实测下来，它的替换准确率比我预期的高，但“上下文无关的误伤”还是会有，所以 human review 不能省。
5.3 传统CLI与AI CLI协同工作流
CLI-Anything 的终极形态，是让传统命令和 AI 命令互相协作。比如我用jq从日志里筛出错误信息，把信息导出到文件，再用 Claude CLI 分析这段日志、列出异常模式；我用rg找到所有待办的 TODO 注释，丢给 Codex CLI 让它批量生成对应的 issue 草稿。
我分享一个具体的组合操作。排查线上问题的时候，通常要先看日志。我执行：
tail -n 1000 app.log | rg "ERROR|Exception" > errors.txt然后用 Claude CLI：
claude < errors.txt让它在同一个终端会话里读取文件内容、分析错误链路、给出排查建议。整个过程不用离开终端，也不用复制粘贴大段日志，体验非常顺。这种组合拳才是 CLI-Anything 的价值所在：它不只是一堆工具，而是一套能互相调用的工作流。
6. 高频报错排查：codex binary缺失、鉴权失败全记录
CLI 工具配置过程中难免踩坑。我把自己遇到过的、以及从网友反馈中高频出现的几类问题整理出来，做成一份可以直接对照的排查表。这些问题都不复杂，但第一次遇到时确实会卡住。
其中最典型的报错是unable to locate the codex cli binary or required runtime components. check your installation。这个名字很唬人，看起来很底层，其实绝大多数情况跟“路径”有关，或者跟安装完整性有关。下面我逐个拆。
6.1 经典报错：unable to locate the codex cli binary 排查实录
这个报错我第一次遇到是在 IDE 插件里调用 Codex CLI 时，明明终端里codex --version能用，插件却告诉我找不到二进制。后来我明白了：IDE 启动时不会加载 shell 的 PATH，它拿着自己那份精简环境去找 codex，找不到就炸了。
排查分三层。第一层看终端能不能跑：
codex --version如果终端也找不到，是 PATH 问题，按 3.4 节处理。第二层如果终端正常但插件报错，在 IDE 的设置里把 PATH 环境变量补上，尤其是 npm global bin 的路径。第三层如果路径都对，重新安装一次组件：
npm uninstall -g @openai/codex npm install -g @openai/codex重装能解决大部分“装了一半、二进制缺失”的情况。还不行的话，清一下 npm 缓存再装。
6.2 command not found：npm全局目录没进PATH
codex或claude安装成功但命令找不到，根因就是 npm 全局目录不在 PATH。我用npm prefix -g查出全局目录，发现是某个 nvm 路径，而默认 shell 没有把它加进去。解决方式：
export PATH="$(npm prefix -g)/bin:$PATH"建议把这一行固化到~/.zshrc里，不要每次都在终端临时执行。我在 3.4 节已经详细写过，这里再强调一遍，因为它实在太高频了。另外注意，如果你用了 nvm，PATH 的顺序很重要，确保 npm 全局 bin 在 PATH 前面。
6.3 鉴权失败 401 与模型找不到 model not found
鉴权 401 的原因一般是环境变量用错了。Claude CLI 兼容接口推荐ANTHROPIC_AUTH_TOKEN，我见过很多人用ANTHROPIC_API_KEY配置，结果一直 401。另外还要检查 key 前后有没有多余空格，source之后有没有真的生效。
模型找不到的报错，一般是ANTHROPIC_MODEL填错。不要在模型名前加服务商前缀，直接填控制台显示的模型 ID。我用过的qwen-max、qwen-plus都能正常识别，有些更小的模型名如果接口不支持，报错的提示信息里会列出当前服务商支持的模型列表，照抄就行。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
command not found | npm 全局目录不在 PATH | 执行npm prefix -g，把 bin 目录加入 PATH |
unable to locate the codex cli binary | 安装不完整或 IDE 环境缺 PATH | 重装包，或在 IDE 设置里补 PATH |
| 401 鉴权失败 | 环境变量名不对或 key 错误 | 改用ANTHROPIC_AUTH_TOKEN，检查 key 前后空格 |
model not found | 模型名填错 | 去掉前缀，按控制台显示的模型 ID 填写 |
| 请求超时 | 基础网络或服务商限流 | 检查网络连通性，换个低峰时段再试 |
7. 我的CLI-Anything小技巧与经验总结
折腾这么一套 CLI 工作流，我最大的心得是：不要把配置一步到位，而是让这套体系跟着你的需求自然生长。CLI-Anything 这个名字听起来很大，但它真正落地的时候，其实就是几个顺手的小脚本、几条环境变量、两个 AI 工具。
我想分享三个比较私人的小技巧。第一个是将常用 AI 指令封装成函数，比如我在~/.zshrc里定义了一个explain函数，接收参数后自动让 Claude CLI 解释一段代码：
explain() { echo "请解释以下代码的作用和潜在问题，尽量详细：" > /tmp/prompt.txt cat "$1" >> /tmp/prompt.txt claude < /tmp/prompt.txt }以后只要输入explain src/utils.js，它就会自动读文件并解释，不用每次都手动描述任务。
第二个技巧维护一份自己的 CLI 命令速查表。我不追求记住所有命令，把常用的 alias、入口、环境变量写在一个 markdown 文件里，放在~/cli-anything/cheatsheet.md。这样即使三个月不用某个工具，翻一下就能快速找回上下文。
第三个技巧是给 CLI 命令设计“安全网”。任何涉及批量修改、自动执行的命令，我都在前面加一个检查动作，比如先用git diff --stat看改动范围，或者先--dry-run跑一遍。AI CLI 再聪明也是工具，代码仓库是你自己的，出了问题还是要自己承担。
最后再分享一个关于模型切换的经验。CLI-Anything 让我最满意的，不是某个模型多厉害，而是“随时能换模型”的自由。今天用 Qwen 做中文项目，明天切回官方模型做长文本设计，底层的 CLI 工具不变，变的只是环境变量。这种模块化、可插拔的思维方式，才是命令行工作流真正值得借鉴的地方。你把工具真正握在手里，而不是被工具束缚住，这就是 CLI-Anything 带给我最大的收获。
