Claude Code剛放出大招，轉眼就被群嘲“用不起”！OpenAl趁機甩出最陰插件，直接偷家

作者｜冬梅

在各大廠狂卷開發者工具生態之際，Anthropic 也在頻繁推出新工具。

北京時間昨天夜里，Anthropic 宣布在其開發工具 Claude Code 中引入一項極具突破性的能力——“Computer Use”（計算機操作能力）。這一功能目前以研究預覽（research preview）形式在 macOS 平臺上線，允許 Claude 直接通過命令行界面（CLI）操控用戶計算機，實現從代碼編寫到應用驗證的完整閉環。

Computer Use 正式可用

傳統的 AI 編碼工具，無論是 GitHub Copilot 還是早期的 Claude Code，本質上仍停留在“生成代碼”的范疇——開發者需要手動完成編譯、運行、調試、驗證等步驟。而“Computer Use”能力的出現，徹底改變了這一流程。

根據 Anthropic 發布的技術說明，Computer Use 能處理任何你通常需要離開終端手動完成的任務，例如：

• 構建并驗證原生應用：請 Claude 構建一個 macOS 菜單欄應用。Claude 會編寫 Swift 代碼，編譯并啟動它，并在你打開應用之前逐個點擊每個控件進行驗證，以確保其正常工作。

• 端到端 UI 測試：讓 Claude 打開本地 Electron 應用，并告訴他“測試用戶引導流程”。Claude 打開應用，點擊注冊按鈕，并截取每個步驟的屏幕截圖。無需 Playwright 配置，也無需測試框架。

• 調試視覺和布局問題：告訴 Claude “模態框在小窗口中顯示不全”。Claude 調整窗口大小，重現問題，截圖，修改 CSS，并驗證修復效果。Claude 看到的問題與你看到的一致。

• 僅支持 GUI 的工具：與設計工具、硬件控制面板、iOS 模擬器或沒有 CLI 或 API 的專有應用程序進行交互。

這意味著，開發者無需離開終端，即可完成過去需要 IDE、瀏覽器、模擬器等多工具協作的復雜流程。更關鍵的是，這種能力并不限于 CLI 環境，而是覆蓋所有需要 GUI 交互的場景，例如：

• 原生 macOS 應用（如 SwiftUI）

• Electron 桌面應用

• 無 CLI 或 API 的專有軟件

• iOS 模擬器、設計工具等

換句話說，Claude 不僅“會寫代碼”，還“會用電腦”。

技術實現：基于 Agent Loop 與 MCP

從技術角度來看，“Computer Use”并非簡單的自動化腳本，而是構建在完整的智能體（Agent）執行框架之上。

該能力通過一個名為computer-use的內置 MCP（Model Context Protocol）服務器實現。MCP 是 Anthropic 近年來重點推進的接口標準，用于統一模型與外部工具、數據源之間的交互方式。

在這一架構中：Claude 作為決策核心（模型）、CLI 作為交互入口、MCP 服務器作為工具調度層，本地系統作為執行環境。Claude 會根據任務自動選擇最合適的執行路徑：

這種“分層決策”機制，本質上是一種成本與效率的優化：GUI 操作最通用，但也是最慢、最不精確的方式，因此僅作為兜底方案。

在引入“computer-use”能力之后，Claude 對本地應用的調用方式并非完全開放，而是建立在一套以“會話為單位”的權限控制機制之上。這一機制的核心目標，是在提升自動化能力的同時，確保用戶對系統訪問范圍擁有清晰、可控的邊界。

首先需要明確的是，啟用 computer-use 服務器，并不等同于允許 Claude 直接訪問用戶計算機中的所有應用程序。系統默認采取的是按需授權策略：只有當 Claude 在當前任務執行過程中，首次嘗試調用某個具體應用時，才會觸發權限請求流程。

在這一過程中，終端會彈出提示信息，向用戶明確展示幾項關鍵內容：其一，Claude 當前希望控制的具體應用名稱；其二，該操作是否涉及額外權限請求，例如訪問剪貼板等敏感資源；其三，在 Claude 執行相關任務期間，是否會對其他正在運行的應用產生影響，例如被隱藏或暫時不可見。

用戶需要基于這些信息進行決策，選擇“允許”或“拒絕”。這一授權行為具有嚴格的作用域限制——所有批準僅在當前會話期間有效，一旦會話結束，相關權限將自動失效，不會被長期保留或跨會話繼承。這種設計有效降低了長期權限濫用的風險。

此外，當 Claude 在同一時間需要訪問多個應用時，系統支持用戶進行批量授權，從而減少頻繁確認帶來的操作負擔。這一設計在多步驟任務或復雜工作流中尤為關鍵，可以在效率與安全之間取得平衡。

社區反饋兩極分化

在 Reddit 社區中，這一新功能迅速引發了廣泛而激烈的討論。

有趣的是，用戶情緒呈現出一種明顯的分裂：一方面認可功能本身的技術價值，另一方面則對其現實可用性表達出強烈不滿。

