使用Codex最大的浪费是每次重新认识它

不妨回想一下，你上次使用 Codex 辅助工作的场景，是不是这样的：你提问一句，它回答一句。对话结束后直接关闭，下一次再发起新话题时，又得把项目背景从头到尾重新描述一遍。

这其实是一种极大的浪费。

浪费的不是 Codex 的能力，而是你自己的宝贵时间。

OpenAI Codex 团队的 Jason Liu 前几天分享了一篇长文，标题为 Getting the most out of Codex。文中提到的内容不少，但真正让人感到“早该这样做的”，其实是两个要点：一个是关于如何开启对话，另一个是关于如何留存记忆。

一、告别每次开新对话：用“长期线程”持续工作

你仔细回顾一下，最近一次让 Codex 帮忙的工作流程，是不是像下面这样：

1. 新建一个对话。
2. 花两三句话介绍项目背景。
3. 描述你需要完成的任务。
4. Codex 开始执行。
5. 你发现它理解有偏差，又补充了几句上下文。
6. 终于得到结果，你关闭对话。
7. 第二天又重复第一步。

问题出在哪里？

答案很简单：你每次都在重新教它认识你的项目。

Jason 针对这个问题给出了一个方案，叫做“长期线程”（Long-running Threads）。核心思路非常直接：不要关闭对话，让线程持续存活。

但这并不是让你保持一个聊天窗口永远不关。他真正做的，是为不同类型的工作各自设立一个“专属位”——通过 Codex 的置顶功能，用 Cmd+1 到 Cmd+9 一键切换。

比如他自己的配置：

• 线程 1：万能助理。专门处理杂务——查消息、整理待办、回答简单问题。
• 线程 2：产品发布。跟进发版流程、检查清单、协调依赖。
• 线程 3：文档审查。持续审查和迭代文档。
• 线程 4：外部监控。盯着外部反馈、评论、舆情。

看出区别了吗？

普通聊天是一次性的问答模式。你问“这个 bug 怎么修”，它给出一段代码，对话就终结了。下次遇到相关问题，又得从头解释一遍。

长期线程则完全不同。它相当于一个持续运转的工作工位。

在“产品发布”这个线程里，Codex 记得上次发版改了什么、哪个模块有兼容问题、QA 反馈了哪些回归测试。你不需要重新交代背景，直接说“这次版本号升到 3.2，顺便把上次的兼容问题也处理一下”，它就能准确理解你的意思。

在“外部监控”这个线程里，Codex 记得上周的 reviewer 说 UI 间距不对、产品经理提了两个新需求、前端同事反映某个组件有性能问题。你完全不用复述这些上下文。

这与普通聊天的本质区别在于：你再也不必每次都从零开始解释自己。

Jason 说了一句非常直白的话：

这个“从零开始”四个字，就是你每天无形中消耗掉的时间。

二、然而长期线程也可能丢失上下文

到这里，你可能已经准备尝试这个方法了。但有一个问题，Jason 不仅没有回避，反而专门拿出来讲清楚了：

长期线程本身也并非绝对安全。

对话可能因各种意外而中断：更换设备、清理缓存、平台升级、或者自己不小心关闭。一旦中断，积累了几周甚至几个月的上下文就会瞬间消失。

更常见的情况是：你在某个对话里和 Codex 讨论了一个重要决策——架构选型用了方案 A 而不是方案 B，因为方案 B 在某个特定场景下存在性能问题。这个决策只记录在了当时的聊天记录里。但下次你开启新对话时，这个新对话对此一无所知。

于是，新对话可能再次推荐你使用方案 B。

你只好花时间解释“上次我们讨论过了，不用 B”，但很不巧，你已经记不清当时的具体原因了，只能重新分析一遍。

真正容易丢失的，往往不是代码，而是这些隐性信息：

• 为什么当时选了 A 而不是 B
• 谁负责哪个模块
• 上次卡在哪里，又是怎么绕过去的
• 哪些人还没有回复
• 哪些坑下次一定要避开

代码有 Git 管理，丢了也能找回。但这些上下文如果只存在于聊天记录里，换一个对话就直接蒸发了。

三、给你的 Codex 配备一个外部记忆库

