OpenAI Codex 是什麼？2026 台灣新手教學：CLI 安裝、費用、提示詞與 Claude Code 比較

一、Codex 是什麼？跟 ChatGPT 差在哪

定義

Codex 是 OpenAI 推出的 AI 編程代理（coding agent），由 ChatGPT 的程式碼編寫模型驅動。在 2026 年 AI 搜尋趨勢全面走向代理化的浪潮中，Codex 是這波變革的代表性產品。它能接收用自然語言描述的任務，然後自主完成以下工作流程：

1. 讀取並理解你的程式碼庫
2. 規劃修改方案
3. 修改檔案、執行指令
4. 跑測試驗證結果
5. 產出 diff 或開 PR

Codex vs ChatGPT：根本差異

很多人第一次聽到 Codex，會問「這跟 ChatGPT 有什麼不一樣？」

簡單說：ChatGPT 是顧問，Codex 是實習生。

ChatGPT 的互動模式是「你問它答」。你貼一段 code 問它怎麼改，它給你一段 markdown 程式碼，你自己複製貼上。它是被動的，不會主動動你的檔案。

Codex 的互動模式是「你派任務，它執行」。你告訴它「幫我修這個 bug」，它自己去找相關檔案、改 code、跑測試、產出 diff。過程中它可能會問你授權（取決於你設定的安全模式），但你不需要一步步指揮它。

一段歷史：Codex 這個名字用過兩次

如果你在網路上搜尋「Codex」，可能會看到一些舊文章在講「Codex API」。那是早期的程式碼生成模型產品線，跟現在的 Codex agent 不是同一件事。

2025 年 5 月，OpenAI 重新推出 Codex，定位成能在雲端沙盒與本機開發環境中工作的 software engineering agent。到 2026 年，Codex 已經延伸到 app、CLI、IDE、Web/Cloud、GitHub code review 與多種工作流整合。這段發展軌跡跟 AI SEO 工具的演進很像：都是從單一功能走向全方位工作流平台。如果你對 AISO（AI 搜尋最佳化）的整體趨勢有興趣，可以看看我們整理的專文。

二、Codex 的主要使用入口

Codex 不是單一工具，而是一組共用 ChatGPT 帳號與工作區控制的 coding agent 入口，這種「多入口、同一後端」的設計跟 Google AI Mode 整合搜尋體驗的做法有異曲同工之妙。官方文件目前把它分成 app、CLI、IDE、Web/Cloud、GitHub/Slack/Linear 等整合與延伸功能；實際可用項目會受方案、地區、工作區設定與功能成熟度影響。

入口	適合場景	在哪啟動	新手提醒
Codex app	把多個代理、worktree、雲端環境與本機工作流集中管理。	macOS / Windows app	適合想把 Codex 當日常開發工作台的人
Codex CLI	在終端機裡讓 Codex 讀取、修改、執行目前資料夾中的程式碼。	終端機輸入 codex	最適合工程師從自己的專案開始試
IDE 擴充	在編輯器內對目前檔案、選取範圍、錯誤訊息直接請 Codex 幫忙。	VS Code 與多數 VS Code forks；其他 IDE 可先用內建 terminal 跑 CLI	適合想少切換視窗的日常開發
Web / Cloud tasks	把較長任務委派到雲端環境，讓 Codex 跑完後回來看結果或套用 diff。	ChatGPT / Codex web 入口	通常需要連接 GitHub repo
整合與延伸功能	GitHub code review、Slack/Linear 工作流、Chrome extension、Computer Use、Automations 等。	依功能在 Codex app、ChatGPT、GitHub 或工作區設定中啟用	團隊導入前先看官方 Feature Maturity 與管理權限

雲端 vs CLI：怎麼選？

這是新手最常問的問題。不管你最終用哪個入口，理解 Codex 的運作邏輯對於掌握 AI 搜尋時代的 SEO 策略也有幫助，因為兩者都在重新定義「人跟工具的協作方式」。兩者的核心差別在於「程式碼在哪裡跑」：

