UnifoLM-OminiA-0.3 一次请求里同时带图文和语音时，真正决定结果好坏的通常不是“谁排在前面”这个物理次序，而是每个模态有没有被放进一个有名字、有指代的槽位。保守做法是把文本放第一位，承担指令和上下文；图像、语音作为附属内容紧随其后，并在文本里显式写出“下面这张图”“下面这段语音”。如果只是把三样东西平铺塞进请求，顺序本身带不来收益，输出跑偏时也无从判断是哪一段被忽略。

处理方向：把一次请求拆成 text / image / audio 三个显式槽位，顺序固定为文本指令在前、图像其次、语音最后，文本里保留指代锚点；再用同一段描述分别配图、配语音、配图文语音跑对照，看输出里是否出现画面细节、是否回应语音内容，以此判断模态被消费还是被跳过。适用于接入初期和提示词调优阶段；不同版本、不同部署方式对模态的支持不一致，需结合环境日志和实际返回确认，本页不给通用性能结论。

把一次请求拆成文本、图像、语音三个输入槽位

槽位的意思不是接口字段名，而是“这块内容在请求里扮演什么角色”。接入前先把三个位置定下来，后续所有模板都按这个结构拼，不临时改。下面是一份通用接入骨架，字段名可按实际 SDK 替换，结构不变：

{
  "request_id": "req-0001",
  "model": "UnifoLM-OminiA-0.3",
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "slot": "instruction",
          "required": true,
          "value": "先描述这张图里有什么，再回答语音中提出的问题。"
        },
        {
          "type": "image",
          "slot": "primary_image",
          "required": false,
          "ref": "img_001",
          "anchor": "这张图"
        },
        {
          "type": "audio",
          "slot": "primary_audio",
          "required": false,
          "ref": "aud_001",
          "anchor": "这段语音"
        }
      ]
    }
  ]
}

槽位职责建议这样划分：

• text / instruction：必填。放任务指令、输出格式要求、以及指向图像和语音的锚点词。没有这段文本，另外两个模态往往没有明确用途。
• image / primary_image：选填，但一旦传入，文本里就必须出现对应锚点，否则模型可能只做泛泛概括。
• audio / primary_audio：选填。若只靠语音提问而文本无锚点，常见情况是模型把语音当成环境音而忽略内容。
• text / 追问位：可选再加一个文本槽位放补充约束，但位置应在图像和语音之后，避免把指代关系打乱。

判断槽位定得对不对，有个简单办法：把文本里的锚点删掉重发一次，如果输出质量明显下降，说明指代确实在起作用，模板可以保留；如果没变化，说明模型本来就在整体读，锚点可以简化。

用同一段描述分别配图、配语音、配图文语音跑四组对照

对照实验的关键是“只改模态组合，其余全不动”。四组的构造方法：A 组只发文本描述，作为基线；B 组文本 + 图像；C 组文本 + 语音；D 组文本 + 图像 + 语音。四组用的文本必须是同一份拷贝，锚点词也一致，不要为某一组重写提示。

每次请求需要固定的变量清单：同一张图（同一路径、同一压缩参数）、同一段音频（同一采样率与时长）、同一份系统提示、同一组采样参数、同一输出长度上限、同一时间段内的同一模型版本串。其中模型版本串和输出长度上限最容易被忽略，版本悄悄变了，四组结果就没有可比性。

记录字段建议按下表落地，一张表一行请求，方便横向比对：

不要只记录“好/不好”，那类判断过后无法复盘。记录原文片段比记评分更有用。

在输出里定位模态信息被用上还是被忽略

从输出反推模态使用，靠的是“只有该模态里才有的信息”。设计输入时刻意埋点：图像里放一个不常见的物件或一行小字；语音里说一个文本中未出现的数字或专有名词。然后看输出是否复现。

可观察的检查点：

• 输出是否描述了图中特有物体、颜色、相对位置或图中文字。
• 输出是否原样复述语音里的数字、地名、人名这类实体，而不是含糊地说“你提到的问题”。
• 输出是否回应了语音的语言和语气，例如语音用方言提问而输出仍按普通话问题作答，通常说明语音只做了粗略识别。
• 输出是否遵守了“先描述再回答”的先后要求，顺序错乱说明文本指令权重被其他模态稀释。
• 输出是否出现“图片中似乎有……”这类含糊表述却没有具体细节，这种多为只读到高层语义。

如果四组里 B 组和 D 组输出几乎一致，而 C 组贴近 A 组，说明语音大概率没被消费，优先查语音槽位是否为空、时长是否越界、音频格式是否被接受。这类判断依靠日志和返回体，不靠猜。

把输入顺序和模态组合固化成可复用的请求模板

模板至少要写清这些字段：template_id 与版本号、system_prompt、text.instruction（指令与输出格式）、text.anchors（锚点词列表）、image.ref 与允许的格式和尺寸范围、audio.ref 与允许的采样率和时长范围、模态组合标识、最大输出长度、以及“缺模态时如何降级”的说明。模板里不写具体业务内容，业务内容作为参数填进去。

每次请求额外记录元信息：request_id、发起时间、模型版本串、模板版本、各输入文件的哈希、模态组合、输出原文留存地址。哈希和版本串是事后区分“是模型变了还是输入变了”的唯一依据。

异常输入的处理方式建议直接写进模板注释：

1. 图像缺失或解码失败：降级为纯文本请求，同时把文本里的图像锚点删除，不要留一个指向空处的“这张图”。
2. 语音为空或转写结果为空：不传 audio 槽位，改为在文本中说明“本段无语音内容”，避免模型自行编造。
3. 图文语音互相冲突（语音说的与图中物体不符）：在文本指令里显式规定优先级，例如“以图像内容为准，并说明语音中的差异”。
4. 音频过长或图像过大：先做截断或分片，把截断位置记录到元信息，不要静默处理。

模板落地后，每次改提示词或换模型版本，都重新跑一遍四组对照，把记录表追加新行而不是覆盖旧行。这样输入顺序和模态组合才真正固定下来，而不是每次都靠临场拼接。