很多开发者第一次使用 coding agent，通常都是从最熟悉的事情开始：让它看仓库、改代码、跑测试、生成 diff，然后开一个 PR。

这当然仍然是 Codex 的核心场景。但如果你只把 Codex 当成“会写代码的助手”，其实只用到了它的一小部分。

因为我们在电脑上做的大量工作，本质上已经被代码和工具包了一层：执行 shell 命令、浏览网页、调用 API、导出文档、回复消息、触发自动化任务。只要这些入口逐渐交给 Codex，它就不再只是一个狭义的编程助手，而会更像一个“帮你完成电脑工作的系统”。

Codex app 把这个变化变得很具体：一个 thread 可以持续保留上下文、调用工具、展示产物，并且在多轮提示之间继续推进，而不是每次对话都从零开始。

想把 Codex 用得更深，可以把下面这些能力组合起来：

• 持久线程：让上下文和工作流长期保留下来
• 语音输入、任务 steering 和 queuing：让你一边工作一边调整方向
• browser、computer-use、MCP servers 和 connectors：让 Codex 走出代码仓库
• thread automations 和 Goals：让它在你离开时继续推进
• side panel：在对话旁边直接审阅代码、文档、幻灯片和其他产物

下面逐一拆开讲。

1. 把 thread 当成长期工作台，而不是一次性聊天

所谓 durable threads，就是能在多次会话之间保留工作上下文的长期 Codex 线程。

一个很实用的做法，是把重要 thread pin 起来。比如：

• Chief of Staff thread：帮你处理消息、日程、待办和优先级
• Release thread：专门跟进一次发布
• Documentation review thread：长期做文档审阅
• External monitoring thread：持续监控外部信息源

这些不是临时聊天窗口，而是一个个持续存在的工作空间。Codex 可以反复回到同一条 thread，记住之前的决策、偏好和上下文。否则，每次你都要重新解释一遍背景，精力就会被大量消耗在“重新开机”上。

如果你经常使用固定的工作流，pinned-thread shortcuts 也很有用：Command-1 到 Command-9 可以直接跳到已保存的线程。

这听起来像一个小功能，但小功能一旦高频，就会改变使用习惯。

2. 用语音输入捕捉还没成型的想法

语音输入的价值，不在于它比打字更“高级”，而在于它能保留想法刚出现时的粗糙状态。

很多时候，我们脑子里的任务并不是一段清晰 prompt，而是这样：

我记得 Slack 里好像有个叫 Ben 的人提过这件事。
具体细节我忘了。
你去找一下。

对一个能搜索、收集上下文、整理结果的 agent 来说，这已经够了。

Codex 内置语音输入，尤其适合两类场景：

• 你还没想清楚任务，但想先把线索倒出来
• 你有一大段会议记录、口述计划或临时想法，不想压缩成几句摘要

这里有个关键点：原始 transcript 往往比短摘要更适合交给 Codex。因为 transcript 会保留犹豫、强调、未完成的句子和上下文里的细节。很多有用信息，恰恰藏在这些“不够整齐”的地方。

3. 区分 steering 和 queuing：一个改现在，一个排后面

语音输入真正变强，是在它和任务控制结合之后。

Steering 指的是：Codex 正在执行任务时，你直接插入新的方向，让它马上调整。

比如你让 Codex 做一个网站审阅，它正在看页面，你在 side panel 里一边标注一边说：

• 这个元素小一点
• 这两个模块之间的间距不对
• 这段文案写错了

这不是等它做完再反馈，而是在它还没跑偏太远时，把方向扭回来。

Queuing 则不同。它不是打断当前任务，而是把下一件事排进队列。

比如你可以说：

等这部分做完，把预览链接发给 Slack 里的 reviewer。

Steering 改变的是 Codex 现在正在做什么。Queuing 改变的是当前任务完成之后要做什么。

这两个能力放在一起，会让用户始终贴在工作流边上：你不需要事事亲自做，但也不会把方向盘完全交出去。

4. 让 Codex 走出代码仓库

当一个 thread 有了连续性，下一个问题就是：它能操作什么？

