Codex 到底在哪里工作：App、CLI、IDE 与 Cloud 中文导读

四个入口都开着，任务却一步没动

你只是想修一个手机页面。Codex App、CLI、IDE 和 Cloud 却同时摆在眼前。每个入口都像能做，点开以后又都需要重新解释一遍背景。

新手很容易把这当成功能选择题。其实真正的问题只有三个：文件现在在哪里，动作要在哪里发生，最后的证据要去哪里看。

入口不是能力排行榜，它是任务的工作现场。 这节课会让同一个页面修复任务走过四个入口。你跟着一张选择卡，看清哪一步会多搬上下文，哪一步最容易留下可验收结果。

先纠正一个常见误解

Codex 不是只有一个聊天框。OpenAI 的 Quickstart 把它放在多个工作表面：桌面应用、终端 CLI、IDE 扩展和云端任务。它们共享“让 agent 理解目标、读取上下文、执行动作、给出结果”的基本能力，但上下文来源、运行位置和交付方式不同。选择表面不是偏好题，而是任务设计的一部分。

这篇中文导读不是逐字翻译。它把五份官方页面中分散的产品事实重新编排成一个选择模型；界面名称和支持范围变化较快，页面底部保留了校准来源。

四个表面分别解决什么问题

工作表面	上下文主要来自哪里	动作发生在哪里	最适合的工作	需要特别检查
Desktop App	project、chat、选择的本地文件夹、上传文件	本地工作区或应用提供的工具	多文件产物、并行项目、浏览器验收、长任务	当前 project、文件夹和权限
CLI	当前目录、终端会话、AGENTS.md、配置与命令输出	本地终端和工作区	探索仓库、编辑、测试、脚本与自动化	当前目录、Git 状态、/status 与权限
IDE	打开的仓库、当前文件、选中代码、编辑器上下文	本地编辑器和终端工具	边读代码边解释、局部修改、快速反馈	打开或选中的内容是否真的相关
Cloud	已连接仓库、可复现环境、任务 prompt	隔离的云环境	后台任务、并行尝试、从 GitHub 等入口委派	环境依赖、秘密、联网和仓库授权

桌面端适合“我需要同时管理项目、文件和长任务”；CLI 适合“我的真实工作循环已经在终端”；IDE 适合“上下文就在正在看的代码旁”；Cloud 适合“任务应在隔离环境后台运行，或需要同时比较多个尝试”。

不要用“简单或复杂”做唯一判断

一个只有三行的配置修改，若必须读仓库规则、运行测试和检查 diff，仍然适合 Codex。一个长达两千字的解释，如果只依赖你给出的文本且不产生文件动作，普通 Chat 可能更合适。

使用四个问题：

1. 关键上下文是聊天输入、上传资料，还是一个真实工作区？
2. 结果只是回答，还是要留下文件、代码、报告、网页或可重复命令？
3. 任务要在本地完成，还是应在隔离云环境后台推进？
4. 最终证据是文本复核、diff、测试、浏览器行为，还是 Pull Request？

如果第四题回答不出来，先不要选“最强”的入口，因为你还没有定义完成。

同一任务如何在不同表面流动

假设目标是修复一个移动端页面：

• 在 IDE 中选中相关组件，适合快速解释布局结构；
• 在 CLI 中检查仓库规则、搜索样式、运行类型检查和测试；
• 在 Desktop App 中可以把改动、浏览器验证和截图放在同一个项目里；
• 在 Cloud 中可以让两个隔离任务尝试不同方案，再比较 diff。

这不表示必须四个都用。正确做法是选一个主表面，只有当上下文或运行方式确实改变时才切换。频繁复制对话会丢掉实际检查过的文件、命令结果和审批历史。

第一次选择练习

下载《工作表面决策表》，为你的任务填写：

目标结果：
必须读取的上下文：
必须执行的动作：
动作运行位置：本地 / 云端 / 不需要执行
完成证据：
主工作表面：
不用其他表面的原因：
需要的权限：

合格示例

