最近重新梳理了一遍 Codex CLI 的使用体验，一个感受越来越强烈：这玩意儿早就超出了“代码生成器”的范畴。
多数人初闻 Codex，脑海中浮现的标签无非是“AI 编程助手”。但真正把它跑起来之后，你会发现它能做的事，远比补几行代码要宽广。它可以审查代码、执行命令、压缩图片，甚至接管浏览器去点击页面、验证流程。只要给予合适的权限，它几乎就是一个能直接操作你电脑的系统级 Agent。
这篇文章不聊空泛的概念，只讲我自己实际怎么用。从安装、交互、一次性任务，到最值得记住的命令、权限配置，以及 Skill 到底是什么，都会一一拆解。
一、从“代码补全器”到“执行型助手”
我现在看 Codex，早已不把它当作“代码补全器”。它更像一个住在终端里的执行型搭档。
你让它 review 当前改动，它会按优先级列出问题；你让它把一张 5MB 的图片压到 2MB 以下，它会自己寻找工具、调整格式、反复尝试，最终交付结果；你让它接管浏览器，它能自动打开页面、点击按钮、滚动检查，然后返回测试结论。
这种体验和普通聊天机器人有本质区别。聊天机器人是“我说，你答”；Codex 是“我说，你去干”。差别就在行动力上。在我看来，这正是 Agent 类工具最核心的竞争力——它不再只提供建议，而是直接对真实环境产生改变。
二、安装极简，但真正的门槛在工作流
安装 Codex CLI 几乎没有难度。前提是电脑里已装 Node.js（官网 nodejs.org 下载即可），然后在终端执行：
npm install -g @openai/codex装完后输入 codex 启动，首次会要求登录。支持 ChatGPT 账号或 API key 两种方式。用 ChatGPT 账号时，终端会给出一个 device code，浏览器验证后回到终端即可开始对话。
安装只是第一步，真正决定使用体验的是你如何组织工作流。我日常最常用的模式有两个：exec 和交互模式。
exec：一次性任务的利器
如果只想让 Codex 完成一件具体的事，没必要进入交互界面。直接使用 codex exec 即可。例如桌面有一张 5MB 的 PNG，想压到 2MB 以下并另存为新文件：
codex exec --full-auto "把桌面上的 sample.png 压到 2MB 以下，保存成 sample-optimized.png"这个例子很能说明问题：它不是在生成一段函数，而是在真实环境里完成任务。我自己测试时，它把图片压到了 1MB 左右，消耗了 7675 token。这也提醒我们，让 Agent 真干活是有成本的，而且不算便宜。因此我的习惯是：日常小任务能 exec 就 exec，复杂需求再进交互模式慢慢迭代。
交互模式：从规划到落地的完整对话
真正让我离不开 Codex 的，是交互模式。终端输入 codex 进入后，你可以像跟一个会动手的搭档聊天一样，一轮一轮推进。
很多人第一次用这类 Agent，最大的问题不是模型不够聪明，而是自己一上来就把需求说糊了。结果 Agent 一顿猛写，UI 歪了、数据流也歪了，改起来更痛苦。我现在的做法是：先切到 /plan 状态，让它先做规划。比如做一个 recipe generator，用本地模板生成，不接大模型接口，先把交互和页面跑起来。进入 plan 后，它会追问细节：生成逻辑是本地模板还是实时调用模型？要不要保存历史？是否需要移动端适配？
这种追问一开始可能让人烦躁，但多来几次就会发现，这一步真能避免大量返工。计划敲定后再让它开工，整个命中率会高很多。这其实也反映了 Agent 工具的一个共性：输入质量决定了输出质量。
三、高频命令、权限与上下文
Codex 的命令很多，但我平时高频使用的就那么几个。
/new：上下文太脏时开新 chat，不用退出重进。/model：当作成本旋钮。中等推理强度适合大多数日常任务，够快也不烧 token；碰到棘手重构、架构设计再调高。/review：把当前 git 改动丢给它，它会按优先级挑问题。连续写代码几小时后，用来自检特别舒服。/status：查看 token 用量和当前状态。/compact：压缩上下文，避免窗口越来越肥、成本飙升。!命令：在交互里直接执行 shell 命令，比如!ls、!cat package.json，不用切出终端。codex resume --last：上次聊到一半退出，回来直接续上。
权限方面，重点理解两个概念：approval（干活前要不要问你）和 sandbox（能动的范围）。当前版本的关键参数包括 --ask-for-approval、--sandbox、--full-auto，以及名字非常直白的 --dangerously-bypass-approvals-and-sandbox。看到这个名字就知道，这不是随便开的。我的建议是，日常使用保持沙箱和审批，只有在你完全信任任务来源时才考虑放开。
Codex 还支持多模态输入，你可以直接扔截图，或用 @ 引用项目文件。这在改前端时特别顶用。比如页面功能没问题但配色土，从 Dribbble 截一张喜欢的 dashboard 丢给它，说“照这个风格重做”。它不一定一步到位，但真的能理解你在嫌弃什么。截图提供审美锚点，文件提供精确上下文，喂得越具体，翻车概率越低。
四、Skill、/init 与上手建议
Skill 是 Codex 里一个被很多人误解的概念。其实它并不神秘，就是一组预先打包好的能力说明书，外加必要的脚本和资源。Codex 读完这份说明，就知道遇到某类任务该怎么干。系统自带一些 Skill，也可以后装。比如装一个浏览器自动化相关的 Skill，然后让 Codex 自己打开网页测应用，从注册、登录到表单、弹窗、移动端异常流程，它都能跑一遍并给出结论。发现问题后，你甚至不用切换工具，直接说“把这个问题修掉”，它就会接着改。这才是 Agent 工作流该有的样子——不是陪你聊天，是替你干活。
对于 /init，我反而比以前更谨慎。有些人喜欢上来就生成一大坨仓库说明文件，想让 Agent 以后都照着做。但如果这个文件写得很空、很泛、很像模板，它只会污染上下文，让 Codex 每次都背着一堆低价值信息干活。我的思路是：真有稳定规则再写，没有就别硬塞。上下文不是越多越好，有用才重要。
Codex 也可以接到 Cursor 或 VS Code 里，终端改了什么，IDE 里基本都能同步看到。但我个人建议先把 CLI 用明白。因为 CLI 最接近 Codex 的原生工作方式——命令、权限、沙箱、会话恢复、一次性执行、后台进程，这些核心能力在终端里感知最清楚。底层逻辑吃透了，再接 IDE 只会更丝滑。
如果你今天才开始用 Codex，建议先做三个小练习：第一，用 codex exec 做一个一次性任务，比如批量改文件名、压缩图片、整理 CSV；第二，在交互模式里，让它从 plan 到实现，完整做一个很小的 Web 页面；第三，给它一张截图或一个现成页面，让它照着风格改 UI。这三步跑完，你对 Codex 的感觉会完全不一样，也会更清楚什么时候该一把梭、什么时候该先 plan、什么时候该给更多上下文。
我现在对 Codex 的判断很直接：它不是“最会写代码”的点状工具，而是一个带执行能力的工作接口。终端是入口，文件系统是手，浏览器是眼睛，命令行和 Skill 是武器库。按这个思路去用，很多以前要自己做的脏活、碎活、重复活，它真的能帮你吃掉一大截。当然，它也不是万能的，权限开太猛有风险，上下文喂太差会翻车，复杂任务不规划也会写偏。但这些都不影响它改变我的工作方式——不是“快一点”，而是彻底换了种干活的方式。