Title: 【第 3721 期】讲透 Codex 操控电脑的三种方式 | BestBlogs.dev
URL Source: https://www.bestblogs.dev/article/944f1440?amp%3Butm_medium=feed&%3Butm_campaign=resources&%3Bentry=rss_article_item
Published Time: 2026-06-22 09:00:00
Markdown Content: 80
This article details three ways Codex controls a computer: computer control, Chrome extension, and built-in browser, and compares their applicable scenarios and trust boundaries. 前 前端早读课
Today 4021 words (about 17 min) View Source →
Sign in to highlight text and take notes as you read. Sign in now
jason 2026-06-22 09:00 福建
Codex 操控电脑有三种方式，你用过哪些？
前言
Codex 操控电脑有三条路径：「电脑操控」驱动桌面原生应用，适合无 API 的软件与跨应用流程；Chrome 扩展继承登录态，擅长多标签页协同与身份认证场景；内置浏览器嵌入对话，是本地开发调试与视觉反馈的利器。三者功能有所重叠，但各擅胜场 —— 选对工具，才能事半功倍。
这个月也是买入 Codex Plus 会员了，上周也配置了在 ChatGPT App 连接电脑 Codex App 了，一切良好。今日前端早读课文章由 @jason 分享，@飘飘编译。
译文从这开始～～
Codex 有三种方式来操作电脑：电脑操控（Computer Use）、Chrome 扩展，以及内置浏览器。 【早说】Codex 不止 OpenAI，全面拥抱开源大模型！
三者的功能恰好有些重叠，容易让人摸不着头脑。
读完这篇文章，你将了解如何安装和触发这三种方式、各自适用的场景、Appshots 和开发者模式如何将它们串联起来，以及如何在 AGENTS.md 中做好配置，让 Codex 自行选择最合适的操作方式。
简而言之：
话虽如此，能用插件或 MCP 的时候，尽量优先用它们。Slack 插件检索一条消息远比在界面上点来点去精准得多；GitHub 插件产生的操作也比直接驱动网页更易于审查。视觉操控真正大显身手的地方，恰恰是结构化工具力所不及的边界地带。
#### 1. 万物皆可 @Computer
「电脑操控」是三种方式中覆盖面最广的。它让 Codex 能够在 macOS 和 Windows 上感知并操作图形界面 —— 包括窗口、菜单、键盘输入和剪贴板，前提是你授权了相应的应用。
当然，它通常也是最慢的。结构化插件可以直接调用 API，而「电脑操控」则需要先观察界面、判断点击位置、等待应用响应，再检查下一步的状态。这个视觉循环确实耗时，但也意味着 Codex 能驾驭那些完全没有可用 API 的应用。 【第3705期】让 Codex 物尽其用：从编程助手到全能工作系统
在 macOS 上，慢并不意味着干扰。「电脑操控」可以在后台操作已授权的应用，丝毫不影响你使用电脑的其他部分。我经常一边用 Codex，一边打开某个应用，然后才发现 Codex 早已在后台默默地跑完了某个工作流。
根据你电脑上安装和授权的应用不同，它能操控的范围包括 Spotify、Xcode、系统设置、iOS 模拟器，甚至「iPhone 镜像」应用来控制你的 iPhone！它还能在多个应用之间无缝切换，应对跨应用的工作流。
适用场景：
* 原生桌面应用，如 Spotify 或财务软件
* iOS 模拟器、iPhone 镜像，或其他纯图形界面的操作流程
* 系统或应用设置的调整
* 没有插件或 API 的数据源
* 需要在多个应用之间流转的工作流
* 某个结构化集成中恰好缺失的那一步操作
安装方法： 打开 Codex 的「设置 > 电脑操控」，点击 "安装" 即可。
触发方式： 在对话中提及 @Computer，或直接让 Codex 使用「电脑操控」。随着模型不断进步，未来它会在需要时自动调用这项能力。
不妨试试以下几个例子：
我最喜欢的一个案例，起因是一个被偷的快递包裹。亚马逊告诉我大约需要 25 分钟才能接通人工客服。我把「电脑操控」权限交给一个 Codex 对话，让它每五分钟查看一次聊天窗口，一旦客服出现就切换到每分钟一次，然后尽力争取退款。我去洗了个澡回来，退款已经搞定了。
> 使用 @Computer 打开 Spotify，找到我的「每周发现」歌单并播放。不要更改我的账户或订阅设置。 > > > 使用 @Computer 打开「iPhone 镜像」，在 iOS 应用中复现新手引导的 bug，并截取出错状态的截图。修复最小相关代码路径，然后重新跑一遍同样的流程。
我还经常把「电脑操控」当作结构化工作流的 "最后一公里"。在一次发布视频中，Codex 能从 Slack 读取反馈、修改代码、渲染出新视频，但当时那个对话中可用的 Slack 集成无法上传文件。于是「电脑操控」接手，点击了 "添加文件" 按钮，补上了这缺失的最后一步。 【第3700期】善用 Codex goal模式
这也是三种方式中信任边界最宽的一种。每次只交给它一个明确的应用或流程。任务无关的敏感应用请保持关闭，留意权限提示弹窗，涉及财务、账户、支付、凭据、隐私和系统安全的操作，请务必亲自在场把关。
#### 2. @Chrome—— 多标签页与身份认证
Codex 的 Chrome 扩展让 Codex 能够访问你已登录的 Chrome 状态。当任务依赖于你现有的账户、Cookie、浏览器配置文件或已认证的标签页时，就该用它。
以下这些场景尤其适合：
* Gmail 或 LinkedIn
* Salesforce 或客服工作台
* 内部数据仪表盘
* 需要跨多个网站进行的登录态调研
* 依赖你的账户或浏览器扩展的表单填写
安装方法： 在 Codex 中打开「插件」，添加 Chrome，然后按照引导流程操作。Codex 会一步步带你安装 Chrome 扩展并授权所需权限。当扩展显示 "已连接" 后，新建一个对话即可开始使用。
触发方式： 在对话中提及 @Chrome，或直接让 Codex 使用你已登录的 Chrome 浏览器：
> 使用 @Chrome 查看当前打开的客户账户，与另一个标签页中的工单进行比对，补全缺失的字段。提交前停下，等我确认。
Chrome 任务会以标签页分组的形式运行，同一个 Codex 对话产生的标签页会自动归在一起。与内置浏览器不同，Chrome 扩展承载的是你真实的浏览器身份，这让它能力更强，同时也更敏感。
另一个显著优势是多标签页协同。Chrome 可以将多个标签页关联到同一个任务 —— 在一个标签页中读取上下文，在另一个中进行比对，再到第三个标签页中继续推进流程。「电脑操控」虽然也能以视觉方式驱动浏览器，但 Chrome 扩展是把操作理解为一个浏览器工作流，而非一连串屏幕坐标。
有一次，我把一个已经打开的 Strudel Composer 标签页交给 Codex，让它把音乐改得更有意思。Chrome 将选中的标签页及页面暴露的 WebMCP 工具一并交给了它。Codex 审视了整首曲子，重写了和声与四分钟的曲式结构，调整了速度，保存了音轨，最后让它自动播放。它不需要在界面上逐个寻找每个控件，因为 Chrome 能将标签页上下文与页面提供的结构化能力结合起来。
我还用这个方式维护一个长期运行的推特对话，指令大致是：
> 每天使用 Chrome 查看我的私信，浏览相关新闻，留意值得关注的反馈或提及。把有长期价值的内容存入我的知识库。不要发帖，也不要发送任何消息。
有意思的不是 Codex 能打开推特这件事本身，而是同一个对话可以在不同时间反复回到同一个已登录的工作状态，将发现的内容关联到本地文件，最后留给我一份可供审阅的结果。
信任边界同样不容忽视。网站会将 Codex 的点击、表单提交和消息视为你本人的操作。同时，页面内容本身也是不可信的输入。请将关键操作设为需要你明确确认的步骤：调研、导航、起草可以自动进行；但发送、发布、购买或提交之前，务必经过你的审阅。
如果整个任务都在浏览器内完成，优先选择 Chrome 而非「电脑操控」。Chrome 具备任务所需的浏览器原生上下文，无需开放对桌面其他部分的访问权限。 【第3685期】给 Codex 最好用的工具，是量身定制的命令行
#### 3. 内置 @Browser—— 为你正在开发的网站而生
内置浏览器是嵌在 Codex 对话中的一个浏览器。你和 Codex 共享同一个渲染页面，因此它特别适合用来构建和调试 Web 应用。
以下场景我都会首选它：
* 本地开发服务器
* 基于文件的页面预览
* 无需登录的公开页面
* 复现视觉 bug
* 检查响应式布局
* 在元素级别留下设计反馈
关键约束在于隔离性。内置浏览器不使用你日常的浏览器配置文件、Cookie、扩展、已登录的会话或现有标签页。当任务需要账户时，这是一个限制；但当任务不需要时，这恰恰是一道有益的安全屏障。
安装方法： 在 Codex 中打开「插件」，添加 Browser 插件并启用即可。
触发方式： 在提示词中提及 @Browser，或直接让 Codex 使用内置浏览器：
> 使用 @Browser 打开 http://localhost:3000/ 上的 Vite 应用，复现移动端溢出 bug，修复它，然后分别在桌面端和移动端宽度下重新验证同一路由。
这构成了一个极其紧凑的反馈闭环：Codex 可以编辑代码、操作页面、检查渲染状态、截图，然后在修复后再跑一遍整个流程。
我最喜欢的是标注功能。审查本地应用时，我可以直接点击某个元素或框选一块区域，留下评论。样式控件还能让我对文字、字体、间距和颜色给出更精准的反馈并即时预览。我习惯把标注和语音输入结合起来：一边审查页面、留下批注、排入更多反馈，一边让 Codex 逐条处理。页面本身就变成了设计规范。
这在设计工作中尤其好用。我经常让 Codex 把一个创意、调研资料包或项目进度整理成一个index.html文件，然后在内置浏览器中打开。比起在新的提示词中试图把整个设计用文字描述清楚，不如直接在真实页面上标注 ——"这里的层级关系反了"、"这块别做得那么像卡片"、"这些控件需要更多空间"、"全局统一用这套字号"。Codex 收到评论后，会同时获取相关截图和元素上下文，修改文件，再重新打开同一页面进入下一轮迭代。
> 根据这份项目简报生成一个单文件 index.html，并在内置 @Browser 中打开。
这个循环的体验，比起来回传截图、写文字说明，更像是和一位设计师在同一块画布上协作。
内置浏览器还很适合作为混合工作流的起点。在另一个对话中，我在内置浏览器里打开了一条 X（推特）帖子，让 Codex 深入了解相关讨论。可见的页面锁定了我指的是哪条帖子；随后 Codex 切换到 Twitter CLI，检索到了 38 条回复，包括浏览器视图中被折叠的嵌套回复。这就是 "最小权限原则" 的实际应用：用浏览器建立屏幕上的上下文，再用结构化工具完成更深层的数据获取。
当然也有取舍。正是这种隔离性让内置浏览器成为优秀的开发工具，但也意味着它不适合用来处理 Google 登录、Passkey，或依赖浏览器扩展的网站。当身份认证不可或缺时，请切换到 Chrome。 【第3673期】OpenAI Codex 最佳实践
#### Appshots（应用快照）
Appshot 不是 Codex 操控电脑的第四种方式，而是一种将你眼前的上下文指给 Codex 看的方式。
在 Mac 上，快速按两下 CMD 键即可捕获最近的窗口。Codex 会把截图和可提取的文字一并附加到对话中。你可以对一个报错、一封邮件、一张设计稿、一个设置面板或一个陌生的表单拍一张 Appshot，然后直接说你的需求。
最容易记住的心智模型是：
Appshot 是你指向电脑上某样东西的方式；Browser、Chrome 和 Computer Use 是 Codex 采取行动的方式。
Appshot 目前通过 macOS 上的 Codex 应用生成。它捕获的是最前端的窗口而非整个桌面，因此既能提供精准的上下文，又无需授予对该应用的操控权限。
关于本文
译者：@飘飘
作者：@jason
原文：https://x.com/jxnlco/status/2066970432855581052
这期前端早读课
对你有帮助，帮”赞“一下，
期待下一期，帮”在看” 一下。 阅读原文