比較項	雲端 Codex	Codex CLI
要不要裝東西	不用，瀏覽器就行	要安裝 CLI
要不要連 GitHub	通常需要連接 repo	不用，能直接處理本機資料夾
程式碼在哪跑	OpenAI 的雲端環境或工作區設定的環境	你的本機與目前工作目錄
適合什麼任務	長時間任務、code review、跨 repo 或可以晚點審 diff 的工作	快速修改、日常 debug、想在本機掌控檔案與指令的工作
安全性	需注意 repo 連接、雲端環境、資料控制與工作區權限	本機執行，但仍要檢查權限、網路與 shell 指令

實際建議：新手先用 CLI 跑一個小任務，再用雲端處理可委派的長任務。如果你對 Google 網頁開發指南裡提到的開發者工具有概念，會發現 Codex 的入口設計跟現代開發工具的走向一致。CLI 讓你理解 Codex 怎麼讀檔、改檔與跑測試；雲端則適合可以明確寫成任務單、完成後再審 diff 的工作。

三、台灣費用與方案怎麼選

Codex 目前不是一個單獨購買的消費者訂閱，而是包含在 ChatGPT 方案、工作區方案或 API key 用量裡。對於還在評估 AI 工具投資報酬率的人，可以參考我們整理的 SEO 入門指南，裡面有工具選擇與預算分配的思考框架。官方說法是：Plus、Pro、Business、Edu、Enterprise 方案包含 Codex；Free 與 Go 也在有限期間內可使用 Codex，但額度較少。實際價格、額度與促銷會依帳號、地區、方案與工作區設定變動，發布前務必再看 ChatGPT 定價頁與 Codex usage dashboard。

方案	台灣價格提醒	Codex 使用方式	適合對象
Free	免費	有限使用，適合試跑小任務	想知道 Codex 是什麼
Go	依台灣登入後定價頁為準	有限期間包含 Codex，額度較輕量	學生、偶爾使用者
Plus	依台灣登入後定價頁為準	個人日常使用主力；達上限後部分帳號可加購 credits	個人開發者、多數人的起步點
Pro	依台灣登入後定價頁為準	比 Plus 更高的 Codex 用量；官方在 2026-05-31 前提供部分 Pro 額外用量促銷	每天高強度使用者
Business / Edu / Enterprise	依官網或業務報價	工作區額度、治理、RBAC、合規與團隊管理	工程團隊、大型組織

台灣付款方式

台灣讀者最常問的實際問題：台灣信用卡能刷嗎？

通常可以用台灣發行的信用卡或平台支援的付款方式訂閱 ChatGPT，但可用卡別與稅費仍以結帳頁為準。建議不要只看第三方文章的截圖，因為 ChatGPT 方案與地區價格會調整。

額度用完怎麼辦？

Codex 用量會計入 ChatGPT 的 agentic usage limit。就像 用 AI 增加網站流量需要持續投入一樣，AI coding agent 的使用也需要在額度與效益之間取得平衡。任務越大、讀到的程式碼越多、輸出越長、使用越強的模型，就越快消耗額度。達上限時，你可能可以加購 credits、切換較小模型、等額度重置，或升級到更高方案；Business / Edu / Enterprise 則由工作區 credits 與管理員設定控管。

怎麼判斷該選哪個方案？

• 只是想試試看：先用免費版，跑幾個小任務感受一下。
• 每週用幾次，改 bug、寫小功能、做 code review：Plus 通常是最合理的起步點。
• 每天用、任務又大又多：考慮 Pro，並學會用較小模型、縮小 context、精簡 AGENTS.md 來延長額度。
• 團隊使用：Business / Edu / Enterprise，重點不是只看額度，而是工作區權限、資料治理、合規紀錄與 GitHub review 流程。

四、Codex CLI 安裝教學：從零開始的第一步

如果你想真正理解 Codex 的工作方式，CLI 是最推薦的起點。理解命令列工具的運作邏輯，對後續做 網站程式碼最佳化或 技術 SEO 也有幫助。它能在你目前的資料夾中讀檔、改檔、跑指令，也支援 image inputs、local code review、subagents、MCP、Skills、Web search、Cloud tasks 等工作流。

