OpenAI Codex 是一個 AI coding agent（AI 編程代理）。你給它一個用自然語言描述的任務，它能在你授權的範圍內讀程式碼、改檔案、跑測試、交出 diff，必要時還能開 PR。它跟一般 ChatGPT 對話最大的差別，一句話講完：ChatGPT 是顧問，Codex 是會自己動手的實習生。根據 OpenAI 官方說法，Codex 目前包含在 ChatGPT Free、Go、Plus、Pro、Business、Edu、Enterprise 方案裡，額度與功能依方案不同。
TL;DR：Codex 把「你問它答」升級成「你派任務、它交付、你驗收」。主要透過 Codex app、CLI、IDE extension、Codex web 四個官方入口使用，全部用同一個 ChatGPT 帳號。官方 CLI 在 macOS/Linux 的主推安裝方式是
curl -fsSL https://chatgpt.com/codex/install.sh | sh，npm 與 Homebrew 也支援。會用的人改變的是整個工作節奏：派任務、看 diff、確認，取代問答與複製貼上。
文章目錄
一、OpenAI Codex 的定位：跟 ChatGPT 的根本差別
定義：它是 agent，不是聊天機器人
Codex 是 OpenAI 推出的 AI 編程代理（coding agent），官方定位成「幫你把軟體工程任務做完」的代理人。它接收自然語言任務後，可以自主完成讀取程式碼庫、規劃修改、改檔案、執行指令、跑測試驗證、產出 diff 或開 PR 這整段流程。在 2026 年 AI 搜尋走向代理化的浪潮裡，它是這波變革的代表性產品之一。
關鍵差別：顧問 vs 實習生
很多人第一次聽到 Codex 會問：「這跟 ChatGPT 差在哪？」最直覺的比喻是：ChatGPT 像顧問，Codex 像一個會自己動手、但需要你驗收的實習生。顧問給建議，實習生交成果。
你問 ChatGPT「這段 React 元件的 state 管理有問題，怎麼修？」它回你一段 markdown，你自己複製貼上。你把同一句話交給 Codex，它會自己打開那個檔案、改好、跑測試、把 diff 秀給你看，等你點頭才入稿。前者是「問 → 讀 → 複製 → 貼上 → 測試」五個動作，後者是「派任務 → 等幾秒 → 看 diff → 確認」。
省下的不是那幾秒鐘。省下的是你腦袋在「編輯器、終端機、瀏覽器、聊天視窗」之間不斷切換的認知負擔。這也是為什麼很多人裝了 Codex 卻用不起來，他們把它當下一個 ChatGPT，繼續用「問答」模式互動，根本沒走到「委派＋驗收」這一步。
同一段歷史用過兩次的名字
如果你搜「Codex」看到舊文講「Codex API」，那是早期的程式碼生成模型，跟現在的 agent 不是同一件事。2025 年 OpenAI 重新推出 Codex，定位成能在雲端沙盒與本機環境裡工作的 software engineering agent。到 2026 年，它已延伸到 app、CLI、IDE extension、web，以及 GitHub、Slack、Linear 等整合。看到舊文講「Codex API」或單純的程式碼補全，先確認日期。
把時間軸拉開看更清楚：Codex 在 2025 年以 coding agent 之姿推出，重心先放在雲端環境裡改程式、跑測試、交出 PR；2026 年初推出桌面版 App，把同樣的能力搬進本機工作區；同年大改版再疊上電腦控制、圖像生成與內建瀏覽器，定位從「幫你寫程式」擴大成「幫你把一件工作從頭做到尾」。這條演進線也說明了為什麼你搜到的舊文，截圖、入口數量、安裝方式常常對不上現在的產品，它半年前長的樣子跟現在已經差一截。
二、Codex 的四個官方入口與整合
Codex 是一組共用同一個 ChatGPT 帳號與工作區的 agent 入口。這種「多入口、同一後端」的設計，跟 Google AI Mode 把搜尋體驗拆成多個介面是同一個思路。OpenAI 官方文件目前列出四個官方 client，再加一層外部整合。
| 入口 | 適合場景 | 在哪啟動 | 新手提醒 |
|---|---|---|---|
| Codex app | 把多個代理、worktree、雲端環境、本機工作流集中管理的指揮中心 | macOS / Windows 桌面 app | 想把 Codex 當日常開發工作台的人 |
| Codex CLI | 在終端機裡讓 Codex 讀取、修改、執行目前資料夾的程式碼 | 終端機輸入 codex | 工程師從自己的專案開始試最直接 |
| IDE extension | 在編輯器內對目前檔案直接請 Codex 幫忙 | VS Code 與多數 VS Code forks、JetBrains 系列 | 想少切換視窗的日常開發 |
| Codex web | 把較長任務委派到雲端環境，交回 PR | 瀏覽器，需把 ChatGPT 連到 GitHub | 適合跨 repo、長時間任務 |
| 整合（非獨立入口） | GitHub code review、Slack、Linear 工作流 | 在對應服務裡連結 Codex | 團隊導入前看官方 Feature Maturity |
雲端任務 vs CLI：怎麼選？
這是新手最常問的問題。核心差別在「程式碼在哪裡跑」。理解這點，對掌握 生成式引擎時代的策略（包括 AISO、AI 搜尋最佳化）也有幫助，兩者都在重新定義人跟工具的協作方式。
| 比較項 | 雲端任務（web） | Codex CLI |
|---|---|---|
| 要不要裝東西 | 不用，瀏覽器就行 | 要安裝 CLI |
| 要不要連 GitHub | 需要連接 repo | 不用，直接處理本機資料夾 |
| 程式碼在哪跑 | OpenAI 的雲端環境 | 你的本機與目前工作目錄 |
| 適合什麼任務 | 長時間任務、code review、跨 repo | 快速修改、日常 debug、想掌控本機檔案 |
| 安全性重點 | 注意 repo 連接與工作區權限 | 本機執行，仍要檢查權限與 shell 指令 |
實際建議：新手先用 CLI 跑一個小任務，再用雲端處理可委派的長任務。CLI 讓你親眼看到 Codex 怎麼讀檔、改檔、跑測試；雲端則適合能寫成任務單、完成後再審 diff 的工作。如果你對 Google 開發者網頁指南裡提到的開發者工具有概念，會發現 Codex 的入口設計跟現代開發工具走向一致。
三、Codex 費用與方案選擇
Codex 包含在 ChatGPT 方案裡，不必另外購買獨立訂閱。官方文件指出，Codex 包含在 Free、Go、Plus、Pro、Business、Edu、Enterprise 方案中，差別在用量額度、可用模型、速度與功能。Free 與 Go 也能用，但額度較輕量，適合試跑小任務。實際價格、額度與促銷會依帳號、地區、方案變動，發布前務必再看 ChatGPT 定價頁與 Codex 的 usage 說明。
| 方案 | Codex 使用方式 | 適合對象 |
|---|---|---|
| Free | 有限度使用，試跑小任務 | 想知道 Codex 是什麼 |
| Go | 額度較輕量 | 學生、偶爾使用者 |
| Plus | 個人日常使用主力 | 個人開發者、多數人的起步點 |
| Pro | 比 Plus 更高的用量，部分使用者可加購 credits | 每天高強度使用者 |
| Business / Edu / Enterprise | 工作區額度、治理、RBAC 與團隊管理 | 工程團隊、大型組織 |
價格怎麼查最準：登入 ChatGPT 後看「Upgrade / Plan」頁面，或在 Codex 內看 usage dashboard。不要把任何第三方文章的幣別數字當成永久價格。實際結帳時看到的幣別、稅費與可用方案，以你的帳號結帳頁為準。多數人可用平台支援的付款方式訂閱 ChatGPT，但卡別與稅費仍以結帳頁為準。官方也提醒，Codex 的用量會計入你的 agentic 額度，跟 ChatGPT for Excel、Workspace Agents 共用。
怎麼判斷該選哪個方案？
- 只是想試試看：先用免費版跑幾個小任務感受一下。
- 每週用幾次，改 bug、寫小功能、做 code review：Plus 通常是最合理的起步點。
- 每天用、任務又大又多：考慮 Pro，並學會用較小模型、縮小 context、精簡 AGENTS.md 來延長額度。
- 團隊使用：Business / Edu / Enterprise，重點不是只看額度，而是工作區權限、資料治理與 GitHub review 流程。
四、Codex CLI 安裝教學：從零到第一個任務
想真正理解 Codex 的工作方式，CLI 是最推薦的起點。理解命令列工具的運作邏輯，對後續做 網站程式碼最佳化或 技術 SEO 也有幫助。官方文件指出，Codex CLI 是開源、以 Rust 撰寫，支援 macOS、Windows、Linux。
安裝方式
官方文件目前主推的獨立安裝腳本（macOS / Linux）：
curl -fsSL https://chatgpt.com/codex/install.sh | sh
之後要升級，重跑同一行即可。如果你已經習慣 Node 生態，npm 也支援：
npm i -g @openai/codex
Homebrew 同樣有支援，確切指令以官方 CLI 文件當下顯示的為準（OpenAI 會定期更新安裝選項）。安裝完成後確認一下：codex --version。第一次執行 codex 時，會提示你用 ChatGPT 帳號或 API key 登入。
登入方式
| 登入方式 | 適合誰 | 額度從哪扣 |
|---|---|---|
| Sign in with ChatGPT（推薦） | Free、Go、Plus、Pro、Business 等帳號 | 使用 ChatGPT / workspace 的 Codex 額度 |
| API key | 沒訂閱 ChatGPT、要走 API 計費 | 從 platform.openai.com 拿 key，按 token 計費 |
第一個任務
登入後，cd 到一個 git 專案，輸入 codex 進入互動模式，然後輸入：
幫我看一下這個專案有沒有明顯的 bug
Codex 會讀取你當前目錄的檔案，分析後回覆建議。想讓它直接修改，可以說：
把 src/utils/format.js 裡的日期格式從 YYYY-MM-DD 改成 YYYY/MM/DD，並確認所有引用這個函式的地方都能正常運作
這個流程會讓你熟悉三件事：Codex 可以讀取專案、Codex 可以修改檔案、Codex 可以根據你的追問調整結果。新手最適合從這種低風險、成果明確的小任務開始。
五、權限設定的安全選擇（一個被忽略的細節會讓你出事）
Codex 的核心能力是「能動手」，所以權限設定比一般聊天工具更重要。官方通稱 approval modes（核准模式），讓你在 Codex 編輯或執行指令前，先決定要它做到什麼程度。不同版本的名稱會變動，但概念可以抓成三層：
| 權限層級 | 行為 | 適合場景 | 新手建議 |
|---|---|---|---|
| 需批准（最保守） | 先讀檔、分析、提計畫；編輯檔案前需要你確認 | 第一次使用、關鍵程式碼 | 從這層開始 |
| 自動編輯 | 允許 Codex 直接改檔，但敏感操作仍會詢問 | 日常開發、你信任它的判斷 | 熟悉專案後再開 |
| 高自主執行 | 讓 Codex 在沙盒中更自主地改檔、跑測試與迭代 | 熟悉的專案、低風險例行任務 | 只在 git 狀態乾淨、測試明確時用 |
新手先用 /plan 看完整計畫，再用 /permissions 選保守權限。養成三個習慣：在 git 裡工作、接受前看 /diff、要求 Codex 跑測試或說明為何不能跑。這比記住某個舊版旗標更重要。
為什麼「全自動」聽起很誘人，卻最容易出事
這裡講一個我們自己踩過的雷。我們用 Codex 與 Claude Code 維運一個 WordPress SEO 工作線，工具會去打 WordPress REST API 更新文章內容。有一次，agent 被授權「自動更新」，它照字面執行：把整個 content 欄位覆寫掉。問題是，文章尾端原本掛了一個結構化資料區塊（FAQPage JSON-LD），覆寫後那個區塊憑空消失，AI 搜尋能讀到的結構化資料也跟著沒了。
這不是 Codex 出錯，它完全照指令做事。問題出在「全自動」把一個會靜默吞掉副作用的動作，放行了。教訓很白話：給 Codex 權限前先問自己一句：它若照字面執行，最壞會改掉什麼？如果答案包含「某個我沒盯著的尾端資料」「某個我看不到的設定檔」，就退回需批准。這跟 E-E-A-T（乃至 站外 SEO 談的權威與信任）是同一件事：最終把關的還是人，工具只是讓你把關得更從容。
六、提示詞與 AGENTS.md：報酬率最高的兩件事
很多人拿到 Codex 後第一個問題是「我要怎麼給它指令？」寫好提示詞的邏輯，跟我們在 SEO 文章寫作指南與 內容行銷裡強調的「先想清楚讀者意圖，再組織內容」是一致的。但實作一陣子你會發現：報酬率最高的不是把 prompt 寫得更漂亮，而是兩件事：把 AGENTS.md 寫好，以及每次都看 diff。這兩件事，多數教學都只帶過。
三段式提示法：背景、目標、約束
不要給 Codex 模糊的指令。理解 搜尋意圖的概念在這裡很有用：就像 SEO 要先搞懂使用者在找什麼，給 Codex 指令也要先釐清你要它做什麼。一個好的提示詞包含三個要素：背景、目標、約束。
範例：
重構這個元件
背景：我有一個 React 元件 UserProfile.jsx，目前是 class component
目標：改寫成 function component（使用 Hooks），保持所有功能不變
約束：必須通過所有現有單元測試、不要改變 props 的 interface
AGENTS.md：Codex 的專案記憶檔，才是真正的主戰場
AGENTS.md 是放在專案根目錄的說明檔案，Codex 會讀它來理解專案約定。它跟 Claude Code 用的 CLAUDE.md 是同類東西。你甚至可以在 Codex app 的輸入框打 /init，讓它自動幫你生成一份 AGENTS.md 初稿，再自己改。
它的角色有點像 內部連結最佳化策略或 標題標籤裡的網站導覽：讓工具快速掌握你的結構與規則。把團隊的測試方式、技術棧、命名規則、禁止事項寫在這裡，每次給 Codex 任務時就不用重複說明。
範例：
# AGENTS.md
## 專案背景
Node.js + Express REST API，資料庫用 PostgreSQL
## 程式碼規範
- 使用 ES Modules（import/export）
- 縮排用 2 個空格
- 變數命名用 camelCase
## 測試
- 執行測試：npm test
- 測試框架：Jest
## 不要做的事
- 不要修改資料庫 schema
- 不要安裝新的 npm 套件（先提案，確認後再裝）
你花 10 分鐘寫好 AGENTS.md，後面省下的是每次任務都要重複說明的時間。但 AGENTS.md 真正的價值，是把踩過的雷寫進去。以我們自己為例，我們的工作線有一份兩百多行的專案記憶檔，每一條幾乎都對應一次真實災難：哪個 API 欄位送錯會把十六篇文章的標題一起覆蓋掉、哪個請求少了某個 header 會被伺服器回 403、哪個快取層會讓你以為已經更新但其實前端還是舊的。這些東西不寫進 AGENTS.md，下次 agent 照樣會踩；寫進去，它下一次就繞開了。
講白了，Prompt 是單次戰術，AGENTS.md 才是長期戰略。若團隊同時用多個 coding agent，可以把核心規範同步到各工具支援的專案記憶檔，保持一致。
每次都看 diff
第二件高報酬率的事，是每次都看 diff。Codex 交出來的東西，文字總結會講得很漂亮，但真正可靠的是它實際改了哪些檔案。這個概念跟 關鍵字最佳化裡說的「精準比廣泛更重要」一致：不要用「感覺對了」驗收，用可檢查的差異驗收。在 git 裡工作，git diff 或 Codex 的 /diff 都行。
七、進階功能：Skills、Automations、MCP、Subagent 與 2026 新能力
熟悉基本操作後，以下功能能讓 Codex 從「好用」變成「不可或缺」。這幾項都是 OpenAI 官方文件明確列出的 Codex 能力。
Skills：把重複流程封裝成技能
如果某個工作流程會反覆出現，把它打包成 Skill。Codex 下次遇到類似任務時，就不用重新學一套。這個概念跟 主題集群的架構很像：把核心資訊集中一處，讓相關工作都能參照。官方還有一個叫 Record & Replay 的功能（macOS），讓你實際操作一遍，Codex 把過程錄下來直接變成一個可重用的 Skill，比用寫的描述穩定的工作流程特別適合。
Automations：把例行任務排程化
Automations 讓 Codex 不用你盯著也能做事，適合固定頻率或可重複的任務，例如 issue 分類、告警監控、CI/CD 相關的例行工作。就像你可以用 Google Trends 定期追蹤關鍵字趨勢。它的重點是把明確、低風險、可驗證的流程變成排程，可審查、可停止、可回復。
MCP（Model Context Protocol）：接外部服務
MCP 是一個開放協定，讓 Codex 連接外部工具與服務。Codex CLI 與 IDE extension 都支援。常見整合包含 GitHub MCP（直接操作 PR、issue、code review）、Sentry MCP（自動讀錯誤報告並修復）、Playwright MCP（讓 Codex 操作瀏覽器做端到端測試）。如果你已經用過我們整理的 免費 Google SEO 工具清單（例如用 Google Search Console 驗網站狀態），會發現 MCP 的邏輯跟這些工具一樣：把分散的功能集中到一個工作流。
外掛（Plugin）：接上現成服務
Codex 還有一層「外掛」概念，很容易跟 Skill 和 MCP 混在一起。簡單分：外掛是把現成的外部服務接進來，例如 Google 日曆、Gmail、Slack、GitHub，你授權後 Codex 才能讀寫這些服務；Skill 是把會重複做的工作流程封裝起來，下次同類任務直接套用；MCP 則是開放協定，讓你或第三方把更客製的工具接上來。三者常搭著用：先裝好 Google 日曆外掛，Codex 才有辦法在整理會議紀錄時，順手把下次開會時間寫進你的日曆。
Subagent 與 Worktrees：多代理並行
Codex 支援 subagent 機制，讓你在主任務中派生多個子代理同時工作；搭配 worktrees（工作樹）與雲端環境，每個代理能在獨立空間執行，不會互相干擾。這對同時修多個 bug、大型重構、或方案比較特別有用。
2026 桌面 app 的新能力：Computer Use、瀏覽器、圖像、遠端控制
2026 年 Codex 桌面 app 加入不少新能力，這些是很多舊教學還沒跟上、但會改變你用法的東西。Codex app 內建瀏覽器，能預覽你做的網頁、協助點擊驗證畫面；Computer Use 讓它在授權下操作 macOS 應用程式；它也能產出圖片、PDF、Excel、文件或簡報，直接在側欄預覽。Remote Control（遠端控制）則讓你從另一個 Codex client 連線控制某個 app 環境，人不在電腦前，也能從別的裝置看進度、批准 Codex 的請求。對需要長時間跑任務又得頻繁核准的工作流，這個功能很實用。各功能的開放資格與作業系統限制以官方文件為準。
核心斜線命令一覽
| 命令 | 功能 |
|---|---|
/plan | 讓 Codex 先產出執行計畫，不直接動 code |
/permissions | 調整 Codex 的權限層級 |
/diff | 查看目前工作樹中的修改 |
/review | 請另一個 Codex review 目前改動 |
/compact | 壓縮上下文，釋放 context window 空間 |
/init | 為當前專案生成 AGENTS.md 初稿 |
/model | 切換模型或調整推理強度 |
/status | 查看當前用量和狀態 |
養成用 /plan 的習慣。在 Codex 執行任何操作前先看完整的步驟規劃，可以避免意外修改。這種「先審查再接受」的態度，在 AI 搜尋時代尤其重要。網站要靠良好的 結構化資料、AI SEO 與 AEO 布局讓搜尋引擎與 AI 答案引擎理解內容（llms.txt 也是同樣思路），你在用 Codex 時也需要把需求與約束表達清楚。
八、多代理並行工作流：用 Codex 做一個完整產品
很多人用了幾次 Codex 後，會習慣「一次只開一個對話」。但 Codex 真正的威力在於多代理並行。你可以把一個產品開發拆成多個獨立任務，每個任務交給不同的 Codex 對話處理。
例如要做一個 AI 工具學習 App，可以這樣拆：
- 一個對話寫產品計畫與需求文件
- 一個對話做前端 UI 設計與元件開發
- 一個對話建後端 API 與資料庫 schema
- 一個對話寫單元測試與整合測試
- 一個對話做登錄等待名單網頁
- 一個對話產生投資人簡報
每個對話都放在同一個專案資料夾裡，用 @ 引用彼此產出的檔案。這不是叫你同時亂開十個任務，而是把每個對話當成一個「專門負責某件事的代理人」。當其中一個任務正在跑，你可以切到另一個任務補需求、測試成果或整理下一步。
這種工作方式的核心是：不要等 AI 做完才開始下一件事；你要學會把工作拆成清楚的小任務，讓多個任務並行。就像 SEO 飛輪模型一樣，多個並行的小努力會累積成複利。
九、實戰場景：四種日常任務範例
場景一：修一個間歇性出現的 bug
前端回報「建立訂單時偶爾會 500 錯誤」，但沒有穩定的重現步驟。你讓 Codex 分析相關函式，檢查未處理的 async/await 錯誤、race condition、未驗證的外部輸入，並看最近的 git log。它讀完可能會告訴你：「createOrder 第 47 行呼叫 inventoryService.checkStock 時沒有 try/catch。」然後你讓它修、加測試、確認 diff。整個過程可能兩三分鐘。
場景二：為既有 API 加新功能
在 src/api/users.js 新增批次刪除功能。你只需要描述需求：路徑、接受格式、錯誤處理、回應格式、必須通過測試。Codex 會參考現有 DELETE /api/users/:id 的實作模式，產出符合團隊慣例的程式碼。
場景三：大規模重構（JS → TS）
這種任務不適合一次丟給 Codex。就像做 頁面 SEO 內容最佳化一樣，一口氣改太多變數會讓你無法判斷哪個改動有效。先用 /plan 分析專案結構、列出遷移優先順序和風險，再逐模組執行。
場景四：把 Codex 用在你不熟、但結構清楚的既有系統
我們自己的真實案例：維運一個 WordPress 站的 SEO 最佳化工作線，背後有一整套 Node 工具腳本，負責打 WordPress REST API 跟 Rank Math SEO 介接、處理精選圖、做內部連結。這套程式碼並不難，但細節很多（跟 程式碼層 SEO 一樣，難在邊界條件）：哪個端點要帶哪個 header、哪個欄位不能送錯、快取層在哪裡。我們把這套腳本交給 Codex，讓它先 /init 生出 AGENTS.md，把那些「送錯會出事」的規則一條條寫進去，再讓它幫忙加測試、補防呆。它最大的價值在於幫我們把一個人人怕動的既有系統，變成有測試保護、可以放心交辦的系統。這正是 Codex 最被低估的用途：替你接手那些「會動但沒人敢碰」的老程式碼，讓你敢於維護它。
十、不寫程式的人也能用 Codex 完成的工作
很多人以為 Codex 是寫程式的人才有資格用的工具。在它剛推出時，這印象不算錯；但 2026 年大改版後，它更像一個「用自然語言就能指揮、會真的把檔案做出來」的工作代理人。你不一定要懂程式，只要能把想完成的事講清楚、把授權範圍設好，它就能幫你跑完許多原本要切換好幾個工具才做得出來的工作。在 搜尋與工具都走向代理化的趨勢裡，這個變化對非工程師的意義，其實比對工程師更大。
做一個活動報名網頁，順便要求它自我檢查
例如想做一個活動報名網頁。你把主題、要放的欄位、風格、手機版不跑版的要求一次說清楚，再補一句「做完請用瀏覽器自動檢查桌機版和手機版有沒有跑版、按鈕能不能按」，它會把網頁做出來、自己跑一輪檢查、回報結果，等你確認。這類「順便要求它自我驗收」的寫法，是非工程師用 Codex 最值得養成的習慣：成果具體，又一定會撞上授權確認那一刻。
整理會議紀錄，順手排進行事曆
再例如整理會議紀錄。把原始筆記餵進去，要它輸出一份結構化的文件（基本資訊、決議、待辦事項、下次開會），並把下次會議時間寫進 Google 日曆。它會在動手寫入日曆前，先把即將新增的內容秀出來等你點頭。前置作業是先連結 Google 日曆這類外掛，Codex 才有辦法幫你寫入。
每天固定收集新聞，寫進試算表
還有一種是排程型的。例如每天早上固定收集產業新聞、整理進試算表，依月份分頁、不覆蓋舊資料、同一則新聞不重複收錄。這是 Codex 自動化（Automations）的典型用法：把規則描述清楚、排好時間，它在背景自己跑，你回來看結果就好。
把這幾個例子擺在一起會發現同一件事：以前要在文書、試算表、日曆、瀏覽器之間來回剪貼的工作，如今只要把規則講清楚，剩下的交給它執行，你負責驗收。但正因為它真的會動手，非工程師更該把「授權前先看它要做什麼、成果出來先看一眼再採用」當成反射動作。我們會建議不寫程式的人從做一個小網頁開始試，因為一定會碰到授權確認那一刻，那是建立對 agent 正確認知最快的捷徑。對非工程師來說，最實在的價值就是這樣：你敢把一件小事交出去，也有能力把它驗收回來。
十一、Codex 與 Claude Code：真實並用分工
如果你已在用 AI coding 工具，很可能聽過 Claude Code；若你在比較其他 AI 助手（例如 Grok），定位也類似。如果你還不熟悉 Claude，可以先看我們的 Claude 教學；在比較桌面版工作流，可以看 Claude Desktop 教學，避免把聊天桌面 App 跟 coding agent 搞混。
核心定位差異
Codex 擅長的是：你把任務描述清楚、派給它、它可以非同步執行，你回來看 diff 就好。Claude Code 擅長的是：你在終端機裡跟它即時互動，邊討論邊改，需要深度推理的場景它表現穩定。
一句話判斷：能寫成任務單、能晚點審 diff 的，先用 Codex。需要即時探索、邊讀邊改的，先用 Claude Code。
真實並用，不是二選一
我們自己的做法就是兩個一起用，而且分工很清楚。Codex 負責可委派的任務，例如修一個能明確重現的 bug、補一份測試、做一輪 code review、跑一個排程自動化。Claude Code 負責需要即時互動的任務，例如一起討論某個架構怎麼拆、某個除錯 session 裡邊讀邊改。兩者讀的是同一份 AGENTS.md / CLAUDE.md，規範一致，不會打架。
這不是「誰比較強」的問題。與其花時間比規格表，不如把這套共用的專案記憶檔寫好，你用哪個 agent 都會變強。它們的搭配，就像 內容集群裡的支柱文章與衛星文章，各司其職但互相支援。
十二、學習路線圖：七天從新手到熟練
如果你是完全新手，照這個順序練，七天後會對 Codex 有紮實的實戰手感。這跟學 SEO 入門一樣，每天做一點比一次讀完一篇長文有效。
- 第一天：安裝 Codex CLI，用 ChatGPT 帳號登入。在任意 git 專案讓 Codex 分析專案結構，產出一份摘要。
- 第二天：請 Codex 做一份研究或整理任務（例如「整理這個專案用到的所有 npm 套件，標出有安全漏洞的」），體驗它讀檔與產出檔案的能力。
- 第三天：用
@檔名讓 Codex 根據既有資料產生新版本。練習引用檔案與追問修改的流程。 - 第四天：用
/init建立 AGENTS.md，把你的專案規範寫進去。然後給 Codex 一個修改任務，觀察它有沒有遵守你的規範。 - 第五天：試試進階功能。安裝一個 MCP server 或建立一個 Skill，體驗 Codex 的擴充能力。
- 第六天：開兩個 Codex 對話，一個做前端、一個做後端。練習多代理並行工作流。
- 第七天：回頭整理你的常用 prompt，把重複的流程做成 Skill 或 Automations。這是從「會用」到「善用」的關鍵轉折。
剛開始用 Codex，最好的目標不是「一次做出完美產品」，而是「把一件小事真的做完」。只要你完成第一份分析、第一個修改、第一個自動化，你就會開始理解：AI coding tool 不只是寫程式，而是把很多原本卡在你腦中的工作，推進到可檢查、可修改、可交付的狀態。
十三、開始使用 Codex：三個立即可行的步驟
如果你還在猶豫要不要投入 AI coding 工具，可以參考我們對 技術 SEO 的真正價值的分析：就像 自然搜尋流量會隨時間累積成長、帶動 轉換率，任何能持續提升效率的工具，長期投資報酬率都比你想像的高。以下是三個立即可行的起步方式：
- 用雲端版感受一下（5 分鐘）：直接開 chatgpt.com/codex，給它一個簡單任務試試，例如「用 Python 寫一個 CLI 工具，統計文字檔中每個單字出現的次數」。感受一下它的互動方式。
- 裝 CLI，在你的專案裡用（15 分鐘）：執行
curl -fsSL https://chatgpt.com/codex/install.sh | sh，登入後 cd 到你的一個 git 專案，輸入「分析這個專案，用一段話說明它做什麼，然後列出前三個可以改善的地方」。 - 建立 AGENTS.md（10 分鐘）：在專案根目錄用
/init生出初稿，再把團隊的程式碼規範、測試方式、技術棧、踩過的雷寫進去。從這個小動作開始，後面每次用 AI coding agent 的品質都會提升。
常見問題 FAQ
- Codex 是免費的嗎？
官方文件顯示 Free 與 Go 方案也能用 Codex，但額度較少。要把 Codex 當日常開發工具，通常會從 Plus 或更高方案開始。實際價格以登入後的 ChatGPT 定價頁為準。 - 不會寫程式，也可以用 Codex 嗎？
可以。2026 年的 Codex 已經能做網頁、整理文件、排程收集資料這類不見得需要懂程式的工作，重點是把任務描述清楚、設好資料夾授權、每次它要動手前先看一眼。但牽涉金流、會員資料、權限或正式上線的功能，最終仍要交給懂的人把關；它能降低門檻，不能取代把關。 - 可以用什麼方式付款？
多數使用者可用平台支援的付款方式訂閱 ChatGPT，但卡別、稅費、幣別和可用方案會受帳號與結帳頁影響。建議直接看官方結帳頁。 - Codex 會把我的程式碼送去哪裡？
取決於你用哪種入口。雲端任務通常在 OpenAI 的雲端環境處理連接的 repo；CLI 在你的本機工作。處理高度機密程式碼時，先確認資料控制與工作區政策。官方也提供企業版的資料治理與 RBAC 控制。 - Codex CLI 要怎麼安裝？
官方主推獨立安裝腳本curl -fsSL https://chatgpt.com/codex/install.sh | sh，npm 的npm i -g @openai/codex與 Homebrew 也支援。安裝後在專案資料夾輸入codex，第一次會提示登入。 - 我已經在用 GitHub Copilot，還需要 Codex 嗎？
兩者定位不同。Copilot 偏向 IDE 內的即時補全與聊天助手，你打字它建議。Codex 是能自主完成任務的 agent，你派任務它執行。如果你只要打字時的即時建議，Copilot 就夠；如果你想讓 AI 自己讀懂專案、修改多個檔案、跑測試、開 PR，那是 Codex 的場景。 - Codex 每次都會產出正確的結果嗎？
不會。Codex 跟所有 AI 工具一樣，有可能判斷錯誤或產出不完美的 code。這就是為什麼你要用/plan、/permissions、/diff和測試流程把關。建議始終在 git 裡工作，先用保守權限，確認 diff 後再接受。 - Codex 用的是哪個模型？
根據 OpenAI 官方文件，目前最新的主力模型是 GPT-5.5，也會提供較輕量、較快的模型選項。實際可用模型以你介面內/model顯示的為準，模型會持續更新。 - Codex 額度用完怎麼辦？
先看 Codex usage dashboard 或 CLI 的/status。可行選項通常包括等額度重置、加購 credits（部分 Plus / Pro 使用者）、切換較小模型、縮小任務範圍、精簡 AGENTS.md 與 MCP context，或改用 API key 按 API 用量計費。就像面對 零點擊搜尋趨勢要調整內容策略，額度管理也是用 AI 工具的基本功。
參考資料
- OpenAI Codex 官方頁面：產品介紹與功能總覽
- OpenAI Codex Developer Docs：入口、概念與功能文件
- Codex CLI 文件：安裝、命令與進階功能
- Using Codex with your ChatGPT plan：方案、額度與資料控制說明
- Claude Code Overview – Anthropic Docs：Claude Code 入口與基本能力
