被演示里的流畅度打动，通常只能说明一件事：那一段示例提示刚好落在系统擅长的区间。换成自己的真实提示，卡顿和“画面跑偏”往往同时出现，但这两件事的成因和修复成本完全不同。实时响应看的是从提交到看见反馈这条链路，画面可控性看的是同一次输入能不能被稳定复现、能不能只改想要改的地方。把 X2.0 的评估拆成两张表，各自只记录能直接看到的东西，选型才不会凭一次演示的印象拍板。

判断方向：实时响应与画面可控性分表评估，不合成一个“体验好坏”的印象分。做法是各列 3 项与 2 项可观察指标，用同一组提示跑两轮对照——第一轮默认配置，第二轮只改一个变量。验证依据是屏幕录制、前端打点日志和截图对比，不是主观感受。边界：指标只反映当前环境和当前提示集下的表现，换内容类型或并发规模后需要重测。

把实时响应拆成几个能直接看到的指标

“快”要先变成能指认的项，否则讨论会滑回主观感受。建议固定下面三项，每项都写清楚看什么、在哪看。三项都在同一台机器、同一个网络下观察，测之前清掉浏览器缓存之外的干扰项，比如后台下载和别人共用带宽。

• 首帧出现时间：从点下提交到第一张可见画面出现（流式返回时是第一块画面）。观察方式：屏幕录制后逐帧看，或在前端请求发出、首块数据到达两个位置各打一个时间戳。记录位置：浏览器开发者工具 Network 面板里该请求的 Timing、前端控制台日志、服务端访问日志里的请求开始时间。
• 连续交互间隔：不只看单次，看连续操作的节奏。做法是固定做 10 次同类操作（连续调同一个参数、连续拖动预览），记录每次输入到画面有反馈的间隔。观察方式：录屏里比对光标动作和画面变化，或者每次操作触发时打点。记录位置：前端打点日志；没有打点能力时，用录屏时间轴手工记。
• 失败重试次数：一次完整会话里出现超时、断流、画面空白、必须手动重来的次数。观察方式：不要只记“成功了几次”，要记失败长什么样。记录位置：浏览器控制台的报错、前端错误上报、网关或反代日志里的超时条目。

前端打点可以先用下面这个骨架，放在发起请求的模块里，输出到控制台；需要留存时把数组随请求一起上报即可。替换项是回调名：如果接入的不是流式返回，就把首块数据的回调换成整包返回的回调，并在记录里注明“非流式”。

const t0 = performance.now();
const marks = [];
const mark = (name) => marks.push({ name, ms: Math.round(performance.now() - t0) });

mark('submit');
// 首块数据到达时调用
mark('first-chunk');
// 画面可操作（可拖拽/可再次提交）时调用
mark('interactive');
console.table(marks);

把画面可控性拆成能直接看到的指标

“像不像”如果不能复现，就只是审美争论。画面这一侧建议只记录两项，两项都靠截图和叠图说话，不靠形容词。

同一提示重复出画面时的一致程度

做法是同一个提示连续跑 3 到 5 次，把每次结果都存下来，按四栏逐次比对：主体数量与位置、构图视角与景别、主要配色关系、画面内文字是否出现错字或乱码（含文字的提示才看这一栏）。记录方法：每次截图按 提示编号_轮次.png 命名存进同一个文件夹，比如 p03_run2.png，另在表格里写判定词，只用“一致 / 部分一致 / 不一致”三个值，不要写“感觉差不多”。判定“部分一致”时，把具体差在哪一栏写在备注里。

局部改动的生效范围

做法是先在已生成画面上只提一个局部改动要求，比如替换某个区域的元素、只调背景色、只改某个人物的姿态，其它条件全部不动。记录方法：改动前后两张图在设计工具里半透明叠加，或者导出后直接对照，然后列一张“实际变动区域清单”，写清楚哪些区域本来不该动却动了、哪些该动的地方没动到位。这张清单比一句“改得挺准”有用得多，因为它能看出改动是扩散到整张图，还是被约束在目标区域内。

用同一组提示做两轮对照记录

两个维度必须在同一条件下比较才有意义。准备一组覆盖你真实业务形态的提示，建议 5 条左右，长短、复杂度、是否含文字都要有。第一轮 A 用默认配置跑完，第二轮 B 只改一个变量（分辨率、生成步数、是否启用缓存等任选其一），其它全部保持不变。两轮之间不要换网络、换机器、换时段太久。

填写规则再强调三点：一行只对应一条提示的一轮，不要把两轮并成一行；响应表现里禁止出现“挺快”“有点卡”这类词，写不出精确值就写“未记录”，事后别补；画面表现必须能追到具体截图文件，否则这一行作废。两轮都记完再对比，不要一边测一边下结论。

根据记录决定优先保速度还是保可控

记录齐了之后，判断其实很机械。如果 A、B 两轮的速度指标差异明显、画面判定都没掉档，说明可以优先保速度，把可调参数往响应侧倾斜；如果画面判定从“一致”掉到“部分一致”、而响应差别在可接受范围内，优先保可控，宁可慢一点也不要每次结果都不一样。两条线同时退化时，先缩小提示范围和改动幅度再复测，别急着归因到系统本身。

表格右侧那一列是诚实的留白：它能提示这份记录还不足以下最终结论。建议把这几项当成下一轮试用的必测内容，尤其是长会话衰减和局部改动后的再次生成，它们往往比首帧快慢更影响实际能不能用。留白没填满之前，先按当前优先级用，不要把临时结论写成长期方案。