OpenAI Codex 完整入門指南：對照 Claude Code 逐項拆解，執行模式、上下文工程、內置終端/瀏覽器、Computer Use 一文學完
整理版優先睇
OpenAI Codex 完整對照 Claude Code 指南：拆解執行模式、上下文工程、內置終端/瀏覽器等核心功能，點出兩者產品路線差異——Codex 偏向 IDE 富交互與生態集成，Claude Code 偏向純終端工程師手感。
呢篇文章係作者由 Claude Code 轉用 Codex 嘅經驗對照。作者早前由 Cursor 切換到 Claude Code 並長期使用，最近一個月正式轉用 Codex。佢留意到 AI Coding 工具圈形成兩個互不理解嘅迴音壁：一邊話 Claude Code 最強，另一邊話 Codex 最強。佢認為兩種工具雖然外觀相似，但底層產品哲學同 Agent 設計思路唔同，只用一種就會形成認知盲區。所以呢篇唔係 Codex 嘅單獨介紹，而係一份「令你具備並行使用兩套工具能力」嘅對照指南。
文章先介紹 Codex 嘅本質：一個能控制你電腦嘅 Coding Agent，除咗 bash 操控本地，仲可以用鼠標鍵盤驅動 macOS GUI 應用 (Computer Use)。底層主力模型係 GPT-5.5 同 GPT-5.4。對外提供四個入口：Codex App、VS Code 擴展、CLI、Codex Cloud。跟住逐一深入講解執行模式（Local / Cloud / Worktrees）、項目側欄同持久化上下文嘅三層結構、快捷鍵分類、模型與推理強度分層匹配、Prompting 四大支柱（Goal、Context、Constraints、Done When）、定製功能（agents.md、Skills、Plugins、MCP）、子 Agent 嘅雙重用途（並行加速同保護主線程）、IDE vs 終端嘅判斷、安全權限模型、Pow…
- OpenAI Codex 完整入門指南：對照 Claude Code…
- OpenAI Codex 完整入門指南：對照 Claude Code…
- OpenAI Codex 完整入門指南：對照 Claude Code…
- OpenAI Codex 完整入門指南：對照 Claude Code…
- OpenAI Codex 完整入門指南：對照 Claude Code…
執行模式與核心差異
Codex 嘅本質同 Claude Code 一樣，係一個具備 agentic loop 嘅 AI Agent，喺你部機讀、寫、運行代碼。但佢嘅操作面更闊：除咗 bash，仲可以用鼠標鍵盤直接驅動 macOS GUI 應用，即係 Computer Use。
Codex 出咗四個入口：Codex App、VS Code 擴展、CLI、Codex Cloud
執行位置可以喺右下角切換：Local 同 Claude Code 無本質分別；Cloud 必須連 GitHub，任務推上雲端；Worktrees 原生集成 Git worktree，同一項目並行兩套本地執行環境，公司項目幾乎一定會用。
- 1 Local：所有命令喺當前目錄跑，同終端無分別。
- 2 Cloud：任務推上雲端虛擬機，唔消耗本機資源。
- 3 Worktrees：將當前倉庫克隆到另一個分支目錄，同一項目並行開發唔互相污染。
上下文工程：從易碎品到資產
Codex App 嘅核心結構係 Project → Thread 兩層模型。頂層係項目，下面掛多個線程，每條線程獨立會話。線程俾 App 緩存，關 App 再開所有上下文都喺度，同終端一關窗口就死好唔同。
線程可以唔掛任何項目，作為自由嘅 Chats 做調研規劃
快捷鍵分四類：導航類（Ctrl+N 新建、Cmd+B 摺疊側欄等）、檢索類（Cmd+K 全局命令、Cmd+F 模糊搜索）、輸入類（Ctrl+M 語音聽寫、@ 引用檔案）、能力調用類（/ 內置原語、$ 用戶 Skills）。
- 導航：Ctrl+N、Cmd+B、Cmd+Opt+B、Cmd+J、Cmd+[ / Cmd+]
- 檢索：Cmd+K（全域命令面板）、Cmd+F（模糊搜索）
- 輸入：Ctrl+M（語音）、@ 引用檔案
- 能力調用：/ 內置原語、$ 用戶 Skills
Prompt 框架與個人化定製
Codex 官方文檔點名四大要素：Goal、Context、Constraints、Done When。其中 Context 建議少用 @ 顯式引用，靠模型自己做語義檢索更可靠，同 Claude Code 社區「喂越多文件越好」形成對照。
Done When 係魔法關鍵詞，俾 Agent 自檢標準，令佢從「我猜我做完了」變成「我能確認我做完了」
定製方面，agents.md 同 Claude 嘅 claude.md 等價，但 agents.md 係開源社區形成嘅標準命名，即使你而家用 Codex，寫喺 agents.md 更防遷移。Skills 係可複用工作流，Codex 內置 Marketplace，將應用層能力擴展推到日常使用。Plugins 係 Skills 超集，可打包 MCP 同其他能力，市場已覆蓋 Jira、GitLab、Microsoft 365 等。
- 1 agents.md：放模型自己睇 code 睇唔出嘅嘢，例如構建命令、PR 規範、團隊約定、遺留項目雷區。
- 2 Skills：用 skill creator 建立可複用工作流，內置 Marketplace 有 Sora、ImageGen、Docs、Playwright 等。
- 3 Plugins：Skills 超集，可打包 MCP，Plugins 市場已覆蓋九十幾個企業工具。
- 4 MCP：叫 Codex 自己裝，唔好手動配 JSON，話「裝一下 X MCP」就得。
子 Agent、IDE 優勢與安全權限
子 Agent 嘅常見用途係並行加速，但另一個同等重要嘅用途係保護主線程上下文。好多工具調用、日誌解析會向主線程傾倒噪聲 token，剝離到子 Agent 可防止 context rot。
子 Agent 係降級模型最自然嘅落腳點，例如調研型任務用 GPT-5.4 mini + low
IDE 形態嘅根本優勢係富渲染：計劃文檔可以排版下載、圖片直接預覽、diff 內聯評論、In-App Browser 可以直接睇 dev server 並圈點反饋、原生圖像生成 gpt-image-2 直接喺工作流內用。Computer Use 更加係直接喺 GUI 幫你點鼠標。
- Sandbox 等級：read-only / write / 默認權限 / full access，可全局+項目級疊加，對具體命令做白名單。
- Hooks 生命週期：session start、pre/post tool use、user prompt submit、agent stop。典型用法：post-tool-use 跑 lint、agent-stop 推桌面通知。
- 核心建議：唔好手寫 .toml，叫 Codex 自己讀配置、問你幾個問題寫出 hook。權限太嚴等於剝奪 Agent 嘅自主跑步時間。
生態集成與最佳實踐
Codex 比 Claude Code 更激進咁將 Agent 鋪入工程師日常工作流：GitHub PR 評論 @codex 觸發 code review、Slack @codex 抓取上下文修復問題、Linear 分配工單俾 Codex 接手。呢啲集成合起來傳達嘅信號係：Codex 想成為工程協作流裏嘅一等成員。
Code Review 面板係 Codex 嘅殺手鐧之一，內聯 diff review、stage/revert/request changes，直接打通 GitHub Pull Request
最佳實踐：一條線程做一件事，過長用 /compact 壓縮，想分叉用 /fork。常見錯誤包括反覆重複同一規則（應該沉澱入 agents.md），唔俾驗證標準，跳過 plan mode，權限太嚴，多線程改同一檔案唔開 worktree，自動化裏跑未打磨嘅 Skill。
- Worktrees：最大化 token 同時間利用，尤其同時壓幾個項目。
- Automations：內置 cron 調度，仲有線程級自動化——某條線程定時醒來繼續推進，唔使開新線程熱身。
- 內置終端：Agent 能夠直接讀取 build 失敗信息、dev server 日誌，支持多 terminal tabs 同 SSH remote。
- Git 面板：commit、自動生成 message、創建 PR、切換 draft 狀態，全部 UI 完成。
點解要專登講 Codex，而唔繼續講 Claude Code
好耐之前我由 Cursor 轉咗去 Claude Code 長用，以前都分享過好多 Claude Code 嘅文章，而最近一個月，我正式轉咗去 Codex。向外一望，AI Coding 工具圈正形成兩個互不理解嘅迴音壁——一邊堅信 Claude Code 最強，另一邊堅信 Codex 最強。呢兩種工具雖然外觀相似，但底層嘅產品哲學同 Agent 設計思路其實唔同，淨係用一種就會有認知盲區。
所以呢個唔係 Codex 嘅單獨介紹，而係一份「令你能夠並行使用兩套工具」嘅對照指南。咁嘅出發點決定咗敍述方式：每講一個 Codex 功能，幾乎都會順便提一句 Claude Code 喺同一點上嘅做法。
Codex 係咩：一個可以控制你電腦嘅 Coding Agent
唔講形態，Codex 嘅本質同 Claude Code 一樣——一個擁有 agentic loop 嘅 AI Agent，喺你部機上面讀、寫、執行代碼。分別係佢嘅「操作面」已經大幅拓寬咗：除咗經 bash 控制本地之外，佢仲可以用自己嘅鼠標同鍵盤直接控制 macOS 上嘅 GUI 應用 (Computer Use)，做原生 App 測試、跨應用工作流，唔再侷限於命令行可達嘅世界。所以「控制你電腦」而家要按字面理解。底層主力模型係 GPT-5.5 同 GPT-5.4 系列。
佢對外提供咗四個唔同形態嘅入口:
- Codex App（主要講述）：一個 Electron 桌面應用，外觀似 IDE 或者 ChatGPT；macOS 同 Windows 都已經正式支援
- VS Code 擴展：將 Codex 嵌入 VS Code 入面
- CLI：命令行版本，類似 Claude Code 嘅形態
- Codex Cloud：基於 OpenAI Agents SDK，喺雲端虛擬機入面執行。每個會話用 session ID 鎖定，可以「先掟上雲端跑，過一陣返嚟接管」
呢度要點出 Codex 嘅一個隱藏戰略傾向：佢嘅工作流刻意設計成「將工作推離本機」——大量功能圍繞 GitHub、圍繞雲端虛擬環境展開。Claude Code 偏向「同我嘅本地環境共生」，而 Codex 偏向「將 Agent 變成一個可以喺雲端、喺 Slack、喺 PR 評論入面獨立運轉嘅工種」。呢條主線喺後面嘅集成功能會成日出現。
Codex App 嘅三種執行模式：Local / Cloud / Worktrees
入到 Codex App 之後，每個項目右下角可以切換執行位置：
- Local：所有命令喺你當前目錄度執行，同 Claude Code 喺終端度執行無本質分別
- Cloud：一定要先將倉庫連到 GitHub。任務推上雲端虛擬機執行，本機唔消耗，亦唔阻塞
- Worktrees：原生集成 Git worktree——將當前倉庫複製到另一個分支目錄，令你喺同一個項目入面同時有兩套並行嘅本地執行環境
Worktree 呢個能力本來就係 Git 自帶嘅，但絕大多數人嫌麻煩從來唔用。Codex 將佢變成咗一等 UI。我嘅判斷係：對個人項目用處唔大，但喺公司項目度幾乎一定會用——因為公司代碼同一時間通常要並行推好多改動線，唔想佢哋互相污染。
真正嘅「殺手特性」：項目側邊欄 + 持久化上下文
呢點值得反覆強調：Codex App 嘅核心結構係 項目 (Project) → 線程 (Thread) 嘅兩層模型。
- 最頂層係項目，相當於「一個倉庫 / 一個工作目錄」
- 項目下面掛多個線程，每條線程相當於一個獨立嘅 Codex/Claude Code 會話實例
如果你淨係需要做調研、規劃、跨項目討論，線程都可以完全唔掛喺任何項目下面，作為一種自由嘅「Chats」存在。咁就將原來「線程一定要依附項目」嘅隱含限制拆走咗。
同終端使用方式相比，最關鍵嘅差異係：線程俾 App 本身緩存咗，熄 App 再開返，所有上下文都喺度。終端模式下，你一熄窗口、斷開 SSH，會話基本就死咗。
將呢個能力放返去我一直主張嘅 「上下文工程 (Context Engineering)」 框架入面睇，會發現 Codex App 實際上已經將上下文做成三層結構:
- 會話上下文——單條線程入面積累嘅信息
- 線程緩存——熄 App 唔會冇，長期保留每條線程作為可重用嘅資產
- Memory (跨會話記憶)——你嘅偏好、項目約定、成日糾正嘅風格會自動抽取並跨 session 重用
呢三層一旦疊起，意義就變咗：終端模式下上下文係易碎品，Codex App 令佢變成沉澱型資產。原本要靠 agents.md 硬編碼嘅「項目慣例」，而家有相當一部分可以俾 Memory 自己捕捉——你只需要糾正一次。
UI 度睇到呢條線程係 local、cloud 定 worktree，對鍾意「睇到狀態」嘅人好友好。但我自己因為已經將終端用到「好似 Vim 咁肌肉記憶化」，仍然偏好終端。
一定要記住嘅快捷鍵
可以歸納成四類：
- 導航類:
Ctrl+N新建線程，Cmd+B摺疊側欄，Cmd+Opt+B開關 Git 變更面板，Cmd+J開終端，Cmd+[/Cmd+]喺歷史度前後跳 - 檢索類:
Cmd+K係全局命令面板（設置、所有命令、跳轉都從呢度入），Cmd+F係模糊搜尋 - 輸入類:
Ctrl+M啟動 Codex 自帶嘅語音聽寫（都可以用 Whisper Flow），@引用文件嚟構建上下文 - 能力調用類:
/觸發 Codex 內置嘅「原語」斜槓命令；$觸發 用戶自定義 Skills ——呢個係同 Claude Code 一個有趣嘅分別，Claude Code 將 slash 當作所有命令嘅統一入口，Codex 就將「內置原語」同「用戶技能」用兩個唔同符號分開
模型與推理強度：兩個獨立維度
/models 列出可選模型：GPT-5.5（目前嘅日常主力，定位複雜編碼同知識型任務）、GPT-5.4、GPT-5.4 mini（官方推薦作為子 Agent 嘅默認模型）、Codex 系列；Max 套餐用戶多一個 Spark，主打極速。
但要強調嘅關鍵點係：模型本身只係一維，推理強度係另一維。每個模型都可以獨立設 low / medium / high / extra high 四級思考長度。真正嘅實戰習慣係將兩個維度結合埋一齊按任務分層匹配:
- 主線程默認 GPT-5.5 + medium，大多數任務到呢度就夠
- 子 Agent 直接降到 5.4 mini + low / medium——調研、日誌解析、跑 lint 呢啲唔需要頂級推理嘅工作，又快又平，仲順便保護主線程
- 只有真正嘅硬骨頭——大代碼庫、難搞嘅 bug、複雜依賴——先用 GPT-5.5 + extra high
- 將 extra high 當默認係典型嘅浪費：又慢、又燒 token、但收益唔明顯
- 模型同推理強度都可以喺線程級或子 Agent 級用自然語言指定，例如「呢條線程之後淨係做細修改，轉做 medium」
另外有個 Fast 模式,輸入 fast ，一開就有——用更高 token 消耗換反應速度，定位係「工作 deadline 趕先開」嘅後備擋。
呢一節背後嘅思想其實好重要：喺 AI 編碼工具度，「用咩級別嘅算力解咩級別嘅問題」已經變成一種新嘅工程素養。Codex 將呢套調節做成顯式嘅滑塊，等於鼓勵用戶養成呢種習慣。
Prompting 嘅「四大支柱」
Codex 官方文檔入面點名嘅四要素，可以講成一個完整框架：
- Goal——你到底想做咩
- Context——相關嘅文件、文件夾、文檔。呢度有一個反直覺嘅建議：少用
@符號顯式引用。除非你已經精準知道目標文件喺邊，否則將工作交俾模型自己做語義檢索，往往比人手指邊個文件更可靠。呢點同 Claude Code 社區入面「喂越多文件越好」嘅做法形成對比 - Constraints——框架、架構、團隊約定，呢啲代碼本身睇唔出嘅隱性規則
- Done When——完成判據。呢個係 Codex 文檔入面嘅「魔法關鍵詞」，本質係俾 Agent 一個自檢標準
第四條值得講多少少。俾 Agent 驗證標準，係單點提升 Agent 質量最有效嘅槓桿——令 Agent 由「我估我做曬」變成「我可以確認我做曬」，呢個係佢有自癒、自迭代能力嘅前提。Codex 已經將呢件事進一步產品化為持久化嘅 /goal 工作流：你可以顯式創建一個帶驗證標準嘅目標，喺 TUI 度 create / pause / resume，跨線程追蹤佢嘅狀態。所以「Done When」唔再依賴你每次都記得寫入 prompt，而係變成一個一等公民嘅工程對象——呢個反過來印證咗嗰條原則。
之後嘅延伸建議係：Plan Mode 幾乎係所有非瑣碎任務嘅正確起點(Shift+Tab 切換，類似 Claude Code)。先在 plan mode 度收集曬上下文、傾掂個 spec，再切返去做執行——呢個係而家工程師最應該養成嘅習慣之一。
定製：將通用工具變成「你嘅」工具
agents.md
同 Claude 嘅 claude.md 等價，但有一個有趣嘅事實：agents.md 是開源社區已經實際上形成咗標準命名——Open Code 等其他工具都認佢，而 Claude Code 只認 .claude 目錄。所以即使你而家用 Codex，將規則寫喺 agents.md 入面係更「防遷移」嘅選擇。
入面應該寫咩？判斷標準係：「模型自己睇代碼睇唔出」嘅所有嘢——構建命令、PR 規範、團隊代碼評審約定，尤其係遺留項目入面嘅地雷（「呢個目錄唔好搞」、「呢種寫法歷史原因唔好重構」）。
Skills
可重用嘅工作流，用 skill creator 創建。Codex 內置一個好顯眼嘅 Marketplace（Sora、ImageGen、Docs、Playwright 等）。呢度有一個產品取向嘅差異：Claude 都有連接器市場，但收得比較深；Codex 將 Skills 同 Plugins 主動推到用戶面前——呢個係 Codex 想令「應用層能力擴展」成為日常使用嘅一部分，而唔係高級用戶先用到嘅隱藏功能。
Plugins
Skills 嘅超集，可以打包 MCP 同其他能力。Plugin 市場而家已經覆蓋 Jira、GitLab、Microsoft 365 等主流企業工具棧，數量一次過擴到九十幾個。呢件事唔可以單單當作「多咗插件」：佢同後面「生態集成」嗰條戰略主線係同一件事——Codex 想令 Agent 進入工程師每日打開嘅每一個 SaaS 工具，而唔淨係 GitHub / Slack / Linear 三間。
MCP
同其他工具一致嘅 MCP。一個反覆強調嘅原則：叫 Codex 自己裝——唔好手動改 JSON，同佢講「裝個 X MCP」，俾 Agent 管理自己嘅環境，係呢一代工具嘅正確用法。
子 Agent：上下文保護比並行更重要
子 Agent 嘅常見講法係「用嚟並行加速」，但同等重要嘅係第二個用途：保護主線程嘅上下文。
好多工具調用、調研、日誌解析過程會向主線程倒大量「噪聲 token」。將呢啲任務剝離到子 Agent 執行，主線程淨係接收結論摘要——呢個就係 Anthropic 圈子入面講嘅「context rot」問題嘅對策。
子 Agent 亦係降級模型最自然嘅落腳點。好似影片入面示範嘅：「開一個子 Agent 調研呢個 App 嘅色彩理論，記得用 GPT-5.4 mini」——調研型任務唔需要頂級推理，用 mini 反而更快、更平，仲順便保護主線程。
IDE vs 終端：一個誠實嘅判斷
IDE 形態（Codex App）嘅根本優勢係富渲染，而且呢個優勢喺最近幾個月進一步拉開咗：
- 計劃文檔可以排版、可以下載，圖片可以直接預覽，diff 可以內聯點開評論，各種交互按鈕直接做入 UI
- In-App Browser——你喺 Codex 裏面可以直接打開本地 dev server 或者公網頁面，對元素圈點評論，反饋直接餵俾 Agent。前端同遊戲開發嘅「睇效果 → 俾反饋 → 改代碼」閉環第一次喺編碼工具入面打通
- 原生圖像生成(
gpt-image-2）——mockup、UI 概念、素材喺工作流入面直接生成同迭代，唔使再切到外部畫圖工具 - 加上前面提到嘅 Computer Use——Codex 直接喺 GUI 度幫你㩒鼠標
終端形態（CLI）嘅天花板就係 TUI——再靚都只係 ASCII。我情感上仍然鍾意終端，但理性判斷係：長遠嚟睇 IDE 形態會贏。理由唔係工程師羣體倒戈，而係新入場嘅人羣結構變咗——越嚟越多想「整嘢」嘅人本身唔係軟件工程師，佢哋要掣、要預覽、要可視化嘅 review。呢一波人羣嘅數量會遠大於核心工程師，所以產品演化嘅引力一定指向 IDE 嗰邊。而當瀏覽器、圖像生成、Computer Use 呢啲能力都接入嘅時候，純 TUI 形態嘅差距已經唔只係體驗問題，而係能力天花板問題。
安全：Sandbox、Approvals、Hooks
Codex 嘅權限模型分兩層。
Sandbox 等級：read-only / write / 默認權限 / full access（相當於 Claude 嘅 --dangerously-skip-permissions）。配置可以全局 + 項目級疊加，仲可以針對具體命令做細粒度白名單（例如常用嘅 git 命令永遠放行）。
Hooks 生命週期：session start、pre-tool-use、post-tool-use、user-prompt-submit、agent-stop。典型用法兩個：
post-tool-use跑 lint，令代碼改完自動過 linteragent-stop推送桌面通知，長任務跑完唔使一直睇住
操作上嘅核心建議依然係嗰條：唔好手寫 .toml，叫 Codex 自己讀配置、問你幾個問題、將 hook 寫出嚟。
權限呢件事嘅真正意義係反覆點出嘅槓桿原理：Agent 可以自主跑嘅時間越長，你嘅槓桿越大——你可以騰出個腦去做其他嘢，或者並行理多個任務。每樣嘢都要 approve 嘅設定，等於將 Agent 降級成一個「打字快啲嘅命令補全」。
Power User 功能羣
Worktrees
之前講過，呢度再強調一次佢嘅最大價值係 token 同時間嘅最大化利用——尤其當你同時壓住幾個項目嘅時候。
Automations（自動化 / Cron）
Codex App 內置 cron 調度，任務可以調用項目入面嘅 Skills 同上下文，OpenAI 仲預設咗 /dream 之類嘅「定期腦暴」模板。但比 cron 更值得用嘅係線程級自動化：你可以令某條已經積咗好多上下文嘅線程定時被喚醒並繼續推進——而唔係每次都開新線程由零開始熱身。呢一步將「線程係上下文資產」呢個理念落到自動化層。
由此帶嚟嘅判斷係：n8n 呢類純工作流編排工具可能正被呢種形態吞噬。原本要靠節點拖拽嘅嘢，而家 Codex App 一個 cron + 一段 prompt + 項目入面嘅 Skills 就做到。當然現實限制係：本機自動化要求電腦長開，而雲端自動化仲喺度開發中。
內置終端
不再只係「普通終端嵌入 App」，已經變成 Agent 嘅眼同擴展手臂。Codex 可以直接讀取集成終端嘅輸出——build 失敗信息、dev server 日誌、長命令嘅中間狀態都睇到，唔使你複製貼上；同時支援多個 terminal tabs 和 SSH remote 連接，即係 Codex App 嘅工作目標可以係一部遠端機器，本地 Mac 只係控制枱。
嗰個「Codex App 跑 Claude Code」嘅遞歸循環依然玩到，但更值得做嘅係：用 SSH remote 令 Codex 喺雲上長跑。
Code Review 面板
呢個係 Codex 嘅「殺手鐧之一」。佢支援：
- 內聯 diff review
- 直接喺某行講「呢度改嚇」，Agent 根據呢個迭代
- stage / revert / request changes 都喺同一個面板度
更加關鍵嘅係，呢套面板已經直接打通咗 GitHub Pull Request——你可以喺 Codex 入面好似喺 GitHub Web 度咁審 PR，行級評論會真實寫返落 PR。配合後面 @codex 嘅 PR 集成，「AI 審 + 人審」喺 Codex 入面合成同一個工作面。呢個正係目前所有終端方案最缺嘅嘢——你只能靠 Vim diff、跳到 VS Code、或者轉去 Cursor 嚟睇。Codex 將呢個體驗直接做入主流程，係佢瞄準非純工程師人羣嘅關鍵產品決策。
語音輸入同截圖拖放
語音之前講過；截圖直接拖入對話框作為視覺上下文，用嚟做設計反饋或者 bug 重現好好用。
Git 一等公民
頂部有完整嘅 Git 操作面板：commit、自動生成 message（留空就俾 AI 寫）、創建 PR、切 draft 狀態，都喺 UI 度完成。呢種「細位嘅體貼」先係普通用戶揀 Codex 嘅真正原因。
外部生態集成：Codex 嘅戰略主戰場
呢一節回應開篇埋落嘅伏筆。Codex 比 Claude Code 更加激進咁鋪入工程師日常工作流：
- GitHub PR：喺 PR 評論度
@codex，觸發代碼 review，相當於 GitHub 入面一個原生角色 - Slack:
@codex：拎取 Slack 消息上下文，開始嘗試修復對應問題 - Linear：將工單分配畀 Codex，佢會接手 triage 並實際推進
呢啲集成單睇每一個都唔算革命性，但合埋一齊傳達嘅產品信號好清晰：Codex 想成為工程協作流入面嘅一等成員——同工程師平等咁存在於 GitHub、Slack、Linear 入面，而唔係只係喺工程師本機嘅終端入面。呢個係佢同 Claude Code 喺戰略上嘅真正分岔。
最佳實踐與常見錯誤
線程管理嘅規則
- 一條線程做一件事，跨任務就開新線程
- 線程太長用
/compact壓縮 - 想分叉討論用
/fork - 呢一切嘅本質都係保護主上下文窗口
- 長遠方向係起更多 Agent 同「harness（保姆架構）」，令線程可以更長時間無人值守
最常見嘅錯誤
- 成日喺 prompt 入面重複同一規則——呢個係信號：應該將佢沉澱落
agents.md（或者等 Memory 自己學識） - 唔俾 Agent 驗證標準——見前面「Done When」
- 跳過 plan mode——值得做嘅任務幾乎都應該先 plan
- 權限校得太緊——等於剝奪 Agent 嘅「自主跑步時間」
- 多線程改同一個檔案唔開 worktree——一定撞車
- 自動化入面跑未打磨好嘅 Skill——「自動化爛活只會令爛活批量產生」
收尾：對行業嘅一個判斷
跳出工具討論，將視角拉遠到行業層面。引用 Jevons 悖論：當一種資源變得更平更高效，總需求往往唔跌反升。煤炭、電力、帶寬都驗證過呢條規律。
將呢條規律套入 AI 編碼：雖然裁員潮明顯、「軟件工程已死」嘅論調流行，但長遠睇 AI 編碼唔係消滅工程師崗位，而係將「整嘢嘅能力」擴散到一個數量級更大嘅人羣入面。呢個亦反過嚟解釋咗點解我認為 IDE 形態會贏：新入場嘅人需要可視化、需要掣、需要 review 面板，而唔係 vim 同 ASCII。
再進一步睇，Codex 呢一年嘅產品演化方向已經唔只係「AI 編碼工具」——Background Computer Use 將工具空間擴到整個 GUI、In-App Browser 接入 web、原生圖像生成接入設計、跨 SaaS 插件接入協作、Memory 將上下文沉澱到跨會話——呢啲組合埋一齊更接近 OpenAI 自己講嘅 「agentic workspace」，甚至有人開始叫佢做 super app。Jevons 悖論喺呢度有佢嘅另一面：編碼呢個動詞本身正被泛化——更加多人想做嘅唔係「寫代碼」，而係「驅動一個可以整嘢嘅 Agent 工作站」。Codex 而家卡位嘅，係呢個新品類嘅入口。
呢個係一個相對樂觀但有結構支撐嘅判斷，唔係簡單嘅辯護。同唔同意係另一回事，但呢個論證框架本身值得記住。
一句話提煉
Codex 同 Claude Code 表面相似，底層路線唔同。Claude 偏向純終端、工程師手感；Codex 偏向 IDE 富交互，並將 Agent 推進 GitHub / Slack / Linear 呢啲協作工具入面，瞄準嘅係「想整嘢但唔想學曬全部工程儀式」嘅更大人羣。掌握「四大支柱 prompt + Plan Mode + agents.md + Worktree + 子 Agent 模型分級 + Code Review 面板」呢個組合，就可以逼近 Codex 嘅能力上限——同時亦理解咗 AI 編碼工具未來幾年嘅產品分岔點喺邊。
相關資源推薦
OpenAI「Codex for Work」精讀：從入門到自動化嘅完整路徑（附 10 個真實落地場景——簡報、週報、PPT、月結、續約管理...）
OpenAI Codex 完整教程 2026：100 分鐘，四個關鍵概念 + 六個實戰項目
為什麼要專門講 Codex,而不是繼續講 Claude Code
很早以前我從 Cursor 切換到 Claude Code 並長期使用,以前也分享過很多 Claude Code 文章,而最近一個月,我正式切換到了 Codex。而向外看,AI Coding 工具圈正在形成兩個互不理解的迴音壁——一邊堅信 Claude Code 最強,另一邊堅信 Codex 最強。這兩種工具雖然外觀相似,但底層的產品哲學和 Agent 設計思路其實不同,只用一種就會形成認知盲區。
所以這不是 Codex 的單獨介紹,它是一份"讓你具備並行使用兩套工具能力"的對照指南。這個出發點決定了敍述方式:每講一個 Codex 功能,幾乎都會順手提一句 Claude Code 在同一個點上的做法。
Codex 是什麼:一個能控制你電腦的 Coding Agent
拋開形態不談,Codex 的本質和 Claude Code 一樣——一個具備 agentic loop 的 AI Agent,在你的機器上讀、寫、運行代碼。區別是它的"操作面"已經被顯著拓寬了:除了通過 bash 控本地之外,它還能用自己的鼠標和鍵盤直接驅動 macOS 上的 GUI 應用 (Computer Use),做原生 App 測試、跨應用工作流,不再受限於命令行可達的世界。所以"控制你電腦"現在要按字面意思理解。底層主力模型是 GPT-5.5 與 GPT-5.4 系列。
它對外提供了四個不同形態的入口:
- Codex App(主要講述):一個 Electron 桌面應用,外觀接近 IDE 或 ChatGPT;macOS 與 Windows 都已正式支持
- VS Code 擴展:把 Codex 嵌入到 VS Code 裏
- CLI:命令行版本,類似 Claude Code 的形態
- Codex Cloud:基於 OpenAI Agents SDK,運行在雲端虛擬機裏。每個會話用 session ID 錨定,可以"先扔到雲端跑,過會兒回來接管"
這裏要點出 Codex 的一個隱藏戰略傾向:它的工作流被刻意設計成"把工作推離本機"——大量功能圍繞 GitHub、圍繞雲端虛擬環境展開。Claude Code 偏向"和我的本地環境共生",而 Codex 偏向"把 Agent 變成一個可以在雲端、在 Slack、在 PR 評論裏獨立運轉的工種"。這條主線在後面的集成功能裏會反覆出現。
Codex App 的三種執行模式:Local / Cloud / Worktrees
進入 Codex App 後,每個項目右下角可以切換執行位置:
- Local:所有命令在你當前目錄裏跑,和 Claude Code 在終端裏跑沒本質區別
- Cloud:必須先把倉庫連到 GitHub。任務推到雲端虛擬機執行,本機不消耗,也不阻塞
- Worktrees:原生集成 Git worktree——把當前倉庫克隆到另一個分支目錄,讓你在同一個項目裏同時擁有兩套並行的本地執行環境
Worktree 這個能力本來就是 Git 自帶的,但絕大多數人嫌麻煩從不用。Codex 把它做成了一等 UI。我的判斷是:對個人側項目用處不大,但在公司項目裏幾乎一定會用——因為公司代碼同一時間往往要並行推進多條改動線,不希望它們互相污染。
真正的"殺手特性":項目側邊欄 + 持久化上下文
這一點值得反覆強調:Codex App 的核心結構是 項目(Project) → 線程(Thread) 的兩層模型。
- 頂層是項目,相當於"一個倉庫 / 一個工作目錄"
- 項目下掛多個線程,每條線程相當於一個獨立的 Codex/Claude Code 會話實例
如果你只需要做調研、規劃、跨項目討論,線程也可以完全不掛在任何項目下,作為一種自由的"Chats"存在。這就把原來"線程必須依附項目"的隱含約束拆掉了。
和終端使用方式相比,最關鍵的差異是:線程是被 App 本身緩存的,關掉 App 再打開,所有上下文都在。終端模式下,你一旦關閉窗口、斷開 SSH,會話基本就死了。
把這個能力放回到我一直主張的 "上下文工程(Context Engineering)" 框架裏看,會發現 Codex App 實際上已經把上下文做成了三層結構:
- 會話上下文——單條線程內累積的信息
- 線程緩存——關 App 不丟,長期保留每條線程作為可複用的資產
- Memory(跨會話記憶)——你的偏好、項目約定、反覆糾正的風格被自動抽取並跨 session 複用
這三層一旦疊起來,意義就變了:終端模式下上下文是易碎品,Codex App 讓它成了沉澱型資產。原本要靠 agents.md 硬編碼的"項目慣例",現在有相當一部分可以讓 Memory 自己捕獲——你只需要糾正一次。
UI 裏能看出這條線程是 local、cloud 還是 worktree,對喜歡"看得見狀態"的人非常友好。但我自己因為已經把終端用得"像 Vim 一樣肌肉記憶化",仍然偏好終端。
必須記住的快捷鍵
可以歸納為四類:
- 導航類:
Ctrl+N新建線程,Cmd+B摺疊側欄,Cmd+Opt+B開關 Git 變更面板,Cmd+J開終端,Cmd+[/Cmd+]在歷史裏前後跳 - 檢索類:
Cmd+K是全局命令面板(設置、所有命令、跳轉都從這進),Cmd+F是模糊搜索 - 輸入類:
Ctrl+M啓動 Codex 自帶的語音聽寫(也可以用 Whisper Flow),@引用文件來構建上下文 - 能力調用類:
/觸發 Codex 內置的"原語"斜槓命令;$觸發 用戶自定義 Skills ——這是它和 Claude Code 一個有趣的差別,Claude Code 把 slash 當作所有命令的統一入口,Codex 則把"內置原語"和"用戶技能"用兩個不同符號分開
模型與推理強度:兩個獨立維度
/models 列出可選模型:GPT-5.5(目前的日常主力,定位複雜編碼與知識型任務)、GPT-5.4、GPT-5.4 mini(被官方推薦為子 Agent 的默認模型)、Codex 系列;Max 套餐用戶多一個 Spark,主打極速。
但要強調的關鍵點是:模型本身只是一維,推理強度是另一維。每個模型都可以獨立設置 low / medium / high / extra high 四檔思考長度。真正的實戰習慣是把兩個維度合在一起按任務分層匹配:
- 主線程默認 GPT-5.5 + medium,大多數任務到此為止
- 子 Agent 直接降到 5.4 mini + low / medium——調研、日誌解析、跑 lint 這些不需要頂級推理的活,既快又便宜,還順便保護主線程
- 只有真正的硬骨頭——大代碼庫、難定位的 bug、複雜依賴——才動 GPT-5.5 + extra high
- 把 extra high 當默認是典型的浪費:既慢、又燒 token、收益卻不明顯
- 模型與推理強度都可以在線程級或子 Agent 級用自然語言指定,比如"這條線程後面只做小改動,改成 medium"
此外有個 Fast 模式,輸入 fast 即可開啓——以更高 token 消耗換響應速度,定位是"在工作 deadline 緊的時候才點亮"的備用擋。
這一節背後的思想其實很重要:在 AI 編碼工具裏,"用什麼級別的算力解什麼級別的問題"已經變成一種新的工程素養。Codex 把這套調節做成顯式的滑塊,等於在鼓勵用戶養成這種習慣。
Prompting 的"四大支柱"
Codex 官方文檔裏點名的四要素,可以講成一個完整框架:
- Goal——你到底要做什麼
- Context——相關的文件、文件夾、文檔。這裏有一個反直覺的建議:少用
@符號顯式引用。除非你已經精準知道目標文件在哪,否則把工作交給模型自己去做語義檢索,往往比人手指文件更可靠。這一點和 Claude Code 社區裏"喂越多文件越好"的做法形成對照 - Constraints——框架、架構、團隊約定,這些代碼本身看不出來的隱性規則
- Done When——完成判據。這是 Codex 文檔裏的"魔法關鍵詞",本質是給 Agent 一個自檢標準
第四條值得多說一句。給 Agent 驗證標準,是單點提升 Agent 質量最有效的槓桿——它讓 Agent 從"我猜我做完了"變成"我能確認我做完了",這是它具備自愈、自迭代能力的前提。Codex 已經把這件事進一步產品化為持久化的 /goal 工作流:你可以顯式創建一個帶驗證標準的目標,在 TUI 裏 create / pause / resume,跨線程跟蹤它的狀態。所以"Done When"不再依賴你每次都記得寫進 prompt,而是變成了一個一等公民的工程對象——這反過來印證了那條原則。
緊接着的延伸建議是:Plan Mode 幾乎是所有非瑣碎任務的正確起點(Shift+Tab 切換,類似 Claude Code)。先在 plan mode 裏把上下文收集完、把 spec 談攏,再切換到執行——這是今天工程師最該養成的習慣之一。
定製:讓通用工具變成"你的"工具
agents.md
和 Claude 的 claude.md 等價,但有個有意思的事實:agents.md 是開源社區已經在事實上形成的標準命名——Open Code 等其他工具也認它,而 Claude Code 只認 .claude 目錄。所以即使你目前用 Codex,把規則寫在 agents.md 裏是更"防遷移"的選擇。
裏面應該寫什麼?判斷標準是:"模型自己看代碼看不出來"的所有東西——構建命令、PR 規範、團隊代碼評審約定,特別是遺留項目裏的雷區("這個目錄別動"、"這種寫法歷史原因不要重構")。
Skills
可複用的工作流,用 skill creator 創建。Codex 內置一個相當顯眼的 Marketplace(Sora、ImageGen、Docs、Playwright 等)。這裏有一個產品取向上的差異:Claude 也有連接器市場,但藏得比較深;Codex 把 Skills 和 Plugins 主動推到用戶臉上——這是 Codex 想讓"應用層能力擴展"成為日常使用的一部分,而不是高級用戶才碰的隱藏功能。
Plugins
Skills 的超集,可以打包 MCP 和其他能力。Plugin 市場目前已經覆蓋 Jira、GitLab、Microsoft 365 等主流企業工具棧,數量一次性擴到了九十多個。這件事不能只當作"插件多了":它和後面"生態集成"那條戰略主線是同一回事——Codex 想讓 Agent 進入工程師每天打開的每一個 SaaS 工具,而不只是 GitHub / Slack / Linear 三家。
MCP
和其他工具一致的 MCP。一個反覆強調的原則:讓 Codex 自己裝——別手動配 JSON,告訴它"裝一下 X MCP",讓 Agent 管理自己的環境,是這一代工具的正確用法。
子 Agent:上下文保護比並行更重要
子 Agent 的常見敍述是"用於並行加速",但同等重要的是第二個用途:保護主線程的上下文。
很多工具調用、調研、日誌解析過程會向主線程傾倒大量"噪聲 token"。把這些任務剝離到子 Agent 裏執行,主線程只接收結論摘要——這就是 Anthropic 圈子裏說的"context rot"問題的對策。
子 Agent 也是降級模型最自然的落腳點。比如視頻裏演示的:"起一個子 Agent 調研這個 App 的色彩理論,記得用 GPT-5.4 mini"——調研型任務不需要頂級推理,用 mini 反而更快、更便宜,還順便保護了主線程。
IDE vs 終端:一個誠實的判斷
IDE 形態(Codex App)的根本優勢是富渲染,而且這個優勢在最近幾個月被進一步拉開了:
- 計劃文檔可以排版、可以下載,圖片可以直接預覽,diff 可以內聯點開評論,各種交互按鈕直接做進 UI
- In-App Browser——你可以在 Codex 裏直接打開本地 dev server 或公網頁面,對元素圈點評論,反饋直接餵給 Agent。前端和遊戲開發的"看效果 → 提反饋 → 改代碼"閉環第一次在編碼工具裏被打通
- 原生圖像生成(
gpt-image-2)——mockup、UI 概念、素材在工作流內直接生成與迭代,不再需要切到外部畫圖工具 - 加上前面提到的 Computer Use——Codex 直接在 GUI 裏替你點鼠標
終端形態(CLI)的天花板就是 TUI——再炫也只是 ASCII。我情感上仍然偏愛終端,但理性判斷是:長期來看 IDE 形態會贏。理由不是工程師羣體倒戈,而是新進場的人羣結構變了——越來越多想"造東西"的人本身不是軟件工程師,他們要按鈕、要預覽、要可視化的 review。這一波人羣的體量會遠大於核心工程師,所以產品演化的引力一定指向 IDE 一側。而當瀏覽器、圖像生成、Computer Use 這些能力都接進來,純 TUI 形態的差距已經不只是體驗問題,而是能力天花板問題。
安全:Sandbox、Approvals、Hooks
Codex 的權限模型分兩層。
Sandbox 等級:read-only / write / 默認權限 / full access(相當於 Claude 的 --dangerously-skip-permissions)。配置可以全局 + 項目級疊加,並能針對具體命令做細粒度白名單(比如常用的 git 命令永遠放行)。
Hooks 生命週期:session start、pre-tool-use、post-tool-use、user-prompt-submit、agent-stop。典型用法兩個:
post-tool-use跑 lint,讓代碼改完自動過 linteragent-stop推送桌面通知,長任務跑完了不用一直盯着
操作上的核心建議依然是那一條:不要手寫 .toml,讓 Codex 自己讀配置、問你幾個問題、把 hook 寫出來。
權限這件事的真正意義是反覆點出的槓桿原理:Agent 能自主跑的時間越長,你的槓桿越大——你能騰出腦子去做別的事,或者並行管多個任務。事事都要 approve 的設置,等於把 Agent 降級成了一個"打字快一點的命令補全"。
Power User 功能羣
Worktrees
前面講過,這裏再次強調它的最大價值是 token 與時間的最大化利用——尤其當你同時壓着幾個項目的時候。
Automations(自動化 / Cron)
Codex App 內置 cron 調度,任務能調用項目裏的 Skills 和上下文,OpenAI 還預置了 /dream 之類的"週期性腦暴"模板。但比 cron 更值得用的是線程級自動化:你可以讓某條已經積累了厚上下文的線程定時被喚醒並繼續推進——而不是每次都開新線程從零熱身。這一步把"線程是上下文資產"這個理念落到了自動化層。
由此帶來的判斷是:n8n 這一類純工作流編排工具可能正在被這種形態吃掉。原本要靠節點拖拽的事情,現在 Codex App 一個 cron + 一段 prompt + 項目內的 Skills 就能做。當然現實約束是:本機自動化要求電腦常開,而云端自動化還在路上。
內置終端
不再只是"普通終端嵌進 App",它已經變成了 Agent 的眼睛和擴展手臂。Codex 能直接讀取集成終端的輸出——build 失敗信息、dev server 日誌、長跑命令的中間狀態都能被看見,不用你複製粘貼;同時支持多 terminal tabs 和 SSH remote 連接,意味着 Codex App 的工作目標可以是一台遠端機器,本地 Mac 只是控制枱。
那個"Codex App 跑 Claude Code"的遞歸循環依然能玩,但更值得做的是:用 SSH remote 讓 Codex 在雲上長跑。
Code Review 面板
這是 Codex 的"殺手鐧之一"。它支持:
- 內聯 diff review
- 直接在某行說"這裏改一下",Agent 據此迭代
- stage / revert / request changes 都在一個面板裏
更關鍵的是,這套面板已經直接打通了 GitHub Pull Request——你可以在 Codex 裏像在 GitHub Web 上一樣審 PR,行級評論會真實寫回 PR。配合後面 @codex 的 PR 集成,"AI 審 + 人審"在 Codex 裏被合成了同一個工作面。這正是目前所有終端方案最缺的一塊——你只能靠 Vim diff、跳到 VS Code、或者切到 Cursor 來看。Codex 把這個體驗直接做進主流程,是它瞄準非純工程師人羣的關鍵產品決策。
語音輸入和截圖拖拽
語音前面講過;截圖直接拖進對話框作為視覺上下文,用來做設計反饋或 bug 復現非常好用。
Git 一等公民
頂部有完整的 Git 操作面板:commit、自動生成 message(留空就讓 AI 寫)、創建 PR、切 draft 狀態,都在 UI 裏完成。這種"小處的體貼"才是普通用戶選 Codex 的真正原因。
外部生態集成:Codex 的戰略主戰場
這一節回應了開篇埋下的伏筆。Codex 比 Claude Code 更激進地往工程師日常工作流裏鋪:
- GitHub PR:在 PR 評論裏
@codex,觸發代碼 review,相當於 GitHub 裏的一個原生角色 - Slack:
@codex抓取 Slack 消息上下文,開始嘗試修復對應問題 - Linear:把工單分配給 Codex,它會接手 triage 並實際推進
這些集成單看每一個都不算革命,但合起來傳達的產品信號是清晰的:Codex 想成為工程協作流裏的一等成員——和工程師同等地存在於 GitHub、Slack、Linear 裏,而不是隻待在工程師本機的終端裏。這是它和 Claude Code 在戰略上的真正分岔。
最佳實踐與常見錯誤
線程管理的規則
- 一條線程做一件事,跨任務就開新線程
- 線程過長用
/compact壓縮 - 想分叉討論用
/fork - 這一切的本質都是保護主上下文窗口
- 長期方向是建更多的 Agent 與"harness(保姆架構)",讓線程能更長時間無人值守
最常見的錯誤
- 反覆在 prompt 裏重複同一規則——這是個信號:該把它沉澱進
agents.md(或者放任 Memory 自己學走) - 不給 Agent 驗證標準——見前面 "Done When"
- 跳過 plan mode——值得做的任務幾乎都該先 plan
- 權限設置太嚴——等於剝奪了 Agent 的"自主跑步時間"
- 多線程改同一文件不開 worktree——必然撞車
- 自動化裏跑沒打磨好的 Skill——"自動化爛活只會讓爛活批量產生"
收尾:對行業的一個判斷
跳出工具討論,把視角拉遠到行業層面。引用 Jevons 悖論:當一種資源變得更便宜更高效,總需求往往不降反升。煤炭、電力、帶寬都驗證過這條規律。
把這條規律套到 AI 編碼上:儘管現在裁員潮明顯、"軟件工程已死"的論調流行,但長期看 AI 編碼不是在消滅工程師崗位,而是在把"造東西的能力"擴散到一個數量級更大的人羣裏。這也回過頭解釋了為什麼我認定 IDE 形態會贏:新進場的人需要可視化、需要按鈕、需要 review 面板,而不是 vim 和 ASCII。
更進一步看,Codex 這一年的產品演化方向已經不只是"AI 編碼工具"——Background Computer Use 把工具空間擴到整個 GUI、In-App Browser 接進 web、原生圖像生成接進設計、跨 SaaS 插件接進協作、Memory 把上下文沉澱到跨會話——這些組合起來更接近 OpenAI 自己說的 "agentic workspace",甚至有人開始稱它為 super app。Jevons 悖論在這裏有它的另一面:編碼這個動詞本身正在被泛化——更多人想做的不是"寫代碼",而是"驅動一個能造東西的 Agent 工作站"。Codex 正在卡位的,是這個新品類的入口。
這是一個相對樂觀但有結構支撐的判斷,不是簡單的辯護。是否同意是另一回事,但這個論證框架本身值得記住。
一句話提煉
Codex 和 Claude Code 表面相似,底層路線不同。Claude 偏純終端、工程師手感;Codex 偏 IDE 富交互,並把 Agent 推進 GitHub / Slack / Linear 這些協作工具裏,瞄準的是"想造東西但不想學全部工程儀式"的更大人羣。掌握"四大支柱 prompt + Plan Mode + agents.md + Worktree + 子 Agent 模型分級 + Code Review 面板"這一組合,就能逼近 Codex 的能力上限——同時也理解了 AI 編碼工具未來幾年的產品分岔點在哪。
相關資源推薦
OpenAI「Codex for Work」精讀：從入門到自動化的完整路徑（附 10 個真實落地場景——簡報、週報、PPT、月結、續約管理...）
OpenAI Codex 完整教程 2026：100 分鐘，四個關鍵概念 + 六個實戰項目