Codex 会话控制斜杠命令(/new、/undo、/resume 等)

随着使用深入，你会积累越来越多的会话。学会用斜杠命令管理会话生命周期，是从"随便用用"走向"掌控全局"的分水岭。本课拆解四个核心命令。

TL;DR 速查卡

• /new：想开个全新任务、不被旧上下文干扰时用。
• /undo：Codex 改错了、想回退最近一步时用。
• /resume：中断或跨天后想接着上次进度时用。
• /fork：想在不影响主线的前提下安全试错时用。

一、/new：新建会话

当你想开始一个全新的、不被历史上下文干扰的任务时：

/new

新建会话会清空当前上下文，从一张白纸开始。好处是避免旧对话的干扰、节省 token；代价是丢失已有的分析。所以，切换大型任务时用它，比在一个冗长会话里硬塞新需求要干净得多。

二、/undo：撤销上一步

Codex 改了文件、你发现不对，想回退：

/undo

它用于撤销最近的一步操作。这是你敢于让 Codex "放手去做"的安全网之一——知道能撤销，才敢放开权限。

三、/resume：恢复对话

中断了、下班了、或者想继续昨天没做完的事：

/resume

恢复之前的会话，让进度不丢失。对于跨天、跨时段的长期任务尤其重要。

四、/fork：分叉线程

想基于当前进度"开一个分支"去尝试另一种方案，又不想破坏主线：

/fork

分叉会复制当前上下文，让你在副本里自由试错。试对了再合并回主线思路，试错了直接丢弃，主对话不受影响。这是探索多种可能性时非常实用的技巧。

实战：用 /fork 安全重构一个函数

假设你要重构项目里的 parseUserList() 函数，它现在又长又难维护。你不确定哪种改法更好，主分支又必须保持可用：

1. 先执行 /fork，复制当前上下文，进入工作分支。
2. 在分支里让 Codex 用**方案 A（提取辅助函数）**重构，跑完测试发现边界逻辑反而更绕，果断放弃。
3. 执行 /undo 回退这次改动，分支回到干净状态。
4. 再让 Codex 用**方案 B（改用流式处理）**重写，这次测试通过、代码也更清晰。
5. 把方案 B 的关键改动合并回主线思路，主线从未被失败尝试污染。

整个过程主线始终稳定，失败的方案 A 只留在分支里，这就是 /fork + /undo 组合的价值。

从上图可以看到：整个循环的起点是 /new，把任务门收拾干净；中途遇到不确定方案先 /fork 分叉，错了用 /undo 及时回退，被打断则用 /resume 接续进度。四个命令串成闭环后，Codex 就从“一次对话”升级为“可持续推进的项目工作流”。

常见问题排查

Q1：执行/undo提示「无可撤销操作」怎么办？

出现这个提示，通常意味着当前会话里已经没有可回退的步骤了。按下面两步排查：

1. 确认是否刚执行过 /new：/new 会清空上下文，之前的操作记录一并被丢弃，此时 /undo 自然无操作可撤。如果改动还没提交，只能靠版本管理（如 git）找回，/undo 帮不上忙。
2. 确认是否已连续撤销到最早一步：/undo 只能逐步回退，撤到最早一次改动后再执行就会提示无可撤销。此时若还想回到更早状态，应改用 /resume 打开历史会话，而不是继续按 /undo。

小技巧：养成「重要改动先 /fork」的习惯，即使 /undo 失效，也能从分支副本里找回，不必依赖撤销栈。

Q2：/fork后忘记合并回主线，如何找回？

分叉只是复制了上下文，主线并不会自动包含分支里的改动。找回分两步：

1. 回到主线会话：执行 /resume 打开主线对应的历史会话，确认当前主线状态。
2. 把分支改动合并回来：如果分支里改的是文件，用 git 对比分支与主线的差异，把需要的改动 cherry-pick 或手动合并到主线；如果只是对话思路，把分支里确认有效的方案要点复制回主线继续执行。

提醒：/fork 的分支不会自动同步回主线，试错成功后记得主动合并，否则分支里的成果会一直「孤立」在副本里。

Q3：/resume找不到历史会话列表，如何定位？

历史会话太多或列表被过滤时，容易找不到目标会话。按下面三步定位：

1. 用关键词缩小范围：在会话列表的搜索框输入任务关键词（如函数名、项目名），快速过滤出相关会话。
2. 按时间排序查找：把列表按「最近使用」或「创建时间」排序，跨天任务通常能在最近几天的记录里找到。
3. 从文件改动反查：如果记得改过哪些文件，用 git log 查看提交记录里的会话标识或备注，再回到 Codex 用对应标识定位会话。

建议：每个长期任务开始时用 /new 单独开一个会话，并让 Codex 在首条消息里写明任务名，这样 /resume 时一眼就能认出该续哪个。

/undo 并非万能。它只能撤销会话内、文件系统层面的最近一步操作，遇到下面两类情况就会失效：

