ChatGPT 与 Codex：对话上下文（Context）的导出、转移和引用

一个项目与 AI 讨论久了，对话里会积累大量有价值的信息：最初的需求、反复调整的技术方案、已经确认的参数、失败过的尝试，以及接下来要做什么。

这些信息可能散落在几个对话中。重新开一个对话，往往又要解释一遍；继续留在旧对话里，又担心内容越来越长，重要结论被淹没。

于是，一个实际问题出现了：已经积累的上下文，能否保存下来、带到另一个对话，甚至把多个对话的成果组合起来使用？

可以。实际操作中，需要区分导出、接续、分支、引用和压缩。它们解决的问题各不相同。

本文以 Codex 已公开的功能为主要操作示例。普通 ChatGPT、桌面端、IDE 插件和命令行版的功能并不完全相同，文中的命令不能直接照搬到所有聊天窗口。整理交接文档、明确资料来源等方法，则适用于更广泛的 AI 对话场景。

一、先分清：聊天记录、当前上下文和项目文件

“Context”通常译为“上下文”，指 AI 在当前工作中可以利用的信息，例如先前消息、任务指令、读到的文件和工具返回结果。

“上下文窗口”则表示模型一次能够处理的信息容量。

理解后续操作，可以先区分三个对象：

对象	含义	回答的问题
聊天记录	保存在会话中的讨论过程	我们曾经说过什么？
当前上下文	模型这次实际用来理解问题的信息	它此刻依据什么工作？
项目文件	代码、文档、数据和配置等实际材料	工作对象现在是什么状态？

三者有关联，但不能互相替代。聊天记录仍然存在，不代表其中每一句话都始终完整放在当前上下文中；长对话经过压缩后，早期内容可能主要通过摘要继续发挥作用。

同样，恢复一个讨论代码的会话，也需要核对当前工作目录里的代码。昨天讨论的版本，与今天磁盘上的版本可能已经不同。

因此，谈“迁移上下文”时，最好先明确：要保存讨论过程、继承任务背景，还是连项目资料一起迁移。

二、导出：把对话保存为可检查的资料

如果目的是备份、留档，或者交给另一个对话阅读，Codex CLI 可以导出会话。

在 Codex CLI 的对话输入框中输入：

/export session.md

即可将完整会话导出为 Markdown 文件。只输入 /export，则可以选择复制到剪贴板或保存到文件。导出前应等待当前这一轮任务结束。

这里的 Markdown 是一种普通文本格式，可以用文本编辑器打开，也便于搜索和整理。

对于导出的记录，可以保留一份完整存档，再单独提炼出仍然有效的需求、参数、决策和待办事项。这样，新对话既有简明的工作依据，必要时也能回查讨论过程。

需要注意，导出的会话文本并不等同于可恢复全部运行状态的通用快照。 把文件交给另一个对话，属于重新提供背景资料，不能据此保证模型会原样恢复此前所有内部状态。

上述 /export 是已确认的 CLI 功能。桌面端或 IDE 是否有对应入口，应以实际界面为准；也不能把 /import 想当然地当作导入任意会话 Markdown 的恢复命令。

三、接续与分支：继续原任务，或另开一条思路

如果只是关闭 Codex 后回来继续原来的工作，通常不需要导出、导入。

在终端中执行：

codex resume

即可选择已保存的会话继续。已经进入 CLI 时，也可以使用 /resume。

如果想保留原对话，同时另开一个继承其历史的新对话，则可以使用：

/fork

例如，前面已经讨论清楚通信协议、运行环境和性能目标，接下来想分别研究两种实现方案。此时建立分支，就能复用先前讨论的基础。

在 CLI 中，还可以从已保存的会话建立分支：

codex fork

或者分支当前目录最近的一次会话：

codex fork --last

已知会话 ID 时，也可以使用 codex fork <SESSION_ID>。

桌面端与 IDE 的官方说明也列出了本地对话的 /fork。桌面端还可在支持的环境中选择新的 Git worktree，即另一个工作副本。具体选项取决于版本和运行环境。

这里要分清两个选择：对话分支决定从哪段历史继续，工作副本决定代码在哪里修改。 如果两个对话仍操作同一份代码，它们的文件修改仍可能互相影响。

四、引用：把多个旧对话的成果带进当前任务

另一种常见情况是：目标对话已经存在，只希望它参考其他对话中的信息。

在支持聊天引用的 Codex 界面里，可以通过 @ 查找并选择原对话。在支持多选的界面中，还可以连续加入多个对话引用。

操作时，要从候选列表中实际选中对应的对话或任务，确认它已成为引用项。仅手动输入“@某个对话标题”这串文字，不能据此判断已经建立了关联。

例如，一个项目可能有三个历史对话：

