之前推过两篇 OpenAI Codex 相关,偏方法论
OpenAI 团队如何使用CodeX,6 项最佳实践
Codex Windows 客户端来了,深读官方文档后我有 5 个判断
刚好这个周末,我的 Plus 额度也差不多耗光了,索性停下来,认真写一篇图文版入门。
如果你最近正准备试试 Codex,这篇可以帮你少走一些弯路。

不得不说 GPT-5.4 相比其他已经算量大管饱(时常给个额度翻倍惊喜),模型能力也是 Opus 级别
如果你第一次接触 Codex,我建议先从 App 入手,因为:
这篇文章我只讲 App,不讲 CLI 和 IDE,目标是让你 10 分钟内知道:它能干什么、该怎么配、哪些设置最值得先改。
多图预警,请准备好流量

官方介绍,其实有 4 中用法,注意下图最下居中,它有网页端

我理解:它们不是替代关系,而是同一套能力的不同入口。
区别不在“谁更强”,而在“你平时在哪儿工作”。

入口 | 更像什么 | 最适合的第一批用户 |
|---|---|---|
App | 本地指挥台 | 想并行跑任务、看 diff、切 worktree 的开发者 |
CLI | 终端主线 | 习惯命令行、想脚本化、想和现有 shell 工作流融合的人 |
IDE extension | 编辑器内副驾驶 | 长时间待在 VS Code、Cursor、Windsurf 里的人 |
Web | 云端执行面板 | 想把任务丢到后台、接 GitHub、跑云端任务的人 |
安装之后界面如下

它既不是 IDE,也不是 CLI,官方只管他叫 APP
我更愿意把它理解成一个本地开发任务调度台,你可以在里面:
这一点,是它和普通聊天式 AI 工具最不一样的地方
右上角,它还有一种使用模式——支持快捷键唤出,悬浮于桌面
这个设计我挺喜欢,它不会强迫你一直待在 App 主窗口里。
你可以把线程挂在浏览器、编辑器、设计稿、预览页面附近,边看边提需求,适合快速来回迭代。
如果你习惯一边看页面、一边让 agent 改代码,这个模式很好用。

底部模型可以切换,还有思考深度,越高效果越好,速度越慢

右上角可以点击切换终端
注意,它不是“整个 App 共用一个终端”,而是线程级别绑定的终端。 也就是说,每个线程都可以对应一个与当前项目或工作区绑定的内置终端。
这意味着你可以在不离开 App 的情况下直接:
甚至,你还可以在这个终端里运行别的 agent。 也就是说,一个界面里同时配合使用 Codex App、Codex CLI,甚至 Claude Code、Gemini、OpenCode 之类的工具,都不是问题

创建终端右侧是差异面板,显示本地项目或工作树检查中的 Git 差异

因为很多人第一次用 agent,最容易犯的一个问题就是:
只看对话,不看改动。
但真正决定结果好坏的,不是它说了什么,而是它到底改了哪些文件、删了什么、加了什么。
所以我自己的使用习惯是:
这样安全感会高很多
Codex 应用程序直接在应用程序内提供常见的 Git 功能,可以直接从 Codex 提交、推送并为本地和工作树任务创建拉取请求。
这件事的价值,不只是“方便”,而是上下文不断裂。 你不需要在“聊天—终端—Git 客户端—代码编辑器”之间频繁来回切

先看左侧工具栏,不同文件夹对应不同项目
一个项目可以开 N 多个线程,不同线程做不同任务
官方解释:线程是一个单一会话,你的提示加上后续的模型输出和工具调用。一个线程可以包含多个提示。例如,你的第一个提示可能要求 Codex 实现一个功能,而后续的提示可能要求它添加测试。当 Codex 正在积极处理线程时,该线程被称为“正在运行”。可以同时运行多个线程,但避免有两个线程修改相同的文件。也可以稍后通过使用另一个提示来继续线程。
我自己的理解更简单:一个线程,就应该只做一件事。
比如:
这样做的好处非常明显:
不建议一个线程里同时混着做三四件事
那样前面聊的是功能实现,后面又插进测试、文档、部署问题,很快就会乱

自动化这里可以设置不同的定时任务,可以是抓取信息,可以是定时分析日志
把一切重复、周期性的任务交给后台自动执行

