Codex重复认知浪费：一次掌握永久复用指南

回想一下，你上次借助 Codex 处理任务，流程是不是这样：你抛出一句，它回应一句。对话结束后关闭窗口，下次再重新开启，又把项目背景从零开始复述一遍。

这本质上是一种惊人的浪费。

浪费的并非 Codex 的潜力，而是你宝贵的工作时间。

OpenAI Codex 团队的 Jason Liu 不久前发布了一篇深度文章，标题是 Getting the most out of Codex。文中涵盖了许多要点，但最令人拍案叫绝、堪称“早就该这样做的”的，其实只有两个核心：一个是对话启动的方式，另一个是记忆如何持久化留存。

一、别频繁开启新对话

仔细审视一下，你最近一次让 Codex 协助的工作流，是否如下所示：

1. 新建一个对话窗口。
2. 用两三句话交代项目背景。
3. 描述你要完成的具体任务。
4. Codex 开始执行。
5. 发现理解偏差，再补充几句上下文。
6. 任务完成，关闭对话。
7. 第二天返回，再次重复步骤一。

问题出在哪里？

根本原因：你每次都在从头手把手教它认识你的项目。

Jason 针对这个痛点的解决方案，称为“长期线程”。核心理念直截了当：不要关闭对话，保持持续活跃。

但这并非鼓励你永久保持一个窗口不关闭。他的做法是针对不同工作类型各自分配一个“专属工位”——利用 Codex 的置顶功能，通过 Cmd+1 到 Cmd+9 快捷键快速切换。

例如他本人的配置：

• 线程 1：全能助手。处理日常琐碎——检阅消息、整理待办、快速回答简单问题。
• 线程 2：产品发布。跟进发布流程、核对检查清单、协调依赖项。
• 线程 3：文档审核。持续审阅与迭代文档内容。
• 线程 4：外部监控。实时跟进用户反馈、评论、舆论信息。

发现差异了吗？

普通对话是一次性问答。你问“这个 bug 怎么修复”，它给出一段代码，对话结束。下次遇到相关问题，仍需从头解释。

长期线程则截然不同。它是一个持续运转的工作台。

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

在“外部监控”线程里，Codex 记得上周 review 指出 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 变强了。而是你终于没有在浪费它的价值。

来源：互联网