充分释放 Codex 的潜力

原文：https://x.com/jxnlco/status/2057153744630890620

作者：jason (@jxnlco)

发布时间：2026年5月21日 凌晨1:37

大多数开发者最初使用 AI 编程智能体（Agent）都是为了处理纯代码任务：检查代码库、生成差异对比（diff）、运行测试以及提交拉取请求（PR）。

这目前仍是 Codex 的核心基本盘。不过，如今电脑上的许多工作其实已经通过代码在间接完成了：执行终端命令、浏览网页、调用 API、导出文档、响应事件以及触发自动化流程。随着这些操作界面逐步对 Codex 开放，它感觉上就不再仅仅是一个狭义上的代码助手，而更像是一个帮你在电脑上搞定各种工作的全能系统。

Codex 应用程序让这种转变变得触手可及。一个对话流（Thread）能够持续保留上下文、调用工具、呈现生成物（Artifacts），并跨越多次提示词连续执行，无需在每次对话后都清空重置。

想要让 Codex 发挥更大威力，关键在于将以下能力组合使用：

• 持久化对话流：能完好保存上下文。
• 语音输入、即时引导与任务排队：让用户在保持深度参与的同时，操作更高效。
• 浏览器、电脑控制（Computer-use）、MCP 服务器和连接器：让 Codex 的触角延伸到代码库之外。
• 对话流自动化与“目标”（Goals）功能：在用户离开电脑时，工作依然能继续推进。
• 侧边栏：供用户在原地评审代码、文档、幻灯片和其他生成物。

持久化对话流（Durable threads）

持久化对话流：长期运行的 Codex 对话流，能跨越多次使用会话，完好保存工作上下文。

把常用对话流“固定”（Pin）起来，是将其留在手边随取随用的好办法。这非常适合那些周期性的工作流，例如：

• 幕僚长（指的是组织里统筹协调、替核心负责人打理各项事务的核心助手/总管角色）对话流
• 版本发布对话流
• 文档评审对话流
• 专门用于外部监控的对话流

这些是持久化的工作空间，而非用完即丢的简短聊天。Codex 可以随着时间推移反复复盘这些对话，记住先前的决定、偏好和工作上下文。如果没有这项功能，每次开始新任务都得把这些背景信息从头重建一遍。

固定对话流的快捷键让这一切变得非常实用。按下 Command-1 到 Command-9，就能直接跳转到你保存的各个对话流中。

语音输入

语音输入的价值在于，它能捕捉到想法最原始、粗糙的雏形，避免了在将其转化为工整文字过程中造成的灵感损耗。

Codex 内置了语音输入功能。在面对那些“说起来很自然、打字却很麻烦”的模糊想法时，它的表现格外惊艳：

我记得 Slack 里好像有个叫 Ben 的人提到过这件事，具体细节我想不起来了。你去帮我查一下。

对于一个能够搜索、收集上下文并汇报结果的智能体来说，这样一句话往往就足够了。

在任务完全定型之前，进行两三分钟的“想法倾倒”（Thought dump），这种方式同样非常奏效。

会议记录的转写文本也是同理。一份未经修饰的会议速记或口述的规划笔记，往往比简短的摘要提供了更丰富、更优质的原材料，因为它保留了不确定性、语气重音以及未完成的思绪。

即时引导与任务排队

当语音输入与对活动任务的明确控制相结合时，会释放出更大的威力。

即时引导（Steering）：在 Codex 正在执行的任务尚未完成当前步骤时，直接接入并给予新的方向指导。

当智能体走错了方向，需要在它跑完整个流程前进行纠偏时，“即时引导”就派上用场了。例如，在评审网站时，用户可以一边在侧边栏对界面进行标注，一边直接打断它：

• 把这个调小一点
• 这两个元素之间的间距感觉不太对
• 这段文案写错了

任务排队（Queuing）：在当前步骤完成后，为 Codex 顺次添加后续要执行的任务。

任务排队则有所不同。它不会打断正在进行的工作，而是把下一个任务加到排队队列中。用户可以这样说：

工作完成后，把预览链接在 Slack 上发给评审人。

即时引导改变的是 Codex 当下正在做的事；而任务排队改变的是接下来应该发生的事。这两种方式都能让用户在工作展开的过程中，始终保持紧密的把控。

工具与触角

一旦对话流具备了连续性，接下来的问题就是它能对什么大展身手了。Codex 的能力可以像涟漪一样层层向外扩展：

