如果你還沒有用過 Codex，可以先把它想像成一位「坐在你專案資料夾裡的 AI 程式開發同事」。
它不是單純的聊天機器人，而是可以協助你讀程式碼、修改檔案、執行命令、查看 diff、撰寫測試，甚至幫你進行程式碼 review 的開發助理。不過，Codex 雖然聰明，但也需要被正確管理。你必須學會如何下指令、如何限制它的行動範圍，以及如何檢查它的修改結果，才能真正安全又有效地使用它。
Codex 指令是什麼？
在 Codex 裡，大致有兩種輸入方式。
第一種是一般 prompt，也就是你平常對 AI 下的工作需求，例如：
幫我看一下這個專案怎麼啟動
幫我修一下登入頁 bug
幫我把這個函式重構得清楚一點這類輸入的重點是「讓 Codex 做事」。
第二種則是斜線指令，也就是以 / 開頭的命令，例如：
/init
/model
/plan
/diff
/review
/compact簡單來說：
一般 prompt = 你要 Codex 做什麼
斜線指令 = 你要怎麼管理 Codex這個觀念很重要。因為如果你只把 Codex 當成聊天工具，就很容易忽略它其實能直接操作專案檔案；但如果你能善用斜線指令，就可以讓它更像一位受控、可靠的開發夥伴。
使用 Codex 前要先知道的三件事
首先，斜線指令必須放在輸入的最前面。
例如：
/model這樣 Codex 才會把它判定為指令。
但如果你輸入：
請幫我 /model這時候 /model 就只會被視為一般文字，而不是指令。
第二，如果你忘記有哪些指令，可以直接輸入：
/Codex 會顯示目前可用的指令列表。你也可以繼續輸入字母來篩選，例如輸入 /mo，就可能看到 /model。
不過，每個人看到的指令列表可能不完全一樣，因為這會受到 Codex 版本、系統環境、插件、權限與實驗功能影響。所以最準確的方式，永遠是看你自己本機輸入 / 後顯示的內容。
第三，不要把 Claude Code 的使用方式完全套到 Codex 上。
例如 Claude Code 常見的是 CLAUDE.md，但 Codex 更常使用的是 AGENTS.md。你可以把 AGENTS.md 理解成寫給 Codex 的「專案入職手冊」。只要把專案規則、啟動方式、測試命令、禁止修改的目錄寫進去，Codex 之後進入專案時就能先理解這些基本規範。
新手最該掌握的 10 個 Codex 指令
1. /init
當 Codex 第一次進入你的專案時，它對你的程式碼一無所知。它不知道這個專案怎麼啟動、怎麼測試、哪些資料夾不能動，也不知道團隊的開發規範。
這時候可以先輸入：
/init它會協助你建立 AGENTS.md。
建立之後，建議你自己補上專案規則，例如：
本專案使用 pnpm
開發命令是 pnpm dev
測試命令是 pnpm test
不要修改 dist 和 generated 目錄
所有 API 請求都集中在 src/lib/api.ts這些資訊非常重要，因為你不用每次都重新提醒 Codex。只要寫進 AGENTS.md，它之後就能自動參考。
2. /status
當你不確定 Codex 目前的狀態時，可以使用：
/status它會顯示目前使用的模型、權限策略、所在目錄、可寫範圍與上下文情況。
這個指令很適合用在以下情境：
不確定 Codex 會不會改錯目錄
懷疑模型沒有切換成功
不知道目前是不是只讀模式
覺得對話變長、上下文快不夠對新手來說，遇到問題時先看 /status 是很穩的排查方式。
3. /model
不同任務適合不同模型。
小任務可以用速度快、成本低的模型；複雜任務則適合切換到能力更強的模型。
輸入：
/model就可以開啟模型選擇器。
通常這些任務適合使用較強的模型：
大型重構
複雜 bug
陌生程式碼庫分析
跨模組遷移
架構設計
安全敏感改動而這些任務通常不需要用到最強模型：
修改文案
解釋小函式
修簡單型別錯誤
產生小工具腳本
閱讀單一檔案 可以簡單記成一句話：
小活別燒錢，大活別省錢。
4. /permissions
Codex 不只是回答你問題，它真的可能修改你的檔案、執行命令。因此，權限設定非常重要。
輸入：
/permissions可以管理 Codex 的操作權限，例如只讀、允許修改檔案、執行命令前是否需要詢問等。
新手建議一開始保守一點，不要直接開全自動。可以先讓 Codex 閱讀專案、提出方案、解釋原因，等你熟悉它的行為後，再逐步放寬權限。
尤其是以下情況，更不建議一開始就放任 Codex 自動操作：
正式環境專案
老舊專案
沒有 Git 版本控制的專案
多人協作中的專案
5. /plan
大任務不要一開始就讓 Codex 直接動手。
例如你不要直接輸入：
幫我重構權限系統比較好的方式是先用：
/plan 幫我分析目前權限系統，給出最小風險的重構方案，先不要改程式碼。/plan 很適合用在：
重構
遷移
複雜 bug
效能優化
多檔案修改
風險不明確的任務新手可以記住一個原則：
任務越大，越要先 /plan。
6. /mention
如果你不希望 Codex 在整個專案裡亂翻，可以直接指定檔案。
例如：
/mention src/api/user.ts接著再問：
幫我解釋這個檔案的請求流程。這個指令適合用在：
指定錯誤檔案
指定元件
指定設定檔
讓 Codex 只圍繞某個檔案分析
避免它讀太多不相關內容很多新手遇到小 bug 時，會讓 Codex 去看半個專案，結果反而浪費時間。你直接給它關鍵檔案，通常效率會高很多。
7. /diff
Codex 修改完程式碼後，不要只看它自己的文字總結。
一定要看真實改動。
輸入：
/diff你可以看到它新增、刪除、修改了哪些內容。
這條指令非常重要。因為 AI 的摘要可能漏講，但 diff 不會。Codex 可能說「我只做了一個小修改」，但實際上它可能改了更多地方。
所以只要 Codex 有動到檔案，就應該養成看 /diff 的習慣。
8. /review
Codex 寫完程式後，你可以讓它切換成 reviewer 的角度再檢查一次。
輸入：
/review它會幫你檢查：
是否有 bug
是否造成行為回歸
是否缺少測試
是否漏掉邊界條件
是否有安全風險在提交前，建議固定使用這組流程：
/diff
/review先看實際改動，再讓 Codex 幫你審查。
9. /compact
當你和 Codex 聊很久之後，對話上下文會越來越長，回應可能變慢，成本也可能增加。
這時候可以使用：
/compact它會把前面的對話壓縮成摘要，然後繼續目前任務。
要注意的是，/compact 不是清空對話，而是壓縮歷史。如果你想完全換一個新任務，才比較適合使用 /new 或 /clear。
如果你擔心重要資訊被壓縮掉，也可以這樣寫：
/compact 保留登入模組的結論、已修改檔案、剩餘 bug 和測試失敗資訊。
10. /resume
如果你昨天讓 Codex 修一個 bug，還沒完成，今天想接著做，可以輸入：
/resume它會開啟歷史會話列表，讓你選擇之前的對話繼續。
這個指令很適合：
跨天任務
大型專案遷移
長時間 debug
分階段開發
開了 fork 後想回主線/side 與 /fork 的差別
新手很容易混淆 /side 和 /fork。
可以先記這句話：
/side 是臨時問一句
/fork 是開一條新路線 /side：臨時側聊
當你正在修 bug，但突然想問 Codex 一個不想打斷主線的問題，就可以用：
/side 這個方案有沒有明顯風險？它適合：
臨時問一個判斷
檢查方案風險
詢問概念解釋
不想污染主線任務 但它不適合複雜多輪討論，也不適合正式嘗試另一套實作方案。
/fork：開新分支
如果你想保留目前主線，同時嘗試另一種實作方式，可以使用：
/fork這就像是在 Git 裡開一個 branch。
它適合：
嘗試另一種架構
比較兩個方案
保留主線同時開實驗線
讓 Codex 用不同思路解決同一個問題如果之後想回到原本主線，可以用：
/resume再從歷史會話中選回原本那條。
第一次使用 Codex 的建議流程
如果你是第一次使用 Codex，可以照這個流程走。
第一步，進入專案目錄：
cd my-project
codex第二步，初始化專案說明：
/init第三步，查看目前狀態：
/status第四步，先讓 Codex 讀專案，不要急著改：
先不要改程式碼，幫我讀一下這個專案結構，告訴我啟動命令、測試命令、主要模組和最危險的目錄。第五步，大任務先請它規劃：
/plan 幫我修復登入頁提交後 loading 狀態不消失的問題。先定位相關檔案，給出最小改動方案，不要直接改程式碼。第六步，確認方案後再讓它實作：
按方案實作，保持改動盡量小。第七步，看真實改動：
/diff第八步，提交前審查：
/review這是一套很適合新手的穩定流程：
先讓它讀
再讓它想
確認後再改
最後由你驗收
寫好 AGENTS.md，Codex 才不會每次都像新員工
/init 只是開始，真正有價值的是你後續寫進 AGENTS.md 的專案規則。
你可以把它寫成這樣：
# Project Guide for Codex
## Commands
Install: pnpm install
Dev: pnpm dev
Test: pnpm test
Lint: pnpm lint
Build: pnpm build
## Rules
Do not edit dist/
Do not edit generated files
Keep changes minimal
Run tests after touching business logic
Use existing components before creating new ones
## Architecture
API clients live in src/lib/api
Shared UI components live in src/components
Route pages live in src/pages
Auth logic lives in src/auth
## Before finishing
Explain changed files
Mention tests run
Mention tests not run
這份文件的價值在於，你不用每次都重新告訴 Codex：
我們專案用 pnpm
不要改 dist
提交前要跑測試
API 都放在哪裡
共用元件在哪裡
只要把規則寫好，Codex 就能長期參考。這也是把 Codex 從「聊天工具」變成「專案同事」的關鍵。
常見問題整理
我看到的指令比文章裡少，正常嗎？
正常。
Codex 可用指令會受到版本、作業系統、插件、實驗功能與設定影響。最準確的方式，是直接在你的 Codex 裡輸入 / 查看當前可用列表。
Codex 會不會亂改我的程式碼？
有可能。
這通常取決於三件事：
你的權限設定是否太寬
你的 prompt 是否清楚
你有沒有檢查 /diff
所以新手不要一開始就全自動。先讓它讀、讓它計畫、讓它說明，再決定是否讓它修改。
/compact 會不會讓 Codex 忘記東西？
它會壓縮歷史，不會完整保留每個細節。
如果你擔心重要資訊遺失，可以在 /compact 後面補充要保留的內容，例如：
/compact 保留登入模組結論、已修改檔案、剩餘 bug 和測試失敗資訊。
/new 和 /clear 有什麼不同？
簡單理解即可：
/new 是開新對話
/clear 是清空終端顯示並 fresh chat
新手不用太糾結。任務還沒結束，用 /compact；任務結束要換新主題，再考慮 /new 或 /clear。
/fork 後怎麼回主線？
使用：
/resume
然後從歷史會話中選回原本的那條對話。
Codex 改完程式後，我應該做什麼？
建議固定三步：
/diff
/review
執行測試
不要只相信 Codex 的文字總結。真正可靠的是 diff 和測試結果。
Codex 和 ChatGPT 寫程式有什麼不同？
ChatGPT 比較像遠端顧問，你通常需要把程式碼貼給它，它才能幫你分析。
Codex 則比較像坐在你專案資料夾裡的同事。它可以直接讀檔案、改檔案、跑命令、看 diff，工作方式更接近實際開發流程。
新手使用 Codex 的口訣
最後可以用這組口訣記住 Codex 的基本操作：
先 /init，讓 Codex 認識專案。
再 /status，確認目前狀態。
大任務先 /plan。
關鍵檔案用 /mention。
改完一定看 /diff。
提交前跑 /review。
對話長了用 /compact。
明天回來用 /resume。
臨時問一句用 /side。
想試新路線用 /fork。
結語：不要把方向盤完全交給 AI
Codex 指令看起來很多，但新手不用一開始全部背起來。只要先掌握 /init、/status、/plan、/diff、/review 這幾個核心指令，就已經能處理大部分日常開發任務。
最重要的是，不要一開始就追求全自動。
你應該把 Codex 當成一位很聰明、但仍然需要你管理的程式開發同事。你給它清楚的上下文，它就少猜；你給它明確的邊界，它就少亂動；你看 diff，它就不容易糊弄你。
真正會用 Codex 的人，不是把方向盤完全交給 AI，而是讓 AI 坐在副駕駛座，幫你看路、查地圖、提醒風險，必要時再讓它替你開一段路。
