jason来自codex团队，这里有一份关于如何最大化使用codex以及我日常使用的基本操作方法的草稿 https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/… 非常欢迎任何反馈

Codex最大化使用 - Jason Liu

来源：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/ https://github.com/jxnl/blog/edit/main/docs/writing/posts/codex-maxxing.mdhttps://github.com/jxnl/blog/raw/main/docs/writing/posts/codex-maxxing.md在Codex出现之前，我已经大量使用编程智能体了。不过，大多数情况下，我都是通过专门为编程工作构建的界面来使用它们：生成diff、修改仓库、发布代码。

大约从11月开始，我开始将它们也推向知识工作领域。我用Slidev做演示，把智能体更多地当作带语音输入的笔记工具，并且持续寻找编程智能体还能帮我产出的其他工件：一个index.html、一份PDF、一个电子表格、一个幻灯片集。

最新的Codex应用升级是第一个让我感觉这种更广泛的模式变得原生的东西。Codex在编程方面依然出色，但更有趣的转变是，它为我的工作提供了一个可以安放的地方。

真正改变我行为的是学会给工作赋予一个“运行循环”：一个持久的线程、共享的记忆、能在我的电脑上执行操作的工具、引导和恢复任务的方法，以及一个可以审查工件本身的界面。

持久化线程

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#durable-threads

第一个改变我行为的是“压缩”。

现在，我会为我关心的每个重要工作流保留一个置顶线程：

• 我的“幕僚长”线程
• 智能体SDK
• OpenAI CLI
• 用于开源的Codex
• 一个专门用来监控Twitter的线程

这些不是简短的聊天对话。它们是巨型线程，我已经压缩了好几个月。它们积累了我不想每次回来都重新创建的历史记录、偏好和旧决定。

置顶线程快捷键

你可以通过 Command-1 到 Command-9 直接跳转到置顶线程。

这有一个权衡。运行时间长的线程并非免费。如果你之后再次访问它们，对话很可能已经不在缓存中了，所以你可能会比使用一个新的短线程花费更多成本。对于我在意的工作流，连续性值得这个代价。

语音输入

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#voice-input

语音输入能让更多我真实的想法进入Codex。

好处不在于速度。而在于智能体能获得我未经修饰的思考版本。Codex内置了语音输入，但我也使用Wispr Flow，因为系统级听写功能也改变了我能向其他所有东西输入多少上下文。如果我在规划一项工作，我可能会说：“我记得Slack里有个叫Ben的家伙提到过这个，具体记不清了，你去看看就行。”这句话太模糊了，打字很烦人，但说出来却非常自然。

同样的情况也适用于对话转录。如果我想写一篇文章，我可以给某人打电话、录下对话，或者用Granola在手机上当面交谈，然后用转录作为起始材料。当模型能接触到我想法的混乱版本，而不是精修过的版本时，很多计划会变得更好。

引导

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#steering

语音在与引导结合时变得更强大。

引导允许你在工具调用之后注入下一条消息。如果我在审查一个网站，我可以在查看的同时不断说话：

• 把这个弄小点
• 这个文案不对
• 这两个东西之间的间距感觉不对
• 这个完成之后，提交一个PR
• 等待预览部署
• 把预览链接发给需要在Slack上审查的人

我不需要等待每一步完成再决定下一步。我可以一边看着智能体还在工作，一边继续添加意图，然后走开，队列已经设置好了。

之后，Heartbeats可以在我离开后监控PR或Slack线程。工作单元不再是“一个提示，一次回答”。它变成了一个小的运行循环。

记忆

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#memory

一旦线程开始持续更长时间，它们就需要在任何一个仓库之外拥有共享的记忆。

重要的不仅仅是保留消息历史。一个长线程能记住很多，但如果有用的部分没有被序列化到持久化的地方，那些记忆就被困在线程里了。记忆系统的意义在于，把线程学到的东西变成一个我可以检查、编辑、对比差异和重复使用的工件。

我大多数长线程都从一个Obsidian仓库开始：

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

在顶层，我保留着 AGENTS.md 指令，上面写着：随着你对人了解得更多、项目取得进展、或者关闭了一个未了结的循环，更新仓库中的相关页面。

这个仓库是智能体居住的地方，与任何一个项目分开。代码库保存代码。仓库保存着围绕我工作的滚动上下文：人员、决策、待办事项、每日笔记、项目状态，以及那些不然就会在线程之间丢失的理解碎片。

