这篇整理自 jason（X：@jxnlco）的《Three Ways Codex Can Use a Computer》。
OpenAI 的 Codex 现在能直接「用电脑」了，而且不止一种方式。麻烦也在这：它常用的有三种操控界面——Computer Use（@Computer）、Chrome 扩展（@Chrome）、应用内浏览器（@Browser），三者的能力刚好重叠到让人分不清该用哪个。
下面把它们拆开讲：各自适合什么场景、怎么安装触发、信任边界在哪，以及 Appshots 又是怎么回事。
先说一条总原则
展开之前，先记住一句话：能用插件 / MCP，就别用可视化操控。
Slack 插件检索一条讨论串，比让 AI 在界面上瞎点更精确；GitHub 插件产生的操作，也比直接驱动网页更容易检查。可视化控制最有价值的地方，其实是结构化工具够不着的那条边界：当一个 app 根本没有可用的 API 时，看屏幕、点按钮才是唯一的出路。
带着这条原则看下面三种方式，就清楚了。
三种方式速览
| 方式 | 触发 | 本质 | 最适合 | 信任边界 |
|---|---|---|---|---|
| Computer Use | @Computer |
看屏幕、操作窗口 / 菜单 / 键盘 / 剪贴板 | 没有 API 的原生桌面应用、系统设置、模拟器 | 最宽，最需要盯着 |
| Chrome 扩展 | @Chrome |
复用你已登录的 Chrome 状态 | 需要账号 / Cookie、多标签页的网页任务 | 携带你的浏览器身份，敏感 |
| 应用内浏览器 | @Browser |
隔离的内置浏览器，与你共享同一渲染页面 | 本地开发、调试 Web 应用、设计标注 | 隔离，不带你的身份 |
1. Computer Use：万物皆可 @Computer
Computer Use 是三者里最通用的一个。它让 Codex 在 macOS 和 Windows 上「看见」并操作图形界面——在你授权的应用里操作窗口、菜单、键盘输入和剪贴板。
代价是它通常也最慢。结构化插件可以直接调 API，而 Computer Use 必须：看界面 → 决定点哪 → 等应用响应 → 检查新状态。这个视觉循环很费时间，但好处是它能对付那些完全没有可用 API 的应用。
在 macOS 上，慢不一定等于打扰。Computer Use 可以在后台操作已授权的应用，你照常用电脑的其他部分。有时用着用着打开某个 app，会发现 Codex 一直在后台默默跑完了某个流程。具体能操作什么，取决于你装了什么、授权了什么：Spotify、Xcode、系统设置、iOS 模拟器，甚至 iPhone 镜像（用来控制你的 iPhone）。一个流程跨多个应用时，它还能在应用之间切换。
什么时候用它：
- 原生桌面应用，比如 Spotify 或某个金融 app
- iOS 模拟器、iPhone 镜像，或其他只有 GUI 的流程
- 系统或应用设置
- 没有插件、没有 API 的数据源
- 需要在多个应用之间来回的工作流
- 某个本来很好用的结构化集成里，缺了一个动作（最后一公里）
怎么装 / 怎么触发： 在 Codex 里打开 设置 > Computer Use，点 Install。触发时 @Computer，或直接让 Codex 用 Computer Use。他说随着模型变强，以后它能在需要时自己调用。
他举过一个例子：包裹被偷了，亚马逊提示要等约 25 分钟才能接到人工客服。他丢给一个 Codex 线程 Computer Use，让它每 5 分钟看一次聊天、客服一出现就改成每分钟看一次、尽力争取退款——洗个澡回来，退款已经办好了。
另一个例子是拿它补「最后一公里」。一次发布视频里，Codex 能从 Slack 读反馈、改代码、渲染新视频，可那条线程里的 Slack 集成偏偏不能上传文件。于是 Computer Use 去点了一下「添加文件」，把缺的那一步补上了。
信任边界： 这是三者里最宽的信任边界。一次只给它一个清晰的应用或流程；与任务无关的敏感应用就关掉；权限提示要认真看；涉及钱、账户、支付、凭证、隐私和系统安全的变更，得全程在场。
2. Chrome 扩展：多标签页与登录态用 @Chrome
Codex 的 Chrome 扩展，让它能访问你已经登录的 Chrome 状态。当任务依赖你已有的账号、Cookie、浏览器配置或已认证的标签页时，就用它。
适合的场景，比如：
- Gmail、LinkedIn
- Salesforce 或某个客服后台
- 内部仪表盘
- 跨多个网站、需要登录的资料检索
- 依赖你账号或浏览器扩展的表单
怎么装 / 怎么触发： 在 Codex 里打开「插件」，添加 Chrome，跟着引导装好 Codex 的 Chrome 扩展并授权。扩展显示「已连接」后，新开一个线程。触发时 @Chrome，或直接让它用你已登录的 Chrome。
它比 Computer Use 强在两点。一是携带你的浏览器身份：Chrome 任务以「标签页组」运行，把同一线程的标签页归在一起，这让它更强，也更敏感。二是多标签页控制：它能把多个标签页关联到同一任务，在一个里读上下文、跟另一个对比、再到第三个里继续。Computer Use 也能可视化地驱动浏览器，但 Chrome 是把整件事理解成「浏览器工作流」，而不是一连串屏幕坐标。
他举了两个例子。一次他把一个已经打开的 Strudel Composer 标签页交给 Codex，让它「把音乐做得更有趣」。Chrome 把选中的标签页和页面的 WebMCP 工具一起给了 Codex，于是它检查乐曲、重写和声与四分钟曲式、改速度、存轨、留着播放——不用挨个去视觉搜索控件，因为标签页上下文和页面暴露的结构化能力被结合在了一起。另一个是长期跑的 Twitter 例行任务，指令大致是：
每天用 Chrome 看我的私信、读相关新闻，找出我该知道的反馈或提及。把有长期价值的东西存进我的 vault。不要发帖、不要发消息。
有意思的不是「Codex 能打开 Twitter」，而是这条线程能随时间回到同一个登录态里继续干活、把发现的东西和本地文件关联起来，最后留给你一个可复核的结果。
信任边界： 网站可能会把 Codex 的点击、表单提交、发消息当成你本人的操作，页面内容本身也是不可信输入。所以要把有后果的步骤显式留给自己：研究、导航、起草可以自动做；发送、发布、购买、提交之前，必须经你审核。
如果整个任务都在浏览器里完成，优先用 Chrome 而不是 Computer Use——它有任务所需的浏览器原生上下文，又不必把整个桌面的访问权打开。
3. 应用内浏览器：给你正在做的网站用 @Browser
应用内浏览器是一个活在 Codex 线程里的浏览器。你和它共享同一个渲染后的页面，所以它特别适合开发和调试 Web 应用。
他会从它开始上手的场景：
- 本地开发服务器
- 基于文件的预览
- 不需要登录的公开页面
- 复现视觉 bug
- 检查响应式布局
- 留下元素级别的设计反馈
它最关键的限制是隔离：不用你平时的浏览器配置、Cookie、扩展、登录态或现有标签页。需要账号时这是限制；不需要账号时，这反而是个好用的边界。
怎么装 / 怎么触发： 在 Codex 里打开「插件」，添加 Browser 插件并启用。触发时在 prompt 里 @Browser，或直接让它用应用内浏览器。比如：
用
@Browser打开 localhost:3000 上的 Vite 应用，复现移动端溢出 bug，修好它，再在桌面和移动宽度下验证同一个路由。
这样就形成了一个紧凑的反馈闭环：Codex 改代码 → 操作页面 → 检查渲染状态 → 截图 → 修完再跑一遍。
他最喜欢的是标注功能。审阅本地应用时，可以直接点某个元素或框选一块区域留评论，样式控件还能让他更精确地反馈文字、字体、间距和颜色。他常把它和语音输入、即时引导结合：边看页面边留评论，边给 Codex 排队更多反馈。用他的话说，页面本身就成了规范。他经常让 Codex 把一个想法、研究资料或项目状态先变成一个单文件 index.html，在应用内浏览器里打开，然后直接在页面上批注——「这个层级是反的」「让它别那么像卡片」「这些控件要更多空间」「所有地方都用这套字号」。这种体验，比来回传截图和文字描述，更接近和设计师在同一块画布上协作。
它也适合作为混合工作流的起点。他还有个例子：先用应用内浏览器打开一条 X 帖子，确认「我说的是哪条」，再让 Codex 切到 Twitter CLI，结果取回了 38 条回复，包括浏览器视图里被折叠的嵌套回复。这正是「最窄表层原则」的实战：先用浏览器看屏幕上的上下文，再用结构化工具做更深的检索。
它也有代价。让它成为好开发平台的那个隔离性，也意味着它不适合去硬刚 Google 登录、Passkey，或依赖你浏览器扩展的网站。身份一重要，就转去 Chrome。
Appshots：不是第四种操控方式
Appshot 不是 Codex 控制电脑的第四种方式，而是把你眼前已有的上下文「指给」它看的手段。
在 Mac 上连按两下 CMD（CMD+CMD）截取最前面的窗口，Codex 会把这张图和能提取到的文字附到线程里。报错、邮件、设计稿、设置面板、不熟悉的表单，都可以 Appshot 一下，然后直接开口问。他觉得最好记的心智模型是这样：
Appshots 是你「指」向电脑上的某样东西；Browser、Chrome、Computer Use 是 Codex「动手」的方式。
Appshots 目前在 macOS 的 Codex 应用里创建，只截最前面那个窗口、不是整个桌面，所以它能在不交出应用控制权的前提下，提供聚焦的上下文。
怎么选：一张简单的决策图
把上面的原则收一下，实际选择其实很直接：
- 任务全在浏览器里、且需要你的登录态？→
@Chrome - 任务全在浏览器里、不需要登录（本地开发 / 公开页 / 调样式）？→
@Browser - 要碰桌面原生应用、系统设置、模拟器，或某个集成缺了最后一步？→
@Computer - 只是想把眼前的窗口内容喂给它？→ Appshot
- 任何时候，只要有现成的插件 / MCP / CLI 能干这件事，就优先用它们，别用可视化操控
关于
关注我获取更多资讯
