如何把 Codex 用到极致

Codex 官方团队的进阶用法：持久对话流、任务干预与排队、对话流自动化、目标驱动、侧边栏审查和共享记忆。

原文线索来自 dotey 的 X 帖子，上游原始来源是 Jason Liu 的文章 Codex-maxxing。

很多人第一次用 Codex 这类 AI Agent 时，只让它干一件事：写代码。比如扫一遍仓库、改几个文件、跑下测试、再提个 PR。

这当然没错，但如果只把 Codex 当成“自动敲代码的手”，其实是把它用窄了。Jason Liu 在原文里强调的一点很关键：真正有价值的，不只是让 Agent 会写代码，而是让工作本身有地方可以持续存在、被记住、被复用、被监督。

也就是说，Codex 最值得学的不是某个单点功能，而是一整套“工作闭环”：

• 用**持久对话流（Durable threads）**承接长期任务
• 用语音输入快速喂给它未经修饰的想法
• 用Steering 和 Queuing 在任务进行中继续加指令
• 用共享记忆 / 外部记忆文件把上下文从单次对话里抽出来
• 用浏览器、电脑操控、连接器、MCP 把能力延伸到仓库之外
• 用Heartbeats / 对话流自动化让任务在你离开时继续运转
• 用Goals 给它一个明确终点
• 用侧边栏直接审查产物，而不是靠聊天窗口猜结果

下面按原文逻辑，把这套方法完整梳理出来。

1. 置顶对话流：把重要工作变成长期线程

Jason 在原文里把这个习惯叫做 Durable threads，而第一步通常是 Pinned threads。

简单说，就是把重要工作流都变成长期存在、持续压缩整理过的“巨型线程”，而不是每次都新开聊天。

例如：

• 一个专门负责日常杂务的“幕僚长”线程
• 一个专门推进某个产品或项目的线程
• 一个专门盯外部反馈的线程
• 一个专门监控社媒或某类信息源的线程

这些线程不是随聊随扔的临时窗口，而是持续积累历史、偏好和旧决策的工作空间。

为什么它重要

长期线程的核心价值不是“快”，而是连续性。

如果没有它，你每次回来都得重新喂一遍背景：

• 之前已经讨论到哪里
• 你个人偏好是什么
• 这个项目卡在哪里
• 哪些决定已经拍板

而用了持久线程后，Codex 可以直接接着往下做，不需要每次从零开始“重新 onboarding 一遍”。

快捷方式

原文提到一个非常实用的细节：置顶线程后，可以直接用 Command-1 到 Command-9 在重要线程之间快速切换。

代价也要知道

这不是没有成本的。长线程重新打开时，历史上下文未必还在缓存里，所以推理成本可能比短线程更高。但对于真正重要、会长期推进的工作流，这个成本通常是值得的。

2. 语音输入：把未经修饰的想法先喂进去

Jason 特别强调，语音输入的价值不是“比打字更酷”，而是它能捕捉到最原始、最未经打磨的想法。

很多念头你说得出来，但懒得打；或者你脑子里有方向，但还没组织成完整 prompt。这个时候语音输入特别合适。

比如这种话，你用嘴说很自然，用手打就很烦：

我记得 Slack 里有个叫 Ben 的人提过这事，细节忘了，你去帮我找找看。

对一个能自己搜索、自己补全背景、再回来汇报的 Agent 来说，这种模糊但高信息密度的输入其实已经足够启动工作。

为什么语音比精修过的 prompt 更有价值

因为它保留了你思考的“毛边”。

原文里提到两种很典型的材料来源：

• 你对着手机口述一个尚未成形的计划
• 你把一次真实对话或会议录音转写后，直接当作起点材料

这类材料往往比一段事后精修过的总结更有价值，因为它保留了：

• 你真正强调的重点
• 你犹豫的地方
• 还没说完但已经冒头的想法

原文还提到，除了 Codex 内置语音输入外，Jason 自己也会用 Wispr Flow 这类系统级语音工具；而在转写材料上，他会把像 Granola 这类工具生成的 transcript 当成后续写作或整理的起点。

3. Steering：任务执行中继续加方向

语音输入和长期线程结合后，下一步就是 Steering。

原文定义得很清楚：
Steering = 在 Codex 已经开工的过程中，继续补充方向，而不是等它做完当前步骤再说。

比如你正在让 Codex 看一个网页、调一个界面、迭代一个本地页面，你可以边看边继续发指令：

• 这个再小一点
• 这句文案不对
• 这两个元素的间距不舒服
• 做完之后顺手开个 PR
• 等预览部署好了再把链接发给审核的人

重点不在某条具体指令，而在工作方式变了：