一部分用戶認為該功能“概念上很酷”，但在當前使用限制之下幾乎缺乏實際意義。

有評論直言，這類發布“顯得不合時宜”，甚至在社區中形成了一種帶有諷刺意味的共識——“很酷，但誰在乎？”點贊較高的評論集中批評 Anthropic 的產品策略，認為連付費用戶的基礎體驗都未得到保障，更不用說嘗試這種高消耗 token 的新能力。在他們看來，資源分配和優先級判斷存在明顯偏差。

與此同時，一些具體問題也被反復提及。例如，Windows 和 Linux 用戶對該功能遲遲未覆蓋表示不滿，認為 Mac 優先的發布路徑忽視了更廣泛的開發者群體。此外，該用戶也表示對不同產品形態之間的定位感到困惑。社區中較為一致的解釋是：“Cowork”更像是桌面端的沙盒助手，用于處理常規任務；而“Computer Use”則是面向開發者的命令行工具，具備更深層的系統訪問能力，主要服務于代碼相關工作流。

還有一部分用戶，則進一步延伸到了成本與商業模式問題。

有用戶指出，當前的定價體系本質上處于“被補貼”的狀態。一旦單位經濟模型趨于穩定，價格結構很可能發生顯著變化，例如更嚴格的分級套餐、更低的使用上限，以及針對重度用戶的高價訂閱（每月 50 至 100 美元甚至更高）。這種判斷的依據在于：如今普通用戶僅用每月 20 美元，就可以完成過去可能需要數萬美元外包成本的工作。

在這一邏輯下，即便模型推理成本正在下降，總體支出仍可能持續上升——因為用戶規模擴大、上下文長度增加，以及任務復雜度提升，都會不斷推高整體算力消耗。因此，無論是提高價格、收緊配額，還是引入更多限制，在部分用戶看來幾乎是“不可避免”的趨勢。

當然，也有聲音以更直觀的方式表達了當前的使用困境。有用戶調侃稱，也許未來某一天，自己能夠攢夠足夠的 token，至少嘗試一次這個功能，而不至于消耗掉整整一周的額度。

OpenAI 同日發布新插件，
把手伸進 Claude 生態

值得注意的是，昨天 OpenAI 連夜也發布了一個新插件 codex-plugin-cc，能讓開發者直接在 Claude Code 里調用 Codex 做代碼審查、對抗性審查，甚至把任務整個移交給 Codex 執行。

從產品策略上看，這并不是簡單的兼容或適配，而更像是一種“反向滲透”：Claude Code 已經形成了自己的插件生態，而 OpenAI 選擇以官方身份入場，將 Codex 明確定位為工作流中的“第二意見系統”。它不直接接管主流程，而是在關鍵節點提供獨立判斷，形成一種帶有對抗性的協作關系。

這一插件（codex-plugin-cc）的設計非?？酥?，核心只提供三類命令，但覆蓋了開發流程中最關鍵的風險點。

首先是/codex:review，用于執行標準的只讀代碼審查。這一模式不修改代碼，重點在于識別常規問題，例如代碼質量、結構缺陷或潛在錯誤。

其次是/codex:adversarial-review，這是插件中更具特色的能力。它并不滿足于表層檢查，而是主動挑戰現有實現中的“隱藏假設”，例如邊界條件、權限邏輯或系統耦合點。這類審查尤其適用于高風險場景，如系統遷移、鑒權機制調整或基礎設施腳本變更，本質上是在用另一套模型思維對現有方案進行“壓力測試”。

第三個命令/codex:rescue則更進一步——它允許開發者在任務陷入停滯時，直接將控制權交給 Codex，由其重新規劃和執行。

OpenAI 推出的新插件，在 X 上引發了用戶的廣泛討論。有用戶表示，“直接告訴 Claude 用 Codex 執行器和 tmux，也是可以達到這種效果的，何必多此一舉?！?/p>

但 OpenAI Codex 團隊成員 Dominik Kundel 在該用戶下方回復，可以自己去試試上述提到的方法。Dominik 的言外之意或許是：如果這樣可以，那我們還做新插件干什么！

也有用戶提出疑問，使用 Codex MCP 和這個新插件有什么區別？

Dominik 在評論區回復該用戶時解答道：“Codex MCP 是一個更簡潔但功能更有限的界面。該插件底層使用 Codex 應用服務器。它與 Codex 應用使用相同的協議，因此可以更方便地添加功能，例如從應用 /CLI 添加實際的審閱功能。由于它不是 MCP，因此也不會像 MCP 那樣占用過多上下文窗口空間。如果 MCP 對您來說很好用，那就太好了！這是一個替代方案。”

https://code.claude.com/docs/en/computer-use

https://x.com/search?q=Claude%20code%20compute%20use%20&src=typed_query

https://x.com/sota0805/status/2038750897984204929

聲明：本文為 AI 前線整理，不代表平臺觀點，未經許可禁止轉載。