Codex 官方分享：如何把 Codex 用到极致

Codex 不只是写代码，它开始接管工作流。

先说结论：Codex 正在从一个 coding Agent，变成一个 computer-work agent。

也就是说，它处理的不只是仓库里的代码。它开始能跑命令、看网页、调 API、导出文档、处理消息、触发自动化、检查目标进度，甚至把一条长期线程当成一个持续工作的现场。

Jason 这篇《Getting the most out of Codex》讲的就是这件事。

Jason 这篇文章想讲的不是单点功能，而是把 Codex 用到极致。

表面看，它是在介绍 Codex App 的一组功能。耐久线程、语音输入、Steering、Queuing、Browser、Chrome、Computer Use、MCP、自动化、Goals、Side Panel、Shared Memory。

但我看完之后，最强烈的感觉是：

这是一套新的工作控制系统。

Codex 的工作半径变大了

以前我们说 AI 编程工具，默认就是让它看仓库、改代码、跑测试、开 PR。

这个中心还在。

Codex 仍然是从代码开始的。你让它读项目、改 diff、运行测试、解释报错，这是它最核心的能力。

但问题是，真实工作从来不只发生在代码里。

一个工程任务，经常要看网页文档、查 Slack 里的上下文、读邮件里的需求、整理表格、导出 PDF、更新演示稿、把结果发给别人、隔一段时间再回来检查反馈。

这些事情以前都散在不同工具里。

Codex App 想做的变化，是把这些表面都接进同一个线程里。

Codex 的工作半径：从代码仓库，走向完整工作流。

你可以把它理解成四层扩张：

一层是写代码。

读仓库、改文件、跑测试，这是基础能力。

第二层是操作电脑。

执行 shell 命令、处理文件系统、跑脚本、调用 API，开始进入真实环境。

第三层是串联工具。

浏览器、文档、表格、幻灯片、消息、日历、邮件，都可以变成 Codex 能触达的工作表面。

第四层是持续推进。

它不只是回答一次，而是能在一个线程里保留上下文，定时回来，看有没有新反馈，继续往目标走。

说白了，Codex 的边界正在从「帮我写一段代码」，变成「帮我把这件电脑上的事做完」。

这才是原文最重要的判断。

线程开始变成工作空间

原文第一个关键词是 durable threads。

我会翻译成「耐久线程」。

意思不是这个聊天记录比较长，而是这个线程可以长期保留工作上下文。

你可以把一个线程固定起来，作为某个长期工作流的入口。比如：

• Chief of Staff 线程
• 发布线程
• 文档审查线程
• 外部监控线程

这些线程不是临时聊天。

它们更像一个个工作空间。

这件事非常关键。

因为很多人用 AI 的效率低，不是因为模型不够聪明，而是每次都在重建上下文。今天解释一遍项目背景，明天再解释一遍偏好，后天又重新说一次什么能改、什么不能改。

线程一旦耐久化，Codex 就能带着之前的决策、偏好、文件、任务状态继续工作。

耐久线程：下一次回来，不必重新解释一遍。

Pinned threads 只是入口。

真正重要的是：你开始把「某类工作」绑定到「某条线程」上。

发布相关的事情，不要散到十个对话里。都回到发布线程。

文档审查相关的事情，不要每次新开。都回到文档审查线程。

外部监控相关的事情，也不要让 Agent 每次从零猜。都回到监控线程。

原文还提到一个小细节：Command-1 到 Command-9 可以快速跳到保存好的线程。

这个细节看起来很小，但背后是一个使用习惯变化：

你不再打开 AI，然后随便问一句。

你开始像切换工作台一样，切换不同的长期线程。

语音输入的价值，是保留粗糙想法

原文里讲语音输入，我觉得这段很实用。

语音输入的价值，不是把打字变快一点。

它真正厉害的地方，是能把一个想法还没压缩成正式文字之前的状态保留下来。

比如你可以直接说：

这句话如果让你打字，你可能会觉得太松散，不好意思发。

但对一个能搜索、能收集上下文、能回来汇报的 Agent 来说，这已经够了。

很多真实任务一开始就是这样的。

不是清清楚楚的需求文档，而是一段含糊的记忆、一个没想完的方向、一个两三分钟的口述想法。

这也是为什么原文说，原始会议转录和口述规划，有时候比总结更有价值。

总结会把不确定性抹掉。

原始转录会保留犹豫、重点、语气和那些还没成型的线索。

对 Agent 来说，这些反而是有用的上下文。

Steering 和 Queuing：人还在回路里

原文把语音输入往前推了一步。

