如何把 Codex 用到极致

很多开发者第一次使用 coding Agent，通常是让它读代码库、改 diff、跑测试、开 PR。这个当然仍然是 Codex 的核心能力。但 Jason Liu 在这篇文章里强调了另一个更重要的变化：今天很多电脑上的工作，本身已经被代码、浏览器、API、Shell、文档导出、消息事件和自动化流程包裹起来。

一旦这些界面都能被 Codex 接入，Codex 就不再只是一个狭义的编程助手，而会更像一个“帮助你完成电脑工作”的系统。

换句话说，Codex 的重点正在从“帮你写一段代码”，转向“帮你持续推进一个工作流”。

下面是全文翻译。

大多数开发者最开始使用 coding agent，都是把它用于代码本身：

检查一个代码库；
生成一组 diff；
运行测试；
打开一个 Pull Request。

这仍然是 Codex 的能力重心。

但电脑上的很多工作，本来就已经被代码中介化了：执行 Shell 命令、浏览网页、调用 API、导出文档、响应事件、触发自动化流程。

当这些操作界面逐渐对 Codex 开放时，它给人的感觉就不再只是一个狭义上的 coding assistant，而更像是一个可以帮你完成电脑工作的系统。

Codex app 把这种变化变得非常具体。

一个 thread 可以保存上下文，可以使用工具，可以展示产物，也可以在多轮提示之间持续推进，而不是每次对话都从零开始。

如果想从 Codex 中获得更多价值，就要把这些能力组合起来使用：

durable threads：可以保存上下文的持久线程；
voice、steering 和 queuing：在用户仍然参与的同时，用语音输入、实时干预和任务排队控制工作；
browser、computer-use、MCP servers 和 connectors：让 Codex 的行动范围超出代码仓库；
thread automations 和 Goals：让 Codex 在用户离开之后继续推进工作；
side panel：让用户直接审查代码、文档、幻灯片和其他产物。

持久线程：把一次聊天变成长期工作区

所谓 durable threads，指的是可以跨多次会话保存工作上下文的长期 Codex 线程。

Pinned threads 是让这些持久线程保持在手边的一种方式。它非常适合一些重复出现的工作流，例如：

一个 Chief of Staff 线程；
一个 release 线程；
一个文档审查线程；
一个专门用于外部监控的线程。

这些不是短聊天，而是持久工作区。

Codex 可以在未来反复回到这些线程里，保留之前的决策、偏好和工作上下文。否则，每次重新开始时，这些上下文都要从头构建一遍。

Pinned-thread shortcuts 让这件事变得更实用。

通过 Command-1 到 Command-9，用户可以直接跳转到已经保存的线程。

语音输入：保留想法还没被压缩之前的样子

语音输入的价值在于，它能捕捉一个想法最粗糙的版本。

很多时候，一个想法在被写成漂亮文字之前，反而包含更多真实信息：犹豫、重点、模糊线索和还没想清楚的部分。

Codex 内置了语音输入。

它尤其适合那些“说出来很自然，但打字会很别扭”的起点，例如：

我记得 Slack 里好像有个叫 Ben 的人提过这件事。

我不记得具体细节了。

你去帮我找一下。

对于一个能搜索、能收集上下文、能整理反馈的 agent 来说，这些信息往往已经够用了。

语音也很适合在任务还没有完全成型之前，先做两三分钟的思路倾倒。

Transcript 也是同样的道理。原始会议记录或口述计划，往往比短摘要更适合作为源材料，因为它保留了不确定性、强调点和那些还没说完的思路。

Steering 与 Queuing：一个控制现在，一个安排下一步

当语音输入和对正在执行的任务进行显式控制结合起来时，它会更有用。

这里有两个关键概念。

Steering：在 Codex 当前步骤完成之前，打断一个正在执行的任务，并给出新的方向。

当 agent 正在朝错误方向前进，需要在它完成之前纠正时，Steering 就很有用。

比如在网站审查过程中，用户可以一边在 side panel 里标注界面，一边打断 Codex 的工作：

把这个做小一点。

这两个元素之间的间距有点不对。

这里的文案不对。

Queuing：把新的工作添加到 Codex 当前任务完成之后的队列里。

Queuing 不会打断正在进行的任务。它只是把下一个任务排到后面。

用户可能会说：

等这项工作完成后，把 preview link 发给 Slack 里的 reviewer。

Steering 改变的是 Codex 现在正在做什么。

Queuing 改变的是 Codex 接下来应该做什么。

二者共同作用，让用户在工作展开的过程中仍然离任务足够近。

工具触达范围：Codex 的边界不应该停在代码仓库

一旦一个 thread 具备连续性，接下来的问题就是：它到底能对什么采取行动？

Codex 可以一层一层向外移动：

$browser：用于 side panel 中的内置浏览器，Codex 可以检查和标注 Web 界面；
@chrome：用于依赖用户 Chrome 登录状态的浏览器工作流；
@computer：用于那些只能通过桌面 GUI 完成的工作。

三者对应的场景不同：

$browser 适合 side-panel browser review；
@chrome 适合依赖用户 Chrome 上下文的登录态工作；
@computer 适合那些只存在于桌面 GUI 里的任务。

MCP servers 和 connectors 把同样的思路扩展到工作流的其他部分。

Slack、Gmail 和 Calendar 之所以重要，是因为很多关键任务最开始并不是以代码的形式出现的，而是以消息、邮件或日程问题的形式出现。

Skills 则让重复工作流变得可复用。

一旦某个流程被证明有用，就应该把它打包成一个 skill。这样 Codex 下次就可以再次运行它，而不需要从头学习这套 routine。

移动端：人不在桌前，任务也可以继续走

