很多人用 Codex 的方式还停留在我问一句它答一句。问完关掉下次再开一个新对话把背景再说一遍。这其实非常浪费。不是浪费 Codex 的能力是浪费你自己的时间。OpenAI Codex 团队的 Jason Liu 前几天发了一篇长文标题叫Getting the most out of Codex里面提到的东西不少但真正让我觉得早就该这么做的是两个点。一个关于对话怎么开一个关于记忆怎么存。一、不要每次都开新聊天你回忆一下最近一次让 Codex 帮你干活是不是这样的流程新开一个对话花两三句话解释项目背景描述你要做的事它开始干活你发现它理解得不太对又补了几句上下文终于做出来了你关掉对话明天又来重复第一步问题出在哪你每次都在重新教它认识你的项目。Jason 给这个问题的解法叫durable threads长期线程。核心思路很简单别关一直开着。但这不是让你开一个聊天窗口永远不关。他做的其实是给不同类型的工作各开了一个专属位——用 Codex 的置顶功能Cmd1 到 Cmd9一键切换。比如他自己的配置线程 1万能助理。专门处理杂事——查消息、整理待办、回答简单问题线程 2产品发布。跟进发版流程、检查清单、协调依赖线程 3文档审查。持续审查和迭代文档线程 4外部监控。盯着外部反馈、评论、舆情你看到区别了吗普通聊天是一次性问答。你问这个 bug 怎么修它给你一段代码对话结束。下次你遇到相关问题又得从头解释。长期线程不一样。它是一个持续工作的工位。线程 2 里Codex 记得上次发版改了什么、哪个模块有兼容问题、QA 反馈了哪些 regression。你不用重新交代背景直接说这次版本号升到 3.2把上次的兼容问题也处理一下它就知道你在说什么。线程 4 里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 变强了。是你终于没有在浪费它。