• 你不需要等每一步执行完再想下一步
• 你可以在它工作时不断塑形
• 你离开时，队列已经按你的意图排好了

这会让“一个 prompt，一个回答”的聊天模式，变成更接近真实协作的工作模式。

4. Queuing：提前把后续动作排上

Steering 是在中途修方向，Queuing 则更像是提前安排“做完这个以后你再干什么”。

比如你可以说：

这一步做完以后，把预览链接发到 Slack 给审核人。

它不会打断当前动作，而是把后续任务排到后面。

这两个概念最好分开记：

• Steering：改正在做的事
• Queuing：安排接下来要做的事

两者一起用，掌控感会比“等它做完一轮再补 prompt”强很多。

5. Shared memory：把上下文从对话里抽出来

原文里有一块本地稿里确实不够完整，就是 Memory / Shared memory。

Jason 的核心观点不是“线程要长”，而是：

线程再长，记忆也仍然被困在对话里。
真正有价值的是把有用的上下文序列化成一个可检查、可修改、可 diff、可复用的外部对象。

这就是为什么他会把长期线程的记忆外置到一个 Obsidian vault 里。

一个典型的知识库结构

保险库/
├── TODO.md
├── 人/
├── 项目/
├── 代理/
└── 注释/

这个 vault 不是某个单独仓库的一部分，而是工作本身的长期记忆层。代码仓库存代码，知识库存：

• 人
• 决策
• 待办闭环
• 每日记录
• 项目状态
• 原本很容易在多轮对话间丢掉的理解

AGENTS.md 很关键

原文特别提到，在这个 vault 的顶层可以放一个 AGENTS.md，告诉 Codex：

• 随着你对人和项目了解得更多，该更新哪些页面
• 做出决策后该记录到哪里
• 哪些 open loop 被关闭了
• 没有实质进展时不要乱改记忆文件

这相当于给“长期记忆层”再加一层规则。

为什么他还把 vault 放进 Git

原文这里还有一个本地稿里容易被忽略的点：Jason 不只是把 vault 当文件夹，而是把它本身也放进 GitHub 仓库。

这样有两个直接好处：

1. 它可以在云端或多端继续工作
2. 记忆更新会变成可审查的 diff

这很重要，因为你不希望 Agent 在长线程里悄悄积累一堆“模糊感受”，却没人知道它记住了什么。你希望它把变化明确写出来：

• 这个人偏好什么
• 这个项目现在在等什么
• 哪个决定已经做出
• 哪个循环已经关闭

Codex 自带记忆功能怎么理解

原文还提到 Codex 自己在 Settings > Personalization > Memories 里也提供官方记忆功能。

Jason 的看法很克制：这个功能更像本地召回层，适合记：

• 稳定偏好
• 重复工作流
• 项目约定
• 常见坑

但它不是你显式知识库和文件化记忆的替代品。

他还提到 Chronicle 这种会利用近期屏幕上下文来帮助建立记忆的方向，不过也提醒这还是研究预览，有权限、速率限制、prompt injection 和本地未加密记忆文件等现实权衡。

结论很简单：
工作不应该只留下更长的聊天记录，而应该留下结构化记忆。

6. 向外延伸：浏览器、电脑操控、连接器与 MCP

当线程有了持久记忆，下一个问题就是：它到底能碰到什么？

原文里 Jason 给了一个非常实用的区分方法：

• $browser：给本地网页界面用，适合检查和标注
• @chrome：给已登录浏览器状态和多标签页用
• @computer：给只能通过图形界面完成的任务用

怎么理解这三者

如果你在迭代本地应用界面，优先考虑 $browser。
如果你需要操作已经登录的浏览器会话，适合 @chrome。
如果某件事只能靠桌面 GUI 点点点完成，那就该上 @computer。

原文还有个很具体的例子：

他的工作机上 Twitter 登在 Safari 里。
如果让 @computer 直接去操作 Safari，就会“占用”掉他正在用的 Safari。
这时 @chrome 更适合，因为它更像是并行使用一组已登录浏览器标签，而不是接管你手头整套桌面操作。

连接器为什么重要

Jason 提到他最常用的连接器是：

• $slack
• $gmail
• $calendar

原因非常实际：很多工作最初出现时，根本还不是代码问题，而只是：

• 一条 Slack 消息
• 一封邮件
• 一个日程冲突

连接器和 MCP 的价值，就是让 Codex 的触角伸到这些真实工作入口里。

Skills 不是花活，是复用

原文也提到 Skills。它的意义不是“炫技”，而是把某个已经被验证有用的工作流包装起来，下次不用再重新教一遍。

这也是为什么他说，一旦某件事做成过一次，往往就应该想办法把它沉淀成 skill，而不是每次重教。

