企业官网建设流程全解析

很多人用 Codex 的方式还停留在：我问一句，它答一句。问完关掉，下次再开一个新对话，把背景再说一遍。

这其实非常浪费。

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

OpenAI Codex 团队的 Jason Liu 前几天发了一篇长文，标题叫Getting the most out of Codex，里面提到的东西不少，但真正让我觉得"早就该这么做"的，是两个点。一个关于对话怎么开，一个关于记忆怎么存。

一、不要每次都开新聊天

你回忆一下，最近一次让 Codex 帮你干活，是不是这样的流程：

1. 新开一个对话
2. 花两三句话解释项目背景
3. 描述你要做的事
4. 它开始干活
5. 你发现它理解得不太对，又补了几句上下文
6. 终于做出来了，你关掉对话
7. 明天又来，重复第一步

问题出在哪？

你每次都在重新教它认识你的项目。

Jason 给这个问题的解法叫"durable threads"，长期线程。核心思路很简单：别关，一直开着。

但这不是让你开一个聊天窗口永远不关。他做的其实是给不同类型的工作各开了一个"专属位"——用 Codex 的置顶功能，Cmd+1 到 Cmd+9，一键切换。

比如他自己的配置：

• 线程 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 变强了。是你终于没有在浪费它。