用 Codex 写代码的人大概都经历过这种尴尬你让它规划一个任务它在 Plan 模式里把方案列得井井有条然后……停在那里等你。你看着那份计划心想“行那就开始吧”于是敲下一句“开始实施”。结果它回你一句“我还在 Plan 模式请先切换到执行模式。”你就得去按ShiftTab切模式再重新发一遍“开始实施”。如果中途忘了切它可能又把你刚才的指令当成新的规划需求重新给你列一遍计划。一来一回原本一句话的事变成了三四个来回。更烦的是长会话里上下文堆了一大堆你切模式的时候还可能切错然后又要重新解释一遍“我到底想干什么”。Codex 的 Plan 模式很聪明但它和 Execute 模式之间的那道门得你自己去推。现在这道门终于被改成了自动门。Codex TUI 在 Plan 模式下完成规划后会主动弹出一个提示框问你Yes, implement this plan直接切到 Execute 模式并自动提交“实施这个计划”的指令。Yes, clear context and implement清空当前上下文在新会话里实施适合长会话后上下文已经“脏了”的情况。No, stay in Plan mode继续规划不实施。选第一个Codex 会通过SubmitUserMessageWithMode事件把“实施指令”和“模式切换”原子性地一起发出去。你不需要先切模式再发消息一步到位。这个设计里有一个很聪明的细节切换和指令是原子的。也就是说如果切换失败指令也不会被发出。不会出现“模式没切成功但指令已经发出去了”这种半吊子状态。另一个细节是“清除上下文再实施”这个选项。它解决的是另一个真实痛点你在一个很长的会话里规划了半天上下文里塞满了讨论、试错、废弃方案。如果直接在这个上下文里实施模型可能会被前面的噪音干扰。清空上下文从干净的状态开始执行反而更稳。这个改动的本质是把“确认实施”和“切换模式”这两个原本分离的操作合并成了一个连续的、有明确语义的交互它没有增加新功能只是让原本就存在的流程少了一步“手动推门”。但用过的人会知道这少掉的一步恰恰是每天要重复几十次的那一步。
用 Codex 写代码的人大概都经历过这种尴尬你让它规划一个任务它在 Plan 模式里把方案列得井井有条然后……停在那里等你。你看着那份计划心想“行那就开始吧”于是敲下一句“开始实施”。结果它回你一句“我还在 Plan 模式请先切换到执行模式。”你就得去按ShiftTab切模式再重新发一遍“开始实施”。如果中途忘了切它可能又把你刚才的指令当成新的规划需求重新给你列一遍计划。一来一回原本一句话的事变成了三四个来回。更烦的是长会话里上下文堆了一大堆你切模式的时候还可能切错然后又要重新解释一遍“我到底想干什么”。Codex 的 Plan 模式很聪明但它和 Execute 模式之间的那道门得你自己去推。现在这道门终于被改成了自动门。Codex TUI 在 Plan 模式下完成规划后会主动弹出一个提示框问你Yes, implement this plan直接切到 Execute 模式并自动提交“实施这个计划”的指令。Yes, clear context and implement清空当前上下文在新会话里实施适合长会话后上下文已经“脏了”的情况。No, stay in Plan mode继续规划不实施。选第一个Codex 会通过SubmitUserMessageWithMode事件把“实施指令”和“模式切换”原子性地一起发出去。你不需要先切模式再发消息一步到位。这个设计里有一个很聪明的细节切换和指令是原子的。也就是说如果切换失败指令也不会被发出。不会出现“模式没切成功但指令已经发出去了”这种半吊子状态。另一个细节是“清除上下文再实施”这个选项。它解决的是另一个真实痛点你在一个很长的会话里规划了半天上下文里塞满了讨论、试错、废弃方案。如果直接在这个上下文里实施模型可能会被前面的噪音干扰。清空上下文从干净的状态开始执行反而更稳。这个改动的本质是把“确认实施”和“切换模式”这两个原本分离的操作合并成了一个连续的、有明确语义的交互它没有增加新功能只是让原本就存在的流程少了一步“手动推门”。但用过的人会知道这少掉的一步恰恰是每天要重复几十次的那一步。