• $browser：用于侧边栏的内置浏览器，Codex 可以借此检查网页并对界面进行标注。
• @chrome：用于已登录的浏览器状态以及基于 Chrome 的工作流。
• @computer：用于那些只能通过桌面图形界面（GUI）完成的工作。

$browser 完美契合侧边栏的网页评审工作。@chrome 适合那些依赖用户 Chrome 个人环境、需要登录状态的网页操作。@computer 则搞定那些只能靠鼠标点击桌面软件才能完成的任务。

MCP（Model Context Protocol）服务器和连接器将同样的理念延伸到了工作流的其他环节。Slack、Gmail 和 日历 至关重要，因为许多核心任务在变成代码之前，最先是以一条消息、一封收件箱邮件或是一个日程冲突的形式出现的。

“技能”（Skills）则让重复的工作流能够被复用。一旦某个工作流被证明行之有效，就可以将其打包为一项技能，这样 Codex 下次就能直接运行，无需重新学习这一套常规流程。

随时随地开展工作

Codex 移动端应用打破了用户必须守在办公桌前的限制。一项任务可以在 Mac 上启动——那里有现成的文件、权限和本地配置，接着在用户外出时，通过手机就能随时查看和跟进。

这在一些细微的时刻意义重大。当 Codex 运行一个耗时较长的任务时，你可以放心离开座位，在外面回答它的提问、批准下一步操作，或者在回座位前调整对话流的方向。本地环境始终在稳定运行，用户不必再被死死栓在电脑前。

自动化

自动化功能让 Codex 能够按计划定时运行任务。如果一个周期性的工作需要每次从一个干净的工作空间全新启动（例如每日报告或定期的代码库检查），请使用定时自动化（Scheduled automation）。如果需要定时任务回到一个活跃的、保留了运行上下文的对话中，则应当使用对话流自动化（Thread automation）。

对话流自动化：类似心跳机制的周期性唤醒调用，能按计划定时返回到同一个 Codex 对话流中。

固定的对话流固然好用，但它们依然在消极地等待用户回来。而对话流自动化可以每隔几分钟或几小时就去检查某件事，持续运行直到满足特定条件，并随着时间的推移自动调整检查的频率。

一个“幕僚长”对话流可以每 30 分钟运行一次：

每 30 分钟检查一次 Slack 和 Gmail，看看有没有需要我处理的未答复消息。帮我整理出轻重缓急。如果有人向我提问，尽可能深入地研究答案并帮我起草一份回复，但先不要发送。

当用户回到电脑前时，最耗费精力的“收集上下文”阶段通常已经完成了。人类只需要做最后决定：点击发送。

对话流自动化也非常适合“反馈循环”。它可以紧盯拉取请求（PR）的评论、Google Docs 的批注或 Slack 的回复，在用户离开时让周围的辅助工作一直保持推进。

想象一个动画制作的工作流，评审人在 Slack 中分享了一段视频。对话流自动化可以定时检查该对话，在新的修改意见到达时自动渲染出一个更新版本，并在同一对话中回复并艾特（@）评审人。如果某个特定集成插件无法完成最终的上传，桌面自动化还能无缝接管，通过图形界面完成最后一步。

这个闭环跨越了用于收集反馈的 Slack、用于渲染的代码库，以及用于最终上传的桌面自动化。

目标（Goals）

当任务拥有一个清晰的终点线，且智能体能够朝着这个终点持续推进时，“目标”功能将爆发巨大的威力。以下是一个不够理想的目标定义：

目标：耗时更长的 Codex 任务，拥有一个智能体可以随着时间推移持续为之努力的终点线。

❌ 不够理想的定义：实现这个 Markdown 文件中的计划。

而一个更强大的“目标”，应该包含可衡量的成功标准。

例如，一位工程师想要将一个内部工具从 Python 迁移到 Rust，他可以建好新目录，定义好目标，并将终点线具体化：只有当所有单元测试都通过时，新的实现才算完成。

一个“目标”将“持续执行”与“验证器”完美结合。用户定义最终结果、停止条件，以及能够表明 Codex 是否正在逐步逼近目标的反馈信号。

实用的验证器包括：

• 测试套件
• 基准测试（Benchmark）
• Bug 复现脚本
• 验证矩阵
• 必须保持顺畅运行的端到端（E2E）工作流

有雄心壮志固然重要，但如果没有验证机制，目标就仅仅是一个空愿。

侧边栏

