同时提交图片和视频时结果不对，先不要怀疑模型。把图像链路和视频字幕链路各用一条最小请求单独跑通，拿到两条确定可用的基准返回，再合并提交做单字段对比，问题最终只会落在三种情况：图像输入本身不行、视频输入本身不行、两类字段在合并时互相覆盖。判断顺序比调参顺序更重要，顺序错了，改参数只会让现象更乱。

适用场景：Wan-Streamer v0.2 同时接收图片与视频、返回与预期不符且分不清问题来源。操作动作：先各跑一条最小样本（单图加一句指令、几秒短片），保存原始返回；再合并提交，每次只改一个字段并留存报错原文。验证方式：对比三次请求的返回结构、状态码和关键字段是否为空。风险边界：样本要贴近真实输入；字段名、帧数上限、时长上限、抽帧策略需结合部署环境确认，单条样本通过不代表批量输入都通过。

图像链路用单图加一句指令跑通

图像链路的目标只有一个：拿到一条确定可用的基准结果，后面所有对比都拿它当参照。样本图建议这样选：单一主体、构图正常、不是超长截图、不是密集小字、常见 jpg 或 png、尺寸在服务允许范围内。先用最简单的图，是为了把「图本身让模型看不懂」这个变量排除掉，链路通了以后再换成真实业务图。

请求体骨架示意如下，键名和必填项以实际服务为准，不要直接照抄：

POST /v1/understand
Content-Type: application/json

{
  image: <图片URL 或 上传后的文件id>,
  prompt: 用一句中文描述画面主体,
  stream: false
}

把这条请求放在能看完整响应体的地方执行，例如带 -i 参数的 curl、HTTP 客户端或服务自带的调试页。判断返回与预期是否正确，看四点：HTTP 状态码是否成功；响应里有没有明确的错误字段；返回文本是否提到了图片中的主体，而不是空串或通用套话；结构化返回时图像相关字段是否被填充。这四点里有一条不符合，就先不要进下一步。

视频链路用几秒短片单独跑通

视频链路的变量比图像多得多，短片要尽量「无聊」：几秒时长、单一场景、镜头不晃、人声清晰或干脆没人声、mp4 容器配常见 h264 编码。先确认服务端收的是本地文件上传还是可访问的 URL，不少抽帧失败其实是取不到视频源，而不是模型问题。

POST /v1/understand
Content-Type: application/json

{
  video: <视频URL 或 上传后的文件id>,
  prompt: 输出这段视频的字幕分段,
  stream: false
}

视频的返回结构和图像通常不一样：字幕类任务一般返回分段列表，每段带起始时间、结束时间、文本；图像任务通常是一段整体描述。差异点就在此处——合并调用如果只返回了一大段整体文字，说明视频分支可能没被触发；如果分段存在但时间是空的，说明抽帧或时长解析环节出了问题。视频这条链路还要单独确认三件事：服务允许的最长时长、默认抽帧间隔或最大帧数、格式不在白名单时是直接报错还是静默转码。这些通常写在配置、启动日志或接口说明里，需要结合环境确认。

合并提交时逐一排除字段冲突

两条链路分别跑通后再合并。合并请求里最大的风险不是模型不会同时处理两种输入，而是同一请求体里字段重名、互斥或被后写入的值覆盖。示例骨架：

POST /v1/understand
Content-Type: application/json

{
  image: <图片URL>,
  video: <视频URL>,
  prompt: 同时描述图片内容并给出视频字幕,
  max_frames: 16,
  detail: high,
  stream: false
}

排查时固定样本、固定 prompt，每次只改一个字段，其余全部不动，并且把每次的完整返回原文留存。建议按这个顺序对比：

• 只传 image，确认返回与图像链路的基准结果一致；
• 只传 video，确认返回与视频链路的基准结果一致；
• image 与 video 同时传，其他参数一字不改，观察返回偏向哪一类输入；
• 在合并请求里逐个恢复 detail、max_frames、prompt，一次只恢复一个；
• 最后只改 prompt 换一种问法，确认差异来自输入还是来自指令。

判断哪一项被忽略，看返回而不是看参数：合并返回里完全没有视频分段字段，说明 video 分支被跳过；分段字段在但内容为空，说明视频读到了却没有输出；返回内容与只传 image 时几乎一样，说明 image 和 video 可能复用了同一个输入槽位。出现异常时把返回原文整段贴进记录，不要只写「报错」或「结果不对」，错误信息里的字段名往往就是冲突点本身。

分别记录两条链路的耗时与失败率

合并调用最容易掩盖问题：视频本来就更慢，图像快，算在一起得到的是一个没有意义的平均值，图像链路的失败也会被视频的成功稀释掉。记录表至少要能按链路拆开统计，字段建议这样设计：

• 时间戳与请求 id，用于回查日志；
• 链路类型：image / video / merged；
• 样本标识与关键参数（prompt、max_frames、detail）；
• HTTP 状态码与业务错误码；
• 端到端耗时，能拿到服务端处理耗时就单独记一列；
• 返回是否可用：结构正确且内容非空；
• 原始返回或错误原文的存放位置。

对比表模板如下，数值按实际调用填写，不要预置结论：

每类样本建议各跑若干次而不是一次，次数按自己能接受的排查成本定。填完后看两个方向：失败是否集中在某一条链路；合并调用的耗时是否明显偏离两条单独请求里较长的那一条。如果图像单独全部正常、合并后图像内容消失，问题就在字段冲突；如果视频单独就超时或返回空分段，问题在视频输入本身，与合并无关。结论写成这种能被下一条日志验证的形式，比笼统地说整体效果不好更有用。