推荐语

探索Codex如何超越代码生成，成为你的长期工作伙伴，释放AI的真正潜能。

核心内容：
1. 将Codex用作长期工作流，而非一次性问答工具
2. 利用语音和Steering功能处理未成形的想法
3. Codex作为操作浏览器、生成文件的多功能工作空间

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

近日，OpenAI Codex的官方团队成员@jason 在X上分享了一篇文章，详细介绍了Codex的一些使用技巧，教大家如何把Codex的能力发挥到极致，非常值得大家一看。

前几天也写了一篇关于Codex入门使用的一篇文章《2026年了，我强烈推荐你用一用Codex，功能太全面了！附使用指南》，能感受到大家对Codex的热情与关注，前来咨询的很多，那今天这一篇，可以算是进阶了，值得反复阅读。

如果还不够，大家可以进一步去阅读原文：https://x.com/jxnlco/status/2057153744630890620

下面进入正题：

很多人第一次用 Codex，注意力都会放在一件事上：它写代码快不快，改 bug 准不准，能不能替我把项目做出来。

这当然重要。

Codex ，Code，它首先是一个很强的编程工具。

但 Jason Liu 在《Codex-maxxing》里讲的重点，其实不是“AI 写代码更强了”，而是另一件更值得注意的变化：Codex 开始变成一个承载工作的地方。

这句话对初学者很关键。

以前我们用 AI，大部分时候是在聊天框里提问。你问一句，它答一句。你再补一句，它再改一版。这个过程很像临时咨询，聊完就结束。

但 Codex 现在不只是回答问题，它可以保留长期对话流，可以记住项目背景，可以操作浏览器和电脑，可以定时回来检查进展，也可以让你直接查看它生成的文件、网页、表格和幻灯片。

也就是说，工作不再只是发生在一条 prompt 里。

它可以在一个对话流里持续往前走。

01.保存长期对话流：不要每次都让 Codex 重新认识你

Jason 提到，他会给重要工作保留固定对话流。

比如一个对话流处理个人助理事务，一个对话流跟进 OpenAI CLI，一个对话流看开源项目，一个对话流专门监控 Twitter。

这些对话流不是普通聊天，而是长期工作流。它们会积累历史、偏好和过去做过的决定。你下次回来时，不用重新解释一遍“这个项目是什么”、“上次为什么这么改”、“哪些方案已经被否掉”。

这对初学者其实很有启发。

很多人用 Codex 的方式太一次性了。今天开一个新窗口让它改首页，明天又开一个新窗口让它修 bug，后天再开一个新窗口问部署问题。每次都像从零开始带新人入职，效率当然低。

更好的做法是：给每个重要项目留一个固定对话流。

你可以一开始就这样对 Codex 说：

这样做的价值不在于“AI 永远不会忘”，而在于你开始把 Codex 当成一个长期工作空间，而不是一次性问答框。

02.语音和 Steering：把脑子里没整理好的想法也交给它

原文里有一个很细但很真实的点：Jason 觉得语音输入的价值不只是快，而是能把未经整理的真实想法交给 Codex。

这点我很认同。

点击这里开启语音输入：

很多时候，我们脑子里的需求并不是工整的。你可能只记得“Slack 里好像有个人提过这个问题”，或者“这个页面哪里怪怪的，但我一时说不清”。这些话打字会觉得啰嗦，甚至不好意思写出来，但用语音说就很自然。

Codex 有了更多原始上下文，就更容易理解真实意图。

更进一步的是 Steering，也就是在 Codex 执行过程中继续给它方向。比如它正在看一个网页，你可以一边看一边补充：“这个按钮太大了”“这段文案不对”“间距有点怪”“改完以后打开 PR”“等预览部署出来再发给别人看”。

这和传统聊天不同。

传统聊天更像一轮一轮问答，Codex 的工作流更像你在现场指挥一个正在干活的人。它执行工具、查看页面、修改文件，你随时补充判断，它再把这些反馈加入后续动作里。

初学者可以先从一个简单习惯开始：

这会减少很多返工。

03.记忆：有些东西不能只留在聊天记录里

长期对话流有一个问题：对话越长，信息越多，但真正有价值的东西很容易埋在历史消息里。

Jason 的解决办法是把重要记忆写成文件。

他会用类似 Obsidian vault 的方式保存工作上下文，里面有 TODO、people、projects、Agent、notes 等目录。

Codex 学到新的项目状态、任务偏好、开放事项和决策结果后，就把它写进这些文件里。

这个思路很重要。

因为聊天记录不是一个好记忆库。它太长、太散，也不好检查。相比之下，文件可以阅读、修改、diff、复用。Codex 更新了什么，你可以通过 Git diff 看出来。它以为重要的东西，你可以检查它记得对不对。

初学者不一定要一上来搭 Obsidian vault，但可以学这个思路：让重要信息沉淀成文件。

比如你可以让 Codex 维护一个简单的 PROJECT_NOTES.md：

这比让所有上下文都留在聊天里可靠得多。

04.工具与触达范围：浏览器、Chrome、电脑操作不是一回事

