评估 GO-3 Preview 这类把感知输入和动作输出串起来的系统时，容易被“动作看着像不像”吸引，判断标准就变成拟人程度。更可操作的评估做法是分两条线：一条看感知到动作之间是否存在可复现的断点，另一条看同一场景在不同任务粒度下断点是否变化。两条线都只依赖可记录的观察，最后写成一份能被别人复核的评估记录。下面给的是观察方法和记录格式，不涉及任何模型内部实现细节，具体字段名、日志入口、配置项需要结合你手上的环境和版本确认。

判断 GO-3 Preview 的衔接质量，可以从两个可观察方向入手：在连续动作序列中标记每次停顿的位置及当时场景变化，再把停顿时刻与输入变化时刻做对齐，区分是感知延迟还是决策切换；然后用粗、细两种任务粒度在同一场景各跑若干轮，比较断点数量和位置。适用场景是交互式任务或分步执行场景；风险边界是观察结论只对该配置和场景成立，未覆盖的组合要标注为未验证，不要外推为整体能力判断。

在连续动作里找衔接断点

先不要评价动作本身好不好看，而是把“感知到动作”的衔接拆成时间点来记录。做法是选一个短场景，例如“看到桌面目标物、移动到附近、停下等待下一步指令”，全程录屏，同时保留输入侧的时间戳（画面帧时间、状态更新时刻）和执行侧的日志时间戳（动作开始、动作结束、停顿）。重点记录每次停顿出现的位置，以及停顿发生时场景发生了什么变化——是目标物移动了、输入画面没更新，还是指令刚切换。这一步只做记录，不解释原因。

建议用下面这种结构保存观察记录。表格可以直接放在共享文档里，字段名按你手上的工具调整：

记录表：衔接断点观察
场景：桌面取物-走近-等待指令
配置：GO-3 Preview / 输入参数 A / 任务粒度=粗

序号 | 停顿位置        | 停顿持续时间 | 停顿前后场景变化          | 输入侧时间戳 | 动作侧时间戳
 1   | 启动后首次前移  | 约 1 段       | 目标物位置未变，画面稳定  | t_in_1      | t_act_1
 2   | 接近目标物前    | 约 1 段       | 输入画面切换了一次        | t_in_2      | t_act_2
 3   | 等待指令阶段    | 较长         | 无新指令下发              | t_in_3      | t_act_3

说明：持续时间和时间戳请按实际日志填写，不要预设数值。

停顿出现的位置要具体到“动作序列的第几步、哪个动作之前或之后”，而不是笼统写“中间卡了一下”。如果同一位置在多次运行中反复出现，这个位置就可以先标为候选断点；只出现一次的停顿，先记为偶发，不进入后续对齐分析。这样做的取舍是：牺牲一部分覆盖度，换取结论可复现。

确认断点是感知延迟还是决策切换

找到候选断点后，要回答一个问题：这个停顿是输入侧的变化被感知得晚，还是系统在切换决策。方法是对照输入变化时刻与动作变化时刻，看两者的对齐关系。具体做法是把输入侧时间戳和动作侧时间戳放在同一时间轴上，逐个断点比对：输入变化（画面更新、目标移动、指令下发）发生在动作停顿之前多久，停顿结束后动作是否与最近一次输入变化对应。

• 输入变化后动作长时间没有响应，且停顿结束后的动作与更早的输入相关：更像感知延迟，需要检查输入帧率、状态推送频率、处理排队情况。
• 输入变化后很快出现动作回退、撤销或换向：更像决策切换，需要检查任务配置中的判定条件、指令优先级和状态机分支。
• 输入没有变化但动作停顿：既不是感知更新也不是指令切换，可能来自执行侧的重试、限速或资源等待，同样先用日志确认。

对齐比对时要注意时间基准一致，输入侧和执行侧的时间戳如果来自不同进程或不同机器，先做一次时钟偏差确认，否则比对结果会整体偏移。这里给一个通用的日志片段骨架，字段名和格式按实际环境替换：