7. 远程控制：你走开以后，任务别停

原文里这一节的重点不是“手机上也能看 Codex”，而是：

工作应该继续留在那台拥有你文件、权限和本地环境的电脑上运转，而你的人可以离开工位。

你可以在自己的 Mac 或工作机上启动一个长任务，然后：

• 去喝咖啡
• 走路回家
• 用手机远程查看它的进展
• 在它卡住时给出批准或方向

这件事真正改变的是节奏：
线程不再因为你离开座位就停摆。

8. Heartbeats：让线程自己定时回来查岗

这一块是本地稿另一个明显不够完整的地方。原文对 Heartbeats 讲得更系统。

它是什么

Heartbeats 可以理解成一种线程级自动化心跳：

让同一个对话线程按设定节奏，自己定时回来检查、推进或响应。

和“定时任务”最大的不同在于，它不是每次从零开始，而是在同一个有历史、有记忆的线程里继续工作。

典型场景 1：Chief of Staff

原文里的一个代表例子，是让一个“幕僚长线程”每 30 分钟跑一次：

每 30 分钟检查一次 Slack 和 Gmail，看看有没有还没回但该处理的消息。
帮我判断优先级。
如果有人问我问题，就尽量把背景研究清楚，先起草回复，但不要直接发出去。

这背后的价值不是代替你做最终决定，而是把最耗时的“收集背景、整理线索、打草稿”先做掉。

典型场景 2：监控反馈循环

另一个例子是盯评论和反馈。

Heartbeats 可以周期性检查：

• Google Docs 评论
• PR 评论
• Slack 线程回复

然后在反馈到来后自动推进后续工作。

原文提到一个动画项目例子：

• 先把视频发到 Slack
• 让 Codex 每 15 分钟检查一次反馈
• 一旦有新意见，就重新渲染一个新版本
• 再回帖并 @ 审核人

更有意思的是，这个闭环跨了多个工具边界：

• Slack 负责收反馈
• Remotion 负责渲染
• @computer 负责完成 Slack MCP 无法直接上传文件时的最后一步 GUI 操作

这个例子说明，Heartbeats、连接器、电脑操控不是孤立功能，而是可以拼成一个完整反馈回路。

典型场景 3：催退款

原文里还有个很生活化的例子，也很能说明它的威力：

包裹丢了，客服要排队 25 分钟。
Jason 创建了一个带 @computer 的线程，告诉 Codex：

每 5 分钟检查一次客服有没有进来。
如果客服出现了，尽力帮我把退款搞定。
一旦他们回复，就切换成每 1 分钟检查一次，以便更快响应。

结果是：他洗完澡回来，退款已经办完了。

这个例子非常说明 Heartbeats 的本质：
不是“帮你自动提醒”，而是让 Codex 在你不盯着的时候继续维持任务推进。

9. Goals：给 Codex 一条真正的终点线

原文里 Jason 对 Goals 的态度很明确：这是他觉得“最新、也还在继续学习怎么用好”的能力。

一个差目标长什么样

比如：

把这份 Markdown 计划实现一下

这类目标的问题是：没有清晰可验证的完成标准。

一个强目标长什么样

强目标一定要有真实的成功判据。

原文举的例子是：把 Python 的 Rich 库迁移到 Rust。
因为原项目已经有一整套完整单测，所以目标可以写成：

迁移 Rich 到 Rust，并且必须通过原库的全部单元测试。

这时测试集就成了一个真正的“oracle”：

• 没通过，就还没完成
• 通过了，才算冲线

Goals 的关键不是野心，是验证

Jason 的这句话特别值得记：

Ambition without verification is just a wish.

也就是：

没有验证机制的野心，只是许愿。

一个好目标，往往离不开一个好 verifier。
原文提到的 verifier 类型包括：

• 完整测试集
• 基准性能测试
• 可稳定复现的 bug
• 验证矩阵
• 必须始终跑通的端到端工作流

所以 Goals 不是“让 Codex 自动冲刺”这么简单，而是：

• 你定义终点
• 你给出停止条件
• 你给出可验证信号

Codex 再围着这个边界持续推进。

10. 侧边栏：从“聊天”进入“做事现场”

原文里 Jason 最兴奋的部分之一，就是 side panel。

他强调：不要把它只当成一个预览窗。

真正的变化是：

侧边栏让 Codex 不再只是一个聊天应用，而开始变成“工作实际发生的地方”。

它主要做三件事

原文总结得很清楚：

1. 检查产物（inspect artifacts）
2. 操作网页表面（operate web surfaces）
3. 审查变更（review changes）

这三件事有一个共同点：
你看到的对象，和 Agent 正在操作的对象，是同一个。

