首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >OpenAI Codex 使用教程

OpenAI Codex 使用教程

作者头像
Ai学习的老章
发布2026-03-27 12:53:41
发布2026-03-27 12:53:41
1.8K0
举报

之前推过两篇 OpenAI Codex 相关,偏方法论

OpenAI 团队如何使用CodeX,6 项最佳实践

Codex Windows 客户端来了,深读官方文档后我有 5 个判断

刚好这个周末,我的 Plus 额度也差不多耗光了,索性停下来,认真写一篇图文版入门。

如果你最近正准备试试 Codex,这篇可以帮你少走一些弯路。

不得不说 GPT-5.4 相比其他已经算量大管饱(时常给个额度翻倍惊喜),模型能力也是 Opus 级别
不得不说 GPT-5.4 相比其他已经算量大管饱(时常给个额度翻倍惊喜),模型能力也是 Opus 级别

不得不说 GPT-5.4 相比其他已经算量大管饱(时常给个额度翻倍惊喜),模型能力也是 Opus 级别

如果你第一次接触 Codex,我建议先从 App 入手,因为:

  • 比 CLI 更直观
  • 比 IDE 插件更独立
  • 比 Web 更贴近本地开发
  • 线程、终端、diff、Git、worktree 这些能力都能在一个界面里看到

这篇文章我只讲 App,不讲 CLI 和 IDE,目标是让你 10 分钟内知道:它能干什么、该怎么配、哪些设置最值得先改。

多图预警,请准备好流量

先弄清楚:Codex 其实有 4 个入口

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

我理解:它们不是替代关系,而是同一套能力的不同入口。

区别不在“谁更强”,而在“你平时在哪儿工作”。

入口

更像什么

最适合的第一批用户

App

本地指挥台

想并行跑任务、看 diff、切 worktree 的开发者

CLI

终端主线

习惯命令行、想脚本化、想和现有 shell 工作流融合的人

IDE extension

编辑器内副驾驶

长时间待在 VS Code、Cursor、Windsurf 里的人

Web

云端执行面板

想把任务丢到后台、接 GitHub、跑云端任务的人

主操作台

安装之后界面如下

它既不是 IDE,也不是 CLI,官方只管他叫 APP

我更愿意把它理解成一个本地开发任务调度台,你可以在里面:

  • 给 agent 下任务
  • 跟踪线程
  • 看终端输出
  • 检查代码差异
  • 做 Git 操作
  • 在不同线程之间并行推进不同工作

这一点,是它和普通聊天式 AI 工具最不一样的地方

浮动弹出窗口:适合快速迭代

右上角,它还有一种使用模式——支持快捷键唤出,悬浮于桌面

这个设计我挺喜欢,它不会强迫你一直待在 App 主窗口里。

你可以把线程挂在浏览器、编辑器、设计稿、预览页面附近,边看边提需求,适合快速来回迭代。

如果你习惯一边看页面、一边让 agent 改代码,这个模式很好用。

模型切换

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

  • 小任务、试探性任务:先用快一点的设置
  • 重构、复杂逻辑、长链路问题:再把思考深度拉高
切换终端:这是 App 很核心的一部分

右上角可以点击切换终端

注意,它不是“整个 App 共用一个终端”,而是线程级别绑定的终端。 也就是说,每个线程都可以对应一个与当前项目或工作区绑定的内置终端

这意味着你可以在不离开 App 的情况下直接:

  • 验证更改
  • 跑脚本
  • 看日志
  • 执行 Git 操作

甚至,你还可以在这个终端里运行别的 agent。 也就是说,一个界面里同时配合使用 Codex App、Codex CLI,甚至 Claude Code、Gemini、OpenCode 之类的工具,都不是问题

差异面板:一定要养成看的习惯

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

因为很多人第一次用 agent,最容易犯的一个问题就是:

只看对话,不看改动。

但真正决定结果好坏的,不是它说了什么,而是它到底改了哪些文件、删了什么、加了什么。

所以我自己的使用习惯是:

  • agent 改完
  • 先看 diff
  • 再决定是继续让它改,还是自己接管

这样安全感会高很多

内置 Git 工具

Codex 应用程序直接在应用程序内提供常见的 Git 功能,可以直接从 Codex 提交、推送并为本地和工作树任务创建拉取请求。

这件事的价值,不只是“方便”,而是上下文不断裂。 你不需要在“聊天—终端—Git 客户端—代码编辑器”之间频繁来回切

线程:Codex App 的真正核心

先看左侧工具栏,不同文件夹对应不同项目

一个项目可以开 N 多个线程,不同线程做不同任务

官方解释:线程是一个单一会话,你的提示加上后续的模型输出和工具调用。一个线程可以包含多个提示。例如,你的第一个提示可能要求 Codex 实现一个功能,而后续的提示可能要求它添加测试。当 Codex 正在积极处理线程时,该线程被称为“正在运行”。可以同时运行多个线程,但避免有两个线程修改相同的文件。也可以稍后通过使用另一个提示来继续线程。

我自己的理解更简单:一个线程,就应该只做一件事。

比如:

  • 一个线程实现功能
  • 一个线程补测试
  • 一个线程修 lint 或类型问题
  • 一个线程做重构
  • 一个线程只做代码审查和计划讨论

这样做的好处非常明显:

  1. 上下文更干净
  2. diff 更容易看
  3. 后续迁移到 worktree 或云线程也更顺

不建议一个线程里同时混着做三四件事

那样前面聊的是功能实现,后面又插进测试、文档、部署问题,很快就会乱

自动化:把重复任务交给后台

