把 Codex 用到极致

作者：中国人本来就聪明
发布时间：2026年5月22日 03:27
原始链接：https://mp.weixin.qq.com/s/hrUO4mZps8Mh33DgGcmKFg

导读

本文是 Jason（@jxnlco） 于 2026 年 5 月 21 日在 X.com 发布的文章《Getting the most out of Codex》（中文译名：把 Codex 用到极致）的简体中文全文翻译。

Jason 是前 OpenAI 团队成员，曾在 Codex 团队直接参与这款 AI 编程 agent 的构建。离开 OpenAI 后，他持续在 X.com 上分享关于 AI agent、编程工具和开发者工作流的深度内容，是 agentic coding 领域最有影响力的声音之一。他对 Codex 的理解不是"用过"，而是"造过"——这篇文章从内部视角出发，系统拆解了 Codex 的各项能力及如何将它们组合起来发挥最大价值。

来源信息

• • 原文链接：https://x.com/jxnlco/article/2057153744630890620
• • 原文作者：Jason（@jxnlco）
• • 发布日期：2026 年 5 月 21 日

把 Codex 用到极致

把 Codex 用到极致

大多数开发者第一次用编程 agent 是为了代码：检视仓库、生成 diff、跑测试、开 pull request。

这仍然是 Codex 的重心所在。但计算机上的大部分工作早已由代码作为中介来驱动：执行 shell 命令、浏览网页、调用 API、导出文档、响应事件、触发自动化。当这些界面开始对 Codex 开放，它慢慢不再像是一个狭义上的编程助手，而更像是一个搞定计算机工作的系统。

Codex 应用让这个转变变得具体。一个 thread 可以保留上下文、使用工具、呈现产物，并且在多轮对话中持续进行，而不是每次交互都从零开始。

想要把 Codex 用出最大价值，你需要把这些能力组合起来：

• 持久线程（Durable Threads），保留上下文
• 语音输入、操控（Steering）和排队（Queuing），让用户仍在回路中
• 浏览器、Computer Use、MCP 服务器和连接器，让 Codex 能触达仓库之外的世界
• 线程自动化（Thread Automations）和 Goals，在用户离开时继续推进工作
• 侧边面板，让用户直接审查代码、文档、幻灯片等各种产物

持久线程

持久线程：跨多个会话保留工作上下文的长运行 Codex 线程。

固定线程是把持久线程放在手边的一种方式。它们适合那些重复出现的工作流，比如：

• 一个"Chief of Staff"线程
• 一个发版线程
• 一个文档审查线程
• 一个专门做外部监控的线程

这些是持久的工作空间，不是简短的聊天。Codex 可以跨时间反复回到这些线程，保留之前的决策、偏好和工作上下文——这些东西原本每次都得从头重建。

固定线程的快捷键让这一切变得务实。Command-1 到 Command-9 直接跳转到已保存的线程。

语音输入

语音输入的价值在于，它能捕捉到想法尚未被压缩成精炼文字之前的粗糙版本。

Codex 内置了语音输入。它尤其适合那些说起来很自然、但打字很别扭的模糊起点：

• 我记得 Slack 里好像有个叫 Ben 的人提过这件事。
• 细节我不记得了。
• 去找一下。

对于一个能搜索、收集上下文并回来汇报的 agent，这往往就够了。

它也适合那种任务还没完全成形之前的两三分钟思考倾倒。

转写文本同理。一份原始的会议转写记录或口述规划笔记，往往比简短摘要更适合作为源材料，因为它保留了不确定性、强调和未完成的思考线。

操控与排队

当语音输入和显式的任务控制结合起来时，它的威力更明显。

操控（Steering）：在一个正在执行的 Codex 任务完成当前步骤之前，用新的方向来打断它。

操控在 agent 跑偏方向、需要在它完成之前纠正的时候很有用。比如在审查一个网站时，用户可以打断正在跑的任务，同时在侧边面板上对界面进行标注：

