爆肝萬字！這應該是全網最完整的 Codex 實戰教學了

大家好，我是 Sunday。

最近這段時間，我後台被同一個問題問到快瘋了。

Codex 到底怎麼用？

CLI、App、VS Code 插件，三個入口擺在那裡，看起來都能用。

plugins、skills、MCP、automations、AGENTS.md、子 agent、權限模式，又一個個冒出來。

你只是想讓它幫你改個程式碼。結果它先塞給你一整套新概念。

不是啊，我只是想修個 bug，怎麼突然像在學一門新職業。。。

所以我昨天特別花了一下午，把 Codex 這套東西重新梳理了一遍，順手錄了一個比較完整的影片。

錄完之後我發現，這裡面其實有很多地方，只看影片很容易滑過去。

尤其是那些 提示詞模板、權限邊界、版本管理、上下文管理，還有什麼時候該讓 Codex 只讀，什麼時候可以讓它動手改程式碼。

這些東西如果不寫下來，真的很容易看完就忘。

所以我乾脆把影片對應的文案重新整理成了這篇文章。

不敢說多權威。

但如果你是工程師，或者你正在用 Codex、Claude Code、Cursor 這類工具做專案，我覺得這篇應該能幫你少踩不少坑。

這篇主要會講這些內容：

• Codex 的三大入口
• 使用 Codex 的注意事項
• 權限模式
• Codex 最佳實踐
• 提示詞與 token 消耗的關係
• 多模態能力
• 版本管理
• 上下文管理
• 長期記憶
• skills
• plugins
• MCP
• 自動化
• 一個完整案例
• 我常用的 Codex 指令模板
• 彩蛋

那麼，我們開始～～

Codex 的三大入口

回到 Codex 本身。

現在 Codex 大概有三個主要入口：

• Codex CLI
• Codex App
• Codex IDE 插件

我們一個一個來說。

第一個是 Codex CLI 。

也就是命令列版本。

如果你是工程師，可以直接透過 npm 安裝：

bash 体验AI代码助手 代码解读复制代码npm install -g @openai/codex

安裝之後，在專案根目錄裡輸入：

bash 体验AI代码助手 代码解读复制代码codex

就可以啟動。

如果你想更新，也可以用：

bash 体验AI代码助手 代码解读复制代码codex --upgrade

CLI 的優點是輕量、直接、適合終端機派。

你在哪個專案目錄打開它，它就會基於哪個專案開始工作。

當我們讓 Codex 第一次接觸一個專案時，可以先讓它讀這個專案。

一般我的提示詞是：

text 体验AI代码助手 代码解读复制代码請先閱讀目前專案結構，不要修改任何程式碼。

告訴我：
1. 這個專案是做什麼的
2. 使用了哪些技術棧
3. 入口檔案在哪裡
4. 啟動、建置和測試命令是什麼
5. 如果我要新增一個功能，應該從哪裡開始

這個習慣非常重要。

很多人用 Vibe Coding 翻車，不是模型不行，是自己太急著讓它改程式碼了。

這樣不翻車才怪。

第二個入口是 Codex App

這個我覺得更適合新手。

直接從官網就可以下載，macOS 和 Windows 都有安裝檔。

因為 App 比 CLI 更像一個完整的 AI 程式開發工作台。

你可以開新對話、搜尋歷史、管理插件、安裝 skills、設定自動化。

官方現在也把 Codex App 定位成多 agent 工作台。

也就是說，它不是只讓你和一個 AI 聊天。

而是讓你可以同時開多個任務，讓不同 agent 在不同專案、不同分支、不同 worktree 裡工作。

如果你第一次用 Codex，我更建議從 App 開始。

因為 CLI 很爽，但它對新手不太友善。

目錄、權限、命令、上下文、沙盒、git 狀態，這些東西混在一起，很容易把人搞懵。

App 至少能讓你有一個更清楚的工作台視角。

第三個入口是 IDE 插件

比如在 VS Code、Cursor 裡直接用 Codex。