需求讨论：记录功能目标、使用场景和限制条件。
方案设计：记录架构、接口、数据格式和技术选择。
调试记录：记录问题现象、尝试过的方法和验证结果。

在新的任务对话中引用这三个来源，就可以要求 Codex 综合它们的内容。但最好进一步说明各个来源负责提供什么信息。

可以这样提问：

请综合我引用的几个对话。需求讨论用于确认目标和限制，方案设计用于梳理架构与接口，调试记录用于确认当前问题和已验证的方法。

请先整理已确认结论、尚未验证的假设、已废弃方案和未完成事项。如果不同对话中的参数或决定存在矛盾，请注明来源及影响，核对后再继续。

这一步很有价值。一个参数可能在最初讨论中设为 100，后来改为 200；一次失败的尝试，也可能只是某个条件下失败，并不意味着那条技术路线永远不可行。

出现得更晚的说法，也不一定就是最终决定。 临时设想、模型建议和用户确认，应当区分。

多个引用让当前任务可以综合更多来源，但不能仅凭界面上的几个引用项，就认定所有对话的全文和内部状态都已无损合并。涉及关键参数时，先让 AI 列出所采用的结论及依据，便于检查是否正确承接。

五、Context 快满了：区分压缩、回顾和分支

如果主要问题是对话太长，可以考虑：

/compact

它会压缩早期上下文，以较精炼的内容保留关键工作信息，为后续任务腾出空间。Codex 也具有自动压缩长对话的机制。

压缩属于信息提炼，不应被当成逐字无损保留。对必须准确保存的参数、测试结果、接口约定，最好同时记录在可检查的文档中。

如果只是想快速回顾当前讨论，CLI 还提供：

/recap

它生成会话摘要，但不承担压缩当前上下文的作用。生成摘要后，也不应默认它已经自动保存成了交接文件。

需要查看当前会话状态和上下文使用情况时，可以使用 /status。

至于 /fork，它主要用于从已有历史分出另一条工作思路。不能期待“开一个新分支”就同时获得空白上下文和完整历史。要降低上下文负担，应考虑压缩，或者把必要信息整理后交给新对话。

六、跨对话交接：一份文档让接手过程更清楚

对于持续数天、数周的工作，值得保留一份结构化交接文档。

在原对话中，可以提出这样的要求：

请把当前任务整理成供另一个对话接手的交接文档，保存为 HANDOFF.md。若当前环境不能写文件，请输出完整文本。

请包含：

1）项目目标、范围和明确限制；

2）已确认的需求与技术决策，以及关键理由；

3）当前工作状态、相关文件路径和版本信息；

4）已完成的工作及验证结果；

5）尚未解决的问题；

6）已尝试但失败的方法、适用条件及失败原因；

7）下一步应执行的具体操作；

8）仍需确认的假设。

请区分已确认事实与推测，保留必要参数、命令和错误信息，并标明已被后续决定取代的内容。

然后在新对话中提供这份文件，并要求：

请先读取 HANDOFF.md，核对当前项目文件和工作状态，再从其中的下一步操作继续。如文档与现状不一致，请先列出差异。

HANDOFF.md 只是一个便于识别的文件名，并非自动生效的内置协议。需要让新对话能够访问它，并明确要求读取。

这套方法也适用于普通 ChatGPT：可以粘贴交接摘要，或在支持文件上传的界面提供文档。关键是把继续工作所必需的信息表达完整。

对于代码项目，还要核对仓库、分支、未提交修改、数据文件和运行条件。会话同步与项目文件访问是两件事；恢复了聊天，并不意味着另一台电脑已经拥有相同版本的代码和资料。

七、长期规则与阶段进度，分别维护

开发项目中，可以把需要长期保持一致的规则放进 AGENTS.md，例如技术栈、目录约定、编码规范和常用构建命令。

Codex 会按作用范围发现并读取适用的 AGENTS.md。普通 ChatGPT 并不会因为你的电脑上存在这个文件，就自动获得其中内容。

阶段性进度则适合放在 HANDOFF.md，例如刚修复的问题、尚未通过的测试、当前阻塞点和下一步任务。

两份文档各自保持精炼：前者说明项目怎样工作，后者说明目前工作到了哪里。需求发生改变时，同时更新对应文档，避免旧结论继续被当作当前要求。

实际使用时，可以按下面的目的选择：

目的	适合的方法
保存讨论记录	使用 CLI 的 `/export`，或保留可读的会话资料
继续原来的任务	恢复已有会话，例如 `codex resume`
沿另一条思路探索	使用 `/fork` 创建继承历史的新对话
综合多个对话的成果	在支持的界面中使用 `@` 引用，并说明各来源的作用
减少长对话的上下文占用	使用 `/compact`
跨工具、跨环境交接	提供结构化交接文档，并核对实际项目文件