Codex 入門最佳實踐「OpenAI官方」
整理版優先睇
OpenAI官方Codex入門最佳實踐：視Codex為需要持續配置嘅隊友
呢篇文章係OpenAI官方Codex最佳實踐指南嘅中文整理版，由YAR師（你說的完全正確）揀選翻譯，目標係幫新手從整體上入門Codex。作者強調核心觀點係：將Codex當成需要持續配置同改進嘅隊友，而唔係一次性嘅助手。文章從九個面向拆解使用技巧，包括提供完整上下文、複雜任務先規劃、沉澱提示詞到AGENTS.md、保持行為一致性、讓Codex測試審查自己、用MCP連接外部系統、將可重用工作流打包成技能、穩定工作流自動化、同埋管理長期運行嘅會話。最後總結常見錯誤，提醒用戶避免堆疊規則入提示詞、唔提供構建測試命令、跳過規劃等。整體係一篇實戰性強嘅工程化養成指南。
YAR師以佢嘅整理角度，將官方文檔轉化成更易入口嘅中文內容，特別適合想快速上手Codex但唔想睇原文檔嘅讀者。文章唔單止講點用，更強調建立良好習慣：上下文俾夠、規範寫入文件、重複變成工具、穩定交給自動化。讀者可以根據實際需要揀選適用部分，唔需要跟足全部。
- 核心結論：Codex係需要持續配置同改進嘅隊友，唔係一次性助手。
- 方法：每個任務要提供完整上下文，包括目標、上下文、約束條件同完成標誌。
- 差異：提示詞應該沉澱到AGENTS.md，類似面向AI嘅README，比手動重複更有效。
- 啟發：複雜任務先用Plan模式或PLANS.md規劃，避免一嚟就寫Code。
- 可行動點：用MCP連接外部系統，將重複工作流打包成Skill，穩定後設定自動化。
OpenAI Codex官方文檔
官方Codex使用指南同案例，適合小白入門。
Codex安裝頁面
安裝Codex（Mac體驗最佳），可從呢度下載。
核心觀念：Codex係隊友，唔係助手
文章開門見山點出核心：把Codex當成需要持續配置同改進嘅隊友，而唔係一次性助手。呢個心態轉變好重要，決定咗點樣用提示詞同管理工作流。
- 目標：清楚講出你想改變或構建嘅嘢。
- 上下文：用@提及相關文件、文檔、示例或報錯。
- 約束條件：指明標準、架構要求或規範。
- 完成標誌：定義任務結束嘅判斷依據，例如測試通過或Bug唔再出現。
推理強度要根據任務難度揀，簡單用低強度，複雜或調試用中高強度。
Codex應用仲支援語音輸入，描述想做嘅嘢比打字快好多。呢個係實用嘅效率技巧。
先規劃再動手：唔好跳過計劃階段
如果任務複雜、模糊或難描述，先讓Codex做規劃先。文章提出三種方式：Plan模式、讓Codex問你、用PLANS.md模板。
Plan模式係最簡單有效嘅選項，透過 /plan 或 Shift+Tab 切換。
讓Codex問你：If你有模糊想法，讓Codex挑戰你嘅假設，將模糊變成具體需求。
呢個步驟好多人會跳過，但係文章強調：唔好嫌麻煩，規劃階段可以慳返好多後續改動時間。
沉澱提示詞：AGENTS.md係最佳載體
一個提示詞模式一跑通，唔好再手動重複。AGENTS.md就係用嚟沉澱呢啲模式，佢會自動加載到上下文，係面向AI Agent嘅README。
AGENTS.md應該涵蓋：倉庫結構、啟動方式、構建/測試/Lint命令、工程規範、約束條件、完成標準。
CLI用 /init 可以快速生成初始AGENTS.md，但要按實際需要編輯。
- 多層級支援：~/.codex 係個人默認，倉庫根目錄係團隊共用，子目錄係局部規則，越具體優先級越高。
- 保持簡潔：簡短準確比長篇模糊更有用。
- 逐步優化：發現Codex重複犯錯時，讓佢覆盤然後更新AGENTS.md。
- 如果太大，將規劃、審查等放獨立markdown，主文件引用就得。
配置同權限：保持行為一致性
配置係令Codex跨會話、跨場景表現穩定嘅主要手段。可以設定默認模型、推理強度、沙箱模式、審批策略等。
推薦：個人默認放 ~/.codex/config.toml，倉庫專屬放 .codex/config.toml，命令行覆蓋只用臨時情況。
兩個關鍵權限：審批模式決定Codex執行命令前要唔要你確認；沙箱模式決定佢可以讀寫邊啲目錄同文件。
新手建議從嚴格開始，熟悉之後再對可信倉庫放開權限。
好多質量問題其實係配置問題，例如工作目錄錯、無寫權限、模型默認值唔啱、缺少工具。所以檢查配置係排查問題第一步。
測試、審查同自動化：完成閉環
唔好只係讓Codex改代碼，仲要讓佢寫測試、運行檢查、確認結果，同埋審查自己嘅改動。咁樣先係完整循環。
Codex應用嘅diff面板可以直接睇改動，點擊行數俾反饋，反饋會傳入下一輪對話。
斜槓 /review 提供PR式審查、審查未提交改動、審查commit、自定義審查指令。
團隊可以寫 code_review.md 並喺AGENTS.md引用，令審查行為一致。OpenAI內部100% PR都經過Codex審查。
- 技能適合：日誌分析、發佈說明、PR審查、遷移規劃、事故摘要、標準調試流程。
- 自動化適合：匯總近期提交、掃描潛在Bug、起草發佈說明、檢查CI失敗、生成每日站會摘要。
最後，管理好會話：每個連貫工作單元保持一個線程，用 /fork 分叉，用 /compact 壓縮上下文。避免用一個線程對應一個項目，要用線程對應任務。
最近好多朋友由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用好，本質上係一套工程化嘅習慣養成過程：上下文俾夠，規範寫入檔案，重複嘅事情變成工具，穩定嘅工具交俾自動化。
--end--
最後記得⭐️我，每日都在更新：如果覺得文章仲可以嘅話可以點讚轉發推薦評論
/...@作者：你講得完全正確（YAR師）
最近很多朋友從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用好，本質上是一套工程化的習慣養成過程：上下文給夠，規範寫進文件，重複的事情變成工具，穩定的工具交給自動化。
--end--
最後記得⭐️我，每天都在更新：如果覺得文章還不錯的話可以點贊轉發推薦評論
/...@作者：你說的完全正確（YAR師）