圖文操作總覽

1. 開啟 Codex app：從主工作區開始，先確認底部輸入框、模型選單、存取權與工作模式。
2. 選擇模型：任務越複雜，越適合使用較強模型；日常小修改則可以切換到較輕量的選項。
3. 調整存取權：第一次使用先選保守模式，等你熟悉 review diff、跑測試與接受修改後，再提高自動化程度。
4. 送出第一個任務：用一段小而明確的指令測試 Codex 如何讀取專案、規劃步驟與輸出結果。

模型怎麼切換？

Codex app 的模型選單不是只選「哪個模型名稱」，也會把推理深度、智慧功能與速度放在同一個工作流裡。新手可以先記一個原則：小任務用中等或較快設定，跨檔案重構、debug、code review 再提高推理深度。

安裝方式

官方文件目前主推 npm 安裝：

npm i -g @openai/codex

macOS 也可用 Homebrew：

# Homebrew（macOS）
brew install --cask codex

安裝完成後確認：

codex --version

官方文件指出 Codex CLI 是開源工具、以 Rust 撰寫，支援 macOS、Windows、Linux。如果你做過 結構化資料（Structured Data）的標記，會發現 Codex CLI 的設定檔邏輯跟 JSON-LD 的概念很像：都是用結構化描述讓系統理解你的意圖。Windows 可以在 PowerShell 原生執行；需要 Linux-native 環境時再選 WSL2。新版本會定期釋出，npm 使用者可用 npm i -g @openai/codex@latest 更新。

登入方式

登入方式	適合誰	額度從哪扣
Sign in with ChatGPT（推薦）	Free、Go、Plus、Pro、Business、Edu、Enterprise 等符合資格帳號	使用 ChatGPT / workspace 的 Codex 額度
API key	沒訂閱 ChatGPT、要走 API 計費	從 platform.openai.com 拿 key，按 token 計費

第一個任務

登入完成後，直接在終端機輸入 codex 進入互動模式，然後輸入：

幫我看一下這個專案有沒有明顯的 bug

Codex 會讀取你當前目錄的專案檔案，分析後回覆建議。如果你想讓它直接修改：

把 src/utils/format.js 裡的日期格式從 YYYY-MM-DD 改成 YYYY/MM/DD，並確認所有引用這個函式的地方都能正常運作

五、Codex 權限設定：先控風險，再讓它自動做事

Codex 的核心能力是「能動手」，所以權限設定比一般聊天工具更重要。這跟 網站最佳化流程裡強調的「先衡量影響範圍再動手」是同樣的道理。新版 CLI 可以用 /permissions 調整當前 session 的 approval preset；你也可以在設定檔中長期保存偏好。不同版本的名稱可能略有變動，但概念可以抓成三層：

權限層級	行為	適合場景	新手建議
Read only / 需批准	先讀檔、分析與提出計畫；編輯檔案或執行指令前需要你確認。	第一次使用、關鍵程式碼、不確定影響範圍	從這層開始
Auto / 自動編輯	允許 Codex 直接改檔，但較敏感的 shell 指令、網路或跨範圍操作仍需審核。	日常開發、你信任它的編輯判斷	熟悉專案後再開
高自主執行	讓 Codex 在沙盒或指定工作區中更自主地改檔、跑測試與迭代。	熟悉的專案、低風險例行任務	只在 git 狀態乾淨、測試明確時使用

設定裡建議先看哪些項目？

正式把 Codex 放進工作流前，可以先到設定中確認幾個方向：帳號與工作區、模型偏好、存取權預設、外掛程式或 MCP、通知與自動化。不同版本的設定頁名稱會調整，但核心目標一樣：讓 Codex 在你可掌控的範圍內工作。

設定方向	你要確認什麼	新手建議
模型與速度	日常回答、重構、debug 是否使用不同推理深度	先用中等或高，複雜任務再提高
存取權預設	是否允許自動修改檔案、執行指令或連接外部工具	先保守，熟悉 diff 後再放寬
工作模式	要在目前專案、單一檔案、雲端任務或右側預覽中工作	先從目前專案的小任務開始
工具整合	是否需要 GitHub、MCP、Skills、瀏覽器或自動化	用到再開，避免一開始給太多範圍