• 把这个改小
• 这两个元素之间的间距感觉不对
• 这行文案是错的

排队（Queuing）：在当前步骤完成后，为 Codex 添加下一件要做的事。

排队不一样。它不中断正在进行的任务。它把下一件事排到队列里。用户可以说：

"搞定之后，把预览链接发给审查者到 Slack。"

操控改变的是 Codex 此刻在做什么。排队改变的是接下来该发生什么。两者都让用户在任务展开的过程中保持贴近。

工具与触达

一旦线程有了连续性，下一个问题就是它能操作什么。Codex 可以逐层向外扩展：

• $browser：用于侧边面板中的内置浏览器，Codex 可以在上面审查和标注网页界面
• @chrome：用于带登录态的浏览器和基于 Chrome 的工作流
• @computer：用于那些只能通过桌面 GUI 完成的操作

$browser 适合侧边面板的浏览器审查。@chrome 适合依赖用户 Chrome 上下文的登录态浏览器操作。@computer 适合只存在于桌面 GUI 中的任务。

MCP 服务器和连接器把同样的思路延伸到工作流的其他部分。Slack、Gmail 和 Calendar 之所以重要，是因为许多关键任务首先以消息、收件箱条目或日程问题的形式出现，然后才变成代码。

Skills 让重复的工作流可复用。一旦一个工作流被验证有用，就把它打包成 skill，这样 Codex 下次就可以直接运行，不用从头重新学习例行流程。

任何地方都能工作

Codex 移动端改变了用户必须在电脑前的时间约束。一个任务可以在 Mac 上启动——那里有文件、权限和本地环境——然后在用户用手机查看时继续推进。

这在小的时刻很重要。你可以在 Codex 跑一个较长的任务时离开工位，在外面回答一个问题，批准下一步，或者在回来之前重新引导线程。本地环境始终保持不变，人不需要在。

自动化

自动化为 Codex 按计划运行任务。当周期性任务应该从工作空间重新开始时（比如日报或定期仓库检查），用定时自动化（Scheduled Automation）。当计划应该回到一个带着上下文的活动会话时，用线程自动化（Thread Automation）。

线程自动化：心跳式的周期性唤醒调用，按计划回到同一个 Codex 线程。

固定线程很有用，但它们仍然在等用户回来。线程自动化可以每隔几分钟或每隔几小时检查一件事，持续直到满足某个条件，并随时间调整节奏。

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

• 每 30 分钟，检查 Slack 和 Gmail 中有没有需要我关注的未回复消息。
• 帮我按优先级排序。
• 如果有人问我问题，尽你所能深入研究答案并草拟回复，但不要发送。

当用户回来时，收集上下文这个最费时的部分通常已经完成了。人仍然决定最后发什么。

线程自动化也适合反馈循环。一个线程自动化可以盯着 pull request 上的评论、Google Docs 上的批注或 Slack 上的回复，在用户离开时让周围的工作保持推进。

想象一个动画工作流：审查者在 Slack 里分享一个视频。线程自动化可以按计划检查线程，在收到评论时渲染一个更新版本，并在同一个线程中回复，标记审查者。如果某个集成环节无法完成最终上传，桌面自动化可以通过 GUI 完成这最后一步。

这个循环串联了 Slack（反馈）、代码仓库（渲染）和桌面自动化（最终上传）。

Goals

当任务有一个 agent 可以持续推进的真正终点时，Goals 的威力最大。一个弱 goal 是：

Goals：较长时间运行的 Codex 任务，带有 agent 能持续推进的终点线。

"实现这个 Markdown 文件中的计划。"

一个更强的 goal 带有可度量的成功标准。

比如，一个工程师要把内部工具从 Python 迁移到 Rust，可以建好新目录，定义 goal，并让终点线变得明确：新实现在所有单元测试通过之前不算完成。

一个 goal 把持续执行和验证器结合起来。用户定义结果、停止条件和判断 Codex 是否在接近目标的信号。

有用的验证器包括：

