Codex 最佳實踐（超長文）：先搞懂 AI，再用好 AI

### 你會學到什麼

很多人開始使用 AI 工具時，會很快遇到幾個問題：

• 明明模型很強，結果做出來的東西卻不穩定。
• 同一個任務，換一種說法以後效果差很多。
• 對話越長，AI 越容易跑偏。
• 工具功能很多，卻不知道該怎樣組織成自己的工作流。
• 看過很多零散教程，真正動手時仍然不知道從哪裡開始。

這門課會把這些問題放到一條完整的學習線上講清楚。課程從 Agent 和普通 AI 對話產品的差異開始，帶你理解 Codex 的定位、模型的選擇方法、上下文管理、對話習慣、內建工具、Skill 機制、自動化能力和實戰場景。

學習完這門課後，你會更清楚地知道：

• 什麼任務適合交給 AI Agent，什麼任務應該拆小。
• 怎樣表達需求，才能讓 AI 更穩定地完成任務。
• 怎樣管理上下文，減少越聊越亂的問題。
• 怎樣使用 Codex 的專案、話題、工具、Skill 和自動化能力。

前言

大家好，我是 oil 歐呦。

我在小紅書上分享 AI 程式開發和 Agent 使用的內容，就是一個普通的前端開發者。我從 2024 年開始接觸 AI 程式開發工具，到 2025 年完全轉成 Vibe Coding 的工作方式，再到現在把 AI Agent 融入到日常工作的方方面面。

這門課的內容來源於我過去一年多的實際使用經驗。不是從官方文件搬來的教程，也不是付費看別人課程之後的二手整理。裡面的每一個方法、每一個坑、每一個心得，都是我自己真實花了時間和錢跑出來的。文章會有點長，大家可以收藏後閱讀！

希望你看完之後能得到什麼

我不希望這門課只是教會你怎麼操作某一個軟體。

我希望你看完之後，能夠對整個 AI 的世界有一個高維度的理解。當你足夠了解 AI 之後，就可以主動過濾掉大量的垃圾資訊和販賣焦慮的內容，有自己的判斷。你能分清楚什麼是真正有價值的能力提升，什麼只是部落客的流量密碼。

更重要的是，你能把 AI 真正用到自己的工作和生活裡去。不管你是程式設計師、產品經理、設計師、自媒體、還是其他任何職業。Agent 能做的事情遠比寫程式多得多，只要你理解了它的能力邊界和正確的使用方式。

關於我

我沒有大廠背景，但在 AI 這個方向上的經歷還算豐富。

最開始我是做前端開發的。轉產品經理是因為我發現自己的興趣不在實作細節上，而是在「這個東西應該做成什麼樣」這件事上。後來 AI 出來了，我在工作中開始接觸 AI 程式開發工具，發現它能讓一個人做到以前一個團隊才能做的事情。這個認知促使我後來加入了一家做通用 AI Agent 的公司做產品經理。

之後我又在兩家 AI 新創做過產品和前端開發。在這些經歷裡，我接觸了 Agent 的設計、模型的選型、上下文的管理、MCP 的開發、SEO 的落地，這些都是實際工作中跑出來的經驗，不是看別人文章學的。

在做自媒體方面，我在小紅書做原創內容，一個多月時間做到了一萬多粉絲，幾乎每週更新四到五個影片。而且自媒體只是我的副業，所以我不需要特別在意數據，不需要講人云亦云的熱門話題，也不需要為了流量去散播焦慮。我只分享自己真正用過覺得好的東西，這也是為什麼我的內容幾乎全是原創。

產品方面，我自己 Vibe Coding 做過 Text-Well（AI 文字校正工具，三天從零到上線）、Wolfcha（AI 狼人殺遊戲，黑客松作品）、還有一個 AI 創作平台（兩個月把 SEO 日曝光從 500 做到 15000+）。

開源方面，我做了不少 Skill 和工具：draw-ui（UI 設計稿生成）、screen-studio-editor（影片剪輯+字幕）、codex-explore-skill（程式碼庫探索）、my-browser（本地瀏覽器自動化）、oiloil-ui-ux-guide（UI/UX 設計規範）等等。

這門課裡所有的內容，都是基於我自己實實在在用過、花過錢、踩過坑的經驗。希望它對你有用。

第 1 章：Agent 與普通 AI Chat 的差異

哈囉大家好，我是 Oil 歐呦，這是本課程的第一章。

其實我個人不太喜歡那種非常刻板的課程章節，先把一些很宏大、與實戰無關的立意強行解釋清楚，然後再一點點去分析裡面的細節。這種方式往往比較枯燥。

但我為什麼要在開頭先講解 Agent 的差異呢？因為很多人其實不太了解 Agent 和普通 AI 對話本質上的差別，也不清楚它們分別能夠完成什麼樣的事情。而弄清楚它們能夠做到什麼，是大家充分利用 AI 最重要的前提條件。

不同的人有不同的需求。從我個人的學習經歷和角度來看，我很多有趣的想法都是基於 Agent 能夠做到的事情，去想像它可以覆蓋我的哪些場景。我一般不先帶著問題再去琢磨 Agent 能不能解決，因為許多問題的解決方向有很多種。

比如給影片添加字幕這件事情，我最開始是使用剪映的，後面也嘗試過一些第三方的產品。再到後來，我突然發現使用 Agent 來處理這件事情可以達到高度客製化的效果。我必須首先了解 Agent 能夠幫我給影片添加字幕，並且理解它具體如何操作，我才能夠想到它在這個場景裡其實會比其他產品處理得更好。

從大家自己使用 Agent 的角度來看也是如此。我們理解了 Agent 可以處理哪些事情之後，自然而然就會聯想到，自己的某個工作場景是不是可以交給 Agent 來運行，或者它能不能幫自己提升工作效率。所以在開始之前，我先給大家講解一下 Agent 和普通 AI 對話的差異。

這裡我們先列舉一些常見的例子。大家平時可能經常聽到 通義千問、騰訊元寶、豆包、DeepSeek、ChatGPT、Gemini、OpenClaw、Claude Code、Codex 和 Cursor 這些產品。如果不了解 AI 的人，可能認為它們就是 AI 本身。但其實它們是不同廠商推出的產品，而且這裡面有一些屬於 AI 對話產品，有一些屬於 Agent 產品。很多人對它們的理解可能僅限於國內和國外的差異，下意識地覺得國外的產品比國內更好使用，比如認為 Claude Code 會比 豆包 更加強大。

為什麼這裡要強調是產品，因為產品和模型其實是兩回事。

其實這裡面最大的差異在於，它們有一些是 AI 對話產品，有一些是 Agent 產品。

像 通義千問、騰訊元寶、豆包、DeepSeek、ChatGPT、Gemini 都屬於 AI 對話產品。

網路上有些 AI 對話產品也支援聯網搜尋功能，但是它們和真正的 Agent 產品在能力上有著巨大的鴻溝。

AI 對話產品的聯網搜尋功能本質上是文字擷取。當我們輸入問題之後，它在後台透過搜尋引擎獲取一些網頁的內容摘要，然後在大模型的視窗裡進行資訊整理，把答案回覆在對話框裡。在這個過程裡，它無法與網頁進行互動，不能點擊網頁裡的各種按鈕，不能登入我們自己的帳號，更沒有辦法把獲取的資訊保存到我們電腦本地的資料夾裡。而 Agent 產品的聯網則是真正的控制和操作。它可以接管一個真實的瀏覽器，像人類一樣去模擬點擊、輸入、翻頁，甚至可以登入我們自己的帳號來執行操作，並且把獲取到的各種資料自動下載到本地。