六、提示詞技巧：讓 Codex 做對事

很多人拿到 Codex 後的第一個問題是「我要怎麼給它指令？」寫好提示詞的邏輯，跟我們在 SEO 文章寫作指南裡強調的「先想清楚讀者意圖，再組織內容」是一致的。以下整理實測有效的提示詞技巧。

基本原則：三段式提示法

不要給 Codex 模糊的指令。理解 搜尋意圖（Search Intent）的概念在這裡很有幫助：就像 SEO 要先理解使用者在找什麼，給 Codex 指令也要先釐清你要它做什麼。一個好的提示詞包含三個要素：背景、目標、約束。

重構這個元件

背景：我有一個 React 元件 UserProfile.jsx，目前使用 class component
目標：將它改寫為 function component（使用 Hooks），保持所有功能不變
約束：
- 必須通過所有現有單元測試
- 不要改變 props 的 interface
- 不要刪除任何現有方法

技巧一：指出相關檔案和位置

Codex 有強大的程式碼搜尋能力，但如果你能縮小範圍，效率更高。這個概念跟 關鍵字最佳化裡說的「精準比廣泛更重要」完全一致：

在 src/api/users.js 裡的 handleLogin 函式，加上輸入驗證：
- email 必須是有效的信箱格式
- password 長度至少 8 位
- 驗證失敗時回傳 400 狀態碼和明確的錯誤訊息

技巧二：加上驗證步驟

告訴 Codex 怎麼確認結果是對的，它會在工作過程中自我檢查。就像 內容行銷裡強調的「每篇內容都要有可衡量的指標」，給 Codex 的驗證步驟越明確，產出越可靠：

修復 src/utils/parser.js 裡處理空值時的 crash bug。

驗證方式：
1. 執行 npm test，所有測試必須通過
2. 新增一個測試案例：輸入 null 應回傳空物件而非 throw
3. 執行 npx eslint src/utils/parser.js，不應有新的 lint 錯誤

技巧三：引導工作方式

你可以告訴 Codex「怎麼做事」，而不只是「做什麼」：

為 src/services/payment.js 新增信用卡驗證功能。

工作方式：
- 參考 src/services/user.js 裡 validateEmail 的實作模式
- 優先使用專案已有的 utils 工具函式，不要重新實作
- 遵循 .github/pull_request_template.md 的 PR 格式
- 不要使用 sudo 或需要提升權限的指令

技巧四：鏈式提示，大任務分步做

大任務不要一次丟給 Codex。拆成幾個步驟，每步完成後驗證，再進行下一步。這個做法跟 長尾關鍵字策略的邏輯類似：把一個大目標拆成多個小而明確的單元，逐個擊破比一次通吃更有效。

# 第一步：先讓 Codex 分析並規劃
codex "分析 src/ 目錄結構，列出轉換 TypeScript 的優先順序和風險"

# 第二步：型別定義
codex "根據剛才的分析結果，先為 src/types/ 產生 TypeScript 型別定義"

# 第三步：逐模組轉換
codex "將 src/utils/ 從 JS 轉成 TS，使用剛產生的型別定義"

# 第四步：產生測試
codex "為轉換後的 src/utils/ 產生 Jest 單元測試"

技巧五：善用 AGENTS.md

AGENTS.md 是放在專案根目錄的說明檔案，Codex 會讀取它來理解專案約定。它的角色有點像 內部連結最佳化策略裡的網站導覽：讓工具快速掌握你的結構與規則。把團隊的測試方式、技術棧、命名規則、禁止事項寫在這裡，每次給 Codex 任務時就不用重複說明。好的 AGENTS.md 會善用 語意關鍵字，讓 AI 精準掌握你的專案語境。不同工具的記憶檔名稱不一定相同，例如 Claude Code 常用 CLAUDE.md，所以跨工具使用時要分別確認。

# AGENTS.md

## 專案背景
這是一個 Node.js + Express 的 REST API 專案，資料庫用 PostgreSQL。