Codex 的能力可以一层层向外扩展：

• $browser：用于 app 内置浏览器，适合在 side panel 里审阅网页、检查渲染效果、做标注
• @chrome：用于依赖你 Chrome 登录态的网页工作流
• @computer：用于只能通过桌面 GUI 操作的任务

简单理解：

• $browser 适合做 side-panel 里的网页审阅
• @chrome 适合处理需要你 Chrome 账号状态的工作
• @computer 适合那些没有 API、只能点界面的桌面任务

MCP servers 和 connectors 则把同一套思路扩展到更多工作流里。比如 Slack、Gmail、Calendar 这些入口很重要，因为很多任务最早并不是以“代码需求”的形式出现的，而是出现在消息、邮件或日程里。

另外，Skills 适合沉淀重复工作流。某个流程一旦被证明有用，就应该把它打包成 skill，让 Codex 下次不需要重新学习整套套路。

5. 不在电脑前，也能继续推进

Codex mobile app 改变的是“你必须坐在电脑前才能推进任务”这件事。

一个任务可以从 Mac 上启动，因为文件、权限和本地环境都在那里。然后你离开桌面，用手机继续查看进度、回答问题、批准下一步，或者在任务跑偏前把它拉回来。

这在小场景里尤其有用。比如你要出门，但 Codex 正在跑一个比较长的任务。过去你可能只能等回到电脑前再看。现在你可以在外面看它问了什么、让它继续、或者临时改变方向。

重点是：本地环境还留在原处，你不需要把整个工作流搬到手机上。

6. 用 Automations 让 thread 自己醒来

Automations 可以按计划运行 Codex 工作。

这里要分两类：

• scheduled automation：适合从某个 workspace 定期启动的新任务，比如日报、仓库检查
• thread automation：适合回到同一条 thread，带着上下文继续做事

Thread automation 可以理解成“心跳式唤醒”：它会按计划回到同一条 Codex thread。

Pinned threads 解决的是“我能快速回来”。Thread automations 解决的是“我不回来，它也会定期醒来看看”。

举个例子，一个 Chief of Staff thread 可以每 30 分钟运行一次：

每 30 分钟检查 Slack 和 Gmail，找出需要我关注但还没回复的消息。
帮我判断优先级。
如果有人问我问题，尽可能深入地查资料并起草回复，但不要发送。

当你回来时，最费时间的上下文收集可能已经完成了。人仍然保留最终决定权，只是不用把前期脏活都自己做一遍。

Thread automations 也适合各种反馈循环。它可以定期查看 PR 评论、Google Docs 评论或 Slack 回复，并在你离开时继续推动周边工作。

比如一个动画工作流：reviewer 在 Slack 里发来视频反馈。Thread automation 可以定期检查这条 thread，有新评论时重新渲染版本，并在同一个 Slack thread 里 tag reviewer。如果某个集成不能完成最后上传，还可以用桌面自动化通过 GUI 补上最后一步。

这时，工作流横跨了 Slack、代码仓库和桌面应用，但对用户来说，它仍然是同一个可持续推进的 thread。

7. 用 Goals 给长期任务一个真正的终点

Goals 适合那些有明确完成条件、需要 agent 持续推进的任务。

一个比较弱的 goal 是：

实现这个 Markdown 文件里的计划。

问题是，它没有清晰的验收标准。什么叫完成？做到哪一步算结束？

更强的 goal 会有可验证的成功条件。

比如，一个工程师要把内部工具从 Python 迁移到 Rust。可以先建好新目录，然后把 goal 写清楚：新的实现不算完成，直到单元测试全部通过。

一个好的 goal 通常包含三样东西：

• 目标结果
• 停止条件
• 一个能判断是否变好的验证信号

常见的 verifier 包括：

• 测试套件
• benchmark
• bug 复现用例
• validation matrix
• 必须持续通过的端到端工作流

野心当然重要，但没有验证，野心就很容易变成愿望清单。

8. 善用 side panel，把产物留在对话旁边

Side panel 的价值在于：产物就在生成它的对话旁边。

