codex官方推薦的10個實用技巧，用完效率翻倍
整理版優先睇
Codex 更新變身開發代理，10 個技巧提升效率
呢篇文章係阿星分享佢學習 Codex 嘅心得。佢發現今次 Codex 更新表面上係多咗 Appshots、Goal mode、瀏覽器標註等功能，但真正改變係 Codex 由一個你問一句佢答一句嘅代碼助手，變成一個可以睇上下文、跑長任務、操作瀏覽器、接入團隊工具、持續完成目標嘅開發代理。整體結論係：正確用法唔係叫佢「幫我寫一段代碼」，而係畀一個同成熟開發代理匹配嘅任務佈置。
文章整理咗 10 個實用技巧，涵蓋提示詞設計、長任務管理、規劃先行、上下文傳遞、測試驗證、偏好固化、多層配置同團隊規模化。最核心嘅包括四段式提示詞、/goal 同 /plan 模式、Appshots 同瀏覽器標註減少溝通成本、AGENTS.md 將偏好固化落嚟、config.toml 管理環境權限。呢啲技巧可以大幅提升用 Codex 嘅效率同準確性。
總括嚟講，Codex 嘅新階段要求用戶由「寫 prompt」轉為「佈置任務」。識得用呢啲技巧嘅人，先算真正進入咗新階段。
- 四段式提示詞（Goal、Context、Constraints、Done when）係官方最佳實踐，減少 Codex 靠估，提升交付準確度。
- /goal 模式適合長時間執行嘅大型任務，需要寫清楚完成標準，Codex 會持續工作直至完成。
- 複雜任務先用 /plan 規劃，等 Codex 理解方向再動手，避免一開始就理解錯。
- Appshots 同瀏覽器標註可以減少大量文字描述，尤其適合 UI 調整同報錯排查。
- AGENTS.md 可以將項目規則、命令、完成標準固化，唔使每次重新教導 Codex，多層配置仲可以管理唔同目錄。
四段式提示詞模板
Goal：優化登錄頁嘅移動端佈局。 Context：重點睇 src/pages/login.tsx 同 src/components/AuthForm.tsx。 Constraints：唔好改接口邏輯，唔好引入新 UI 庫，保持現有設計風格。 Done when：移動端 375px 寬度下按鈕唔溢出，表單間距統一，現有測試通過。
AGENTS.md 模板
# AGENTS.md ## Project rules - Do not introduce new dependencies unless explicitly approved. - Keep existing file structure. - Use TypeScript strict mode. - Follow existing component naming conventions. ## Commands - Install: pnpm install - Dev: pnpm dev - Test: pnpm test - Lint: pnpm lint ## Done means - Code compiles. - Relevant tests pass. - No unrelated files changed. - Summary includes changed files and risk notes.
用四段式提示詞同規劃模式，減少 Codex 靠估
阿星提到，Codex 官方最佳實踐入面將好嘅提示詞拆成四個部分：Goal、Context、Constraints、Done when。普通寫法好似「幫我優化登錄頁」，但更好嘅寫法係畀曬呢啲資訊，等 Codex 唔使靠估。呢個技巧雖然簡單，但係最有效減少誤解嘅方法。
四段式提示詞：Goal、Context、Constraints、Done when
對於長任務，可以直接用 /goal 模式。唔使一輪一輪催 Codex「繼續」「接着改」，而係畀一個明確目標，等佢自己持續工作，甚至跑幾個鐘。阿星提醒，/goal 唔係寫得越短越好，而係要寫清楚咩叫「完成」。
/goal 模式適合持續幾小時嘅任務
如果任務複雜，最好先用 /plan 規劃。叫 Codex 先閲讀項目結構，畀一個修改計劃，包括改咩文件、有咩風險、需要你確認嘅問題。呢一步看似慢，但係慳返之後改錯方向嘅時間。
先 /plan 規劃，再動手實現
用 Appshots 同瀏覽器標註，傳遞上下文更直接
Appshots 係 macOS Codex App 嘅新功能，按兩個 Command 鍵就可以將當前最前面嘅應用窗口傳畀 Codex，唔單止截圖，仲會帶埋可讀取文字。呢個功能對於 UI 調整、報錯彈窗、設計稿預覽呢類場景特別有用，唔使再寫一大堆文字描述。
Appshots：按兩個 Command 鍵傳送應用窗口
另外，瀏覽器標註功能亦都增強咗，可以直接喺頁面預覽入面標註元素，例如「呢度字體縮細 2px」「呢度上下間距加 8px」。阿星話呢個比寫長 prompt 更準，本質上係令 Codex 從「聽你描述頁面」變成「睇住頁面改頁面」。
瀏覽器標註可以直接對元素修改，精準度高
測試驗證同 AGENTS.md，將偏好固化落嚟
阿星強調，唔好只係叫 Codex 生成代碼，仲要叫佢驗證。改完之後叫佢運行相關測試、lint 同類型檢查，如果失敗就自己定位修復，最後彙報結果同風險。呢句指令非常重要，因為你想要嘅係「經過驗證嘅交付」，唔係「睇落好似識行嘅代碼」。
改完代碼後要叫 Codex 運行測試同 lint
另外，如果你成日要提醒 Codex「唔好改目錄結構」「唔好引入新庫」「用 Tailwind」等，就應該寫 AGENTS.md。呢個係畀 agent 睇嘅 README，會自動加載入上下文。一個簡單模板包括項目規則、命令同完成標準。
AGENTS.md 可以減少每次重新教育 Codex
# AGENTS.md
## Project rules
- Do not introduce new dependencies unless explicitly approved.
- Keep existing file structure.
- Use TypeScript strict mode.
- Follow existing component naming conventions.
## Commands
- Install: pnpm install
- Dev: pnpm dev
- Test: pnpm test
- Lint: pnpm lint
## Done means
- Code compiles.
- Relevant tests pass.
- No unrelated files changed.
- Summary includes changed files and risk notes.多層 AGENTS.md 同 config.toml，管理複雜項目
AGENTS.md 可以放喺唔同層級：全局 ~/.codex/AGENTS.md、repo 級、子目錄級。越近當前目錄優先級越高。呢個對於複雜項目好有用，例如後台系統同移動端可以各自有唔同規則，Codex 進入唔同目錄時會自動套用。
多層 AGENTS.md：全局、項目、子目錄
另外，config.toml 可以管理模型、推理強度、沙盒、審批策略、MCP 等。阿星建議新手保持默認審批同沙盒策略，只畀 Codex 處理當前項目權限。仲可以設定唔同 profile，例如安全模式同信任模式，核心原則是「讓 Codex 高效，但唔好讓佢無邊界」。
config.toml 設定審批策略同沙盒
[profiles.safe]
approval_policy = "on-request"
[profiles.trusted]
approval_policy = "on-request"團隊規模化：插件共享同 Analytics，睇流程節省
Business 同 Enterprise 嘅更新包括插件共享同 Analytics 升級。插件共享可以通過 marketplace sources 分發可複用插件包，包括 skills、應用集成同 MCP servers。Analytics 則睇到活躍用戶、積分、token、運行次數等指標。
插件共享令團隊可以共用內部工具
但阿星認為，企業真正應該關注嘅唔係 Codex 寫咗幾多行代碼，而係邊啲重複任務被自動化、邊啲測試排查流程變短、邊啲人可以將 Codex 融入真實工作流。
哈囉，大家好
我係阿星！
最近我喺度加班學codex。發現Codex今次更新，表面睇係 Appshots、Goal mode、瀏覽器標註、插件共享、Analytics呢啲功能一齊推出。但真正嘅變化唔係「功能多咗」。
真正嘅變化係：Codex正喺度由一個你問一句、佢答一句嘅代碼助手，變成一個可以睇上下文、跑長任務、操作瀏覽器、接入團隊工具、持續完成目標嘅開發代理。下面呢10個技巧就好關鍵。
1. 唔好淨係話「幫我改」，要用四段式提示詞
Codex官方最佳實踐裏面，其實已經將好嘅提示詞拆得好清楚：
Goal、Context、Constraints、Done when。
即係目標、上下文、約束、完成標準。（資料嚟自OpenAI Developers）
普通寫法：
幫我優化登入頁
更好嘅寫法：
Goal：優化登入頁嘅流動裝置佈局。
Context：主力睇 src/pages/login.tsx 和 src/components/AuthForm.tsx。
Constraints：唔好改接口邏輯，唔好引入新嘅UI庫，保持現有設計風格。
Done when：流動裝置375px闊度下按鈕唔好溢出，表間距統一，現有測試通過。
呢類提示詞最大好處係，Codex唔使估。
你唔係要佢「發揮」，你係畀佢交付標準。
2. 長任務直接用 /goal，唔好一輪一輪咁催
以前用AI寫代碼，最麻煩係佢做一半就停咗，
你仲要不斷話「繼續」「跟住改」「再檢查下」。
而家Goal mode已經正式用得。
官方話佢可以喺Codex App、IDE插件同CLI入面用，
令Codex圍住一個明確目標持續工作，
甚至跑幾個鐘或者幾日。（資料嚟自OpenAI Help Center）
適合 /goal 嘅任務唔係「寫一個按鈕」，
而係呢種：
/goal
將呢個項目嘅登入、註冊、忘記密碼三個頁面統一成新嘅設計規範。
要求：
- 1.唔改變後端接口；
- 2.保留現有表單驗證；
- 3.統一流動裝置樣式；
- 4.每完成一個頁面後執行相關檢查；
- 5.最後總結我改咗邊啲檔案、邊啲地方需要人工複檢。
關鍵點：目標文本本身就係完成標準。
所以 /goal 唔係寫得越短越好，而係要寫清楚咩叫「完成」。
3. 難任務先開 /plan，唔好一嚟就叫佢鬱代碼
如果任務複雜，最好先叫Codex規劃，而唔係直接實行。
官方都建議複雜、模糊或者難描述嘅任務，先叫Codex plan，再鬱手。（資料嚟自OpenAI Developers）
你可以咁樣寫：
暫時唔好改代碼。
請先閲讀項目結構，揾出實現呢個功能可能會用到嘅檔案。
然後畀我一個修改計劃，包括：
- 1.需要改邊啲檔案；
- 2.每個檔案改啲咩；
- 3.可能嘅風險；
- 4.需要我確認嘅問題。
等我確認之後先開始實行。
呢步看似慢，其實節省時間。
因為Codex最易翻車嘅地方，唔係唔識寫代碼，而係方向一開始就理解錯咗。
4. 用Appshots傳上下文，少寫一大堆廢話
今次最實用嘅新功能之一係Appshots。
喺macOS嘅Codex App度，撳兩個Command掣，
就可以將當前最前面嘅應用視窗傳畀Codex。
佢唔止係截圖，仲會帶埋可讀取文字。（資料嚟自OpenAI Developers）
即係你唔使再咁樣描述：
頁面右上角嗰個掣旁邊嘅間距有啲怪，即係頭像左邊嗰個位……
你可以直接Appshot，然後話：
睇呢個介面。
將頂部導航右側嘅按鈕組間距調整得更自然啲，視覺上同左邊Logo對齊。
唔好改頁面結構，只改樣式。
對UI、報錯彈窗、配置介面、控制枱輸出、
設計稿預覽呢類場景，
Appshots會大幅減少溝通成本。
5. 前端改樣式，用瀏覽器標註，唔好用純文字描述
今次Codex嘅in-app browser annotations都加強咗。
官方說明入面提到，
高級標註可以
直接針對字體大小、顏色、間距等樣式問題
畀出更精確嘅反饋。（資料嚟自OpenAI Developers）
呢個對前端特別有用。
以前你要話：
第二張卡片嘅標題太大，
按鈕離底部太近，
圖片比例唔係太啱。
而家更好嘅方式係：
打開頁面預覽，直接喺瀏覽器度標註對應元素：
呢度字體縮細2px。
呢度上下間距加8px。
呢個按鈕同左邊文字置中對齊。
呢張圖保持16:9，唔好拉伸。
呢個比寫長prompt更準。
本質上，佢令Codex由「聽你描述頁面」，
變成「睇住頁面改頁面」。
6. 叫Codex自己寫測試、跑測試、解釋測試結果
好多人用Codex最大問題係：淨係叫佢生成，唔叫佢驗證。
官方最佳實踐都提到，唔好淨係叫Codex做改動，
仲要叫佢創建測試、執行檢查、確認結果、審查diff。（資料嚟自OpenAI Developers）
你可以直接加一句：
改完之後請執行相關測試、lint同類型檢查。
如果測試失敗，先自己定位原因並修復。
最後話畀我知：
- 1.執行咗邊啲指令；
- 2.係咪全部通過；
- 3.重有邊啲風險需要人工檢查。
呢句說話非常重要。
因為你唔係要一段「睇落似行得鬱」嘅代碼，
你要一個「經過驗證嘅交付」。
7. 為項目寫 AGENTS.md，將你嘅偏好固化落嚟
如果你每次都喺度提Codex：
不要亂改目錄結構。
不要引入新庫。
接口文件別動。
CSS 用 Tailwind。
組件命名按項目規範來。咁就表示你應該寫 AGENTS.md 了。
官方把 AGENTS.md 形容成畀agent睇嘅開放格式README，
會自動加載入上下文。
佢適合寫項目結構、執行方式、測試指令、工程規範、禁止事項、完成標準等。（資料嚟自OpenAI Developers）
一個簡單版本
可以咁樣寫：
# AGENTS.md
## Project rules
- Do not introduce new dependencies unless explicitly approved.
- Keep existing file structure.
- Use TypeScript strict mode.
- Follow existing component naming conventions.
## Commands
- Install: pnpm install
- Dev: pnpm dev
- Test: pnpm test
- Lint: pnpm lint
## Done means
- Code compiles.
- Relevant tests pass.
- No unrelated files changed.
- Summary includes changed files and risk notes.呢樣嘢嘅價值係：
你唔使每次都重新教Codex。
8. 用多層 AGENTS.md 管住唔同目錄
重有一個好多人唔知嘅細節：AGENTS.md 可以放喺唔同層級。
官方說明入面提到，可以有全局 ~/.codex/AGENTS.md，
都可以有repo級別、子目錄級別嘅 AGENTS.md。
越近當前目錄嘅說明優先級越高。（資料嚟自OpenAI Developers）
呢個就好適合複雜項目。
比如：
~/.codex/AGENTS.md
個人通用偏好：回答中文、改動前先解釋、不要擅自裝依賴
project/AGENTS.md
項目級規則：技術棧、啓動命令、測試命令、PR 標準
project/apps/admin/AGENTS.md
後台系統規則：Ant Design、權限邏輯不能動
project/apps/mobile/AGENTS.md
移動端規則：React Native、注意 iOS/Android 差異咁樣Codex進入唔同目錄時，會自動拎到唔同嘅工作規範。
呢個比每次手動解釋高效得多。
9. 將 config.toml 配好
好多Codex問題唔係模型唔得，而係環境未配置好。
官方建議將個人默認配置放喺 ~/.codex/config.toml，repo級配置放喺 .codex/config.toml。
配置入面可以管理模型、推理強度、沙盒、審批策略、MCP等。（資料嚟自OpenAI Developers）
新手建議：權限一開始唔好開得太大。
可以先保持默認審批同沙盒策略，淨係畀佢處理當前項目嘅權限。等你確認呢個項目可靠、指令安全，再逐步放寬。
更實用嘅做法係為唔同場景設定唔同profile：
# ==========================================
# Profile：安全模式（用於新項目/陌生倉庫）
# ==========================================
[profiles.safe]
approval_policy = "on-request"
# approval_policy = 執行命令前要不要經過你批准
# "on-request" = 每次執行命令前都彈窗問你"能跑嗎？"（最嚴格，適合不確定安全性的場景）
# ==========================================
# Profile：信任模式（用於熟悉、已驗證的項目）
# ==========================================
[profiles.trusted]
approval_policy = "on-request"
# 官方推薦即使是信任項目也保持 "on-request"（手動批准）
# 如果你確定要全自動（比如跑 CI 腳本、定時任務），可以改成：
# "never" = 從不請求批准，Codex 直接執行（效率最高，風險最大，僅限非交互式自動化）
核心原則係：
令Codex高效，但唔好令佢冇邊界。
10. 團隊用Codex，唔好淨係睇「生成咗幾多代碼」，要睇「節省咗幾多流程」
今次Business同Enterprise相關更新入面，插件共享同Analytics好值得留意。
插件共享允許團隊透過marketplace sources分發可複用插件包，入面可以包括skills、應用集成同MCP servers。（資料嚟自OpenAI Developers）
Analytics升級就可以見到活躍用戶、積分、token、執行次數、用戶排行榜、代碼生成行數、插件使用情況等指標。（9to5Mac）
但企業真正應該睇嘅唔係「Codex寫咗幾多行代碼」。
更加應該睇：
哪些重複任務被自動化了？
哪些測試、排查、修復流程變短了？
哪些內部工具可以通過插件共享給全團隊？
哪些人已經把 Codex 融入真實工作流？
哪些倉庫最適合先做 agent 化改造？即係話，Codex對團隊嘅價值，唔係多咗一個寫代碼嘅人。
而係令團隊入面好多原本靠人手複製、搜索、排查、執行指令嘅流程，
開始被系統性壓縮。
總結
今次Codex更新，最值得關注嘅唔係某一個單點功能。
Appshots解決嘅係上下文問題。
Goal mode解決嘅係長任務問題。
瀏覽器標註解決嘅係前端反饋問題。
插件共享同Analytics解決嘅係團隊規模化問題。
所以，Codex嘅正確用法已經唔係：幫我寫一段代碼。
而係畀出一個同成熟嘅開發代理匹配嘅任務佈置。
會咁樣用嘅人，先算真正進入咗Codex嘅新階段。
哈嘍，大家好
我是阿星！
最近我在加班學習codex。發現Codex 這次更新，表面上看是 Appshots、Goal mode、瀏覽器標註、插件共享、Analytics 這些功能一起上線。但真正的變化不是“功能變多了”。
真正的變化是：Codex 正在從一個你問一句、它答一句的代碼助手，變成一個可以看上下文、跑長任務、操作瀏覽器、接入團隊工具、持續完成目標的開發代理。下面這 10 個技巧就很關鍵。
1. 不要只說“幫我改”，要用四段式提示詞
Codex 官方最佳實踐裏，其實已經把好提示詞拆得很清楚：
Goal、Context、Constraints、Done when。
也就是目標、上下文、約束、完成標準。(信息來自OpenAI Developers)
普通寫法：
幫我優化登錄頁
更好的寫法：
Goal：優化登錄頁的移動端佈局。
Context：重點看 src/pages/login.tsx 和 src/components/AuthForm.tsx。
Constraints：不要改接口邏輯，不要引入新的 UI 庫，保持現有設計風格。
Done when：移動端 375px 寬度下按鈕不溢出，表單間距統一，現有測試通過。
這類提示詞最大的好處是，Codex 不用猜。
你不是在讓它“發揮”，你是在給它交付標準。
2. 長任務直接用 /goal，不要一輪一輪催
以前用 AI 寫代碼，最麻煩的是它做一半就停了，
你還得反覆說“繼續”“接着改”“再檢查一下”。
現在 Goal mode 已經正式可用。
官方說它可以在 Codex App、IDE 插件和 CLI 中使用，
讓 Codex 圍繞一個明確目標持續工作，
甚至跑幾個小時或幾天。(信息來自OpenAI Help Center)
適合 /goal 的任務不是“寫一個按鈕”，
而是這種：
/goal
把這個項目的登錄、註冊、忘記密碼三個頁面統一成新的設計規範。
要求：
- 1.不改變後端接口；
- 2.保留現有表單校驗；
- 3.統一移動端樣式；
- 4.每完成一個頁面後運行相關檢查；
- 5.最終給我總結改了哪些文件、哪些地方需要人工複核。
關鍵點：目標文本本身就是完成標準。
所以 /goal 不是寫得越短越好，而是要寫清楚什麼叫“完成”。
3. 難任務先開 /plan，別一上來就讓它動代碼
如果任務複雜，最好先讓 Codex 規劃，而不是直接實現。
官方也建議複雜、模糊或者難描述的任務，先讓 Codex plan，再動手。(信息來自OpenAI Developers)
你可以這樣寫：
先不要改代碼。
請先閲讀項目結構，找出實現這個功能可能涉及的文件。
然後給我一個修改計劃，包括：
- 1.需要改哪些文件；
- 2.每個文件改什麼；
- 3.可能的風險；
- 4.需要我確認的問題。
等我確認後再開始實現。
這一步看似慢，其實省時間。
因為 Codex 最容易翻車的地方，不是不會寫代碼，而是方向一開始就理解錯了。
4. 用 Appshots 傳上下文，少寫一大堆廢話
這次最實用的新功能之一是 Appshots。
在 macOS 的 Codex App 裏，按兩個 Command 鍵，
就能把當前最前面的應用窗口發給 Codex。
它不只是截屏，還會帶上可讀取文字。(信息來自OpenAI Developers)
這意味着你不用再這樣描述：
頁面右上角那個按鈕旁邊的間距有點怪，就是頭像左邊那個地方……
你可以直接 Appshot，然後說：
看這個界面。
把頂部導航右側的按鈕組間距調得更自然一點，視覺上和左側 Logo 對齊。
不要改頁面結構，只改樣式。
對 UI、報錯彈窗、配置界面、控制枱輸出、
設計稿預覽這類場景，
Appshots 會大幅減少溝通成本。
5. 前端改樣式，用瀏覽器標註，不要純文字描述
這次 Codex 的 in-app browser annotations 也增強了。
官方說明裏提到，
高級標註可以
直接針對字體大小、顏色、間距等樣式問題
給出更精確的反饋。(信息來自OpenAI Developers)
這對前端特別有用。
以前你要說：
第二個卡片的標題太大，
按鈕離底部太近，
圖片比例不太對。
現在更好的方式是：
打開頁面預覽，直接在瀏覽器裏標註對應元素：
這裏字體縮小 2px。
這裏上下間距加 8px。
這個按鈕和左邊文案居中對齊。
這張圖保持 16:9，不要拉伸。
這比寫長 prompt 更準。
本質上，它讓 Codex 從“聽你描述頁面”，
變成“看着頁面改頁面”。
6. 讓 Codex 自己寫測試、跑測試、解釋測試結果
很多人用 Codex 最大的問題是：只讓它生成，不讓它驗證。
官方最佳實踐也提到，不要只讓 Codex 做改動，
還要讓它創建測試、運行檢查、確認結果、審查 diff。(信息來自OpenAI Developers)
你可以直接加一句：
改完後請運行相關測試、lint 和類型檢查。
如果測試失敗，先自己定位原因並修復。
最後告訴我：
- 1.跑了哪些命令；
- 2.是否通過；
- 3.還有哪些風險需要人工檢查。
這句話非常重要。
因為你不是要一段“看起來能跑”的代碼，
你要一個“經過驗證的交付”。
7. 給項目寫 AGENTS.md，把你的偏好固化下來
如果你每次都在提醒 Codex：
不要亂改目錄結構。
不要引入新庫。
接口文件別動。
CSS 用 Tailwind。
組件命名按項目規範來。那說明你該寫 AGENTS.md 了。
官方把 AGENTS.md 形容成給 agent 看的開放格式 README，
會自動加載進上下文。
它適合寫項目結構、運行方式、測試命令、工程規範、禁止事項、完成標準等。(信息來自OpenAI Developers)
一個簡單版本
可以這樣寫：
# AGENTS.md
## Project rules
- Do not introduce new dependencies unless explicitly approved.
- Keep existing file structure.
- Use TypeScript strict mode.
- Follow existing component naming conventions.
## Commands
- Install: pnpm install
- Dev: pnpm dev
- Test: pnpm test
- Lint: pnpm lint
## Done means
- Code compiles.
- Relevant tests pass.
- No unrelated files changed.
- Summary includes changed files and risk notes.這東西的價值是：
你不用每次重新教育 Codex。
8. 用多層 AGENTS.md 管住不同目錄
還有一個很多人不知道的細節：AGENTS.md 可以放在不同層級。
官方說明裏提到，可以有全局 ~/.codex/AGENTS.md，
也可以有 repo 級別、子目錄級別的 AGENTS.md。
越靠近當前目錄的說明優先級越高。(信息來自OpenAI Developers)
這就很適合複雜項目。
比如：
~/.codex/AGENTS.md
個人通用偏好：回答中文、改動前先解釋、不要擅自裝依賴
project/AGENTS.md
項目級規則：技術棧、啓動命令、測試命令、PR 標準
project/apps/admin/AGENTS.md
後台系統規則：Ant Design、權限邏輯不能動
project/apps/mobile/AGENTS.md
移動端規則：React Native、注意 iOS/Android 差異這樣 Codex 進入不同目錄時，會自動拿到不同的工作規範。
這比每次手動解釋高效得多。
9. 把 config.toml 配好
很多 Codex 問題不是模型不行，而是環境沒配好。
官方建議把個人默認配置放在 ~/.codex/config.toml，repo 級配置放在 .codex/config.toml。
配置裏可以管理模型、推理強度、沙盒、審批策略、MCP 等。(信息來自OpenAI Developers)
新手建議：權限別一開始開太大。
可以先保持默認審批和沙盒策略，只給它處理當前項目的權限。等你確認這個項目可靠、命令安全，再逐步放寬。
更實用的做法是給不同場景設置不同 profile：
# ==========================================
# Profile：安全模式（用於新項目/陌生倉庫）
# ==========================================
[profiles.safe]
approval_policy = "on-request"
# approval_policy = 執行命令前要不要經過你批准
# "on-request" = 每次執行命令前都彈窗問你"能跑嗎？"（最嚴格，適合不確定安全性的場景）
# ==========================================
# Profile：信任模式（用於熟悉、已驗證的項目）
# ==========================================
[profiles.trusted]
approval_policy = "on-request"
# 官方推薦即使是信任項目也保持 "on-request"（手動批准）
# 如果你確定要全自動（比如跑 CI 腳本、定時任務），可以改成：
# "never" = 從不請求批准，Codex 直接執行（效率最高，風險最大，僅限非交互式自動化）
核心原則是：
讓 Codex 高效，但不要讓它無邊界。
10. 團隊用 Codex，不要只看“生成了多少代碼”，要看“節省了多少流程”
這次 Business 和 Enterprise 相關更新裏，插件共享和 Analytics 很值得注意。
插件共享允許團隊通過 marketplace sources 分發可複用插件包，裏面可以包括 skills、應用集成和 MCP servers。(信息來自OpenAI Developers)
Analytics 升級則能看到活躍用戶、積分、token、運行次數、用戶排行榜、代碼生成行數、插件使用情況等指標。(9to5Mac)
但企業真正該看的不是“Codex 寫了多少行代碼”。
更應該看：
哪些重複任務被自動化了？
哪些測試、排查、修復流程變短了？
哪些內部工具可以通過插件共享給全團隊？
哪些人已經把 Codex 融入真實工作流？
哪些倉庫最適合先做 agent 化改造？也就是說，Codex 對團隊的價值，不是多了一個寫代碼的人。
而是讓團隊裏很多原本靠人肉複製、搜索、排查、跑命令的流程，
開始被系統性壓縮。
總結
這次 Codex 更新，最值得關注的不是某一個單點功能。
Appshots 解決的是上下文問題。
Goal mode 解決的是長任務問題。
瀏覽器標註解決的是前端反饋問題。
插件共享和 Analytics 解決的是團隊規模化問題。
所以，Codex 的正確用法已經不是：幫我寫一段代碼。
而是給出一個和成熟的開發代理匹配的任務佈置。
會這樣用的人，才算真正進入了 Codex 的新階段。