## 程式碼規範
- 使用 ES Modules（import/export），不用 CommonJS（require）
- 縮排用 2 個空格
- 變數命名用 camelCase，常數用 UPPER_SNAKE_CASE
- 所有 API 回應遵循 { success, data, error? } 格式

## 測試
- 執行測試：npm test
- 測試框架：Jest
- 測試檔案放在 __tests__/ 目錄下

## 不要做的事
- 不要修改資料庫 schema
- 不要安裝新的 npm 套件（先提案，確認後再裝）
- 不要使用 any 型別

七、進階功能：Skills、Automations、MCP、Subagent

如果你已經熟悉基本操作，以下進階功能能讓 Codex 從「好用」變成「不可或缺」。

外掛程式：把常用工具接進 Codex

外掛程式讓 Codex 能連接瀏覽器、GitHub、Slack、試算表、簡報、文件等工具。如果你已經用過我們整理的 免費 Google SEO 工具清單，會發現 Codex 外掛的邏輯跟這些工具一樣：把分散的功能集中到一個工作流裡。新手可以先從只讀或低風險工具開始；等你確定工作流需要，再加入能修改外部資料的外掛。

Automations：把例行任務排程化

Automations 適合固定頻率或可重複的任務，就像你可以用 Google Trends 定期追蹤關鍵字趨勢一樣，例如每日摘要、每週回顧、專案監控、依賴檢查、文件整理。它的重點不是「讓 AI 一直跑」，而是把明確、低風險、可驗證的流程變成排程。

Skills：把重複流程封裝成技能

如果某個工作流程會反覆出現，你可以把它打包成 Skill。Codex 下次遇到類似任務時，就不用重新學習整套流程。

Skill 的本質是一個包含 SKILL.md 的資料夾，裡面可以放 instructions、scripts、references、assets。Repo 內常見位置是 .agents/skills/，個人常用技能可以放在 ~/.agents/skills/。當你要把多個 skill 或 app/MCP 整合打包給團隊安裝時，再升級成 plugin。

舉個例子，如果你經常需要做 code review，可以建一個 code-review.md Skill：

---
name: code-review
description: 針對指定檔案或 PR 進行結構化 code review
---

## 觸發條件
當使用者要求 review 程式碼時使用此 Skill。

## 執行步驟
1. 讀取指定的檔案或 git diff
2. 依以下維度逐一檢查：
   - 正確性：邏輯是否有錯、邊界條件是否處理
   - 安全性：是否有 SQL injection、XSS、敏感資料外洩風險
   - 效能：是否有不必要的迴圈、N+1 查詢
   - 可讀性：命名是否清晰、註解是否足夠
   - 測試：是否有對應的測試案例
3. 輸出格式：
   - 每個問題用一行摘要 + 具體位置 + 建議修改方式
   - 標注嚴重程度（critical / warning / suggestion）

Skill 建好後，Codex 會依據名稱與 description 判斷何時載入完整指令。你可以用 /skills 指令查看或明確指定要使用的 Skill。

MCP（Model Context Protocol）：接外部服務

MCP 是一個開放協定，讓 Codex 能連接外部工具和服務。Codex CLI 與 IDE extension 都支援 MCP；你可以用 codex mcp 指令新增 server，也可以在 ~/.codex/config.toml 或可信任專案的 .codex/config.toml 中設定。

常見 MCP 整合：

• GitHub MCP：直接操作 PR、issue、code review
• Sentry MCP：自動讀取錯誤報告並修復
• Playwright MCP：讓 Codex 操作瀏覽器進行端到端測試，對於驗證 網頁速度對 SEO 的影響特別實用
• Figma MCP：讀取設計稿產生對應的 UI code，包含 標題標籤結構與 圖片 alt 屬性等 SEO 相關元素

設定範例（config.toml）：

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

Subagent：多代理並行工作

Codex 支援 subagent 機制，讓你可以在一個主任務中派生多個子代理同時工作。每個子代理在獨立的 Git Worktree 中執行，不會互相干擾。

這對以下場景特別有用：

