Codex 让 AI"用电脑"的三种途径：Computer Use、Chrome 扩展、应用内浏览器

Codex 让 AI"用电脑"有三种途径：Computer Use、Chrome 扩展、应用内浏览器。三者功能重叠，容易混淆。读完这篇，你就能分清它们各自的安装方式、触发口令、适用场景，以及如何让 Codex 自己选对工具。

先记住一条总原则

能用插件或 MCP，就别用图形操控。

• Slack 插件能精确抓取一段对话，比在 Slack 里点来点去靠谱得多；
• GitHub 插件产生的操作比驱动网页更容易审计；
• 图形控制最有价值的场景，是结构化工具失效的那条边界——也就是 API 和插件覆盖不到的地方。

理解了这一点，再往下看三种方式。

一、@Computer：万能，但最慢

Computer Use 是三种方式里覆盖面最广的。它让 Codex 在 macOS 和 Windows 上看到并操作图形界面——窗口、菜单、键盘输入、剪贴板，都能在经过你授权的 App 里使用。

代价是它通常也最慢。插件可以直接调 API，而 Computer Use 必须：看界面 → 判断点哪里 → 等应用响应 → 检查下一帧状态。这个视觉循环很费时间，但换来一个关键能力——它能动那些没有任何 API 的 App。

在 macOS 上，“慢"不等于"打扰”。它能在后台默默操作授权过的 App，你可以继续用电脑干别的事。我就经常一边用 Codex，一边发现它悄悄把某个流程跑完了。

具体能驱动什么，取决于你装了什么、授权了什么：

• 原生桌面应用（Spotify、财务软件等）
• iOS 模拟器、iPhone Mirroring
• 系统设置、应用设置
• 没有插件/ API 的数据源
• 跨多个 App 的串联流程
• 某个结构化集成里"缺的那一步"

怎么装：Codex 里进 Settings > Computer Use，点 Install。

怎么触发：在 prompt 里提到 @Computer，或直接让它用 Computer Use。模型越来越聪明后，它会在需要时自己调用。

几个典型用法：

• 打开 Spotify，找到 Discover Weekly 并播放——但别动账号和订阅设置；
• 打开 iPhone Mirroring，复现 iOS App 的某个 onboarding bug，截图后修最小相关代码，再跑一遍；
• 它还能当结构化流程的"最后一公里"：比如某个流程能从 Slack 读反馈、改代码、渲染视频，但 Slack 集成上传不了文件——Computer Use 点一下"添加文件"就补齐了。

我最喜欢的一个例子，是从一个被偷的快递开始的：Amazon 说转接客服要等约 25 分钟。我给一个 Codex 线程开了 Computer Use，让它每 5 分钟检查一次聊天窗口，客服出现后改成每分钟一次，尽力争取退款。等我洗完澡回来，退款已经到账。

信任边界：这是三者里最宽的边界。一次只给它一个明确的 App 或流程；敏感 App 不用就关掉；遇到权限弹窗要审；涉及财务、账号、支付、凭据、隐私、系统安全的操作，务必在场盯着。

二、@Chrome：要多 Tab 和已登录身份时用它

Chrome 扩展让 Codex 访问你已登录的 Chrome 状态。任务依赖账号、Cookie、浏览器配置或已认证 Tab 时，选它。

适合的场景：

• Gmail、LinkedIn
• Salesforce、客服控制台
• 内部 Dashboard
• 跨多个站点的已登录调研
• 依赖账号或浏览器扩展的表单

怎么装：Codex 里进 Plugins，添加 Chrome，按引导装扩展、授权权限。扩展显示 Connected 后，开个新线程。

怎么触发：提 @Chrome，或明确让它用你已登录的 Chrome。

Chrome 任务跑在标签组里，同一个线程的标签会聚在一起。和内嵌浏览器不同，它带着你的浏览器身份——能力更强，但也更敏感。

它最大的优势是多 Tab 控制：能同时把好几个 Tab 关联到同一任务，在一个 Tab 读上下文、另一个 Tab 对比、第三个 Tab 继续推进。Computer Use 也能视觉驱动浏览器，但 Chrome 是把它当浏览器工作流来理解，而不是一连串屏幕坐标。

举个真实的例子：我把一个已经打开的 Strudel Composer（音乐作曲）标签丢给 Codex，让它把音乐改得更精彩。Chrome 把这个 Tab 连同页面的 WebMCP 工具一起给了它。Codex 检查作品、重写和声和四分钟的曲式、改速度、保存、让曲子继续播放——全程不用视觉到处找控件，因为 Chrome 把 Tab 上下文和页面暴露的结构化能力合在了一起。

