夜雨聆风用 Codex CLI，十分钟把 OpenAI 的编程助手接进终端
如果你已经习惯在编辑器里问 AI，一个很自然的问题就是：能不能别来回复制报错、粘贴代码、再切回终端跑命令。
Codex CLI 做的就是这件事。
它不是编辑器侧边栏里的聊天框，而是直接住进终端。你在项目根目录敲一句 codex，它就能读文件、改文件、跑命令，还会按项目里的 AGENTS.md 来做事。
对开发者来说，最实在的价值不是“它会写代码”，而是它终于能在现场干活了。
先说结论
如果你只想知道它值不值得装，我的答案是：值得。
尤其是这几种场景。
看一个陌生仓库。
顺着报错往下查。
改一条功能链路，再补上测试。
先拉一个能跑的原型。
这类活本来不难，但很碎。碎就容易打断思路。Codex CLI 最擅长接这种活。
十分钟装好
按 OpenAI 现在的官方文档，最短路径就是两步。
npm install -g @openai/codex@latest
codex
第一次启动会让你登录。可以直接用 ChatGPT 账号，也可以走 API key。
如果你更习惯 API key，先在 shell 里配好：
export OPENAI_API_KEY="<你的 OpenAI API Key>"
codex
升级也很直接：
codex --upgrade
OpenAI 官方这套说明，我看的是 2026 年 5 月还在更新的版本，所以命令可以直接照着用。
常用命令，先记这几个就够了
如果你第一天上手，真的不用背太多。
先把这几条记住，已经能覆盖大部分场景。
# 启动默认模式
codex
# 自动改文件，但跑命令前仍会确认
codex --auto-edit
# 自动改文件并自动执行命令
codex --full-auto
# 跳过审批与沙箱，危险模式
codex --yolo
# 指定模型
codex -m o3
# 升级到最新版本
codex --upgrade
还有两个小动作也很实用。
一个是会话里直接输入 /mode，不用退出重开，就能切换当前的 approval mode。
另一个是 Ctrl-C。如果它卡住了，或者你看它走偏了，直接中断，然后补一句“继续，但只检查 src/billing”，往往就能拉回来。
codex --yolo 要单独说一句。
它不是普通意义上的“更快一点”，而是直接跳过审批和沙箱。OpenAI 仓库里一直把它当成极危险选项来看，适合你已经在 Docker、dev container 之类外部隔离环境里兜住风险的时候再用。平时在本机项目里，优先用 --full-auto 就够了。
第一天怎么用
别一上来就让它“帮我做个功能”。
先拿一个小任务试手感。
比如进一个项目根目录后，先问它：
Explain this repo to me.
或者更贴近中文习惯一点：
先不要修改文件。
告诉我这个仓库的入口在哪。
测试命令是什么。
哪些目录看起来像生成产物。
这一步很重要。因为 Codex CLI 不是单纯答题，它会一边看目录，一边读文件，再决定接下来往哪走。你先让它“只读”，能很快摸清它的节奏。
再往下，可以试一个非常具体的小改动。
只看 billing export 这条链路。
先列计划，不要直接改。
不要动 generated 文件。
如果需要改 schema，先告诉我原因。
做完跑相关测试，停下等我确认。
这类提示词没什么花样，但特别好用。
因为你不是在“启发一个模型”，你是在给一个会动手的 agent 划边界。
三个模式，先用最稳的
按 OpenAI 当前帮助文档，Codex CLI 常用的是这三个启动方式：
codex
codex --auto-edit
codex --full-auto
默认模式最稳，适合第一天上手。它会先读文件，提议修改和命令，等你确认再执行。
--auto-edit 适合重复性改动。它可以自动改文件，但跑命令前还是会问你。
--full-auto 放权最多，适合修构建、跑一轮原型这种较长任务。第一次用别急着开这个。等你知道它会怎么走，再把权限一点点放出去，心里更踏实。
--yolo 比 --full-auto 还要激进。你可以把它理解成“别问，直接干”。只有在外部已经做好隔离，而且你真的知道自己在放开什么权限时，才值得碰它。
我的建议很简单：先用默认模式，把“会不会乱改”这件事看明白，再往上开。
常见使用场景，可以直接照抄
很多人装完 Codex CLI，第一反应是“然后呢”。
然后就从这些小场景开始。
1. 读一个陌生仓库。
刚接手新项目时，这个场景特别高频。
先不要修改文件。
告诉我这个仓库的入口在哪。
测试怎么跑。
核心目录分别是干什么的。
适合用 codex 默认模式。
2. 顺着一次失败的测试找根因。
这个比“直接帮我修 bug”更稳。先找根因，再决定改不改。
Find the first real error in this failing test run.
Do not edit generated files.
Tell me the likely root cause first.
适合用 codex 默认模式。
3. 做一批重复的小改动。
比如统一改一个字段名，或者补几处同类校验。这种活人工最烦，Codex CLI 很合适。
Rename this field across the billing module.
Only touch billing-related files.
Show me a short plan first.
Run relevant tests before finishing.
这种场景可以试 codex --auto-edit。
4. 补一条完整但不大的功能链路。
比如后端多返回一个字段，前端消费它，再把测试补上。
Add this field to the API response.
Update the caller.
Add or update tests.
Do not refactor unrelated modules.
这个场景我还是建议先用 codex 默认模式，等你确认它的计划没跑偏，再让它动手。
5. 快速拉一个原型。
比如做个脚本、生成一个最小 demo、或者把一个想法先跑起来。
Create a minimal prototype in a new folder.
Keep the scope small.
Explain the file structure after you finish.
这个场景如果目录干净，而且你知道自己在放权，可以试 codex --full-auto。
6. 先要方案，不要代码。
这其实是最容易被忽略的一种用法。
Do not edit yet.
List the files you expect to change.
List the checks you will run.
Tell me the risks first.
拿它当一个会读仓库的技术搭档，而不是一上来就写代码，效果通常更稳。
四种模式怎么选
命令记住以后，真正影响手感的，其实是你在什么场景下开哪一档权限。
我自己的判断很简单。
codex 默认模式。
适合陌生仓库、线上问题排查、第一次改某条业务链路。
这时候你最需要的不是速度，而是可控。它每走一步都会让你看见，出偏差也容易及时拉回来。
codex --auto-edit。
适合重复性改动，比如统一改字段名、补几处同类校验、批量小修小补。
文件改动交给它自动做，命令执行你再把一道关，效率和安全感会比较平衡。
codex --full-auto。
适合原型、小工具、一次性脚本、或者你已经很熟的仓库。
这种场景里，文件和命令都可以让它一口气往下走。前提是你知道它改坏了也容易收拾，不会牵一发动全身。
codex --yolo。
适合已经放进 Docker、dev container、临时沙箱机里的任务，而且你明确知道自己不想要任何审批和限制。
这不是“效率更高一点”的模式，而是“我愿意自己兜底”的模式。只要还在本机主环境里，我都不建议把它当日常用法。
如果你懒得细想，就按这个顺序开权限：
先用 codex熟了以后试 --auto-edit确认任务足够小、环境足够安全，再用 --full-auto--yolo留给隔离环境
这么走，基本不容易翻车。
AGENTS.md 才是上手的关键
很多人刚装 Codex CLI，觉得它时灵时不灵。
大多数时候，不是模型忽然变笨了，是项目规矩没人告诉它。
Codex CLI 会读仓库里的 AGENTS.md。这几乎是它最好用的一个点。你把工作方式写进去，它后面每次进项目都会先看这张纸。
一个很够用的最小版本，大概是这样：
# AGENTS.md
- Use pnpm
- Before editing, show a short plan
- Do not edit generated/*
- Only touch files related to the current task
- Run relevant tests before finishing
别贪多。
写五条真规矩，比写半本团队手册管用。
我自己常加的还有两条：
- If schema changes are needed, explain why first
- Do not refactor unrelated modules
这两句能少掉很多“顺手一改”。
我最常用的四个动作
说到底，工具值不值得留在机器里，还是看它能不能进日常。
我现在最常让 Codex CLI 做四件事。
1. 读仓库。
Read this repo and explain the architecture briefly.
2. 查报错。
Find the first real error in this failing test run.
Do not patch generated files.
3. 补一条功能链路。
Add this field to the API, update the caller, and add tests.
Only touch the billing module.
4. 先出计划。
Do not edit yet.
List the files you expect to change and the checks you will run.
你会发现，真正高频的不是“让它从零写一个系统”，而是这些原本要你自己来回走很多步的小活。
它跟 Claude Code 有什么不一样
这篇不是横评，我只说最直接的体感。
Codex CLI 的优点是上手快，命令简单，和 OpenAI 自家的账号体系连得顺，而且现在官方已经把 MCP、Hooks、Skills、subagents 这些能力接进来了，路子比刚发布时完整很多。
它还有一个很实际的点：开源。仓库就在 GitHub 上，底层是 Rust。对想看清工具到底怎么工作的开发者来说，这个属性很重要。
如果你以前对 Codex 的印象还是“一个比较轻的终端助手”，那得更新一下了。至少到 2026 年 5 月，这东西已经明显不是那个阶段。
最后给一个真能抄的上手顺序
如果你今晚就想试，我建议直接按这个顺序来。
安装 @openai/codex。在一个 Git 仓库根目录运行 codex。先让它只读，解释项目结构。 新建一个最小 AGENTS.md，写清包管理器、generated 文件、测试命令。选一个小任务，让它先列计划，再改文件。 等你对它的节奏有感觉了，再试 --auto-edit。
这样上手，基本不会踩空。
我现在电脑里会一直留着 Codex CLI。不是因为它什么都能做，而是很多本来要我自己消耗注意力的小事，终于有人能在终端里接过去了。
