画面既慢又崩的时候，最容易犯的错是把“卡”当成一个毛病。PixVerse Game 这类实时生成的场景里，出帧延迟和角色漂移通常来自不同的环节：延迟更多和渲染链路、分辨率、单次请求的负载有关；漂移更多和镜头节奏、场景切换、角色绑定与参考一致性有关。两者混在一起改，就会遇到“延迟好一点、漂移更明显”的情况。可操作的做法是：先把现象拆成延迟列和漂移列各自记录，再用同一段操作同时打点和截图保证时间对齐，然后一次只改一条线并复测，最后把两列结论分开写。

先做拆分，不急着调参。适用场景：同一段操作里既觉得出帧慢、又看到角色位置或外观在漂。操作动作：延迟列只记时间差，漂移列只记外观变化描述，两类现象分开落表。验证方式：用同一段操作同时打点和截图，靠时间戳与文件名一一对应回看。风险边界：两条线同时改动时，复测结果无法归因；是否能拆分清楚，需要结合你当前的采集方式和可回放的输入确认。

把“卡”拆成延迟列和漂移列分别记

两列字段的定义要写死在模板里，避免记录时临时想措辞。延迟列的取值方式是“时间差”：从某个操作事件到某个画面事件之间相差多少毫秒，只填数值和事件名，不写主观感受。漂移列的取值方式是“外观变化描述”：角色相对参考帧往哪个方向偏、偏了大概多少、肢体或服饰有没有错位跳变，只描述看到什么，不猜原因。

两张表分开写，好处是记录时不会用“卡顿严重”这种一个词同时盖住两个问题。建议每列至少连续记 3 段同样的操作，再看有没有稳定出现的模式。

用同一段操作同时打点和截图

两条线的证据必须共享同一时间轴，否则事后对不上。通用做法是：跑一段固定操作，在关键事件上打点写日志，同时按打点时刻截图。tag 换成你这次的操作名，t0 放在操作开始处。

// 通用打点骨架：同一段操作同时写日志、存截图
// 需替换：tag 改成当前操作名，截图目录改成你自己的路径
const tag = 'run_pose_slide';
const t0 = performance.now();

function mark(event, extra = {}) {
  const rel = Math.round(performance.now() - t0);
  console.log(JSON.stringify({ ts: Date.now(), rel, event, tag, ...extra }));
}

mark('input_start');    // 触发角色动作或场景切换
mark('first_frame');    // 画面出现第一帧
mark('settle_frame');   // 画面不再明显变化

截图命名建议带上同一组字段：tag__event_relms__序号.png，例如 run_pose_slide__first_frame_0000ms__01.png。序号只用于同一毫秒内的多张截图，不参与对齐。验证方式很直接：文件名里的 rel 应该能在日志里找到同 tag 同 event 的那条记录，一条日志对一张截图，对不上就说明打点和截图不在同一段操作里，需要重跑。

事后核对可以先把两边的 rel 排序再比对：

ls captures/pixverse | grep run_pose_slide | sed 's/.*__\([0-9]*\)ms__.*/\1/' | sort -n

如果日志是 JSONL，可以用 grep run_pose_slide run.jsonl 取出对应行，人工核对 rel 字段。这条命令只是整理材料，是否对齐仍然靠肉眼确认时间戳和文件名。

只对延迟列做改动并复测

这一轮只允许动延迟相关的项，不动镜头和场景切换。常见可改项：输出分辨率、生成帧率上限、单次请求的时长或步数、同屏负载元素数量、渲染前的等待策略。改动项一次只动一个，避免“改了三个地方、延迟降了但说不出是哪个起作用”。

1. 记录改动前的延迟列数据，至少 3 段同样操作。
2. 只改一个项，其余保持原样。
3. 用同一段操作复测 3 次，逐次记录首帧时间差与稳定时间差。
4. 同时看漂移列：如果漂移描述明显变了，说明这个改动跨线了，要么回退，要么把漂移变化单独记下来。

记录格式建议一行一项：改动项 | 改动前时间差(3次) | 改动后时间差(3次) | 漂移列有无变化。延迟列结论要能回答“这个改动是否稳定地影响时间差”，只出现一次好转不算成立。

再只对漂移列做改动并复测

反向来一轮：这一轮只动和画面稳定相关的项，不动分辨率、帧率这类延迟项。可调项通常包括镜头推进或拉远的速度、切镜间隔、转场方式（硬切或淡入过渡）、场景切换时角色位置是否重置、角色绑定或骨骼跟随参数、背景与前景元素数量、参考图与提示词里角色描述的一致性。

观察方式仍以回放和截图比对为主：跑同一段操作，按截图序号逐帧看角色轮廓相对参考帧的偏移方向和幅度，以及切换场景后角色是否回到预期位置。如果漂移只在某次切换之后出现，就把切换步骤单独拆出来再跑一次，缩小范围。复测同样是 3 次，记录格式：可调项 | 漂移描述(3次) | 延迟列有无变化。漂移的判定偏描述性，建议同一项至少两轮观察结论一致再认为成立。

把两列结论分开写成两段

最后不要合成一句“优化了卡顿”。延迟一段、漂移一段，各自用同一组字段，互不引用对方的结论。

两段结论里，如果出现“延迟改动导致漂移变化”这类跨线记录，单独标注出来，下一轮再验证，不要写进任何一段的成立判断里。