很多人第一次打開 Codex,只把它當成「終端機裡的 ChatGPT」。這會浪費它最有價值的能力:Codex 不是用來陪你聊天的,它是可以進入本地專案、閱讀程式碼、修改檔案、執行測試的 AI Coding Agent。
如果你只是偶爾問幾句程式碼問題,直接用 ChatGPT 也夠。但如果你每天都要修 bug、寫測試、做 code review、改腳本、維護多個客戶專案,那麼 Codex 的正確用法就不是「能不能用」,而是:怎麼安全地用、怎麼穩定地用、怎麼把成本控制住。
這篇教學從 0 開始,帶你完成 2026 年 Codex 的完整工作流:安裝、登入、在專案內使用、常見任務提示詞、進階 review 流程,以及如何透過 LowCostAI 這類統一 AI API Gateway 設定 OpenAI 相容 API,讓 Codex 更適合個人開發者、工作室和小團隊長期使用。
目錄
- Codex 到底是什麼
- 安裝 Codex CLI
- 第一次啟動:ChatGPT 登入還是 API Key
- 第一個真實專案:讓 Codex 先讀再改
- 5 個最常用的 Codex 工作流
- 進階用法:把 Codex 當成有邊界的工程師
- 省錢設定:接入 OpenAI 相容 API
- 用 LowCostAI 管理 Codex 成本
- 常見錯誤與排查
- FAQ
Codex 到底是什麼
Codex CLI 是 OpenAI 推出的本地命令列 coding agent。它執行在你的終端機裡,可以讀取目前專案目錄裡的檔案,理解程式碼結構,修改程式碼,並執行測試、建置、lint 等命令。
它和普通聊天工具最大的差別是:
- ChatGPT:你把程式碼複製給它,它給你建議。
- Codex:它進入你的專案目錄,自己看檔案、改檔案、跑命令。
這代表 Codex 更適合處理「有上下文」的工程任務,例如:
- 閱讀陌生專案並總結結構
- 定位啟動失敗原因
- 修復一個具體 bug
- 為既有模組補測試
- 重構某個檔案而不改變外部行為
- review 目前 git diff
- 生成 README、遷移說明、發布日誌
但這也代表你要給它清晰邊界。Codex 可以很快,但不能盲信。最好的使用方式不是「讓它自動接管整個專案」,而是把任務拆小:先分析、再計畫、後執行,最後由你 review diff。
安裝 Codex CLI
macOS 和 Linux 可以使用官方安裝腳本:
curl -fsSL https://chatgpt.com/codex/install.sh | sh
Windows PowerShell 可以使用:
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
如果你習慣 npm,也可以安裝 npm 套件:
npm install -g @openai/codex
macOS 使用者也可以用 Homebrew:
brew install --cask codex
安裝完成後檢查版本:
codex --version
進入任意專案目錄啟動:
cd your-project
codex
如果能進入 Codex 的互動介面,說明安裝完成。
第一次啟動:ChatGPT 登入還是 API Key
Codex 常見有兩種登入方式:ChatGPT 帳號登入,以及 API Key 登入。
方式一:ChatGPT 帳號登入
第一次執行:
codex
然後選擇 Sign in with ChatGPT。
這種方式適合剛開始體驗 Codex 的使用者。你不需要理解 Base URL、模型 ID、API Key、Gateway 設定,登入後就能直接使用。
適合:
- 個人開發者快速體驗
- 已經有 ChatGPT Plus / Pro / Business 的使用者
- 不需要團隊帳單和專案級統計的場景
缺點也很明顯:如果你是小團隊或工作室,很難按專案、成員、客戶分別統計用量,也不方便設定 Key 級額度。
方式二:API Key 登入
如果你想把 Codex 接到 OpenAI API,或者接到 LowCostAI 這樣的 OpenAI 相容 API Gateway,可以使用 API Key。
臨時測試可以這樣:
export OPENAI_API_KEY="YOUR_API_KEY"
codex
如果使用 OpenAI 相容 Gateway,還需要設定 Base URL:
export OPENAI_API_KEY="YOUR_GATEWAY_KEY"
export OPENAI_BASE_URL="https://your-gateway.example.com/v1"
codex
很多介面要求 Base URL 以 /v1 結尾。如果你少寫 /v1,可能會遇到 404、model not found、streaming 異常等問題。
API Key 方式更適合:
- 高頻使用 Codex 的開發者
- 需要控制成本的小團隊
- 外包工作室和客戶專案
- 需要統一模型入口、統一帳單、Key 級額度控制的場景
第一個真實專案:讓 Codex 先讀再改
新手最容易犯的錯誤是,一進專案就對 Codex 說:
幫我最佳化這個專案。
這句話太寬了。Codex 不知道「最佳化」指效能、結構、命名、型別、安全還是建置速度,很容易做出一堆你並不想要的修改。
更穩的第一步是讓它只讀分析:
請閱讀目前專案,輸出:
1. 技術棧
2. 主要目錄結構
3. 啟動命令
4. 測試命令
5. 最重要的業務模組
不要修改任何檔案。
當你確認它理解專案後,再讓它做診斷:
請檢查目前專案最可能導致建置失敗的問題。先輸出診斷和修復計畫,不要修改程式碼。
最後才允許它執行:
按剛才的計畫修復,只修改必要檔案。完成後執行測試,並總結改動。
這個「三步法」非常重要:
- 先讀專案
- 再給計畫
- 最後修改和驗證
它能顯著降低 AI 亂改程式碼的機率。
5 個最常用的 Codex 工作流
1. 專案導覽
接手新專案時,可以讓 Codex 生成專案說明:
請閱讀目前專案,生成一份面向新開發者的專案導覽,包括技術棧、目錄結構、啟動方式、測試方式、核心模組和常見注意事項。不要修改程式碼。
如果結果不錯,再讓它寫入文件:
請把上面的專案導覽整理為 PROJECT_OVERVIEW.md。
2. 修復啟動失敗
專案跑不起來時,不要直接讓它「修好」,先定位:
這個專案啟動失敗。請檢查 package.json、設定檔和錯誤日誌,定位原因。先給診斷,不要修改檔案。
確認診斷後:
按你的診斷修復問題,然後執行啟動命令驗證。
3. 生成測試
寫測試是 Codex 性價比最高的任務之一:
請為 src/utils/price.ts 添加單元測試,覆蓋正常輸入、邊界值和異常輸入。先閱讀既有測試風格,不要引入新的測試框架。
關鍵是告訴它「保持既有風格」。否則它可能會引入專案裡根本沒用過的新工具。
4. 小範圍重構
適合 Codex 的重構應該邊界清晰:
請重構 src/api/user.ts,目標是減少重複程式碼和提升可讀性。不要改變公開函式簽名,不要修改無關檔案。完成後執行相關測試。
不要讓它「一次性重構整個專案」。AI agent 最適合做小步、可驗證、可回滾的修改。
5. 本地 Code Review
提交前可以讓 Codex review 目前 diff:
請 review 目前 git diff,重點檢查:
1. 潛在 bug
2. 型別問題
3. 安全風險
4. 效能問題
5. 是否缺少測試
不要修改程式碼,只輸出可執行建議。
這一步特別適合個人開發者。你沒有同事幫你 review 時,Codex 至少能提前攔下一部分低級錯誤。
進階用法:把 Codex 當成有邊界的工程師
Codex 不是「全自動工程師」,更像一個執行力很強但需要邊界的 junior engineer。你給它的任務越清晰,它的產出越穩定。
複雜任務建議使用這種提示詞:
我要增加一個 API Key 用量統計頁面。請先閱讀專案結構,然後輸出實作計畫:
1. 需要修改哪些檔案
2. 新增哪些元件
3. 資料從哪裡來
4. 風險點是什麼
5. 如何測試
先不要修改程式碼。
等計畫合理後再執行:
計畫可以。請按階段實作。每完成一個階段說明改動,並執行對應檢查。
如果涉及高風險模組,例如支付、認證、權限、資料庫遷移,要明確禁止範圍:
不要修改資料庫 schema,不要修改鑑權邏輯,不要執行 git commit。完成後只執行測試並總結 diff。
一個成熟的 Codex 工作流通常是:
- Codex 讀專案
- Codex 給計畫
- 人確認邊界
- Codex 修改程式碼
- Codex 跑測試
- 人檢查 git diff
- 人提交 commit
注意最後一步:不要讓 AI 自動替你提交關鍵程式碼。提交是責任邊界,最好由人完成。
省錢設定:接入 OpenAI 相容 API
當你每天只用 Codex 幾次時,預設登入方式就夠了。但當你開始高頻使用它做測試、review、文件和腳本時,成本會變成一個真實問題。
這時可以考慮把 Codex 接入 OpenAI 相容 API Gateway。
臨時測試:
export OPENAI_API_KEY="YOUR_LOW_COST_API_KEY"
export OPENAI_BASE_URL="https://api.lowcostaiapi.com/v1"
codex
這裡的 https://api.lowcostaiapi.com/v1 請以 LowCostAI 後台實際展示為準。如果後台給出的 Base URL 不同,就用後台地址。
長期使用建議寫入 Codex 的使用者級設定檔:
~/.codex/config.toml
範例設定:
model = "your-default-model"
model_provider = "lowcostai"
[model_providers.lowcostai]
name = "LowCostAI"
base_url = "https://api.lowcostaiapi.com/v1"
env_key = "LOWCOSTAI_API_KEY"
wire_api = "responses"
然後在 shell 中設定:
export LOWCOSTAI_API_KEY="YOUR_LOW_COST_AI_KEY"
再啟動:
codex
這樣做的好處是,你不需要在每個專案裡重複寫 Key,也不會把敏感資訊提交進程式碼倉庫。
用 LowCostAI 管理 Codex 成本
LowCostAI 的定位不是「只換一個便宜介面」,而是給團隊、工作室和開發者一個統一的 AI API 接入與用量管理入口。
對 Codex 使用者來說,真正有價值的是這幾件事:
- 統一接入 Claude、OpenAI、Gemini 等模型
- 支援 Codex、Claude Code、Cursor、Gemini CLI 等 AI Coding 工具
- 為不同成員、專案或客戶建立獨立 Key
- 按 Key 查看用量和帳單
- 設定額度,避免單個任務失控
- 用透明口徑展示模型價格、匯率和平台倍率
建議小團隊這樣分 Key:
codex-personal-dev
codex-team-review
codex-client-a
codex-client-b
codex-ci-automation
每個 Key 對應一個明確用途。這樣你可以知道:
- 哪個專案最耗錢
- 哪個客戶的 AI 成本最高
- 哪個自動化任務異常消耗
- 哪些模型適合降級
- 哪些任務必須保留高品質模型
省錢的關鍵不是「永遠用最便宜的模型」,而是按任務分層:
適合低成本模型的任務:
- 解釋日誌
- 生成簡單測試
- 寫腳手架程式碼
- 總結目錄結構
- 生成 README 初稿
- 批量改文案
適合高品質模型的任務:
- 安全相關程式碼
- 權限和支付邏輯
- 資料庫遷移
- 大型重構
- 架構設計
- 最終 code review
這才是 AI Coding 的長期省錢方式:低風險任務降成本,高風險任務保品質。
常見錯誤與排查
Base URL 少了 /v1
錯誤範例:
export OPENAI_BASE_URL="https://api.lowcostaiapi.com"
更常見的正確形式:
export OPENAI_BASE_URL="https://api.lowcostaiapi.com/v1"
具體以後台顯示為準。
目前終端機沒有載入 Key
檢查:
echo $OPENAI_API_KEY
echo $LOWCOSTAI_API_KEY
如果輸出為空,說明目前 shell 沒有載入環境變數。重新 export,或執行:
source ~/.zshrc
模型名不匹配
Codex 設定裡的 model 必須是 Gateway 支援的模型 ID。後台顯示什麼,就填什麼。不要憑記憶寫模型名。
Provider 只支援普通 Chat Completions
Codex 不是普通聊天客戶端。它可能需要 Responses API、streaming、工具調用等能力。接入 Gateway 前,建議確認:
- 是否支援 OpenAI-compatible API
- 是否支援 Codex CLI 所需介面
- 是否支援 streaming
- 推薦模型名是什麼
- Base URL 是否需要
/v1
一次性讓 Codex 改太多
不要寫:
幫我最佳化整個專案。
改成:
只分析 src/api 目錄的重複程式碼,輸出重構建議,不要修改檔案。
AI Coding 的穩定性來自小步快跑,而不是一次梭哈。
FAQ
Codex 適合完全不會寫程式的人嗎?
適合學習和做小工具,但不適合完全不 review 地交付生產程式碼。Codex 能解釋程式碼、生成範例、輔助排錯,但你仍然需要判斷它的修改是否合理。
ChatGPT 登入和 API Key 哪個更好?
新手用 ChatGPT 登入最簡單。高頻使用者、小團隊和工作室更適合 API Key,尤其適合接入 LowCostAI 這類統一 Gateway,方便管理 Key、額度和帳單。
Codex 能透過 LowCostAI 使用嗎?
可以,前提是 LowCostAI 後台提供的 OpenAI 相容介面支援 Codex 所需能力。通常你需要設定 API Key、Base URL 和模型名。
怎麼防止 Codex 亂改程式碼?
讓它先只讀分析,再輸出計畫;明確限制修改範圍;要求它執行測試;最後你自己檢查 git diff。不要給它過於寬泛的任務。
最推薦的 Codex 省錢策略是什麼?
按任務分層。低風險任務用低成本模型,高風險任務用高品質模型;同時透過 LowCostAI 給不同專案和客戶分 Key、設額度、查用量。
下一步
如果你還沒用過 Codex,建議先從一個非核心專案開始:讓它讀專案、補測試、review diff。等你熟悉工作流後,再把它接入 LowCostAI,給不同專案設定獨立 Key 和額度。
對個人開發者,Codex 能節省大量重複勞動。對小團隊和工作室,Codex + LowCostAI 的組合更像一套可管理的 AI Coding 基礎設施:統一入口、成本可查、額度可控、模型可切換。
你可以從這裡開始: