你會學到怎麼整理資料、拆解需求、產出內容、檢查結果，也會練習改文案、調樣式、跑預覽、讀錯誤訊息。

適合誰

| 角色 | 你可能遇到的問題 | 課上會練什麼 |
|

第一階段：骨架完整

• 建立 VuePress + Theme Hope 文件站。
• 建立 README、貢獻指南、行為準則和安全政策。
• 搭建入門、進階、團隊和案例目錄。
• 新增官方資料索引。
• 補充第一批截圖和命令輸出。
• 給每篇教程增加“適用版本”和“最後核對日期”。

第二階段：指南成型

• 完成 CLI 從安裝到日常使用的完整教程。
• 完成 AGENTS.md 專題。
• 完成提示詞模板庫。
• 完成排障手冊第一版。
• 補齊 Cloud、IDE、桌面 App 的使用差異。

第三階段：案例驅動

• 收集 20 個真實工程案例。
• 每個案例包含任務說明、關鍵過程、驗證方式和覆盤。
• 建立案例標籤：前端、後端、測試、重構、文件、CI、安全。
• 補充失敗案例，說明 Codex 不適合直接處理的場景。

第四階段：社群傳播

• 設計更完整的首頁和 Open Graph 圖。
• 建立中英文關鍵詞索引。
• 釋出 GitHub Pages。
• 整理適合社媒傳播的短連結和學習路線圖。
• 邀請早期貢獻者認領章節。

貢獻入口

你可以從這些任務開始：

• 修正文件裡的不準確表述。
• 新增一個你親自跑過的 Codex 案例。
• 給排障手冊補一個常見錯誤。
• 把官方文件的新變化同步到資料索引。

三種使用姿勢

| 模式 | 適合任務 | 典型命令 |
|

設定檔案放在哪裡

通常位於：

~/.codex/config.toml

專案長期規則建議寫到倉庫內的 AGENTS.md，個人偏好放到本機 config.toml。這樣團隊成員能共享專案規則，又能保留自己的 CLI 使用習慣。

最小設定示例

下面是一個學習用示例，實際欄位請以官方 config reference 和當前 CLI 版本為準：

model = "gpt-5.1-codex-max"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[profiles.readonly]
approval_policy = "on-request"
sandbox_mode = "read-only"

[profiles.build]
approval_policy = "on-request"
sandbox_mode = "workspace-write"

這個示例表達三件事：

• 預設允許在當前工作區寫檔案。
• 高風險命令仍需要審核。
• 額外保留一個只讀 profile，適合新倉庫分析。

常見設定項按用途理解

| 用途 | 你要決定什麼 | 建議 |
|

先理解四層設定

| 層級 | 典型檔案或入口 | 解決的問題 | 初學者建議 |
|

三個概念

| 能力 | 解決的問題 | 適合沉澱什麼 |
|

先分清風險等級

| 風險等級 | 例子 | 建議策略 |
|

你可以把每一天都當成一支口播影片：先講「小白遇到什麼問題」，再給一段可以直接複製給 Codex 的問法，最後教他怎麼驗收結果。

怎麼使用這 60 天

每一天都照這個順序練：

1. 說清楚你現在手上有什麼。
2. 要求 Codex 先不要修改檔案。
3. 讓它盤點、分類、提出下一步。
4. 你確認方向後，再讓它小步執行。
5. 最後要求它交代改了什麼、怎麼驗證、還有什麼風險。

D1-D10：先讓 Codex 看懂資料

| 天數 | 小白場景 | 可以直接複製的問法 | 驗收重點 | 延伸閱讀 |
|

最後核對

官方資料最後核對日期：2026-05-27。下載地址與安裝方式以 OpenAI Codex 產品頁 和 chatgpt.com/codex/cloud 為準，不同地區和帳號方案下可用功能可能有所差異。

本教程裡的 Codex 桌面 App 指電腦端客戶端，不是手機 App。它由 OpenAI 官方釋出，支援 macOS 和 Windows，安裝後可以在本地管理專案、發起任務、使用 Skills 和 Automations。

下載

開啟 chatgpt.com/codex/cloud，頁面中央會顯示對應系統的下載按鈕。

macOS：

點選「Download for macOS」下載 .dmg 安裝包。

Windows：

Windows 使用者點選對應的下載按鈕，下載完成後執行安裝程式，按提示完成安裝。

macOS 安裝步驟

1. 開啟下載好的 .dmg 檔案
2. 將 Codex 圖示拖入「Applications（應用程式）」資料夾
3. 首次啟動時，macOS 可能提示「無法驗證開發者」，進入「系統設定 → 隱私與安全性」，點選「仍要開啟」

登入

安裝完成後開啟 App，使用 ChatGPT / OpenAI 帳號登入。

安裝後驗證

登入成功後，左側欄應顯示「Projects」和「Chats」兩個入口，頂部顯示當前帳號資訊。如果介面正常載入，說明安裝成功。

下一步：訂閱 ChatGPT Plus / Pro

最後核對

官方資料最後核對日期：2026-05-27。定價、方案與 Codex 可用性請以 ChatGPT 定價頁 和 Using Codex with your ChatGPT plan 為準。

為什麼需要訂閱

免費版 ChatGPT 可以體驗基礎對話，但 Codex 功能通常需要付費方案才能穩定使用。第一次學 Codex，不需要一開始就買最高方案，先用 Plus 跑完 D1-D10 的小任務比較實際。

| 方案 | 適合誰 | 建議 |
|

最後核對

官方資料最後核對日期：2026-05-27。本章參考 Codex App docs、Settings、Agent approvals and security 等官方資料。介面說明以當前 Codex 桌面 App 實際版本為準，不同系統、地區、客戶端版本和帳號方案下顯示可能略有差異。

認識對話和專案

開啟 Codex 桌面 App，左側欄包含兩個主要入口：Chat（對話） 和 Project（專案）。

Chat 對話

與 ChatGPT 網頁端對話體驗基本一致，適合處理日常的、一次性的問答和簡單任務。每個對話相互獨立，不共享工作目錄。

Project 專案

適合需要操作本地檔案的任務，例如生成程式碼、編寫文件、製作 PPT、完成報告。在專案裡建立的所有對話都共享同一個本地工作目錄，方便統一管理多個子任務。

在專案裡下達指令後，Codex 的修改會直接應用到你本地資料夾中的檔案。

對話方塊功能說明

Codex 桌面 App 的對話方塊與 ChatGPT 網頁端類似，但額外提供了以下功能：

1. 新增上下文：可以附加檔案、截圖或其他參考內容
2. 切換模型：在不同模型之間切換
3. 控制權限：設定 Codex 在當前任務中的操作權限
4. 選擇工作目錄：指定 Codex 在哪個本地資料夾下執行任務

設定面板

點選左下角頭像或設定圖示可以開啟設定面板。

上圖左側就是 Codex 桌面 App 的設定選單。不要把它當成一次性必須填完的表單：新手只需要確認「常規」和「權限」能支撐第一個任務，其他設定等真實場景出現後再逐步開啟。

新手先按這四步檢查

1. 先選工作模式：做程式碼、網站、指令碼、倉庫任務時選「適用於程式設計」；寫文案、整理資料、做非程式碼任務時可以選「適用於日常工作」。
2. 先別急著開最大權限：剛開始建議讓 Codex 只在當前工作區內讀寫檔案，遇到聯網、系統檔案、危險命令時再單獨審核。
3. 先設定工作目錄：第一個任務儘量使用一個空資料夾或測試專案，不要直接把重要專案交給新手階段的 Codex。
4. 先觀察使用情況：如果任務經常中斷、額度告急或模型響應變慢，再回到「使用情況」和方案頁面確認限制。

設定逐項說明

什麼時候需要改設定

| 你遇到的情況 | 優先檢查 |
|

最後核對

官方資料最後核對日期：2026-05-27。本文參考 OpenAI 官方文章 Work with Codex from anywhere。具體入口、可用地區、系統支援和介面名稱會隨客戶端更新變化，請以當前 ChatGPT 手機 App 和 Codex 桌面 App 為準。

這裡說的“手機端 Codex”，更準確地說，是 ChatGPT 手機 App 裡的 Codex 入口。它不是單獨的手機 Codex App，也不是把手機變成遠端桌面滑鼠鍵盤。

你可以把它理解成：桌面 App、遠端開發機或其他已授權環境里正在執行 Codex，手機端負責連線這些環境，讓你在離開電腦時繼續檢視、回覆、審核和調整任務。

你需要更新你的 ChatGPT APP 到最新版本，然後選擇連線你電腦裡面的 Codex。

連線桌面 Codex APP：

在 ChatGPT 中開啟 Codex，就可以直接使用了。

它能做什麼

手機端連線到正在執行 Codex 的機器後，可以繼續處理這些事情：

• 檢視正在進行的執行緒和任務狀態。
• 閱讀 Codex 的階段性輸出、終端輸出、截圖、diff 和測試結果。
• 回覆 Codex 的澄清問題。
• 審核命令、網路訪問或其他需要人工確認的操作。
• 改變任務方向、切換模型或補充新的上下文。
• 新建任務，讓 Codex 從已連線的開發環境裡開始工作。

真正執行任務的地方仍然是桌面 App 或遠端環境。你的檔案、依賴、憑據、權限和本地設定不會因為手機端接入而搬到手機上。

使用前提

使用前先確認這些條件：

• 手機上安裝並更新 ChatGPT App。
• 電腦上安裝並更新 Codex 桌面 App。
• 手機和電腦登入同一個 ChatGPT / OpenAI 帳號，且處在支援 Codex 的地區和方案範圍內。
• 桌面 App 已經連線到對應專案，或 Codex 正在某臺已授權機器、devbox、遠端環境中執行。
• 如果任務會寫檔案、跑命令、訪問網路，仍然需要理解並確認對應權限。

推薦使用場景

手機端最適合處理“離開電腦但不想讓任務停住”的時刻：

• 通勤路上檢視長任務進展。
• Codex 需要你選擇方案時，快速給出方向。
• 任務卡在權限審核時，從手機上批准或拒絕。
• 會議前讓 Codex 彙總最新程式碼、issue、文件或客戶背景。
• 突然想到一個改動點，先發給 Codex 開始探索，回到電腦後再細看 diff。

不適合怎麼用

手機端不適合替代完整的本地審查流程。下面這些事情最好回到電腦上做：

• 大範圍程式碼合併前的最終 review。
• 涉及生產環境、金鑰、帳單、釋出部署的高風險操作。
• 需要長時間閱讀大量 diff 的任務。
• 需要你手動操作 IDE、偵錯程式或本地 GUI 的任務。

如果你在手機上審核命令，建議只批准自己能看懂的操作。遇到刪除、覆蓋、部署、傳輸敏感資料等動作，先停下來，回到電腦上確認。

一個典型流程

1. 在電腦上開啟 Codex 桌面 App，並進入對應專案。
2. 讓 Codex 開始一個需要較長時間的任務，例如排查失敗測試或整理文件。
3. 離開電腦後，在 ChatGPT 手機 App 中進入 Codex。
4. 開啟同一個正在執行的任務執行緒。
5. 檢視 Codex 的輸出、截圖、終端日誌、測試結果或 diff。
6. 如果 Codex 需要確認，直接在手機上回復、審核或調整方向。
7. 回到電腦後，再做完整 diff review、執行驗證命令和提交。

和 Codex Cloud 的區別

| 對比項 | 手機端連線桌面 App | Codex Cloud |
|

三種方案怎麼選

| 方案 | 適合誰 | 優點 | 需要注意 |
|

最後核對

官方資料最後核對日期：2026-05-27。本章以開發一個簡單網頁為例，演示從建立工作目錄到任務迭代的完整操作流程。

本章以"用 Codex 桌面 App 開發一個關於 AI 發展歷史的簡單網頁"為例，走完一次完整的任務閉環，幫助你快速上手 Codex 桌面 App 的基本用法。

第一步：建立本地工作資料夾

在本地新建一個空資料夾，作為 Codex 的工作目錄。Codex 生成的所有檔案都會儲存在這裡。

第二步：選擇對話還是專案

開啟 Codex 桌面 App 後，你需要選擇用"對話"還是"專案"來開始任務。

• 對話：適合一次性任務，操作簡單，但多個對話之間不共享工作目錄。
• 專案：支援在同一工作目錄下建立多個對話，每個對話處理不同的子任務，管理更方便。

如果你不確定選哪個，優先選擇專案——後續擴充套件任務時更靈活，工作目錄也只需要設定一次。

第三步：新增工作目錄

選擇專案後，點選"使用現有資料夾"，選中剛才建立的資料夾。

選擇完成後，對話方塊左下角會顯示當前工作目錄的路徑，確認路徑正確即可。

第四步：輸入任務描述，開始執行

在對話方塊中輸入你的需求，點選傳送，Codex 就會開始執行任務。

任務完成後，Codex 會在對話中展示結果，同時將生成的檔案寫入工作目錄。

如果生成的是網頁檔案，可以直接點選 Codex 彈出的"開啟"按鈕，在 App 內建瀏覽器中預覽效果，無需手動開啟資料夾。

第五步：逐步迭代

對結果不滿意時，直接在當前對話方塊中繼續描述修改需求，Codex 會在已有基礎上進行調整。

隨著對話輪次增加，上下文視窗會逐漸被填滿。點選對話方塊右下角的小圓圈圖示，可以檢視當前上下文使用情況。

如果使用的是"對話"模式而非專案，新建對話時需要重新指定工作目錄，兩個對話之間也是相互隔離的，不方便統一管理。這也是推薦使用專案的主要原因之一。

我們使用codex開發obsidian新手教程網站作為示例：來說明任務的順序執行管理和並行操作

1.順序執行

選擇本地專案/建立新的專案，該專案實際上就對應我們本地的一個資料夾，它儲存在我們的本地。

然後點選建立新的對話。

我們向 CodeX 傳送任務，讓他幫我們設計一個網站，這個時候他就會開始執行。

在這個任務沒有執行的過程中，如果我們去給他下達新的命令，就只能等待。顯示的是下面這種情況：

這種相當於當前他正在執行一個任務，我們給他的另外兩個命令就需要排隊，必須等前面的任務執行完成之後才能執行。

但是如果我們想修改一下要求，比如想讓他明確這個網站的背景風格為“手繪風格”，如果等他設計完成之後再去修改就會比較麻煩。我希望他在正在設計的時候就知道我的風格要求。

這時候，我們可以點選引導選項。這樣操作後，他就會執行一個“插隊”的操作：

1. 原本的任務順序：
   (a) 執行網站設計
   (b) 介紹技術選型
   (c) 執行手繪風格要求（原定第三個任務）

2. 插隊後的效果：
   我們想讓“手繪風格”在設計過程中就發揮作用，透過點選引導提示，這個任務就會直接插隊到當前正在執行的任務當中。

這實際上就是透過這樣一個過程，演示如何對順序執行的任務進行管理以及相關的插隊操作。

2.如何並行

實際上就是一個專案（Project）裡面，我們同時去執行多個任務。

這個時候，我們只需要在左側邊欄點選“新建對話”就可以了。這樣的話，它的幾個任務就會並行執行，互不干擾。

三種常見模式

1. Suggest
   這是最保守的模式。Codex 可以讀取檔案並提出修改建議，但真正改檔案或執行命令前，通常仍需要你確認。它適合初次瞭解陌生倉庫、做程式碼審查、或者你希望全程掌控關鍵操作的時候使用。

2. Auto Edit
   這個模式通常允許 Codex 自動寫檔案，但在執行 shell 命令時仍會保留人工確認。它適合你已經比較瞭解專案結構，想讓 Codex 快速完成重構、批次改文件或區域性實現，但又不想完全放開命令執行權限的場景。

3. Full Auto
   這是自主性最高的模式。Codex 會在受限環境中自動讀取、寫入並執行命令，適合較長的連續任務，比如修復構建、跑一輪驗證或完成一個邊界明確的小功能。因為風險更高，最好只在版本可回退、任務範圍清晰、並且你理解當前沙盒邊界時使用。

怎麼選更穩妥

• 第一次進入新專案，優先從 Suggest 開始。
• 需要批次修改文件、樣式或測試時，可以考慮 Auto Edit。
• 只有在任務邊界明確、倉庫可回滾、並且你接受它連續執行命令時，再考慮 Full Auto。

使用時的提醒

• 不同客戶端可能不會把權限模式寫成完全一樣的中文名，建議優先認官方英文模式名。
• 即使使用更自動化的模式，也要保留對高風險操作的複核，比如安裝依賴、刪除檔案、訪問網路、推送程式碼或處理敏感資訊。
• 如果你不確定當前模式會不會執行某個動作，先讓 Codex 說明它準備執行哪些命令、會改哪些檔案，再決定是否繼續。

如果你在 App 中看到了和技能、外掛相關的入口，可以結合下面的概念來理解它們：

Skill 是什麼

Skill 可以理解為一份讓 Codex 穩定執行重複任務的操作手冊。當某個工作流已經很固定，例如“審查 PR”“整理文件”“補案例索引”，就可以把它沉澱成一個 Skill，減少每次重複描述的成本。

一個 Skill 通常會包含：

1. 一個 SKILL.md 檔案
   這裡會寫清觸發場景、執行步驟、輸出格式和注意事項。
2. 必要時配套指令碼、模板或參考檔案
   用來幫助 Codex 更穩定地完成任務。

常見使用方式是：

• 先準備或安裝可用的 Skill。
• 在發起任務時明確說明你希望使用哪個 Skill。
• 讓 Codex 按這個 Skill 的流程執行，再根據結果繼續追問或迭代。

有些工作區會提供更直接的安裝或啟用方式；也有一些場景裡，需要先把 Skill 放到約定目錄，或者透過現有外掛能力來分發。穩妥起見，不建議把“給一個 GitHub 連結就一定能自動安裝”寫成固定結論，更好的表述是：可以把 Skill 來源交給 Codex 協助識別和安裝，但具體流程會受客戶端能力和工作區設定影響。

Plugin 是什麼

Plugin 更像一種打包和分發機制，用來把可複用工作流、應用整合、MCP 服務設定等能力組合起來，方便在專案或團隊中統一安裝和使用。

簡單理解：

• Skill 關注“這件事應該怎麼做”。
• Plugin 關注“把哪些能力打包起來，方便安裝和複用”。

所以 Skill 往往是具體流程本身，而 Plugin 更像承載這些流程和整合能力的安裝單元。

怎麼理解它們的關係

你可以把兩者想成：

• Skill 是“工作說明書”
• Plugin 是“裝著說明書、工具和連線設定的工具箱”

有些外掛裡會包含一個或多個 Skills，也可能附帶應用整合或 MCP 設定。這樣團隊在遷移環境時，不用手動一個個設定。

使用時的提醒

• 外掛和技能的具體入口會隨版本變化，不要把某個截圖裡的按鈕位置當成永遠不變。
• 如果外掛涉及外部系統、瀏覽器、郵箱、知識庫或專案管理工具，先確認它是隻讀還是可寫。
• 涉及安裝、寫回外部系統或共享給團隊時，最好保留人工複核。

當一個工作流已經足夠穩定、而且會重複發生時，就可以考慮把它交給 Automation，在後臺按計劃觸發，而不是每次都手動發起。

適合自動化的任務包括：

• 定期檢查文件死鏈
• 每週整理一次 issue 或 PR 摘要
• 每天彙總 failing CI
• 在固定時間提醒補覆盤或更新文件

可以怎麼理解自動化

一個自動化任務通常至少會包含三部分：

1. 目標物件
   它對應哪個專案、倉庫或執行緒。
2. 觸發時機
   比如固定時間、固定間隔，或者稍後回到當前任務繼續跟進。
3. 執行內容
   也就是讓 Codex 到時具體去完成什麼。

常見使用流程

在支援 Automations 的介面裡，你通常會經歷類似下面的流程：

1. 選擇對應的專案、倉庫或當前執行緒。
2. 設定執行時間或執行週期。
3. 寫清楚自動化任務本身的目標、輸出格式和邊界。
4. 儲存後觀察第一次執行結果，再決定是否長期保留。

這裡最容易被忽略的一點是：自動化 prompt 要儘量寫成”自包含”的任務說明。不要預設它會記得你之前說過什麼，最好把檢查範圍、輸出格式和驗證要求寫完整。

❌ 不夠自包含的寫法：

請檢查一下文件裡的連結有沒有問題。

✅ 推薦的寫法：

請檢查 docs/ 目錄下所有 .md 檔案中的外部連結是否有效。

檢查範圍：僅檢查以 http:// 或 https:// 開頭的連結，忽略錨點和相對路徑。
輸出格式：按”檔案路徑 | 行號 | 連結 | 狀態”列出失效連結；全部正常時輸出”全部連結正常”。
驗證方式：對每個連結發起 HEAD 請求，超時 5 秒視為失效。
限制：不修改任何檔案，不建立新檔案。

兩者的區別在於：第一種每次觸發時 Codex 都要靠猜測來填補缺失的細節，結果容易不穩定；第二種把邊界、格式、驗證方式都寫明白了，無論在哪次執行、哪個上下文裡，行為都是一致可預期的。

使用時的提醒

• 不同工作區裡的自動化能力可能並不完全一樣，有些支援專案級任務，有些更偏向提醒和跟進。
• 第一次設定時，建議先從低風險、只讀型任務開始。
• 如果自動化會寫檔案、訪問外部系統或觸發通知，最好先確認權限邊界和人工複核方式。

這個寵物最大的價值在於狀態的視覺化：

1. 任務進度一目瞭然： 不用一直切換回 Codex 的介面，就能看到當前任務的進度。
2. 實時狀態反饋：
   • 它會在 Codex 忙碌的時候顯示忙碌的畫面。
   • 在需要你確認的時候會發出提醒。
   • 任務完成之後，它也會讓你知道可以去檢查結果了。

安裝前檢查

官方倉庫當前給出的 CLI 執行環境建議：

| 專案 | 建議 |
|

選擇第一個任務

適合新手：

• 修復一個文案錯別字。
• 給一個純函式補測試。
• 更新 README 裡的過期命令。
• 解釋一個小模組，並補充必要註釋。
• 修復一個已經有失敗測試覆蓋的 bug。

暫時避開：

• 大規模架構重構。
• 跨多個服務的遷移。
• 沒有測試的核心業務邏輯改動。
• 涉及生產憑據、帳單、權限和刪除資料的操作。
• 需要同時修改十幾個檔案的需求。

第一步：只讀建圖

先讓 Codex 理解倉庫：

請只讀分析當前倉庫，不要修改檔案。

請輸出：
1. 專案用途
2. 關鍵目錄
3. 安裝、測試、構建命令
4. 當前任務適合從哪裡開始
5. 你建議我第一次交給你的低風險任務

第二步：給出小任務

推薦複製這個模板：

請修復當前倉庫中最小範圍的一個測試失敗。

要求：
1. 先執行測試，確認失敗資訊。
2. 閱讀相關程式碼和測試，不做無關重構。
3. 修改最少必要檔案。
4. 修復後重新執行相關測試。
5. 最後總結：失敗原因、改了哪些檔案、驗證命令和剩餘風險。

如果任務是文件：

請更新 [文件檔案] 中關於 [主題] 的說明。

要求：
1. 先讀取相關官方資料和現有文件結構。
2. 保持中文教程風格，避免整段翻譯官方原文。
3. 涉及操作步驟時標出需要補圖的位置。
4. 修改後執行文件站構建。
5. 最後列出來源連結和需要人工補圖的位置。

第三步：觀察過程

重點觀察五件事：

| 觀察點 | 說明 |
|

最後核對

官方資料最後核對日期：2026-05-27。本章以 VS Code 為例演示外掛安裝與基本用法，操作介面以實際版本為準。

本章介紹如何在 VS Code 程式碼編輯器中安裝 Codex 外掛，並透過外掛完成開發任務。相比桌面 App，在 VS Code 中使用 Codex 可以更直接地看到檔案目錄結構和修改前後的對比，適合習慣在編輯器裡工作的開發者。

安裝 Codex 外掛

開啟 VS Code，點選左側邊欄的「擴充套件」圖示，在搜尋框中輸入 Codex，選擇第一個結果，點選「安裝」即可。

開啟外掛對話視窗

安裝完成後，在 VS Code 中開啟任意一個專案檔案，右上角會出現 ChatGPT 的圖示。點選該圖示，右側邊欄就會展開 Codex 的對話視窗。

開始使用

對話視窗開啟後，直接輸入需求，Codex 就會開始輔助完成開發任務，用法與 Codex 桌面 App 基本一致。

使用 @ 指定檔案：

在對話方塊中輸入 @ 後選擇具體檔案，Codex 會直接定位到該檔案進行分析或修改，比讓它全域性搜尋更快、更準確。建議在任務目標明確時優先使用 @ 指定相關檔案。

App 與 VS Code 外掛怎麼選

| | Codex 桌面 App | VS Code 外掛 |
|

所以 Codex 提供了記憶系統來解決這樣的問題

AGENTS.md 是給 Codex 這類編碼代理看的專案說明檔案。它可以描述專案結構、開發命令、測試要求、程式碼風格和協作邊界。

為什麼需要 AGENTS.md

沒有專案規則時，Codex 需要從倉庫裡推斷很多事情：

• 用哪個包管理器。
• 如何執行測試。
• 哪些目錄是生成物。
• 哪些檔案不能改。
• 提交前要跑哪些檢查。

AGENTS.md 能把這些規則顯式寫下來，減少反覆解釋。

建議放在倉庫哪裡

針對於我們開啟的專案，我們可以在專案根目錄下建立一個 AGENTS.md 的檔案。

它是 Codex 的記憶檔案，Codex 在開始工作之前會先讀取 AGENTS.md 的內容。我們可以測試一下：

1. 在 AGENTS.md 檔案裡面寫入一些內容。

