把 Codex 用成工作流：线程、工具和自动化
Codex 不只适合改代码。配合持久线程、工具、自动化和共享记忆，它可以处理更完整的电脑工作流。
很多人第一次使用编程 Agent，入口都是代码：读仓库、改 diff 、跑测试、开 PR 。
Codex 当然仍然适合这类任务。但电脑上的很多工作，本来就已经由代码、命令、网页、 API 、文档导出、事件响应和自动化串起来。把这些入口交给 Codex 后，它就不只是写代码的助手，更像一个可以执行电脑工作的系统。
这篇整理成一份偏实操的用法指南，重点保留几个可直接照着配置的部分：持久线程、语音输入、任务纠偏、工具入口、自动化、 Goals 、侧边栏和共享记忆。
1. 用持久线程承接长期工作
持久线程的价值，是把反复出现的工作流放在同一个上下文里，避免每次重新开聊。
适合固定置顶的线程包括：
- Chief of Staff：每天帮你处理待办、邮件、消息和优先级
- Release：围绕一次版本发布持续跟进
- Docs Review：反复审文档、改结构、查遗漏
- External Monitoring：定期监控外部变化
这类线程更像小型工作区，可以保留之前的决策、偏好和上下文，减少重复说明。
如果你有 1 到 9 个常用线程，可以用快捷键快速切换：
Command-1 到 Command-9
2. 先用语音把粗糙想法丢进去
语音输入适合记录还没整理好的想法。很多任务刚开始时并不完整，但只要线索足够，Agent 就能继续查找和补全。
例如可以直接说：
我记得 Slack 里好像有个叫 Ben 的人提过这件事，我不记得细节了。去帮我找一下。
这类输入不需要先写成完整需求。 Codex 可以搜索、收集上下文，再回来汇报。
会议记录、语音备忘、两三分钟的想法倾倒，也适合作为输入。粗糙文本往往比过度压缩的摘要更有用，因为它保留了不确定性、重点和语气。
3. 区分 Steering 和 Queuing
语音和持续线程结合后，最有用的是两种控制方式：Steering 和 Queuing 。
Steering 是在任务进行中插入新方向。比如 Codex 正在审一个页面，你发现方向不对，可以中途打断：
把这个模块做小一点。
这两个元素之间的间距不对。
这里的文案需要重写。
Queuing 是不打断当前任务，只把下一步排进去：
等这件事完成后，把预览链接发给 Slack 里的 reviewer。
两者的区别很简单：Steering 改变正在做的事，Queuing 安排接下来要做的事。
4. 给 Codex 更多可操作入口
线程有了连续性之后，下一步是让它能操作更多环境。
常见入口可以这样分：
$browser 用于侧边栏里的浏览器，适合检查和标注网页
@chrome 用于需要登录态和 Chrome 上下文的任务
@computer 用于只能通过桌面 GUI 完成的工作
MCP servers 和 connectors 可以继续把 Slack 、 Gmail 、 Calendar 等系统接入工作流。很多任务最早出现在消息、邮件、日历和外部工具里，后面才进入代码仓库。
如果某个流程反复出现，可以把它打包成 skill，让 Codex 下次直接复用，不必重新学习一遍。
5. 用自动化处理周期性检查
自动化适合定期重新唤醒一个工作流。它可以从同一个工作区启动，做日报、仓库检查、评论跟踪或外部监控。
一个 Chief of Staff 线程可以这样设置：
Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention.
Help me prioritize what matters most.
If someone asks me a question, research the answer as much as possible, but do not send anything without my approval.
翻成实际用法就是：每 30 分钟检查 Slack 和 Gmail，找出需要处理的消息，先研究答案，但发送前必须等人确认。
这种模式适合把“收集上下文”的成本提前完成。人回来时，不需要重新翻消息，只需要判断哪些内容可以发出去。
6. 用 Goals 处理有终点的长任务
Goals 适合有明确完成标准的任务。弱目标通常长这样：
Implement the plan in this Markdown file.
更好的写法要加上可验证的终点：
把这个内部工具从 Python 迁移到 Rust。
新实现需要放在指定目录。
完成标准是：现有测试套件通过，并且新的命令行入口和旧版本输出一致。
一个 Goal 至少要写清三件事：
- 要达到什么结果
- 什么时候可以停止
- 用什么信号判断正在接近目标
常见 verifier 包括：
- 测试套件
- benchmark
- bug 复现脚本
- validation matrix
- 必须持续通过的端到端流程
没有验证条件，长任务很容易变成一句愿望。
7. 用侧边栏审产物
侧边栏的作用，是把产物留在产生它的对话旁边。你不需要导出文件、切换窗口，再回头解释哪里有问题。
它适合四类工作：
- 检查产物
- 标注需要修改的位置
- 操作网页界面
- Review 变更
Markdown 、表格、数据表、文档、幻灯片，都可以放在旁边直接看。 deck 或 PDF 可以一直开在生成它的线程旁边，方便继续修。
浏览器页面也能变成控制面板。 Codex 可以打开页面、检查渲染、定位问题、根据标注继续修。
适合放进侧边栏的产物包括：
index.html：轻量静态页面- Storybook：UI review
- Remotion Studio：程序化动画
- 浏览器幻灯片
- 数据分析类 app
一个单独的 index.html，就可以成为可长期维护的交互式产物。配合自动化，它还能被定期刷新。
8. 把共享记忆放进可检查的文件
长线程会积累上下文，但关键内容最好不要只留在对话里。更稳的方式，是把记忆落到普通文件中，例如一个 Obsidian vault 。
一个简单结构可以是：
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/
顶层再放一个 AGENTS.md，说明 Codex 应该如何更新这个工作区：
- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, deadlines, and follow-ups.
- Do not create churn when existing notes can be updated.
仓库保存代码，vault 保存滚动上下文：涉及的人、发生的变化、当前卡点、后续动作，以及下个线程需要接上的信息。
Codex 也有 Settings > Personalization > Memories 里的记忆功能，适合保存偏好、常用流程和已知坑点。文件记忆和产品内记忆可以配合使用。
一套可落地的组合
如果从零开始，可以按这个顺序搭：
- 建一个固定线程，专门处理某类重复工作
- 用语音或长文本输入粗糙需求
- 用 Steering 修正进行中的任务
- 用 Queuing 排入下一步动作
- 接入
$browser、@chrome、@computer或 MCP - 把重复流程沉淀成 skill
- 给周期性任务加自动化
- 给长任务写清 Goal 和 verifier
- 把长期上下文写入 vault 和
AGENTS.md
这样用 Codex，重点会从“让它改一段代码”，扩展到“让它沿着一条可检查、可中断、可续接的工作流往前走”。