• 一套测试
• 一个 benchmark
• 一个 bug 复现
• 一个验证矩阵
• 一个必须持续通过的端到端工作流

志向很重要，但没有验证，它就只是个愿望。

侧边面板

侧边面板让工作停留在产生它的对话旁边。用户不必导出产物再切换上下文，可以直接原地审查。产物可以是代码，也可以是一份幻灯片、一份 PDF、一个浏览器页面、一个表格或是沿途产生的其他产物。

它在四件事上尤其出色：

• 审查产物
• 标注需要改的地方
• 操作网页界面
• 审查变更

侧边面板让用户原地审查 Markdown、表格、数据表、文档和幻灯片。他们可以不跳出循环就检查、标记和修订产物。

标注

标注

幻灯片或 PDF 可以在产生它的线程旁边保持打开状态，随时准备好接受直接审查和修补。

Codex 中的表格

Codex 中的表格

内置浏览器让 Codex 审查渲染后的页面、控制它，并直接响应审查界面上的标注。对页面或产物的评论留在工作循环内，不会变成另一个独立的交接。

网页同时变成了产出物和控制界面。Codex 可以构建一个产物，在侧边面板中打开它，审查它，调试它，并在原地持续完善同一个对象。

Codex 侧边面板中的网页审查

这些界面尤其好用：

• index.html：适合轻量级静态产物
• Storybook：适合 UI 审查
• Remotion Studio：适合程序化动画
• 基于浏览器的幻灯片：适合做演示
• 数据应用：适合分析工作流

一个单独的 index.html 文件就可以成为一个持久交互产物，不需要服务器。线程自动化也可以随时间刷新静态产物，这样当用户回来时，线程里总是有新的东西等着。

共享记忆

当长运行线程能在任何单一对话之外共享记忆时，它们变得更加有用。

共享记忆：存储在单个线程之外的持久上下文，让未来的工作能够从显式、可审查的东西恢复，而不是凭空开始。

一种持久的模式是将线程锚定在 Obsidian vault 中。实践中就是一个纯文件目录，方便审查、编辑、移动和长期保留。团队可以把那个目录存在云存储、Git、Dropbox、Google Drive 或其他适合他们工作流的同步层中。

一个 vault 大概长这样：

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

在顶层，AGENTS.md 可以定义 Codex 在逐步了解人员、项目、决策和开放循环的过程中，应该如何更新这个工作空间。

不要照搬某个确切的 vault 结构。教 agent 持久上下文应该放在哪里、什么上下文值得保留、以及什么时候不该制造噪音。

一份实用的 AGENTS.md 可能这样写：

• 把 ~/vault 当作持久工作记忆。
• 偏好规范化的笔记，而不是笔记蔓延。
• 显式路由 TODO、人员、项目、每日摘要和草稿笔记。
• 保留决策、阻塞项、负责人、日期和有用的链接。
• 如果没有任何有意义的变更，不要搅动 vault。

仓库保存代码。vault 保存滚动上下文：涉及的人员、什么变了、什么被阻塞了、什么需要跟进，以及那些在会话之间本会消失的东西。

重要的上下文不应该只活在对话转录里。把它写到下一个线程能继续捡起来的地方。

Codex 在 Settings > Personalization > Memories 中也有第一方记忆功能。它为偏好、重复工作流和已知陷阱提供了一层本地回忆。它补充明文的显式上下文，而不是替代它。Chronicle 也朝同一个方向努力，帮助 Codex 从近期的屏幕上下文中构建记忆。

从代码向外延伸

Codex 仍然以代码为起点。但围绕代码的更多工作现在已经可以通过同一个系统触达：MCP 服务器、浏览器界面、桌面控制、线程自动化和可审查的产物。

这改变了控制模式。操控打断进行中的工作。排队安排下一件任务。线程自动化在用户离开时让线程保持活跃。Goals 添加了一条具体的终点线，Codex 可以持续朝它推进。

Codex 现在可以带着一个工作流从指令走到执行再到产物审查，即使这个工作离开了代码仓库。