這個適合你已經在寫程式，想讓 Codex 在目前工程裡協助你處理某個檔案、某個 bug、某個元件的時候使用。

我們以 VS Code 為例。

直接在外掛市集中搜尋 Codex，安裝外掛即可。

然後打開對應專案，就可以在右上角找到 Codex 的圖示。

點進去之後，就能直接進入 Codex 的工作台。

同時要注意：

如果你同時安裝了 Codex App 和 Codex IDE 插件，它們的資料是可以互通的。

使用 Codex 的注意事項

那第一次用 Codex，應該怎麼開始？

我建議你不要一上來就找一個公司核心專案練手。

先找一個 demo 專案。

或者找一個你自己不怕改壞的小專案。

然後確認這個專案已經被 git 管理。

如果還沒有，可以先透過以下指令初始化：

bash 体验AI代码助手 代码解读复制代码git init
git add .
git commit -m "initial commit"

這樣做的目的是：確保萬一 Codex 把你的程式碼改錯了，你還能還原回去。

同時要注意，當我們使用 Vibe Coding 進行開發時，每次 Codex 修改了程式碼之後，最好都做一次 git commit，以防萬一。

所以，一定要做好版本管理。

另外，第一次啟動 Codex，不要讓它寫程式碼。

就讓它讀專案。

給大家一個我常用的提示詞：

text 体验AI代码助手 代码解读复制代码請先不要修改任何程式碼。

你現在只需要閱讀專案結構，並告訴我：
1. 這個專案是做什麼的
2. 使用了哪些技術棧
3. 入口檔案在哪裡
4. 啟動和建置命令是什麼
5. 如果我要新增一個頁面，應該從哪裡開始

這一步做完之後，你再看它的理解準不準。

如果它理解錯了，就修正它。

不要急著讓它動手。

你可以繼續問：

text 体验AI代码助手 代码解读复制代码你剛才對專案的理解裡，有哪些地方是不確定的？

請列出來，並說明你還需要查看哪些檔案。

這樣的方式實測非常好用，分享給大家。

權限模式

接著講權限模式。

這個東西很多人會忽略，但我覺得它非常關鍵，所以單獨拿出來講一下。

我們知道，Codex 是可以讀取和修改你本機程式碼和檔案的。

這樣就會涉及到本機檔案安全的問題。

比如，萬一 AI 直接把你電腦裡很重要的檔案刪了，那就麻煩了。

所以，為了避免這個問題，Codex 裡的權限模式通常可以分成三種。

第一種是 預設權限

預設權限最安全，也可以說最保守。

它可以讀檔，可以給你提出修改建議，也可以提出要執行的 shell 指令。

但是，真正修改檔案或者執行指令之前，需要你主動批准。

好處是安全。

壞處是你不能離開。

畢竟每一步你都得主動確認。

第二種是 自動審查模式

它比預設權限稍微激進一點。

預設權限是，AI 想改檔案、想執行指令，都要先問你。

自動審查的意思是，Codex 會先自己判斷這個操作是不是安全。

如果它只是修改目前專案裡的普通程式碼，或者執行一些常見指令，比如安裝依賴、跑測試、跑建置，那它可能就會自動通過，不用你每一步都按確認。

這樣做的好處是效率更高。

比如你讓 Codex 修一個 bug，它可能會先讀程式碼，然後改程式碼，然後跑測試，再根據錯誤繼續修改。

如果每一步都要你確認，其實就很打斷節奏。

但是自動審查也不是完全放開。

如果 Codex 要做一些風險比較高的事情，比如刪除檔案、存取專案外目錄、讀取敏感檔案、連網下載東西，或者執行一些危險指令，它還是會停下來讓你確認。

所以自動審查更適合什麼場景？

適合你已經比較熟悉這個專案，也比較信任目前這次任務。

你希望 Codex 能連續多做幾步，不要每一步都來問你。

但你又不想完全放開權限。

這時候，用自動審查就比較合適。

它其實是一個折衷模式：

