Codex CLI 对话怎么继续？codex resume、/fork 与 /compact 使用指南

先说结论：继续原任务用 resume，真正分叉再用 fork

Codex CLI 会保存本地对话。需要回到之前的同一个任务时，可以运行 codex resume，从当前仓库的近期对话中选择，也可以搜索本地保存的对话；已经在交互界面中时，可使用 /resume。如果要在保留原对话记录的前提下尝试另一条实现路线，再使用 /fork 创建新的对话分支。

当对话只是变长但目标没有改变，不必为了“清理上下文”立刻新开任务。可以使用 /compact 把已有上下文压缩为摘要，也可能由 Codex 自动完成压缩。官方最佳实践强调：一个连贯的工作单元尽量保持在同一对话，只有工作真正分叉时才 fork。

一、什么情况下应该使用 codex resume

适合 resume 的情况包括：昨天的功能还没做完；修复后要继续验证同一问题；需要保留前面已经确认的架构决定；或者终端意外关闭后继续原会话。恢复同一对话可以保留此前的目标、约束和工具输出，减少重新解释项目背景的时间。

恢复后第一件事不是立刻继续修改，而是用 /status 或简短询问确认当前目录、模型、权限和任务阶段，再检查 Git 状态与未提交变更。会话记录能恢复讨论，但磁盘、分支、依赖和外部服务可能已经变化，所以仍需要重新确认环境。

二、怎样恢复最近或更早的 CLI 对话

在项目目录运行 codex resume，可重新打开当前仓库的近期对话，或从本地对话中查找需要继续的记录。选择时不要只看时间，还要核对标题、仓库和任务摘要，避免把相似项目的上下文恢复到错误目录。

如果团队同时维护多个分支，建议在结束一次会话前留下明确交接：完成了什么、剩余什么、当前分支和最后验证命令是什么。下次 resume 后先读交接和 diff，再决定是否继续原路线。这样能降低“会话恢复正确，但代码状态已经不同”的风险。

三、/fork 与新开对话有什么区别

/fork 会在保留原始对话记录的基础上创建新的对话，适合从同一背景出发比较两种方案，例如一个分支采用小改动修复，另一个分支尝试重构。原对话不会因为新分支的讨论被覆盖，后续可以分别评估结果。

但 fork 的是对话上下文，不应把它理解为自动复制一份独立代码仓库。若两条方案会同时修改文件，应配合 Git branch 或 worktree 隔离磁盘状态，并明确每个对话对应哪个工作目录。否则两个会话仍可能面对同一工作树，造成改动互相覆盖。

四、长对话何时使用 /compact

当上下文很长、早期命令输出占据大量空间，但任务目标仍保持一致时，可以使用 /compact 生成压缩摘要。摘要应保留目标、已做决定、关键文件、失败尝试、测试结果和剩余工作，而不是只保留一句“继续修复”。

压缩后建议让 Codex复述当前状态，并抽查关键约束是否仍在，例如禁止修改的目录、兼容版本、部署窗口和验收标准。若发现遗漏，立即补充到当前提示或 AGENTS.md。压缩能提高可用性，但不能代替仓库中的持久化文档和测试。

五、恢复会话后必须重新检查的四项状态

第一是 Git：分支、HEAD、未提交文件和远端更新；第二是运行环境：依赖、环境变量、数据库与服务是否仍可用；第三是权限：当前沙箱、可写目录和网络策略是否改变；第四是任务事实：需求、接口或外部文档是否在暂停期间更新。

对易变化的信息，可以在明确需要时使用搜索能力重新核验，而不要把几天前的结论当作永久事实。涉及付款、权限、生产配置或删除操作时，即使会话里已有授权，也要确认当前目标和精确范围，避免旧上下文造成越界操作。

六、一个可复用的恢复提示模板

恢复后可以这样开始：先不要修改文件，读取当前 Git 状态和最近一次交接，总结已完成、待完成、风险和验证结果；确认当前工作树与会话记录一致后，再继续下一项最小改动。若存在冲突或外部状态变化，先报告再处理。

如果需要 fork，可写清楚分支目标：保留原方案不变，新对话只评估替代实现；使用独立 worktree；完成后给出两种方案的改动范围、测试结果、回退成本和推荐。明确比较标准能防止新分支只是重复原讨论。

七、避免会话越积越乱的习惯

每个连贯任务使用一个对话，任务边界改变时才新开或 fork；每完成一个阶段就记录结果与下一步；重要规则写入 AGENTS.md 或项目文档；代码变更用 Git 保存可恢复检查点；长输出只保留结论和必要证据。

不要把会话记录当作唯一项目记忆。部署步骤、回滚命令、接口契约和验收清单应进入仓库或团队文档。站内更多实践可访问 https://gptupcn.com/codex/ ，但具体命令与可用功能应以当前 Codex CLI 和官方文档为准。

八、三个典型场景应该选哪个命令

场景一：功能做到一半，第二天继续测试同一实现。应使用 codex resume，恢复后核对 Git 和环境。场景二：现有修复能工作，但想并行比较重构方案。应先创建独立 branch 或 worktree，再用 /fork 保留背景并明确新方案边界。场景三：任务没有分叉，只是对话积累了大量日志。应使用 /compact，随后检查摘要是否保留关键约束。

若需求已经从“修复登录错误”变成“重新设计整个权限系统”，这通常不再是同一工作单元。与其在旧对话中继续堆积上下文，不如完成当前交接，创建新对话并只带入经过确认的架构资料。这样能避免早期临时假设影响新设计。

自动化场景还要区分交互式恢复与脚本恢复。可重复的流水线应显式记录输入、仓库修订、验证命令和输出位置，而不是依赖某次人工对话中的隐含状态。会话恢复适合延续推理，版本控制和流水线记录才负责保证结果可复现。

结语

resume、fork 和 compact 分别解决继续、分叉和压缩三个问题。把会话边界与 Git 边界一起管理，恢复后重新检查环境，并用交接记录保存关键状态，才能让长任务既连续又可控。