而 OpenClaw、Claude Code、Codex、Cursor 這些產品都是 Agent 產品。

其中 Gemini 除了擁有 AI 對話產品，最近還推出了一個 Agent 產品叫做 Gemini Spark。而 Codex 與 ChatGPT 則都屬於 OpenAI 公司。

1.1 什麼是 AI Agent

大家平時應該都使用過 豆包，很多人可能習慣在手機上使用它。豆包 就是非常經典的 AI 對話產品。我們在對話框裡輸入一行問題，它在視窗裡回覆一段文字，這種一問一答的方式非常適合進行日常諮詢或者文字撰寫。

但是，如果我們想讓它幫我們去處理具體的電腦操作，就會發現它根本做不到。比如我們需要它把某個資料夾裡的所有圖片重新命名，它沒有辦法直接控制我們的電腦去修改檔名，只能給我們提供一段 Python 程式碼。我們必須自己把程式碼複製出來，新建檔案，自己在終端機裡執行。如果執行報錯了，我們還要把錯誤訊息複製回去向它提問。這中間需要手動進行大量的複製和貼上操作。

而 Agent 就是用來解決這種繁瑣步驟的。在使用 Agent 時，我們不需要自己去複製執行程式碼。我們只需要提供一個整體目標，它自己就會去進行任務拆分，選擇合適的工具，然後一步步運行到結束。

傳統的 AI 對話產品只是在瀏覽器視窗裡回覆文字，而 Agent 產品可以在終端機裡執行命令、修改檔案、甚至控制瀏覽器，直接幫我們把這些零碎的操作全部運行完畢。

在之前，大家對於 Agent 的定義其實並不明確，經常會把一些簡單的工作流也當作是 Agent 產品。Anthropic 官方之所以要特意編寫一篇文章，就是為了幫大家劃分清楚這個分類。而到了現在，大家對於 Agent 產品其實已經有了一個非常明確的定義，那就是可以自己去規劃行動以及呼叫工具的系統。

在官方的分類裡，系統被分成了工作流和 Agent 產品。

工作流是把大模型和各種工具用固定的程式碼串聯起來。比如我們編寫一段程式，第一步呼叫介面獲取資料，第二步翻譯文字，第三步保存到資料庫。在這個過程裡，大模型只是一個計算節點。模型自己沒有決定權，只能跟著程式設計好的路線運行。

Agent 產品則是把過程控制權完全交給了大模型，讓模型自己動態決定接下來的步驟和工具。比如我們分配給它一個修改 Bug 的目標。它會自己決定先使用搜尋工具尋找相關檔案，自己閱讀程式碼並定位問題，接著自己修改檔案，最後運行測試來驗證。如果測試報錯，它還會自己分析報錯原因並且重新修改，直到任務完成。

在整個過程裡，我們沒有給它設定死板的程式碼路線。每一步要使用什麼工具、接下來怎麼執行，全是由模型在運行中根據返回的實際結果自己決定的。這種擁有動態決定權的系統，才是我們所說的 Agent 產品。

1.2 普通 AI 對話產品的工作限制

當我們使用普通的 AI 對話產品時，往往會發現它的工作限制非常明顯。

除了前面提到的無法直接操作電腦之外，網頁版 AI 對話產品的上下文額度也是有限的。當我們對話時間長了，它就會忘記前面的對話內容。它也沒有辦法直接讀取我們電腦上的本地檔案，更沒有辦法知道我們本地的實際測試結果。

因為普通的 AI 對話產品本質上是一個靜態的沙盒環境，它和我們的本地電腦、真實的外部網際網路是徹底斷開的。它所有的輸出都只能停留在文字框裡，無法對真實世界產生任何回饋。

1.3 真實場景下的功能對比

為了讓大家更清晰地理解這兩種產品的差異，我們可以查看在具體生活場景裡，它們面對相同的問題時會產生怎樣不同的操作和結果。

場景一：整理旅遊攻略

我們要求它們查詢西湖、西溪濕地、靈隱寺的最新門票價格和開放時間，然後製作一個表格檔案放置到電腦桌面上。

• 普通 AI 對話產品：通常只能進行單次的聯網查詢。它會在後台透過搜尋引擎獲取這三個景點的相關網頁摘要，然後在聊天的文字框裡，為你繪製一個由字元拼接而成的排版表格，或者直接打包生成一個可以供你下載的表格檔案連結。但是，它沒有辦法直接打通你本地電腦的作業系統，無法直接將製作好的表格檔案寫進你的電腦桌面路徑裡。
• Agent 產品：可以自主利用瀏覽器自動化工具，逐個訪問景點的官方網站，主動點擊門票預訂或公告頁面，獲取到當天的最新資料。隨後它會直接呼叫你本地作業系統的檔案寫入介面，在你的電腦桌面上新建一個真正的表格檔案，將資料填寫並保存，完成後直接提示運行成功。

場景二：整理本地的照片

我們桌面上有一個叫做待整理照片的資料夾，裡面有一百張照片。我們需要把拍模糊了的照片以及重複的照片挑選並刪除，剩下的按照拍攝日期，新建不同的資料夾進行分類存放。

• 普通 AI 對話產品：直接告知我們無法存取本地電腦桌面，更沒有權限修改檔案。隨後它會提供一段長長的 Python 程式碼，讓我們自己去安裝執行環境、配置各種依賴庫。如果是不懂程式碼的非專業使用者，面對這些程式碼只會覺得無從下手。
• Agent 產品：直接讀取本地的資料夾。它自己呼叫圖像查看工具，逐張對比照片的清晰度和內容，挑出不合格的照片並移入垃圾桶。同時呼叫系統的檔案管理工具，建立具體日期的分類資料夾，把合格的照片自動移動進去。

場景三：製作每日工作簡報

我們希望每天早上九點鐘，自動去一些技術社群和社交平台收集關於大模型的熱門貼文，整理好標題和連結，透過辦公軟體發送給自己。

• 普通 AI 對話產品：表示自己無法在後台自發啟動，也無法控制其他軟體。它只能作為一個被動的工具，在我們主動傳送訊息提問時給予回覆。
• Agent 產品：可以利用其自身自帶的定時自動化運行機制（例如 Codex 的 Automation 自動化任務面板）。我們在產品裡直接為它配置好定時任務的目標和時間規則，它就會在每天早上九點鐘自動在後台啟動，控制瀏覽器並登入我們的社交帳號抓取貼文，整理完畢之後直接呼叫辦公軟體的發送介面，將簡報彈窗發送出來。

1.4 AI Agent 的自主循環與工具呼叫機制

Agent 能夠幫我們完成這些事情，是因為它的運行邏輯是一個自主循環。在學術上這個機制叫作 ReAct 循環，也就是思考、行動、觀察三個步驟的不斷重複。

我們可以透過重新命名圖片這個場景來理解。

• 思考：Agent 會先分析我們給它的整體任務，決定先查看資料夾裡有哪些檔案。
• 行動：它呼叫了檔案搜尋工具，去讀取資料夾的內容。
• 觀察：它看到了搜尋工具回傳的檔案列表，發現裡面有五張圖片。
• 思考：它根據拿到的圖片列表，決定呼叫檔案重新命名工具。
• 行動：它執行了重新命名工具，修改了檔名。
• 觀察：它確認重新命名工具回傳修改成功的訊息，確認任務已經完成。

在這個循環裡，最重要的就是工具呼叫機制。Agent 自己不具備修改檔案或者控制電腦的能力。它是透過呼叫我們提供給它的工具，比如執行終端機命令的工具、讀取檔案的工具，來間接控制電腦的。如果工具運行報錯了，它在觀察這一步會獲取報錯資訊，然後在下一步的思考中自己去尋找解決辦法，不需要我們去干預。