1. 回到 Codex 對話視窗問它：“這是一個什麼樣的系統？”

從這裡可以看出，Codex 會讀取 AGENTS.md 檔案，把裡面的內容自動帶入到新的對話，作為它們的上下文。

當然，在當前目錄根目錄下建立 AGENTS.md 只對當前資料夾生效，並不是全域性生效的。

如果想要全域性生效，有以下兩種方式：

1. 在系統的全域性 Codex 資料夾裡面找到 AGENTS.md。
2. 在 Codex 桌面 App 裡面開啟設定，找到“個性化”，在其中填寫“自定義指令”。這裡面設定的就是全域性的 AGENTS.md 檔案。

設定全域性檔案後，對於所有的專案都會生效。所以它們的作用域和作用範圍是不一樣的，這一點大家需要了解一下。

推薦模板

# AGENTS.md

## 專案概覽

- 專案型別：
- 主要語言：
- 關鍵目錄：

## 常用命令

- 安裝依賴：`...`
- 本地開發：`...`
- 執行測試：`...`
- 型別檢查：`...`
- 格式化：`...`

## 程式碼規範

- 遵循現有程式碼風格。
- 不做無關重構。
- 新增功能必須補充或更新測試。

## 安全邊界

- 不讀取或提交 `.env`、金鑰和私有憑據。
- 不執行刪除生產資料的命令。
- 修改資料庫遷移前先說明影響。

## 交付要求

- 說明改動檔案。
- 說明驗證命令和結果。
- 說明未驗證項和剩餘風險。

寫作建議

• 越具體越好。執行測試：pnpm test 比“記得測試”有用。
• 把生成目錄、構建產物、鎖檔案策略寫清楚。
• 如果是 monorepo，請說明每個包的邊界。
• 如果有特殊 lint、格式化或程式碼生成流程，寫在命令區。
• 對安全敏感專案，單獨寫“禁止事項”。

最小可用版本

# AGENTS.md

## 專案命令

- 安裝依賴：`pnpm install`
- 本地開發：`pnpm dev`
- 構建：`pnpm build`

## 改動規則

- 修改前先閱讀相關檔案。
- 保持現有程式碼風格。
- 不提交構建產物和環境變數檔案。

## 驗證要求

- 文件改動執行：`pnpm build`
- 程式碼改動執行相關測試。

## 安全邊界

- 不讀取 `.env` 或任何私有憑據。
- 不執行釋出、部署、資料庫遷移和刪除資料命令。

你需要關心什麼

先把風險拆成幾個層面：

• 檔案系統：能讀寫哪些目錄。
• 網路：是否允許訪問外網。
• 命令：是否允許安裝依賴、啟動服務、跑遷移。
• 憑據：是否可能接觸金鑰、token、cookie。
• 資料：是否會修改資料庫、物件儲存或生產資源。

低風險任務

通常可以較快推進：

• 修改文件。
• 補充測試。
• 修復本地可復現 bug。
• 更新非敏感設定。
• 執行專案已有的測試命令。

高風險任務

建議先確認計劃：

• 刪除檔案或批次移動檔案。
• 資料庫遷移。
• 修改認證、權限、支付、帳單邏輯。
• 訪問生產服務。
• 上傳、下載或處理敏感資料。
• 引入新依賴或大規模升級依賴。

給 Codex 的安全提示詞

請在動手前先說明你計劃執行的命令和可能影響的檔案。不要讀取 `.env`、金鑰、token 或任何私有憑據。不要執行刪除資料、釋出、部署或遷移命令，除非我明確確認。

Codex 桌面 App 中的審核流程

在 Codex 桌面 App 裡，當 Codex 要執行寫入檔案、執行命令、訪問網路等敏感操作時，會暫停並彈出審核提示，列出它打算做的事。你可以：

• 放行：確認操作合理，繼續執行
• 拒絕：取消該步驟，Codex 會嘗試其他方案
• 修改提示詞：告訴它換一種方式做

這個機制在前面的實戰案例中多次出現——比如 Playwright MCP 操作瀏覽器時，每一步填寫輸入框、開啟網頁都需要手動放行。

養成習慣：不確定的操作先看清楚再放行，尤其是涉及刪除檔案、寫入設定或訪問外部服務的步驟。

團隊建議

• 在 AGENTS.md 寫清楚禁止事項。
• 把高風險命令放進人工審核流程。
• 給測試、lint、型別檢查提供明確命令。
• 避免把生產憑據放在普通開發環境裡。
• 對 Codex 產出的 PR 仍然執行正常程式碼審查。

Codex 找不到專案上下文

可能原因：

• 你不在專案根目錄。
• 倉庫缺少 README、測試命令或專案說明。
• monorepo 沒有說明包邊界。

處理方式：

• 先讓 Codex 只讀目錄並總結專案結構。
• 新增或更新 AGENTS.md。
• 在任務說明裡指定相關目錄。

Codex 改動範圍太大

處理方式：

• 明確“只修改這些檔案”。
• 要求“先輸出計劃，不要動手”。
• 把任務拆成更小的步驟。
• 在 review 時拒絕無關重構。

測試跑不起來

處理方式：

• 讓 Codex 先定位測試命令。
• 檢查依賴是否安裝。
• 區分環境問題和程式碼問題。
• 如果是環境問題，讓 Codex 記錄阻塞，而不是繼續亂改。

生成內容不準確

處理方式：

• 要求 Codex 引用它依據的檔案。
• 對官方事實要求附連結。
• 讓它區分“已確認”和“推測”。
• 讓它先讀程式碼再寫文件。

登入或權限問題

處理方式：

• 更新 Codex CLI 到最新版本。
• 重新執行登入流程。
• 檢查當前帳號計劃和組織策略。
• 檢視官方 Help Center 的 Codex 相關文章。

切換 provider 後舊會話不可見

可能原因：

• 修改過 config.toml 根級 model_provider。
• 舊會話檔案還在，但會話 metadata、SQLite 狀態或專案路徑快取仍指向舊 provider。
• CLI /resume 能看到舊會話，但 Codex Desktop 專案側看不到，可能只是 Desktop 最近 50 條會話的首屏顯示限制。

處理方式：

• 先確認 ~/.codex/sessions 或 ~/.codex/archived_sessions 裡是否還存在舊會話檔案。
• 如果只是 Desktop 專案側不可見，先判斷是否被最近 50 條顯示限制擋住。
• 如果確認是切換 provider 後 metadata 不一致，再參考 config.toml 裡的社群工具說明。
• 使用第三方工具前先備份 ~/.codex，不要把它當成官方認證或帳號切換工具。

