Codex入門最佳實踐「OpenAI官方」
整理版優先睇
把Codex當成隊友，持續配置同改進
呢篇文章係OpenAI官方嘅Codex使用最佳實踐指南，專為新手而設。作者想解決嘅問題係，點樣先可以唔係得一次過用Codex，而係將佢變成一個長期可靠嘅AI程式設計夥伴。整體結論係，用Codex唔係靠一條神奇嘅prompt，而係要靠一套工程化習慣：畀足上下文、將規範寫入檔案、重複嘅嘢變成工具、穩定嘅工具交畀自動化。
文章強調，Codex嘅能力已經好強，但喺大型或複雜嘅代碼庫入面，要解鎖更好效果，關鍵係畀佢足夠嘅任務上下文。一個好嘅提示詞應該包含目標、上下文、約束條件同完成標誌。複雜任務要先規劃再動手，可以用Plan模式、等Codex反問你，或者用PLANS.md模板。而家好多開發者淨係識得不斷改prompt，但忽略咗持久化規則，呢個係常見錯誤。
將好使好用嘅提示詞沉澱落AGENTS.md，等於係畀Codex一個面向AI嘅README。配置係保持行為一致性嘅關鍵，仲可以透過MCP連接外部系統，將可重用嘅工作流打包成Skill，穩定嘅工作流交畀自動化。最後，要管理好長期運行嘅會話，每個連貫工作單元保持一個線程。呢啲做法加埋，先至係用得好Codex嘅真正心法。
- 用Codex嘅核心係將佢當成隊友，而家係一次過助手，而係持續配置同改進嘅夥伴。
- 畀足任務上下文係提升效果嘅關鍵，提示詞要包含目標、上下文、約束條件同完成標誌。
- 將重複用到嘅prompt沉澱落AGENTS.md，而家係每次都重新輸入，仲要按層級配置。
- 穩定嘅工作流要先變成Skill，然後先自動化，唔好喺未穩定之前就自動化。
- 每個連貫工作單元保持一個線程，需要分叉先用fork，避免上下文膨脹影響效果。
OpenAI Codex 最佳實踐官方指南
原文出處，包含完整嘅使用建議同案例。
畀足上下文，規劃先行
Codex本身已經夠強，但係喺大型代碼庫入面，要令佢發揮得更好，就要畀足任務上下文。一個好嘅提示詞應該包含四個要素：目標、上下文、約束條件同完成標誌。
目標係你想改變或構建乜嘢
上下文可以用@直接提及具體檔案
約束條件係要遵循嘅標準或架構要求
完成標誌好似測試通過或Bug唔再出現
推理強度要根據任務難度揀，簡單用低強度，複雜用中高強度。喺Codex應用仲可以用語音輸入，快過打字好多。
複雜任務要先規劃再動手
有三種規劃方式：Plan模式最簡單有效，讓Codex先收集上下文、提出澄清問題，再製定計劃。可以用 /plan 或者 Shift+Tab 切換。第二係讓Codex反問你，將模糊諗法變成具體需求。第三係用PLANS.md模板，適合多步驟工作流。
將規則沉澱落檔案，保持一致性
一個好嘅prompt模式跑通之後，就唔好再反複手動輸入。AGENTS.md係一個畀AI睇嘅README，會自動加載到上下文，幫Codex瞭解點樣喺你個代碼庫入面工作。
AGENTS.md應該包含倉庫結構、啟動方式、構建命令同工程規範
多層級配置：個人全局、團隊共享、局部規則
用CLI嘅 /init 命令可以快速生成初始版本。保持簡潔好重要，發現Codex重複犯錯時，就更新AGENTS.md。如果檔案愈嚟愈大，可以拆開做獨立markdown再引用。
配置係保持行為一致性嘅主要手段
可以配置默認模型、推理強度、沙箱模式、審批策略等。個人默認配置放 ~/.codex/config.toml，倉庫專屬放 .codex/config.toml。審批模式同沙箱模式係權限控制嘅關鍵，開始時建議較嚴格，熟咗之後先放鬆。
測試審查，連接外部系統
唔好淨係畀Codex做改動，仲要佢寫測試、運行檢查、確認結果。Codex可以完成完整循環，前提係佢知道乜嘢叫好嘅結果。
為改動編寫或更新測試
運行測試套件、檢查Lint、格式化
審查diff有冇Bug或迴歸
喺Codex應用可以切換diff面板直接睇本地改動， /review 命令提供多種審查方式。如果團隊有 code_review.md 並喺AGENTS.md引用，Codex就會跟住規範做。用GitHub Cloud仲可以設定自動審查PR，OpenAI內部100% PR都經過Codex審查。
當Codex需要嘅上下文喺代碼庫之外，就用MCP連接外部系統。MCP係開放標準，可以訪問數據頻繁變化嘅工具，唔使複製貼上。喺Codex應用嘅設置→MCP伺服器可以管理，接入工具要有節制，由一兩個開始逐步擴展。
將重複工作流變成Skill同自動化
當一個工作流變得可重複，就唔好再依賴長提示詞，應該將佢打包成Skill，寫入SKILL.md。每個Skill只做一件事，由2-3個具體用例開始，定義清晰輸入輸出同觸發短語。
Skill 喺CLI、IDE插件同Codex應用都用得
/skill-creator 係搭建第一個Skill嘅最佳起點
個人Skill放 $HOME/.agents/skills，團隊共享可以放倉庫嘅 .agents/skills 目錄。技能描述最重要，要講清楚做乜同幾時用。
一旦工作流穩定落嚟，就可以交畀自動化。喺Codex應用嘅自動化標籤頁設定項目、提示詞、執行頻率同環境。適合自動化嘅任務包括匯總提交、掃描Bug、起草發佈說明等。一個區分方式：技能定義方法，自動化定義時間表。未穩定嘅先唔好自動化。
自動化唔只係執行，仲可以用嚟回顧同維護
管理會話，避開常見錯誤
Codex嘅會話積累咗上下文、決策同操作，管理好佢對質量影響好大。可以固定線程同創建工作樹，CLI有好多實用斜槓命令： /resume 恢復對話、 /fork 創建新線程、 /compact 壓縮早期上下文。
每個連貫工作單元保持一個線程
只有當工作真正分叉時先fork
可以用子Agent工作流將有邊界嘅任務分出去，等主Agent專注核心問題。
最後提幾個常見錯誤：將持久性規則堆入提示詞而唔係AGENTS.md；冇話畀Agent點樣運行構建命令；跳過複雜任務嘅規劃；未搞清楚工作流就開放權限；同一批檔案並行多個會話但冇用git工作樹；任務唔穩定就自動化；好似監工咁睇住Codex一步步做；一個線程對應一個項目而唔係一個任務。
最近好多朋友由cc轉去codex，好多人問我究竟點用codex，其實我覺得唔使睇任何資料視頻，OpenAI官方就有最好嘅使用指南同case
傳送門：
https://developers.openai.com/codex
由今日開始，我會揀啲日常普通人最可能需要嘅codex功能分享俾大家
今日呢篇都係來自OpenAI官方嘅Codex使用最佳實踐指南，適合新手由整體上入門codex，當然唔係叫你照住一條一條去做，做到心中有數都係好嘅。
核心觀點得一句：將Codex當成需要持續配置同改進嘅隊友，而唔係一次性嘅助手。
未安裝codex（Mac上面嘅體驗係最好嘅，好多功能都係由Mac第一時間支援），睇呢度：
https://chatgpt.com/zh-Hans-CN/codex/
具體點做？拆開來講。
第一件事：俾任務提供完整上下文
Codex本身已經夠強，就算提示詞唔完美，都可以俾到唔錯嘅結果。但如果你喺大型或複雜代碼庫裏面工作，俾佢足夠嘅任務上下文，係解鎖更好效果嘅關鍵。
一個好嘅提示詞應該包含四個要素：
目標，即係你想改變或構建啲乜；上下文，邊啲文件、文檔、例子或報錯信息同當前任務相關，可以用@直接提及具體文件；約束條件，Codex需要跟從邊啲標準、架構要求或規範；完成標誌，任務結束嘅判斷根據係乜，例如測試通過、行為改變、Bug唔再出現。
推理強度都要根據任務難度來揀。簡單任務用低強度，複雜任務或調試用中高強度，長時間嘅推理密集型任務用最高強度。
另外，喺Codex應用裏面，可以直接用語音輸入來描述你想做啲乜，比打字快好多。
第二件事：複雜任務先規劃再動手
如果任務複雜、模糊或者好難描述清楚，叫Codex喺開始寫代碼前先做規劃。
有三種方式可以用：
方式一係Plan模式，呢個係最簡單亦最有效嘅選項。Plan模式叫Codex先收集上下文、提出澄清問題，再製定更完善嘅計劃。透過 /plan 或 Shift+Tab 切換。
方式二係叫Codex來問你。如果你有個模糊嘅想法但唔知點描述，叫Codex先採訪你，挑戰你嘅假設，將模糊嘅想法變成具體嘅需求，然後再寫代碼。
方式三係使用PLANS.md模板，適合更複雜嘅多步驟工作流。
第三件事：將好用嘅提示詞沉澱到AGENTS.md
一個提示詞模式一旦行得通，就唔好反覆手動重複佢。呢個就係AGENTS.md嘅用處。
將AGENTS.md理解為一個面向AI Agent嘅README文件。佢會自動加載到上下文裏面，係話俾Codex知點樣喺你嘅代碼庫裏面工作嘅最佳載體。
一份好嘅AGENTS.md應該涵蓋：倉庫結構同重要目錄、項目啟動方式、構建、測試同Lint命令、工程規範同PR要求、約束條件同禁止事項、任務完成嘅標準同驗證方式。
CLI裏面嘅 /init 命令可以快速生成一個初始嘅AGENTS.md，作為起點，但需要根據團隊嘅實際工作方式進行編輯。
AGENTS.md支持多層級：擺喺 ~/.codex 裏面嘅係個人全局默認配置，擺喺倉庫根目錄嘅係團隊共享標準，擺喺子目錄裏面嘅係局部規則，越具體嘅文件優先級越高。
保持簡潔好重要。一個簡短準確嘅AGENTS.md，比一個充滿模糊規則嘅長文件更有用。由基礎內容開始，發現Codex反覆犯同一個錯誤時，叫佢做覆盤，然後更新AGENTS.md。
如果AGENTS.md越來越大，可以保持主文件簡潔，將規劃、代碼審查、架構等具體內容分別放到獨立嘅markdown文件裏面，喺主文件裏面引用就得。
第四件事：透過配置保持行為一致性
配置係令Codex跨會話、跨場景表現穩定嘅主要手段。可以配置嘅項目包括默認模型、推理強度、沙箱模式、審批策略、配置文件同MCP設置。
推薦嘅配置方式：
個人默認配置擺喺 ~/.codex/config.toml（喺Codex應用裏面透過設置→配置→打開config.toml訪問），倉庫專屬配置擺喺 .codex/config.toml，命令行覆蓋只用於臨時情況。
Codex有兩個關鍵嘅權限控制項：審批模式決定Codex喺執行命令前是否需要你嘅確認，沙箱模式決定Codex能夠讀寫邊啲目錄同文件。
啱啱開始使用編程Agent時，建議由默認權限開始，保持審批同沙箱設置較為嚴格，等你熟悉工作流之後，再對可信任嘅倉庫或特定場景適當放開權限。
CLI、IDE插件同Codex應用共享同一套配置層。好多質量問題其實係配置問題，例如工作目錄唔啱、缺少寫權限、模型默認值唔合適、缺少必要工具或連接器。
第五件事：叫Codex測試同審查自己嘅代碼
唔好只係叫Codex做出改動，仲要叫佢喺需要時編寫測試、運行相關檢查、確認結果，並喺你接受之前審查工作。
Codex可以完成呢個完整嘅循環，前提係佢知道咩叫好嘅結果。呢個標準可以來自提示詞或AGENTS.md。
具體包括：為改動編寫或更新測試、運行相應嘅測試套件、檢查Lint、格式化或類型檢查、確認最終行為符合需求、審查diff是否存在Bug、回歸或風險模式。
喺Codex應用裏面，可以切換diff面板直接睇本地改動，點擊具體嘅行可以提供反饋，呢啲反饋會作為上下文傳入下一輪對話。
斜槓命令 /review 提供咗幾種代碼審查方式：對比基礎分支嘅PR式審查、審查未提交嘅改動、審查某個commit、使用自定義審查指令。
如果團隊有 code_review.md 文件並喺AGENTS.md裏面引用佢，Codex喺審查時都會跟從嗰啲規範。呢個係令審查行為喺多個倉庫同貢獻者之間保持一致嘅有效模式。
如果你使用GitHub Cloud，仲可以設置Codex自動審查PR。OpenAI內部100%嘅PR都經過Codex審查，可以選擇自動觸發或者@Codex手動觸發。
第六件事：用MCP連接外部系統
當Codex需要嘅上下文喺代碼庫之外時，用MCP來連接。咁樣Codex就可以直接訪問你已經在用嘅工具同系統，唔需要將實時信息反覆複製粘貼到提示詞裏面。
MCP，即模型上下文協議，係一個將Codex與外部工具同系統連接嘅開放標準。
適合用MCP嘅場景：所需上下文喺代碼庫之外、數據頻繁變化、想叫Codex直接調用工具而唔係依賴粘貼嘅說明、需要跨用戶或項目可重複集成。
Codex同時支持STDIO同帶OAuth嘅Streamable HTTP服務器。
喺Codex應用裏面，入設置→MCP服務器可以查看自定義同推薦嘅服務器，Codex通常可以幫你安裝所需嘅服務器，直接問佢就得。喺CLI裏面都可以用 codex mcp add 命令添加自定義服務器。
接入工具要有節制，只係喺真正打通某個工作流嘅時候先加。由一兩個能夠明確減少手動操作嘅工具開始，再逐步擴展。
第七件事：將可複用嘅工作流打包成技能
當一個工作流變得可重複時，就唔好再依賴長提示詞或反覆來回。將佢做成Skill，打包進SKILL.md文件裏面，Codex會持續應用呢套指令、上下文同支撐邏輯。技能喺CLI、IDE插件同Codex應用裏面都用得。
每個技能只做一件事。由2到3個具體用例開始，定義清晰嘅輸入同輸出，描述要寫清楚呢個技能做啲乜同幾時用佢，要包含用戶實際會講嘅觸發短語。
唔需要一開始就覆蓋所有邊緣情況。先叫一個典型任務行得通，再將佢做成技能並持續優化。只係喺能夠提升可靠性嘅時候先加入腳本或額外資產。
如果你發現自己一直喺度複用同一個提示詞或反覆糾正同一個工作流，咁佢就應該變成一個技能。
技能特別適合呢啲場景：日誌分析、發佈說明起草、對照清單嘅PR審查、遷移規劃、遙測或事故摘要、標準調試流程。
/skill-creator 技能係搭建第一個技能初版嘅最佳起點。先喺本地迭代，準備好咗再打包成插件分享。技能描述係最重要嘅部分，佢要講清楚呢個技能做啲乜同幾時用佢。
個人技能存放喺 $HOME/.agents/skills，團隊共享技能可以提交到倉庫裏面嘅 .agents/skills 目錄，對新成員上手好有幫助。
第八件事：穩定嘅工作流交俾自動化
一旦某個工作流穩定咗，就可以叫Codex喺後台定時執行佢。喺Codex應用嘅自動化標籤頁裏面，可以選擇項目、提示詞、執行頻率同運行環境。
可以調用技能作為提示詞，仲可以選擇喺獨立嘅git工作樹定係本地環境裏面運行。
適合自動化嘅任務包括：彙總近期提交、掃描潛在Bug、起草發佈說明、檢查CI失敗、生成每日站會摘要、定時運行可重複嘅分析工作流。
有一個區分方式：技能定義方法，自動化定義時間表。如果一個工作流仲需要大量人工引導，先將佢做成技能，等佢變得可預測，自動化先至真正發揮放大效果。
自動化唔只係執行，都可以用來做回顧同維護，例如定期審視最近嘅會話、總結反覆出現嘅問題，然後持續優化提示詞、指令或工作流設置。
第九件事：管理好長期運行嘅會話
Codex嘅會話唔只係聊天記錄，而係積累咗上下文、決策同操作嘅工作線程，管理好佢哋對質量影響好大。
Codex應用裏面可以固定線程同創建工作樹。如果用CLI，以下斜槓命令好實用：
/experimental 切換實驗性功能並寫入config.toml；/resume 恢復保存嘅對話；/fork 創建新線程同時保留原始記錄；/compact 喺線程過長時生成早期上下文嘅摘要版本（Codex都會自動壓縮對話）；/agent 喺並行運行多個Agent時切換活躍嘅Agent線程；/theme 選擇語法高亮主題；/apps 喺Codex裏面直接使用ChatGPT應用；/status 查看當前會話狀態。
一個建議：每個連貫嘅工作單元保持一個線程。如果工作仲係同一個問題嘅延續，留喺同一個線程裏面通常更好，因為佢保留咗推理軌跡。只有當工作真正分叉先至fork。
可以用子Agent工作流將有邊界嘅任務從主線程裏面分出去，叫主Agent專注於核心問題，用子Agent處理探索、測試或分類呢類任務。
最後：幾個常見錯誤
啱啱開始用Codex時，有幾個坑值得注意：
將持久性規則堆進提示詞裏面，而唔係放進AGENTS.md或技能；冇話俾Agent知點樣運行構建同測試命令，搞到佢睇唔到自己嘅工作結果；跳過多步驟複雜任務嘅規劃階段；未搞清楚工作流就俾Codex開放咗完整權限；喺同一批文件上並行運行多個會話卻冇用git工作樹；喺任務仲未穩定嘅時候就將佢變成自動化；好似監工咁盯着Codex一步步執行，而唔係叫佢並行工作；用一個線程對應一個項目而唔係一個線程對應一個任務，導致上下文膨脹、效果變差。
將Codex用好，本質上係一套工程化嘅習慣養成過程：上下文俾夠，規範寫進文件，重複嘅事情變成工具，穩定嘅工具交俾自動化。
最近很多朋友從cc轉向codex，有很多人問我究竟怎麼用codex，其實我覺得不用看任何資料視頻，OpenAI官方就有最好的使用指南和case
傳送門：
https://developers.openai.com/codex
從今天開始，我會挑選一些日常中普通人可能最需要的codex功能分享給大家
今天這篇來也是自在OpenAI官方的Codex使用最佳實踐指南，適合小白從整體上入門codex，當然了不是說你要照着一條一條去做，做到心理有數也是好的。
核心觀點只有一句話：把Codex當成需要持續配置和改進的隊友，而不是一次性的助手。
還沒安裝codex（Mac上的體驗是最好的，很多功能也是從Mac第一時間支持的），看這裏：
https://chatgpt.com/zh-Hans-CN/codex/
具體怎麼做？拆開來說。
第一件事：給任務提供完整上下文
Codex本身已經足夠強，即使提示詞不完美，也能給出不錯的結果。但如果你在大型或複雜代碼庫裏工作，給它足夠的任務上下文，是解鎖更好效果的關鍵。
一個好的提示詞應該包含四個要素：
目標，也就是你想改變或構建什麼；上下文，哪些文件、文檔、示例或報錯信息與當前任務相關，可以用@直接提及具體文件；約束條件，Codex需要遵循哪些標準、架構要求或規範；完成標誌，任務結束的判斷依據是什麼，比如測試通過、行為改變、Bug不再復現。
推理強度也要根據任務難度來選。簡單任務用低強度，複雜任務或調試用中高強度，長時間的推理密集型任務用最高強度。
另外，在Codex應用裏，可以直接用語音輸入來描述你想做什麼，比打字快得多。
第二件事：複雜任務先規劃再動手
如果任務複雜、模糊或者難以描述清楚，讓Codex在開始寫代碼前先做規劃。
有三種方式可以用：
方式一是Plan模式，這是最簡單也最有效的選項。Plan模式讓Codex先收集上下文、提出澄清問題，再製定更完善的計劃。通過 /plan 或 Shift+Tab 切換。
方式二是讓Codex來問你。如果你有個模糊的想法但不知道怎麼描述，讓Codex先採訪你，挑戰你的假設，把模糊的想法變成具體的需求，然後再寫代碼。
方式三是使用PLANS.md模板，適合更復雜的多步驟工作流。
第三件事：把好用的提示詞沉澱到AGENTS.md
一個提示詞模式一旦跑通，就不要反覆手動重複它。這正是AGENTS.md的用處。
把AGENTS.md理解為一個面向AI Agent的README文件。它會自動加載到上下文裏，是告訴Codex如何在你的代碼庫裏工作的最佳載體。
一份好的AGENTS.md應該涵蓋：倉庫結構和重要目錄、項目啓動方式、構建、測試和Lint命令、工程規範和PR要求、約束條件和禁止事項、任務完成的標準和驗證方式。
CLI裏的 /init 命令可以快速生成一個初始的AGENTS.md，作為起點，但需要根據團隊的實際工作方式進行編輯。
AGENTS.md支持多層級：放在 ~/.codex 裏的是個人全局默認配置，放在倉庫根目錄的是團隊共享標準，放在子目錄裏的是局部規則，越具體的文件優先級越高。
保持簡潔很重要。一個簡短準確的AGENTS.md，比一個充滿模糊規則的長文件更有用。從基礎內容開始，發現Codex反覆犯同一個錯誤時，讓它做覆盤，然後更新AGENTS.md。
如果AGENTS.md越來越大，可以保持主文件簡潔，把規劃、代碼審查、架構等具體內容分別放到獨立的markdown文件裏，在主文件裏引用即可。
第四件事：通過配置保持行為一致性
配置是讓Codex跨會話、跨場景表現穩定的主要手段。可以配置的項目包括默認模型、推理強度、沙箱模式、審批策略、配置文件和MCP設置。
推薦的配置方式：
個人默認配置放在 ~/.codex/config.toml（在Codex應用裏通過設置→配置→打開config.toml訪問），倉庫專屬配置放在 .codex/config.toml，命令行覆蓋只用於臨時情況。
Codex有兩個關鍵的權限控制項：審批模式決定Codex在執行命令前是否需要你的確認，沙箱模式決定Codex能讀寫哪些目錄和文件。
剛開始使用編程Agent時，建議從默認權限開始，保持審批和沙箱設置較為嚴格，等你熟悉工作流之後，再對可信任的倉庫或特定場景適當放開權限。
CLI、IDE插件和Codex應用共享同一套配置層。很多質量問題其實是配置問題，比如工作目錄不對、缺少寫權限、模型默認值不合適、缺少必要工具或連接器。
第五件事：讓Codex測試並審查自己的代碼
不要只讓Codex做出改動，還要讓它在需要時編寫測試、運行相關檢查、確認結果，並在你接受之前審查工作。
Codex可以完成這個完整的循環，前提是它知道什麼叫好的結果。這個標準可以來自提示詞或AGENTS.md。
具體包括：為改動編寫或更新測試、運行相應的測試套件、檢查Lint、格式化或類型檢查、確認最終行為符合需求、審查diff是否存在Bug、迴歸或風險模式。
在Codex應用裏，可以切換diff面板直接查看本地改動，點擊具體的行可以提供反饋，這些反饋會作為上下文傳入下一輪對話。
斜槓命令 /review 提供了幾種代碼審查方式：對比基礎分支的PR式審查、審查未提交的改動、審查某個commit、使用自定義審查指令。
如果團隊有 code_review.md 文件並在AGENTS.md裏引用它，Codex在審查時也會遵循那些規範。這是讓審查行為在多個倉庫和貢獻者之間保持一致的有效模式。
如果你使用GitHub Cloud，還可以設置Codex自動審查PR。OpenAI內部100%的PR都經過Codex審查，可以選擇自動觸發或者@Codex手動觸發。
第六件事：用MCP連接外部系統
當Codex需要的上下文在代碼庫之外時，用MCP來連接。這樣Codex就能直接訪問你已經在用的工具和系統，不需要把實時信息反覆複製粘貼到提示詞裏。
MCP，即模型上下文協議，是一個將Codex與外部工具和系統連接的開放標準。
適合用MCP的場景：所需上下文在代碼庫之外、數據頻繁變化、想讓Codex直接調用工具而不是依賴粘貼的說明、需要跨用戶或項目可重複集成。
Codex同時支持STDIO和帶OAuth的Streamable HTTP服務器。
在Codex應用裏，進入設置→MCP服務器可以查看自定義和推薦的服務器，Codex通常可以幫你安裝所需的服務器，直接問它就行。在CLI裏也可以用 codex mcp add 命令添加自定義服務器。
接入工具要有節制，只在能真正打通某個工作流的時候才加。從一兩個能明確減少手動操作的工具開始，再逐步擴展。
第七件事：把可複用的工作流打包成技能
當一個工作流變得可重複時，就不要再依賴長提示詞或反覆來回了。把它做成Skill，打包進SKILL.md文件裏，Codex會持續應用這套指令、上下文和支撐邏輯。技能在CLI、IDE插件和Codex應用裏都能用。
每個技能只做一件事。從2到3個具體用例開始，定義清晰的輸入和輸出，描述要寫清楚這個技能做什麼以及什麼時候用它，要包含用戶實際會說的觸發短語。
不需要一開始就覆蓋所有邊緣情況。先讓一個典型任務跑通，再把它做成技能並持續優化。只在能提升可靠性的時候才加入腳本或額外資產。
如果你發現自己一直在複用同一個提示詞或反覆糾正同一個工作流，那它就應該變成一個技能。
技能特別適合這些場景：日誌分析、發佈說明起草、對照清單的PR審查、遷移規劃、遙測或事故摘要、標準調試流程。
/skill-creator 技能是搭建第一個技能初版的最佳起點。先在本地迭代，準備好了再打包成插件分享。技能描述是最重要的部分，它要說清楚這個技能做什麼以及什麼時候用它。
個人技能存放在 $HOME/.agents/skills，團隊共享技能可以提交到倉庫裏的 .agents/skills 目錄，對新成員上手很有幫助。
第八件事：穩定的工作流交給自動化
一旦某個工作流穩定了，就可以讓Codex在後台定時執行它。在Codex應用的自動化標籤頁裏，可以選擇項目、提示詞、執行頻率和運行環境。
可以調用技能作為提示詞，還可以選擇在獨立的git工作樹還是本地環境裏運行。
適合自動化的任務包括：彙總近期提交、掃描潛在Bug、起草發佈說明、檢查CI失敗、生成每日站會摘要、定時運行可重複的分析工作流。
有一個區分方式：技能定義方法，自動化定義時間表。如果一個工作流還需要大量人工引導，先把它做成技能，等它變得可預測了，自動化才能真正發揮放大效果。
自動化不只是執行，也可以用來做回顧和維護，比如定期審視最近的會話、總結反覆出現的問題，然後持續優化提示詞、指令或工作流設置。
第九件事：管理好長期運行的會話
Codex的會話不只是聊天記錄，而是積累了上下文、決策和操作的工作線程，管理好它們對質量影響很大。
Codex應用裏可以固定線程和創建工作樹。如果用CLI，以下斜槓命令很實用：
/experimental 切換實驗性功能並寫入config.toml；/resume 恢復保存的對話；/fork 創建新線程同時保留原始記錄；/compact 在線程過長時生成早期上下文的摘要版本（Codex也會自動壓縮對話）；/agent 在並行運行多個Agent時切換活躍的Agent線程；/theme 選擇語法高亮主題；/apps 在Codex裏直接使用ChatGPT應用；/status 查看當前會話狀態。
一個建議：每個連貫的工作單元保持一個線程。如果工作還是同一個問題的延續，待在同一個線程裏通常更好，因為它保留了推理軌跡。只有當工作真正分叉時才fork。
可以用子Agent工作流把有邊界的任務從主線程裏分出去，讓主Agent專注於核心問題，用子Agent處理探索、測試或分類這類任務。
最後：幾個常見錯誤
剛開始用Codex時，有幾個坑值得注意：
把持久性規則堆進提示詞裏，而不是放進AGENTS.md或技能；沒有告訴Agent如何運行構建和測試命令，導致它看不到自己的工作結果；跳過多步驟複雜任務的規劃階段；還沒搞清楚工作流就給Codex開放了完整權限；在同一批文件上並行運行多個會話卻沒用git工作樹；在任務還不穩定的時候就把它變成自動化；像監工一樣盯着Codex一步步執行，而不是讓它並行工作；用一個線程對應一個項目而不是一個線程對應一個任務，導致上下文膨脹、效果變差。
把Codex用好，本質上是一套工程化的習慣養成過程：上下文給夠，規範寫進文件，重複的事情變成工具，穩定的工具交給自動化。