侧边栏让你的工作成果与催生出该成果的对话并排呈现。用户无需导出文件再切换软件，在原地就能直接评审。输出的结果可能是代码，但也可能是一份幻灯片、一份 PDF、一个网页、一张表格，或者在过程中创建的其他生成物。

它能够极好地胜任以下四种工作：

1. 检查生成物
2. 标注需要修改的地方
3. 操作网页界面
4. 评审变更

通过侧边栏，用户可以在原位评审 Markdown、电子表格、数据表、文档和幻灯片。他们可以直接检查、标记和修改生成物，而不会打断现有的工作流闭环。

标注功能

幻灯片或 PDF 可以直接在产生它的对话流旁保持打开状态，随时等待直接的评审与修复。

Codex 中的电子表格

应用内浏览器让 Codex 能够检查渲染出的页面、控制它，并直接对正在评审的界面上的标注做出响应。页面或生成物上的评论会保留在工作流内部，而不会变成一个需要单独交接的独立任务。

网络在此刻既是输出结果，又是控制界面。Codex 可以构建一个生成物，在侧边栏中打开它、检查它、调试它，并在原地不断精雕细琢同一个对象。

这些界面形式在实际中表现得尤为出色：

• 用于轻量级静态生成物的 index.html
• 用于 UI 评审的 Storybook
• 用于编程式动画的 Remotion Studio
• 用于演说的基于浏览器的幻灯片页
• 用于分析工作流的数据应用

一个单纯的 index.html 文件就能变成一个持久的交互式生成物，甚至不需要任何服务器支持。对话流自动化还可以在后台随时刷新这些静态生成物，这样当用户返回时，对话里就会有全新的成果在等待评审。

共享内存（Shared memory）

当长期运行的对话流能够将记忆共享到单一对话之外时，它们会变得更加有用。

共享内存：存储在单个对话流之外的持久化上下文，以便未来的工作可以从一个明确且可评审的基础上有序恢复。

一种经受住实践检验的持久化模式是：将长期的上下文锚定在一个 Obsidian 知识库（Vault）中。在实践中，这意味着一个由纯文本文件组成的文件夹，它非常直观，极易被检查、编辑、移动并长期保存。团队可以将该文件夹存储在云存储、Git、Dropbox、Google Drive 或任何适合其工作流的同步层中。

一个知识库的结构可能长这样：

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

在根目录下，你可以用一个 AGENTS.md 文件来定义 Codex 应该如何更新这个工作空间——随着它对人员、项目、决策和未闭环任务的了解逐步深入。

请不要生搬硬套某一种固定的知识库结构。你需要教会智能体的是：持久化的上下文应该存在哪里、哪些背景需要保留，以及什么时候不要去制造无谓的文件改动。

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

- 将 ~/vault 视为持久的工作记忆库。
- 倾向于建立更具权威性的核心笔记，避免笔记无序蔓延。
- 明确对待办事项（TODOs）、人员、项目、每日摘要和草稿笔记进行归类。
- 完好保存决策、绊脚石（blockers）、负责人、日期和有用的链接。
- 如果没有发生实质性的有意义变化，不要对知识库进行无谓的改动。

代码库用来存放代码。而知识库则用来存放不断滚动的上下文：参与其中的人、改变了什么、什么被卡住了、什么需要跟进，以及那些如果不在会话之间记录就会烟消云散的零星信息。

核心的上下文不应该只存在于某一次的聊天记录里。把它写在某个地方，让下一个对话流能够随时无缝接棒。

此外，Codex 在“设置 > 个性化 > 记忆”中也提供了原生的记忆功能。它们为个人偏好、常用工作流和已知踩坑点提供了一个本地的记忆唤回层。它们与明确写下的文本上下文相辅相成，而非取而代之。Chronicle 功能也在朝着这个方向发力，帮助 Codex 从近期屏幕展现的上下文中构建记忆。

从代码向外延伸

Codex 依然是以代码为起点。但如今，围绕代码展开的更多外围工作，都可以通过同一个系统触达：MCP 服务器、浏览器界面、桌面控制、对话流自动化以及可原位评审的生成物。

这彻底重塑了控制模型。即时引导打断正在进行的工作；任务排队让后续任务有序排队；对话流自动化在用户离开时让对话保持活跃；“目标”功能则给出了一个明确的终点线，供 Codex 持续为之努力。

如今，即便工作完全脱离了代码库本身，Codex 也能带着你的工作流，一路从“接收指令”顺畅走向“付诸执行”，最终完成“成果评审”。

最后附上我的Codex 使用记录