# 把两侧事件按时间轴对齐后逐条查看，仅示意结构
t_in_001  frame_update  scene=stable
t_in_002  frame_update  scene=changed  target=moved
t_act_001 action_start   step=approach
t_act_002 action_pause   step=approach  dur=一段
t_act_003 action_resume  step=approach  ref=t_in_002
# 判读：t_act_003 引用 t_in_002，说明停顿结束后的动作由最近一次输入驱动；
# 若 ref 指向更早的 t_in_001，则倾向感知延迟一侧。

如果日志里没有现成的 ref 字段，可以用人工标注代替：看录屏里停顿结束后的动作对应哪一刻的画面，再和输入日志对照。这种人工对齐精度有限，结论应写“倾向”，不写“确定”。

换一个任务粒度重复同样的观察

第二条评估线是任务拆解的粒度。把同一场景按两种粒度各跑若干轮：一种是粗粒度任务，例如“去把目标物拿过来”作为一个整体指令；另一种是细粒度任务，例如拆成“定位目标物”“前移到可及范围”“执行抓取”“返回”几个子任务分别下发。轮数不必多，通常每种粒度跑三轮以上就能看出断点是否稳定，但具体轮数要结合场景耗时和资源决定。

记录时比较四个量：断点数量、断点位置、停顿持续时间、停顿前后的场景变化。需要特别关注两种差异——粗粒度下断点多但集中在任务切换处，往往说明决策层在长任务中缺少中间锚点；细粒度下断点变少但每次子任务启动都有固定延迟，往往说明每个子任务都有一次感知到动作的重新建立过程。这两种情况对应的调整方向不同，不要合并成一个“衔接不好”的结论。

粒度对照记录
场景：桌面取物（同一初始状态）
粒度=粗：轮次 3，断点位置 [启动, 接近前, 等待]
粒度=细：轮次 3，断点位置 [子任务启动处 x N]
差异摘要：粗粒度断点集中在中途，细粒度断点集中在每段起点
待确认：初始状态是否每轮一致；输入画面亮度/角度是否变化

如果两种粒度的断点位置高度重合，说明断点更可能来自感知或执行链路的固定环节，而不是任务拆解方式；如果断点位置随粒度明显迁移，说明任务拆解的粒度确实在影响衔接，评估时就要把粒度作为一个显式变量写进记录。

把两条线的观察写成一份评估记录

最后要把两条线的观察合成一份可交付的评估记录，让别人拿到后能按同样的步骤复核。建议固定四块内容：评估对象与配置、衔接断点记录、粒度对照记录、结论与未验证项。结论表述要区分“观察到的事实”和“推断的原因”，不要把推断写成定论。

GO-3 Preview 衔接与粒度评估记录
1. 评估对象：GO-3 Preview，配置项 [填写]，场景 [填写]，轮数 [填写]
2. 衔接断点：位置 [...]，数量 [...]，停顿前后场景变化 [...]
3. 粒度对照：粗粒度断点 [...]，细粒度断点 [...]，位置差异 [...]
4. 结论表述模板：
   在本配置与场景下，观察到 [位置] 出现可复现停顿；
   对齐输入与动作时间戳后，该停顿更接近 [感知延迟/决策切换/执行侧等待]；
   切换任务粒度后，断点位置 [是否迁移]，据此判断粒度对衔接 [有/无明显] 影响。
5. 未验证项：[未覆盖的配置组合]、[未测试的场景]、[人工对齐精度限制]、[轮数不足的位置]

结论模板里的每一项都要能回指到前面的记录行，回指不到的判断就不要写进结论。未验证项要主动列出，例如只测了单一初始状态、只用了两种粒度、时间戳对齐靠人工标注，这些限制会直接影响结论适用范围。把这份记录交给他人时，对方按同样的配置和场景重跑，应该能复现断点位置的大致分布；如果复现不了，先检查初始状态和输入条件是否一致，再讨论结论是否成立。