為什麼檔案系統和命令執行是 Agent 的核心

在所有 Agent 能呼叫的工具裡，有兩個是最基礎的：檔案讀寫和終端機命令執行。

為什麼這兩個這麼重要？因為我們電腦上幾乎所有的操作，最終都可以拆解成「讀寫檔案」和「執行命令」這兩件事。寫程式是在寫檔案，裝軟體是在執行命令，改設定是在寫檔案，跑測試是在執行命令，做表格是在寫檔案，壓縮圖片是在執行命令。

只要一個 Agent 擁有了檔案讀寫和命令執行這兩個能力，它理論上就能做我們在電腦上能做的任何事情。因為任何複雜的操作，都可以被它分解成一連串的檔案操作和命令執行。

這也解釋了一個趨勢：為什麼這些原本叫做 Coding Agent 的工具，都在慢慢變成通用 Agent。

從 Coding Agent 到通用 Agent

先說一下什麼是通用 Agent。

市面上的 Agent 產品其實有很多種。有些是專門做某一件事的，比如專門幫你寫郵件的、專門幫你做 PPT 的、專門幫你做數據分析的。這類 Agent 通常有一個固定的工作介面和預設的工作流，我們能做的事情被限定在它設計好的範圍內。

而通用 Agent 指的是沒有被限定在某個特定場景裡的 Agent。它有檔案系統的完整權限、能執行任意的終端機命令、能安裝和呼叫各種工具。我們給它什麼任務它就做什麼任務，不存在「這個功能我沒有」的限制。它的能力邊界取決於它能呼叫的工具有多少，而不是產品經理預設了哪些功能。

像 Codex、Claude Code、Cursor，它們最早都是給程式設計師寫程式用的。但是大家慢慢發現，寫程式無非就是在讀檔案、改檔案、跑命令。那幫我整理文件不也是讀檔案改檔案嗎？幫我做調研不也是執行一些搜尋命令嗎？幫我批量處理圖片不也是跑一些腳本嗎？

這些 Coding Agent 本來就有檔案系統的完整權限和命令執行的能力，它們天然就能做遠超寫程式以外的事情。只是最早的使用者群體是工程師，所以大家以為它只能寫程式。

OpenClaw 走的是另一條路。它從一開始就定位為通用 Agent，面向的不只是程式設計師。它可以接入微信、飛書這些即時通訊工具，在手機上就能控制電腦執行任務。它預設帶有記憶和人設系統，互動方式更像一個私人助理。

但如果我們看底層能力，OpenClaw 和 Codex 其實是一樣的東西：檔案讀寫 + 命令執行 + 瀏覽器控制 + 自主循環。只不過 OpenClaw 是從「通用助理」這個角度切入的，而 Codex 是從「程式設計工具」這個角度切入的。它們都在向同一個方向演化——成為一個能做任何事情的通用作業系統級別的 Agent。

Codex 現在加了桌面端、加了瀏覽器控制、加了 Computer Use、加了圖片生成、加了定時任務、加了手機端遠端控制。它已經不再只是一個程式設計工具了。而 OpenClaw 因為從一開始就不是為寫程式設計的，它本身不擅長處理複雜的程式設計任務。所以官方提供了一個叫 coding agent 的 Skill，它的作用就是當我們讓 OpenClaw 去寫程式的時候，它不會自己硬寫，而是去找我們電腦上裝的 Codex 或者 Claude Code，把程式設計任務委派給這些專業的程式設計 Agent 去執行。這本身就說明了不同 Agent 之間是可以協作分工的。

它們最終都會變成同一種東西：一個擁有完整系統權限的、能呼叫任意工具的、可以自主規劃執行任務的通用 Agent。只是入口不同、互動風格不同、擅長的場景不同。

理解這一點之後，我們在後面使用 Codex 的時候，就不要把它侷限在寫程式這一件事上。任何我們在電腦上做的事情，只要能被拆解成檔案操作和命令執行，都可以交給它。

常用模型選擇

在上一章裡，我們弄清楚了 Agent 產品和普通 AI 對話產品的本質差異。在這一章裡，我們來聊聊模型選擇。

很多剛接觸 AI 的人，經常會被各種名字搞糊塗。所以我們在挑選模型之前，先把三個概念搞清楚。

搞清楚模型、Agent 與 AI 產品的差別

我們經常聽到的一個名字，在不同的語境下，代表的其實是完全不同的東西。我們以 Google 公司的 Gemini 為例。

第一，AI 對話產品。這是我們在手機應用商店或者網頁上直接使用的軟體，有聊天輸入框和各種按鈕。我們平時說使用 Gemini 查個資料，指的就是它的 AI 對話產品。

第二，大語言模型。就是背後真正在思考的那個東西。我們透過軟體或者介面呼叫的 Gemini 3.5 Flash，就是大語言模型。模型本身沒有介面，它只是一個運行在雲端伺服器上的計算程式。

第三，Agent 產品。這是利用模型智慧、配上本地工具的自動化系統。比如 Google 官方推出的 Gemini Spark，或者我們本課程的主角 Codex。

為什麼我們要強調這個差異呢？因為我們在使用 Codex 或者 Cursor 這樣的 Agent 產品時，我們是在使用一個 Agent 的外殼，去挑選一個大語言模型作為它的智慧大腦。Agent 產品的運行上限，取決於你給它配置了什麼模型。

誰是目前最強的首選

目前在海外，最強的三家大模型廠商就是 OpenAI、Anthropic 和 Google。他們各自有自己最強的模型系列。

在之前，這三家廠商的實力很接近，很難說誰比誰強。但是截止到 2026 年 5 月底，最強的模型已經非常明確了，那就是 OpenAI 的 GPT-5.5 和 Anthropic 的 Claude Opus 4.7。在 Agent 的運行場景下，它們兩個是目前表現最好、最頂尖的模型。

在很長的一段時間內，GPT 和 Claude 系列都是大家進行 AI 程式開發和驅動 Agent 的首選。而我的實操經驗是，只要大家能夠使用這兩個模型，在日常開發和高難度任務中，就沒有太大必要去選擇其他差一些的模型。

我們來看看這三家模型各自的特點。它們都原生支援視覺辨識。

Claude 系列

Claude 系列的優勢是程式開發能力很強，需求理解能力也是三家裡最好的。當你向它描述一個稍微有些抽象或者複雜的業務邏輯時，它能比較準確地抓住你的真實意圖，寫出的程式碼邏輯比較嚴密。但是，它的缺點就是價格昂貴。無論是呼叫 API 介面的按量計費，還是各種高級訂閱方案，它的使用成本都是三家裡面最高的。

GPT 系列

GPT 系列的程式開發執行力也很強，但是在理解抽象需求的能力上，它會稍微遜色於 Claude。如果你給它的指令不夠具體，它有時會產生一些理解偏差。不過，它的優勢在於實際使用性價比很高。雖然從單次呼叫的模型單價來看它並不便宜，但是如果你訂閱了 ChatGPT Pro 或 ChatGPT Ultra 這樣的包月方案，在重度開發和高頻使用的場景下，折算下來的實際開銷會比 Claude 便宜非常多，用量額度也更加慷慨。

Gemini 系列

Gemini 系列在 Agent 場景下表現一般。工具呼叫成功率不高，邏輯規劃容易跑偏，不太適合當 Agent 的主力模型。最新的 Gemini 3.5 Flash 有一些改善，但跟前兩家比還是有差距。不過 Gemini 的優點是審美好，寫出來的文案和排版比較自然、有人氣，而且價格便宜。我一般把它用來做設計相關的事情。