桌面 App 適合什麼

• 本地倉庫中的長任務和多階段任務。
• 同時推進多個不互相阻塞的任務。
• 使用 Worktrees 隔離不同實現分支。
• 把重複流程寫成 Skills。
• 用 Automations 做提醒、定期檢查或後續跟進。
• 配合瀏覽器、文件、表格、簡報等外掛做跨工具工作。

核心能力地圖

| 能力 | 用途 | 學習重點 |
|

適用場景

• 連線 GitHub 倉庫後發起任務。
• 讓 Codex 閱讀倉庫並總結架構。
• 將 issue 轉成可執行任務。
• 生成 PR 摘要或變更說明。
• 面向非開發者解釋技術改動。
• 把複雜任務拆成階段計劃。

第一次任務怎麼寫

先讓 Codex 只讀分析：

請閱讀這個倉庫並幫我理解 [主題]。請先總結相關目錄和關鍵檔案，再給出執行建議。暫時不要修改程式碼。

進一步推進時：

請基於剛才的分析，完成第一步最小改動，並建立可審查的結果。請說明改動原因、驗證方式和剩餘風險。

適合非開發者的用法

| 場景 | 任務說明 |
|

CLI 能做什麼

• 只讀理解倉庫結構、入口、測試命令和風險點。
• 修改程式碼、文件、設定和測試。
• 執行 lint、typecheck、unit test、build 等驗證命令。
• 在終端裡檢視 diff、調整審核策略、恢復會話。
• 透過 codex exec 執行標準化的一次性任務。
• 配合 AGENTS.md、config.toml、Skills、MCP 構建長期工作流。

推薦學習順序

1. 安裝 CLI 並完成登入。
2. 在陌生倉庫中做一次只讀總結。
3. 學會互動模式中的常用 Slash Commands。
4. 完成一次低風險修改，並執行驗證。
5. 學會 codex exec，把可重複任務指令碼化。
6. 增加 AGENTS.md 和本地 config.toml。

互動模式

進入專案根目錄：

cd path/to/project
codex

第一輪建議不要直接讓 Codex 改程式碼。先讓它建立地圖：

請只讀分析當前倉庫，不要修改檔案。

請輸出：
1. 專案用途
2. 主要目錄和入口檔案
3. 安裝、啟動、測試、構建命令
4. 當前倉庫對 Codex 來說最需要注意的風險
5. 適合第一次交給 Codex 的 5 個低風險任務

非互動模式

codex exec 更適合批處理和自動化：

codex exec "請只讀分析當前倉庫，輸出安裝、測試和構建命令。不要修改檔案。"

建議讓輸出格式穩定：

請讀取當前倉庫，不要修改檔案。

輸出格式：
## 專案概覽
## 本地執行
## 測試命令
## CI 風險
## 適合 Codex 處理的任務

適合指令碼化的任務：

| 任務 | 產出 |
|

Cloud 適合什麼

• 連線 GitHub 倉庫後分派任務。
• 在後臺處理長時間修復、遷移或分析。
• 基於 issue 或需求生成分支和 PR。
• 團隊成員共同檢視任務進度。
• 為大型倉庫做結構分析和風險掃描。

提交任務前的清單

| 檢查項 | 為什麼重要 |
|

IDE 適合什麼

• 解釋當前檔案或選中程式碼。
• 為一個函式補測試。
• 區域性重構。
• 生成註釋、文件或型別說明。
• 審查當前 diff。
• 快速理解錯誤資訊和呼叫鏈。

選區任務寫法

選區越準確，結果越穩定。推薦模板：

請只基於當前選中的程式碼解釋：
1. 它在模組中的職責
2. 輸入輸出和副作用
3. 可能的邊界情況
4. 如果要補測試，建議覆蓋哪些場景

如果允許修改：

請只修改當前檔案和對應測試檔案。

目標：為當前函式補充邊界測試。
要求：
1. 先解釋測試場景。
2. 修改後執行相關測試。
3. 不做無關重構。

IDE 中的高頻任務

| 任務 | 推薦輸入 | 結果檢查 |
|

入口對照表

| 入口 | 更適合 | 典型任務 | 學習優先順序 |
|

方法地圖

| 主題 | 解決什麼問題 |
|

文件工作

適合任務：

• 把 README 改成新手友好的版本。
• 根據程式碼生成模組說明。
• 整理遷移指南。
• 生成釋出說明。
• 把 issue、PR、commit 整理成周報。

任務模板：

請閱讀當前倉庫的 README、docs 和 package 設定，幫我整理一份新手上手指南。

要求：
1. 不修改程式碼。
2. 命令必須來自倉庫真實設定。
3. 不確定的步驟標註為“待確認”。
4. 輸出目錄結構、安裝步驟、開發命令、測試命令和常見問題。

學習工作

適合任務：

• 讓 Codex 按學習順序解釋程式碼庫。
• 生成“從入口到核心模組”的閱讀路線。
• 把複雜模組講成產品、設計或運營也能理解的語言。
• 把陌生技術棧拆成學習清單。

任務模板：

請把這個倉庫當成學習材料。請按初學者閱讀順序講解：
1. 先看哪些檔案
2. 每個目錄承擔什麼職責
3. 關鍵資料流或呼叫鏈
4. 學完後可以做的 3 個練習

產品與運營工作

適合任務：

• 把 PR 改動翻譯成使用者影響。
• 生成釋出公告草稿。
• 檢查文案和功能說明是否一致。
• 從 issue 中提取使用者痛點。

任務模板：

請閱讀當前 diff，把技術改動整理成產品釋出說明。請包含：
1. 使用者能感知到的變化
2. 管理後臺或設定變化
3. 可能影響舊使用者的地方
4. 需要客服或運營同步的話術

知識管理

Codex 很適合把零散經驗沉澱成模板：

• 排障記錄。
• FAQ。
• 任務模板。
• 團隊規範。
• 案例覆盤。

最終目標是把“每次臨時問一次”變成“下一次直接複用”。

任務六要素

| 要素 | 寫法 | 示例 |
|

團隊接入清單

| 專案 | 建議 |
|

適用場景

• 讓 Codex 幫你在網頁裡搜尋資料。
• 讓 Codex 開啟某個站點並完成簡單點選流程。
• 在不離開當前工作區的前提下，把瀏覽器操作接入任務鏈路。

使用前先理解一件事

這裡說的“控制瀏覽器”，更準確地說，是讓 Codex 藉助瀏覽器或瀏覽器外掛能力去完成網頁互動。不同工作區裡，入口可能叫 Chrome、Browser，也可能表現為瀏覽器外掛或內建瀏覽能力。