目标结果：修复订单页 390px 宽度下的横向溢出，不改变桌面布局
上下文：真实仓库、设计截图、现有测试、项目 AGENTS.md
动作：修改 CSS，运行测试和构建，用浏览器验证两个视口
运行位置：本地
证据：diff、测试通过、390×844 与 1280×720 截图
主表面：Desktop App 或 CLI
不用 Cloud：需要本机已有浏览器和未提交工作区上下文
权限：只写当前工作区；不部署、不访问生产数据

不合格示例

“任务比较复杂，所以用 Codex Cloud。”复杂并不等于需要云端。若任务依赖未提交的本地改动或本机服务，云环境反而缺少关键上下文。

版本与可用性提醒

官方页面会随产品快速变化。安装方式、支持平台、入口名称、Cloud 集成和模型可用性都属于高漂移信息。学习时记住选择逻辑；真正操作前，回到下方官方链接核对当前界面和命令。

完整案例：同一个移动端缺陷，四个表面如何分工

假设你收到一个问题：“订单页在手机上会横向滚动，但桌面正常。”这句话还不足以决定工作表面。先把任务拆成四类需求：

需求	需要的上下文	最自然的表面	可复查证据
理解组件关系	当前文件、调用方、样式来源	IDE	文件清单与布局解释
查找真正溢出元素	完整仓库、运行命令、浏览器	App / CLI	DOM 测量与复现步骤
比较两种独立实现	可复现环境、干净基线	Cloud / worktree	两份 diff 与验证结果
做最终验收	本地真实服务、目标视口	App + Browser	桌面和移动端行为记录

如果本机工作区里已有未提交设计改动，直接把任务交给没有这些状态的云环境，可能得到一份逻辑正确却覆盖用户工作的 patch。相反，如果只是要解释一个选中的函数，把整个仓库交给长任务也会增加无关检查。选择表面的关键不是“谁能力最强”，而是谁拥有完成这一步所需的最小充分上下文。

一条可靠的表面切换记录

当任务确实需要切换表面时，先留下交接记录：

当前目标：修复 390px 下订单表格溢出
已确认：溢出来自表格最小宽度，不是页面容器
当前状态：尚未修改；工作区有用户自己的 header.tsx 改动
下一步：在本地分支只修改 OrderTable.tsx 与相关测试
验证：390×844 无横向滚动；1280×720 不回归
不要做：不要暂存 header.tsx，不要部署

这份记录的价值是保留事实、所有权和停止点，而不是复制整段聊天。

故障诊所：表面选错时会出现什么

现象	可能原因	先检查什么	恢复方式
回答很合理，却没有读真实代码	任务仍停留在普通 Chat	是否提供了仓库或文件入口	转到能读取工作区的表面，并要求先报告证据
Cloud 结果无法在本机应用	环境、分支或未提交状态不同	基线 commit、依赖和秘密	补环境说明，缩小为可独立 patch
IDE 修改只解决局部，运行后仍失败	选中内容缺少调用链	入口、调用方、测试与运行时	让 Codex 扩展只读调查范围，再决定修改
多个表面给出互相冲突的结论	基线和验收口径不同	每次运行使用的文件和命令	统一基线，只保留有环境证据的判断

自测：不要凭产品名称作答

1. 任务需要本机登录态浏览器，但不改代码，主表面应由什么决定？
2. 任务要后台比较三个独立重构方案，但本机有未提交改动，切到 Cloud 前必须留下哪些基线？
3. 只需要解释当前选中函数时，为什么 IDE 往往比创建长时 Cloud 任务更合适？

参考判断：分别从“关键上下文在哪里”“动作在哪里发生”“证据在哪里复核”作答，而不是从任务字数或产品新旧程度作答。

下次别先点产品，先画现场

把下一项任务写在纸上，只标三件事：事实在哪里、动作在哪里、结果在哪里验收。答案自然指向某个入口时再打开 Codex。

如果四个入口仍然都像可以用，不要猜。先选动作最少、证据最直接的那个。产品界面会变，这个判断不会跟着按钮一起过期。

完成检查

• 我能说出四个表面的上下文来源，而不只是产品名称
• 我为任务定义了动作发生位置与验收位置
• 我解释了为什么不选择另外至少一个表面
• 我没有把“复杂”误当成使用 Cloud 的充分理由
• 我知道产品可用性和入口应回查官方页面