這裡有一個很多人忽略的問題：如果你沒有使用過最強的模型，你很可能會對 AI 的表現感到不樂觀。

我平時接過許多付費諮詢。很多人在找我之前，都對 AI 究竟能不能幫他們把事情做好抱有很大的懷疑。當我詢問他們之前是如何操作時，他們通常會說，他們之前使用的是某個普通產品去做某件事情，結果發現 AI 給出的回答非常糟糕，或者在任務進行到一定深度時，模型的幻覺就變得很嚴重，甚至根本無法理解他們輸入的真實需求。

這其實是一個誤區。他們之所以覺得 AI 不行，很大程度上是因為從來沒有體驗過真正強的模型。用弱模型去跑複雜的 Agent 任務，效果自然不好。但如果換成 GPT-5.5 或者 Claude Opus 4.7，之前很多搞不定的問題就通了。

當然，除了模型本身的智慧之外，還有一個關鍵因素決定了任務的成敗，那就是不同 Agent 產品的 harness 能力。

harness 翻譯過來可以理解為馬鞍或者鞍具，在 Agent 場景下就是指這個工具套件和底層框架的設計能力。不同的 Agent 產品，它們的 harness 結構設計是略有差異的。哪怕呼叫完全相同的底層大語言模型，一個設計好的 Agent 框架，能透過更好的工具調度、上下文引導、以及運行時糾錯機制，把模型的智慧榨取到極限。而一個簡陋的框架，則會讓同一個模型高頻出錯。因此，我們在選好頂尖模型的同時，也需要配合一個設計得比較好的 Agent 產品。

什麼是多模態以及它的實際場景

我們在看模型規格表時，經常會看到單模態和多模態這兩個詞。

通俗地來解釋，模態（Modality）其實就是大模型和外部世界交流的感官通道。

傳統的單模態模型只有純文字這一條感官。它只能讀寫文字和程式碼，無法直接感知圖像和音訊資料。而多模態模型則相當於給大模型增加了視覺、聽覺和語音生成。它不僅能夠讀取純文字，還能直接看懂你傳送給它的圖片、影片，甚至直接分析音訊錄音。

在網頁端聊天時，多模態可能只是讓你能發一張表情包。但在 Agent 產品的執行循環裡，不同的模態結合具體的自動化工具，能夠直接幫你解決很多繁瑣的工作。

網頁設計和網頁還原的應用

在過去，我們如果想要 AI 幫我們編寫一個網頁，我們必須在對話框裡使用幾百個字，非常繁瑣地向它描述：左上角放一個灰白色的輸入框，右邊放一個深藍色的按鈕，背景需要帶有微弱的網格漸層。儘管費盡唇舌，單模態模型寫出來的介面往往很難看。

• 生成設計稿：我們可以直接呼叫 GPT Image 2 等生圖工具來做 UI 設計。這裡很多人可能會去網路上找各種生圖提示詞模板，其實沒必要。在 Agent 裡面，我們只要說一個大概的需求（比如「做一個簡約風格的 Dashboard 頁面」），AI 會自己寫合適的生圖提示詞。網路上那些特別長的英文提示詞，大多就是 AI 自己寫的，不是人手打的。另外生圖的時候給一張參考圖比純文字描述效果好很多，AI 能從參考圖裡提取風格、配色、佈局這些資訊，比我們用文字描述精確得多。還有一個技巧：如果你看到一張圖片想知道它的生圖提示詞是什麼，直接把圖片丟給任何一個支援圖片輸入的多模態模型，讓它幫你倒推提示詞就行了。
• 精準還原網頁：你可以將生成的這幾張設計圖，或者你在網路上看到的任何優秀網站截圖，直接傳送給擁有視覺能力的頂級模型（如 GPT-5.5、Claude Opus 4.7 或者是原生支援影片和超長圖像流識別的 Gemini 3.5 Flash）。它會掃描這張圖片，提取出頁面裡的顏色 HEX 代碼、容器圓角大小、文字行高和邊距，然後直接寫出還原度很高的 HTML 和 CSS 程式碼。這種從圖片直接寫成網頁的流程，單模態模型是做不到的。

字幕校對時的實際效果

我們在做影片製作或者字幕轉錄時，經常會遇到同音字轉譯錯誤的情況。比如我們在影片裡說的是程式開發工具 Claude Code，普通的語音辨識引擎在轉錄時，由於它只有聽覺這單一模態，往往會識別成 cloud call（雲端通話）。而頂級多模態模型（如 Claude Opus 4.7 原生支援長影片和關鍵幀感知）可以處理這個問題。

在 Agent 的自動剪輯工作流裡，它會採取兩個模態聯合工作的校對方式：

• 第一步，透過音訊轉譯生成初版字幕。
• 第二步，Agent 會在後台對你的影片畫面進行關鍵幀抽幀 OCR 掃描。模型會核對影片畫面裡電腦螢幕上出現的程式碼、網站標誌、或者是視窗標題。
• 第三步，模型會核對螢幕上顯示的 Claude Code，去校對音訊聽到的同音字 cloud call。一旦發現兩者不一致，它就會結合上下文，自動將錯漏的字幕修正為準確的專有名詞，並且自動處理首字母大寫。這種利用視覺糾正聽覺的視聽聯合校對，就是多模態在實際生產場景下的用法。

原生多模態和插件多模態的差異

這裡大家也需要注意一個細節，那就是原生多模態和插件多模態的效能差距。

很多國產模型和部分開源模型在呼叫 API 介面時，本身是不直接支援圖像和音訊資料輸入的。它們想要處理圖片，必須依賴 Agent 框架在本地配置臨時的 ASR 或 OCR 插件進行中轉。這種臨時拼接的模態呼叫速度慢，而且經常因為圖片背景複雜而發生報錯。

而像 OpenAI 的 GPT-5.5、Anthropic 的 Claude Opus 4.7 或者是 Google 的 Gemini 3.5 Flash，都是在底層演算法上直接支援多模態原生輸入的。在執行高頻、複雜的自動化瀏覽器控制任務時，原生多模態模型幾乎是唯一的選擇。

挑選 Agent 模型需要看重什麼

我們在網頁上跟 AI 聊天，通常只看它回答得聰不聰明。但如果放到 Agent 裡去執行任務，評估標準就不一樣了。根據我自己的使用經驗，適合 Agent 的模型要看這幾個方面。

彙報時的交流感

在 Agent 運行中，模型需要頻繁地向你彙報它準備運行什麼指令、修改什麼檔案，並且向你申請執行權限。如果模型的回覆非常生硬和晦澀，使用複雜的話去解釋簡單的問題，你就會很難看懂它的方案，從而無法建立信任感。

比如早期的 GPT-5.4 在這方面問題就比較明顯，方案寫得很複雜。而最新的 GPT-5.5 在日常交流方面就改進得很好，基本都是通俗的大白話。相反，Claude Opus 4.7 雖然程式開發能力得到了提升，但是說話的語氣比 4.6 版本要稍微生硬和機械了一些，犧牲了一點日常交流的溫度。

上下文被多次壓縮後的聽話程度

Agent 產品在連續執行長任務時，上下文會迅速增加。當上下文達到一定長度，Agent 產品會自動運行壓縮機制，把之前的對話和工具執行記錄進行精簡。

在上下文被多次壓縮之後，很多普通的模型就會開始出現失憶或者偷懶的情況，容易亂改之前已經定好的程式碼方案。在這方面，GPT-5.5 的指令遵循度表現非常強，即使在長任務和頻繁壓縮之後，依然能夠嚴格遵守之前的指令。

修改大檔案的穩定性

Agent 產品需要高頻地對我們本地的檔案進行修改。它通常會先讀取一個檔案，然後透過搜尋與替換其中的一段程式碼來完成修改。

