背景

完成博客迁移之后，我对 Copilot Pro 的体验并不算满意，尤其是在调试、细节处理和复杂任务推进上，经常需要反复补充上下文。于是我订阅了 Codex，想把它放到更接近真实工作的场景里试一试：既包括代码生成、调试和项目修改，也包括文档、PPT、邮件总结这类日常任务。

Codex 的安装过程整体比较简单。从官网下载安装包后，后续安装会跳转到 Microsoft Store。这个流程本身不难，但体验上有点绕：入口在官网，实际安装和更新却依赖微软商店。或许是为了兼容 Windows 的安全机制，顺带优化厂商 CDN 下载成本及快速部署体验，但这也导致了后续更新的体验不太流畅。当前 Windows 的 App 产品安装，不少有这种交互的趋势。

目前它的迭代频率比较高，而 Microsoft Store 的更新并不总是及时。有时官方已经发布新版本，但客户端迟迟没有自动更新，导致一些新功能在本地看不到，或者因为版本过旧而无法正常使用。遇到这种情况，就需要手动检查更新，过程比较打断节奏。

比如最近 Codex 推出的 Chrome 插件，我遇到过官方发布已经十几个小时，但 Microsoft Store 仍然没有把 Codex 可下载的客户端更新到可用版本的情况。相比之下，Chrome Web Store 里的 Codex 插件更新更快一些，基本上插件上架后就能安装使用。

不过 Codex Chrome 插件刚推出时稳定性还不够好。它需要和本地 Google 浏览器的 Codex 插件客户端建立连接，连接不稳定时就会影响实际使用。比如我尝试通过 Codex Chrome 插件读取并总结 Gmail 邮件，就遇到过连接失败、无法获取邮件内容的问题。如果主要需求是处理 Gmail，我更倾向于直接使用 Codex 的 Gmail 插件。它通过关联邮箱账户读取内容，稳定性比依赖浏览器插件链路更好。

体验对比

在代码生成方面，Codex 给我的感觉比 Copilot Pro 更顺。这里的“顺”不是说它每次都能一次性给出完美答案，而是它更像一个能持续推进任务的助手：能理解更长的上下文，也更容易把任务拆下去、改下去、验证下去。

Copilot Pro 更像是一个嵌在编辑器里的代码辅助工具。它在补全、局部生成和简单调试上有价值，但面对复杂需求时，经常需要我多次解释背景、修正方向、补齐限制条件。很多时候，它不是不能做，而是推进成本比较高。

Codex 的优势主要来自模型能力和任务形态。它可以直接使用 ChatGPT 较新的模型，在理解复杂需求、生成代码、修改项目和解释问题时，整体表现更稳定。以前用 Copilot Pro 时，一些需求需要多轮来回才能接近预期；换成 Codex 后，虽然仍然需要迭代，但无效沟通明显少了很多。

两者还有一个很大的差别：任务边界不一样。Copilot Pro 的定位更偏代码生成和调试，而 Codex 更像一个完整的 AI 工作台。除了写代码，它还可以处理 Markdown、PPT、翻译、数据分析、自动化流程等任务。在一些场景里，它甚至可以替代部分自动化工具的工作，而且不用单独处理 API 模型选择、订阅配置和安全接入这些问题。

当然，这并不意味着 Codex 可以“一键生成最终结果”。无论是代码功能、页面排版、文档结构，还是安全、性能、架构预留，都需要在生成结果的基础上继续迭代。区别在于，Codex 的迭代效率更高，修改路径更连贯。用了一段时间后，已经开始考虑退订 Copilot Pro，有点回不去的感觉。同时 Codex 比 OpenCode 也要好用多了。

Codex 也不是没有缺点。某些特定技术领域里，它生成的代码仍然可能不够准确，需要人工校验和调整；订阅费用也不低，对很多人来说都会是一个现实因素。不过如果它确实能降低试错成本、缩短从想法到结果的距离，那这笔钱就不只是买工具，而是在买一种新的工作方式。

从不明确到可执行

我在尝试 Codex 的过程中，感触最深的不是“它能写多少代码”，而是它对模糊需求的承接能力。

比如我想做一个 AI infra 相关的 PPT。如果直接说“帮我生成一个 AI infra 的 PPT”，Codex 通常会先给出一个大纲，甚至直接生成一批页面内容。但这个结果大概率只是“能用来开始”，并不一定符合真实汇报场景：受众是谁、汇报目标是什么、内容要多深、视觉风格偏技术还是偏管理、哪些术语必须出现、哪些内容不能展开，这些都会影响最终质量。

如果先在计划模式里把需求和限制说清楚，效果会明显好很多。比如先说明 PPT 的受众、汇报目标、内容边界、表达风格、视觉方向和预期页数，再让 Codex 根据这些约束设计结构，后续生成出来的内容就更接近可用稿。

这也是我觉得计划模式很有价值的地方。它解决的不是“完全不知道要什么”的问题，而是“方向明确，但细节还没展开”的问题。很多事情难就难在从零开始：你知道自己想要一个结果，但不知道第一步该怎么拆，不知道应该采用什么结构，也不知道过程中会遇到哪些细节。

Codex 在这里提供了一个很好的起点。它可以先给出框架，再陪你逐步细化。PPT 是这样，代码功能也是这样。很多功能在真正动手之前，细节是想不到的，只有做起来才会暴露出来。Codex 可以很快生成测试用例框架、任务编排 YAML、初版页面或脚本模板，而我需要做的，是在这个基础上判断、取舍、修正和推进。

相比完全从零手写，这种方式极大降低了启动阻力，也减少了很多前期预研的不确定性。

一点观察

Codex 给我的最大变化，是它重新定义了“开始做一件事”的成本。

过去很多事情不是不能做，而是启动成本太高：需要先查资料、搭环境、写模板、试框架、补细节。现在这些步骤仍然存在，但其中很大一部分可以被更快地铺开。人要做的事情，也从单纯执行，更多变成了设定目标、判断方向、控制质量和完成收尾。在这个过程中，标准化的时间花费会大幅下降，同时在主观分析和决策上投入更多精力，工作效率会有质的飞跃。AI 工具真正改变的，不只是它能替我们完成哪些任务，而是它降低了我们把想法推进成结果的成本。

这种工作方式会继续模糊兼容多数不同岗位之间的边界。它让人更容易跨到原本不熟悉的领域，去做一些过去不太敢尝试的事情。比如全栈开发、自动化分析、轻量级设计、内容生产，这些原来可能分布在不同角色里的工作，现在都更容易被一个人串起来。

未来的岗位也许会越来越目标导向，而不是只按固定职能划分。一个人负责的，可能不再只是某个明确 title 下的一小块职责，而是一个可以被交付、被验证、被持续迭代的结果。

这件事已经在发生了。自己需要适应的，也不只是某一个工具，而是这种新的协作方式。