多模态模型设计页面生成的公平评测教程

一、教程目标：把“能看图”变成“能做设计”

当一款支持视觉输入的模型发布后，很多人的第一个动作是丢一张图过去，看它能不能读出文字、描述画面。这一步只完成了验证链路的起点：识别（perception）。而真实的设计工程要求的是后两层能力：

• 理解：读懂信息层级、栅格与留白、空间关系、色彩与品牌气质，并能说清“为什么这样排”；
• 产出：把判断翻译成可运行的结构化代码（HTML/CSS 与轻量脚本），并在自身输出上完成自检与修复。

本教程要完成的最终任务是：读者可以独立搭建一套可复现的横向评测流程，对多款支持视觉输入的大模型在同一设计任务上的表现做公平对比，并输出一张包含“首版通过率、修复轮次、耗时、成本、缺陷类型分布”的结论表。

公平性的核心是四件事：同一份设计基线、同一批素材、同一套工具权限、同一轮修复机会。任何一项漂移，结论就不再可比。

二、适用读者与适用场景

读者	关注点
前端/客户端开发者	生成代码的可运行性、响应式正确性、无障碍合规
算法/平台工程师	评测链路的可复现性、自动化程度、成本与时延采集
技术负责人	选型依据、单位任务成本、稳定性与风险边界
企业应用落地方	素材合规、数据脱敏、评测结论的可审计性

典型场景包括：多模态模型选型、设计稿转代码流水线（design-to-code）能力评估、企业内部设计规范基线下的自动化生成评测、以及持续回归（每次模型版本更新后重跑同一套任务集）。

三、为什么必须先定义“能力分层”

如果不先把评估维度写死，评测很容易退化成主观印象。建议固定三层能力，每层对应可观测证据：

层级	能力定义	可观测证据
识别层	读出图中的文字、组件、色彩	结构描述准确度、颜色取样偏差
判断层	说明信息层级与视觉权重	层级排序是否与设计意图一致、栅格是否对齐
产出层	生成可运行页面并自检	页面渲染结果、控制台报错、修复前后的差异

只有产出层的证据能被脚本自动采集，评测才具备可复现性。因此本教程把“截图 + 断言脚本”作为主要证据来源，把模型自述作为辅助解释，而不是结论本身。

四、前置准备

4.1 环境与依赖

• 一个可控的本地或容器化运行环境，用于渲染模型生成的页面；
• 一套浏览器自动化能力（无头/有头均可），支持多视口截图、DOM 求值、控制台与网络错误捕获；
• 统一的 HTTP 接入层，屏蔽不同模型供应商的协议差异（这一点最关键，见 4.2）；
• 对象存储或本地目录，用于保存输入素材、模型输出、截图与日志；
• 一台计时准确的执行机，用于记录墙钟时间（wall-clock）与并发度。

如果团队已有云上基础环境，可以直接复用通用能力类别，例如对象存储（存放素材与截图产物）、容器平台（跑隔离的渲染沙箱）、日志服务与监控告警（采集错误率与耗时分布）、身份认证（管理访问密钥）。若已经在百度智能云上具备这些基础服务，评测框架可以落在同一账号体系内，减少跨域同步与权限配置成本。

4.2 被评测对象的登记与归一化

不要直接在业务代码里硬编码不同供应商的调用方式。先建一张模型登记表：

[
  { "id": "model-a", "vision": true,  "tools": ["browser"], "params": { "temperature": 0.2, "max_output_tokens": 8192 } },
  { "id": "model-b", "vision": true,  "tools": ["browser"], "params": { "temperature": 0.2, "max_output_tokens": 8192 } },
  { "id": "model-c", "vision": true,  "tools": ["browser"], "params": { "temperature": 0.2, "max_output_tokens": 8192 } }
]

登记表的作用有三个：一是采样参数一致，温度、最大输出长度必须相同，否则随机性会成为混淆变量；二是工具权限一致，如果 A 能截图而 B 不能，就不再是同一场比赛；三是可回溯，任何一次结论都能定位到确切的模型标识与参数。

4.3 素材与设计系统基线冻结

这是最容易被忽略、但对结论影响最大的一步。需要冻结的资产包括：

