AI工作流 - codex会话保持

AI工作流

AI工作流 - codex会话保持

Codex CLI 继续会话，不要靠重新复制聊天记录。本文整理 codex resume、/resume、--last、--all 和 fork 的区别，以及在长任务里如何减少重复说明、保留上下文。

为什么需要“继续会话”能力

用 Codex CLI 做真实项目，最烦的一件事是：昨天已经讲清楚需求、读过文件、跑过检查，今天打开终端又要重新交代一遍。如果只是复制上一段聊天记录，既浪费时间，也容易漏掉关键上下文。

继续会话的核心价值，是保留已有任务脉络。比如 Codex 已经知道：

  • 这个仓库的发布脚本、测试命令、AGENTS.md 规则
  • 你刚刚做过哪些改动、哪些命令失败过
  • 之前已经定位到的文件位置和错误线索

恢复会话后，它能基于之前的记录继续工作，而不是从零开始重新训练。

这和重新开一个新会话不同：

方式 优点 适合场景
新会话 干净、无历史包袱 全新任务、上下文已过期
继续会话 连贯、节省说明 还没完成的任务、刚中断的排查、需要追踪上下文的长流程

如果刚开始用 Codex CLI，可以先看 Codex CLI 安装和登录教程；如果已经在本地项目里跑过任务，再回来学习 resume 会更容易理解它的价值。

三种常见的恢复方式

方式一：终端运行 codex resume

这是最直接的恢复入口。它会让你从历史会话列表里选择一个，适合你不确定要恢复哪一个任务时使用。

方式二：codex resume --last

如果你就是想继续当前工作目录下最近一次会话，这个命令更快。

注意，官方文档说明 --last 默认按当前工作目录选择最近会话，不是全局随便找一个最近会话。这种设计是合理的——不同项目的上下文混在一起，很容易让 Codex 读错文件、跑错命令。

方式三：CLI 交互中输入 /resume

如果你已经进入 Codex CLI，可以直接用斜杠命令打开保存会话选择器。它适合你已经在对话里，但发现需要切回之前某个会话。

1
2
3
4
5
6
7
8
# 选择一个历史会话
codex resume

# 继续当前目录最近一次会话
codex resume --last

# 跨目录查找最近会话
codex resume --last --all

对长期项目来说，最好固定从项目根目录打开 Codex。这样 resume、权限、AGENTS.md、脚本路径和 Git 状态都更一致。

--last 和 --all 不要混用

很多人误以为 codex resume --last 会恢复“全电脑最近一次 Codex 会话”。更稳的理解是：默认从当前工作目录相关的会话里找最近一次。

如果你确实要跨目录选择最近会话，可以加 --all。但不建议新手频繁这样做，除非你很清楚要恢复的会话来自哪个项目。

跨目录混用 resume 是高风险操作：Codex 拿到的是 A 项目的命令历史，但当前目录是 B 项目，很容易出现“看似在继续，其实上下文错位”的情况。

什么时候用 SESSION_ID？

如果你已经知道某个会话 ID，可以直接指定：

1
codex resume 00000000-0000-0000-0000-000000000000

这种方式适合：

  • 自动化记录：脚本里写入 ID，方便复盘
  • 团队交接：把会话 ID 写进交接文档
  • 日志追溯：发布系统里保存明确会话 ID

普通个人用户不一定每天都要记 ID，但做重要任务时，把会话 ID 写进交接记录会很有用。

举例：你用 Codex 维护 WordPress 站点，一次任务可能包括选题、写稿、生成图片、发布、检查。如果中间被打断，记录会话 ID 能让下一次继续时更准确。

恢复会话后第一句话怎么写？

不要一恢复就说“继续”。更好的做法是给 Codex 一个很短的状态校准，让它知道你要从哪里继续：

1
请先总结当前会话已经完成的步骤、未完成事项和下一步风险，然后继续执行发布后检查。

或者：

1
先读取当前 git 状态和最近一次工具输出，不要立刻改文件。确认上下文后再继续修复测试失败。

这类提示能减少“看似恢复了，但其实漏看最新文件状态”的问题。AI 编程不是只靠聊天历史，当前仓库状态同样重要。

resume 和 fork 有什么区别？

命令 含义 类比 Git
resume 继续原来的会话 继续当前分支
fork 从已有会话分出一个新会话 从当前进度开新分支

举例：你让 Codex 修一个前端 bug，原会话已经定位到样式问题。

  • 如果你想继续按原方案修 → 用 resume
  • 如果你想另开一条路线，让它尝试重构组件 → 用 fork

fork 适合“想尝试另一种方案，又不想破坏原来的讨论脉络”的场景。真正做项目时，两者都很有用。

哪些任务最适合继续会话？

长时间排查

比如测试失败、构建失败、依赖冲突、线上页面异常。前面已经试过哪些命令、看过哪些文件，继续会话能保留这些信息。

跨天写作和发布

对内容站来说，Codex 可能已经读过项目发布规范、站内链接和标签配置。第二天继续，比重新解释更省时间。

多轮代码审查

初审、修改、复查、补测试往往不是一次完成。继续会话能让 Codex 记住前一次发现的问题和验证结果。

复杂自动化流程

如果任务涉及 MCP、浏览器检查、截图、表格、WordPress API，恢复上下文能减少重复授权和重复说明。相关权限设计也可以看 Codex CLI 权限设置教程。

什么时候不该继续旧会话？

不是所有任务都适合 resume。出现下面这些情况，开新会话反而更清楚：

  • 旧会话方向已经跑偏
  • 包含过时假设、项目文件已经大变
  • 你要做一个完全不同的新需求
  • 旧会话里堆了太多失败尝试，继续它可能让 Codex 过度受前面思路影响

针对最后一种情况，可以新开会话，只把结论、错误日志和当前目标整理成简短说明，作为新会话的起点。

建议规则：同一任务继续用 resume；不同任务开新会话；想探索替代方案用 fork；想做长期目标管理，可以结合 Codex CLI /goal 工作流。

参考资料