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

Wed, 17 Jun 2026 12:19:30 +0800

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 的資料來源；
需要在多個桌面應用程式之間切換的流程；
結構化整合已經完成大部分工作，但最後缺一個介面動作。

安裝方式：

打開 Codex 的 Settings。
進入 Computer Use。
點擊 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 或瀏覽器擴充功能。

安裝方式：

打開 Codex 的 Plugins。
新增 Chrome。
依提示安裝 Codex Chrome 擴充功能並批准權限。
看到擴充功能顯示 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、擴充功能、登入工作階段或現有分頁。任務需要帳號時，這是限制；任務不需要帳號時，這反而是清晰的安全邊界。

安裝方式：

打開 Codex 的 Plugins。
新增 Browser 外掛。
啟用它。

觸發方式：

`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 建立，捕獲的是最前面的視窗，不是整個桌面。這讓它適合提供聚焦上下文，而不必直接授予應用程式控制權。

怎麼選擇

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

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

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

Chrome擴充功能 on KnightLi的博客

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

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

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

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

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

怎麼選擇

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

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

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