比預設權限更省心，但比完全存取權限更安全。

第三種是 完全存取權限

這個模式就要謹慎了。

你可以把它理解為：把 Codex 的限制降到最小。

在這個模式下，Codex 可以更自由地讀取檔案、修改檔案、執行指令，甚至存取專案外的目錄和網路。

好處是執行效率最高。

比如你讓它做一個比較大的任務：遷移專案、批次重構、安裝依賴、跑腳本、跨多個目錄改程式碼。

它不需要一直停下來等你確認，可以更像一個真正的開發助手一樣，連續把事情往下推進。

但是風險也最大。

因為一旦它理解錯了你的意思，或者執行了一個不該執行的指令，就可能真的影響你本機的檔案。

所以我不建議大家日常一直開完全存取權限。

尤其是陌生專案、剛 clone 下來的開源專案、公司核心專案，或者裡面有 .env、金鑰、token、設定檔的專案，都不要隨便開。

更穩的做法是：

• 平時用預設權限。
• 高效率的時候，用自動審查。
• 在你非常確定這個專案安全、任務明確，而且你知道 Codex 接下來要做什麼的時候，再臨時打開完全存取權限。

用完之後，最好再切回預設權限或自動審查。

所以這三種模式可以簡單總結一下：

預設權限，最安全，但是需要你頻繁確認。

自動審查，效率更高，適合日常開發裡的連續任務。

完全存取權限，能力最強，但風險也最高，只適合臨時使用。

Codex 最佳實踐

然後我們來看使用 Codex 進行 Vibe Coding 的最佳實踐。

這裡一共分成 4 步：

• 第一步，指定範圍。
• 第二步，指定狀態。
• 第三步，指定驗收標準。
• 第四步，隨時中斷。

我們一個個來看。

第一步 指定範圍

不要讓 Codex 在整個專案裡亂逛。

尤其是大專案。

你如果只想改登入頁，就把登入頁相關檔案告訴它。

你如果只想查一個 hook，就把 hook 檔案和呼叫位置告訴它。

在 App 或 IDE 裡，可以透過 @ 指定檔案。

在 CLI 裡，也可以直接把路徑寫清楚。

比如：

text 体验AI代码助手 代码解读复制代码請只閱讀 src/pages/login 和 src/hooks/useAuth 相關檔案。

幫我判斷登入跳轉邏輯是否存在時序問題。

這就比一句「幫我看看登入有啥問題」可靠很多。

第二步 指定狀態

也就是你要明確告訴它，現在是只讀，還是可以修改。

比如：

text 体验AI代码助手 代码解读复制代码先不要修改程式碼，只輸出分析。

或者：

text 体验AI代码助手 代码解读复制代码可以修改程式碼，但修改前先給我計劃。

再或者：

text 体验AI代码助手 代码解读复制代码請按計劃直接修改，完成後執行相關測試。

你看，這三句話對應的工作狀態完全不一樣。

很多人用 Codex 出問題，就是因為沒有說清楚邊界。

第三步 指定驗收標準

比如：

text 体验AI代码助手 代码解读复制代码完成後請確保：
1. npm run lint 可以通過
2. 相關測試可以通過
3. 不引入新依賴
4. 不修改無關檔案
5. 最後總結修改內容、驗證結果和剩餘風險

這就叫驗收標準。

你不給驗收標準，它就只能按自己的理解收工。

而 AI 的「我覺得完成了」，和工程裡的「真的完成了」，經常不是一回事。

第四步 隨時中斷

如果你發現 Codex 開始往奇怪方向走，不要硬等它做完。

直接中斷。

在 AI 執行的過程中，點擊暫停按鈕，然後告訴它：

text 体验AI代码助手 代码解读复制代码暫停剛才的方向。

你現在的理解有問題。
正確目標是 XXX。
請基於目前 diff 重新評估，不要繼續擴大修改範圍。

這就像帶實習生一樣。

方向不對的時候，要早點修正。

提示詞與 token 消耗的關係

然後我們來看提示詞與 token 消耗的關係。

