Cue 跑到一半没动静，第一件要做的事不是改任务描述，也不是重开一次，而是确认它停在第几个执行步骤。判断依据来自三样东西：本次提交的任务原文、按顺序排列的执行步骤状态、停住时页面上出现的提示文字。这三样拿齐，才能区分是任务描述本身有问题、上下文在中途被截断，还是某个动作在等人工确认。

把这次中断当成一条可复现的记录：原样保存任务文本，逐步核对执行状态，找出第一个没有输出的步骤，再只改一处变量重跑对照。常见情形大致三类——停在确认动作上、反复停在同一处、一份任务里塞了多个互不依赖的目标。

把中断那次的任务原文原样存下来

凭记忆重写任务原文，是排查中最容易让变量失控的一步。重写时人往往会顺手把描述压短、把顺序理顺，等到下一次跑通或跑不通，已经说不清是哪一处改动起的作用。

建议在页面还开着的时候，把下面这张表填完。提示文字要逐条抄，不要合并同类项，也不要只记最后一句。

区分自动出现的提示和自己补发的消息很重要。自己补发的那条往往改变了上下文，如果把它当成工具的输出，后面的对照就会失真。

在会话记录里数清楚执行停在第几步

「执行到一半卡住」和「第二步根本没开始」是两种情况。第二步没有输出，通常意味着前一步的产物没有被下一步接住，或者任务描述到这里就断了；第五步之后没动静，才更像执行环节本身出了状况。

按顺序把每一步的状态列出来，只填三种：已完成、等待确认、无输出。然后指出第一个没有输出的步骤，并把它前一步的产物写清楚。整理用的结构可以参考下面这种写法：

步骤 1  读取输入目录        已完成   产物：文件清单，共 N 个
步骤 2  按日期分组          已完成   产物：分组结果
步骤 3  处理第一组          无输出   ——
步骤 4  处理第二组          未开始   ——

这是人为整理的结构，不代表 Cue 会输出完全相同的字段，实际以页面和会话记录里看到的内容为准。数步骤的时候有一个容易漏的点：某些动作在等待确认时界面看起来和没输出几乎一样，需要结合提示文字判断，不要直接归到「无输出」。

改一处变量重跑一次做对照

确认了停住的步骤之后，用最小改动重跑，判断问题出在任务描述还是执行环节。对照表至少要有三个字段：改动点、预期差异、实际差异。一次只改一处，其余输入、会话设置、文件内容保持不变。

两组复跑的示范前提是一样的：

复跑前提
- 同一份输入文件
- 同一会话设置
- 任务目标、验收条件不动

第 1 次：只改描述长度，步骤顺序原样保留
第 2 次：只调换步骤顺序，字数与措辞原样保留

如果两次都停在同一个步骤，且输入没有变化，那么问题更可能落在该步骤本身依赖的产物上，而不是描述写法上。这时候回到上一步，检查那一步的输出是否真的完整、格式是否和下一步的输入预期一致。

用通用骨架重写任务描述再跑

把一大段模糊的说明改成可以逐步检查的任务，通常比反复调整措辞更有效。下面是一份通用写法骨架，字段名可以按自己的习惯改，不代表工具方的固定格式：

目标：把某目录下的一批日志按日期归并成文件

步骤：
1. 列出目录下所有 .log 文件
2. 按文件名中的日期分组
3. 每组追加写入 merged_日期.log

每步怎么算完成：
- 第 1 步：输出文件数量；数量为 0 就停下并说明
- 第 2 步：列出分组结果
- 第 3 步：输出每个合并文件的路径和行数

遇到不确定先问：
- 文件名里没有日期时，先问怎么处理，不要自行猜测

骨架里有两个位置值得保留：一是每步的完成标准，让中断点容易定位；二是「不确定先问」这一条，它可以减少动作在等待确认时被误判成卡死。重写之后先用小范围输入跑一次，确认步骤能依次推进，再换回完整输入。

决定是继续等、缩任务还是拆任务

三种情形对应三种动作，判断依据主要看提示文字和停住的位置是否重复出现。

• 页面停在确认动作上：出现「是否继续」「是否覆盖」一类提示，步骤状态是等待确认。动作是人工确认一次，然后继续观察后续步骤是否推进。不要在这一步反复重发任务，重复提交可能让前一步产物被覆盖。
• 反复停在同一处：两次以上都在同一步骤没有输出，且任务描述和输入没有变化。动作是缩短任务，把这一步之前的内容拆出去单独跑，先确认前一步的产物能被下一步正常接收。
• 任务跨越多个目标：一份任务里同时包含整理数据、写报告、发送通知这类互不依赖的目标。动作是拆成几次独立提交，每次只留一个目标和一个验收点，这样停住时能立刻知道是哪一段的问题。

把这次的中断记录留在会话旁边，下次再遇到停住，可以直接和上一次对照，而不必从零开始重新描述任务。