原文里还有一段讲得很实用：Codex 能接触的东西变多了，但不同工具适合不同场景。

Jason 的区分大概是这样：

• 本地网页预览适合用 browser，
• 登录态和多标签任务适合用 Chrome，
• 只有图形界面才能完成的事才用 computer。

比如你在调本地项目，就让 Codex 看本地浏览器；你需要它进入已经登录的网站，就用带登录态的浏览器；如果某个任务只能在桌面 App 里点来点去，那才让它操作电脑。

这对初学者很有用，因为很多人会把“AI 能操作电脑”理解成万能能力。

其实不是，真正会用的人，会根据任务选择合适的入口。

如果你让 Codex 改一个网页，最好的结果不是它凭空描述“页面应该更好看”，而是让它打开真实预览，看到你看到的页面，然后基于同一个画面修改。

这样你说“这个区域太挤”、“这一段被截断了”、“按钮不明显”，它知道你指的是什么。

这里还有一个延伸点：插件和 Skills 会让重复工作变得更稳定。Slack、Gmail、Calendar 这类插件负责把工作入口接进来；Skills 则把你反复使用的流程打包起来。

你做过一次有用的流程，就可以把它沉淀成可复用能力，下次不用重新教。

05.Heartbeats：让 Codex 定时回来看看事情有没有进展

原文里最有画面感的部分，是 Heartbeats。

普通对话流的问题是，它一直在等你说话。Heartbeats 则让一个对话流可以定时回来执行任务。

比如每 30 分钟检查 Slack 和 Gmail，有没有需要你回复的重要消息；比如每 15 分钟检查一个 Slack 对话流，看别人有没有给视频反馈；比如等客服上线后，继续跟进退款流程。

这不是简单的定时提醒。

它的关键在于：Codex 可以根据外部反馈继续行动。有人在 Slack 里提了修改意见，它可以重新渲染视频；PR 有了评论，它可以整理反馈；客服终于出现了，它可以接着对话。

对初学者来说，不用一开始就设计复杂自动化。你可以先把 Heartbeats 理解成“让 Codex 帮你盯住那些容易断掉的工作”。

比如：

或者：

再或者：

很多个人项目不是失败在技术难，而是失败在没人持续把线捡起来。Heartbeats 的价值就在这里。

06.Goals：真正强的目标，必须带验收标准

Jason 在原文里讲 Goals 的时候，说了一个特别关键的判断：弱目标是“执行这个 Markdown 里的计划”，强目标必须有真实的成功标准。

他举的例子是把 Python 的 Rich 库迁移到 Rust。

这个任务很大，但它有一个清楚的判断标准：迁移后的版本必须通过原项目的单元测试。测试套件就成了一个“裁判”。没通过，就没完成。

这句话对初学者特别重要：

没有验收标准的野心，只是愿望。

你让 Codex “帮我优化项目”，它很难知道什么叫优化完成。你让它“降低首页加载时间，并用性能数据说明改动前后变化”，它就有了方向。你让它“修复这个 bug，并确保现有测试通过”，它就知道什么算完成。

所以以后给 Codex 任务时，尽量不要只给动作，要给结果判断。

比如不要说：

可以说：

这才是 Codex 能稳定工作的任务格式。

07.侧边栏：Codex 不只是生成文件，还要让你检查文件

原文最后讲到 side panel，也就是 Codex 的侧边栏工作区。Jason 很看重这个地方，因为它不只是预览窗口，而是工作发生的地方。

Markdown、表格、CSV、PDF、幻灯片、网页，都可以在里面查看和评论。

Codex 生成了一个表格，你不是只能看原始文本，而是能像表格一样检查。它生成了 PDF，你可以直接看渲染结果。

它做了一个网页，你可以在侧边栏里打开、点击、标注，然后让它继续修改。

这件事把 Codex 和普通聊天工具拉开了。

普通聊天工具经常停在给你一段内容。

Codex 更进一步，它让你检查那个内容是不是真的能用。尤其是 index.html 这种小型产物，Jason 很喜欢：不需要复杂服务器，直接生成一个可以打开的小应用，就能立刻交互和修改。

对初学者来说，这里有一个很实用的原则：

如果你让 Codex 帮你想一个小工具，不要只要方案，让它做一个 index.html。

如果你让它整理数据，不要只要文字总结，让它做表格。

你让它写演示，不要只要大纲，让它做 slides。可检查的东西越多，幻觉空间越小。

08.初学者真正要学的，是让工作持续往前走

这篇原文最打动我的，不是某一个具体功能，而是它把 Codex 描述成一个“工作可以继续发生的地方”。

这些东西合在一起，才是 Codex 真正值得关注的变化。

所以，如果你是初学者，我不建议你只问“Codex 怎么写代码更快”。这个问题太窄了。更值得问的是：

我能不能把一个项目放进 Codex 里，让它持续理解、持续执行、持续检查、持续留下记录？

如果可以，它就不只是一个代码助手。

它会变成一个让工作不断往前走的空间。

按照惯例，用一张图总结今天的分享：

更多精彩内容，我们下期见。