前几天看到 Jason（OpenAI 的人）发了一篇讲 Codex 用法的长文，数据很夸张——一千六百多人收藏。我仔细看完之后，说实话有点感慨：大多数人用 Codex 的方式，可能连它三成的能力都没碰到。
不是说大家用得不好，而是 Codex 这个工具的设计本身就在悄悄往前走，很多能力已经在那里了，但你如果不主动去摸，它就安安静静地待着，不打扰你，也不帮你。
今天就借 Jason 那篇内容，结合我自己用 Codex 和 Hermes Agent 的经验，把几个真正能改变工作方式的点拎出来聊聊。
别只拿它当代码助手
大多数人第一次用 Codex 的流程是：看仓库、改代码、跑测试、提 PR。这没问题，这也是它的核心。
但 Codex 能做的事早就超出这个范围了。执行 Shell 命令、浏览网页、调 API、导出文档、响应事件、触发自动化——这些在电脑上的活，本质上都是“代码在中间做调度”。当这些能力被 Codex 接管之后，它就不只是一个写代码的助手了，更像是一个帮你把电脑活干完的系统。
这个转变听起来抽象，但用起来感受很具体。
持久线程：别每次都从头来
Codex 现在支持持久线程了。什么意思呢？就是一个对话可以跨多次使用保持上下文，不用每次都重新解释“我是谁、我在干嘛、上次做到哪了”。
Jason 提到了一个用法我觉得特别好：把高频工作流钉住。 比如你可以固定一个“参谋线程”，专门帮你处理日常杂事；一个“发版线程”，跟踪每次发布的进度；一个“文档审阅线程”，持续维护你的文档体系。
这些不是一次性聊天，而是长期工作空间。Codex 会在里面记住你之前做过的决定、你的偏好、你处理过的问题。快捷键 Command-1 到 Command-9 可以直接跳到这些钉住的线程，很方便。
我个人觉得这个思路跟 Hermes 的 Obsidian vault 持久化记忆是一个方向——难的不是让 AI 干一次活，而是让它别失忆。
语音输入：先别想清楚也能开始
这个功能很多人可能没注意。Codex 内置了语音输入，特别适合那些“脑子里有个模糊想法但还没组织好”的时刻。
比如你可以直接说：
我记得好像有个人叫 Ben 在 Slack 里提过这个事，具体细节我忘了，你帮我查一下。
对于一个能搜索、能收集上下文、能汇报的 Agent 来说，这就够了。你不需要先把想法打磨成完美的文字再说出来。
Jason 还提到了一个很妙的点：会议录音转写比摘要更有用。 因为原始转写保留了不确定性、语气重点和没想清楚的思路，这些对 Agent 来说才是真正的输入材料。摘要反而是信息损耗后的产物。
驾驭和排队：边干边调
这是两个容易混但完全不同的操作。
驾驭（Steering） 是在 Codex 正在干活的时候打断它，给新方向。比如它在帮你审一个网页，你看着觉得“这个间距不对”“文案换一下”，直接打断它说就行，不用等它做完。
排队（Queuing） 是给它安排下一件事。比如“做完这个之后，把预览链接发到 Slack 里给 reviewer”。它不打断当前任务，只是把下一条加到队列里。
驾驭改变的是现在，排队改变的是下一步。两个一起用，你就能在任务推进的同时保持控制感，不用干等它做完才发现方向跑偏了。
触角往外伸：不只是仓库里的事
Codex 的能力边界在持续往外扩：
- $browser：侧边栏内置浏览器，可以直接审网页、做标注
- @chrome：调用你登录态的 Chrome，处理需要账号权限的工作
- @computer：接管桌面 GUI，处理那些只能通过鼠标点击完成的任务
再往外，MCP 服务器和连接器把 Slack、Gmail、日历这些工具也拉进来了。很多重要的事先是一条消息、一封邮件、一个日程邀请，然后才变成代码问题。把这些渠道打通，Codex 才真正能帮你“从头到尾”处理一件事。
还有 Skills——当你发现某个工作流好用，可以打包成 Skill，下次直接复现，不用从头教。
离开工位也能继续
Codex 的移动端 App 改变了一个很现实的问题：你不需要一直坐在电脑前了。
任务可以在 Mac 上启动（因为文件、权限、本地环境都在那里），然后你用手机随时检查进度、回答问题、批准下一步。本地环境不动，人可以走。
Jason 举的例子很生活化：离开座位让 Codex 跑一个长任务，中途从手机上回答一个问题或者调整一下方向，回来的时候发现上下文收集的活已经干完了，你只需要做决定。
自动化和目标：让它自己跑
定时自动化适合那些需要定期从头跑的任务，比如每天出一份报告、定期检查仓库状态。
线程自动化更有意思——它是“心跳式”的，定期回到同一个线程检查一下。比如你可以设一个参谋线程，每 30 分钟检查一次 Slack 和 Gmail，把需要你处理的事情整理好，能研究的先研究，但不替你发出去。等你回来的时候，最耗时间的上下文收集已经做完了，你只管做判断。
Jason 说了一句我觉得很到位的话：自动化的核心不是替你做决定，而是替你省掉“了解情况”的时间。
Goals 是另一个利器。它给 Codex 一个明确的终点线。弱目标是“把这个 Markdown 文件里的计划实现了”，强目标是“把 Python 项目迁移到 Rust，直到所有单元测试通过为止”。
目标 + 验证器（测试套件、基准测试、bug 复现、端到端工作流）才是真正的闭环。没有验证器的目标只是愿望。
侧边栏：产出和对话不分离
Codex 的侧边栏不只是看代码的地方。代码、PPT、PDF、网页、数据表格——所有在对话过程中产生的产物都可以在侧边栏里直接查看、标注、修改。
不需要导出到别的软件再切换上下文。Codex 可以在侧边栏打开一个网页，检查它、调试它、在页面上直接标注要改的地方，然后继续迭代。网页既是产出物，也是控制面。
Jason 特别提到了几个好用的场景：一个 index.html 文件就能变成一个不需要服务器的交互式产物；Storybook 做 UI 审查；Remotion Studio 做动画；基于浏览器的幻灯片做演示。
共享记忆：别把上下文只存在对话里
长期线程变得好用的前提是：上下文不能只活在某一次对话里。
Jason 推荐了一个做法：用 Obsidian vault 作为持久工作记忆。一个文件夹，里面放 TODO、人物笔记、项目进展、决策记录，同步到云端或 Git。AGENTS.md 告诉 Codex 怎么维护这个空间——记什么、不记什么、什么时候不该动。
仓库存代码，vault 存流动的上下文。
这个思路我在 Hermes 上一直在用，确实有效。关键不是建多少文件夹，而是教 Agent 什么值得记、什么不该记。记太多叫噪音，记太少叫失忆。
说到底
Codex 还是从代码出发的。但它能触及的范围已经远超仓库本身了：MCP 服务器、浏览器、桌面控制、线程自动化、可审阅的产物。
控制模型也变了。驾驭打断当前，排队安排下一步，线程自动化在你离场时维持运转，Goals 给一个终点线让它自己追。
它现在能把一个工作流从指令带到执行再到产物审查，哪怕这个工作流已经出了代码仓库的范围。
如果你也在用 Codex，或者在用 Hermes Agent 这类工具，建议认真想想：你是在用它改代码，还是在用它帮你干活？ 这两个状态之间，差的不是功能，是用法。