如果模型在這方面不夠穩定，它在編輯幾十行的小檔案時可能沒有問題，但在編輯幾百行的大檔案時，就容易發生替換失敗，甚至會自作主張地刪掉不相關的程式碼。

在本地檔案編輯的穩定性上，Claude Sonnet 4.6 以及 Claude Opus 4.7 表現很好。而國產的 MiniMax 2.7 雖然運行速度很快，長上下文理解也不錯，但在利用 Agent 修改大型檔案時，經常會發生定位失敗，或者導致大段程式碼重寫遺失。

實際開發中的開銷決策

我們在考慮模型開銷時，千萬不要只盯著模型介面（API）的價格表去計算成本。在實際使用 Agent 產品開發時，計費方式和使用場景才是決定你帳單支出的關鍵。

包月訂閱往往比介面計費更划算

在 Agent 產品的 ReAct 運行循環裡，模型每一次去執行工具或者查看檔案，都需要把之前所有的會話歷史、專案程式碼結構全部作為上下文重新讀取一遍。這會導致每一次對話消耗的 Token 數量以指數級迅速飆升。

如果我們完全使用介面（API）按量計費，遇到複雜的開發任務，隨便修改和除錯幾次功能，可能就會產生幾美元甚至十幾美元的開銷，這會讓你在編寫時非常心痛、畏手畏腳。

我的經驗是，只要大家在日常重度開發，能夠選擇「包月訂閱」就絕不要選擇「API 計費」。比如訂閱了 200 美元的 ChatGPT Ultra 升級包月方案，在 Cursor 或者 Windsurf 裡使用 GPT-5.5 或者 Codex 運行高難度的程式開發，無論你怎麼高頻提問和重寫檔案，每月的支出都是固定封頂的。這樣就不用每次寫程式的時候還在心裡算錢了，讓你能夠全神貫注地去解決具體的業務。

透過子 Agent 分發降低 API 成本

如果因為團隊協作或者軟體本身的限制，我們必須呼叫介面（API）計費（比如使用 Claude Code 自動運行複雜的建置），我們可以透過主輔模型組合的設計來大幅度降低費用：

• 頂級高智慧模型只用來編寫開發方案：我們在主視窗裡讓它設計修改方案。由於它不需要具體去運行檔案改寫，它在主會話裡的輪次就會非常少，上下文很乾淨，所以整體費用非常低。
• 低開銷的輔模型作為子 Agent 去具體修改檔案：主 Agent 將寫好的確定方案傳遞給子 Agent。子 Agent 在後台執行高頻的檔案讀取、修改、重試、測試報錯以及重新編譯。雖然這個過程會產生大量的 Token 消耗，但由於輔助模型的單價很低（通常是頂級模型的十分之一甚至更低），最終的總開支會低很多。

視具體場景挑選高性價比模型

不同模型的長處不同，大家需要根據具體的任務類型來進行精準調度，避免大材小用：

• 寫程式與設計還原：如果我們需要寫一些好看的頁面排版、設計 UI 佈局、或者撰寫大白話的營運文案，可以直接呼叫 Gemini 3.5 Flash。它生成 Token 的速度很快，價格很便宜，且天生具備非常好的審美和文案風格，完全沒有必要在這些任務上消耗昂貴的 Claude 額度。

關於模型生成 Token 的速度，業界裡一般會使用 TPS（Tokens Per Second）這個指標來衡量，也就是大模型每秒鐘能夠輸出多少個 Token。

大家在用不同的模型時，對 TPS 的直觀體感是完全不同的。如果一個模型的 TPS 在 50 以下，你會覺得輸出很慢，程式碼和文字像是在斷斷續續地往外蹦。而 Gemini 3.5 Flash 或者是 GPT-5.4 mini 這種輕量模型的 TPS 通常可以達到 150 到 200 以上。

這種高 TPS 的生成速度，在實際使用中非常有優勢。比如有些網頁展示或者小遊戲的需求，使用者是不想等待太長時間的。高 TPS 能夠做到讓一整頁 React 程式碼在一兩秒鐘內刷地一下全部生成並呈現在螢幕上，等待時間會短很多。如果在終端機運行大型重構，高 TPS 的子 Agent 也能很快把檔案改完，避免你合上電腦乾等。

另外，大家可能還會看到一個叫做 TTFT（Time to First Token，首字回應時間）的參數，也就是你傳送指令後，模型需要等待多少毫秒才會吐出第一個字。通常輕量模型反應很快，首字等待時間只有一兩百毫秒；而開啟深度思考的推理模型，首字等待時間可能需要十幾秒。在挑選模型時，我們也要把這兩個速度維度考慮進去。

• 運行單點修改和報錯排查：這幾款優秀的國產模型（GLM-5.1、MiniMax 2.7、DeepSeek V4 Pro）在中英文多任務和常規程式碼執行中的表現都非常好。但大家需要有一個清晰的預期，當任務複雜度很高、或者上下文達到幾十萬 token 的時候，它們相較於 GPT-5.5 和 Claude Opus 4.7 依然更容易產生定位失效和規劃跑偏。所以，我更推薦讓它們在子 Agent 機制下，去具體運行那些已經確定好的單點修改、腳本執行或者常規報錯排查，這能幫你省下大量的開發預算。
• 大專案重構與老舊系統維護：如果你的任務涉及複雜的程式碼依賴重構，或者排查非常隱蔽的記憶體洩漏，千萬不要為了省錢而使用低配模型。在這種高難度任務下，低配模型因為邏輯規劃不完善，經常會陷入修改錯誤、報錯、重新修改失敗的死循環，最終反覆累計消耗大量 token。你以為省了錢，結果最終產生的帳單開銷反而比直接使用 GPT-5.5 或 Claude Opus 4.7 一次性修改成功還要昂貴。

我的模型組合演變過程

我平時寫程式基本全是 Vibe Coding，自己不動手改檔案，全靠跟 Agent 說話讓它去執行。用了一段時間之後，我的模型組合經歷了一次比較大的變化。

在過去，我習慣使用多模型異構的組合：

• 產品經理：使用 Claude Opus 4.6。因為它的需求理解能力很強，交流感好，程式碼設計能力也出色。
• 日常執行者：使用 GPT-5.3 Codex。因為它的介面呼叫價格非常便宜，我讓 Claude 把各種需要機械化運行的零碎開發任務，透過子 Agent 派發給 Codex 去執行。
• 設計師：使用 Gemini 3.1 Pro。因為 Claude 和 Codex 在視覺設計上的審美比較單一，而 Gemini 能夠根據簡單的需求，設計出質感非常好的介面。

現在我已經不用這種多模型的搭配了，直接 All-in-One：現在我完全使用 Codex 加上 GPT-5.5 運行日常所有的開發任務。

一方面是 GPT-5.5 修了之前說話晦澀的問題，交流感和程式開發能力都不錯了。另一方面，我訂閱了 200 美元的 ChatGPT Ultra 套餐，額度很夠用，每天重度開發也花不完，性價比比 Claude 高很多。

至於設計審美的短板，我已經透過自己開源的 draw AI 插件，配合 GPT Image 2 進行 AI 生圖來直接設計介面，然後再讓 Codex 將設計圖還原為 HTML 寫入專案裡，把設計這個環節也覆蓋了。

Codex 的介紹與定位

在上一章裡，我們詳細討論了如何選擇適合 Agent 的大語言模型。在這一章裡，我們來討論本課程的核心主角：Codex。

很多人在接觸命令列 Agent 的時候，第一個想到的往往是 Anthropic 推出的 Claude Code。