因此，更穩妥的理解方式是：

1. 在當前工作區確認是否已經啟用了相關瀏覽器能力。
2. 如果是第一次使用，按介面引導完成瀏覽器側安裝或授權。
3. 安裝完成後，再在任務裡明確告訴 Codex 你想讓它做什麼。

一個常見流程

如果你的客戶端提供了 Chrome 相關外掛或瀏覽器能力，常見流程通常類似這樣：

1. 在 Codex 桌面 App 中找到對應的瀏覽器能力並啟用。
2. 按引導完成瀏覽器側的外掛安裝或連線設定。
3. 回到任務中，明確描述目標網頁、搜尋詞和預期輸出。

第一次點選後會跳轉到瀏覽器外掛安裝頁，點選新增擴充套件即可

任務示例

你可以像下面這樣給出一個明確任務：

請使用瀏覽器能力開啟 Bilibili，搜尋“RAG 知識庫 教程”，找一個適合新手入門的影片，並把標題和連結返回給我。

一個類似任務完成後，Codex 可能會：

1. 開啟目標站點。
2. 搜尋你提供的關鍵詞。
3. 進入相關結果頁。
4. 把它認為最合適的結果連結返回給你。

你要重點檢查什麼

• 它開啟的網站是不是你指定的那個站點。
• 搜尋詞有沒有被錯誤改寫。
• 點選結果後返回的是不是你真正需要的頁面，而不是廣告頁或無關頁。
• 如果涉及登入態、個人資料或付費後臺，是否會超出你願意授權的範圍。

風險提醒

• 瀏覽器相關能力通常比純文字任務權限更高，第一次使用時建議從只讀、低風險頁面開始。
• 不要直接讓 Codex 操作帶有支付、刪除、發帖、提交表單等高風險頁面，除非你準備全程複核。
• 如果教程依賴外掛安裝，未來介面名稱或入口位置可能變化，因此文件裡應優先描述“能力和流程”，而不是把某個按鈕位置寫死。

這篇案例面向醫護人員、研究生、規培醫生和醫學科研初學者，演示如何讓 Codex 幫你把一個醫學研究問題整理成可複核的文獻工作台。它不替你診斷患者，也不替你下治療決策；它只幫助你做研究輔助、資料整理和寫作準備。

適合什麼場景

• 準備綜述、開題報告或課題背景。
• 想把幾篇論文整理成證據表。
• 想檢查文獻總結裡有沒有過度推斷。
• 想把醫學問題轉成 PICO 或 PICOS 框架。
• 想給團隊留下可追蹤的文獻閱讀記錄。

不適合的場景：

• 讓 Codex 直接給某個患者診斷或治療方案。
• 讓 Codex 編造 PMID、DOI、指南或隨機對照試驗。
• 讓 Codex 處理未脫敏的真實病歷。
• 把模型輸出當成最終醫學結論。

推薦目錄結構

先在本地建一個小型資料夾，例如：

literature-review-demo/
├─ question.md
├─ papers/
│  ├─ paper-01.md
│  ├─ paper-02.md
│  └─ paper-03.md
├─ evidence-table.md
├─ gaps-and-risks.md
└─ summary-draft.md

每篇論文可以先放結構化筆記，不需要一開始就很完美：

# Paper 01

Title:
Year:
Study type:
Population:
Intervention or exposure:
Comparator:
Outcome:
Key result:
Limitations:
PMID or DOI:

第一步：把問題拆成 PICO

先在 question.md 寫下研究問題：

# Research question

在成人 2 型糖尿病患者中，連續葡萄糖監測是否能改善血糖控制和低血糖風險？

然後讓 Codex 幫你拆解：

請只讀取 question.md。

任務：
1. 把這個醫學研究問題拆成 PICO。
2. 標出哪些資訊還不明確。
3. 不要給臨床建議。
4. 輸出到 question.md 的 “PICO draft” 小節。

比較好的輸出應該像這樣：

| 元素 | 內容 | 需要補充 |
|

GitHub 開源倉庫

| 倉庫 | 作者 | 用途 | 相關案例 |
|

對有程式設計經驗的人來說，解決方法有很多——GitHub Pages、Vercel、Cloudflare Pages——但這些工具對普通使用者並不友好：什麼是分支？什麼是部署？什麼是域名解析？

本篇介紹一個對新手極其友好的工具：DKFile。

Draw.io 就是一個非常好的工具。它可以用來繪製：

1. 流程圖
2. 架構圖
3. 思維導圖
4. 系統設計圖
5. 業務流程圖
6. 技術路線圖

很多程式設計師、產品經理、架構師都會用它來表達複雜系統之間的關係。前段時間，Draw.io 官方釋出了自己的 MCP。

GitHub 地址：https://github.com/jgraph/drawio-mcp

本章節介紹如何使用 Codex 安裝、使用 Draw.io 的 MCP 工具，去繪製資訊圖或架構圖。

演示用的是一個購物車專案。

適合處理什麼

| 場景 | 可以交給 Codex 的任務 | 人工要確認 |
|

1. Remotion：使用 React 寫影片
2. HyperFrames：使用 HTML、CSS 或 JS 做影片

如果你想做一些輕量化的影片，比如網頁轉影片、文件轉影片等，那麼使用 HyperFrames 就是一個非常不錯的選擇。

當前案例概覽

| 型別 | 已收錄案例 | 適合學習什麼 |
|

前段時間，AI 領域的著名研究者 Andrej Karpathy 提出了一個新想法。他認為 RAG 的主要問題在於：每一次提問，模型都要從零開始重新發現知識。如果你問了一個需要綜合五篇文件的問題，RAG 會檢索、拼接、生成；如果你明天再問同樣的問題，它會重複整個過程，沒有任何積累，也沒有任何記憶。本來可以建立關聯的知識，卻在一次又一次的反覆查詢中被浪費掉了。

Karpathy 給出的解決方案是 LLM Wiki。他描述的系統分為三層：

1. 原始資料層 — 負責收集論文、文章、播客、網頁等素材。大模型對這一層只讀不改。
2. Wiki 層 — 大模型擁有這一層的完整所有權。它負責編寫 Markdown 檔案、目錄、摘要、實體概念、比較分析和綜述，建立頁面、更新頁面，並維護交叉引用。我們只需要負責閱讀。
3. Schema 層 — 一個設定檔案，例如對於 Codex 來說就是 AGENTS.md，對於 Cursor 來說就是 .cursorrules。告訴大模型這個 Wiki 的結構規範、命名約定和工作流程，並在使用過程中共同迭代這份檔案。