自动化这里可以设置不同的定时任务,可以是抓取信息,可以是定时分析日志

把一切重复、周期性的任务交给后台自动执行

刚开始用 Codex,我建议先把线程、本地模式、diff、Git 这些基础链路跑顺,再来碰自动化

技能

技能就是 SKills ,这里大量是我自己创建的

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

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

很多以前要靠 MCP 或手工配置解决的问题,已经可以被一部分 Skills 覆盖掉。

不是说 MCP 没用了,而是对于很多普通用户来说,Skills 的上手门槛更低,路径也更短。

如果你只是想快速补齐某类能力,先看看有没有现成 Skills,往往比从零折腾更省时间。

设置-常规

如果你第一次打开设置,不少人会有点懵

因为选项挺多,看起来哪里都能改

但我觉得真正值得优先关注的,不多

然后进入设置-常规,建议打开运行时防止系统休眠

Speed 我选了 Fast,优点是快,缺点是 2 倍消耗

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

跟进行为有两种模式,排队 or 引导,它正在运行任务时,引导模式允许在任务执行中注入新的指令,立即生效。排队则是新指令要等当前任务结束后才执行。

如果你喜欢边跑边干预,选引导 如果你更想让任务按顺序稳定执行,选排队

设置-Appearance

我没动,看个人习惯,默认就挺好,无不适感

如果你没有特别强的界面偏好,这部分可以先放着,不是最优先该折腾的地方

配置:Approval 和 Sandbox 决定了你有多“放手”

它详细配置都在 config.toml 中

  • Approval policy
  • Sandbox setting

它们本质上决定了一个问题:你愿意给 agent 多大权限

比如:

  • 不放心,就把 Approval 设得更严格,很多动作都手动确认
  • 不放心,就把 Sandbox 设成只读
  • 如果你已经很熟悉自己的环境和项目,再逐步放开权限

我自己比较激进,基本会直接给高信任和 Full access

设置-个性化:能锦上添花,但不是刚需

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

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

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

设置-MCP 服务器

随着 Skills 逐渐补上很多能力,MCP 对普通用户来说,不再是刚需

我没怎么搞,以前配置了很多,但现在 Skills 取代一大批,Playwright 肯定是必装

设置-Git

我多数都是选择本地模式

设置-环境

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

设置-工作树

仅对你使用工作树模式时有效

工作树主要作用:一个仓库,多个并行文件夹,各跑各的分支

让多个 agents 能同时工作而不发生冲突

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

  • 本地:直接在当前项目目录中工作
  • 工作树:在 Git 工作树中隔离更改
  • 云端:在配置好的云端环境中远程运行

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

关于工作树,最详细的介绍:https://git-scm.com/docs/git-worktree

云线程:适合把任务丢到远端跑

云线程在隔离的环境中运行,Codex 会克隆你的仓库并检出它正在工作的分支。当你想并行运行工作或从另一台设备委派任务时,云线程很有用。要使用云线程与你的仓库,先将代码推送到 GitHub。

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

这类模式适合什么时候用?我的理解是两类场景:

  1. 想并行委派任务
  2. 想在另一台设备之外,把任务挂到云端执行

如果你要让云线程操作你的仓库,先把代码推到 GitHub。

Slash 命令

对话框输入 / 可以调出可用命令,最常用的是 /plan

这个命令很适合放在“真正开始改代码之前”

它的价值不是帮你直接产出代码,而是先把思路、步骤、边界、风险梳理清楚。 尤其是当任务本身比较复杂时,先花一轮把计划拧清楚,后面返工会少很多。

简单说就是:

先让 agent 和你对齐怎么做,再让它开始做。

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

上下文窗口

线程中的所有信息都必须适应模型的不同上下文窗口

Codex 会监控并报告剩余的空间,对于较长的任务,Codex 可能会通过总结相关信息并丢弃不太相关的细节来自动压缩上下文。通过重复压缩,Codex 可以在多个步骤上继续处理复杂任务。

没有额度了,这一步无法截图展示了。

国产模型支持

不订阅 ChatGPT 也可以用 Codex

修改两个地方

~/.codex/auth.json

代码语言:javascript
复制
{

"OPENAI_API_KEY": "sk-"

}

~/.codex/config.toml

代码语言:javascript
复制
model_provider = ""  # 设置API供应商
model = ""   

[model_providers.siliconflow]
base_url = ""
name = ""

[projects."/Users/huhaiyang/Library/Mobile Documents/iCloud~md~obsidian/Documents/zhangAI/"]
trust_level = "untrusted"

写的很浅,我本人也不算深度用户,后续大家感兴趣,我会再写一篇使用技巧

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-03-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 机器学习与统计学 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 先弄清楚:Codex 其实有 4 个入口
  • 主操作台
    • 浮动弹出窗口:适合快速迭代
    • 模型切换
    • 切换终端:这是 App 很核心的一部分
    • 差异面板:一定要养成看的习惯
    • 内置 Git 工具
  • 线程:Codex App 的真正核心
  • 自动化:把重复任务交给后台
  • 技能
  • 设置-常规
  • 设置-Appearance
  • 配置:Approval 和 Sandbox 决定了你有多“放手”
  • 设置-个性化:能锦上添花,但不是刚需
  • 设置-MCP 服务器
  • 设置-Git
  • 设置-环境
  • 设置-工作树
  • 云线程:适合把任务丢到远端跑
  • Slash 命令
  • 上下文窗口
  • 国产模型支持
  • 写的很浅,我本人也不算深度用户,后续大家感兴趣,我会再写一篇使用技巧
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档