Codex 使用電腦的三種方式：Computer Use、Chrome 擴充功能和內建瀏覽器

Jason 在 X 上整理了一篇關於 Codex 電腦操作能力的長文，核心問題很實用：Codex 現在可以透過 Computer Use、Chrome 擴充功能和內建瀏覽器三種方式「使用電腦」，但它們的邊界很容易混在一起。

簡單說：

• 能用外掛或 MCP 解決時，優先使用結構化工具。
• 需要操作桌面應用程式、系統設定或沒有 API 的介面時，用 @Computer。
• 任務依賴你已登入的 Chrome、帳號狀態、Cookie 或多個分頁時，用 @Chrome。
• 正在開發網頁、除錯本機頁面、檢查響應式版面或留下視覺回饋時，用 @Browser。

視覺控制最適合放在結構化工具碰不到的邊界上。比如 Slack 外掛通常比讓 Codex 去點 Slack 頁面更精準；GitHub 外掛產生的動作也比驅動網站更容易檢查。只有當 API、外掛或 MCP 不能覆蓋最後一步時，才讓 Codex 去看螢幕、點按鈕。

原帖：https://x.com/jxnlco/status/2066970432855581052

1. 用 @Computer 操作桌面和原生應用程式

Computer Use 是三種方式裡範圍最廣的一種。它讓 Codex 在你批准的 macOS 或 Windows 應用程式裡觀察圖形介面，並透過視窗、選單、鍵盤、剪貼簿等方式完成操作。

它通常也是最慢的。結構化外掛可以直接呼叫 API；Computer Use 需要看介面、判斷該點哪裡、等待應用程式回應，再檢查下一步狀態。這個視覺迴圈有成本，但好處是它可以處理那些沒有可用 API 的軟體。

在 macOS 上，「慢」不一定意味著打擾。Computer Use 可以在被授權的應用程式裡背景工作，你仍然可以繼續使用電腦的其他部分。它能處理的對象取決於你安裝並授權了哪些應用程式，可能包括 Spotify、Xcode、系統設定、iOS 模擬器，甚至 iPhone Mirroring。

適合使用 @Computer 的任務：

• 原生桌面應用程式，例如 Spotify、財務軟體、設計工具；
• iOS 模擬器、iPhone Mirroring 或其他只能透過 GUI 操作的流程；
• 系統設定或應用程式設定；
• 沒有外掛、MCP 或 API 的資料來源；
• 需要在多個桌面應用程式之間切換的流程；
• 結構化整合已經完成大部分工作，但最後缺一個介面動作。

安裝方式：

1. 打開 Codex 的 Settings。
2. 進入 Computer Use。
3. 點擊 Install，依提示完成授權。

觸發方式：

1

Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings.

1

Use @Computer to open iPhone Mirroring, reproduce the onboarding bug in the iOS app, and take a screenshot of the failing state. Fix the smallest relevant code path, then run the same flow again.

原文裡有一個很能說明邊界的例子：Jason 曾經讓 Codex 處理 Amazon 包裹被盜後的客服等待。Amazon 提示大約要 25 分鐘才能接入客服，他讓 Codex 每 5 分鐘檢查一次聊天視窗，客服出現後改成每分鐘檢查，並盡量完成退款溝通。等他回來時，退款已經完成。

還有一種常見用法是「最後一公里」。例如 Codex 可以透過 Slack 讀取回饋、修改程式碼並渲染影片，但目前執行緒裡的 Slack 整合不能上傳檔案。這時 Computer Use 只需要點擊 Add file，完成最後那個結構化工具缺失的動作。

安全邊界也要更嚴格：Computer Use 的權限範圍最廣，最好一次只給它一個明確應用程式或流程。涉及財務、帳號、付款、憑證、隱私和系統安全的動作，要保持人在場，並檢查權限提示。

2. 用 @Chrome 處理登入狀態、多分頁和帳號相關任務

Codex Chrome 擴充功能讓 Codex 使用你已經登入的 Chrome 狀態。只要任務依賴帳號、Cookie、瀏覽器資料、現有分頁或瀏覽器擴充功能，就更適合用 @Chrome。

適合使用 @Chrome 的任務：

• Gmail、LinkedIn 等需要登入的網站；
• Salesforce、客服後台或內部控制台；
• 公司內部儀表板；
• 需要跨多個已登入網站做研究；
• 表單依賴你的帳號、Cookie 或瀏覽器擴充功能。

安裝方式：

1. 打開 Codex 的 Plugins。
2. 新增 Chrome。
3. 依提示安裝 Codex Chrome 擴充功能並批准權限。
4. 看到擴充功能顯示 Connected 後，開始一個新執行緒。

觸發方式：

1

Use @Chrome to review the open customer account, compare it with the support ticket in the other tab, and draft the missing fields. Stop before submitting.

Chrome 任務會在分頁群組裡執行，這能把同一個 Codex 執行緒相關的頁面收在一起。和內建瀏覽器不同，Chrome 擴充功能使用的是你的真實瀏覽器身分，所以能力更強，也更敏感。

Chrome 的另一個優勢是多分頁控制。它可以在一個分頁讀取上下文，在另一個分頁比較資訊，再到第三個分頁繼續處理。Computer Use 也能視覺驅動瀏覽器，但 Chrome 更像是以「瀏覽器工作流」的方式理解任務，而不是一連串螢幕座標。