很多同學會覺得，跟 Codex 說話是不是越短越好？

說的話越短，token 消耗就越低？

其實不一定。

短指令有時候反而更費 token。

因為你說得太短，Codex 就要自己搜尋、自己猜、自己補上下文。

你以為省事了。

實際上它繞了一大圈，token 消耗也就上來了。

舉個例子。

比如你說：

text 体验AI代码助手 代码解读复制代码優化一下這個頁面。

這樣說省事吧。

但是 Codex 就會很痛苦。

你要優化的是什麼？

是 UI，還是效能，還是程式碼可維護性？

它只能猜。

而它猜的這個過程，token 消耗可能非常大。

所以，更可靠的說法是指定具體的優化事項。

比如：

text 体验AI代码助手 代码解读复制代码請閱讀 src/pages/dashboard 相關檔案。

我現在覺得這個頁面有三個問題：
1. 首屏資訊太散
2. 行動端版面容易擠壓
3. 介面請求失敗時沒有明顯回饋

先不要修改程式碼。
請先輸出你的修改計劃，告訴我會改哪些檔案，以及為什麼這樣改。

這個指令就好很多。

要記住：在 Vibe Coding 的場景下，最怕的就是讓 AI 自由發揮。

Codex 的多模態能力

Codex 不只是能看文字。

你也可以給它截圖、設計稿、錯誤截圖、UI 問題截圖。

比如你看到頁面上某個按鈕被擠壓了，或者行動端版面錯位了。

你可以直接把截圖丟進去，複製貼上或者拖曳過去都可以。

然後說：

text 体验AI代码助手 代码解读复制代码這是目前頁面的截圖。

請結合截圖和程式碼，判斷版面問題可能在哪裡。
先不要修改程式碼，只輸出原因和修改方案。

這個效果會比純文字描述好很多。

畢竟一圖勝千言。

版本管理

再講版本管理和回滾。

Codex 改程式碼之前，先看 git 狀態。

Git 是一個程式碼版本管理工具，可以直接在官網下載。

在每次 Vibe Coding 修改程式碼之前，透過 Git 做好版本管理，這是我非常建議大家養成的習慣。

你可以 直接透過 Git 指令 或者 視覺化工具來做 。

也可以讓 Codex 先看：

text 体验AI代码助手 代码解读复制代码請先檢查目前 git 狀態。

告訴我有哪些未提交修改。
不要修改任何檔案。

如果工作區已經有你自己寫到一半的東西，一定要小心。

因為 Codex 可能會在這些檔案上繼續改。

不是說不能改。

而是你要知道它改了什麼。

每完成一個小任務，就讓它總結一次 diff。

比如：

text 体验AI代码助手 代码解读复制代码請總結這次修改：
1. 改了哪些檔案
2. 每個檔案改了什麼
3. 為什麼這樣改
4. 是否還有風險
5. 建議我如何驗證

然後你自己看一眼 diff。

不要直接閉眼提交。

上下文管理

接著講上下文管理。

這個也是 AI Agent 裡特別關鍵的東西。

Codex 每個對話都有上下文。

你前面說過什麼，它做過什麼，讀過什麼檔案，改過什麼東西，都會逐漸堆進去。

一開始這很爽。

因為它記得你剛才做了什麼。

但時間長了之後，上下文會越來越重。

回答會變慢，甚至開始混淆舊任務和新任務。

也就是大家平常說的：感覺 AI 變笨了。

這時候你就要有意識地管理上下文。

我的建議是，每個對話只做一類任務。

比如這個執行緒只修登入 bug。

那個執行緒只做元件重構。

不要在同一個執行緒裡，一會兒讓它寫頁面，一會兒讓它查 CI，一會兒又讓它總結會議。

這會把上下文搞得很髒。

什麼時候繼續舊對話？

當這個任務和前面的上下文強相關。

比如剛才修到一半，測試還沒過，那就繼續。

什麼時候開新對話？

當你要處理一個新問題，或者舊上下文已經太亂。