刚开始用 Codex,我建议先把线程、本地模式、diff、Git 这些基础链路跑顺,再来碰自动化
技能就是 SKills ,这里大量是我自己创建的

往下拉,也有官方推荐的 SKills

点击新建 skills 时,它会自动跳转,默认使用 Skill Creator 创新,写清楚自己的需求就行了

很多以前要靠 MCP 或手工配置解决的问题,已经可以被一部分 Skills 覆盖掉。
不是说 MCP 没用了,而是对于很多普通用户来说,Skills 的上手门槛更低,路径也更短。
如果你只是想快速补齐某类能力,先看看有没有现成 Skills,往往比从零折腾更省时间。
如果你第一次打开设置,不少人会有点懵
因为选项挺多,看起来哪里都能改
但我觉得真正值得优先关注的,不多
然后进入设置-常规,建议打开运行时防止系统休眠
Speed 我选了 Fast,优点是快,缺点是 2 倍消耗

上图默认打开目标,可以设置成你熟悉的工具,甚至可以使用 antigravity

跟进行为有两种模式,排队 or 引导,它正在运行任务时,引导模式允许在任务执行中注入新的指令,立即生效。排队则是新指令要等当前任务结束后才执行。
如果你喜欢边跑边干预,选引导 如果你更想让任务按顺序稳定执行,选排队

我没动,看个人习惯,默认就挺好,无不适感
如果你没有特别强的界面偏好,这部分可以先放着,不是最优先该折腾的地方

它详细配置都在 config.toml 中
它们本质上决定了一个问题:你愿意给 agent 多大权限
比如:
我自己比较激进,基本会直接给高信任和 Full access

它的个性化只有两个,一个是亲和,一个是务实

上面自定义指令,我参考了这位大佬的配置

实际感受还可以,缺点是更慢,消耗更多

随着 Skills 逐渐补上很多能力,MCP 对普通用户来说,不再是刚需
我没怎么搞,以前配置了很多,但现在 Skills 取代一大批,Playwright 肯定是必装

我多数都是选择本地模式

这里是对你添加的项目配置环境文件

仅对你使用工作树模式时有效
工作树主要作用:一个仓库,多个并行文件夹,各跑各的分支
让多个 agents 能同时工作而不发生冲突

回到操作页面,线程的运行模式有几种,前两者是本地执行

本地模式可以迁移至工作树

关于工作树,最详细的介绍:https://git-scm.com/docs/git-worktree
云线程在隔离的环境中运行,Codex 会克隆你的仓库并检出它正在工作的分支。当你想并行运行工作或从另一台设备委派任务时,云线程很有用。要使用云线程与你的仓库,先将代码推送到 GitHub。

关联之后就可以直接对你的 Github 仓库进行操作

这类模式适合什么时候用?我的理解是两类场景:
如果你要让云线程操作你的仓库,先把代码推到 GitHub。
对话框输入 / 可以调出可用命令,最常用的是 /plan
这个命令很适合放在“真正开始改代码之前”
它的价值不是帮你直接产出代码,而是先把思路、步骤、边界、风险梳理清楚。 尤其是当任务本身比较复杂时,先花一轮把计划拧清楚,后面返工会少很多。
简单说就是:
先让 agent 和你对齐怎么做,再让它开始做。

如果担心它找不准 skills 也可以手动用 / 指定

线程中的所有信息都必须适应模型的不同上下文窗口
Codex 会监控并报告剩余的空间,对于较长的任务,Codex 可能会通过总结相关信息并丢弃不太相关的细节来自动压缩上下文。通过重复压缩,Codex 可以在多个步骤上继续处理复杂任务。
没有额度了,这一步无法截图展示了。
不订阅 ChatGPT 也可以用 Codex
修改两个地方
~/.codex/auth.json
{
"OPENAI_API_KEY": "sk-"
}
~/.codex/config.toml
model_provider = "" # 设置API供应商
model = ""
[model_providers.siliconflow]
base_url = ""
name = ""
[projects."/Users/huhaiyang/Library/Mobile Documents/iCloud~md~obsidian/Documents/zhangAI/"]
trust_level = "untrusted"