Codex mobile app 改变了一个问题：用户什么时候必须坐在桌前。

一个任务可以从 Mac 上开始，因为文件、权限和本地环境都在那里；然后用户离开桌面，在手机上继续查看进展。

这在很多小场景里很有用。

用户可以在 Codex 运行较长任务时离开桌面，从外面回答一个问题，批准下一步操作，或者在线程继续跑下去之前重新定向它。

本地环境保持不变。

用户不必一直坐在电脑前。

自动化：让 thread 定时醒来继续工作

Automations 可以按计划运行 Codex 工作。

如果某个周期性任务应该从一个 workspace 里重新开始，比如每日报告或定期代码仓库检查，那么适合使用 scheduled automation。

如果一个计划任务应该回到一个已有的活跃 conversation，并带着它正在运行的上下文继续，那么适合使用 thread automation。

Thread automations 可以理解为一种“心跳式”的定时唤醒机制：它会按照时间表回到同一个 Codex thread。

Pinned threads 很有用，但它仍然需要等待用户主动回来。

而 thread automation 可以每隔几分钟或几小时检查一次某件事，持续运行直到满足某个条件，并且随着情况变化调整节奏。

一个 Chief of Staff thread 可能每 30 分钟运行一次：

每 30 分钟检查 Slack 和 Gmail，看看有没有需要我注意但还没回复的消息。

帮我判断哪些事情最重要。

如果有人问我问题，请尽可能深入地研究答案，并帮我起草回复，但不要发送。

当用户回来时，收集上下文这部分最费时间的工作通常已经完成了。

人仍然决定最终发送什么。

Thread automations 也适合反馈循环。

它可以监听 Pull Request comments、Google Docs comments 或 Slack replies，在用户离开时继续推动外围工作。

举个动画工作流的例子：

Reviewer 在 Slack 里发来一段视频；thread automation 可以定时检查这个线程，当评论出现后渲染更新版本，并在同一个 Slack thread 里回复并 tag reviewer。

如果某个集成无法完成最后的上传，desktop automation 可以通过 GUI 补上最后一步。

这个循环横跨 Slack 反馈、代码库渲染和桌面自动化上传。

Goals：没有验证器的雄心，只是愿望

Goals 最强的地方，是它适合那些有真实终点、agent 可以持续推进的任务。

一个弱 goal 可能是：

实现这个 Markdown 文件里的计划。

Goals 指的是带有明确终点、Codex 可以长时间持续推进的任务。

更强的 goal 应该包含可衡量的成功标准。

例如，一个工程师要把内部工具从 Python 迁移到 Rust。他可以先创建新的目录，定义 goal，并把完成标准写清楚：新的实现只有在 unit tests 全部通过之后才算完成。

一个 goal 其实是持续执行与验证器的组合。

用户定义结果、停止条件，以及判断 Codex 是否正在接近目标的信号。

有用的验证器包括：

test suite；
benchmark；
bug reproduction；
validation matrix；
必须持续通过的端到端工作流。

Ambition matters, but without verification it’s just a wish.

雄心当然重要，但如果没有验证，它就只是愿望。

Side panel：让产物留在对话旁边

Side panel 让工作产物留在生成它的 conversation 旁边。

用户不需要先导出一个 artifact，再切换到另一个上下文里审查它，而是可以直接在原地看。

这个产物可能是代码，也可能是 deck、PDF、浏览器页面、表格，或工作过程中生成的其他 artifact。

Side panel 尤其适合四类工作：

检查 artifacts；
标注需要修改的地方；
操作 Web 界面；
审查变更。

用户可以在 side panel 中直接查看 Markdown、spreadsheets、data tables、documents 和 slides。

他们可以检查、标记和修改这些 artifacts，而不必打断工作循环。

Deck 或 PDF 可以一直打开在生成它的 thread 旁边，随时等待直接审查和修复。

Codex 的 in-app browser 可以检查一个已经渲染出来的页面，控制它，并对 review surface 上的 annotations 直接作出响应。

页面或 artifact 上的评论留在同一个工作循环里，而不是变成一次单独的交接。

Web 于是同时变成了输出界面和控制界面。

Codex 可以构建一个 artifact，在 side panel 里打开它，检查它，调试它，然后在原地持续打磨同一个对象。

这些界面尤其适合：

index.html：轻量级静态 artifact；
Storybook：UI review；
Remotion Studio：程序化动画；
基于浏览器的 slide decks；
用于分析工作流的数据应用。

一个单独的 index.html 文件，就可以成为一个不需要服务器的持久交互式 artifact。

Thread automations 也可以随着时间刷新静态 artifacts，让用户回来时，thread 里已经有新的东西等着他。

Shared memory：重要上下文不应该只活在聊天记录里

长时间运行的 threads 如果能共享 conversation 之外的 memory，会变得更有用。

Shared memory 指的是保存在单一 thread 之外的持久上下文，使未来工作可以从一个明确、可检查的位置恢复。

一种持久模式，是把 persistent threads 锚定在一个 Obsidian vault 里。

在实践中，这意味着使用一个由普通文件组成的文件夹。它易于检查、编辑、移动，也适合长期保存。

团队可以把这个文件夹放在 cloud stoRAGe、Git、Dropbox、Google Drive，或者任何适合自己工作流的同步层里。

一个 vault 可能长这样：

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

在顶层，AGENTS.md 可以定义 Codex 在了解更多人物、项目、决策和 open loops 之后，应该如何更新这个 workspace。

不要照搬某一种精确的 vault 结构。

真正要教给 agent 的，是 durable context 应该放在哪里，哪些上下文应该被保留，以及什么时候不要制造无意义的文件 churn。

一个实用的 AGENTS.md 可以这样写：

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.