比如你剛做完登入，現在要做支付。

那就開新執行緒（開一個新的對話框）。

同時，讓它在任務結束的時候，做一次收尾總結。

比如：

text 体验AI代码助手 代码解读复制代码請總結這個任務。

包括：
1. 目標是什麼
2. 最終改了什麼
3. 已驗證什麼
4. 還有什麼風險
5. 後續繼續做應該從哪裡開始

這個總結以後特別有用。

因為你下次搜尋歷史，或者重新打開這個執行緒的時候，不需要從一堆碎片裡找線索。

你能直接看到這次任務的工程紀錄。

這就是 Codex App 裡搜尋功能的價值。

長期記憶

說到長期記憶，就要講 AGENTS.md。

如果你用過 Claude Code，可能會知道 CLAUDE.md。

在 Codex 裡，對應更常見的是 AGENTS.md。

你可以把它理解成寫給 AI Agent 的專案說明書。

Codex 會讀取這些檔案，把裡面的規則當成長期上下文。

它可以有幾層。

全域層面

可以放你的個人偏好。

比如你希望它回答中文，改程式碼前先給計劃，測試失敗要說明原因。

專案根目錄

可以放專案規範

比如技術棧、啟動命令、測試命令、程式碼風格、目錄約定。

子目錄裡

也可以放某個模組的特殊規則

比如這個目錄是舊程式碼，不要重構共用介面。

或者這個模組裡所有請求都必須走統一封裝。

這東西非常有用。

因為你不用每次都重複說一遍。

比如你可以在專案根目錄放一個 AGENTS.md，寫成這樣：

text 体验AI代码助手 代码解读复制代码# Project Instructions

- 預設使用中文回答。
- 修改程式碼前，先說明計劃。
- 不要主動引入新依賴，除非明確說明原因。
- 不要重構無關檔案。
- 前端元件需要考慮 loading、empty、error 狀態。
- 涉及使用者輸入時，需要考慮驗證和錯誤提示。
- 修改完成後，優先執行 npm run lint 和相關測試。
- 如果測試無法執行，需要說明原因和剩餘風險。

以後 Codex 進入這個專案，就會帶著這些規則工作。

這就是長期記憶。

把你的工作標準固化下來。

把團隊的程式碼規範、分支規範、測試規範、目錄約定都寫進去。

這會比每次在群組裡重複提醒可靠得多。

skills

然後是 skills。

這個東西有多紅，我就不用多說了。

現在幾乎所有大模型產品都開始提供 skills 的功能。

而且，我也覺得這是 Codex 裡非常值得研究的部分。

很多人會把 skill 和 plugin 混在一起。

其實不是一回事。

skill 更像一套做事方法。

它告訴 Codex，遇到某類任務時，應該按什麼流程做，檢查什麼風險，用什麼標準輸出。

比如你可以有一個前端 review skill。

裡面寫清楚，每次 review 前端程式碼，要重點看元件邊界、狀態管理、介面錯誤處理、行動端適配、效能問題、XSS 風險。

以後你讓 Codex review，它就不是泛泛地看一下。

而是按這套標準來。

你也可以有一個寫作 skill。

把你的文章結構、語氣、禁用詞、案例組織方式都寫進去。

以後你讓 Codex 寫稿子，它就不需要每次重新適應你的風格。

把這些東西寫成 skill，就變成了可以重複使用的工作流。

Codex 中預設就有一個 Skill Creator。

利用它可以直接建立你自己的 skills。

比如你可以讓 Codex 幫你建立一個 skill：

text 体验AI代码助手 代码解读复制代码請幫我建立一個前端程式碼審查 skill。

它需要在 review 時重點檢查：
1. 是否破壞現有元件約定
2. 是否引入不必要依賴
3. 是否有響應式狀態混亂
4. 是否遺漏 loading、empty、error 狀態
5. 是否有行動端適配問題
6. 是否有 XSS 風險
7. 是否補充必要測試

也可以直接讓它安裝別人的 skills。