我还用它跑一条长期 Twitter 线程，指令大致是：每天用 Chrome 检查 DM、读相关新闻、找该知道的反馈或提及，把值得留的写进我的知识库，但不要发帖或发消息。

有意思的地方不是"Codex 能打开 Twitter"，而是这条线程能长期回到同一份已登录的工作，把发现的东西连到本地文件，留下一份可审阅的结果。

信任边界：网站可能把 Codex 的点击、提交、发消息当作你本人操作；页面内容本身也是不可信输入。所以重大步骤要明确分开：调研、导航、起草可以自动跑；发送、发布、购买、提交前必须你过目。

一句话选择：任务全程在浏览器里——优先 Chrome，不要 Computer Use。Chrome 有任务需要的浏览器原生上下文，又不开通对桌面其余部分的访问。

三、@Browser（应用内浏览器）：给你正在做的网站用

应用内浏览器是长在 Codex 线程里的浏览器，你和 Codex 共享同一个渲染页面，特别适合构建和调试 Web 应用。

我通常从这里起步：

• 本地开发服务器
• 基于文件的预览
• 不需要登录的公开页面
• 复现视觉 bug
• 检查响应式布局
• 留元素级的设计反馈

关键约束是隔离：它不用你日常的浏览器配置、Cookie、扩展、已登录会话、已有标签。任务需要账号时这是限制；任务不需要账号时，这是个有用的边界。

怎么装：Codex 里进 Plugins，添加 Browser 插件并启用。

怎么触发：提 @Browser，或明确让它用应用内浏览器。

例：用 @Browser 打开 http://localhost:3000/ 上的 vite 应用，复现移动端溢出 bug，修掉它，然后在桌面和移动两种宽度下再验证同一路由。

这就形成一个紧凑的反馈闭环：改代码 → 操作页面 → 检查渲染状态 → 截图 → 修完再跑一遍。

我最喜欢的是标注功能。审本地应用时，我能直接点某个元素或框选一片区域，留一条评论。样式控件还能让我对文字、字体、间距、颜色给出更精确的反馈。我经常配合语音输入和引导用：一边审页面、留评论，一边在 Codex 处理时继续排队新的反馈——页面本身就成了需求文档。

这对设计活儿特别有用。我常让 Codex 把一个想法、研究资料或项目状态做成一个单文件 index.html，再在应用内浏览器打开。然后我直接在真实页面上标注：“这个层级反了”、“这别做得像卡片”、“这些控件得留多点空间”、“全部用这套字号”——Codex 收到评论（附带相关截图和元素上下文）后改文件，重新打开同一页再来一轮。

这个循环更像和设计师在同一块画布上协作，而不是来回传截图和文字。

应用内浏览器也能当混合流程的起点。有次我在应用内浏览器打开一条 X 帖子，让 Codex 调研讨论；可见页面确定了"我说的是哪条"，随后 Codex 切到 Twitter CLI，拉出 38 条回复，包括浏览器视图里被折叠的嵌套回复。这就是最小化边界原则的实战：浏览器拿来定位可见上下文，结构化工具用来深挖数据。

取舍：让应用内浏览器成为好开发环境的"隔离"，也意味着它不适合跟 Google 登录、Passkey、依赖浏览器扩展的站点较劲——身份相关的事，转去 Chrome。

四、Appshots：不是第四种控制方式

Appshot 不是第四种控制方式，而是让你把眼前已有的上下文指给 Codex 看。

在 Mac 上按 ⌘ + ⌘（连按两次 Command），Codex 会把最前面的窗口截下来，把图片和可提取文本一起附到线程。你可以对错误、邮件、设计稿、设置面板、陌生表单各来一张，然后简单说一句就行。

记住这个心智模型最省事：Appshots 是你给 Codex"指东西"用的；Browser、Chrome、Computer Use 才是 Codex"动手"用的。

目前 Appshot 只能从 macOS 的 Codex App 创建，截的是最前面的窗口（不是整个桌面），所以它很适合给聚焦的上下文，而不必交出对那个 App 的控制权。

五、怎么选？一张速查表

三条原则收尾：

1. 能用结构化工具就别用图形控制——图形控制只在工具失效的边界最有价值；
2. 任务全在浏览器里，优先 Chrome 而非 Computer Use；
3. 身份敏感或需要账号，从 Browser 移到 Chrome。

掌握了这几点，你就能让 Codex 在对的场景里用对的工具，而不是一律用最慢、最宽的那条路。