Hi~ 我是 Eric！👋
如果你一路有看我前面幾篇 Codex App 的文章，應該知道我一直把它當成「AI Agent 的開發工作台」。它可以開 repository、建立 Worktree、讀 AGENTS.md、改檔、跑測試、看 diff，最後把一份能被工程師審查的成果交回來。
而在 2026 年 7 月 9 日，這個工作台出現了目前最大的一次產品變化：
Codex 正式整合進新的 ChatGPT Desktop App。
這次更新很容易被寫成「ChatGPT 不只會聊天，現在也能寫程式」。但以我過去都在關注 Codex App 的角度來看，這個敘述只講到一半。
更完整的理解應該是：原本獨立負責軟體開發的 Codex，現在接上 ChatGPT 的對話能力與 Work 的長任務能力。 開發者不用再把「想需求、查資料、整理文件、動程式碼」拆散在不同 App 裡，而是能在同一個桌面入口，依任務性質切換到適合的模式。
這不是 Codex 被 ChatGPT 吃掉。相反地，Codex 仍然是最靠近 repository、終端機、diff、測試與 Pull Request 的核心，只是它現在有了更大的工作半徑。
Codex 沒有消失，它只是搬進新的 ChatGPT Desktop App
先處理大家最直接的問題：原本的 Codex App 到底怎麼了？
OpenAI 的官方說明是：新版 ChatGPT Desktop App 已在 macOS 與 Windows 全球推出，並把 Chat、Work、Codex 放進同一個 App。既有 Codex App 使用者照平常流程更新，就會移到新的 ChatGPT Desktop App；使用舊版 ChatGPT Desktop App 的人，則會在 App 裡看到下載新版的提示。 ChatGPT 官方 Release Notes 有完整的遷移說明。
舊版 ChatGPT Desktop App 可能會保留成 ChatGPT Classic。它仍會取得模型更新、錯誤修正、安全性更新與既有 Enterprise 功能，但新的 agent 能力，例如 Work 與 Codex，會放在新版 App。
所以這次改版不是：
- Codex App 被關掉。
- ChatGPT 新增一個普通的 coding 聊天模式。
- 所有工作內容突然變成同一種對話。
而是：
- Codex 的開發能力被保留下來。
- Chat、Work、Codex 共用同一個桌面入口。
- 使用者依任務性質切換工作模式，不必一直換 App。
- 帳號、方案與部分工作區控制開始用一致的方式管理。
講白一點，以前是三個辦公室分散在不同樓層；現在它們搬到同一層，但每個房間仍有自己的工作內容與權限。
Chat、Work、Codex 到底差在哪？先看任務性質，不要看名稱猜
OpenAI 對三個模式的分工其實很明確： ChatGPT Work and Codex 官方說明 將 Chat 定位為問題與對話、Work 定位為研究與完整交付、Codex 則是專門處理軟體開發與技術工作的 Agent。
| 模式 | 核心任務 | 可以做什麼 | 不適合拿來做什麼 |
|---|---|---|---|
| Chat | 快速理解與對話 | 問問題、搜尋、腦力激盪、翻譯、改寫、快速分析 | 直接操作完整 repository、長時間執行多步驟開發任務 |
| Work | 長任務與完成型交付 | 研究、分析連接的資料與檔案，製作文件、試算表、簡報、報告、Sites | 取代專門的程式碼開發、測試與版本控制流程 |
| Codex | 軟體開發與技術工作 | 寫程式、除錯、跑測試與指令、review 變更、操作 repository | 一般閒聊，或只需要快速改寫一句話的低成本任務 |
Chat：先把問題問對，不要一開始就叫 Agent 猜
Chat 是最熟悉的快速入口。你可以用它討論需求、整理腦中的想法、比較兩種方案，或先把問題問清楚。
例如準備開發「學生資料匯入」功能時，先在 Chat 裡釐清：
- 支援哪些檔案格式？
- 欄位缺漏要擋下來，還是允許部分匯入？
- 重複資料怎麼辨識？
- 錯誤訊息要給一般使用者，還是給系統管理員？
這些事情如果沒先講清楚，直接進 Codex 叫它「幫我做匯入功能」，Agent 只會很努力地替你猜一份規格。
Work：把研究和交付物整理到可以執行
Work 是這次新加入的重要角色。它適合較長、較複雜的任務，可以分析資料、使用連接的 Apps 與檔案，並產出完整文件、試算表、簡報、報告或 Sites。
延續前面的例子，Work 可以協助：
- 讀取舊系統規格與訪談紀錄。
- 比對既有資料欄位與新版 API 契約。
- 整理成需求規格、風險清單與驗收條件。
- 產出給主管看的簡報，或給開發團隊看的設計文件。
- 透過 Scheduled Tasks 定期追蹤資料品質或專案狀態。
這裡最關鍵的是「完成型交付」。Chat 比較像一起討論；Work 則是接下較長的任務，讓你在過程中追蹤進度、回答問題、調整方向並核准重要動作。
Codex：最後真的進 repo、改 code、跑驗證
當需求已經足夠清楚，真正要碰專案時，主角就回到 Codex。
Codex 可以使用本機資料夾、repository、終端機與開發工具。它能讀程式碼、修改檔案、執行測試與指令、檢視變更，並把結果整理成工程師可以 review 的形式。
這也是為什麼我不會把這次更新寫成「ChatGPT 變成開發工作台」。比較精確的說法是：
Chat 負責把問題說清楚，Work 負責把研究與交付整理好，Codex 負責把它落到可驗證的工程成果。
一個 App，不代表三種工作自動共用所有內容
整合之後很方便，但這裡有一個很容易誤會的地方：同一個 App，不代表所有對話、檔案與執行環境會無條件混在一起。
官方對不同 surface 的資料邊界有明確說明：
| 工作內容 | 可以在哪裡使用 | 需要注意的邊界 |
|---|---|---|
| Chat | Web、桌面與行動版 | Chat 對話可以在 ChatGPT Web 與桌面 App 間同步 |
| Work（雲端） | Web、行動版 | 雲端 Work 對話留在支援的雲端 surface；推出初期不會出現在桌面 Work |
| Work（桌面） | ChatGPT Desktop App | 可在授權後使用本機檔案與桌面 App；桌面 thread 與本機檔案留在該電腦 |
| Codex | ChatGPT Desktop App、CLI、IDE、Web 等 Codex client | 桌面 Codex 任務不會直接變成 Web 對話；行動版透過 Remote tab 查看支援的桌面任務 |
OpenAI 也特別說明，Codex 並不是 Web 或行動版裡可以直接選擇的模式。你可以在 ChatGPT 行動版 Remote tab 存取支援的桌面 Codex 任務，但那不會把 Codex thread 變成一般的 Web 或行動版聊天紀錄。
這個設計其實合理。Codex 的工作上下文可能包含本機檔案、終端機輸出、專案設定與尚未提交的變更；如果全部自動同步到任何裝置，反而會增加安全與狀態一致性的風險。
Codex 在新 App 裡，新增了哪些工程能力？
除了入口整合，這次 Codex 本身也有幾個很實際的更新。
1. 直接在 diff 裡編輯
以前 review Agent 變更時，常見流程是先看 diff、發現一小段不對，再回到檔案或叫 Agent 重改。新版加入 diff 內嵌編輯，讓人類可以直接修正局部內容。
這很重要，因為 AI Agent 開發不應該只有「接受全部」和「全部重來」兩個選項。能在 diff 裡補一刀，才比較接近真正的 code review。
2. 側邊欄 Pull Request review
Pull Request review 被帶進側邊工作區後，Codex 不只負責寫 code，也更接近整個變更審查流程。
你可以要求它：
- 摘要變更範圍。
- 尋找缺少的測試與邊界條件。
- 檢查規格和實作是否一致。
- 說明哪些地方需要人工判斷。
3. 更快的 Computer Use
Computer Use 讓 Codex 可以操作支援的桌面應用程式，執行測試、除錯或驗證前端流程。速度提升的價值不是讓滑鼠移動看起來比較帥，而是縮短「改 code → 開 App → 驗證 → 回來修正」的循環。
4. 一個 project 支援多個 repository
這對企業系統特別有感。前端、後端、文件與部署設定常常分散在不同 repo。過去 Agent 容易只看到其中一塊；現在同一個 project 可以處理多個 repository，更適合追蹤跨 repo 影響。
當然，多 repo 也代表權限和變更範圍更大。不要因為 App 支援，就一次把所有 repo 都丟進去。還是應該從任務真正需要的範圍開始。
Plugins 也整合了：能力可以跨 Chat、Work、Codex 使用
這次更新同時把原本的 App Directory 改為 Plugin Directory。Plugin 可以封裝 Skills、Apps 與 App templates，並依支援情況出現在 ChatGPT Web、Desktop、Work 與 Codex。
對開發團隊來說，這代表可重複的工作流程不必只存在某一個對話裡。例如：
- 在 Work 使用公司核准的資料來源整理需求。
- 在 Codex 使用相同的 Plugin 規則執行開發流程。
- 透過 Skill 固定 review、驗證與輸出格式。
- 由管理員用 workspace 權限、角色與 App permission 控制可用範圍。
但 Plugin 不會越權。它仍受來源系統權限、workspace 設定、角色、確認規則與外部服務驗證限制。安裝一個 Plugin，不等於突然取得整間公司的資料。
方案與額度：同一個 App，也不代表所有人看到完全相同
Codex 已包含在 ChatGPT 各方案中，包括 Free 與 Go，但使用額度會依方案而異。ChatGPT Work 則依方案、surface 與 rollout 狀態逐步開放；Web 與行動版初期提供給符合資格的付費方案。
還有一個企業或重度使用者要注意的地方：官方說明指出，Codex、ChatGPT Work、ChatGPT for Excel 與 Workspace Agents 在方案可用時，會共用同一個 agentic usage／credit pool。
也就是說，同一個 App 裡的模式不是各自送你一份無限額度。任務越大、模型越強、執行時間越久、codebase 越複雜，消耗就可能越高。
這也是為什麼下一篇要單獨談 GPT-5.6：模型選擇不只是「哪個比較聰明」，它同時會影響速度、成本與額度配置。
實戰情境：一個新功能，如何在同一個 App 跑完整流程？
假設今天要替校務系統新增「學生資料批次匯入」。我會這樣使用三個模式：
第一階段：Chat 釐清問題
- 使用者是行政人員還是資訊人員？
- 匯入 Excel、CSV，還是兩者都支援？
- 重複資料、缺漏欄位、錯誤日期要怎麼處理？
- 匯入一半失敗時，是否需要整批 rollback？
這一階段目標不是產出 code，而是把模糊需求變成能討論的決策。
第二階段：Work 整理規格與交付物
- 讀取舊系統欄位文件與新 API 規格。
- 產出資料對照表、風險清單、驗收條件。
- 整理主管簡報與開發團隊設計文件。
- 建立後續追蹤或監控任務。
第三階段：Codex 實作與驗證
- 開啟前端、後端與測試 repo。
- 先閱讀
AGENTS.md和既有架構。 - 在 Worktree 內完成 API、UI 與測試變更。
- 執行建置、單元測試和必要的瀏覽器驗證。
- 整理 diff、風險與尚未驗證項目，交給工程師 review。
這才是「一個 App 完成不同性質任務」真正有價值的地方。不是讓同一個模式硬做所有事，而是讓不同模式接力完成一條工作流。
原本的 Codex 工程流程要保留，甚至應該更嚴謹
介面整合後，最危險的誤解是：「現在都在 ChatGPT 裡了，應該不用再管 Codex 的工程設定。」
剛好相反。
當 Codex 能碰更多 repo、使用 Computer Use、連接更多工具時，工程護欄更重要：
AGENTS.md：說明 repo 地圖、規則與完成標準。- Local environments：確保新工作區知道怎麼安裝、建置與測試。
- Worktree：隔離 Agent 任務，不污染主要工作目錄。
- Diff review：確認變更範圍與既有使用者修改。
- 驗證命令：用實際建置、測試與瀏覽器結果證明完成。
- 人工決策：資料庫、正式環境、資安與部署不可完全交給模型猜。
如果你還沒整理這套流程，可以接著看我之前的兩篇文章：
升級前檢查清單
準備切換到新的 ChatGPT Desktop App 時，我建議先確認：
- 更新 App：既有 Codex App 使用者依正常更新流程遷移；舊 ChatGPT Desktop App 使用者依提示下載新版。
- 確認方案與 workspace policy：Work、Codex、Plugin 與外部 Apps 的可用性可能受方案、角色與管理員設定影響。
- 檢查本機授權：只開放任務需要的資料夾、App、Browser 與外部服務。
- 保留既有 repo 設定：確認
AGENTS.md、Local environments、Worktree 與測試命令仍可使用。 - 不要假設 thread 全部同步：了解 Chat、Cloud Work、Desktop Work 與 Codex 的資料邊界。
- 重新確認額度：長任務與強模型可能共用 agentic usage pool，執行前先看方案限制。
結語：Codex 從獨立工作台，變成整合流程的最後一哩
這次更新真正改變的，不只是 App 名稱。
Codex 原本就能把 Agent 帶進 repository、終端機、Worktree、diff 與測試流程。現在它接上 Chat 的即時對話、Work 的研究與交付，再透過同一個桌面 App 串起不同性質的任務。
我會用一句話總結：
Chat 把問題說清楚，Work 把材料整理完整，Codex 把結果做成可以 review、測試與合併的工程成果。
下一篇，我會接著完整拆解這次同步出現的 GPT-5.6：Sol、Terra、Luna 與各種推理模式到底怎麼選 。當一個 App 能執行更多任務後，懂得選擇適合的模型，會比永遠選最強更重要。