原文提到一個 Strudel Composer 的例子：Jason 把一個已經打開的音樂創作分頁交給 Codex，讓它把音樂做得更有意思。Chrome 給了 Codex 目前選中的分頁和頁面提供的 WebMCP 工具，Codex 檢查作品、重寫和聲與四分鐘結構、修改速度、儲存曲目，並讓它繼續播放。它不需要視覺尋找每個按鈕，因為 Chrome 可以把分頁上下文和頁面暴露的結構化能力結合起來。

長期任務也適合 Chrome。例如可以讓 Codex 每天用 Chrome 檢查 X 私訊、相關新聞和回饋，把值得長期保存的資訊加入本機知識庫，但明確要求不要發布或傳送訊息：

1
2
3

Every day, use Chrome to check my DMs, read relevant news, and look for
feedback or mentions I should know about. Add anything durable to my vault.
Do not post or send messages.

這裡真正重要的不是 Codex 能打開 X，而是同一個執行緒可以持續回到同一組登入狀態任務裡，把看到的資訊連接到本機檔案，並留下可審查的結果。

Chrome 的信任邊界同樣要清楚：網站會把 Codex 的點擊、提交、傳送訊息視為你的行為；頁面內容本身也可能是不可信輸入。比較穩妥的做法是允許它自動研究、導航和起草，但傳送、發布、購買、提交之前必須由你確認。

如果整個任務都在瀏覽器裡，而且需要登入狀態，優先選 Chrome，而不是 Computer Use。

3. 用 @Browser 開發和除錯網頁

內建瀏覽器是 Codex 執行緒裡的瀏覽器。你和 Codex 看到的是同一個渲染頁面，所以它特別適合網頁開發、視覺除錯和設計回饋。

適合使用 @Browser 的任務：

• 本機開發伺服器；
• 本機 HTML 或檔案預覽；
• 不需要登入的公開頁面；
• 復現視覺 bug；
• 檢查響應式版面；
• 對頁面元素留下設計回饋。

它最重要的約束是隔離：內建瀏覽器不使用你的正常瀏覽器資料、Cookie、擴充功能、登入工作階段或現有分頁。任務需要帳號時，這是限制；任務不需要帳號時，這反而是清晰的安全邊界。

安裝方式：

1. 打開 Codex 的 Plugins。
2. 新增 Browser 外掛。
3. 啟用它。

觸發方式：

1

Use @Browser to open vite app on <http://localhost:3000/>, reproduce the mobile overflow bug, fix it, and verify the same route again at desktop and mobile widths.

這個入口最適合形成緊密回饋迴圈：Codex 修改程式碼、操作頁面、檢查渲染狀態、截圖，再根據結果繼續修。

原文中特別強調了「標註」能力。做本機應用程式評審時，你可以直接點擊某個元素或框選區域並留言，也可以對文字、字型、間距、顏色給出更具體的回饋。Codex 收到評論時，同時拿到相關截圖和元素上下文，然後修改檔案並重新打開同一頁面。

對於設計工作，可以把一個想法、研究材料或專案狀態交給 Codex，讓它先生成一個單檔 index.html，再用內建瀏覽器打開。相比用另一段提示詞重新描述整個設計，你可以直接在頁面上標註：

1
2

Create a single-file index.html for this project brief and open it in the
in-app @Browser.

這樣頁面本身就變成了規格說明。

內建瀏覽器也適合做混合流程的起點。原文舉了一個 X 帖子的例子：先在內建瀏覽器打開帖子，讓 Codex 確認你指的是哪一條；然後切換到 Twitter CLI 拉取 38 條回覆，包括瀏覽器介面隱藏的巢狀回覆。這就是「用最窄的表面建立上下文，再用結構化工具深入檢索」。

但如果任務卡在 Google 登入、Passkey、瀏覽器擴充功能或帳號狀態上，就應該從內建瀏覽器切到 Chrome。

Appshots：指向上下文，不負責執行

Appshots 不是第四種電腦控制方式，而是把你眼前的上下文交給 Codex 的方法。

在 Mac 上，可以按兩次 CMD 捕獲最近的視窗。Codex 會把圖像和可用文字附加到執行緒裡。你可以對錯誤提示、郵件、設計稿、設定面板或陌生表單做 Appshot，然後告訴 Codex 你想讓它處理什麼。

一個好記的模型是：

Appshots 負責指出你電腦上的東西；Browser、Chrome 和 Computer Use 負責行動。

Appshots 目前從 macOS 的 Codex app 建立，捕獲的是最前面的視窗，不是整個桌面。這讓它適合提供聚焦上下文，而不必直接授予應用程式控制權。

怎麼選擇

如果要把這三種方式放進日常工作流，可以按下面順序判斷：

1. 先看有沒有外掛、MCP、CLI 或 API。能結構化完成，就不要讓 Codex 去點介面。
2. 如果需要操作桌面應用程式、系統設定、模擬器或多個本機應用程式，用 @Computer。
3. 如果任務在瀏覽器裡，並且依賴你的登入狀態、Cookie、擴充功能或多分頁，用 @Chrome。
4. 如果任務是網頁開發、公開頁面檢查、本機預覽或設計標註，用 @Browser。
5. 如果只是想告訴 Codex「看這個視窗」，先用 Appshots 提供上下文，再決定下一步用哪個入口。

這些入口的差別不只是功能差別，也是信任邊界差別。越接近你的真實帳號和桌面環境，就越應該把目標說清楚，把不可執行的動作寫明白，並在提交、傳送、付款、發布前保留人工確認。