我也把这个仓库作为一个GitHub仓库保存。这为我带来了两件事：

1. 它可以在云端工作
2. 差异对比（diff）成为记忆的审查界面

当智能体更新仓库时，我可以阅读差异对比，看看它认为哪些信息足够重要需要记住。这个审查步骤很重要。我不希望永久线程在对话历史中悄悄积累模糊的氛围感。我希望它们写下变化：这个人喜欢这个，这个项目在等待那个，这个决定已经做出，这个循环已经关闭。

这也是为什么我喜欢把记忆作为文件。文件迫使智能体将经验压缩成一种能在线程之外存活的形式。如果线程死亡、压缩不当、或者持续依赖变得太昂贵，有用的知识仍然在那里。

到那时，置顶线程开始感觉不那么像聊天，而更像是不同的工人在读取同一个笔记本。

Codex 在 设置 > 个性化 > 记忆 中也有一方记忆功能。我将其视为一个本地回忆层：对于稳定的偏好、重复的工作流程、项目约定和已知陷阱很有用，但不能替代签入的指令或一个显式的仓库。Chronicle 在这里尤其有趣，因为它可以利用最近的屏幕上下文来帮助构建记忆。我还没有认真使用过它，文档也明确指出这是一个选择加入的研究预览，在权限、速率限制、提示注入和未加密的本地记忆文件方面存在实际权衡。但从方向上看，它指向了我关心的同一件事：工作应该留下结构化的记忆，而不仅仅是更长的聊天记录。

电脑与浏览器操作

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#computer-and-browser-use

一旦一个线程有了记忆，下一个问题就是它能触及什么。

我脑子里最有用的区分是：

• $browser 用于我想要检查和注释的本地网页界面
• @chrome 用于已登录的浏览器状态和多个标签页
• @computer 用于仅以GUI形式存在的工作

如果我在迭代一个本地应用，我会用 $browser。如果我需要在已登录的浏览器会话中工作，我会用 @chrome。如果完成任务的唯一方法是点击桌面应用，我会用 @computer。

在我的工作电脑上，Twitter登录在Safari里。如果我用 @computer 在那里读取Twitter，我就无法使用Safari了。@chrome 在我想让智能体并行使用多个已认证的标签页而不占用我正在使用的整个应用时更好。

连接器将其范围扩展到我的实际工作中。我用得最多的是 $slack、$gmail 和 $calendar，因为Slack线程、收件箱和日历是很多工作在变成代码之前出现的地方。

技能使重复的工作流程可重用。技能创建器和技能安装器是一个很好的起点。技能安装器允许你直接从编辑器添加OpenAI推荐的技能。在 Codex宠物 推出后，我用它安装了Hatch宠物技能，但有用的模式是通用的：一旦你做了一件有用的事，你通常可以将其打包，这样Codex就可以再次执行，而无需重新教授工作流程。

远程控制

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#remote-control

远程控制让这些更长的循环变得便携。

Codex可以在你的文件、权限和本地设置已经存在的机器上继续工作，而你可以从移动端检查，审查它发现的内容，回答问题，批准下一步，或者改变方向，无需回到办公桌前。OpenAI将其描述为一种从任何地方与Codex合作的方式。

当Codex已经在做一些长时间运行的任务，而你希望保持势头时，这一点最为重要。你可以启动一个任务，离开，然后在它到达决策点时用手机引导它。

这与置顶线程、语音和Heartbeats重要的原因相同。工作不再仅仅因为我更换了位置而必须暂停。一个线程可以继续运行，而我可以保持足够的注意力来解除下一步的阻碍。

Heartbeats

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#heartbeats

置顶线程很有用，但它们仍然在等着你说话。Heartbeats 是让它们变得周期性的东西。

Heartbeat 是一个线程本地的自动化。你可以说：“每隔几个小时盯一下这个，”然后线程就可以自我安排。一个线程可以有多个调度，一直运行直到某个条件满足，并随着时间的推移调整其频率。

幕僚长

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#chief-of-staff

我的“幕僚长”线程每30分钟运行一次：

每30分钟，检查Slack和Gmail中需要我关注的未回复消息。
帮助我确定什么最重要。
如果有人问我问题，尽可能深入研究答案，为我草拟回复，但不要发送。

当我回到Slack时，回复通常已经准备好了草稿。我仍然决定发送什么，但收集上下文的昂贵部分已经完成了。

监控反馈

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#monitor-for-feedback

