昨天，OpenAI Codex 团队的 Jason 发了一篇长文，题目叫《Getting the most out of Codex》，完整地分享了自己充分利用Codex的经验，直接教大家如何榨干 Codex！
第一次上手 Codex，大多数人都会把它当成一个更强的编程助手。
让它读仓库、改代码、跑测试、修 bug、开 PR，这些当然是它最顺手的活。但如果 Codex 只被用来写代码，多少有点可惜。
Jason 的文章里提到了很多玩法，真正的把 Codex 放到了更大的工作流里：从理解需求，到查上下文，再到执行、预览、反馈、继续推进。
下面这套方法，值得每个使用 Coding Agent 的人重读一遍。
一、不要总开新聊天，要养长期线程
很多人用 AI 的方式还停留在：
我问一句，它答一句。我再问一句，它重新理解一遍。
这其实非常浪费。
Codex 更适合的使用方式，是建立 durable threads：长期线程。
你可以把它理解成一个固定的工作台：一个线程专门跟进发版，一个线程专门处理文档，一个线程专门盯产品反馈，也可以有一个类似 Chief of Staff 的线程，帮你整理消息、待办和优先级。
这和普通聊天最大的区别是：普通聊天是一次性问答，长期线程是一个持续工作的办公室。
Codex 可以在这个线程里记住此前的决策、偏好、约束、坑点和上下文。你不用每次都重新解释“我们这个项目怎么跑”“这个人是谁”“上次为什么这么改”。
这也是榨干 Codex 的第一步：
不要把每次任务都当新会话。把重复发生的工作，沉淀成固定线程。
二、别把 prompt 写得太“端着”，语音反而更好用
很多人低估了 Codex 的语音输入价值。
真正的工作里，需求一开始往往不是清晰的。你脑子里可能只有一团模糊信息：
我记得 Slack 里好像 Ben 提过这个问题。具体在哪我忘了。你去找一下，然后帮我看看要不要处理。
这种话如果要打字，你可能先要整理半天。但如果用语音，两三分钟就能把背景、疑问、猜测、情绪、优先级全部说出来。
对 Codex 这样的 agent 来说，这些粗糙信息反而有价值——它们保留了不确定性，也保留了线索。这样，Codex 就可以先去找上下文，再判断相关性，最后把事情整理成一个可执行的下一步。
所以，别总想着给 Codex 写“完美 prompt”。
更高效的方式是：
先把脑子里的粗糙想法倒出来，再让 Codex 去搜索、整理、验证和推进。
三、不要等它做完才批改，要学会中途纠偏
Codex 的一个关键能力，是你可以在任务进行中继续控制它。
这里有两个概念很重要。
1. Steering：打断并纠偏
当 Codex 正在执行任务时，如果你发现它方向不对，不必等它跑完。
你可以直接插一句：“这里方向错了，先别改后端。”“这个按钮太大了，缩小一点。”“这段文案不是这个意思，重写。”“先别提交，先给我看 diff。”
这叫 steering：在任务还没结束时，实时纠偏。
这很像你在带一个初级同事做事：不是等他交付一个完整错误结果，而是在中途不断微调方向。
2. Queuing：把下一个任务排进去
另一种情况是，你不想打断当前任务，但希望它做完之后继续干下一件事。
比如：
当前修改完成后，把预览链接发给 Slack 里的 reviewer。测试通过后，顺便更新一下 changelog。PR 创建后，帮我写一段 reviewer note。
这叫 queuing：不改变现在正在做的事，而是把下一步排上队。
掌握这两种控制方式后，你和 Codex 的关系就从“提问—等待答案”，变成了“边执行、边监督、边追加任务”。
这才是 agent 的正确用法。
四、不要把 Codex 关在代码仓库里
Codex 的核心当然还是代码。但真正的软件工作，很少只发生在仓库里。
需求可能在 Slack，决策可能在邮件，会议安排在 Calendar，反馈写在 Google Docs，界面问题要去浏览器里看，最后交付的东西也不一定是代码，可能是一份 PDF、一页 slide、一个数据表，或者一个可以打开的 demo。
如果 Codex 只能读仓库，它能做的是工程链路中的一段。可一旦它能进入浏览器，能使用你已经登录的 Chrome 上下文，能连接 Slack、Gmail、Calendar，甚至能处理一些桌面 GUI 操作，它能做的就变成了一整条工作链路。
举个例子：reviewer 在 Slack 里提了一个反馈，Codex 可以先读懂那段上下文，找到对应代码，修改实现，重新生成预览，再把结果带回同一个反馈线程里等你确认。
这时候，它已经不是在“写代码”了，而是在帮你推进一件事。
这也是这篇文章里最值得注意的地方：Codex 的边界，不应该停在 repo。浏览器、消息、邮件、文档、日历，都可以成为它工作的入口。
五、让 Codex 在你离开后继续跑
如果 Codex 只有在你发消息时才工作，它还是一个被动工具。
更进一步的用法，是给长期线程加上自动化，让它定时醒来看看有没有新情况。
比如你可以设置一个“Chief of Staff”线程，每 30 分钟自动运行一次：
检查 Slack 和 Gmail 里有没有需要我回复的消息。帮我判断优先级。如果有人问我问题，先深入研究，起草回复，但不要发送。
同样的方式也适合 PR 评论、文档反馈、客户邮件、测试结果、日报周报这类事情。它们不一定都需要你立刻处理，但很耗注意力，也很适合让 Codex 先帮你盯着。
自动化的价值，不是让 AI 替你拍板，而是让它在你不在的时候，把信息收集、初步整理、重复检查这些耗时间的部分先做掉。
六、给它一个能验收的目标
很多人给 Codex 派任务，会说：
按这个 Markdown 文件里的计划实现一下。
这句话能用，但不够好。因为它只说了要做什么，没有说做到什么程度算结束。
更好的说法是：
把这个内部工具从 Python 迁移到 Rust。所有单元测试通过，并且现有命令行行为保持一致，才算完成。
后面这半句很关键。它给了 Codex 一个明确的验收标准。
Codex 越清楚“完成”的定义，就越能自己往前推进。测试是否通过，benchmark 是否达标，bug 是否能复现并修掉，端到端流程是否还能跑通，这些都可以成为它判断进度的信号。
没有验收标准的任务，很容易变成“差不多做了”。有验收标准的目标，才适合交给 agent 长时间执行。
七、把 side panel 当成工作台，而不是展示区
Codex 的 side panel 很容易被低估。
它不只是用来展示结果的地方，更像是一个工作台。代码、文档、表格、PDF、slide、网页、数据看板，甚至一个临时生成的 index.html，都可以放在这里看。
这件事的意义在于，它把生成、预览、审查、修改放到了同一个循环里。
以前做这些事，你可能要在聊天窗口、IDE、浏览器、文档工具之间来回切。现在可以让 Codex 先生成一个 artifact，打开给你看；你指出哪里不对，它再继续改。
对于前端页面、文档、数据分析、演示材料这类需要反复看效果的工作，这个模式会省很多来回切换的时间。
八、给 Codex 留一个外部记忆库
长期线程有用，但重要上下文最好不要只放在聊天记录里。
更稳的方式，是给 Codex 准备一个外部记忆库。它可以是 Obsidian，也可以只是一个普通文件夹，用来存 TODO、项目笔记、人物信息、决策记录、阻塞事项和关键链接。
vault/├── TODO.md├── people/├── projects/├── agent/└── notes/
仓库保存代码，记忆库保存项目的滚动上下文。
真正容易丢的，往往不是代码，而是这些信息：为什么当时这么决策，谁负责哪个模块，上次卡在哪里，哪些人还没回复，哪些坑下次不要再踩。
如果这些内容只留在某个对话里，下一个线程很难接上。如果它们被写进文件里，能被审查、编辑、同步，Codex 以后就能继续使用。
时间长了，它就不只是一个聪明的临时助手，而会慢慢变成一个熟悉你项目和工作习惯的系统。
结语：别只问它会不会写代码
这篇文章给我的最大启发，不是 Codex 又多了几个功能，而是我们应该换一种方式看它。
如果你只让它写函数、修 bug、补测试，它当然只是一个 coding assistant。
但如果你让它进入长期线程，连接真实工具，读消息、查资料、理解仓库、修改代码、跑测试、生成预览、收集反馈、定时跟进、保存上下文，它就开始接近一个工作代理。
榨干 Codex 的关键，是你有没有把它放进自己的工作流里。
最后用一句话概括：
Codex 的上限，不取决于它会不会写代码，而取决于你有没有把它当成一个可以持续工作的系统来设计。