1. 素材集：图片、Logo、图标、占位文案，打上版本号（如 assets-2026.09），并记录每个文件的尺寸与授权来源；
2. 设计规范快照：色板、字阶、间距刻度、圆角、栅格列数、断点定义，导出为机器可读的设计令牌（design token）文件；
3. 品牌气质描述：一段 50～100 字的文字约束，例如“克制、留白充足、以文本层级承担视觉重量”。

冻结的原则是只读：任务开始后，任何人不得替换素材或调整令牌，否则必须先作废本轮全部结果。

4.4 浏览器验证环境

至少准备两个视口：桌面 1440×900 与移动 390×844。除此之外，固定浏览器内核版本、设备像素比（DPR=1 或 2 需注明）、字体加载方式（避免本地字体缺失导致排版差异）。

4.5 指标与记录表定义

建议的最小指标集：

• 首版通过率：未经过任何修复即满足通过标准的任务比例；
• 修复轮次：达到通过标准所需的迭代次数（上限 1 轮）；
• 墙钟耗时：从发出请求到最终产物通过校验的时间；
• 单位任务成本：按输入/输出 token 与图片计费口径折算的人民币金额；
• 缺陷类型分布：溢出、截断、层级错乱、交互失效、控制台报错、无障碍问题；
• 代码质量项：是否有语义化标签、是否可访问（对比度、焦点可见、替代文本）。

五、任务集设计：三个任务覆盖三层能力

任务本身要能区分模型，所以必须同时包含判断难度与实现难度。推荐三个递进任务：

任务一：信息层级重构。 给一张信息密集的后台列表截图，要求生成结构等价、层级一致的页面。考察点是：能否正确识别主次、分组与密度关系，并用合适的字号/字重/间距表达，而不是把文字平铺成等权重块。

任务二：品牌气质落地。 给一张移动端品牌页截图 + 一段气质描述，要求生成符合色板与字阶约束的响应式页面。考察点是：色彩取样准确度、栅格对齐、留白比例，以及在移动视口下不破坏版式。

任务三：带状态的完整产品页。 给多张不同状态的截图（默认、加载中、空态、错误态），要求生成可交互页面。考察点是：状态机完整性、交互反馈、空态文案设计、以及桌面与移动双视口下的一致性。

每个任务必须附带明确的通过标准，否则无法判定“是否通过”：

通过标准（示例，任务二）
[ ] 色板命中：抽样 6 个品牌色，与基线偏差 ΔE < 髅 threshold 内
[ ] 栅格对齐：所有主要容器左边缘对齐至 8px 刻度
[ ] 层级正确：H1 字号 > 卡片标题 > 正文，且字重递增
[ ] 无溢出：桌面与移动视口下无横向滚动条
[ ] 无截断：所有文本节点未被裁剪，无省略号以外的意外截断
[ ] 控制台无 error 级别报错
[ ] 无障碍：正文对比度 ≥ 4.5:1，交互元素具备可见焦点态

六、实施步骤

步骤 1：冻结基线并建立隔离执行环境

做什么：将 4.3 中的素材与令牌打包，写入版本清单文件；创建干净的渲染沙箱目录。

为什么：确保所有模型面对的是同一份“事实”。这一步不做，后续任何差异都无法归因。

注意：沙箱内禁止联网加载外部字体与 CDN 资源，改为本地注入，避免网络波动污染排版结果。

步骤 2：统一提示词与输出协议

做什么：为每个任务写一份固定提示词，包含四段结构：角色与目标、约束条件（引用令牌文件名）、交付要求（单文件 HTML + 内联样式 + 必要的轻量脚本）、自检要求（生成后列出可能的溢出/截断风险点）。所有模型使用逐字相同的提示词与素材顺序。

为什么：提示词是模型之间最大的隐性差异来源。逐字一致才能保证对比有效。

注意：提示词里不要写“请参考某品牌的风格”，而要把风格拆成可测量的约束（具体色值、间距数值、字号区间）。

步骤 3：首版生成并记录过程数据

做什么：调用各模型产出首版页面，同时记录：请求时间戳、输入 token 数、输出 token 数、图片张数与尺寸、工具调用次数、是否触发了浏览器工具、返回耗时。

为什么：这些是成本模型与“能力画像”的原始数据。尤其“是否依赖浏览器闭环”这个特征，只能靠工具调用日志判断，不能靠事后回忆。