本篇介紹如何參考 Karpathy 的理念，在 Obsidian 裡藉助 Codex 搭建一套 LLM Wiki 知識庫。

內容創作者以前有一件很頭疼的事：給文章配圖。但自從 Codex 命令列可以直接呼叫 ChatGPT 最新的生圖模型 gpt-image-2 之後，我們就可以在 Obsidian 裡讓 Codex 根據文章內容自動生成配圖。

前提條件：

1. 瞭解 Obsidian 的基本操作
2. 熟悉 Codex 命令列的使用方式（參見本教程第二部分）

像 Codex 這類程式設計類的 Agent，不僅能夠編寫和修改程式碼，還能夠開啟網頁，像人一樣檢查頁面是否跑通。

本章節使用命令列的方式，來學習 MCP 的安裝和使用。

適用場景

• 你已經找到一個想用的社群 Skill。
• 你想讓 Codex 幫你完成安裝，而不是手動整理目錄和檔案。
• 你希望安裝後立刻用一個真實任務驗證它是否可用。

準備一個 Skill 來源

首先要有這個 Skill 的來源地址。很多開發者會把自己做好的 Skill 放在 GitHub 倉庫裡，供其他人安裝和複用。

這個案例裡使用的是一個社群 PPT Skill：

guizang-ppt-skill

第一步：安裝

你可以把 Skill 倉庫地址交給 Codex，請它協助識別並完成安裝流程。

例如：

請幫我安裝這個 Skill：https://github.com/op7418/guizang-ppt-skill
安裝完成後，告訴我它的用途、依賴要求，以及應該如何呼叫。

不同工作區裡，安裝方式可能不完全一樣。有些會直接支援安裝，有些則會先分析倉庫結構，再提示你確認放置位置或依賴要求。

第二步：呼叫使用

安裝完成後，可以直接讓 Codex 呼叫這個 Skill 去完成一項真實任務。

如果這個 Skill 已經提前安裝過，你通常也可以透過斜槓命令、技能選擇器，或者在任務裡明確點名的方式來呼叫它。

例如：

請使用剛剛安裝的 PPT Skill，根據“AI 程式設計工具入門”這個主題生成一份適合分享的演示稿。先告訴我還缺哪些關鍵資訊。

如果你沒有給足上下文，Codex 往往會先回到這個 Skill 的操作手冊裡，看看它需要什麼輸入，然後再向你追問必要資訊。

當你補齊背景、主題、受眾或風格要求後，它會按該 Skill 的流程去讀取 README、模板和相關文件，再生成結果。

如果這個 Skill 的預設產物是 HTML 演示稿，你通常可以直接在 Codex 內建瀏覽器裡開啟預覽。

你要重點檢查什麼

• Codex 安裝的是不是你指定的那個 Skill，而不是名稱相似的別的倉庫。
• 安裝後有沒有說明依賴要求、輸出格式和呼叫方式。
• 生成結果是否符合這個 Skill 原倉庫描述的能力邊界。
• 如果結果不理想，是 Skill 本身限制，還是你提供的輸入資訊不夠。

風險提醒

• 社群 Skill 不是官方能力，品質和維護狀態差異會很大，使用前最好先看倉庫 README。
• 不要預設“給出 GitHub 連結就一定能一步安裝成功”，有些 Skill 還會依賴額外指令碼、模板或本地環境。
• 第一次驗證時，優先選一個小任務，確認 Skill 能正常執行後，再拿去做正式產物。

你的程式碼跑在雲伺服器上，本地一行程式碼都沒有——Codex 照樣能幫你找到 Bug、修好它、跑通測試。這篇文章手把手帶你走一遍完整流程。

最後核對日期：2026-05-27。

自動檢查報告：官方資料自動檢查報告。

自動檢查只確認官方連結狀態與內容指紋是否變化；「最後核對日期」仍代表人工確認過內容。

OpenAI 官方

• Codex 產品頁：Codex 的產品定位、使用介面和團隊能力概覽。
• Codex in ChatGPT Help Center：計劃可用性、入口和常見問題。
• OpenAI Codex CLI Getting Started：CLI 入門、安裝和基礎能力。
• Codex 文件入口：Codex 桌面 App、CLI、Cloud、設定、安全、Skills、MCP 等官方文件入口。
• Codex cloud docs：雲端任務、GitHub 連線和倉庫工作流入口。
• Introducing Codex：Codex 釋出背景和雲端軟體工程代理介紹。
• Introducing the Codex app：Codex 桌面 App 相關介紹。
• Work with Codex from anywhere：ChatGPT 手機 App 中的 Codex 入口、跨裝置連線和可用性說明。
• Unrolling the Codex agent loop：Codex agent loop 背後的工作方式介紹。

官方文件重點頁面

• Codex App docs（桌面端）：桌面 App 功能入口，包含本地專案、Review、Automations、Worktrees、Local Environments、In-app Browser、Computer Use 等主題。
• Codex CLI features：CLI 互動模式、非互動模式、功能概覽。
• AGENTS.md：專案規則檔案的官方說明。
• Codex security：沙盒、審核和安全邊界。
• Codex config basic：基礎設定。
• Codex config advanced：高階設定。
• Codex config reference：完整設定參考。
• Codex skills：Skills 官方說明。
• Codex Cloud docs：雲端任務、環境、倉庫連線和任務執行入口。

GitHub 官方倉庫

• openai/codex：Codex CLI 開源倉庫。
• AGENTS.md 相關文件：專案規則檔案相關說明。
• CLI getting started：CLI 首次使用流程。
• Authentication：認證和登入相關說明。
• Exec：非互動模式相關說明。
• Slash Commands：CLI 會話命令說明。
• CLI 安裝與構建：系統要求、原始碼構建和日誌說明。
• CLI 設定：設定文件索引。
• Sandbox 文件：沙盒與審核官方入口。
• Exec Policy：命令執行策略相關說明。
• Skills：CLI 倉庫中的 Skills 文件。

如何使用這些資料

• 入門安裝優先看 Help Center 和 GitHub README。
• 瞭解產品邊界優先看 OpenAI Codex 產品頁。
• 做團隊接入時優先看 Help Center、平台文件、App 文件和企業相關說明。
• 寫教程時不要整段翻譯原文，應轉化成中文場景和可復現步驟。
• 涉及價格、計劃、模型、可用地區、功能開關、帳號權限時，必須開啟原文重新確認。

這份報告只代表官方連結可訪問與內容指紋是否變化，不代表文章內容已完成人工核對。文章內的「官方資料最後核對日期」仍需人工確認後再更新。

概覽

| 狀態 | 數量 |
|