多模态设计任务的公平评估与工程验证实践

一、设计能力评估，为什么不能只看截图

多模态模型在设计任务中的价值，并不止于描述图片内容。一个模型即使能够准确识别参考图里的标题、地图和按钮，也未必能理解这些元素之间的信息层级，更不一定能够将其转化为可运行、可维护、可适配不同屏幕的页面。

真正的设计交付至少包含四个连续环节：

第一，理解输入。模型需要分辨任务说明、参考图片、结构化数据和媒体素材各自承担的作用，避免把视觉装饰误判为业务要求。

第二，形成方案。模型需要建立清晰的信息架构，确定页面阅读顺序、主要操作路径，以及桌面端与移动端的布局关系。

第三，实现功能。图表、地图、音频、收藏和状态恢复等能力，必须依赖真实数据与有效交互，而不能仅以静态占位形式呈现。

第四，验证结果。模型需要通过浏览器中的实际页面，检查尺寸、溢出、遮挡、状态同步与异常反馈，并根据证据完成修复。

因此，设计任务中的多模态能力，更适合被理解为“视觉理解、工程实现与反馈修正”的组合能力。评估的目标不是寻找一张最好看的截图，而是判断系统能否稳定完成一条可验收的交付链路。

二、先把任务写成可验证的交付合同

公平评估的起点不是模型运行，而是任务定义。

如果需求仅写成“制作一个有高级感的海洋主题页面”，不同实现之间很难形成有效比较。有的方案可能擅长视觉表现，有的方案可能更重视数据完整性，最终评价容易退化为主观偏好。

更合理的方法，是将需求拆分为四类约束。

1. 必须完成的功能

这类要求直接决定任务是否通过，例如：

• 时间选择能够驱动图表更新；
• 地点选择能够切换对应信息；
• 音频播放与暂停状态保持一致；
• 收藏列表能够正确新增和移除条目；
• 页面刷新后能够恢复约定范围内的状态。

每项功能都应写明触发动作、预期变化和验收方式，避免使用“交互自然”“体验完整”等难以直接判定的表述。

2. 必须遵守的数据与素材规则

要求页面使用提供的数据和媒体资源，不能用虚构数值填补缺失内容，也不能把真实音频替换为无效按钮。

对于无法加载的素材，应要求页面明确展示错误或降级状态，而不是静默失败。

3. 视觉与适配要求

视觉要求可以包含信息层级、留白、对比度、图片裁切和布局稳定性，但应区分“必须满足的边界”与“允许自由发挥的部分”。

例如，移动端不得出现非预期横向滚动，可以作为硬性要求；标题采用何种构图，则可以保留设计空间。

4. 提交与运行要求

应规定统一的启动方式、交付文件范围、运行环境和检查入口。只有交付方式一致，后续的时间统计、故障归因和结果复核才有意义。

三、用两类场景覆盖不同能力

不同设计任务考察的能力并不相同。单一场景的高分，不能直接推导为全面的设计能力。

场景一：数据驱动的海洋主题叙事页面

该场景可以包含多年温度记录、世界地图、海域说明和海洋影像，要求用户通过滚动、年份选择或海域切换理解数据变化。

它主要考察三个方面。

首先是数据语义是否正确。年份、单位、数据来源说明和图表数值之间必须对应。若年份发生变化，而曲线标记、数值卡片或说明文字没有同步更新，页面就只是表面联动。

其次是叙事结构是否清晰。首屏可以承担情绪建立，但后续内容必须解释“数据说明了什么”。大标题和背景图不能挤占所有有效信息，也不能让用户无法判断下一步操作。

最后是数据与结论的边界。若温度数据和风险信息之间没有明确的计算依据，就不应将二者包装为实时推导关系。可以展示既有风险说明，但需要标明其适用范围，避免用视觉效果制造过度确定的判断。

这一场景的核心不是堆叠图表，而是把数据、空间和文字组织成可以被理解的阅读路径。

场景二：声音地点探索应用

该场景包含地图点位、多段真实音频、地点介绍、播放控制、收藏列表和刷新恢复。

与展示型页面相比，它更接近有状态的产品界面，适合检验模型是否真正理解业务流程。

例如，用户在地图中选择地点后，地点卡片、音频来源、播放进度和收藏按钮都应指向同一条记录。切换到下一段音频时，旧音频应按约定停止，界面不能出现“标题已经切换，但播放内容仍属于上一地点”的状态错位。

收藏也不是一个按钮变色的问题。详情区域与收藏列表应读取一致的数据；取消收藏后，所有相关视图都应更新；刷新页面后，应按照任务约定恢复收藏，而不是仅恢复按钮外观。

此外，音频播放可能受到浏览器策略、资源加载和解码结果的影响。点击播放后，页面应根据实际播放结果更新状态，不能在播放失败时仍显示为正在播放。

四、公平对比需要控制哪些变量

使用相同提示词，只是公平评估的一部分。若运行条件不同，结果依然可能失真。

1. 统一输入材料

所有参评系统应接收相同的需求文本、图片、数据和媒体文件。素材文件应保持一致，最好记录校验信息，以排除文件版本差异。

还应固定初始项目结构与运行依赖，防止某个系统因为获得了更完善的模板而占据优势。

2. 统一工具权限

文件访问、终端执行、浏览器查看和截图能力都会影响最终结果。

如果一个系统能够查看实际页面，另一个系统只能生成文件，那么比较得到的是不同工作流的表现，而不只是模型能力差异。