如果 Codex 正在执行一个任务，你还能不能中途控制它？

这里有两个概念：Steering 和 Queuing。

Steering 是中途打断。

Agent 正在干活，但方向不对，你不等它做完，直接插一句新的指令。

比如它正在审查一个网页，你在侧边栏看到按钮太大、间距不对、文案写错了，就可以边看边说：

• 这里缩小一点
• 这两个元素之间太挤
• 这句文案不对

这不是重新开一个任务。

这是在任务进行中修方向。

Queuing 是排队。

它不打断当前工作，只是把下一步排上。

比如你说：

Steering 改变的是现在。

Queuing 安排的是下一步。

这两个功能的意义很大。

因为 Agent 的任务会越来越长。以前 AI 回答十几秒，现在一个真实任务可能跑几分钟，甚至更久。

如果你只能等它结束，再重新纠偏，这个协作体验会很差。

更好的方式是：人在回路里，但不是人肉接管。

你保持低频、高价值的干预。

方向偏了，Steer。

下一步明确了，Queue。

你像一个项目负责人，不像一个每一步都亲手操作的人。

工具决定 Agent 能碰到什么

原文接着讲工具。

一条线程有了连续性，下一件事就是：它到底能接触哪些工作表面？

这里 Jason 把 Codex 的工具半径分了几层。

工具决定 Agent 能碰到什么：能力边界越清楚，授权越可靠。

$browser 适合侧边栏里的浏览器审查。

也就是你让 Codex 打开一个网页，看渲染效果、检查交互、配合你的标注继续改。

@chrome 适合需要登录态的浏览器工作。

比如某些网页必须依赖你自己的 Chrome 账号、Cookie、扩展或已登录状态。

@computer 适合只能通过桌面 GUI 完成的工作。

有些事没有 API，也不在网页里，只能打开软件、点按钮、拖文件、操作窗口。

MCP servers 和 connectors 是下一层。

Slack、Gmail、Calendar 这些连接很重要，因为很多任务一开始就不是代码任务。

它可能是一条消息。

可能是一封邮件。

可能是一个会议安排。

这些东西一旦接进来，Codex 就能从「任务出现的地方」开始工作，而不是等你把任务手动复制到聊天框。

Skills 又是另一件事。

连接器解决的是能力问题：能不能碰到 Slack、Gmail、Calendar。

Skill 解决的是流程问题：遇到某类任务，应该怎么做。

这就是我一直说的：

Prompt 是消耗品，Skill 是资产。

一次性 prompt 只能解决这一次。

Skill 会把一套被验证过的流程沉淀下来，让 Codex 下次不用重新学。

Mobile App 和 Automations：人可以离开桌子

原文里有一句话很重要：Codex mobile app 改变的是人什么时候必须坐在电脑前。

很多任务必须从 Mac 开始。

因为文件在本地，权限在本地，环境也在本地。

但任务跑起来之后，人不一定要一直坐在桌前。

你可以离开电脑，在手机上查看进度，回答问题，批准下一步，或者及时修方向。

本地环境还在。

人不一定在。

这就是 Codex mobile app 的价值。

再往后就是 Automations。

这里要分清两种：

一种是 scheduled automation。

适合每天报告、定期仓库检查这种从工作区重新开始的任务。

另一种是 thread automation。

它回到同一条线程里，带着已有上下文继续推进。

原文举了一个 Chief of Staff 线程的例子：

每 30 分钟检查 Slack 和 Gmail，看有没有需要我注意的未回复消息。帮我判断优先级。如果有人问我问题，你先尽可能深入研究答案，给我起草回复，但不要直接发送。

这个设计很有意思。

Agent 做最耗时间的上下文收集。

人保留最后决策权。

这就是一个靠谱的自动化边界。

它不是替你乱发消息。

它是把信息先筛一遍，把回复草稿准备好，把你回来之后最耗脑子的部分提前做掉。

原文还提到反馈循环。

比如 PR 评论、Google Docs 评论、Slack 回复，都可以被 thread automation 定时检查。

有人给了反馈，Codex 回到上下文里继续改。

如果涉及视频渲染，甚至可以从 Slack 的反馈开始，到代码仓库里重新渲染，再通过桌面自动化完成最后上传。

这就不是「AI 回复一句话」了。

这是一个跨工具的工作闭环。

Goal 不是愿望，是带验证器的终点

原文对 Goals 的说法，我很认同。

弱 Goal 是：

这句话太虚。

它没有完成标准。

强 Goal 一定要有可验证的终点。

