Claude Code开始“会用电脑”，OpenAI则用Codex插件直接切入其开发者生态。
原文标题：Claude Code刚放出大招，转眼就被群嘲“用不起”！OpenAl趁机甩出最阴插件，直接偷家
原文作者：AI前线
冷月清谈：
技术上，这项能力建立在 Agent Loop 与内置 MCP 服务器之上。Claude 会在不同执行方式间做选择，GUI 操作更多作为兜底方案，以平衡通用性、效率和精度。权限方面采用按需授权，且以会话为单位生效，用户可看到将访问的应用、可能涉及的额外权限及对当前环境的影响，降低长期滥用风险。
社区反馈明显分化。认可者看重它让 AI“会用电脑”的意义，质疑者则集中吐槽成本高、token 消耗重、仅限 Mac、与既有产品定位存在混淆。不少用户担心，随着用户规模和任务复杂度上升，未来价格上涨、配额收紧可能是大概率事件。
同一天，OpenAI 发布 codex-plugin-cc，允许开发者在 Claude Code 中直接调用 Codex 进行代码审查、对抗性审查和任务接管。相比单纯兼容，这更像是在 Claude 生态里嵌入一个“第二意见系统”，显示出两家在开发者工具和工作流入口上的正面竞争。
怜星夜思：
2、文章里很多人吐槽这类功能“很酷但用不起”，你觉得 AI 开发工具未来更可能走向高价专业化，还是低价普及化？
3、OpenAI 把 Codex 插件放进 Claude Code，这种“在对手地盘上提供第二意见”的做法，你觉得是开发者受益，还是生态竞争会变得更混乱？
4、如果这类“会用电脑”的能力以后扩展到 Windows、Linux 甚至企业内网系统，你觉得最大的阻力会是技术问题，还是权限与安全问题？
原文内容
在各大厂狂卷开发者工具生态之际，Anthropic 也在频繁推出新工具。
北京时间昨天夜里，Anthropic 宣布在其开发工具 Claude Code 中引入一项极具突破性的能力——“Computer Use”（计算机操作能力）。这一功能目前以研究预览（research preview）形式在 macOS 平台上线，允许 Claude 直接通过命令行界面（CLI）操控用户计算机，实现从代码编写到应用验证的完整闭环。
传统的 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 不仅“会写代码”，还“会用电脑”。
从技术角度来看，“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，也是可以达到这种效果的，何必多此一举。”
但 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 前线整理，不代表平台观点，未经许可禁止转载。
