OpenAI Codex 使用教程

之前推過兩篇 OpenAI Codex 相關(guān)，偏方法論

剛好這個周末，我的 Plus 額度也差不多耗光了，索性停下來，認(rèn)真寫一篇圖文版入門。

如果你最近正準(zhǔn)備試試 Codex，這篇可以幫你少走一些彎路。

不得不說 GPT-5.4 相比其他已經(jīng)算量大管飽（時常給個額度翻倍驚喜），模型能力也是 Opus 級別

如果你第一次接觸 Codex，我建議先從 App 入手，因為：

• 比 CLI 更直觀

• 比 IDE 插件更獨立

• 比 Web 更貼近本地開發(fā)

• 線程、終端、diff、Git、worktree 這些能力都能在一個界面里看到

這篇文章我只講 App，不講 CLI 和 IDE，目標(biāo)是讓你 10 分鐘內(nèi)知道：它能干什么、該怎么配、哪些設(shè)置最值得先改。

多圖預(yù)警，請準(zhǔn)備好流量

先弄清楚：Codex 其實有 4 個入口

官方介紹，其實有 4 中用法，注意下圖最下居中，它有網(wǎng)頁端

我理解：它們不是替代關(guān)系，而是同一套能力的不同入口。

區(qū)別不在“誰更強”，而在“你平時在哪兒工作”。

入口

更像什么

最適合的第一批用戶

App

本地指揮臺

想并行跑任務(wù)、看 diff、切 worktree 的開發(fā)者

CLI

終端主線

習(xí)慣命令行、想腳本化、想和現(xiàn)有 shell 工作流融合的人

IDE extension

編輯器內(nèi)副駕駛

長時間待在 VS Code、Cursor、Windsurf 里的人

Web

云端執(zhí)行面板

想把任務(wù)丟到后臺、接 GitHub、跑云端任務(wù)的人

主操作臺

安裝之后界面如下

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

我更愿意把它理解成一個本地開發(fā)任務(wù)調(diào)度臺，你可以在里面：

• 給 agent 下任務(wù)

• 跟蹤線程

• 看終端輸出

• 檢查代碼差異

• 做 Git 操作

• 在不同線程之間并行推進(jìn)不同工作

這一點，是它和普通聊天式 AI 工具最不一樣的地方

浮動彈出窗口：適合快速迭代

右上角，它還有一種使用模式——支持快捷鍵喚出，懸浮于桌面

這個設(shè)計我挺喜歡，它不會強迫你一直待在 App 主窗口里。

你可以把線程掛在瀏覽器、編輯器、設(shè)計稿、預(yù)覽頁面附近，邊看邊提需求，適合快速來回迭代。

如果你習(xí)慣一邊看頁面、一邊讓 agent 改代碼，這個模式很好用。

模型切換

底部模型可以切換，還有思考深度，越高效果越好，速度越慢

• 小任務(wù)、試探性任務(wù)：先用快一點的設(shè)置

• 重構(gòu)、復(fù)雜邏輯、長鏈路問題：再把思考深度拉高

右上角可以點擊切換終端

注意，它不是“整個 App 共用一個終端”，而是線程級別綁定的終端。
也就是說，每個線程都可以對應(yīng)一個與當(dāng)前項目或工作區(qū)綁定的內(nèi)置終端。

這意味著你可以在不離開 App 的情況下直接：

• 驗證更改

• 跑腳本

• 看日志

• 執(zhí)行 Git 操作

甚至，你還可以在這個終端里運行別的 agent。
也就是說，一個界面里同時配合使用 Codex App、Codex CLI，甚至 Claude Code、Gemini、OpenCode 之類的工具，都不是問題

差異面板：一定要養(yǎng)成看的習(xí)慣

創(chuàng)建終端右側(cè)是差異面板，顯示本地項目或工作樹檢查中的 Git 差異

因為很多人第一次用 agent，最容易犯的一個問題就是：

只看對話，不看改動。

但真正決定結(jié)果好壞的，不是它說了什么，而是它到底改了哪些文件、刪了什么、加了什么。

所以我自己的使用習(xí)慣是：

• agent 改完

• 先看 diff

• 再決定是繼續(xù)讓它改，還是自己接管