注意：并发发起时，建议错开请求或使用独立限流配额，避免供应商侧的速率限制导致重试次数虚高，进而扭曲成本与耗时。

步骤 4：视觉回看与自动化校验

做什么：渲染首版产物，在两个视口下截图，并运行断言脚本：

// 通用伪代码：视口截图 + 溢出与截断检测
const VIEWPORTS = [
  { name: "desktop", width: 1440, height: 900 },
  { name: "mobile",  width: 390,  height: 844 },
];
for (const vp of VIEWPORTS) {
  await page.setViewport(vp);
  await page.goto(renderUrl);
  await page.evaluate(() => document.fonts.ready);
  await page.screenshot({ path: `shot-${vp.name}.png`, fullPage: true });
  const issues = await page.evaluate(() => {
    const out = [];
    const de = document.scrollingElement;
    // 1. 横向溢出
    if (de.scrollWidth > window.innerWidth + 1) {
      out.push({ type: "overflow-x", delta: de.scrollWidth - window.innerWidth });
    }
    // 2. 文本截断 / 意外裁剪
    for (const el of document.querySelectorAll("*")) {
      const style = getComputedStyle(el);
      if (style.overflow === "hidden" && el.scrollHeight > el.clientHeight + 1) {
        out.push({ type: "text-clipped", tag: el.tagName, cls: el.className });
      }
      // 3. 元素越出视口右边界
      const r = el.getBoundingClientRect();
      if (r.width > 0 && r.right > window.innerWidth + 1) {
        out.push({ type: "element-out-of-view", tag: el.tagName, right: r.right });
      }
    }
    return out;
  });
  record(`${taskId}-${modelId}-${vp.name}`, { issues, shot: `shot-${vp.name}.png` });
}

为什么：截图是“人眼可复核”的证据，断言脚本是“可统计”的证据，两者必须同时具备。

注意：fullPage 截图会改变视口高度语义，判断“视口内首屏是否正确”时要额外截一张非全页图。

步骤 5：一轮修复与差异比对

做什么：把步骤 4 的 issues 列表和两张截图回传给模型，允许其修复一轮，然后重跑步骤 4。

为什么：真实工程中，模型的“自我修正能力”比“一次做对”更重要，但两者要分开计分，不能合并成一个“通过率”。

注意：修复提示必须统一模板，例如“以下为校验发现的问题清单与截图，请仅修复这些问题，不要重写整体结构”。同时记录修复后的文件差异行数——差异越小，说明首版质量越高。

步骤 6：结果判定

按任务通过标准逐项判定，记录首版通过 / 修复后通过 / 未通过三态，并附上失败项的具体证据（截图区域 + 断言输出）。

步骤 7：汇总与成本折算

做什么：把过程数据汇总为对比表。

指标	模型 A	模型 B	模型 C
首版通过（3/3 任务中）	3	2	2
修复后通过	3	3	3
平均修复轮次	0.0	0.7	0.3
是否需要视觉闭环	否	是	部分
平均墙钟耗时	中	较慢	最快
三任务总成本	较高	中	约 1 元多人民币量级
主要缺陷类型	少量样式偏差	状态缺失	语义化标签偏弱

成本折算公式（通用口径，务必注明计费单位与是否含税）：

总成本 = Σ_over_tasks Σ_over_rounds ( 输入token × 输入单价 + 输出token × 输出单价 )
        + Σ 图片计费（按张或按图像 token 折算，取供应商实际口径）
        + 重试与修复轮次产生的额外调用

注意：以上数据来自一次小规模实验，样本量仅 3 个任务、单次运行，不具备统计显著性。它的价值在于方法可复现，而不在于排名结论本身。要做选型决策，必须把任务集扩到 15～30 个，并重复 3 次以上取分布。

七、配置说明

把评测参数外置为配置，避免改代码导致基线漂移：

evaluation:
  version: "eval-2026.09"
  baseline:
    design_tokens: "tokens-v1.json"
    assets: "assets-2026.09"
  sampling:
    temperature: 0.2
    max_output_tokens: 8192
    top_p: 1.0
  tools:
    browser: true          # 全部模型必须一致
    allow_network_fetch: false
  iteration:
    max_fix_rounds: 1
    fix_prompt_template: "fix-only.prompt"
  viewports:
    - { name: "desktop", width: 1440, height: 900 }
    - { name: "mobile",  width: 390,  height: 844 }
  pass_criteria:
    min_passed_items: 7
    contrast_ratio_min: 4.5
  records:
    store: "object-storage"
    keep_screenshots: true

