這個功能解決的是什麼問題？
過去如果一項工作需要用到「沒有 Connector 的網站」，使用者只能自己開瀏覽器、手動查資料、複製貼上回 Claude，這段人力操作永遠是流程裡最沒辦法自動化的一截。內建瀏覽器把這段補上：Claude 自己開瀏覽器、自己讀網頁、自己點按鈕填表單，使用者不需要再當中間的複製貼上工。
它解決的不是「Claude 能不能看懂網頁」（這件事 Claude in Chrome 早就能做），而是「Claude 能不能在使用者完全不用開自己瀏覽器的前提下，獨立完成一整段網頁操作」。
跟 Claude in Chrome 同時存在，會不會讓人搞不清楚該用哪個？
分辨方式其實只有一個判斷點：這個任務需不需要「你現在開著的那個分頁」。如果答案是「是」（例如你正在看的 CRM 頁面、還沒回的信），用 Claude in Chrome；如果答案是「不需要，Claude 自己去哪個網站查資料都可以」，用內建瀏覽器。
官方也設計了預設邏輯降低選擇負擔：已經在用 Claude in Chrome 的人，它會繼續是預設選項；沒在用的人，Claude 會自動改用內建瀏覽器。使用者真正需要手動介入切換的情境不多。
「不會看到你的分頁、書籤或密碼」這句話具體是什麼意思？
這句話的重點在於架構層級的隔離，不是承諾或政策上的自律。內建瀏覽器是一個跟使用者日常瀏覽器完全分開的獨立環境，兩者之間預設沒有資料流通管道——Claude 沒有管道可以讀到你 Chrome 或 Edge 裡開著的分頁內容，這是環境隔離的結果，不是「Claude 選擇不去看」。
登入資訊的移轉則是一個完全獨立、需要使用者主動操作的動作：你可以選擇把哪些網站的登入資訊帶進內建瀏覽器，而銀行、信箱、SSO 這三類預設被排除在移轉範圍外，除非你自己主動加入。這代表即使你把大部分常用網站的登入資訊都搬過去了，最敏感的帳號類別仍然多一層「你必須主動選才會發生」的門檻。
官方都承認提示詞注入無法完全消除了，一般使用者該怎麼辦？
這句話值得認真看待，不是官方的免責條款而已——它反映的是目前整個產業對「AI 代理操作網頁」風險的真實技術現況：檢查機制能降低成功率，但無法保證零風險，這點在 Claude in Chrome 上線時官方就已經明確承認過，內建瀏覽器沿用同一套防護，風險輪廓也相同。
對一般使用者來說，實際能做的判斷主要落在「你讓 Claude 去哪個網站」這件事上：內容結構穩定、來源可信的網站（例如公司內部系統、你長期在用的服務儀表板），風險相對可控；來源不明、內容由不特定第三方自由編輯的頁面（例如公開論壇、使用者生成內容為主的網站），則是提示詞注入比較容易藏身的地方，這類任務建議優先用 Claude in Chrome 在你自己盯著的分頁裡處理，或至少提高警覺、分段確認 Claude 的操作是否符合預期。
Anthropic 於 2026 年 8 月 27 日宣布，Claude Cowork 桌面版新增內建瀏覽器功能。當任務需要用到網站時，這個瀏覽器會直接在 Cowork 的側邊面板開啟，Claude 可以自行瀏覽網頁、讀取內容、點擊按鈕並填寫表單，使用者不需要另外安裝任何瀏覽器擴充功能。
官方舉的使用情境包括：讓 Claude 蒐集撰寫報告所需的網路資料、從網站儀表板整理數字，或是進入目前沒有提供 Connector 的企業入口網站處理工作。這些過去需要使用者自己開瀏覽器、複製貼上資料再回頭給 Claude 的流程，現在可以整段交給 Claude 自己跑完。
值得先分清楚的是，這不是 Claude in Chrome 的功能升級，而是完全獨立的新能力。Claude in Chrome 操作的是使用者「目前已經開啟、且已經登入」的分頁——適合處理眼前這個 CRM 頁面、這封還沒回的信、正在編輯的這份文件。Cowork 內建瀏覽器則是給 Claude 一個獨立的瀏覽環境，跟使用者自己平常用的瀏覽器完全分開運作。
這個區隔也決定了使用者該選哪一個：如果任務就是要處理你眼前這個網頁，用 Claude in Chrome；如果任務只是要 Claude 自己跑去某個網站蒐集資料或執行操作、不涉及你目前開著的分頁，用 Cowork 內建瀏覽器。如果使用者本來就已經在用 Claude in Chrome，它會維持運作並繼續作為預設選項；其他情況下 Claude 則會使用內建瀏覽器。兩者可以在「Settings → Cowork → Preferred browser」裡切換。
因為是獨立瀏覽環境，Anthropic 特別說明 Claude 不會直接看到使用者自己瀏覽器裡的分頁、書籤或密碼。如果需要讓 Claude 登入某個網站，使用者可以選擇把登入資訊逐一帶入內建瀏覽器——目前 macOS 支援從 Chrome、Edge 或 Firefox 移轉登入資訊，Windows 與 Linux 則支援從 Firefox 移轉。銀行、電子郵件及 Single Sign-On 網站預設不包含在移轉範圍內，使用者要主動選擇才會加入，等於把最敏感的帳號類別預設排除在外。
Claude 具備瀏覽器操作能力後，也必然要面對 AI 代理操作網頁時常見的提示詞注入（prompt injection）風險——網站內容裡可能藏著指示，試圖讓 Claude 偏離使用者原本交付的任務去做別的事。Anthropic 表示，Cowork 內建瀏覽器採用與 Claude in Chrome 相同的防護措施，包括即時檢查 Claude 目前的操作是否仍然符合使用者原先提出的要求。官方也直接承認，這類措施只能降低風險、無法完全消除，因此建議使用者優先讓 Claude 在可信任的網站上操作。
Claude Cowork 內建瀏覽器目前開始陸續推送，適用於 Claude 桌面版的 Pro、Max 與 Team 方案，支援 macOS、Windows 及 Linux（Linux 版本目前仍為 Beta）。Enterprise 方案已經可以使用，管理員能在「Organization settings → Cowork → Built-in browser」中集中管理這項功能的開放與限制。
內建瀏覽器實際運作在 Claude 桌面應用程式裡：只要桌面應用程式保持開啟並連線，即使使用者是從網頁版或手機發出指令，Claude 仍能驅動這個瀏覽器完成任務；如果桌面應用程式沒有開啟，網頁版則仍可透過 Claude in Chrome 使用瀏覽器功能。
如果你的工作常常卡在「這個系統沒有 Connector，只能自己開網頁手動查資料再貼回來」，內建瀏覽器補的正是這一塊——它不取代 Connector（有 Connector 的服務仍然是更穩定的選項），而是處理那些永遠不會有官方整合、但你三不五時就得手動跑一次的網站。實際導入前，先盤點你會讓 Claude 造訪的網站清單：優先從你信任、內容結構穩定的網站開始，銀行、Email、SSO 這類帳號本來就預設不會被移轉，不需要額外設定就已經有一層保護；至於其他網站的登入資訊要不要移轉進去，等於是在「省下手動貼資料的時間」跟「多開放一組帳號給 AI 操作」之間自己拿捏，沒有一體適用的標準答案。