用 Gemini 3.5-flash 做 UI 截图审查：从多模态识别到前端设计建议落地

凌晨准备提测时，前端同学最怕什么？不是接口慢半拍，而是页面截图发到群里后，设计师一句“这里间距不对”“按钮层级有点乱”，然后大家开始逐像素来回确认。UI 审查本质上是“看图、理解、判断、给建议”，非常适合交给多模态模型先跑一轮初筛。如果你想快速体验 Gemini、ChatGPT、Claude 等模型的图文能力，可以试试 KULA 镜像平台 （https_传://ouai^送.me_门），只需常规注册即可在线使用，适合做截图识别、提示词调试和方案验证。

1. 为什么 UI 截图适合交给多模态模型？

传统 UI Review 主要依赖人工经验：看视觉层级、看对齐、看留白、看交互状态是否完整。问题是，人工审查容易受到时间、情绪、上下文信息影响。

而 Gemini 3.5-flash 这类多模态模型，可以直接读取界面截图，并结合提示词完成几类任务：

• 识别页面结构：导航、卡片、按钮、表单、弹窗等；
• 判断视觉问题：对齐、间距、字号、颜色对比度；
• 输出设计建议：按优先级给出可执行修改方案；
• 辅助前端定位：把问题描述转成 CSS 或组件调整建议；
• 生成验收清单：帮助团队形成稳定的 Review 标准。

它不能替代设计师，但非常适合做“第一轮 UI 体检”。尤其在迭代频繁的管理后台、移动端活动页、数据看板里，效率提升会比较明显。

2. 推荐的 UI 审查流程

一个可落地的流程可以分成四步。

第一步，前端或测试上传当前页面截图。建议截图保持完整，不要过度裁剪。如果是长页面，可以按首屏、核心区域、底部区域分别截图。

第二步，把截图交给多模态模型，并附上页面背景说明。例如“这是一个 SaaS 管理后台的订单列表页，目标用户是运营人员，需要重点检查信息密度和操作效率”。

第三步，让模型按固定格式输出结果。不要只问“这个页面怎么样”，这样答案会比较散。更推荐让它从布局、视觉层级、交互状态、可访问性、前端实现五个维度分析。

第四步，前端根据建议分类处理。比如“立即修改”“设计确认”“下个版本优化”。这样不会让 AI 建议变成新的噪音。

3. 一条好用的提示词模板

多模态模型的能力上限很高，但输出质量很依赖提示词。下面这个text模板适合做日常 UI 截图审查：

你是一名资深 UI/UX 设计评审专家和前端工程顾问。
请基于我上传的界面截图进行审查，输出要具体、可执行。

页面背景：
- 页面类型：{例如：管理后台订单列表页}
- 用户角色：{例如：运营人员}
- 主要目标：{例如：快速筛选订单并处理异常状态}
- 设计风格：{例如：简洁、偏企业级、信息密度适中}

请从以下维度分析：
1. 页面结构是否清晰；
2. 视觉层级是否合理；
3. 间距、对齐、留白是否存在问题；
4. 按钮、表单、标签、状态色是否易理解；
5. 是否存在可访问性问题，例如对比度不足、字号偏小；
6. 从前端实现角度，给出 CSS 或组件层面的优化建议。

输出格式：
- 总体评分：1-10 分
- 主要问题：按优先级列出
- 修改建议：每条建议包含“问题位置、原因、建议做法”
- 前端落地建议：给出可执行方案
- 验收清单：列出 5 条检查项

这个模板的关键在于：给角色、给背景、给维度、给格式。模型越清楚你的目标，越不容易输出泛泛而谈的内容。

4. Node.js 示例：上传截图并获取 UI 建议

华为云开发者社区的读者多半更关注“怎么接到工程里”。下面用 Node.js 写一个简化示例：读取本地截图，把图片转成 base64，再发送给多模态模型接口。

不同平台的接口字段可能略有差异，下面代码重点展示工程思路，实际接入时按你所使用的服务文档调整。

js

import fs from "node:fs";

const API_KEY = process.env.MODEL_API_KEY;
const API_URL = process.env.MODEL_API_URL;

function imageToBase64(path) {
  const buffer = fs.readFileSync(path);
  return buffer.toString("base64");
}

async function reviewScreenshot(imagePath) {
  const base64Image = imageToBase64(imagePath);

  const prompt = `
你是一名资深 UI/UX 设计评审专家和前端工程顾问。
请分析这张 UI 截图，并从布局、视觉层级、间距、可访问性、前端实现五个维度给出建议。
输出要具体，不要只说“优化体验”。
请按以下结构输出：
1. 总体评价
2. 高优先级问题
3. 中低优先级问题
4. 前端落地建议
5. 验收清单
`;

  const response = await fetch(API_URL, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "gemini-3.5-flash",
      messages: [
        {
          role: "user",
          content: [
            { type: "text", text: prompt },
            {
              type: "image_url",
              image_url: {
                url: `data:image/png;base64,${base64Image}`
              }
            }
          ]
        }
      ],
      temperature: 0.3
    })
  });

  if (!response.ok) {
    throw new Error(`Request failed: ${response.status}`);
  }

  const data = await response.json();
  return data;
}

