Codex App GUI 特色這件事，我覺得不能只用「CLI vs 桌面版」來看。CLI 很好，我也喜歡 CLI，那種乾淨、直接、可以塞進自動化流程的感覺很迷人。但 Codex App 做出來的東西其實不是「把 CLI 包一層漂亮介面」，它比較像是把 AI coding agent 變成一張工作台：左邊是對話，右邊是瀏覽器、diff、terminal、文件、圖片、執行結果，人和 agent 真的在同一個畫面裡工作。
這篇是看完 愛好 AI 工程 Blog 對 Codex App GUI 功能的整理後，再補 OpenAI 官方文件和我自己的使用判斷寫成。不是逐段改寫原文，我想講的是：哪些功能真的改變工作方式，哪些功能看起來炫，但要用對場景才有價值。
先講結論：Codex App 強在「一起看東西」
CLI 的強項是下指令、跑工具、改檔案、看輸出。Codex App 的強項則是「人和 AI 一起看同一個東西」。這差很多。
你在做前端 UI、修後台流程、看 PR diff、整理文件、測試網站、操作登入後的系統時，很多資訊不是文字能講清楚的。以前你要截圖、貼圖、補一句「這裡偏左」、「那個按鈕怪怪的」。現在 Codex App 可以直接把瀏覽器、Chrome、桌面 App、review pane 拉進同一個流程。這不是小改版，是工作模式變了。
如果你還在分不清 Codex 桌機版和 CLI 的定位，可以先看我之前寫的 OpenAI Codex 桌機版介紹，再回來看這篇會更順。
1. Appshots：不是截圖，是把當下脈絡丟給 Codex
Appshots 是我覺得最有代表性的 GUI 功能。照 OpenAI 官方文件，macOS 版 Codex App 可以用快捷鍵把目前最前面的 app 視窗送進 thread。它會包含可見畫面，也可能包含該視窗能提供的文字內容；有些 app 還能提供畫面外的文字。不過官方也提醒，Google Docs、Gmail、Sheets、Slides 這類服務不一定每次都能拿到完整文件，必要時還是要靠對應 plugin 或 connector。
這就很像你把正在看的錯誤畫面、設定頁、設計稿、API 文件、Email 丟給旁邊同事看。差別是那位同事是 Codex，而且它可以接著去改程式、跑測試、開瀏覽器驗證。CLI 當然也能讀檔、看輸出，但它沒辦法自然吃到「我現在眼前這個 app」的狀態。
2. Remote control：讓 Codex 不再綁死在桌前
OpenAI 在 2026 年 5 月發表的「Work with Codex from anywhere」裡，把 Codex 帶進 ChatGPT mobile app。官方描述的重點不是手機版聊天而已，而是你可以從手機看到遠端機器上的 thread、terminal output、diff、test result、approval，甚至在 Codex 需要你決定時，直接從手機接手。
這件事對長任務很關鍵。以前 agent 跑到一半問你：「要選 A 還是 B？」你人不在電腦前，它就卡住。現在你可以在捷運上看它卡在哪，回一句「先走保守解法，不要動資料庫」，工作就繼續往前。這種節奏很像帶一個遠端同事，不是開一個終端機放著等它跑完。
順帶一提，愛好 AI 工程 Blog 提到 Linux 上用 codex remote-control 的玩法。這個我會把它當成社群實測的延伸招，不會寫成標準官方流程。官方文件目前比較明確的是 Remote SSH、桌面 App、行動 App 和受信任機器之間的連線模式。
3. $browser、@chrome、@computer：三種操作介面不要混著用
Codex App 最容易讓人混亂的地方，是它有好幾種「讓 AI 看畫面 / 操作畫面」的方式。我會這樣分：
| 功能 | 適合做什麼 | 我的用法 |
|---|---|---|
$browser | 測本機開發中的網站、前端 UI、互動流程 | 做網頁、工具頁、WordPress 前台驗證優先用這個 |
@chrome | 需要你已登入 Chrome 的網站或後台 | 處理登入後流程、資料搬移、研究資料時用 |
@computer | 需要操作桌面 App、系統設定、非瀏覽器 GUI | 真的只能靠點擊和畫面判斷時再用 |
OpenAI 的 Computer Use 文件也講得很清楚：如果你正在做本機 web app，先用 in-app browser；真的需要操作桌面 GUI，再用 computer use。這個順序很重要。不要什麼都叫 AI 點來點去，能用檔案、API、CLI、瀏覽器 DOM 解決的，通常會更穩。
4. Thread、Fork、Steering：GUI 讓你比較不會把對話搞髒
AI coding 最常見的災難不是模型不會寫 code，而是你把任務脈絡弄成一團。原本叫它修 bug，半路想到要重構，接著又插一句「順便補測試」，最後 thread 裡混了三條線，誰都看不懂。
Codex App 的 thread list、pin、fork、steering 和 queuing，價值就在這裡。GUI 讓你看得到每條 thread 的狀態，也可以從某一則輸出直接 fork 出新 thread。修 bug 就修 bug，重構就重構，研究就研究。你不需要用腦袋記「第三個 terminal tab 是哪一條任務」。
這也是我現在越來越推薦桌面 App 的原因。CLI 很適合單線工作，但一旦你同時跑兩三條任務，GUI 的 thread 管理會救你很多心智負擔。
5. Review pane：改 code 不是重點，看懂 diff 才是重點
Codex 會寫 code 不稀奇。真正麻煩的是：你怎麼知道它改得對不對？OpenAI 的 review 文件提到，Codex App 可以在 review pane 裡看 diff、stage、revert，甚至對特定行留下 inline comments，再叫 Codex 針對那些 comment 處理。
這個功能很實際。你不需要整段說「第二個檔案中間那個判斷式怪怪的」。你直接在那一行留言：「這裡不要吃掉 0，請保留空字串和數字 0 的差異」。Codex 看到的是 line-specific feedback，修起來比泛泛一句「再檢查一下」準很多。
如果你常用 AI 改 WordPress 專案，也可以搭配我上一篇整理的 WordPress Agent Skills 教學。Agent Skills 管規範，Review pane 管檢查結果，兩個加起來才像真正的開發流程。
6. Automations 和 Goals：長任務需要可回來的上下文
Thread automations 是我覺得容易被低估的功能。OpenAI 文件把它形容成 attached to the current thread 的 recurring wake-up calls。白話一點：你可以讓 Codex 固定回到同一條 thread 檢查某件事，而不是每次都開一個新任務從零開始。
這很適合 PR review loop、部署等待、長時間資料整理、固定看 Slack / GitHub / 文件留言。有些工作不是一次 prompt 就結束，而是要「等一下再看」、「有人回覆再接著處理」、「測試跑完再往下」。CLI 可以用 cron 或 script 做一些事，但要保留對話上下文和判斷流程，thread automation 比較自然。
Goals 則更像是給 Codex 一個長期目標。我的建議是，不要寫「幫我把這個做好」這種爛目標。要寫清楚完成標準：要通過哪些測試、不能動哪些檔案、每完成一段要怎麼回報。AI 長任務最怕不是慢，是一路跑偏還很努力。
那 CLI 還有沒有價值？當然有
不要把這篇看成「GUI 贏了，CLI 可以丟掉」。不是。CLI 還是非常適合自動化、CI、server、SSH、低資源環境、快速單點修正。你要在一台沒有圖形介面的 Linux server 上處理事情，CLI 仍然是王道。
我的分法會是這樣：CLI 負責短、快、可腳本化的工作；Codex App 負責需要人一起看、一起判斷、一起 review 的工作。前者像工具，後者像工作台。這也是為什麼我寫 Codex on Windows 教學時，會把原生 App、CLI、IDE extension、WSL2 分開講，因為它們不是誰取代誰，而是不同場景要選不同介面。
我會怎麼用 Codex App？
- 前端 UI：用 in-app browser 看畫面，直接標註哪裡要改。
- WordPress 專案：開一條 thread 做外掛，一條 thread 做 SEO / REST API，一條 thread 看測試。
- 長任務：用 goal，但一定寫完成標準，不讓它自己腦補。
- PR review：在 review pane 留 inline comments，叫 Codex 逐條處理。
- 遠端工作：出門時用手機看進度、批准命令、改方向。
- 敏感資料：Appshots、Chrome、Computer Use 都要注意分享範圍，不要順手把客戶資料丟進去。
結論：Codex App 不是比較漂亮，是比較像工作發生的地方
Codex App 最值得看的，不是某一個功能有多酷，而是它把 AI coding 從「文字對話」推向「共同工作空間」。你可以看畫面、標註、fork、review diff、跑瀏覽器、接 Chrome、操作桌面 App、讓 thread 之後再醒來。這些東西堆在一起，才是 GUI 的意義。
CLI 還會繼續存在，而且很重要。但如果你的工作牽涉設計稿、前端、後台、文件、PR、長任務和多人協作，Codex App 會越來越不像「另一個聊天視窗」，而像你每天真正開工的那張桌子。
常見問題 FAQ
Codex App 比 Codex CLI 好用嗎？
看任務。CLI 適合短任務、腳本、自動化和遠端 server；Codex App 適合需要看畫面、review diff、管理多條 thread、操作瀏覽器或桌面 App 的工作。不是誰取代誰，而是場景不同。
Codex Appshots 會讀到所有文件內容嗎？
不一定。官方文件說 Appshots 會擷取前景視窗和可取得的文字內容，但 Google Docs、Gmail、Google Sheets、Slides 等服務有時可能只能取得可見畫面。敏感內容也要小心，不要隨手分享。
$browser、@chrome、@computer 差在哪？
$browser 適合本機 web app 和前端驗證；@chrome 適合需要登入狀態的 Chrome 工作流；@computer 適合只能靠桌面 GUI 操作的任務。一般開發網頁時，先用 in-app browser 會比較穩。
Codex App 的 Review pane 有什麼用？
Review pane 讓你直接看 diff、stage、revert，還能在特定程式碼行留下 inline comments。這比用文字描述「某個檔案中間那段」準很多，也比較適合實際 code review。
Codex Thread automations 適合什麼任務？
適合需要回到同一條 thread 的週期性任務，例如等部署完成、追 PR review、固定檢查 Slack 或 GitHub 回覆、長時間研究整理。重點是保留上下文，而不是每次重新開一個任務。
