1. 先把 Codex CLI 跑起来安装、更新与 PATH 问题Codex CLI 是这两年命令行 AI 开发工具里出镜率最高的一类终端编程代理它的交互式 REPL 里藏着一整套以斜杠开头的控制命令也就是常说的「/斜杠命令」。很多人第一次接触时会以为斜杠命令只是“用来退出的按钮”实际上它才是会话的驾驶舱。你在终端敲下codex进入交互模式后所有对话、文件操作、命令审批都发生在这个 REPL 里而管理这一切的入口就是那一排/\*\*命令。现实很骨感很多人的第一道坎并不是斜杠命令记不住而是根本进不了这个界面。网上反复出现的报错unable to locate the codex cli binary or required runtime components. check that codex is installed and accessible in your PATH几乎成了新手区热门问题。这个错误的根因多半不是 Codex 没装上而是调用它的那个进程找不到二进制文件。尤其当你在 VS Code 插件、Continue、Cline 这类编辑器集成工具中使用 Codex 时编辑器进程继承的环境变量和你终端里.bashrc文件里手工 export 的 PATH 常常不是同一套。1.1 安装与登录的路径选择安装 Codex CLI 本身并不复杂最常见的系统化安装方式是 npm 全局安装npm install -g openai/codex如果本地已经装过旧版本更新时建议直接指定最新标签避免本地缓存带来版本混乱npm install -g openai/codexlatest也有不少用户通过 Homebrew 等系统包管理方式安装。但无论你用哪种方式装完第一件事不是立刻启动codex而是验证二进制位置与版本which codex codex --version没有输出或者提示 command not found十有八九是 PATH 没包含 npm 或包管理器的全局 bin 目录。Windows 用户可以在 PowerShell 里查看 npm 全局路径找到后手动追加到环境变量Ubuntu 用户如果用了 nvm容易被“终端重启后 nvm 未加载、Node 全局路径失联”的问题卡住。我记得第一次在 Ubuntu 下装好 Codex打开新终端发现codex不见了折腾半天才意识到是~/.bashrc里少了 nvm 的初始化语句。后来我在配置文件里显式把 npm 全局 bin 目录写进 PATH再source一遍问题才算根治。登录是另一个容易忽略但影响很大的环节。Codex CLI 支持 ChatGPT 账号登录也支持 OpenAPI 密钥方式鉴权。个人写代码、做项目原型登录账号最省事团队里要按量计费、做自动化流水线API 密钥方式更可控。无论选择哪种方式都必须先完成认证再进入交互模式否则会话一开始就报鉴权错误后续所有斜杠命令都无从谈起。1.2 不同系统下“找不到二进制”的排查链路如果你在终端直接运行codex没问题但在 IDE 里看到那行 “unable to locate the codex cli binary” 报错先别急着重装。保持镇定按这条链路排查通常几分钟就能定位在终端执行which codex拿到二进制绝对路径。打开 IDE 或插件的设置看有无 codex 可执行文件路径的配置项有就填绝对路径。如果没有路径配置就把二进制所在目录写入系统级 PATH注意是“系统级”而不是某个 shell 的 rc 文件因为 GUI 应用加载环境变量的方式比你想象得保守。重启 IDE让进程重新读取环境变量。再跑一次codex --version确认二进制可达且版本正确。很多人栽在“系统级 PATH”这一步。比如 macOS 上通过 nvm 安装 Nodecodex通常位于 nvm 的版本目录下而 Finder 启动的 VS Code 根本不会读取 nvm 注入的那段 PATH所以终端里正常、编辑器里找不到就是情理之中的事。Windows 也有类似情况cmd 里正常代表不了 VS Code 一定继承同一份 PATH特别是通过管理员方式安装的全局包普通权限进程未必能访问同样的 bin 目录。还有个小操作很容易被忽略更新 Codex CLI 后跑一次codex install。这个命令会重新生成 shell hooks 等辅助文件。如果不做旧版本的启动脚本可能还指向旧二进制甚至出现“版本号看着更新了、行为完全没变”的假象。2. 斜杠命令全景一条命令读懂整个控制面板斜杠命令的本质是交互式 REPL 里以/开头的控制指令。它跟普通提问有本质区别普通文本是发给模型的内容斜杠命令是发给客户端程序本身的操作指令。打个比方你在微信里发“帮我看看明天的天气”是发给 AI 的消息但你点“发送”按钮触发的是微信客户端的功能。斜杠命令就是 Codex CLI 里的“发送按钮”只不过按钮多了几十个。2.1 命令为什么需要一个“前向斜杠”用斜杠作为命令前缀有个很实际的好处正常代码讨论里它天然不会成为行首第一个字符。你可能会说“请把路径改为 /var/log/nginx/access.log”但这句话里的/在句子中段不是行首。CLI 因此能用一个简单可靠的判断规则来区分“这是命令”还是“这是给 AI 的消息”看这一行的第一个字符是不是/。Codex CLI 在读取输入时会把独立成行的、以斜杠开头的输入识别为命令。这里有个细节如果你正在粘贴代码代码块里某一行是以/开头的REPL 不一定把它当作命令因为命令识别通常按输入流中的行首处理。所以不用太担心/etc、/usr这类路径被误判成命令只要它不是当前输入那行的第一个 token 就行。2.2 高频斜杠命令速查表我日常在交互模式里实际用到的命令基本集中在下面这些。不同版本的 Codex CLI 对命令支持会有细微差别最稳妥的判断方式永远是进入会话后执行/help以当前版本实际输出为准。命令作用通俗解释/help列出所有可用命令与快捷键说明相当于终端的 man 手册随时可看/new清空当前会话上下文开启新对话换任务刷新脑子旧对话内容不再影响新任务/redo不重复应用已有文件改动重新执行上一个请求模型干砸了但你又不想重新描述一遍需求/undo回滚最近一次生成对工作区文件的改动手滑后的后悔药/status展示工作目录、git 分支、当前模型、审批状态先看仪表盘再开车/model弹出模型选择菜单同一道菜换不同厨师/switch切换工作根目录或项目从项目 A 跑到项目 B/agents切换不同的代理配置或运行模式换一种干活的风格/approvals查看待批准的文件改动并逐条处理把改动摆上桌你点头才算数/config查看或临时覆盖当前配置项临时调参数不用退出重来/quit正常结束会话关店打烊这张表差不多就是 Codex CLI 交互模式的“主干控制面板”。每个命令背后都有各自的适用边界用对了效率起飞用错了反而破坏工作区。2.3 一行的规则命令解析、输入与多行消息有经验的用户会注意到斜杠命令的解析和普通聊天输入并不在一条路径上。REPL 会把输入先做一个“是否为控制指令”的判定是则进入命令处理器否则才进入模型调用管线。这也意味着一部分命令支持追加参数。例如某些版本里/model可以直接在命令后指定模型名/new后面也可以带项目路径作为初始上下文。但要注意“一行一条”原则。别试图把/new和/undo写在同一行处理。斜杠命令一旦被执行当前输入框里尚未提交的内容会被丢弃。你如果想先告诉模型“把刚才的修改撤销掉”那就好好输入自然语言消息而不是把它和/undo混在同一行。混写的结果通常只有命令被识别那句自然语言根本没到模型那里。对于多行消息还有个容易踩的坑粘贴代码进入输入框时如果整段内容里的某一行恰好以/开头虽然理论上不会误触发但我个人仍倾向先把长代码存成文件再在对话里引用文件路径。这样不仅避免命令误判风险还能让模型拿到完整上下文而不是被终端换行截断的残片。3. 会话控制类/new、/redo、/undo 和 /quit 的边界会话控制类斜杠命令是使用频率最高的一批同时也是误解最多的一批。很多人把它们当成通用聊天窗口按钮来用但实际上它们操作的对象不同有的是清理上下文有的是重建工作区有的是终止进程。看清这些边界才不至于在模型输出一团乱麻时越操作越乱。3.1 /new 清理的是上下文不是磁盘/new的作用是开始一段新对话。从实现角度看它清空的是当前会话积累的上下文历史包括之前的用户消息、助手回复、工具调用记录以及这些消息中获得的临时状态。它不会去动磁盘上已有的文件。你执行/new之后工作目录里的代码、git 分支、未提交改动都还在只是 AI 不再记得刚才聊过什么。这个边界很重要。很多用户看到模型一直沿用上一个任务的错误思路下意识想用/new来“清掉错误状态”。敲完/new模型是恢复正常了但你以为上一轮的修改也被清掉——其实没有。文件改动仍然保留在磁盘上只是新会话不再把上一轮的错误结论当作事实基础。如果你的目标是彻底重置物理环境比如让工作区回到某个 commit你应该用 git 命令而不是/new。/new只负责“清空大脑”。那什么时候用/new我的习惯是在开始一个新任务时使用尤其是任务和上一个任务没有关系或者上一个任务已经在工作区留下大量模型生成的中间产物时。先/new再描述新需求能避免模型被旧任务的“思路惯性”带偏。3.2 /redo 与 /undo 的互补逻辑/redo和/undo看起来是一对对称命令实际上功能完全两个方向。/undo处理的是文件系统层面它把最近一次模型回合造成的文件改动尽力回滚相当于在磁盘上做一次增量级别的后悔撤销。实现方式通常依赖 git 的索引和工作树状态对比Codex CLI 会记录每个模型回合执行前后工作区的 diff再基于 diff 反向操作。所以/undo并不是万能的。对于未跟踪的新文件、被删除后又重新创建的路径、以及模型直接修改但最终没被记录进 diff 的文件/undo的恢复能力有限。/redo处理的是对话生成层面它会基于当前上下文重新运行上一轮的任务请求而不是简单地把上一轮生成的编辑重新应用一遍。我实际用下来的感受是/redo是在已有对话上下文的基础上重新发起一次生成让模型“再回答一遍刚才的问题”。如果你刚执行过/undo那redo重新运行任务时工作区已经回到相对干净的状态模型不会再沿用上一轮已落盘的错误改动从而有机会产出干净的新结果。所以/redo和/undo更像是一套组合拳模型把代码改坏了先/undo把工作区恢复再用/redo让模型重新思考一次同样的需求如果还是不对就换模型或者补充上下文。这套流程比反复发“重新生成一遍”要高效得多因为/redo不需要重新解释需求模型仍然记得任务的来龙去脉。3.3 收尾别用 CtrlC/quit 与进程信号的区别很多人习惯用CtrlC终止命令行程序这在大多数工具里没问题但在 Codex CLI 这种带交互状态机的程序里CtrlC和正常的退出命令不是一回事。第一次按CtrlC通常是取消当前正在进行的生成操作而不是退出整个会话。如果你的模型正在执行长任务CtrlC等于打断它的工作再按一次有的版本才会提示确认退出。直接按CtrlD也可能只是模拟 EOF未必会走正常收尾逻辑。更稳的退出方式是/quit。它会走一遍会话收尾流程如果有未处理完的命令审批会明确提示你放弃如果 shell hooks 已经安装它还会把当前会话状态同步回 shell 环境让你退出后能继续在普通终端里工作。我第一次没装 shell hooks对/quit和CtrlD的区别感受不深后来装了 hooks才发现用/quit退出后当前目录、最近命令状态都能无缝衔接到终端体验完全不一样。所以别小看这个看似多余的斜杠命令。4. 模型与执行环境/model、/switch、/agents、/config 的切换逻辑交互式 REPL 并不是只从一个入口加载一次配置就固定不变Codex CLI 允许你在会话进行中切换模型、切换工作目录、切换代理风格以及覆盖部分配置。很多人只把codex当成一个纯聊天的终端窗口忽略了它其实是一个“带运行环境的智能终端”。用好这一组命令才能避免频繁退出重开。4.1 /model 切换的是“思考方式”不是“API”Codex CLI 启动时会从配置文件中读取一个默认模型但不同任务对模型强度的需求差别很大。简单重复的任务用轻量模型响应更快成本更低复杂重构、跨文件分析的大任务用强模型效果更稳。/model命令会弹出一个列表列出当前登录方式下可用的模型供你选择。切换模型时有个常见误解切换不会清空会话历史。对话记录通常还在上下文里但不同模型的上下文策略不同切换后模型对之前细节的记忆程度未必一致。复杂任务在你切换模型后最好主动复述一遍关键约束不要想当然认为新模型已经完整继承旧模型的“记忆”。可参考的建议是先让轻量模型做信息收集、文件扫描、代码定位这类前期工作再切换更强模型做核心架构设计或代码生成。这比全程都用一个模型更省时间配合斜杠命令甚至能做到无缝切换。4.2 /switch 把工作根目录换掉/switch解决的是多项目同步工作的问题。输入/switch后CLI 一般会列出最近工作过的项目列表也可以手动输入一个新目录选择后Codex 会把后续文件操作、命令执行、路径解析的根目录切换过去。它和终端里cd类似区别在于 Codex 会重新检查新目录的环境、git 分支、配置文件确保后续任务在新上下文里执行而不只是换一个字符串前缀。在重构一个项目到一半突然需要去另一个项目修复紧急 bug 时/switch尤其有用。不需要退出当前会话、换终端、重新登录、重新描述项目背景直接切目录就行。如果你长期在多仓库之间横跳这个命令能显著减少“重复交代背景”的时间损耗。4.3 /agents 与 /config 的进阶作用/agents是给定义了多套代理配置的用户准备的。你可以在配置里预置几个不同风格的 Copilot 执行配置比如一个偏向谨慎审批、另一个偏向快速输出然后在会话中用/agents切换。如果没有配置多套/agents会返回没有可选项的提示。对大多数用户来说这一项前期用不上但当你需要不同任务用不同执行风格时它比手动改一堆配置参数舒服得多。/config则用来在会话中查看当前生效的配置比如默认模型、审批策略、调试开关等。你可以在不退出进程的情况下临时覆盖某些选项。但要注意/config做的临时改动通常只在当前会话有效退出后恢复为配置文件默认值需要持久化的时候还是要去编辑~/.codex/config.toml这类配置文件。一个实用的小习惯在修改config.toml之前先用/config看一眼当前会话正在用的实际配置别凭记忆去改文件。配置文件有继承和默认值机制你看到的“默认值”未必等于编辑器里找到的那一条。以/config输出的实际值为准能省不少排错的时间。5. 审批落地/approvals 与文件变更的确认斜杠命令里/approvals是最容易被人忽视、但对财产安全影响最大的一条。Codex CLI 不是一个只会在终端里打印文本的聊天程序它真的能修改文件、执行命令。为了保证不出现“说了一句话磁盘被改得面目全非”的失控情况默认机制会适当拦截事件要求用户确认。5.1 为什么 Codex 默认不“直接改盘”Codex CLI 在默认情况下不会无条件执行所有生成操作它会根据内部审批策略在工作区要发生变化时先展示 pending 的改动。你可以把这个机制理解成“每个操作都要过一道中介质检”模型算出结果后CLI 先把改动列出来由用户决定是接受还是拒绝。审批策略可以通过配置调整从强制确认到完全自动放行都有相关选项。很多人为了让工具“更流畅”会倾向关闭确认但我的建议是至少保留对文件变更的确认尤其是在不熟悉的任务、刚入职的新项目、或者多人共用的机器上一份人工过目的 diff 永远是最后一道防错网。5.2 使用 /approvals 审阅和批准变更当会话里积压了多个待处理操作时/approvals可以把它们集中列出来。你会看到这次改动涉及哪些文件、有哪些 diff、预计执行什么命令然后逐条决定批准或拒绝。这比在自然语言里回复“好继续”更清晰因为自然语言回复很容易被模型解读成“全部批准”而/approvals让你有逐个流程节点把关的选项。我在实际过程中最常用到的场景是这样的模型一次提交了一个包含五个文件修改的大 patch但其中有两个文件改动方向不对。我就在/approvals里只批准需要保留的那几个文件把不希望的改动挡在门外。等后续任务迭代时模型就会基于“用户实际批准的那部分”继续推进而不是拿着一条理想化的整体 diff 胡来。5.3 审批不等于代码复审要特别强调/approvals只是让你对“是否接受这次改动”做一个门卫式决定它不能替代人工代码复审。你看到 diff 可以判断“这个改动方向是否可接受”但不代表你能同时发现所有潜在的测试失败、边界条件或性能问题。合规的做法是落地改动前心里清楚这次改动的意图落地后立刻运行测试、编译、lint并且做一次完整的 diff 阅读。有些人习惯在/approvals里快速全部批准一旦模型之后又改了同名文件最终 diff 会叠加原文件内容都变了这时你此刻批准的其实是“累计结果的两个大块”不是单次改动。所以越是复杂项目越要小步推进频繁使用/approvals做局部确认。一次批准太多跨模块改动后面排查问题会非常痛苦。6. 真实工作流绕开斜杠命令最常见误区的组合玩法谈到最后把前面这些命令组合起来才能真正发挥斜杠命令的威力。这里我分享一套自己在实际项目里反复验证过的操作流程包含一次“从空目录开始”的干净会话以及迭代修复中的组合套路。6.1 从空目录开始的一次“干净会话”假设我要在一个临时目录里验证一个想法过程是这样mkdir /tmp/codex-demo cd /tmp/codex-demo git init codex进入 REPL 后先执行/new确保没有上一次会话的残留上下文污染本次任务。接着/status确认当前工作目录、git 分支、未跟踪文件的状态。这样做的目的是给自己一个明确的“起点快照”一旦后续发生不可控变化可以知道自己是从哪里开始偏离的。任务描述结束后模型会给出方案。此时我不急着批准先要求它列出要修改的文件列表和改动思路。再执行/approvals逐条看 diff。只批准自己真正认可的部分不认可的改动退回重做。等首个改动落地跑测试确认通过再进入下一步任务。最后用/quit退出带回干净的 shell 状态。这一整套流程下来关键不是命令有多高级而是通过/new的上下文隔离、/status的现场快照、/approvals的分批确认把不可控的模型行为一步步约束在可控范围里。6.2 迭代修复中的组合套路在已有项目上的迭代修复套路会有些不同。我先/status检查当前分支和未提交改动避免模型基于错误的状态做决策。然后把需求拆成小步第一步让模型写测试第二步让模型实现功能第三步用/approvals审阅。如果模型生成的解决方案结构不合理先/undo把磁盘改动撤掉再用/redo让模型基于同一需求重新生成而不是发一条新消息重新描述。一个特别有效的细节是/redo前先把需求里唯一有歧义的点强调一遍比如“要求保持模块导出接口不变这是底线”这样重新生成的结果往往更贴合预期而不是换个姿势继续错。整个迭代过程中我会有意识地控制每次任务范围不超过一个文件或一个功能点。范围太大/undo的恢复能力受影响/approvals的审阅效率也断崖式下跌。小步提交配合 git commit 建立检查点是我目前最推荐的稳定性方案。6.3 实测中容易翻车的三个认知误区/new是无损的不可能丢上下文。其实/new会直接清空当前会话历史而且没有“恢复上一段会话”的反悔命令。执行之前想清楚当前会话里如果有有价值的中间讨论最好复制保存或用 git 提交锁住文件状态否则就再也找不回来了。斜杠命令可以一次组合多个动作。事实上命令解释器通常只处理每行的第一个命令多余的内容会被丢弃或不解析。不要试图把/undo和/redo写成一行这种操作方式大概率只执行了其中一半另一半变成无效输入。版本更新后斜杠命令名单不变。Codex CLI 更新后命令支持会有增删。最保险的习惯是每次升级后跑一次/help花十秒钟扫一眼命令列表尤其是当你知道新版本引入了多代理切换或新审批模式时旧习惯可能在新版本里不再适用。斜杠命令是一张需要保鲜的工具地图不是考前背诵一遍就一劳永逸的公式表。说了这么多我最后想补充一个个人体会斜杠命令的设计初衷不是让你把它背得滚瓜烂熟而是让“在终端里与模型协作”这件事变得更像操作一个真实工具而不是陪一个偶发性失忆的模型闲聊。把/status当仪表盘把/approvals当安全阀门把/undo、/redo当方向盘这套交互方式用顺之后你会发现 Codex CLI 完全可以成为值得信赖的“第二双手”而不是一个需要你时刻盯防的不稳定员工。