reviewScreenshot("./screenshots/order-page.png")
  .then(result => {
    console.log(JSON.stringify(result, null, 2));
  })
  .catch(err => {
    console.error(err);
  });

这里建议把 temperature 设置低一些，比如 0.2 到 0.4。UI 审查不是创意写作，更需要稳定、严谨、可复现的结果。

5. 如何让 AI 的建议更像“设计评审”？

很多人第一次使用截图识别，会觉得模型说得挺对，但落地价值一般。原因通常不是模型不行，而是输入信息太少。

例如同一张页面，如果不说明业务目标，模型可能只会评价“页面信息较多”。但如果告诉它“这是客服处理工单的高频页面，用户每天要操作 6 小时”，它就会更关注信息密度、操作路径和疲劳感。

建议给模型补充三类上下文：

• 业务目标：页面要帮助用户完成什么任务；
• 用户特征：新手多还是专家多，使用频率高不高；
• 约束条件：是否必须遵循现有设计系统，是否要兼容移动端。

比如分析一个数据看板，可以加上：“该页面用于运营晨会投屏展示，核心指标需要 3 秒内被识别。”这样模型就会优先检查主指标是否醒目，而不是纠结一些次要按钮样式。

6. 输出结果如何进入团队协作？

AI 给出的建议最好不要直接等同于最终结论。更稳妥的做法，是把它当成“候选问题列表”。

可以在团队里设计一个轻量流程：

1. 前端提交页面截图；
2. 自动触发 UI 截图审查；
3. 生成 Markdown 报告；
4. 设计师确认关键问题；
5. 前端按优先级修改；
6. 测试根据验收清单回归。

如果项目已经有 CI 流程，也可以把截图审查放在预览环境之后。比如每次合并到测试分支，自动截取关键页面，然后生成审查报告。但要注意，不建议把 AI 评分直接作为阻断发布的硬条件。更合理的方式是提醒和辅助。

7. 前端落地时重点关注哪些问题？

从实际经验看，多模态模型对以下问题识别比较稳定：

第一，视觉层级混乱。
例如标题、说明文字、按钮权重接近，用户不知道先看哪里。前端可以通过字号、字重、颜色透明度、间距来调整。

第二，间距不统一。
比如卡片之间是 20px，表单项之间是 18px，按钮和输入框之间又是 13px。这类问题肉眼不一定马上发现，但模型会给出趋势性判断。前端可以用设计 token 或 spacing scale 统一。

第三，状态表达不清。
比如成功、警告、失败都只靠颜色区分，或者禁用态按钮不够明显。这里可以补充图标、文案和 hover 提示。

第四，移动端适配风险。
模型能从截图中推断某些区域在小屏下可能拥挤，但最终还需要前端用真实断点验证。

第五，可访问性问题。
比如浅灰文字放在白色背景上，对比度不足。建议结合工具进一步校验，不要只依赖视觉判断。

8. 一个可复用的报告格式

为了让审查结果进入研发流程，可以统一成 Markdown：

# UI 截图审查报告

## 页面信息
- 页面名称：
- 截图时间：
- 版本分支：
- 审查范围：

## 总体评分
- 评分：
- 一句话结论：

## 高优先级问题
| 位置 | 问题 | 影响 | 建议 |
| --- | --- | --- | --- |
| 顶部筛选区 | 控件间距不一致 | 降低扫描效率 | 使用统一 8px 栅格 |

## 前端修改建议
- 调整 `.filter-bar` 的 gap 为 16px；
- 主按钮使用统一组件尺寸；
- 状态标签补充 icon 与 title 提示。

## 验收清单
- [ ] 首屏主任务是否清晰
- [ ] 主要按钮是否突出
- [ ] 表单控件是否对齐
- [ ] 文字对比度是否足够
- [ ] 移动端断点是否验证

这样的报告更容易被复制到需求卡片、缺陷单或合并请求评论里，也方便后续追踪。

9. 使用边界：AI 能看图，但不能替你拍板

最后要强调一点：Gemini 3.5-flash 这样的多模态模型适合做效率工具，而不是最终裁判。

它能帮你发现“可能的问题”，也能给出“可参考的修改方向”。但设计系统规范、品牌调性、业务优先级、研发成本，仍然需要团队判断。

比较理想的状态是：
AI 负责快速扫一遍，设计师负责专业取舍，前端负责工程落地，测试负责验收闭环。

当 UI Review 从“凭感觉讨论”变成“截图输入、结构化输出、清单化修改”，团队沟通成本会明显下降。对于前端和设计同学来说，这不是少做一步，而是把重复检查交给工具，把注意力留给真正需要判断的地方。

注：本文配图由ChatGpt Image-2 辅助生成。

【本文完】