同样的模式也适用于审查循环。Heartbeat 可以监控Google Docs评论、Pull Request评论或Slack回复，并在反馈到来时保持工作推进。

我最喜欢的例子来自一个动画项目。我在Slack里发了一个视频，告诉Codex每15分钟检查一次线程以获取反馈，在收到评论时重新渲染一个新版本，然后回复到线程里并@评论者。Slack MCP服务器无法上传文件，所以智能体使用了 @computer 来点击“添加文件”按钮并发布修改后的渲染结果。

有趣的部分不仅仅是它每15分钟检查一次Slack。这个循环跨越了工具边界：Slack用于反馈，Remotion用于渲染，@computer用于上传。这时，Heartbeats、连接器和电脑操作不再像是独立的功能。它们共同构成了一个持续运行的反馈循环，无需我坐在那里。

获取退款

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#get-a-refund

最近我有个包裹被偷了。亚马逊告诉我需要大约25分钟才能联系到人工客服，所以我创建了一个带有 @computer 的线程，并告诉它：

每5分钟，检查客服人员是否已加入此线程。
如果已加入，尽最大努力帮我要到退款。
一旦他们回复，切换到每分钟检查一次，这样我可以更快回应。

等我洗完澡出来，退款已经办好了。

我的许多Heartbeat还会更新我的Obsidian仓库，作为一种显式的记忆。

目标

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#goals

我仍在学习如何最好使用的最新东西是“目标”。

你应该对它们抱有雄心。一个弱的目标是“实现这个Markdown文件中的计划”。一个强的目标有一个真正的成功标准，智能体可以持续努力去达成。

上周我尝试将Python的Rich库移植到Rust。因为原始项目已经有了庞大的单元测试套件，我可以设定一个目标：将Rich移植到Rust，但它必须通过原始库的所有单元测试。

那个测试套件为这次运行提供了一个真正的检验标准：Rust移植版本只有通过了与Python库相同的测试才算完成。

这与和AI进行长长的对话、积累一个Markdown计划、然后最终说“实现这个”是不同的。执行的质量只取决于你给出的目标和验证标准。没有验证的雄心只是一个愿望。

侧边面板

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#the-side-panel

Codex中最让我兴奋的部分是侧边面板。

很容易把它想象成一个预览发生的地方。这低估了它。侧边面板是Codex停止仅仅作为一个聊天应用，开始成为工作发生的地方的地方。

对我来说，它承担三项工作：检查工件、操作网页界面、审查更改。在这三项中，我都可以查看并与智能体正在操作的同一个对象进行互动。

检查工件

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#inspect-artifacts

Markdown、电子表格、CSV、PDF和幻灯片都可以放在那里。

Markdown是可以评论的。电子表格会渲染公式并支持单元格编辑，我用来管理Codex开源计划。CSV变成表格而不是原始文本。PDF直接渲染，对于LaTeX尤其有用。无需离开应用就可以创建和审查幻灯片。

重要的不仅仅是Codex能生成工件。而是我可以检查和注释它们，而不会打断循环。

操作网页界面

原文链接：https://jxnl.github.io/blog/writing/2026/05/10/codex-maxxing/#operate-web-surfaces

应用内的浏览器更有趣。智能体可以看到它，通过 $browser 用JavaScript控制它，而且我可以直接在我正在看的东西上留下注释。

现在有几个网页界面我一直这样用：

• index.html 用于轻量级的静态工件
• Storybook 用于审查UI组件
• Remotion Studio 用于程序化动画
• Slidev 用于演示文稿
• Streamlit 用于数据应用

最小的版本往往是最好的。你可以让模型制作一个包含JavaScript和CSS的单一 index.html 文件，在侧边面板中打开它，然后立即开始与之交互。无需服务器。我一直在尝试使用Heartbeats随时间更新一个静态的 index.html，这样每当我回到一个线程时，已经有一个新鲜的工件在等着我了。

Thariq有一篇非常好的帖子，他认为HTML比Markdown更适合作为输出格式。我认为这个直觉是对的。一旦输出变成了一个小的应用程序而不仅仅是一个文档，关系就变了。

如果我需要更重的玩意儿，我可以使用Vite应用，但那样我需要保持服务器运行。一个简单的 index.html 要耐用得多。

对于动画工作，我经常同时打开Storybook和Remotion Studio。我可以留下“让这个弹跳”或“这个应该更大”之类的评论，并且智能体可以检查我正在查看的同一个浏览器状态，包括当前帧。