在以前的很長一段時間裡，Claude Code 幾乎是所有人公認最頂尖、最成熟的 Agent 產品。因為 Anthropic 這個公司在 Agent 的設計和工程落地方面積累了很多經驗。他們很早就發布了一系列品質很高的研究文章，包括如何設計工具（Tools）、如何利用漸進式載入去設計 Skill 機制，以及如何高效地去管理上下文空間。

在我的實際開發和學習過程中，這些文章對我來說是必讀的參考。再加上 Claude 本身程式開發推理和需求理解能力很強，Claude Code 在很長一段時間內，基本沒有其他產品能達到它的水準。

既然 Claude Code 這麼強，那為什麼 OpenAI 後來推出的 Codex 會吸引我，並且逐漸成為了我的日常主力呢？這裡其實有一個非常重要的產業背景。

在之前很長的一段時間裡，OpenAI 並沒有把全部的精力放在 Codex 上面。他們當時更傾向於去做一些覆蓋面非常廣泛的多媒體 AI 應用，比如備受關注的影片生成模型 Sora 這一類。這導致在 Agent 領域，OpenAI 被早早深耕此處的 Anthropic 搶佔了先機。

後來競爭格局變了。2026 年 3 月底 OpenAI 關掉了 Sora 影片應用和 API，戰略重心轉向了程式碼生成和 Agent 方向。

為了應對 Anthropic 的強力競爭，OpenAI 開始在 Codex 上全面發力。調配了頂級的算力來支援 Codex 的迭代，在 2026 年上半年高頻更新，推出了多端聯動的桌面端和更強大的底層執行模型。這也是為什麼 Codex 最近的能力提升很快，並且開始在開發效率上追上 Claude Code。

我們先從 Codex 現在的具體形態說起。

什麼是 Codex

其實，Codex 就是一個運行在本地專案裡的工具。它的作用就是用來幫我們執行一些具體的編碼任務、運行本地編譯或者進行自動測試。

在最底層的設計上，它使用 Rust 語言進行了重構和編寫，所以它在我們的終端機裡冷啟動時非常快，掃描大專案目錄、查找裡面的程式碼方法和定義時，幾乎感受不到任何延遲，本地記憶體的占用也特別微小。

如果你習慣了使用普通的 AI 對話視窗，你可能覺得它只是一個寫完程式碼讓你自己去複製貼上的對話框。但如果我們使用 Codex，我們把它啟動在某個專案目錄裡，它就能夠直接和我們的本地系統進行檔案級別的互動，自己把程式碼寫好並且編譯運行，幫我們完成那些原本需要手動運行很多步的繁瑣工作。

它們其實幾乎沒有差異

作為目前市面上最強大的兩個終端機 AI Agent 產品，大家經常喜歡把 Codex 和 Claude Code 拿來進行全面比較。

但是在我的實際使用體驗中，它們兩個在日常開發的使用體感上，其實幾乎沒有任何差異。

首先，它們的核心互動流程和節奏是完全一致的。它們都是在本地命令列終端機裡運行。當你敲下啟動命令後，都會進入一個流式的黑乎乎的終端機互動面板。當你輸入一個開發需求，它們都會自主去掃描專案目錄、讀取本地檔案、在後台執行測試和編譯。在它們準備進行任何程式碼修改或者運行敏感的終端機指令之前，都會在螢幕上彈出一個確認提示，等待你按下 Enter 鍵進行授權。

其次，在核心功能上，它們也是完全相通的。它們都無縫支援 /goal 等非同步長期執行任務的命令。它們在長對話下也都會自動觸發上下文的壓縮機制，都支援接入 MCP 協議來擴充工具，也都支援透過撰寫客製化的 Skill 來固定日常的重複工作流。

你只要學會了其中任何一個工具的使用方法，在切換到另一個工具時，基本不需要承擔任何額外的學習和適應成本。

它們唯一的微小差異，僅僅體現在背後的模型品牌、外殼的封裝形式、以及國內使用者的帳號安全穩定性上：

• 模型生態：Claude Code 預設綁定 Anthropic 官方的 Claude 系列模型。而 Codex 則是 OpenAI 旗下的產品，預設使用 GPT 系列模型。
• 產品形態：Claude Code 目前依然是一個純粹運行在終端機命令列裡的工具。而 Codex 除了命令列工具之外，OpenAI 官方還為它封裝了更方便管理多個並行開發任務的桌面端應用，以及多端聯動的手機端。
• 帳號安全性：這是一個對國內使用者來說非常現實的痛點。Anthropic 的風控機制很嚴，甚至可以說對國內 IP 存在明顯的地域限制，大面積封禁國內關聯的帳戶，很多人剛儲值了訂閱會員或者綁定了虛擬卡，幾秒鐘內就會被無預警封號。這導致使用 Claude Code 經常面臨很高的斷線和封號風險。相比之下，OpenAI 針對中國使用者的常規網路存取和充值的風控邏輯要寬容、穩定得多，使用起來很少會遇到動輒封號的糟心情況。

跟 OpenClaw 的差異在哪

很多人可能還會問到另一個最近很紅的工具：OpenClaw。

OpenClaw 和 Claude Code / Codex 能做到的事情其實是一樣的。它們都有檔案操作、執行腳本、瀏覽器控制、聯網搜尋這些核心能力。OpenClaw 能做到的事情，Claude Code 都能做到；反過來也一樣。

但是它們在產品設計上的取向是不同的。

OpenClaw 最方便的地方在於，它可以很輕鬆地配置到我們的飛書、微信、Telegram 上面。我們在手機上就能跟它對話，遠端控制電腦去執行任務，完全不用坐在電腦前面。它還預設帶有 Memory 和 Soul 系統，會不斷把我們對話中的資訊記到它的記憶裡去，還會完善自己的人設。

而 Claude Code 是一個專注於寫程式的工具。它有 Task 拆解、Worktree 分隔、LSP 語意導航這些對工程師來說很實用的能力。大部分人使用 Claude Code 的時候，不會去開啟什麼複雜的記憶系統，因為程式碼倉庫本身就是它的記憶。它要做的事情就是跟寫程式有關的，讀現有的程式碼就能知道專案是做什麼的，有什麼規範、什麼設計風格。上下文保持乾淨，執行任務的效果就會更好。

這裡有一個我自己的觀察：OpenClaw 帶著記憶帶著靈魂，有一定的情緒價值，但它在嚴肅處理工作任務的時候，效果是不如 Claude Code 這一類程式設計工具的。因為你想要呼叫 Agent 去執行任務，它的上下文越短、品質越高越好。一大堆跟當前任務無關的記憶塞在上下文裡面，反而影響了它的執行能力。

不過它們之間並不是非此即彼的關係。我自己就是同時在用的。OpenClaw 官方甚至提供了一個叫做 coding agent 的 Skill，意思就是如果我們讓 OpenClaw 去寫程式，它會自己去找我們電腦裡有沒有裝 Codex 或者 Claude Code，然後把程式設計任務委託過去。它們是有分工的：OpenClaw 像一個小愛同學，負責一些輕量的待辦管理、檔案整理、資訊抓取、手機遠端控制；而 Codex 或 Claude Code 負責複雜程式設計、架構設計、長流程的工程任務。

我為什麼選擇使用 Codex

其實不同的 Agent 產品之間差別沒有想像中那麼大。我選 Codex 主要就是因為它搭配 GPT-5.5 的整體效果不錯。

一方面，在日常高強度的開發之下，我訂閱了 ChatGPT Pro 包月方案，額度高得根本用不完。相比於處處受限、或者很貴的 API 按量扣費，這種不限額度、能夠讓我隨便折騰、隨便試錯，用起來非常爽。