你不需要把文件导出去、切到另一个软件、再回来描述哪里不对。代码、PDF、deck、网页、表格、文档，都可以留在同一个工作循环里审阅和修改。

它特别适合做四件事：

1. 检查产物
2. 标注需要修改的地方
3. 操作网页界面
4. 审阅变更

Side panel 可以直接审阅 Markdown、spreadsheet、数据表、文档和 slides。你可以在旁边看、标、改，而不是把反馈拆成一个单独的交接流程。

Deck 或 PDF 可以一直留在生成它的 thread 旁边，随时等待审阅和修补。

In-app browser 让 Codex 可以检查渲染后的页面、控制页面，并直接响应你在页面上的标注。评论不会变成另一个孤立的待办，而是留在当前工作循环里。

网页会同时变成输出对象和控制界面：Codex 可以构建一个 artifact，打开它，检查它，调试它，然后继续在同一个对象上迭代。

这些 surface 特别适合放进 side panel：

• index.html：轻量静态产物
• Storybook：UI 审阅
• Remotion Studio：程序化动画
• 浏览器版 slide deck：演示文稿
• 数据应用：分析工作流

一个单独的 index.html，就可以变成一个不需要服务器的持久交互式 artifact。Thread automations 还可以定期刷新静态 artifact，让你回到 thread 时，已经有新东西等着看。

9. 把共享记忆写到 thread 之外

长期 thread 会积累大量上下文，但真正可靠的记忆，不应该只活在对话记录里。

Shared memory 指的是：把持久上下文存到单个 thread 之外，让未来的工作能从一个明确、可审阅的地方继续。

一个很耐用的模式，是把 persistent threads 锚定在 Obsidian vault 里。说白了，就是一个普通文件夹，里面是纯文本文件。它容易查看、编辑、迁移和长期保存，也可以放在 cloud storage、Git、Dropbox、Google Drive 或任何适合团队的同步层里。

一个 vault 可能长这样：

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

顶层的 AGENTS.md 可以告诉 Codex：当它学到关于人、项目、决策和开放问题的新信息时，应该如何更新这个 workspace。

注意，不要照抄某个固定结构。更重要的是教会 agent：

• 哪些上下文应该长期保存
• 什么应该写进 canonical notes，而不是制造一堆零散笔记
• TODO、people、projects、daily summaries 和 scratch notes 分别放哪里
• 决策、阻塞、owner、日期和有用链接要保留下来
• 如果没有真正有意义的新信息，就不要制造文件 churn

仓库保存代码。Vault 保存滚动上下文：谁参与了、发生了什么、卡在哪里、下一步是什么、哪些信息不应该随着对话结束而消失。

Codex 也有第一方的 memory features，位置在 Settings > Personalization > Memories。它更像一个本地回忆层，适合保存偏好、重复工作流和常见坑。它可以补充显式的 written context，但不应该完全替代后者。

Chronicle 也在朝同一个方向走：帮助 Codex 从最近的屏幕上下文里构建记忆。

10. 最后的心法：Codex 从代码开始，但不必停在代码里

Codex 仍然从代码场景出发，这是它最稳定、最自然的起点。

但围绕代码的很多工作，现在也可以被同一个系统触达：MCP servers、browser surfaces、desktop controls、thread automations、reviewable artifacts。

这会改变我们控制工作的方式：

• Steering：打断正在进行的工作，及时修正方向
• Queuing：把下一步排进队列
• Thread automations：你离开时，thread 仍然会醒来继续检查
• Goals：给长期任务一个明确终点，让 Codex 持续朝它推进

所以，更准确的理解是：Codex 不只是“帮你写代码”。它可以把一条工作流从指令、执行、产物生成，到审阅和迭代串起来。即使工作已经离开代码仓库，也仍然可以留在同一个系统里完成。

如果你想真正把 Codex 用起来，不妨从一个长期 thread 开始：选一个重复出现、上下文复杂、需要跨工具协作的任务，把它 pin 起来，给它工具、给它记忆、给它自动化，再慢慢把你反复做的动作沉淀成 skill。

这时，Codex 才开始从“一个会写代码的聊天窗口”，变成你的工作操作系统。