一个有趣的发现#

Jason Liu 是 Python Instructor 库的作者，在 AI 工具链领域深耕多年。他最近写了一篇文章，分享了自己使用 OpenAI Codex 的独特方式，引发了 Hacker News 上近百条讨论。

核心观点很简单：大多数人把 Codex 当成一个写代码的聊天机器人来用，但它真正的潜力在于成为一个「有记忆、能持续运转的工作平台」。

这篇文章不是 Codex 的入门教程，而是一套进阶方法论。如果你已经用过 Codex，但总觉得「好像还能做更多」，那接下来的内容可能会给你一些启发。

持久线程：让对话不会白费#

你有没有这种经历：跟 AI 聊了很久，把项目背景、需求细节都交代清楚了，结果第二天打开新对话，一切又要从头说起？

Jason 的做法是为每个重要的工作流创建一个「持久线程」，并且把它钉住（Pin）。他在 Codex 里维护了好几个长期线程：

  • 一个「参谋长」线程，处理日常事务协调
  • 一个用于 Agents SDK 开发
  • 一个用于 OpenAI CLI 项目
  • 一个专门监控 Twitter 动态

这些不是短对话，而是持续数月的「超级线程」。Codex 的压缩（Compaction）机制会自动把旧消息浓缩，保留上下文的同时释放内存。你可以用 Command+1 到 Command+9 快速跳转到钉住的线程。

这里有个权衡：长期线程不在缓存中，重新访问时的推理成本会比新对话高。但对于重要的工作流来说，连续性带来的价值远超这点成本。

我的看法是，这个模式特别适合那些需要持续迭代的项目。比如你正在做一个开源库的重构，每天花半小时推进一点，持久线程能让你省去反复交代背景的时间。

语音输入：把脑子里的东西倒出来#

Jason 提到一个很有意思的观察：语音输入的价值不在于打字速度，而在于它能把你「未经编辑的思考」直接传给 Codex。

他举了个例子：「我觉得 Slack 上有个叫 Ben 的人提过这个，具体说了什么我记不清了，你去查一下。」这句话你大概懒得打出来，但说出来就很自然。而 Codex 拿到这种模糊的指令后，居然真的能去 Slack 搜到相关信息。

他还用 Granola 录制线下对话，把转录文本作为写作素材。比起精心组织的提示词，这种「粗糙版」的想法有时反而能给模型更好的上下文。

这个思路值得借鉴。很多人跟 AI 交互时会不自觉地「美化」自己的表达，把提示词打磨得很精确。但实际上，模型处理自然语言的能力已经很强了，你完全可以像跟同事说话一样跟它沟通。

实时纠偏：边看边说，不用等#

这是 Jason 最推崇的功能之一。Codex 的「Steering」机制允许你在它还在执行任务的时候，随时插入新的指令。

想象这个场景：你让 Codex 帮你审一个网页。它还在工作，你已经看到了几个问题：

  • 「这个字号太小了」
  • 「这段文案不对」
  • 「间距再调大一点」
  • 「改完之后开个 PR」
  • 「等预览部署好了，把链接发到 Slack 上」

你不需要等它做完每一步才能说下一步。这种「边看边说」的交互方式，让工作流从「一次提问，一次回答」变成了一个持续运转的操作循环。

在传统的工作模式下，你是 AI 的「审批者」，每一步都要等它完成、你审核、再给下一步指令。Steering 把这个模式打破了，你变成了「共同驾驶者」。

共享记忆：给 AI 一个笔记本#

线程能持久化了，下一步就是让知识在线程之间流通。Jason 用 Obsidian 仓库（Vault）作为 Codex 的共享记忆层。

他的仓库结构大致是这样的：

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

仓库顶层放着 AGENTS.md 指令，告诉 Codex：当你了解到新的人员信息、推进了项目进度、或者关闭了一个待办事项，就更新仓库里对应的页面。

关键的设计决策是：仓库是一个 Git 仓库。这带来了两个好处：

  1. Codex 可以在云端操作它
  2. 每次更新都有 diff，你可以审查 AI「记住了什么」

Jason 特别强调了「审查」这个环节。他不希望 AI 在对话历史里默默积累一些模糊的印象，而是要求它把学到的东西写成明确的文件：这个人偏好什么，这个项目在等什么，这个决策是怎么做的，这个待办已经关闭了。

这种「记忆即文件」的设计还有一个好处：即使线程丢失了、压缩出错了、或者成本太高不想继续用了，有价值的知识仍然保存在文件里。

我个人觉得这个模式非常优雅。很多 AI 工具的记忆功能是黑盒的，你不知道它记了什么、忘了什么。把记忆显式化为文件，既可审查，又可版本控制，还能跨工具复用。

浏览器与电脑控制：AI 能碰的东西更多了#

Jason 区分了三种控制模式：

  • $browser：用于本地 Web 应用的预览和标注
  • @chrome：用于需要登录态的浏览器操作，支持多标签页并行
  • @computer：用于只能通过 GUI 操作的任务

选择哪种取决于任务的性质。如果你在调试一个本地 Web 应用，用 $browser 就够了。如果你需要 Agent 帮你操作一个需要登录的网站，用 @chrome。如果任务必须通过桌面应用的图形界面完成，用 @computer。