比如你可以在 GitHub 上找到一個 skill，然後直接跟 Codex 說：

text 体验AI代码助手 代码解读复制代码請幫我安裝這個 skill，並檢查它的用途和安全風險。
連結是：XXX

它就可以幫你完成安裝。

plugins

再講 plugins。

plugin 和 skill 最大的差別是：

skill 更像方法，plugin 更像工具箱。

插件可以讓 Codex 連接更多外部工具和資訊來源。

比如 GitHub、瀏覽器、文件、郵件、日曆、電腦應用、各種 MCP 服務。

一旦這些接上，Codex 就不只是個寫程式的助手。

它開始進入真實工作流。

比如你可以讓它看 GitHub PR 的 review comment：

text 体验AI代码助手 代码解读复制代码請查看目前 PR 的 review comment。

總結必須修改的問題。
先不要改程式碼。

也可以讓它讀取某個文件，再檢查專案裡對應模組有沒有受影響：

text 体验AI代码助手 代码解读复制代码請讀取這份需求文件。

找出和目前專案相關的變更點。
然後只輸出可能受影響的檔案和模組。
不要修改程式碼。

這就很像一個能在不同工具之間來回跑的 AI 同事。

但我還是要強調一遍。

能力越大，邊界越重要。

插件不是裝得越多越好。

權限也不是給得越高越好。

尤其是涉及公司倉庫、郵件、聊天記錄、文件權限的時候，一定要注意資料邊界。

MCP

然後是 MCP。

這個詞最近也很紅。

MCP 你可以先簡單理解成一套讓 AI 連接外部工具和資料來源的協議。

比如資料庫、瀏覽器、知識庫、設計工具、內部系統。

以前 AI 想用這些東西，每個工具都要單獨適配。

現在透過 MCP，就更像有了一套統一的介面。

Codex 接上 MCP 之後，就能存取更多外部能力。

比如：

• 查詢資料庫結構
• 讀取內部文件
• 操作瀏覽器
• 檢索知識庫

當然，不同環境支援什麼 MCP，要看你自己的設定和權限。

我這裡不建議大家一上來就折騰一堆 MCP。

新手先把最基本的專案讀寫、權限、上下文、AGENTS.md、git 工作流搞明白。

這些才是根本。

MCP 是擴充。

根本沒打好，擴充越多越容易亂。

自動化

再講自動化。

這個功能我覺得很多人會低估。

自動化就是你給 Codex 一個任務，再給它一個時間規則，讓它自己週期性執行。

有點像排程工作。

但它不是普通排程。

因為執行任務的是一個 Agent。

比如你可以讓它每天早上總結昨天的提交：

text 体验AI代码助手 代码解读复制代码每天早上 9 點，檢查目前專案過去 24 小時的提交記錄。

輸出：
1. 主要改動
2. 涉及模組
3. 潛在風險
4. 今天需要我關注的地方

不要修改程式碼。

你也可以讓它每 30 分鐘檢查一次 PR 狀態：

text 体验AI代码助手 代码解读复制代码每 30 分鐘檢查一次目前 PR。

如果有新的 review comment，請總結評論內容，並判斷哪些需要修改。

不要自動改程式碼。
只在發現新問題時提醒我。

還可以讓它每天晚上總結今天的 diff：

text 体验AI代码助手 代码解读复制代码每天晚上 6 點，總結今天目前專案的 git diff。

告訴我：
1. 改了哪些檔案
2. 每個檔案大概改了什麼
3. 有沒有明顯風險
4. 明天繼續做應該從哪裡開始

這類任務特別適合 Codex。

因為它們重複、明確、有固定判斷標準。

自動化我也建議從只讀任務開始。

先讓它回報，不要讓它自動改。

等你確認它的判斷穩定，再慢慢擴大權限。

這裡可以分兩類理解。

一種是 跟目前對話綁定的自動化

比如你正在等部署結果。

你可以讓 Codex 10 分鐘後回到這個執行緒繼續檢查。

這種適合短週期、強上下文任務。