另一方面，GPT-5.5 在圖片生成模態上的表現很好。它無縫支援官方最新的 GPT Image 2 圖片生成工具。我們在日常使用時，甚至可以直接在會話裡透過生圖的方式來幫助我們進行 UI 介面或者是創意資產的設計和迭代。

Cursor 作為替代入口

這裡補充一個現實問題。Codex 要用的話，我們得訂閱 ChatGPT Pro，這需要有美區的手機號或者信用卡才能完成付款。Claude Code 也一樣，Anthropic 的訂閱對國內使用者來說門檻更高，還有封號風險。很多人卡在這一步就上不去了。

如果你暫時買不到 GPT 的直接訂閱，沒有美區手機號，或者沒有信用卡，又想快速體驗多個頂尖模型搭配 Agent 的效果，可以去用 Cursor。

Cursor 的好處在於：

它是一個桌面應用，下載安裝的門檻很低。裡面所有的設定（Plugin、Rules、Skill、MCP）都是可視化的，有地方可以點，不用去終端機裡敲斜線命令。

它聚合了目前最強的幾個模型。GPT-5.4、Claude Sonnet、Opus、Gemini 3.1 Pro，這些模型都在裡面，你可以自己選擇使用。

它不跟單一的模型廠商綁定。用 Codex 的話我只能用 GPT，用 Claude Code 的話我只能用 Claude。但 Cursor 裡面既有海外的頂尖模型，也有國內的一些模型，我們可以自由切換，比較哪個效果好。

當然 Cursor 也需要翻牆和訂閱（20 美元），但比起自己去搞美區帳號、綁虛擬卡、配 API Key 那一套流程，簡單很多。如果你的支付問題解決了，能直接訂閱 ChatGPT Pro，那還是建議直接用 Codex，體驗會更完整。

在下一章裡，我們將正式開始搭建 Codex 的運行環境，並且詳細拆解它的設定檔。

安裝與基礎配置

在決定使用 Codex 之前，我們需要先準備好本地的運行環境，並且在軟體裡登入帳號、完成基礎的參數設定。

我們需要準備的運行環境

因為我們在讓 Agent 編寫程式碼或者運行日常任務時，往往需要使用到各種外部依賴，所以建議在電腦上先安裝好以下兩個最基礎的環境工具。

一是 Node.js 環境。建議直接安裝最新的 LTS 穩定版本。因為我們後續透過 MCP 協議去載入和管理各種外部工具、發布插件時，大部分底層腳本都需要依賴 Node.js 運行環境。 二是 Git 工具。因為 Agent 在自動進行程式碼修改和 /goal 長期任務時，需要自動在本地進行程式碼差異比對、新分支的切分和程式碼提交，所以本地的 Git 命令列環境是必不可少的。

如何下載和安裝桌面端

我們這套課程完全不需要、也完全不推薦大家直接去黑乎乎的終端機命令列裡敲命令。我們所有的任務和管理，全部直接在官方提供的、可視化的桌面端軟體裡完成：

• macOS 使用者：直接訪問 Codex 官方桌面端頁面 進行下載安裝。如果你的 Mac 是蘋果 M 系列晶片，選擇 Apple Silicon 硬體版本；如果還是早期的 Intel 晶片，選擇 Intel 版本即可。
• Windows 使用者：直接訪問 Windows Microsoft Store Codex 頁面 進行一鍵下載安裝。

安裝完畢之後，直接雙擊打開軟體就行了。

Windows 使用者注意：Codex 在 Windows 上支援原生的 PowerShell 沙盒，不需要裝 WSL 或虛擬機。但如果你的專案依賴 Unix 命令（比如 sed、grep 這些），可能還是需要配一下 Git Bash 或者 WSL。大部分日常使用不會遇到問題。

打開之後左側是導覽列：New chat（新對話）、Search（搜尋歷史）、Plugins（插件和 Skill）、Automations（自動化任務）。中間是對話區域。底部是輸入框，我們所有跟 Agent 的互動都從這裡開始。

登入我們的帳號

當你第一次打開 Codex 桌面端應用時，在介面上直接點擊登入。系統會自動在你的預設網頁瀏覽器裡彈出一個登入頁面，你只需要直接登入你已有的 ChatGPT Plus 或者是 ChatGPT Pro 訂閱帳號進行授權即可。

需要提醒的是，官方目前雖然還支援 OpenAI API 金鑰（即輸入 sk- 開頭的金鑰）進行單獨的 Token 扣費，但如果是重度開發，高頻的上下文讀取會導致 API 的扣費速度很快，沒用幾天可能幾十美元就花出去了。因此我最推薦的方式就是直接登入已經訂閱的 ChatGPT Plus 或者是 ChatGPT Pro 帳號，直接使用訂閱內包含的可用額度，這會幫我們節省很多開發成本，也完全不用承擔多餘的帳單焦慮。

設定檔 config.toml 的修改入口

完成了帳號的登入之後，我們就可以對它的運行規則和基礎參數進行修改了。Codex 所有的參數，都是透過一個叫做 config.toml 的設定檔進行控制的。

我們可以直接在可視化介面裡找到這個檔案的修改入口。在左側導覽列裡，點擊 Configuration 面板，你就會在右側看到一個 Open config.toml 的按鈕。

點擊它，系統就會自動為你調起本地的文字編輯器來直接編輯全域的 config.toml 設定檔，介面入口如下：

如果你在 Cursor 或者 VS Code 編輯器裡修改這個 .toml 檔案，我建議你在設定檔的最頂上敲入下面這行程式碼。它會為你提供參數自動完成和格式診斷：

toml 代碼解讀複製代碼#:schema https://developers.openai.com/config-schema.json

常用的核心參數設定

在這個打開的 config.toml 檔案裡，下面幾個參數是我們在後面寫程式碼、做自動化任務時最常用到的，建議在第一天就設定好。

• 功能特性開關（[features]）：
  • goals = true：開啟後，支援強大的非同步長期任務（/goal 命令）。
  • hooks = true：開啟後，支援透過撰寫自動化的 Hook 機制來監聽和擴充 Agent 的運行事件。
• 常用的核心參數（根級別）：
  • model = "gpt-5.5"：推薦的全域預設主力模型。
  • model_reasoning_effort = "high"：思考深度。可選 low / medium / high。low 速度快但分析淺，high 慢但推理能力強。我日常用 medium，複雜任務切 high。
  • sandbox_mode = "workspace-write"：沙盒模式。這個設定決定了 Agent 能動哪些檔案。workspace-write 只允許改當前專案目錄裡的檔案；read-only 只能看不能改；如果設成完全不限制的模式，它就能改你電腦上任何位置的檔案，一般不建議。
• 外部工具介面（[mcp_servers]）：
  • [mcp_servers.filesystem]：控制載入的本地檔案系統插件，定義命令（npx）、參數（@modelcontextprotocol/server-filesystem）以及啟用狀態（enabled = true）。
• 帳號與帳單權限（[billing]）：
  • model_provider = "chatgpt"：綁定 ChatGPT 的高級訂閱服務，將大模型執行額度直接掛載在你的 ChatGPT Plus ($20/月) 或者是 ChatGPT Pro ($200/月) 個人帳單額度上。

這個參數規格在最新的 2026 軟體生態下是完全保持同步的，後續我們如果調試了新的工具（如 Git 提交、Browser 控制等），也會隨時在對應的章節進行即時參數記錄與補充。

完成這些核心參數設定後，按下快捷鍵保存檔案，我們的 Codex 專屬控制台就已經完全設定妥當。

這裡還有一個非常省事的小技巧：既然你已經用上了 Codex，其實大部分的 config.toml 設定參數，你根本不需要自己動手去打開檔案逐行修改。