此外，Codex 的连接器（Connectors）可以对接 Slack、Gmail、日历等常用工具。Jason 用得最多的就是这三个，因为「Slack 线程、收件箱和日历是很多工作在变成代码之前的样子」。

心跳自动化：让 AI 自己「值班」#

如果说持久线程让对话不会白费，那「心跳」（Heartbeats）就是让线程自己动起来。

心跳是线程级别的定时任务。你可以告诉 Codex：「每隔几个小时检查一下这个。」线程会自己调度执行，可以同时设置多个调度，可以设定终止条件，还能动态调整频率。

Jason 的「参谋长」线程每 30 分钟执行一次：

每 30 分钟检查 Slack 和 Gmail，找出需要我回复的消息，帮我排优先级。如果有人问了问题，尽可能深入地研究答案，拟好回复草稿，但不要发送。

当他回到 Slack 时，回复草稿往往已经准备好了。他仍然决定哪些消息该发，但收集上下文这个最耗时的部分已经完成了。

更有趣的是一个动画项目的例子。Jason 在 Slack 发了一段视频，请 Codex 每 15 分钟检查一次线程里的反馈。收到评论后，Codex 会用 Remotion 重新渲染一个版本，然后在 Slack 线程里 @ 提交反馈的人。Slack MCP 不支持上传文件，所以 Agent 用了 @computer 来点击「添加文件」按钮完成上传。

这个案例展示了多个能力的协同：心跳做定时调度，Slack 连接器读取反馈，Remotion 渲染动画，@computer 处理文件上传。单独看每个功能都很普通，组合在一起就形成了一个不需要人盯着的反馈循环。

还有一个更接地气的例子：Jason 的快递被偷了，亚马逊说要等 25 分钟才能跟人工客服聊。他创建了一个线程，用 @computer 告诉 Codex：

每 5 分钟检查客服是否加入了对话。如果加入了，尽量帮我拿到退款。对方回复后，改成每分钟检查一次，这样能更快响应。

等他洗完澡出来，退款已经搞定了。

目标系统：给 AI 一个真正的「完成标准」#

Codex 最近新增了 Goals 功能，用于处理更长期的任务。Jason 强调了一个关键区别：好的目标不是「按照这个 Markdown 文件执行计划」，而是有一个 AI 可以持续推进的真实成功标准。

他举了个很硬核的例子：把 Python 的 Rich 库迁移到 Rust。因为原项目有完善的单元测试套件，他设定了这样的目标：「把 Rich 迁移到 Rust，但必须通过原库的所有单元测试。」

这个测试套件就是一个真正的「验证器」：Rust 版本不算完成，直到它通过了跟 Python 版本相同的测试。

Jason 总结得很精辟：「没有验证的野心只是幻想。」这句话适用于所有 AI 编程场景。如果你给 AI 一个模糊的任务描述，它也只能给你一个模糊的结果。但如果你能定义什么是「完成」，AI 就能持续迭代直到达标。

侧边栏：工作发生的地方#

Jason 对 Codex 的侧边栏功能特别兴奋。他认为很多人把它当成「预览窗口」，这低估了它的价值。

侧边栏做了三件事：检查产物、操作 Web 界面、审查变更。在这三种场景下，你看到的就是 Agent 正在操作的对象。

对于 Markdown、表格、CSV、PDF、幻灯片这些产物，侧边栏可以直接渲染和编辑。Markdown 支持评论，表格支持单元格编辑，PDF 可以直接预览，幻灯片可以在应用内创建和审查。

对于 Web 应用，内置浏览器更有趣。Agent 可以通过 $browser 用 JavaScript 控制它，你也可以直接在页面上留下标注。Jason 经常用来做轻量级的 index.html 原型，不需要启动服务器就能在侧边栏里交互。

他还提到了一个有趣的趋势：比起 Markdown，HTML 作为输出格式正在变得更受欢迎。一旦输出从「文档」变成「小应用」，你和 AI 的关系就变了。

写在最后#

Jason 的这篇文章最大的价值不在于介绍了 Codex 的某个具体功能，而在于展示了一种思维方式的转变：从「AI 是我发出指令后等待结果的工具」变成「AI 是一个可以持续运转、有记忆、能自主执行任务的工作伙伴」。

持久线程给了连续性，语音输入降低了交互门槛，实时纠偏让协作更流畅，共享记忆让知识不丢失，心跳自动化让任务自己跑起来，目标系统给了明确的完成标准。

这些功能单独拿出来都不算惊天动地，但组合在一起，就构成了一套完整的「AI 驱动工作流」。Jason 的核心洞察是：AI 编程助手的终极形态不是写更多的代码，而是让更多的工作能在你离开之后继续推进。

当然，这套方法论有它的适用门槛。你需要对 Codex 的功能有深入了解，需要投入时间搭建记忆体系，还需要对 AI 的自主行为保持一定的监督。但对于那些每天重度使用 AI 工具的开发者来说，这些投入的回报是非常可观的。

参考来源： Jason Liu, “Codex-maxxing”, jxnl.co, 2026-05-10. 原文链接：https://jxnl.co/writing/2026/05/10/codex-maxxing/