Codex 最大化

# Codex-maxxing - Jason Liu 来源: https://jxnl.co/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、修改仓库、发布代码。 大概在十一月左右，我开始把它们也用到知识工作中。我用 Slidev (https://sli.dev/) 做演示，用智能体来做语音输入的笔记记录，并持续寻找编程智能体能帮我产出的其他工件：一个 `index.html`、一份 PDF、一个电子表格、一套幻灯片。 最新的 Codex 应用升级，是我第一次体验到的能让这种更广泛的模式变得原生化的工具。Codex 在编程方面依然出色，但更有趣的转变是，它让我的工作有了一个可栖身的地方。 改变我行为的关键，是学会为工作提供一个运作循环：一个持久的线程、共享的记忆、能在我电脑上操作的工具、引导和恢复任务的方式，以及一个能让我审查工件本身的界面。 ## 持久线程¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#durable-threads) 第一件改变我行为的事情是压缩。 压缩 压缩把长时间运行的线程浓缩，使其在不必完整携带每一条旧消息的情况下继续运作。 现在，我会为每一个我关心的关键工作流保留一个固定线程： - 我的“参谋长”线程 - Agents SDK (https://openai.com/index/the-next-evolution-of-the-agents-sdk/) - OpenAI CLI (https://github.com/openai/openai-cli) - Codex for open source (https://openai.com/form/codex-for-oss) - 还有一个专门监控 Twitter 这些不是简短的聊天。它们是巨线程，我已经压缩了好几个月。它们积累了历史、偏好以及旧决策，我不希望每次回来时都要重新构建。 固定线程快捷键 你可以通过 `Command-1` 到 `Command-9` 直接跳转到固定线程。 这里有一个权衡。长时间运行的线程并非免费。如果你后来再访问它们，对话很可能已经不在缓存中，因此你会比在全新的短线程中花费更多成本。对于我在意的工作流来说，连续性值得这个代价。 ## 语音输入¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#voice-input) 语音输入让我更多的实际思考能够进入 Codex。 它的好处并非速度。而是智能体能获取到我未经编辑的思考版本。Codex 有内置的语音输入功能，但我也使用 Wispr Flow，因为系统级别的听写也改变了我能向其他所有工具输入多少上下文。如果我在规划一项工作，我可能会说：“我觉得 Slack 里有个叫 Ben 的家伙提到过这个，我不太记得具体内容了，就去查查吧。” 这句话太模糊，打字很烦人，但说出来却完全自然。 同样的情况也适用于转录文本。如果我想写一篇文章，我可以给别人打电话、录下对话，或者用 Granola 在手机上当面聊，然后用转录文本作为起点材料。当模型能接触到我想法的混乱版本，而不仅仅是修饰后的版本时，很多计划会变得更好。 ## 引导¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#steering) 当语音与引导结合时，它的作用就更大了。 引导 引导在 Codex 正在工作时添加更多指示，而不是等待当前步骤完成。 引导允许你在工具调用之后注入下一条消息。如果我在审查一个网站，我可以在查看的同时继续说话： - 这个再小一点 - 这段文案不对 - 这两个东西之间的间距感觉不对 - 这个完成后，开一个 PR - 等待预览部署 - 把预览链接发给 Slack 上需要审查它的人 我不需要等每一步完成再决定下一步。我可以在智能体还在工作时不断添加意图，然后在队列已经成型后走开。 之后，Heartbeats 可以在离开后监控 PR 或 Slack 线程。工作的单位不再是“一个提示，一个回答”。它变成了一个小型运作循环。 ## 记忆¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#memory) 一旦线程开始持续更久，它们就需要在任何单个仓库之外的共享记忆。 关键点不仅仅是保留消息历史。一个长线程可以记住很多内容，但这些记忆被困在线程之内，除非有用的部分被序列化到某个持久化的地方。记忆系统的目的是把线程学到的东西变成一个我可以审查、编辑、比较差异和复用的工件。 我大多数长时间运行的线程都从一个 Obsidian 仓库开始： `` vault/ ├── TODO.md ├── people/ ├── projects/ ├── agent/ └── notes/ `` 在顶层，我保留了 `AGENTS.md` 指令，内容大致是：当你了解更多关于人的信息、在项目上取得进展或关闭一个未决循环时，更新仓库中相应的页面。 这个仓库是智能体的居住地，与任何单个项目分开。仓库存放代码。仓库存放我工作相关的滚动上下文：人、决策、未决循环、每日笔记、项目状态，以及那些否则会在线程间丢失的理解片段。 我也把仓库作为一个 GitHub 仓库来维护。这给我带来了两样东西： 1. 它可以在云端工作 2. 差异成为记忆的一个审查界面 当智能体更新仓库时，我可以读取 diff，看看它认为哪些东西重要到值得记住。这个审查步骤很重要。我不希望常青线程在对话历史中悄无声息地积累感觉。我希望它们记录下改变的东西：这个人更喜欢这个，这个项目在等待那个，这个决定已经做出，这个循环已经关闭。 这也是我喜欢将记忆保存在文件中的原因。文件迫使智能体将经验压缩成一种可以在线程之外存活的形式。如果线程死亡、压缩得不好或者变得太贵而无法继续依赖，有用的知识仍然在那里。 到了那一步，固定线程开始感觉不像聊天，更像不同的工人在阅读同一个笔记本。 Codex 也有第一方的记忆功能，在 `设置 > 个性化 > 记忆` 中。我认为这些是一个本地回忆层：对于稳定的偏好、重复的工作流程、项目约定和已知陷阱很有用，但不能替代签入的指令或显式的仓库。Chronicle (https://developers.openai.com/codex/memories/chronicle) 在这方面尤其有趣，因为它可以利用最近的屏幕上下文来帮助构建记忆。我还没有认真地使用它，而且文档明确说明这是一个选择加入的研究预览，存在关于权限、速率限制、提示注入和未加密的本地记忆文件的真实权衡。但从方向上看，它指向了我在乎的同一件事：工作应该留下结构化的记忆，而不仅仅是一个更长的聊天记录。 共享记忆 共享记忆在单个聊天之外维护的上下文，比如我仓库中的笔记，不同线程可以重复使用。 ## 计算机和浏览器使用¶ (https://jxnl.co/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 pets (https://developers.openai.com/codex/app/settings#codex-pets) 发布后，我用它安装了 Hatch Pet 技能，但有用的模式是通用的：一旦你做过一次有用的事，你通常可以把它打包，这样 Codex 就能再次执行，而无需重新教导工作流程。 ## 远程控制¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#remote-control) 远程控制让这些更长的循环变得便携。 Codex 可以持续在你文件、权限和本地设置所在的那台机器上工作，同时你可以从移动设备上查看进度、审查它找到的内容、回答一个问题、批准下一步或改变方向，而不必回到你的办公桌前。OpenAI 将之描述为一种从任何地方与 Codex 协作的方式 (https://openai.com/index/work-with-codex-from-anywhere/)。 当 Codex 正在执行长时间运行的任务，而你希望保持势头时，这一点最为重要。你可以开始一个任务，走开，然后在它到达决策点时从手机上进行引导。 这与固定线程、语音和 Heartbeats 的重要性原因相同。工作不再仅仅因为我更换了地点就必须暂停。一个线程可以继续运行，而我可以保持足够的关注来解除下一步的障碍。 ## Heartbeats¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#heartbeats) 固定线程很有用，但它们仍然在等你说话。Heartbeats 是让它们变得可重复的关键。 Heartbeats Heartbeats线程可以为自己安排的定期检查，比如监控 Slack 或拉取请求的新活动。 Heartbeat 是一种线程本地的自动化。你可以说，“每隔几小时关注一下这个”，然后线程可以自行安排。一个线程可以有多个计划，运行直到某个条件满足，并且可以随时间调整其节奏。 ### 参谋长¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#chief-of-staff) 我的“参谋长”线程每30分钟运行一次： `` 每30分钟，检查 Slack 和 Gmail 中未回复、需要我注意的消息。 帮助我优先处理最重要的事情。 如果有人问我问题，尽可能深入地研究答案，并为我起草回复，但不要发送。 `` 当我回到 Slack 时，回复通常已经躺在草稿里了。我仍然决定发送什么，但收集上下文的昂贵部分已经完成了。 ### 监控反馈¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#monitor-for-feedback) 同样的模式也适用于审查循环。Heartbeat 可以监控 Google Docs 评论、拉取请求评论或 Slack 回复，并在反馈到达时保持工作推进。 我最喜欢的例子之一来自一个动画项目。我在 Slack 上发布了一个视频，并指示 Codex 每15分钟检查一次线程的反馈，在收到评论时重新渲染新版本，并回复到线程中提及审查者。Slack MCP 服务器无法上传文件，所以智能体使用 `@computer` 来点击“添加文件”按钮并发布修改后的渲染。 有趣的部分不仅仅是它每15分钟检查一次 Slack。这个循环跨越了工具的边界：Slack 用于反馈，Remotion 用于渲染，`@computer` 用于上传。这时，Heartbeats、连接器和计算机使用不再像是独立的功能。它们一起成为一个反馈循环，无需我在场就能持续运行。 ### 申请退款¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#get-a-refund) 最近我的一个包裹被偷了。亚马逊告诉我联系人工客服大约需要25分钟，所以我创建了一个带有 `@computer` 的线程并告诉它： `` 每5分钟，检查一下客服代表是否已加入这个线程。 如果加入了，尽最大努力帮我要到退款。 一旦他们回复，切换到每分钟检查一次，以便更快回应。 `` 等我洗完澡出来，退款已经办好了。 我的许多 Heartbeat 也会更新我的 Obsidian 仓库，作为一种显式记忆。 ## 目标¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#goals) 最新、我还在学习如何很好使用的东西是 Goals。 Goals 目标带有真正终点线的长期任务，Codex 可以持续朝之推进。 你应该对它们雄心勃勃。一个弱目标是“实现这个 Markdown 文件中的计划”。一个强目标有一个真正的成功标准，智能体能一直朝着这个标准努力。 上周我尝试将 Python Rich (https://github.com/Textualize/rich) 库迁移到 Rust。因为原始项目已经有一个庞大的单元测试套件，我可以设定这样一个目标：将 Rich 迁移到 Rust，但它必须通过原始库的所有单元测试。 那个测试套件给运行提供了一个真正的裁判：Rust 移植完成的条件是它能通过与 Python 库相同的测试。 这与和 AI 进行长时间对话、积累一个 Markdown 计划、然后最终说“实现这个”是不同的。执行只和你给出的目标与验证一样好。没有验证的雄心只是空想。 ## 侧面板¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#the-side-panel) Codex 中最让我兴奋的部分是侧面板。 很容易把这个看成是预览发生的地方。这低估了它。侧面板是 Codex 不再只是一个聊天应用，而是开始成为工作发生的地方的关键。 对我来说，它承担三项工作：检查工件、操作网页界面、审查更改。在这三项中，我都可以查看和评论智能体正在操作的同一个对象。 ### 检查工件¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#inspect-artifacts) Markdown、电子表格、CSV、PDF 和幻灯片都可以放在那里。 Markdown 是可评论的。电子表格渲染公式并支持单元格编辑，我用它来管理 Codex 开源计划。CSV 变成表格而非纯文本。PDF 直接渲染，结合 LaTeX 时尤其有用。幻灯片可以在不离开应用的情况下创建和审查。 重要的不仅仅是 Codex 能够生成工件。而是我可以在不打断循环的情况下检查和注释它们。 ### 操作网页界面¶ (https://jxnl.co/writing/2026/05/10/codex-maxxing/#operate-web-surfaces) 应用内浏览器更有趣。智能体可以看到它，通过 `$browser` 用 JavaScript 控制它，我也可以直接在我正在看的东西上留下注释。 现在我有几个经常这样使用的网页界面： - `index.html` 用于轻量级静态工件 - Storybook 用于审查 UI 组件 - Remotion Studio 用于程序化动画 - Slidev (https://sli.dev/guide/) 用于演示 - Streamlit 用于数据应用 最小的版本往往是最好的。你可以让模型创建一个带 JavaScript 和 CSS 的单一 `index.html` 文件，在侧面板中打开，并立即开始与之交互。无需服务器。我一直在尝试使用 Heartbeats 随时间更新静态的 `index.html`，这样每当我返回一个线程时，已经有一个新鲜的工件在等着我。 Thariq 有一篇非常好的文章 (https://x.com/trq212/status/2052809885763747935)，关于更喜欢 HTML 而非 Markdown 作为输出格式。我觉得这个直觉是对的。一旦输出变成一个小型应用而不仅仅是文档，关系就变了。 如果需要更重量级的东西，我可以用 Vite 应用，但那样我需要保持服务器运行。一个纯 `index.html` 要持久得多。 对于动画工作，我经常有 Storybook 在运行。