• 已执行 /new：新建会话会清空上下文，之前的操作记录一并被丢弃，/undo 无从回退。
• 操作涉及外部系统：比如已推送远程仓库、已部署到服务器、已发送消息或调用外部 API。这些副作用发生在 Codex 工作区之外，/undo 管不到。

应对策略很简单：把不可撤销的操作挡在分支里。凡是可能产生外部副作用的改动，先 /fork 再执行，确认无误后才合并回主线。下面用一个例子说明：

# 主线：直接推送有风险
git push origin main          # 若代码有问题，/undo 无法撤回远程提交

# 安全做法：先 /fork 建立安全网
# 1. 执行 /fork，进入工作分支
# 2. 在分支里修改并本地验证
git commit -am "refactor: 重构 parseUserList"
git push origin feature/refactor   # 即使推错，也只影响分支，不影响主线
# 3. 确认无误后，再合并回主线

下面用一个更具体的场景说明「已推送远程仓库后 /undo 失效」：假设你在主线直接改了代码并推送到远程，随后发现改动有问题：

# 主线：直接修改并推送
git add src/parser.py
git commit -m "refactor: 重写 parse_user_list"
git push origin main          # 已推送到远程

# 发现问题后执行 /undo
/undo                         # 只能回退本地文件改动，无法撤回远程提交

此时 /undo 只能撤销本地工作区的最近一步，远程仓库里的提交已经不在 Codex 的撤销范围内。补救方式有两种：

# 方式一：本地回退后强制推送（仅限个人分支或可接受强推的仓库）
git revert HEAD              # 生成一个反向提交，保留历史，推荐
git push origin main

# 方式二：若已确认要彻底丢弃该提交
git reset --hard HEAD~1
git push --force origin main # 慎用：会改写远程历史，多人协作时可能影响他人

补救的关键在于：推送前先 /fork。把改动放进分支里验证通过后再合并推送，即使推错也只影响分支，主线始终保留一个可回退的干净状态。

下面用一段更贴近日常的 Python 流程，演示「在 /fork 分支内改文件 → 本地验证 → 合并回主线」的完整闭环：

# 假设主线代码位于 src/parser.py，当前内容如下：
#   def parse_user_list(raw):
#       # 又长又难维护的实现
#       ...

# ========== 第 1 步：执行 /fork，进入工作分支 ==========
# 此时 Codex 复制了当前上下文，主线文件保持原样，可以放心改动。

# ========== 第 2 步：在分支内修改文件 ==========
# 让 Codex 用方案 B（流式处理）重写 parse_user_list
new_impl = '''
def parse_user_list(raw):
    """流式解析用户列表，逐行产出，避免一次性加载大文件。"""
    for line in raw.splitlines():
        if not line.strip():
            continue
        name, _, age = line.partition(",")
        yield {"name": name.strip(), "age": int(age.strip())}
'''

# 把新实现写入 src/parser.py（在 /fork 分支内，不影响主线）
with open("src/parser.py", "w", encoding="utf-8") as f:
    f.write(new_impl)

# ========== 第 3 步：本地验证 ==========
# 跑单元测试，确认重构没有破坏原有行为
import subprocess
result = subprocess.run(
    ["pytest", "tests/test_parser.py"],
    capture_output=True,
    text=True,
)
assert result.returncode == 0, "测试未通过，先不要合并！"
print("本地测试通过，可以安全合并回主线。")

# ========== 第 4 步：确认无误后合并回主线 ==========
# 在 /fork 分支里验证通过后，再把改动合并回主线
# git add src/parser.py
# git commit -m "refactor: 用流式处理重写 parse_user_list"
# git checkout main
# git merge feature/refactor
# git push origin main   # 此时推送的是已验证的代码，风险大大降低

这段流程的关键在于：所有修改和验证都发生在 /fork 分支内。即使第 3 步测试失败，也只需执行 /undo 回退分支里的改动，主线始终是干净的；只有验证通过后，才把改动合并回主线并推送。

把「会产生外部副作用的操作」全部放进 /fork 分支里执行，主线就始终保留一个可回退的干净状态——这才是真正意义上的安全网。

五、命令组合的常见用法

一个典型的工作流可能是这样的：

1. 用 /new 开启单个清晰的任务；
2. 途中不确定时用 /fork 试方案；
3. 发现改错用 /undo 回退；
4. 忙到一半用 /resume 下次继续。

把四个命令串起来，你的 Codex 使用就会从"一次性对话"升级为"可持续的项目协作"。

小结

• /new：新建会话，清空上下文。
• /undo：撤销最近一步操作。
• /resume：恢复之前的会话。
• /fork：分叉线程，安全试错。

到此这篇关于Codex 会话控制斜杠命令(/new、/undo、/resume 等)的文章就介绍到这了,更多相关Codex 会话控制斜杠命令内容请搜索脚本之家以前的文章或继续浏览下面的相关文章，希望大家以后多多支持脚本之家！

最新评论