另一種是 獨立自動化

比如每天早上檢查專案提交。

每週五生成專案週報。

每天晚上總結錯誤日誌。

這種任務每次都是獨立巡檢，不一定依賴目前對話。

你可以這樣判斷：

• 如果任務需要接著目前對話繼續，就用目前執行緒自動化。
• 如果任務每次都是固定巡檢，就用獨立自動化。

這樣就比較好理解了。

一個完整案例

接下來，我們用一個具體案例串起來。

假設我要做一個番茄鐘應用。

先看看最後的實現效果

一套完整的工程實踐，總共可以分成 6 步。

很多人可能會說，這麼麻煩？

直接說一句：

text 体验AI代码助手 代码解读复制代码幫我寫一個番茄鐘應用。

不就行了嗎？

這樣能做出來嗎？

能。

但效果大概率一般。

更可靠的方式，是把 Codex 開發變成一套完整的工程實踐。

第一步，先拆需求

text 体验AI代码助手 代码解读复制代码我想做一個番茄鐘應用。

請先幫我拆需求，不要寫程式碼。

輸出：
1. 核心功能
2. 可選功能
3. 第一版最小可用範圍
4. 可能的邊界情況
5. 建議的實作順序

這一步，你可以用 GPT，也可以用 Codex。

如果你還沒想清楚，我更建議先用 GPT。

因為 GPT 更適合討論和拆解。

第二步，讓 Codex 讀專案

text 体验AI代码助手 代码解读复制代码請閱讀目前專案結構。

判斷番茄鐘功能應該放在哪些目錄下。

先不要修改程式碼。
只輸出檔案計劃，包括要新增哪些檔案、修改哪些檔案，以及原因。

這一步很關鍵。

因為同樣是番茄鐘，在不同專案裡寫法不一樣。

有的專案用 React。

有的用 Vue。

有的用 Next.js。

有的有自己的元件庫。

有的有自己的狀態管理。

Codex 必須先讀專案，才能按專案風格做。

第三步，讓它小步實作第一版

text 体验AI代码助手 代码解读复制代码按剛才的計劃實作第一版。

要求：
1. 完成 25 分鐘工作計時和 5 分鐘休息計時
2. 支援開始、暫停、重置
3. 支援工作和休息狀態展示
4. UI 簡潔，不要做複雜動畫
5. 不要引入新依賴

完成後執行專案檢查是否報錯。

注意，我這裡沒有讓它一次性做一堆東西。

沒有歷史統計。

沒有通知提醒。

沒有音效。

沒有複雜主題。

先做核心功能。

因為 Codex 做大任務，最怕一口吃太多。

第四步，讓它檢查自己

text 体验AI代码助手 代码解读复制代码請 review 這次改動。

重點檢查：
1. 計時器是否正確清理
2. 元件卸載後是否可能繼續 setState
3. 開始和暫停狀態是否混亂
4. 重置邏輯是否正確
5. 行動端版面是否會溢出
6. 有沒有不必要的複雜程式碼

先只輸出 review 結果，不要修改。

這一步非常有價值。

讓 Codex 寫程式碼是一回事。

讓 Codex 站在 reviewer 角度再看一遍，是另一回事。

第五步，再讓它修

text 体验AI代码助手 代码解读复制代码請根據剛才 review 裡確認的問題進行修復。

只修改和這些問題直接相關的程式碼。
不要做額外重構。
完成後再次總結 diff。

第六步，沉澱經驗

text 体验AI代码助手 代码解读复制代码請總結這次實作番茄鐘功能的過程。

包括：
1. 最終檔案結構
2. 核心實作思路
3. 遇到的問題
4. 後續如果要加歷史記錄和通知提醒，應該從哪裡開始
5. 哪些規則可以寫進 AGENTS.md

你看，這一整套下來，Codex 的工作品質會穩定很多。

我常用的 Codex 指令模板

這裡我再給大家一套我自己比較常用的 Codex 指令模板。

第一個，讀專案模板

