我把 Codex App 当主力后,才看懂它最近在更新什么

我最近越来越少把 Claude Code 当唯一入口。不是因为 Claude Code 不强。它当然强。但对我来说，账号稳定性这件事已经从“偶尔担心一下”，变成了主力工具选择里的风险项。

如果一个工具只是偶尔帮我写几行代码，那它不稳定，最多是麻烦。如果它已经开始承接我的需求分析、代码修改、文档沉淀、工作流复盘，甚至帮我维护一整套本地规则，那账号和入口的不确定性，就不是小问题了。

这也是我近期把 Codex App 当成主力入口的原因。

更有意思的是，Codex 最近确实更新得很快。但这篇文章不是想把 CLI 更新逐条讲一遍。对我来说，真正改变使用习惯的是 Codex App 这条线：它开始更像一个能看见现场、承接长任务、接受远程使用和插件能力的主力工作台。

这不是“版本号大了一点”的问题。看完最近几版更新，我的判断是：Codex 正在从一个代码助手，变成一个更完整的 AI 工作台。

这几版更新，不只是多了几个按钮

我把最近几条官方更新压成一张表。重点不是背版本号，而是看它们解决了什么使用问题。

如果只看单点功能，可能会觉得它们很散：截图、浏览器、插件、远程、Goal、doctor、SDK、结构化输出。

但放到一起看，方向很清楚：Codex 在补一个主力工作台需要的五块能力。

第一，拿到真实上下文。第二，能跑更长任务。第三，能跨设备继续工作。第四，能复用规则和插件。第五，能诊断和治理自己的运行环境。

这五件事，比“某一次回答是不是更惊艳”更影响长期效率。

所以我现在的使用顺序很明确：日常高频交互优先用 Codex App；需要脚本化、结构化输出、诊断或自动化的时候，再把 CLI 当底层工具用。

Appshots：少一点描述，多一点现场

以前让 AI 改一个界面问题，经常要先讲半天：

“左上角那个按钮有点挤。”

“不是这个页面，是弹窗里的列表。”

“颜色不是背景，是 hover 状态。”

这类描述很容易失真。你以为自己讲清楚了，模型拿到的是一段二手转述。

Appshots 的价值就在这里。官方说明里提到，在 macOS 的 Codex app 中，可以同时按两枚 Command 键，把当前最前面的 app 窗口连同截图和可用文本发给 Codex。

这件事对写代码的人很实用。

它让“我看到的状态”直接进入上下文。尤其是 UI 调整、报错弹窗、设计稿对照、本地工具界面、浏览器页面状态，这些原本很难描述清楚的东西，现在可以变成 Codex 的输入。

我的建议是，不要把 Appshots 当截图工具用。它更适合这三类场景：

·页面已经跑起来了，但你不想重新描述布局问题。

·报错或弹窗里有上下文，复制文字会丢状态。

·你希望 Codex 直接根据当前界面提出下一步操作。

这类能力的本质不是“多模态很酷”，而是减少你替系统做上下文搬运。

Goal mode：适合长任务，但前提是目标要清楚

这次更新里，Goal mode 不再是实验功能，并且已经出现在 Codex app、IDE extension 和 CLI 里。

官方的描述很直接：你可以让 Codex 朝着一个具体目标推进数小时，甚至数天。

这听起来很强，但我反而会更谨慎地用。

因为长任务最怕的不是模型不努力，而是目标不清楚。如果你只说“帮我优化一下这个项目”，那它跑得越久，越可能把成本花在你本来不想改的地方。

我更建议把 Goal mode 用在有明确验收标准的任务上，比如：

·“把这个前端页面接入现有设计系统，保持现有 API 不变，最后跑 lint 和截图检查。”

·“按这个 workflow 生成一篇公众号文章，产物必须包含资料笔记、角度卡、蓝图、草稿、质检和发布包。”

·“排查这个构建失败，先定位根因，再给最小修改，不做顺手重构。”

也就是说，Goal mode 不是让你少思考目标，而是让你把目标写得更像任务契约。

我自己的规则是：长任务至少写清楚三件事。

第一，目标是什么。第二，哪些事不要做。第三，什么结果算完成。

如果任务跨小时甚至跨天，还要有阶段产物。否则所谓“自主推进”，很容易变成“带着假设继续往下跑”。

Remote 和 mobile：真正有用的是同一个工作环境

Codex 最近也在补远程能力。

2026 年 5 月 14 日的更新里，OpenAI 提到可以通过 ChatGPT mobile app 连接一台运行 Codex app 的 Mac。关键点不是“手机也能打开 Codex”，而是它会从那台连接的 host 上运行，所以同一套项目、文件、凭证、plugins、skills 和配置都还在。

这对我这种重度依赖本地工作流的人很重要。

很多 AI 工具的远程能力，本质上是另开一个干净环境。看起来随时随地，实际上一到复杂任务就缺仓库、缺权限、缺配置、缺本地脚本。

Codex 这条路线更像是：远程不是重新开始，而是接着你的主力机器往下跑。

当然，这也不意味着所有任务都应该在手机上处理。我的理解是，mobile 和 remote 更适合三类动作：

·看长任务进展，决定继续、暂停还是补充信息。

·处理明确的小修，比如改一段文案、补一个测试、调整一个配置。

·在外面突然想到一个任务，先丢给主机排队，回到电脑前再做最终确认。