這樣安全感會高很多

內(nèi)置 Git 工具

Codex 應(yīng)用程序直接在應(yīng)用程序內(nèi)提供常見的 Git 功能，可以直接從 Codex 提交、推送并為本地和工作樹任務(wù)創(chuàng)建拉取請求。

這件事的價值，不只是“方便”，而是上下文不斷裂。
你不需要在“聊天—終端—Git 客戶端—代碼編輯器”之間頻繁來回切

線程：Codex App 的真正核心

先看左側(cè)工具欄，不同文件夾對應(yīng)不同項目

一個項目可以開 N 多個線程，不同線程做不同任務(wù)

官方解釋：線程是一個單一會話，你的提示加上后續(xù)的模型輸出和工具調(diào)用。一個線程可以包含多個提示。例如，你的第一個提示可能要求 Codex 實現(xiàn)一個功能，而后續(xù)的提示可能要求它添加測試。當(dāng) Codex 正在積極處理線程時，該線程被稱為“正在運行”。可以同時運行多個線程，但避免有兩個線程修改相同的文件。也可以稍后通過使用另一個提示來繼續(xù)線程。

我自己的理解更簡單：一個線程，就應(yīng)該只做一件事。

比如：

• 一個線程實現(xiàn)功能

• 一個線程補測試

• 一個線程修 lint 或類型問題

• 一個線程做重構(gòu)

• 一個線程只做代碼審查和計劃討論

這樣做的好處非常明顯：

1. 上下文更干凈

2. diff 更容易看

3. 后續(xù)遷移到 worktree 或云線程也更順

不建議一個線程里同時混著做三四件事

那樣前面聊的是功能實現(xiàn)，后面又插進(jìn)測試、文檔、部署問題，很快就會亂

自動化：把重復(fù)任務(wù)交給后臺

自動化這里可以設(shè)置不同的定時任務(wù)，可以是抓取信息，可以是定時分析日志

把一切重復(fù)、周期性的任務(wù)交給后臺自動執(zhí)行

剛開始用 Codex，我建議先把線程、本地模式、diff、Git 這些基礎(chǔ)鏈路跑順，再來碰自動化

技能

技能就是 SKills ，這里大量是我自己創(chuàng)建的

往下拉，也有官方推薦的 SKills

點擊新建 skills 時，它會自動跳轉(zhuǎn)，默認(rèn)使用 Skill Creator 創(chuàng)新，寫清楚自己的需求就行了

很多以前要靠 MCP 或手工配置解決的問題，已經(jīng)可以被一部分 Skills 覆蓋掉。

不是說 MCP 沒用了，而是對于很多普通用戶來說，Skills 的上手門檻更低，路徑也更短。

如果你只是想快速補齊某類能力，先看看有沒有現(xiàn)成 Skills，往往比從零折騰更省時間。

設(shè)置-常規(guī)

如果你第一次打開設(shè)置，不少人會有點懵

因為選項挺多，看起來哪里都能改

但我覺得真正值得優(yōu)先關(guān)注的，不多

然后進(jìn)入設(shè)置-常規(guī)，建議打開運行時防止系統(tǒng)休眠

Speed 我選了 Fast，優(yōu)點是快，缺點是 2 倍消耗

上圖默認(rèn)打開目標(biāo)，可以設(shè)置成你熟悉的工具，甚至可以使用 antigravity

跟進(jìn)行為有兩種模式，排隊 or 引導(dǎo)，它正在運行任務(wù)時，引導(dǎo)模式允許在任務(wù)執(zhí)行中注入新的指令，立即生效。排隊則是新指令要等當(dāng)前任務(wù)結(jié)束后才執(zhí)行。

如果你喜歡邊跑邊干預(yù)，選引導(dǎo)
如果你更想讓任務(wù)按順序穩(wěn)定執(zhí)行，選排隊

設(shè)置-Appearance

我沒動，看個人習(xí)慣，默認(rèn)就挺好，無不適感

如果你沒有特別強的界面偏好，這部分可以先放著，不是最優(yōu)先該折騰的地方

配置：Approval 和 Sandbox 決定了你有多“放手”

它詳細(xì)配置都在 config.toml 中