• 同時修多個 bug：一個代理修 bug A，另一個修 bug B，各自在獨立的 worktree 裡工作
• 大型重構：主代理負責規劃，子代理分頭執行不同模組的重構
• 方案比較：派兩個子代理用不同方式解同一個問題，最終你選比較好的那個

核心斜線命令一覽

命令	功能
/plan	讓 Codex 先產出執行計畫，不直接動 code
/permissions	調整 Codex 可自行讀檔、改檔、執行指令的權限
/diff	查看目前工作樹中的修改，接受前先審 diff
/review	請另一個 Codex review 目前改動
/compact	壓縮上下文，釋放 context window 空間
/skills	查看和呼叫已安裝的 Skills
/mcp	查看目前連接的 MCP servers 與工具
/status	查看當前用量和狀態
/theme	切換 CLI 佈景主題
/copy	複製最新回覆到剪貼簿
/clear	清除畫面但保留對話歷史
/vim	啟用 Vim 編輯模式

八、實際應用場景範例

場景一：修一個惱人的 bug

你有一個 Express API，前端回報「建立訂單時偶爾會 500 錯誤」，但沒有穩定的重現步驟。這種間歇性問題跟排查 重複內容問題很像：症狀不穩定，但根因通常藏在邏輯分支裡。

步驟 1：讓 Codex 分析問題

分析 src/routes/orders.js 的 createOrder 函式。
前端回報建立訂單時偶爾出現 500 錯誤，但沒有穩定的重現步驟。
請檢查：
1. 是否有未處理的 async/await 錯誤
2. 是否有 race condition
3. 是否有未驗證的外部輸入
4. 查看最近的 git log，看這個函式最近改了什麼

驗證：跑 npm test 確認沒有破壞現有測試

步驟 2：Codex 回報發現

Codex 讀取檔案後可能會告訴你：「在 createOrder 的第 47 行，呼叫 inventoryService.checkStock 時沒有 try/catch。當庫存服務逾時會導致 unhandled promise rejection，造成 500 錯誤。」

步驟 3：讓它修

修復這個問題。加上錯誤處理，庫存服務逾時時改回傳 503 而非 500。
並新增一個測試案例模擬庫存服務逾時的情況。

步驟 4：檢查 diff

Codex 修完後會顯示 diff。你檢查改動是否合理，確認後接受。整個過程可能 2-3 分鐘，比起自己 trace code、查 log、改 code、寫測試，省下不少時間。

場景二：為既有 API 加新功能

在 src/api/users.js 新增批次刪除功能。

需求：
- 路徑：DELETE /api/users/batch
- 接受使用者 ID 陣列，例如 { "userIds": [1, 2, 3] }
- 空陣列回傳 400
- 不存在的 ID 忽略（不報錯）
- 回應格式：{ success: true, data: { deletedCount: 2, notFound: [99] } }
- 必須通過 npm test

參考：現有的 DELETE /api/users/:id 的實作模式

場景三：大規模重構（JS → TS）

這種任務不適合一次丟給 Codex，而是分步進行。就像做 頁面 SEO 內容最佳化一樣，一口氣改太多變數會讓你無法判斷哪個改動有效。

先規劃：

/plan
分析這個專案的檔案結構，規劃從 JavaScript 遷移到 TypeScript 的步驟。
列出：
1. 需要安裝哪些 TypeScript 相關套件
2. 每個目錄的遷移優先順序（從依賴最少到最多）
3. 預計的風險點
4. 建議的 tsconfig.json 設定

逐模組執行：

根據剛才的規劃，開始遷移 src/utils/ 目錄。
產生型別定義、轉換程式碼、確保 npm test 通過。

場景四：日常小任務

有些任務很小，但手動做起來很煩：

找出專案裡所有 console.log，列出去掉後不會影響功能的那些（排除測試檔案和故意留的 debug log），然後移除它們。

把所有 .js 檔案裡的 var 宣告改成 const 或 let，跑 eslint 確認沒問題。

檢查 package.json 裡的依賴，列出有安全漏洞的套件和建議的更新版本。

這種日常小任務交給 Codex 特別划算，省下的時間你可以拿來做更有價值的判斷工作。

