你用 Codex，还只是让它写代码吗？

用 Codex 做真实项目时，真正让人卡住的经常不是“代码会不会写”，而是那些夹在工作流里的小问题：页面哪里要改说不清，bug 调完以后上下文太脏，方案改乱了想回到中间某一步，复杂需求又怕它一上来写偏。

还有一个很常见的场景：很多网页不是简单搜索一下就能拿到结果。它可能需要登录、鉴权，或者依赖浏览器里的已有会话。以前通过 API 或搜索结果拿到的信息不一定够准，现在让 Codex 直接打开 Chrome，像人一样进入网页去看，反而更方便。

再往后用，你还会遇到更细的工作流问题：主线任务正在跑，临时想问一句怎么办？创建日历、填表、点应用这些电脑操作，能不能也让 Codex 处理？每天都想追踪的信息，能不能定时自动跑？

我日常用下来，Codex 真正顺手的地方，恰恰是画布圈选修改、消息编辑、fork、计划模式、侧边会话、Chrome、Computer Use、定时任务这些细节。

查网页这件事，可以让 Codex 自己进 Chrome 做

以前让 AI 查网页，更多是通过浏览器 API 或搜索结果拿到一部分信息。现在不一样的是，Codex 可以自己打开 Chrome，像人一样进入网页、点击、阅读页面，再把结果整理出来。尤其是一些需要鉴权登录、依赖已有浏览器会话的网页，用浏览器形式访问会更快也更方便。

使用前需要先把 Chrome 相关能力安装好。安装完成后，Codex 才能在需要访问网页时调用浏览器，而不是只停留在聊天框里等你贴资料。

 

先安装 Chrome 相关能力，让 Codex 可以接管浏览器任务。

 

安装完成后，网页访问、资料读取和内容总结就可以进入自动流程。

使用时也很直接，直接在输入框里说清楚任务就行。比如：找出当天 GitHub 上热门的 3 个 skill，总结它们的特点，并附上对应链接。

 

输入自然语言任务后，Codex 会把它拆成浏览器里的连续动作。

运行后，它会自己打开 Chrome，进入 GitHub 页面查看内容，再把信息整理回来。过去更像是拿到搜索结果或页面摘要，现在它可以真的进入页面逐个查看。

 

任务过程中，Codex 会进入网页提取信息。

 

最终结果会整理成可读内容，直接附上对应信息。

操作电脑这件事，也不一定非要自己点

还有一类任务不是查资料，而是操作电脑。比如打开日历、创建事项、在应用里点击和输入，甚至让 Codex 自己打开电脑上的 PPT，一页一页往里写内容。这类原本必须手动完成的动作，也可以让 Codex 代劳。好处是你不用一直在不同软件之间切来切去。

用之前同样要先启用 Computer Use。启用之后，你可以直接说要它操作哪个应用、完成什么动作，比如打开日历创建一个事项。

 

Computer Use 面向本机应用操作，适合需要点击、输入、打开应用的任务。

 

在输入框里直接描述要完成的电脑操作，Codex 会开始执行。

 

示例里它会打开日历并创建对应事项，这类流程不用再手动一步步点。

前端改细节，最烦的是说不清楚“哪里要改”

前端页面最麻烦的不是生成第一版，而是后面改细节。按钮偏一点、间距不舒服、某块颜色不对，都要截图再解释位置。

 

页面生成后可以直接在右侧预览，先把“看效果”这一步接上。

Codex 的解法是把预览和批注接上：看到哪里不对，直接在图上圈出来，再写一句要怎么改。

 

直接圈出要改的位置，比“左上角第二块下面那个按钮附近”这种描述清楚多了。

这个功能适合改 UI 细节。它解决的不是代码能力，而是沟通成本。

 

改完之后再看结果，前后对照就很直观。

第二个痛点：一个小需求，不应该带着一堆调试上下文

用 AI 做项目时，经常会出现这种情况：前面排 bug 排了很久，后面只是想改一个小地方，但整段调试历史还在上下文里。模型会带着这些信息继续理解新需求，既费 token，也容易让判断变乱。

比如我只是想把页签里的“系统”去掉。这种需求本来很简单，不值得把前面整段 bug 排查都带进去。

 

一个小改动，如果跟在大量调试记录后面，反而容易变复杂。

这时更好的办法不是继续往下追加，而是直接编辑最后一条消息，把新需求替换进去。这样临时排查过程就不会继续进入下一轮。

 

编辑上一条输入，本质上是在给下一轮任务清理入口。

 

这种方式适合把临时调试过程从主线里拿掉。

第三个痛点：改了很多轮，突然想回到前面的版本

编辑上一条消息只能解决最近一步。如果你已经改了很多轮，突然发现前面的版本更好，继续在当前会话里让它“回到之前”就很容易绕。

更干净的办法是找到想回去的那条消息，直接 fork 一条新路线。这个功能很适合做方案分支：保留现在的进度，同时从某个旧节点重新试。

 

在目标消息旁边 fork，相当于从这个时间点重新开线。

这里有一个容易误解的点：fork 不等于代码自动回滚。它主要是在会话层面回到某个节点，后续代码目录怎么处理，要看你选择派生到本地还是新工作树。

 

