12 · 一句話覆盤 Codex 全貌 · AI 程式設計教學中文版

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
決策鏈	decision chain	從入口到驗證把六件事串成的一條可複用判斷路徑。
全貌六件事	—	用好 Codex 的六個核心：入口、上下文、工具、邊界、驗證、團隊落地。
工作樹邊界	working tree scope	多人協作時不碰別人改動、每批只改少量檔案的約束。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你自測是否真的會用 Codex，並補上薄弱環節。

你是 Codex 掌握度自測顧問，幫我檢查是否真的會用 Codex，並指出該補的薄弱環節。

【角色】
你清楚用好 Codex 的全貌只有六件事——入口、上下文、工具、邊界、驗證、團隊落地，能透過幾個問題診斷我的真實掌握程度。

【輸入】
- 我通常怎麼給 Codex 任務：___
- 我會設定邊界（sandbox / approval）嗎：___
- 我怎麼驗證它做對了：___
- 我用過哪些入口和工具：___

【工作流程】
1. 對照六件事逐項評估我的掌握程度
2. 找出最薄弱的一兩環
3. 給針對性的補強動作
4. 給一句話判斷我是會用還是還在當玩具

【輸出規範】
▌一、六件事逐項判斷（會 / 半懂 / 不會）
▌二、最該補的薄弱環節
▌三、針對性補強動作
▌四、整體判斷 + 下一步

【硬約束】
- 診斷基於我的實際回答，不給通用評語
- 薄弱環節要給可執行補法，不只指出問題
- 不誇我也不打擊，務實判斷
- 邊界和驗證的短板要重點提醒（最容易出事）

學完 Codex，最好的檢驗不是記住多少名詞，而是能不能用一句話解釋它。

Codex 交付的是建議、diff 和驗證證據，不是免審結果。最後仍然要看 diff、看風險、看未驗證項。

What is Codex

回到 Codex 的基本定位。

CLI App IDE Cloud

根據任務選擇入口，而不是每個入口都亂用。

Team production

從個人使用升級到團隊可治理流程。

一句話

Codex 是一個 AI Coding Agent：它讀現場、改檔案、調工具、跑驗證、交結果。你的工作不是“讓它寫程式碼”，而是給它目標、上下文、邊界和驗證標準，然後審查它的交付。

全貌只有六件事

flowchart LR
    Goal["目標"] --> Context["上下文"]
    Context --> Tools["工具"]
    Tools --> Boundary["邊界"]
    Boundary --> Verify["驗證"]
    Verify --> Review["審查"]

第一，目標。你要讓 Codex 知道這次任務到底解決什麼問題，而不是隻說“最佳化一下”。

第二，上下文。Codex 需要專案檔案、AGENTS.md、設定、歷史對話、工具輸出和你補充的業務背景。

第三，工具。Codex 透過檔案讀寫、shell、瀏覽器、MCP、skills、subagents 和 hooks 進入真實工程現場。

第四，邊界。Sandbox 決定它能碰哪裡，approval 決定高風險動作是否需要你確認。

第五，驗證。測試、lint、diff、記錄、截圖、執行結果都屬於驗證證據。

第六，審查。Codex 完成後仍要 review，不要把最終回答當成事實完成。

你是否真的會用

能做到這些，才算開始工程化使用 Codex：

任務開始前說清目標、範圍和禁止事項。
讓 Codex 先理解專案，而不是一上來改程式碼。
根據風險選擇 CLI、IDE、App 或 Cloud。
能解釋 sandbox 和 approval 各自控制什麼。
知道什麼時候該用 MCP、Skill、Subagent、Hook。
完成後要求 diff、驗證結果、未驗證項和剩餘風險。

如果這些做不到，不是“不會用 Codex”，而是還沒有建立工程化使用習慣。

決策鏈

接到任何任務，按這條鏈走：

任務清楚嗎？不清楚就分診，先收集錯誤、現象、目標和驗收標準。
規則齊嗎？沒有專案規則就先讀或補 AGENTS.md。
入口對嗎？本地小改動用 CLI / IDE，長任務用 Cloud，團隊自動化用 codex exec 或 GitHub Action。
邊界畫了嗎？先 read-only，需要寫入再 workspace-write，危險操作必須審批。
需要外部工具嗎？需要文件、資料庫、內部 API，再接 MCP 或瀏覽器。
這是重複任務嗎？重複流程沉澱成 Skill，獨立探索交給 Subagent，必須執行的檢查交給 Hook。
可以驗證嗎？不能驗證就先補驗證方式，再執行。

最後才讓 Codex 執行，並要求它交驗證證據。

新手最少必要能力

你不需要一開始學完所有功能。

先選一個入口。IDE 適合邊看邊改，CLI 適合終端使用者，Cloud 適合非同步長任務。

寫一份 AGENTS.md。哪怕只有專案用途、啟動命令、測試命令、禁止事項，也比每次口頭解釋強。

預設用 workspace-write + on-request 或更保守的 read-only 起步。不要一上來全許可權。

每個任務先讓 Codex 讀現場，再讓它改。不要把“馬上動手”當效率。

每次結束都覆盤，把穩定經驗沉澱回 AGENTS.md、Skill 或 rules。

常見誤區

裝 4 個入口就算掌握。實際應先把一個入口用順。
配 10 個 MCP 就更強。工具越多，許可權和錯誤來源越多。
把 Subagent、Hook、Skill 一起上。真實重複問題出現後再加。
只看 Codex 最終回答。真正要看它讀了什麼、改了什麼、驗證了什麼、沒驗證什麼。
把 AGENTS.md 當文件。它是專案和 Agent 的協作介面，應該持續演進。

讀完應能回答

Codex 和普通聊天機器人的差別是什麼？
一次穩定任務為什麼需要目標、上下文、邊界和驗證？
AGENTS.md 應該寫什麼，不該寫什麼？
Sandbox 和 approval 分別防什麼風險？
App、IDE、CLI、Cloud 各適合什麼人和任務？
MCP、Skill、Subagent、Hook 各自解決什麼問題？
團隊要如何從個人使用升級到可審查、可追溯、可治理？

下一步

選一個真實小任務，不要選玩具 demo。

先讓 Codex 只讀理解專案，輸出專案用途、目錄結構、執行方式、風險和建議小任務。

再選一個範圍很小的改動，讓它修改、驗證、說明未驗證項。

最後把這次任務中你反覆提醒它的規則沉澱進 AGENTS.md。

學習閉環就是：任務、覆盤、沉澱、下一個任務。

12 · 一句話覆盤 Codex 全貌