10.1 检查产物

原文点名提到这些都可以在侧边栏里直接看和审：

• Markdown
• 电子表格
• CSV
• PDF
• 幻灯片

而且不是“只能看一眼”：

• Markdown 可以直接评论
• 表格会渲染公式，还能改单元格
• CSV 不再只是原始文本
• PDF 直接渲染，LaTeX 场景尤其方便
• 幻灯片可以在应用内生成和审查

重点不是“Codex 能生成这些文件”，而是：

你可以在不打断闭环的情况下，直接检查并标注这些产物。

10.2 操作网页表面

原文把应用内浏览器描述得更有意思。

Agent 不只是“打开网页”，它还能：

• 看到这个页面
• 通过 $browser 去控制它
• 响应你直接留在页面上的标注

Jason 提到几个他经常这样使用的页面类型：

• index.html：最轻量的静态产物
• Storybook：审 UI 组件
• Remotion Studio：做程序化动画
• Slidev：做演示文稿
• Streamlit：做数据应用

为什么 index.html 特别重要

原文专门强调了一个很实用的判断：

最小版本往往最好。

很多时候，只要让模型生成一个单文件的 index.html，带一点 JS 和 CSS，就已经足够：

• 不用起服务器
• 马上能在侧边栏里打开
• 马上能交互、评论、迭代

如果要更重的工程化界面，当然也能上 Vite，但那意味着你还得维持本地 server。
对很多需要长期留存的工作物而言，单文件 HTML 反而更耐久。

原文甚至提到，他还在实验让 Heartbeats 随时间持续更新一个静态 index.html，这样每次回来时，都已经有一个最新产物在等你。

动画、演示、数据应用这些场景

原文里这些例子也值得保留：

• Storybook 和 Remotion 可以并排打开，边看边评
• 你可以直接批注“这个要更大”“这个要弹一点”
• Slidev 里，Codex 可以帮你检查是否有内容被截断、在幻灯片间切换并响应你的标注
• Streamlit 和类似工具，未来会越来越适合放进这种工作流里

Jason 还专门引用了 Thariq 的观点，大意是：一旦输出从文档变成了小型应用，关系就变了。HTML 作为输出格式，比 Markdown 更适合这种"可交互、可迭代"的工作模式。他认为这个直觉是对的。

11. 共享记忆和侧边栏结合后，工作就不再死在 prompt 之间

原文最后想表达的，不是某个花哨 feature，而是一个整体判断：

当 Codex 同时拥有这些能力：

• 可以记住
• 可以回到同一个线程继续做
• 可以把记忆外置成文件
• 可以碰到仓库之外的真实工具
• 可以定期自己查岗
• 可以有明确目标
• 可以直接在同一界面审产物

你和它的关系就不再是：

• 你发一条 prompt
• 它回一段答案
• 整个过程到此为止

而更像是：

• 你定义方向和边界
• 它在你离开时继续推进
• 你回来时看到的是一个已经演进中的工作系统

12. 这篇教程里最值得直接照抄的实践顺序

如果你不是想“理解概念”，而是想马上开始用，我建议按这个顺序抄作业：

1. 先为长期项目建立 1-3 个置顶线程
2. 给其中至少 1 个线程配一个外部记忆位置 例如 Obsidian vault 或专门的工作记忆仓库
3. 开始在执行中主动使用 Steering 和 Queuing
4. 尝试让它接入 Slack / Gmail / Calendar 这类真实入口
5. 给一个线程加上 Heartbeat，先做最简单的定时检查
6. 给一个真实任务设一个有 verifier 的 Goal
7. 尽量把输出变成可审查的产物 比如 HTML、PDF、表格、幻灯片，而不只是聊天文本

13. 总结

Codex 当然仍然是非常强的代码助手，但 Jason 这篇文章真正想传达的是：
当线程、记忆、工具触角、自动化和审查界面连起来之后，Codex 才开始真正变成一个能持续运转的工作底座。

它最重要的变化，不是“会写代码”这件事本身，而是：

• 工作不再必须在你盯着屏幕时才发生
• 上下文不再只能困在一次对话里
• 产物不再只能靠聊天窗口描述
• 反馈闭环不再要你每次亲手重新串起来

当这些都成立以后，Agent 才不只是”答题器”，而是真正能持续推进工作的协作者。

The more Codex gets places to remember, revisit, inspect, and act, the less my work dies between prompts. That is the change I care about. Not that an agent can write code for me, but that more of my work can keep moving after I leave.

Codex 能记住、能回去、能审视、能行动的地方越多，工作就越不会死在两次 prompt 之间。这才是真正值得在意的变化——不是它能帮我写代码，而是更多工作可以在我不在的时候继续推进。