因為 Codex 作為一個能夠直接讀寫檔案的 Agent，它自己是擁有修改設定檔的能力的。我們只需要在會話框裡直接給它發一句話，比如：「幫我把設定檔的預設模型換成 gpt-5.5，並且把推理思考強度設定為 high」，或者「幫我把設定檔的 goals 特性開關打開」。

它就會自己去尋找我們個人根目錄下的 config.toml 檔案，自發地把這些設定行修改好，並且在修改前把修改計畫展示在螢幕上。這種讓 AI 幫我們設定 AI 的懶人做法，才是使用 Agent 最該培養的直覺。

Skill 的觸發入口

Codex 的桌面端裡，點擊左側的 Plugins，切到 Skills 標籤頁，可以看到目前已安裝的所有 Skill。我們在對話的時候，可以用 $skill-name 的方式手動觸發某個 Skill，也可以直接說話讓 Codex 根據語意自動匹配。

Skill 是 Codex 非常核心的擴充機制，我們會在後面的第八章裡詳細講解它的原理、怎麼找、怎麼安裝、以及怎麼自己寫。這裡大家先知道在哪裡能看到就行。

從下一章開始，我們將正式進入具體功能的使用實操中。

上下文工程

之前我和一個不怎麼用 AI 的朋友聊天，他跟我說了一個讓我很意外的認知。他說他覺得 AI 是越用越聰明的，就像養一隻寵物一樣，你陪它的時間越長，它就越了解你，越聰明。

然後他跟我說了一個他實際遇到的問題：他跟豆包聊了一整天，一開始聊得很好，它記得他的名字、他之前說過什麼。但聊著聊著，他突然發現豆包好像忘記他是誰了，之前聊過的東西也想不起來了。他非常困惑，問我說這 AI 不是越來越聰明的嗎，怎麼突然變笨了？

我相信有這種困惑的人不在少數。在我們正式開始使用 Codex 之前，有必要先把上下文這個概念說清楚。因為後面的話題管理、Goal 命令、壓縮機制，全部都跟這個東西有關。

AI 不會因為跟你聊天而變聰明

這個可能是很多人最大的誤解。

大語言模型在訓練完成之後，它的能力就固定了。我們跟它聊天的過程中，它不會「學習」新的知識，也不會因為我們多聊幾句就變得更聰明。它只是在閱讀我們給它的資訊，然後基於這些資訊來回答。

那它為什麼一開始看起來很「懂你」呢？因為我們之前跟它說過的話，還在它的「視野範圍」內。但這個視野是有邊界的。

每一次對話都是無狀態的

這個點很多人不知道。我們覺得自己在跟 AI「對話」，感覺它「記住」了前面說的話。但實際上，模型本身是沒有記憶的。它每一次生成回覆，都是從零開始的一次全新推理。

那它怎麼做到「記住」之前聊過的內容呢？答案很簡單：每一次我們發訊息的時候，產品在後台會把之前所有的對話記錄全部打包，連同我們最新這條訊息一起，整體丟給模型。模型從頭到尾看一遍這些內容，然後生成回覆。

也就是說，我們發第十條訊息的時候，模型實際上收到的是前面九輪完整的問答記錄加上我們第十條訊息。它每次都是在「讀完整份聊天記錄」之後才回答的，而不是真的「記住」了什麼。

這個認知很重要，因為它直接解釋了為什麼聊多了之後 AI 會變慢、變貴、變笨：每一條新訊息，都要重新傳送前面所有的內容。聊得越長，每一輪的資訊量就越大。

上下文的本質：一份有大小限制的完整檔案

理解了上面這個點之後，上下文就好解釋了。

每次模型回答問題的時候，它面前有一份完整的檔案。這份檔案裡寫著：

• 系統給它的行為規則（比如「你是一個有幫助的助理」）
• 我們之前發的所有訊息
• 它之前回覆的所有內容
• 中間呼叫工具的結果（比如它讀了什麼檔案、搜了什麼網頁）

它每次回答的時候，就是把這份檔案從頭到尾看一遍，然後基於裡面的全部內容來生成下一句話。

這份檔案就是上下文。

問題在於，這份檔案有大小限制。每個模型的檔案容量不一樣，我們通常用 Token 數量來衡量。一個 Token 大約等於一個中文字或者半個英文單字。

不同模型的上下文有多大

目前主流模型的上下文視窗大小差異很大：

模型上下文視窗GPT-5.5 / GPT-5.41,050,000 TokenClaude 4.7 Opus / 4.6 Sonnet1,000,000 TokenGemini 3.5 Flash / 3.1 Pro1,000,000 TokenQwen 3.7 Max1,000,000 TokenDeepSeek V4 Pro1,050,000 Token豆包 Seed 2.0 Pro256,000 TokenKimi K2.6262,000 TokenMiniMax M2.7205,000 TokenDeepSeek R1164,000 Token目前頂尖模型基本都到了 100 萬 Token 的級別，大概相當於能裝下 2500 頁純文字。而部分模型還在 20 萬左右。

上下文視窗大意味著什麼？意味著我們可以在一次對話裡塞進更多的背景資訊。比如我們讓 Agent 去分析一個大型程式碼專案，如果上下文視窗夠大，它可以一次性讀取更多的檔案，對整體架構的理解就更完整。如果視窗太小，它只能看到局部，容易做出片面的判斷。

對於 Agent 來說，上下文大還有一個好處：它可以在不觸發壓縮的情況下執行更長的任務鏈。每一次工具呼叫的結果（檔案內容、終端機輸出、網頁內容）都會寫進上下文。一個複雜任務下來，可能輕鬆消耗幾十萬 Token。視窗大的模型能撐更久才需要壓縮，任務執行的連貫性就更好。

Agent 的上下文裡都裝了什麼

在 Codex 這樣的 Agent 裡面，上下文的組成比普通的 AI 對話產品要複雜得多。我們平時看到的只是聊天介面上的幾條訊息，但實際上在後台，每一輪對話傳給模型的檔案裡塞了很多東西：

• 系統指令 — Agent 的行為規則、可用工具的 JSON Schema 描述、目前工作目錄、日期時間等基礎資訊
• Skill 描述 — 如果我們安裝了 Skill，每個 Skill 的觸發條件和說明都會寫進去
• 我們發的訊息 — 就是我們在輸入框裡打的內容
• 模型的回覆 — 包括它生成的文字回覆
• 思維鏈 — 模型在回答之前的推理過程（在支援 thinking 的模型裡會很長）
• 工具呼叫與結果 — 它讀了哪些檔案、檔案的完整內容是什麼、運行了什麼終端機命令、終端機輸出了什麼、搜尋了什麼網頁、網頁內容是什麼

這些全部堆在一起，就是一輪對話的真實上下文體積。

我們可能只發了一句「幫我看看這個專案的結構」，但 Agent 在後台可能讀了十幾個檔案，每個檔案幾百行程式碼，終端機跑了幾個命令，這些結果全部寫進了上下文。一句話的任務，實際消耗的 Token 可能是幾萬甚至十幾萬。

這裡面最大的消耗來源往往是工具呼叫的返回結果。一個檔案可能幾千行，一次終端機輸出可能幾百行，一個網頁擷取下來可能上萬字。這些東西一旦寫進上下文，就會一直待在裡面，每一輪對話都要重新傳送。

上下文是一種注意力預算

Anthropic 在他們的官方文章裡提了一個我覺得很好理解的說法：上下文是一種有限的注意力預算。

什麼意思呢？我們往上下文裡塞的每一條資訊，都在消耗模型的注意力。如果裡面全是跟當前任務高度相關的資