九、Codex 與 Claude Code 比較：該選哪個

如果你已經在使用 AI coding 工具，很可能聽過 Claude Code。如果你還不熟悉 Claude，可以先看我們整理的 Claude AI 教學，這裡用一個務實的角度比較兩者。

核心定位差異

Codex 擅長的是：你把任務描述清楚、派給它、它可以非同步執行，你回來看 diff 就好。這種「委派後回來驗收」的模式，跟我們在 AI 搜尋最佳化策略裡提到的「把重複性工作交給 AI」概念一致。

Claude Code 擅長的是：你在終端機裡跟它即時互動，邊討論邊改，需要深度推理的場景它表現穩定。

功能比較

比較項	OpenAI Codex	Claude Code
主要入口	Codex app、CLI、IDE extension、Web/Cloud、GitHub/Slack/Linear 整合	CLI、IDE、GitHub Actions、SDK、MCP 與自訂 slash commands
核心模型	依 Codex 版本與 /model 可選清單而定；官方文件會更新可用模型	依 Claude Code 帳號、API provider 與 /model 設定而定
並行代理	Codex app 強調 worktrees、cloud environments 與多代理工作流	支援 custom subagents，可為不同任務配置獨立 prompt 與工具權限
非同步任務	雲端任務、Automations、GitHub review 與 app background workflows 較完整	可透過 GitHub Actions、SDK 或 terminal 流程自動化，但主要體驗仍偏互動式
開源狀態	Codex CLI 是 Apache 2.0 開源	以 Anthropic 官方發佈的 CLI、SDK 與 GitHub Action 文件為準
權限控制	/permissions、sandbox、workspace controls、RBAC 與 Codex Cloud 控制	/permissions、tool permissions、hooks、MCP permission 設定
GitHub 工作流	支援 GitHub code review、cloud tasks 與整合入口	支援 Claude Code GitHub Actions，可用 @claude 或 action workflow
MCP 支援	支援	支援
專案記憶檔	使用 AGENTS.md 與 skills/plugins	使用 CLAUDE.md、memory 與 custom commands

成本與使用體驗比較

項目	OpenAI Codex	Claude Code
費用入口	ChatGPT 方案內含 Codex 用量；達上限後依帳號可能可加購 credits 或用 API key	Claude.ai 訂閱、Anthropic API，或 Bedrock / Vertex AI 等 provider
用量查看	Codex usage dashboard、CLI /status、工作區 credits	Claude Code /cost、/status 與 provider 帳單
任務風格	適合明確規格、可審 diff、可交給背景或雲端完成的工程任務	適合互動探索、架構討論、逐步除錯與深度 pair programming
資料位置	CLI 可在本機跑；Cloud tasks 會在雲端環境處理 repo	CLI 在本機互動；GitHub Actions 則在 GitHub runner 中執行
比較方式	不要只看 benchmark，實測你的 repo：同一個 issue、同一組測試、同一份 review rubric	同左；不同模型與方案會讓結果差很多

怎麼選？

你要做的事	建議先試	原因
可寫成明確任務單的 bug fix / PR review	Codex	雲端任務、GitHub review 與 app 工作流較順
長時間背景工作、例行檢查、issue triage	Codex	Automations 與 background workflows 是它的強項
不確定方向、需要邊問邊改的架構探索	Claude Code	互動式 terminal pair programming 體驗成熟
想用自訂 subagent 分工	兩者都可試	Codex 偏 worktree / app 多代理；Claude 偏專用 subagent prompt 與工具權限
高度敏感的私有程式碼	本機模式優先	Codex CLI 或 Claude Code 都要確認資料控制、權限與是否啟用雲端/GitHub workflow
已經深度使用 ChatGPT 工作區	Codex	帳號、workspace controls、GitHub 與 app 體驗整合度更高

十、怎麼開始：三個立即可行的步驟

如果你還在猶豫要不要投入 AI coding 工具，可以參考我們對 SEO 的真正價值的分析：任何能持續提升效率的工具，長期投資報酬率都比你想像的高。以下是三個立即可行的起步方式：