閱讀使用經驗和實踐建議

Codex 的穩定性不只來自模型能力，也來自工作流設計。好的上下文、清楚的規則、合適的許可權、可執行的驗證和可複用的 skills，都會直接影響結果質量。

OpenAI 的 best practices guide 覆蓋 CLI、IDE、App 等入口。本頁把核心建議整理成可執行步驟。

一條穩定工作鏈

flowchart LR
    Context["給上下文"] --> Plan["先規劃"]
    Plan --> Rules["沉澱規則"]
    Rules --> Configure["配置行為"]
    Configure --> Validate["測試和審查"]
    Validate --> Tools["接入外部工具"]
    Tools --> Skills["沉澱 Skills"]
    Skills --> Automate["自動化重複任務"]

這條鏈路的重點是逐步加固，而不是一次性把所有能力開啟。

先給任務上下文

一個可靠任務至少包含四件事：

• Goal：你要改變什麼。
• Context：哪些檔案、報錯、設計、文件和任務相關。
• Constraints：哪些規則、邊界、禁止事項必須遵守。
• Done when：什麼算完成，怎麼驗證。

示例：

目标：修复设置页移动端按钮文字溢出。
上下文：问题发生在 375px 宽度，相关页面是 settings/profile。
约束：不改全局设计系统，不新增依赖。
完成标准：375px 不溢出，桌面布局不退化，types:check 通过。

上下文不一定長，但必須真實、相關、當前。

難任務先規劃

複雜任務直接開改，通常會擴大範圍。更穩的做法是先讓 Codex 做只讀計劃：

请先只读分析，不要修改文件。
输出相关文件、风险点、建议修改范围、验证方式和不确定项。

Plan 階段適合：

• 需求模糊。
• 改動跨多個模組。
• 你不確定檔案位置。
• 任務需要設計取捨。
• 需要先估計風險。

計劃不是儀式。它是防止 Codex 在錯誤方向上高效執行。

用 AGENTS.md 儲存長期規則

當你反覆在 prompt 裡寫同一類要求，就應該沉澱到 AGENTS.md。

適合寫入：

• repo layout。
• 啟動、測試、構建命令。
• 包管理器和禁止命令。
• 程式碼風格、PR 預期、驗證標準。
• 敏感目錄、金鑰、部署和生產紅線。
• 多 agent 協作時的檔案邊界。

維護原則：

• 短而準，比長而泛更有用。
• 只有反覆發生的規則才寫進去。
• 發現 Codex 第二次犯同類錯誤，就更新規則。
• 大型專項流程可以引用獨立 markdown 或 skill。

用配置保持行為一致

config.toml 用來儲存長期偏好，CLI 引數用來處理一次性覆蓋。

常見配置維度：

• sandbox mode。
• approval policy。
• profiles。
• MCP servers。
• feature flags。
• model reasoning effort。

建議：

• 個人預設值放在 CODEX_HOME/config.toml。
• 專案規則放在 repo .codex/ 或 AGENTS.md。
• 臨時實驗使用 -c key=value。
• 常用模式沉澱為 profile。

配置不清楚時，很多質量問題會偽裝成“模型不穩定”。

用驗證建立反饋迴圈

不要只讓 Codex 改完就停。讓它驗證、解釋證據、說明未覆蓋範圍。

驗證可以包括：

• 單元測試。
• 型別檢查。
• lint。
• build。
• 截圖或瀏覽器檢查。
• diff review。
• 手動驗收清單。

關鍵是驗證必須對應任務目標。文件改動跑型別檢查，UI 改動看截圖，業務邏輯改動跑相關測試。

如果驗證失敗，Codex 應說明：

• 失敗命令是什麼。
• 失敗是否由本次改動引入。
• 已經嘗試了什麼。
• 下一步需要什麼環境或人工決策。

用 MCP 接入外部上下文

當上下文在 repo 外時，用 MCP，而不是反覆複製貼上。

適合接入：

• issue tracker。
• 日誌和監控。
• 內部文件。
• 設計工具。
• 只讀資料庫查詢。
• GitHub、Slack、Linear 等協作系統。

接入原則：

• 從 1-2 個高價值工具開始。
• 明確只讀和寫入許可權。
• 避免把敏感 token 寫入儲存庫。
• 把工具使用邊界寫進規則或 managed configuration。

MCP 的價值是減少上下文搬運，不是把所有系統無差別開放給 agent。

把重複流程變成 Skills

當一個 prompt 或流程反覆出現，就應該變成 skill。

適合沉澱：

• PR 審查清單。
• release note 生成。
• 文件美化和質量檢查。
• 日誌分診。
• migration planning。
• incident summary。

一個好 skill 應該包含：

• 清楚的觸發描述。
• 輸入和輸出邊界。
• 需要讀取的檔案或規則。
• 驗證方式。
• 必要時的指令碼或模板。

先做小而穩定的 skill，再逐步擴充套件，不要一開始覆蓋所有邊界情況。

自動化只處理穩定流程

Automations 適合已經穩定、可重複、低歧義的任務。

適合：

• 定期總結 commits。
• 掃描常見 bug 模式。
• 生成 standup summary。
• 檢查 CI failures。
• 起草 release notes。

不適合：

• 需要頻繁人工判斷的任務。
• 許可權高、影響生產的任務。
• 結果很難驗證的任務。

實用原則：skill 定義方法，automation 定義時間表。

最小採用順序

1. 先寫清楚任務 prompt。
2. 對複雜任務先 plan。
3. 把重複規則寫進 AGENTS.md。
4. 配置 sandbox、approval 和 profiles。
5. 每次改動都執行對應驗證。
6. 接入最有價值的 MCP。
7. 把重複流程沉澱為 skills。
8. 最後再自動化穩定任務。

Codex 的最佳實踐不是某一個技巧，而是這條鏈路能持續改進。

延長用量的 4 個槓桿

官方 Pricing 頁給出 4 條延長 usage limits 的具體做法，可以直接套到日常工作裡：

這 4 條不需要排隊做。哪一條容易改、立即就改。

接下來去哪