fork 的两个选项，决定会话和代码目录怎么继续。

这两个选项有个共同点：会话状态都会复制到你选择的那条消息为止，代码都不会自动回滚。也就是说，已经提交到 git 的代码不会因为 fork 消失；没提交的文件状态，也不会自动变回当时的样子。

它们唯一明显的区别，是代码位置。local 会留在原目录继续做；new worktree 会开一个全新的隔离目录。我的理解是：local 适合重新组织对话，new worktree 适合尝试一条不影响主目录的新路线。

 

本地派生回到的是会话状态，不是自动回滚代码。

 

new worktree 的价值，是把后续代码实验放到新的隔离目录里。

第四个痛点：复杂需求一上来就写，很容易越写越偏

当需求变复杂时，我不太建议直接让 Codex 开始改。因为一旦它理解偏了，后面写得越多，返工越麻烦。

计划模式的价值就在这里。它会先拆任务、列步骤，让你确认方向，再进入实现。跨文件修改、复杂页面、重构这类任务，我会优先用这个模式。

 

计划模式适合先确认方向，再进入执行。

计划满意就实施，不满意就继续改。它不是为了多一个流程，而是为了避免 AI 一路写下去才发现方向不对。

 

确认计划后再执行，方向更容易对齐。

第五个痛点：主线任务跑着，临时问题到底问不问？

还有一个场景很常见：Codex 正在执行一个比较长的任务，你突然想到一个轻量问题。问吧，担心打断主线；不问吧，又怕忘。

 

侧边会话适合处理这种临时问题。

 

主线继续跑，侧边单独交流。

侧边会话的好处是，它不会打断左侧主线。你可以把轻量问题放到旁边问，主任务继续做自己的事。这个设计适合长任务执行时临时查概念、确认思路、问一点小问题。

 

侧边会话的价值，是把临时问题和主线执行分开。

第六个痛点：有些任务不是写代码，而是要会调用工具

如果只看前面几个功能，Codex 还是偏开发工作流。但加上 plugin 之后，它就开始往工作台方向走了。

plugin 不是普通按钮，更像一组能力包。里面可能有 skill、MCP 或应用控制能力。装上之后，Codex 才知道某类任务该按什么流程做、能调用什么工具。

 

安装插件，相当于给 Codex 增加可调用能力。

比如写 PPT 的插件，核心是 Presentations 这个 skill。它不只是让 Codex 生成几页幻灯片，而是告诉它怎么按演示文稿的方式组织内容和版式。

 

先选择并安装演示文稿相关能力，让 Codex 知道这类任务应该怎么做。

 

安装后可以看到对应的 skill，它负责把“怎么做好 PPT”变成可执行规则。

使用时直接告诉 Codex 你要做什么主题的 PPT，它会按这个能力里的流程去生成初稿。生成结果不算惊艳，但能作为初稿继续改。对我来说，这就够实用：先把结构和页面搭起来，再迭代细节。

 

PPT 初稿可以作为继续打磨的基础。

 

打开结果后，能继续检查版式和内容。

最后一个痛点：重复任务和固定方法，不想每次重新说

用到后面我发现，真正适合长期使用的不是某一次生成，而是把自己的方法沉淀下来。skill 就是一个例子。

比如这次整理文章，我就是先让 Codex 帮我写一个 skill，把写作要求、文章结构和检查标准沉淀进去，再用这个 skill 组织内容。以后遇到类似文章，不用每次重新解释文风、结构和检查标准。

 

先直接提出“帮我写一个 skill”的需求，把自己的写作偏好说清楚。

 

生成过程中，Codex 会把要求转成结构化的 skill 说明。

 

写好之后，这个 skill 就可以在后续同类任务里复用。

这件事的价值是稳定。一次写好规则，后面同类任务就能继续复用。

 

使用自定义 skill 后，文章会按预设编辑方法展开。

定时任务解决的是另一类重复问题。比如你可以直接告诉 Codex：每个工作日固定拉取 GitHub 热门 skill，整理成摘要。它适合那些每天都想追踪、但每天都不一定记得看的信息。

 

先用自然语言创建定时任务，说清楚频率和要执行的内容。

添加之后，任务会出现在列表里。到时间自动运行，也可以手动试运行，先确认它能不能产出你想要的结果。

 

任务创建后会显示在列表里，方便管理。

 

可以设置工作日 9 点运行，也可以先试运行。

 

试运行结果能确认任务是否真的有产出。

我的看法

我日常用 Codex，越来越明显的感觉是：它的价值不只是把代码写出来，而是把中间那些容易打断节奏的动作接上。

画布圈选修改，减少的是解释成本；消息编辑和 fork，减少的是上下文负担；计划模式和侧边会话，减少的是跑偏和打断；Chrome、Computer Use、定时任务，则把查资料、操作应用、重复收集这些事也接进来。

如果只是偶尔问几段代码，可能感受不到这些细节。但只要把 Codex 放进真实项目里用，就会发现好不好用往往不在某一次回答，而在它能不能少让你解释一次、少让你切换一次、少让你重复做一次。