Codex 官方分享：如何把 Codex 用到极致

Codex 正在经历一场深刻的定位转变。它不再只是一个帮你写代码的 AI 助手，而是正在进化为一个能够处理完整工作流的 computer-work agent。这意味着它的能力边界正在从「帮我写一段代码」扩展到「帮我把这件电脑上的事做完」。理解这一转变，是用好 Codex 的前提。

耐久线程：让 AI 记住你的工作上下文

Codex 的工作半径可以理解为四层扩张。第一层是写代码，这是它的核心能力，读仓库、改文件、跑测试、开 PR，这些基础能力依然强大。第二层是操作电脑，执行 shell 命令、处理文件系统、调用 API，开始进入真实环境。第三层是串联工具，浏览器、文档、表格、幻灯片、消息、日历、邮件，都可以变成 Codex 能触达的工作表面。第四层是持续推进，它不只是回答一次，而是能在一个线程里保留上下文，定时回来检查反馈，继续往目标走。

语音输入与 Steering/Queuing：人在回路中的艺术

原文第一个关键概念是 durable threads（耐久线程）。这不只是聊天记录变长了，而是这个线程可以长期保留工作上下文。你可以把它理解为一个持久化的工作空间：Chief of Staff 线程负责统筹协调，发布线程负责版本发布，文档审查线程负责内容审核，外部监控线程负责持续跟踪。这些线程不是临时聊天，而是真正的工作入口。 很多人使用 AI 的效率低，不是因为模型不够聪明，而是每次都在重建上下文。今天解释一遍项目背景，明天再解释一遍偏好，后天又重新说一次什么能改、什么不能改。线程一旦耐久化，Codex 就能带着之前的决策、偏好、文件、任务状态继续工作。下一次回来，不必重新解释一遍。 Command-1 到 Command-9 可以快速跳转到保存好的线程，这个细节背后是一个使用习惯的变化：你不再打开 AI 然后随便问一句，而是开始像切换工作台一样切换不同的长期线程。

Goals 与验证器：让目标可衡量

语音输入的价值经常被低估。它真正厉害的地方不是把打字变快，而是能把一个想法还没压缩成正式文字之前的状态保留下来。比如你可以直接说：「我记得 Slack 里好像有个叫 Ben 的人提过这件事，细节我忘了，你去找一下。」这句话如果让你打字，你可能会觉得太松散不好意思发，但对一个能搜索、能收集上下文、能回来汇报的 Agent 来说，这已经足够了。很多真实任务一开始就是这样开始的，不是一个清清楚楚的需求文档，而是一段含糊的记忆、一个没想完的方向、两三分钟的口述想法。 Steering 和 Queuing 则是把人的控制力往前推了一步。Steering 是中途打断，Agent 正在干活但方向不对，你可以不等它做完直接插入新指令，比如「这里缩小一点」「这两个元素之间太挤」。这不是重新开一个任务，而是在任务进行中修正方向。Queuing 是排队，它不打断当前工作，只是把下一步排上，比如「这件事做完之后，把预览链接发给 Slack 里的审阅人」。 这两个功能的意义在于：Agent 的任务会越来越长，以前 AI 回答十几秒，现在一个真实任务可能跑几分钟甚至更久。如果你只能等它结束再重新纠偏，

共享记忆：让上下文持续沉淀

一条线程有了连续性，下一个问题就是它到底能接触哪些工作表面。Codex 的工具半径分了几层：$browser 适合侧边栏里的浏览器审查，让 Codex 打开网页看渲染效果、检查交互；@chrome 适合需要登录态的浏览器工作，依赖你自己的 Chrome 账号、Cookie、扩展；@computer 适合只能通过桌面 GUI 完成的工作，有些事没有 API 也没有网页，只能打开软件点按钮拖文件。 MCP servers 和 connectors 是下一层，Slack、Gmail、Calendar 这些连接很重要，因为很多任务一开始就不是代码任务，它可能是一条消息、一封邮件、一个会议安排。这些一旦接进来，Codex 就能从「任务出现的地方」开始工作，而不是等你把任务手动复制到聊天框。 Skills 又是另一件事。连接器解决的是能力问题——能不能碰到 Slack、Gmail、Calendar；Skill 解决的是流程问题——遇到某类任务应该怎么做。Prompt 是消耗品，Skill 是资产，一次性 prompt 只能解决这一次，Skill 会把一套被验证过的流程沉淀下来，让 Co

如有侵权，请联系删除。