• Approval policy

• Sandbox setting

它們本質(zhì)上決定了一個問題：你愿意給 agent 多大權(quán)限

比如：

• 不放心，就把 Approval 設(shè)得更嚴(yán)格，很多動作都手動確認(rèn)

• 不放心，就把 Sandbox 設(shè)成只讀

• 如果你已經(jīng)很熟悉自己的環(huán)境和項目，再逐步放開權(quán)限

我自己比較激進(jìn)，基本會直接給高信任和 Full access

設(shè)置-個性化：能錦上添花，但不是剛需

它的個性化只有兩個，一個是親和，一個是務(wù)實

上面自定義指令，我參考了這位大佬的配置

實際感受還可以，缺點是更慢，消耗更多

設(shè)置-MCP 服務(wù)器

隨著 Skills 逐漸補上很多能力，MCP 對普通用戶來說，不再是剛需

我沒怎么搞，以前配置了很多，但現(xiàn)在 Skills 取代一大批，Playwright 肯定是必裝

設(shè)置-Git

我多數(shù)都是選擇本地模式

設(shè)置-環(huán)境

這里是對你添加的項目配置環(huán)境文件

設(shè)置-工作樹

僅對你使用工作樹模式時有效

工作樹主要作用：一個倉庫，多個并行文件夾，各跑各的分支

讓多個 agents 能同時工作而不發(fā)生沖突

回到操作頁面，線程的運行模式有幾種，前兩者是本地執(zhí)行

• 本地：直接在當(dāng)前項目目錄中工作

• 工作樹：在 Git 工作樹中隔離更改

• 云端：在配置好的云端環(huán)境中遠(yuǎn)程運行

本地模式可以遷移至工作樹

關(guān)于工作樹，最詳細(xì)的介紹：https://git-scm.com/docs/git-worktree

云線程：適合把任務(wù)丟到遠(yuǎn)端跑

云線程在隔離的環(huán)境中運行，Codex 會克隆你的倉庫并檢出它正在工作的分支。當(dāng)你想并行運行工作或從另一臺設(shè)備委派任務(wù)時，云線程很有用。要使用云線程與你的倉庫，先將代碼推送到 GitHub。

關(guān)聯(lián)之后就可以直接對你的 Github 倉庫進(jìn)行操作

這類模式適合什么時候用？我的理解是兩類場景：

1. 想并行委派任務(wù)

2. 想在另一臺設(shè)備之外，把任務(wù)掛到云端執(zhí)行

如果你要讓云線程操作你的倉庫，先把代碼推到 GitHub。

Slash 命令

對話框輸入 / 可以調(diào)出可用命令，最常用的是 /plan

這個命令很適合放在“真正開始改代碼之前”

它的價值不是幫你直接產(chǎn)出代碼，而是先把思路、步驟、邊界、風(fēng)險梳理清楚。
尤其是當(dāng)任務(wù)本身比較復(fù)雜時，先花一輪把計劃擰清楚，后面返工會少很多。

簡單說就是：

先讓 agent 和你對齊怎么做，再讓它開始做。

如果擔(dān)心它找不準(zhǔn) skills 也可以手動用 / 指定

上下文窗口

線程中的所有信息都必須適應(yīng)模型的不同上下文窗口

Codex 會監(jiān)控并報告剩余的空間，對于較長的任務(wù)，Codex 可能會通過總結(jié)相關(guān)信息并丟棄不太相關(guān)的細(xì)節(jié)來自動壓縮上下文。通過重復(fù)壓縮，Codex 可以在多個步驟上繼續(xù)處理復(fù)雜任務(wù)。

沒有額度了，這一步無法截圖展示了。

國產(chǎn)模型支持

不訂閱 ChatGPT 也可以用 Codex

修改兩個地方

~/.codex/auth.json

{

 "OPENAI_API_KEY": "sk-"

 }

~/.codex/config.toml

model_provider = ""  # 設(shè)置API供應(yīng)商
model = ""   

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

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

 

建議多看看官方博客

https://developers.openai.com/blog/topic/codex

寫的很淺，我本人也不算深度用戶，后續(xù)大家感興趣，我會再寫一篇使用技巧