比如把一个内部工具从 Python 迁移到 Rust。你不能只说「完成迁移」。你要告诉 Codex：新的实现要跑通单元测试，测试通过才算完成。

Goal 不是愿望：它必须带验证器和停止条件。

Goal 的核心是三件事：

目标是什么。

停止条件是什么。

用什么信号判断正在接近目标。

原文列了几类很实用的 verifier：

• 测试套件
• benchmark
• bug 复现
• validation matrix
• end-to-end workflow

我用中文说就是：

测试能过。

指标能达标。

Bug 能复现且被修掉。

验证矩阵能打勾。

端到端流程能持续跑通。

没有验证，雄心只是愿望。

这句话特别适合所有 Agent 任务。

你让 AI 做一件大事，如果不给它验收标准，它就只能凭感觉往前跑。

一旦有了验证器，它才知道什么时候该继续，什么时候该停，什么时候该回头修。

Side Panel：产物要留在对话旁边

原文讲 Side Panel，我觉得这部分被很多人低估了。

Side Panel 的价值不是多一个预览窗口。

它的价值是：产物和产生它的对话放在一起。

你不用生成一个文件，切到另一个软件，打开，发现问题，再回到聊天框重新描述。

你可以在同一个工作现场里检查、标注、修改。

原文截图：Codex 在侧边栏里生成 PDF，并直接在预览上标注修改意见。

原文说 Side Panel 特别适合四件事：

• 检查产物
• 标注需要修改的地方
• 操作网页表面
• 审查改动

产物不一定是代码。

它可以是 Markdown、表格、数据表、文档、幻灯片、PDF、网页、动画预览。

这点很重要。

原文截图：CSV 表格可以留在 Codex 侧边栏里检查，不必跳出当前线程。

因为 Codex 的输出正在从 diff 扩展到 artifact。

你让它做一个 index.html，这个文件可以直接成为一个轻量静态应用。

你让它做 Storybook，可以直接审查 UI。

你让它做 Remotion Studio，可以直接审查程序化动画。

你让它做浏览器版 slides，可以直接迭代演示稿。

原文截图：PPT 预览、文件改动和对话留在同一个工作现场里。

网页不只是输出。

网页也开始变成控制表面。

Codex 可以生成它，打开它，检查它，调试它，再继续改它。

共享记忆：别让上下文只活在聊天记录里

原文最后讲 shared memory。

这部分和我的认知非常一致。

长线程有价值，但重要上下文不能只活在聊天记录里。

聊天记录适合过程。

共享记忆适合沉淀。

原文提到一个很朴素的做法：用 Obsidian vault 作为耐久工作记忆。

目录可以很简单：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

关键不是照抄这个结构。

关键是你要告诉 Agent：

什么内容要长期保存。

什么内容应该写到 canonical note。

什么内容只是临时 scratch。

什么时候不要为了记录而制造文件噪音。

这就是 AGENTS.md 的价值。

它不是摆设。

它是在告诉 Codex：这个工作区的记忆应该怎么更新。

比如：

• 把 ~/vault 当作耐久工作记忆
• 优先更新规范笔记，少制造碎片
• TODO、人物、项目、日总结、草稿笔记要明确路由
• 保留决策、阻塞、负责人、日期和有用链接
• 如果没有实质变化，不要 churn vault

这段我非常想强调。

代码仓库保存代码。

Vault 保存滚动上下文。

人是谁，需求怎么变，哪里卡住，下一步谁负责，之前为什么这么决策，这些东西如果不写下来，下一条线程就会重新猜。

真正能长期使用 Agent 的人，一定会重视共享记忆。

因为上下文厚度，才是后面真正的壁垒。

我的判断：别再只把 Codex 当代码助手

这篇原文最值得带走的，不是某个功能怎么点。

是一个工作方式的变化。

Codex 仍然从代码开始。

但越来越多围绕代码的工作，正在被同一个系统接住：MCP、浏览器、桌面控制、线程自动化、可审查产物、共享记忆、Goals。

这会改变人的控制方式。

你不再只是写 prompt，等答案。

你要开始定义工作现场。

哪条线程负责什么。哪些工具可以授权。哪些流程应该沉淀成 Skill。

哪些任务适合自动唤醒。哪些 Goal 必须绑定验证器。哪些上下文要写进共享记忆。

本质很简单：

未来能用好 Codex 的人，一定是会搭工作系统的人。

如果你给它线程、文件、工具、Skill、自动化、验收标准和共享记忆，它就开始像一个能持续推进工作的执行系统。

这才是 Codex 真正值得关注的地方。