预计字数：4000 字 阅读时间：9 分钟 难度等级：⭐⭐（用过 AI 写作/编程工具即可，有 Codex 体验更佳）
核心价值：让读者知道，AI 执行过程中除了等，还有 4 个动作可以主动控制节奏
大家一开始用 Codex 时，模式都很固定。
发一条消息。等它跑完。跑完了再发下一条。
方向不对？那是我的提示词没写清楚。需求漏了？下一条补上。中间发现 Codex 在改我不让它改的东西？等它跑完再说吧，别打断，打断了怕它乱。
后来有一次，我让 Codex 帮我写一篇文章的初稿。写了大概两百字的时候，我发现它的方向偏了------我说的"从碎片到系统"，它理解成了"推荐系统学习路线"，开始列一堆课程链接。
要是在以前，我肯定让它继续。跑完再说，反正跑完了我再改。
但那天我试了一下双击 Esc。
第一次按下去，Codex 的执行速度慢了下来，像是在确认什么。再按一次，它停了。
我问它："刚才写到哪了？"
它告诉我进度。偏掉的部分只有一百多字。好在我叫停得早，没用它跑完三千字再从头改。
那一下我就明白了。跟 AI 打交道，核心技能不是"第一句话写得够完美"，写清楚了它就不会跑偏------这不可能。Codex 再聪明也有理解偏差的时候。真正管用的是跑偏了能及时拉回来。
从那以后，我的用法变了。
我把"等结果"变成了"管过程"。
五个动作，对应"刹车、改工单、现场提醒、待办便签、复制工作台"
如果把 Codex 想象成一个坐在工位上帮你干活的同事，下面这些动作就很好记了：
- 双击 Esc = 刹车
- 编辑上一条 = 改工单
- 引导 vs 排队 = 现场提醒 vs 待办便签
- 分叉 = 复制工作台
逐一拆开说。
一、双击 Esc 叫停（刹车）
刚才那个场景就是例子。
假设你让 Codex：
帮我整理这个项目的代码，但不要修改数据库部分。
执行一会儿后，你发现它正在查看数据库文件，或者你突然想起还有一个重要限制没有说。
这时不用等。
在输入框处连续按两次 Esc，就可以停止当前执行。
第一次按下 Esc，相当于你对正在干活的同事喊了一声：
先停一下。
Codex 会进入停止确认状态。再按一次，才真正结束这一轮工作。这样设计是为了避免误触，毕竟很多人按 Esc 只是想关掉菜单或者退出某个输入状态。
注意一点：打断不是撤销。
Codex 在停止前已经完成的文件修改，通常仍然保留。它只是不会继续后面的步骤，并不会自动把工作区恢复到执行前。
所以打断之后，可以先问一句：
刚才已经完成了哪些修改，还有哪些没有做？
确认现场，再决定继续、调整还是回退。
这个动作很像踩刹车。踩刹车不是把车倒回出发点，只是先别继续往前开。
二、上一句话说错了，直接编辑，不必补十条解释
我们平时和人聊天，说错一句话，往往要在后面补：
不对，我刚才不是这个意思。 上一条里的 A 改成 B。 其他要求保持不变。
补得越多，上下文越乱。Codex 虽然能读懂，但也需要同时记住原要求、纠正说明和新的边界。
更干净的做法，是直接编辑上一条已经发送的消息。
把鼠标移到最近一条自己发送的消息上，选择编辑，修改后重新发送。Codex 会根据修改后的版本重新执行这一轮。
例如原来写的是：
把登录页面改成手机号登录。
发出去后你才想起来，应该保留邮箱登录作为备选。不用在后面补一条"保留邮箱作为备选"------直接把上一条编辑成：
把登录页面改成手机号登录，保留邮箱登录作为备选。
Codex 按新版本执行，不会有上下文混乱的问题。
平时习惯用补丁式对话的人，第一次用编辑时会有一种"原来可以这样"的清爽感。补丁式对话的问题在于：每补一条，Codex 就多记住一层上下文，到后面它要同时处理原始需求 + 修正 A + 修正 B + 修正 C，负担越来越重。直接编辑，就一条干净的指令。
三、引导 vs 排队：最常用、也最容易被忽略的
你发了一条新消息给 Codex，它正在执行上一轮任务。这条新消息会去哪里？
默认情况下，它会引导当前执行------相当于你走到同事工位前，说了一句：
等一下，还有一件事。
同事会停下来，先处理你的新信息，再继续手头的工作。
引导适合这些场景：
- 补充约束条件："不要碰 database 目录"
- 纠正当前方向："刚才那个文件不对，换一个"
- 紧急追加："加一个错误处理"
但引导也有风险。
举个例子，Codex 正在重构一个函数，你突然想到一个无关的事：
顺便看看那个旧的日志文件还在不在。
如果你用的是引导，Codex 可能真就停下来去翻日志了------本来函数重构在关键步骤上，这一打断，回头它还要重新加载上下文，效率反而更低。
另一种选择是排队。
排队就是告诉 Codex："你先干完手上这件事，再处理我的新消息。"
适合什么？
- 全新的下一步任务
- 不影响当前执行的想法补充
- 想到了就先记下来，发完去做别的事
我之前一直用默认的引导，觉得"想到了就马上让它做"效率最高。后来发现不对------频繁引导打断了 Codex 的执行流，它每次中断后都要重新加载上下文。反而排队的任务，等当前任务完成后再处理，Codex 的执行状态是连续完整的。
现在我养成了一个习惯：默认排队，除非这条消息真的必须立刻影响当前执行。
判断标准很简单，只问自己一句：
这条消息会不会改变 Codex 现在正在做的事？
会改变，就点引导。不会改变，只是下一件事，就让它继续排队。
四、想尝试另一种思路，不要推翻原任务，直接分叉
有时当前对话没有错，只是你想试试另一种可能。
例如你让 Codex 设计一个后台页面，它给出了传统表格方案。你觉得可以，但又想看看卡片式布局会是什么效果。
如果直接在原对话里说：
不要表格了，全部改成卡片。
原来的路线就被覆盖了。试完卡片后如果觉得还是表格好，又要往回走。
更合适的办法，是从当前任务继续到一个新任务，也就是分叉。
新任务会继承分叉点之前的对话背景，但之后拥有自己的消息、结果和执行过程。原任务仍然留在原来的路线，不受新讨论影响。
它很像在地图上的岔路口复制一支队伍。一支继续走左边，尝试表格方案。另一支从同一个位置出发，走右边，尝试卡片方案。最后比较结果，再决定采用哪一条路。
我有一次写一篇文章的开头，让 Codex 出了三个版本。A 版用故事开头，B 版用问题开头，C 版用数据开头。三个我都不想放弃，就直接分叉了三条线，每条线各自往下展开。最后比较下来，A 版的故事开头最自然，B 版和 C 版的素材也没浪费------拆成了正文里的案例。
分叉特别适合这些场景：
- 比较两种技术方案
- 尝试不同的页面设计
- 保留稳定方案，同时实验激进改法
- 从同一份分析得出不同版本的文章
- 当前任务已经很长，想把后续子任务单独整理
点击"在新任务中继续"，从当前位置分出另一条路线。新任务会标出与原任务的接续关系，原来的任务仍然保留。
不过有一点要注意：对话分叉不等于文件也自动复制。
如果两个本地任务操作的是同一个项目目录，它们仍然可能修改同一批文件。两个任务同时动手，很容易互相覆盖。涉及代码实验时，可以为不同任务使用独立的 Git worktree，也就是给每条路线准备一套单独的工作目录。
分叉复制的是对话路线，不一定复制施工现场。这一点要分清。
从"等结果"变成"管过程"
这五个动作，可以记成一张很短的清单：
- 方向明显错了，双击 Esc，先停车
- 最近一条需求写错了，直接编辑，换掉旧工单
- 新消息默认排队，先放进下一轮待办
- 新信息要立刻改变当前工作，点击引导，现场告诉它
- 想尝试另一条路线，用分叉，保留两个方案
刚开始使用 Codex，不需要一上来就研究复杂提示词。
先学会观察它正在做什么，然后在合适的时间叫停、补充、排队或分路。你会发现，跟 AI 打交道不再是"发一条等一条"，而是像带一个需要偶尔提醒的新同事------大部分时候它自己干得挺好，关键是你要在岔路口出现的时候，及时说句话。
因为真正重要的，不是第一句话写得有多完美。
而是当事情开始变化时，你仍然知道该怎么把方向握在手里。
今天就打开 Codex，在输入框里连续按两次 Esc 试试。你会有完全不同的感受。
既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果可以给我个星标⭐，将不胜感激～谢谢你看我的文章，我们，下次再见。
#AI写作 #Codex #AI工具 #效率提升 #大象AI共学
作者：大象-推动 AI 共学，让普通人轻松上手AI