mcpField
M
multimodal-orchestration

multimodal-orchestration

github.com/owl-listener设计与 UI191290 次安装20 周前更新
代码仓库

关于 multimodal-orchestration

用于协调 AI 交互中的文本、图像、语音、代码、结构化数据和工具的设计技能。帮助产品设计者依据用户需求选择模态,并规划转换与降级方案。

主要功能

  1. 01模态选择规则
  2. 02跨模态转换设计
  3. 03处理模态冲突
  4. 04输入与输出模态矩阵
  5. 05降级方案规范

适用场景

  1. 01规划设计评审功能的模态
  2. 02设计从文本到工具的转换
  3. 03为不可用模态定义无障碍替代方案
  4. 04解决文本与图像输出冲突

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/owl-listener/ai-design-skills --skill multimodal-orchestration

安装后在 Claude Code 中输入/multimodal-orchestration确认已加载。

详细介绍

多模态编排

AI 交互日益涉及多种模态——文本、图像、语音、代码、工具和结构化数据。设计这些模态如何协同工作,就是编排。每个团队都面临这样的风险:因为某种模态可用就切换过去,而不是因为它能为用户提供帮助。

多模态的重点不是用上每一种模态,而是在恰当的时机使用恰当的模态,并妥善处理模态之间的衔接。

模态选择

每种模态都有其优势:

  • 文本:精准、可编辑、可供参考。最适合说明、解释和细腻的内容。
  • 图像:空间化、整体性强、直观。最适合布局、图表和视觉概念。
  • 语音:自然、解放双手、富有情感。最适合对话流程和无障碍体验。
  • 代码:可执行、精准、可验证。最适合技术规格和自动化。
  • 结构化数据:表格、表单、JSON。最适合比较、配置和数据录入。
  • 工具使用:在外部系统中执行操作。最适合执行,而非生成。

设计者决定 AI 在回答的每个部分使用哪种模态,也决定邀请用户以哪种模态输入。

跨模态转换

交互切换模态时,应设计好转换方式:

  • 文本 → 图像:“这是该布局可能呈现的样子。”AI 根据文本描述生成视觉内容。
  • 图像 → 文本:用户上传截图;AI 对其进行描述或评析。
  • 文本 → 工具:AI 编写计划,然后执行。
  • 语音 → 文本:将口头对话记录并总结为结构化笔记。

转换应当自然流畅。用户不应该需要手动切换模式。

模态冲突

有时不同模态之间会相互冲突:

  • 文本说一回事,图像却展示了另一回事
  • 语音语气与文本内容相矛盾
  • 结构化输出与对话语境不一致

为每种交互情境确定一种主要模态。其他模态作为辅助,用于补充主要模态,绝不凌驾于其之上。

决策规则

  • 选择用户能够采取行动的模态,而不是 AI 能够生成的模态。 如果用户想要图表,图表会令人印象深刻;如果用户只想要一个数字,图表就显得多余。
  • 始终保留文本记录。 语音和图像输出无法通过屏幕阅读器访问、无法搜索,并会在会话结束时丢失。即使文本不是主要模态,它也能作为审计记录。
  • 模态不一致时,以主要模态为准,并指出冲突。 “图表显示三个步骤,文本却提到了四个——我来协调一下。”
  • 切换模态时必须提前告知,或者确保可以轻松撤销。 用户要么知道模式正在改变(“这是对应的图表”),要么能轻点一下就关闭新模态。
  • 不要在一句话中途切换模态。 在一轮交互中从语音切换到图像再切回语音,会打乱用户的处理节奏。应在轮次边界分组呈现不同模态的输出。
  • 输入模态由用户决定。 绝不要强迫用户离开他们一开始选择的模态——AI 可以多模态输出,但输入模态由用户决定。

反模式

  • 模态炫技:仅仅因为系统能做到,而不是因为用户需要,就切换到吸睛的模态(图表、语音、生成式 UI)。用户看到的是花招,而不是帮助。
  • 有损转换:在模态之间转换时,丢失了重要信息。语音 → 文本会丢失重音和停顿;图像 → 文本会丢失空间关系。记录丢失的信息,或同时保留两种模态。
  • 模态锁定:AI 用模态 X 回复,用户也只能用模态 X 回应。语音提问就必须语音作答,即使用户此时正在开会。
  • 未告知的切换:交互过程中模态突然改变,没有任何提示。这会破坏无障碍体验、违背用户预期,也会让屏幕阅读器用户完全无法使用。
  • 主模态冲突:两种模态都自称具有权威性。当两者不一致时,用户不知道该信哪个。
  • 模态作秀:用户想要的是散文,却给出结构化输出(JSON、表格)。看起来严谨,读起来却更糟。

何时不应使用

  • 设计上采用单一模态的产品——搜索框、代码补全工具、转录工具。不要仅仅因为模型支持多种模态,就添加更多模态。
  • 输入受限的场景(驾驶、戴医疗手套操作、低带宽)——选择在该场景中可用的一种模态并坚持使用;协调开销只会成为负担。
  • 早期原型——先把一种模态做好,再添加衔接方式。多数多模态失败源于主要模态尚未准备就绪。

另请参阅

  • generative-ui —— 当辅助模态是生成式 UI 时,此技能会定义何时切换,generative-ui 则定义切换到什么。
  • conversation-patterns —— 模态转换本质上是伪装起来的修复序列;应按此进行设计。
  • progressive-disclosure —— 次要模态往往是高级功能,应有意地逐步披露。
  • feedback-loops —— 跟踪用户会撤销哪些模态切换;这是你能获得的最明显的隐式反馈信号。

设计产物

  • 模态映射,展示每个交互节点使用的模态
  • 跨模态转换规范(触发条件、内容、模态不可用时的回退方案)
  • 各功能的输入/输出模态矩阵
  • 模态不可用时的回退定义(网络连接缓慢、屏幕阅读器、无障碍设置)

示例——设计评审功能的模态矩阵:

阶段AI 输出(主要)AI 输出(辅助)用户输入原因
上传反馈文本确认—图像(模型图)用户以图像思考;AI 以文本确认,便于留档。
评审文本(编号)带注释的图像叠加层文本编号文本便于引用;叠加层标明各要点的位置。
提出修改建议带注释的图像文本说明文本或点击要点用户可选择视觉修改(轻点一次)或书面说明。
迭代文本图像差异对比图像(修订后的模型图)迭代周期中,文本占主导,因为用户想要的是比较,而非观感。

请注意这一模式:AI 使用与用户输入相匹配的模态,或最便于采取行动的模态,并以文本为主干。大多数时候,图像是辅助模态;只有在确认视觉修改的关键时刻,图像才是主要模态。

改编自多模态界面相关研究,以及这样一项原则:模态应对应用户对任务的表征,而不是系统的能力(Maybury 和 Wahlster 关于智能多媒体界面的研究)。

评论

支持 Markdown