text 体验AI代码助手 代码解读复制代码請先閱讀目前專案，不要修改任何程式碼。

幫我總結：
1. 專案是做什麼的
2. 技術棧是什麼
3. 目錄結構如何組織
4. 啟動、建置、測試命令是什麼
5. 新增一個頁面應該從哪裡開始
6. 目前專案有哪些明顯維護風險

第二個，修 bug 模板

text 体验AI代码助手 代码解读复制代码我遇到了一個 bug：XXX。

請先閱讀相關程式碼，不要修改。

輸出：
1. 可能原因
2. 涉及檔案
3. 你需要進一步確認的資訊
4. 修復計劃

第三個，執行修改模板

text 体验AI代码助手 代码解读复制代码請按剛才確認的計劃修改程式碼。

要求：
1. 修改範圍只限於 XXX
2. 不要引入新依賴
3. 不要重構無關程式碼
4. 完成後執行相關測試
5. 最後總結修改內容和風險

第四個，review 模板

text 体验AI代码助手 代码解读复制代码請 review 目前 git diff。

重點關注：
1. 是否破壞現有功能
2. 是否有邊界情況遺漏
3. 是否有錯誤處理缺失
4. 是否有型別問題
5. 是否有安全風險
6. 是否需要補測試

只輸出問題，不要修改程式碼。

第五個，任務收尾模板

text 体验AI代码助手 代码解读复制代码請總結這個任務。

包括：
1. 目標是什麼
2. 最終改了什麼
3. 已驗證什麼
4. 還有什麼風險
5. 後續繼續做應該從哪裡開始

這幾個模板你不用背。

你只要記住背後的邏輯：

• 先讀。
• 再計劃。
• 再執行。
• 再驗證。
• 再總結。

這就是最樸素，也最穩定的 Codex 工作流。

彩蛋

打開之後長這樣：

裡面包含了非常多的 Codex 設定。

比如個人化、MCP、瀏覽器使用等等。

這些設定後面可以慢慢研究。

不過這裡有個非常好玩的彩蛋功能，就是之前 Claude Code 也有的 寵物。

只不過之前 Claude Code 的寵物有點虎頭蛇尾。

而 Codex 這個雖然沒怎麼宣傳，但我覺得做得還挺完整。

選擇「外觀」，拉到最後，有一個 寵物 模組。

裡面包含了一大堆寵物，同時也可以自訂寵物。

只要點擊「喚醒寵物」，你的寵物就會出現在電腦桌面上。

有一種以前用電腦管家小籃球的既視感。

如果你覺得 Codex 預設提供的寵物太醜了，現在也有很多 Codex 寵物市場。

比如 https://codex-pets.net/

是不是感覺比官方的好看多了。。。

安裝也非常簡單。

比如安裝我最喜歡的 雞哥。

直接透過右側的指令即可完成安裝 npx codex-pets add ikun

當然了，這塊就是一個彩蛋。

好玩歸好玩。

真正決定 Codex 好不好用的，還是前面那些東西。

新對話、搜尋、插件、skills、自動化。

這些才是 Codex APP 真正的工作流核心。

總結

今天的內容挺長了，我看了一下有一萬六千字。當然影片也挺長的，剪完之後也有 40 分鐘。

最後總結一下：

AI 不是神。它是一個非常強的工具。

但越是這種工具，越需要你會用。

新手最容易犯的錯誤，就是丟一個模糊任務，然後期待它一次性做完。

這非常不可靠。

真正可靠的方式是：

• 先只讀。
• 再計劃。
• 再小步修改。
• 再測試驗證。
• 再總結沉澱。
• 把常用規則寫進 AGENTS.md。
• 把重複標準做成 skills。
• 把外部工具透過 plugins 和 MCP 接進來。
• 把重複巡檢交給自動化模組。
• 複雜任務再拆給多個 agent 並行做。

然後你自己負責方向、判斷和驗收。

我覺得這才是 Codex 最有價值的地方。

原文出處：https://juejin.cn/post/7638806086187565082