因此，应明确每个系统可使用的工具、可访问的资源，以及是否允许外部检索。

3. 明确资源预算的公平口径

“时间相同”“调用次数相同”和“费用相同”并不等价。

固定时间适合观察单位时间的交付效率；固定费用适合比较预算约束下的有效产出；固定调用次数便于分析交互过程，但不能保证实际计算资源一致。

评估报告应说明采用哪一种口径，不宜将不同预算条件下的结果直接合并排名。

4. 固定修复规则

可以约定首版提交后只允许一轮集中修复，但必须定义“一轮”的边界：从统一反馈下发开始，到再次提交可验收版本结束。

反馈应描述可复现的现象，例如“窄屏下地图区域高度接近零”，而不是直接提供修改后的代码。这样既能保证问题信息对称，也能保留对诊断能力的考察。

五、将首版能力与闭环能力分开评分

如果只看最终结果，容易掩盖首版质量和修复成本。

一个系统可能首次交付就接近可用，另一个系统则依赖浏览器检查完成关键修补。两者最终都通过，并不代表交付风险相同。

建议至少记录三组结果：

首版结果：首次提交时，功能通过多少，是否存在阻断性错误，视觉和移动端适配处于什么水平。

修复结果：收到统一反馈后，是否定位了根因，是否真正解决问题，是否引入新的回归。

交付结果：最终版本是否满足验收标准，完成过程中消耗了多少时间、调用资源和人工操作。

这种分层记录可以区分“首次生成质量高”和“反馈修正能力强”两种不同优势，也能避免将大量人工辅助误计为系统自身能力。

六、浏览器闭环应检查真实行为

浏览器验证不应退化为截图欣赏。截图能发现布局问题，却不能证明业务逻辑正确。

1. 布局检查

至少覆盖具有代表性的宽屏和窄屏尺寸，并检查：

• 地图、图表和播放器是否具有有效尺寸；
• 标题与正文是否存在截断或遮挡；
• 长文本是否导致布局溢出；
• 浮动控件是否挡住主要内容；
• 页面是否出现非预期横向滚动。

例如，地图区域高度异常，可能与父容器尺寸未确定、百分比高度缺少参照，或布局压缩有关。修复时应沿容器尺寸链查找原因，而不是只增加一个任意高度来掩盖问题。

2. 交互检查

采用固定操作序列，比随机点击更容易复现：

进入页面，选择地点，启动播放，切换音频，加入收藏，打开收藏列表，刷新页面，再移除收藏。

每一步都应记录预期状态，并检查相关组件是否同步。对于数据叙事页面，则应检查年份、图表标记、数值卡片和解释文字之间的一致性。

3. 异常检查

还应验证资源加载失败、空收藏列表、无效本地记录等情况。

异常状态不是附加装饰，而是产品完整性的一部分。一个只在理想路径下正常运行的页面，不能等同于稳定可交付的应用。

七、视觉质量要有量表，也要保留审美判断

视觉评价无法完全客观化，但可以通过拆分维度降低随意性。

可采用以下维度：

• 信息层级：主要内容与次要说明是否容易区分；
• 阅读节奏：页面是否具有合理的疏密变化；
• 视觉一致性：字体层级、颜色、间距和控件风格是否统一；
• 参考约束符合度：是否理解参考图的布局逻辑，而不是机械复制表面元素；
• 响应式完整性：移动端是否重新组织内容，而非简单缩小；
• 可访问性：对比度、键盘操作、焦点反馈和媒体说明是否合理。

为降低名称和先验印象的干扰，可以采用匿名评审，并随机排列展示顺序。评审者应同时查看页面运行结果和交互过程，不能只依据经过挑选的首屏截图给分。

八、成本与速度必须建立在验收通过之上

低成本或短耗时本身不代表高效率。如果页面没有完成核心功能，生成得再快，也不能视为有效交付。

建议分别记录：

• 首版可运行时间；
• 首版核心功能通过时间；
• 修复后的最终通过时间；
• 模型调用成本；
• 构建、运行与检查资源成本；
• 人工检查和干预时间。

一种便于理解的统计方式是：

有效任务平均成本＝评估范围内的总成本÷通过验收的任务数量。

使用这一指标时，需要同时报告通过率和任务难度。若通过任务数量为零，就不能继续使用该公式得出有意义的平均成本，更不能忽略失败任务的投入。

时间统计也应区分模型生成、依赖准备、页面构建和浏览器检查。否则，缓存状态或网络波动可能被误判为模型执行效率的差异。

九、从一次演示走向可复现评估

一次实验只能说明特定任务、环境和预算条件下的表现，不能直接代表所有设计任务中的稳定能力。

更可靠的评估应保留需求版本、素材清单、运行配置、操作轨迹、截图、错误记录和最终文件，并对代表性任务开展多次独立运行。

分析时不仅要看平均表现，还要关注波动和失败方式。例如，某类系统可能偶尔生成非常出色的视觉方案，却经常出现状态同步错误；另一类系统可能视觉变化较小，但交付结果更稳定。对于企业应用，稳定性往往与平均质量同样重要。

最终报告应回答四个问题：系统完成了什么，在哪些条件下完成，付出了多少资源，以及仍然存在哪些风险。

多模态设计能力的真正分水岭，不是能否生成漂亮页面，而是能否把视觉判断转化为正确实现，并在真实运行反馈中持续收敛。只有将输入、工具、预算、验证和人工介入都纳入评估，才能得到对开发者和企业用户真正有价值的结论。