Jason 给出的解决方案是这样的：

在对话之外，单独维护一份持久化的记忆。

具体怎么做？他使用 Obsidian，但本质上任何能存纯文本的文件夹都行。哪怕只是在本地建一个文件夹，里面放几个 Markdown 文件也完全够用。

关键不在于工具，而在于结构。他提供的参考结构如下：

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

表面上看，这只是一个普通的文件夹。但仔细想想，这里面存放的到底是什么？

• TODO.md：待办事项与优先级。
• people/：项目中涉及的人员、角色、联系方式、谁在等谁的反馈。
• projects/：每个项目的进展、关键决策、阻塞点。
• agent/：Codex 自身的工作日志，哪些工作流已验证有效，效果不错。
• notes/：临时笔记、会议要点、灵感碎片。

代码库存的是代码。而这个记忆库，存的则是项目的“滚动上下文”。

什么是滚动上下文？就是指那些一直处于变化中，但每个时刻又都必须了解的信息。今天谁负责什么、哪个模块遇到了阻塞、上周做出了什么决策、哪些反馈尚未处理。这些东西，Git 管不了，文档系统也管不了，但它们对你工作的连续性至关重要。

四、但还有一个关键问题：如何避免混乱

到这里你可能会想：行，那我建个文件夹，让 Codex 帮我往里写内容不就行了？

问题来了。让 Codex 写内容时，它往往会出现两种极端表现：

一种是写得太多。 你让它记录一下今日进展，它直接给你整出一篇 800 字的日报，里面大部分内容其实可有可无。翻两回，你就再也不想看了。

另一种是写得太乱。 文件随意创建，命名随心所欲，今天记在这，明天又记在那。一周之后，连你自己都找不到东西究竟在哪里。

Jason 的解法是在记忆库的根目录放置一个 AGENTS.md 文件。这个文件的作用并非存放信息，而是给 Codex 制定规则。

他给出了一个实际示例，核心思想大致如下：

最后一条，也是最关键的一条。

“如果没有实质性新进展，就不要动文件。”

这解决的是 Codex 的“过度积极”问题。很多时候，你只是让 Codex 查个东西，它却顺手把你的整个笔记体系重新梳理了一遍。初衷也许是好的，但结果往往是你的精心维护的结构被它搞得一团糟。

AGENTS.md 本质上就是一份工作契约——你和 Codex 之间，关于“记忆该如何管理”的约定。写清楚什么该记、什么不该记、记在哪里、什么时候不该改动。以后每个新对话进来，先读取一遍这个文件，就明白了规则。

五、两者结合才是完整的方案

回到开头的话题。

长期线程解决的是对话内的连续性——在同一个线程里，今天和明天无缝衔接，不会断档。

外部记忆库解决的是对话外的连续性——即使对话意外丢失了，关键信息依然完好无损地保存着。

但只有两者结合起来，才能构成一个完整的、可靠的方案。

Jason 举了一个很好的例子。他的“万能助理”线程每隔 30 分钟自动运行一次：检查 Slack 和 Gmail，整理未读消息，排列优先级，草拟回复但不发送。这个线程本身是长期线程，上下文始终连贯。但如果它在运行过程中，同时把重要发现写入了外部记忆库——比如“张三在 Slack 上提了一个新的性能问题，尚未回复”——那么，即便这个线程因为某种原因中断了，下一个线程接手时，依然能从这个记忆库里读到这条关键信息。

对话内的记忆，让你不必重复自己。对话外的记忆，让你无所畏惧于信息丢失。

说实话，这两个点都不是什么复杂的技术概念。既不涉及高深的架构设计，也不需要你学习任何新工具。

但它解决的是 Codex 使用中一个被严重低估的问题：上下文断裂。

你每次新开一个对话都在重新解释项目背景，这并非 Codex 的问题，而是你的使用方式有待优化。你每次做出重要决策都不做记录，下次又从头讨论一遍，这不是记忆力的问题，而是你没有给 Codex 准备一个可靠的外部存储空间。

这两个习惯一旦改变，你用 Codex 的效率将完全不同。

不是 Codex 变强了。而是你终于没有在浪费它的价值。