字段风险提示：

• temperature 越低越稳定，但过低会削弱创意型设计任务的表现，建议在对比表中固定并说明；
• max_output_tokens 过小会人为制造截断，使成本对比失真；
• allow_network_fetch: false 用于消除外部资源加载差异，但若你的真实场景需要远程字体，则应放开并在报告中标注；
• keep_screenshots 关闭会失去人工复核能力，建议保留至少一轮产物。

八、结果如何解读：三种典型画像

评测跑完后，不要只写“谁更好”。更有价值的是识别能力画像：

画像一：首版稳定性强。 一次生成的代码结构清晰、层级正确，修复轮次为 0。适合追求低干预、快速出稿的场景，但单位任务成本通常更高。

画像二：强依赖视觉闭环。 首版缺陷较多，但拿到截图后能准确定位并修复，最终产物完成度最高。适合允许“生成—截图—修复”自动闭环的流水线；如果生产环境拿不到截图回传能力，它的优势会大幅缩水。

画像三：成本与时延优先。 单价低、响应快，在简单到中等复杂度任务上性价比突出；缺陷多集中在语义化与细节规范上，需要通过设计令牌约束和后置校验补齐。

选型建议：先按任务复杂度分层，再匹配模型。简单模板类任务用低成本模型批量跑，复杂交互页面走带视觉闭环的链路，关键页面保留人工复核。任何单一模型都不应被默认用于全部层级。

九、常见问题与排查

现象	可能原因	排查思路
不同模型成本差异异常大	输出长度未归一化、重试次数不均	对比 max_output_tokens 实际消耗与实际输出 token，检查是否被截断后重试
同一模型两次结果差异很大	采样参数不一致或供应商默认值变更	固定 temperature，记录每次调用返回的参数回显
桌面正常、移动端溢出	缺少断点处理、固定宽度单位	在断言脚本里增加 document.scrollingElement.scrollWidth 对比，定位具体越界节点
截图与人工判断不一致	字体未加载完成、动画未结束	增加 document.fonts.ready 与稳定等待（如连续两帧一致再截图）
控制台报错但无视觉异常	资源 404、脚本作用域冲突	同时采集 console 与 network 两类事件，分开统计
结论无法复现	素材或令牌被改动	用版本清单校验哈希，发现不一致即作废本轮

十、优化建议

• 性能：并行渲染多个视口、复用浏览器实例、对产物做哈希去重，避免同一页面重复截图；
• 成本：把任务分层，简单任务走小参数模型；在提示词中明确“最小可行实现”，抑制过度生成；对修复轮次设置硬上限，防止成本失控；
• 稳定性：所有断言脚本版本化，与评测配置一起入库；每次运行保存原始 JSON 日志，保证可回溯；
• 可维护性：接入层用统一抽象封装不同供应商协议，新增模型只需在登记表中追加一行；
• 安全与合规：素材必须去标识化，避免把真实用户数据、内部设计稿或密钥带入提示词；密钥放环境变量或密钥管理服务，不写入仓库；产物截图若含敏感信息，需设置存储访问策略与保留期限；
• 可扩展性：把评测接入持续集成，在模型版本更新时自动重跑基线任务集，形成趋势曲线而非单点结论。

十一、总结

这套教程的关键不在于“测出谁赢”，而在于把设计能力评测变成可复现的工程流程：冻结素材与设计令牌、逐字统一提示词、统一工具权限与采样参数、用截图加断言脚本采集客观证据、限制修复轮次、并按成本与耗时折算总代价。

回顾核心步骤：定义三层能力与通过标准 → 冻结基线 → 统一接入层 → 首版生成并记录过程数据 → 双视口截图与自动化校验 → 一轮修复与差异比对 → 汇总成本与时延 → 输出能力画像与选型建议。

后续可以继续推进的方向：把任务集从 3 个扩展到覆盖多类版式的基准集、引入像素级差异与视觉相似度指标、增加无障碍自动检测项、以及对修复策略本身做 A/B 实验，观察“多轮轻修复”与“单轮重写”在总成本与最终质量上的取舍。