别把手机当主战场。它更像一个能接上主机上下文的遥控器。

Plugins、skills 和 `@` mentions：把重复规则变成资产

我真正关心 Codex 的地方，不只是它能不能写代码。

更重要的是，它能不能记住我的工作方式。

CLI 0.131.0 里，`@` mentions 可以统一搜索文件、目录、plugins 和 skills。0.133.0 又继续增强插件发现和 marketplace 相关信息。app 26.519 还提到，ChatGPT Business 已经可以通过 marketplace sources 做 plugin sharing，团队可以分发包含 skills、app integrations、MCP servers、lifecycle hooks 的插件包。

这里我不会把 CLI 放到主角位置。我的实际偏好是：在 App 里完成大多数对话、看图、改稿、看浏览器状态和长任务推进；CLI 更适合放在背后，处理那些明确、可重复、可自动化的任务。

这条线很关键。

个人使用 AI 工具时，一个常见问题是：每次都要重新交代规则。

比如：

·这个仓库怎么跑测试。

·这个项目哪些目录不能动。

·写前端时用哪套组件。

·公众号文章要先做资料笔记和角度卡。

·小修不要默认加测试。

·工作流长任务必须有阶段门禁。

如果这些规则只停留在聊天里，它们就会不断丢失。你每次重新解释，AI 每次重新理解，最后很多错误不是能力问题，而是上下文管理问题。

Codex 的 plugins、skills、AGENTS.md、hooks、MCP 这些东西，真正价值是把重复规则变成资产。

我现在越来越倾向于一个顺序：先脚本，后 Skill，最后才是 Agent。

固定输入输出的事，交给脚本。需要判断但可复用的规范，写成 skill。真的需要动态拆解和多阶段推进时，再让 agent 工作。

这样做以后，AI 不再只是“聪明的对话框”，而是能进入你的工作系统。

CLI 退到背后：主力工具也必须可诊断

一个工具要成为主力，不能只看顺的时候多强，还要看坏的时候能不能排查。

CLI 0.131.0 加了 `codex doctor`，用于 runtime、auth、terminal、network、config、本地状态等诊断。0.132.0 里，`codex exec resume` 支持 `--output-schema`，让恢复后的自动化任务还能维持结构化 JSON 输出。

这两个点看起来不性感，但很重要。

因为真正跑工作流时，问题经常不在模型本身，而在环境：

·认证过期。

·本地配置没加载。

·插件没有注册。

·当前目录不对。

·任务恢复后输出格式漂了。

·远程连接和本地状态不一致。

如果没有诊断工具，这些问题会被误判成“AI 不行”。但它们很多其实是环境、配置、流程问题。

我判断一个 AI 工具能不能长期用，会看它有没有把这些脏活累活产品化。

`doctor` 这类能力就是信号：它开始承认自己不只是一个模型入口，而是一个需要被维护的运行系统。

那普通人现在该怎么用 Codex？

如果你也在考虑把 Codex 放到更重要的位置，我建议不要一上来就追所有新功能。

先做五件很具体的事。

第一，先把 Codex App 当主入口。

如果你平时需要看界面、改代码、读文档、对照截图、让它接着一个任务往下跑，App 的交互成本更低。CLI 适合明确命令，不适合所有人日常都拿来当主入口。

第二，检查版本。

至少知道自己本地跑的是什么版本。比如：

codex --version

如果你是通过 CLI 使用，也要留意官方 changelog 里的安装命令和版本变化。不要一边用旧版本，一边抱怨新功能不可用。

第三，把常用规则写进项目。

能写进 `AGENTS.md` 的，不要每次口头说。能沉淀成 skill 的，不要散在聊天里。能用脚本验证的，不要靠模型自觉。

第四，长任务用 Goal mode，但先写契约。

不要只写“帮我做完”。要写目标、边界、验收标准、不要做什么、最后怎么验证。

第五，界面问题优先给现场。

能用 Appshots、截图、浏览器标注、图片输入，就不要让自己当人工转述层。你描述得越多，信息损耗越多。

第六，把远程能力当连续性工具，不当万能入口。

手机上适合看进展、补信息、下达明确小任务。真正复杂的决策，仍然要回到可验证的产物和环境里。

我现在对 Codex 的判断

我不会说 Codex 已经完美替代任何工具。

更准确的说法是：它越来越像一个可以承接长期工作的系统。

Claude Code、Codex、Cursor 这些工具之间，单次能力差距会不断变化。但当 AI agent 进入真实工作，真正拉开差距的不是一次回答，而是四件事：

·能不能稳定使用。

·能不能拿到足够真实的上下文。

·能不能把规则和经验沉淀下来。

·能不能在长任务里留下可验证产物。

这也是我这次看 Codex 更新后最明确的感受。

它不是只在补“更会写代码”。它在补一个主力工具需要的基础设施：上下文、远程、计划、插件、诊断、自动化。

所以我把它切成主力，不是因为追新，也不是因为某次回答惊艳。

而是因为当一个工具开始承接我的工作流时，我更在意它能不能稳定、可复用、可恢复、可验证。

这不是情怀问题，是工程问题。

如果一个规则真的重要，它就不该只留在聊天里。

如果一个工具真的要成为主力，它也不能只会聊天。

OpenAI Codex changelog：https://developers.openai.com/codex/changelog。