告别逐像素比对——UI走查自动化的完整落地实践

大脸包纸

杭州/设计爱好者/6天前/379浏览

版权

大脸包纸

哈哈，写这篇文章的时候才发现，距离上次更新已经365+天了...

没跑路哈，还在 AI 这条路上，只是换了个坑位继续搞设计。新东家2026年的口号就是“AI first” ，目前公司内部从产品到运营，已实现全民工作AI化。

好了，开聊正事。本次就是分享一下，我认为用AI帮助工作提效的工作流程- UI走查。

一、起念：被重复劳动困住的设计师

每个做过 UI 走查的设计师都懂这种痛苦。

版本发布前一周，你打开设计稿，再打开研发给的测试包。左手是 Figma，右手是产品页面。你开始逐页比对：登录页的按钮圆角是不是 16px？首页卡片的内边距偏差了几个像素？设置页的标题字重是不是 Medium？

iOS 端、安卓端、Web 端、桌面端...一个页面 2-5 分钟，遇到大版本几百个页面看下来，再一个个标注问题、一条条放到云效，一两天时间就过去了。更麻烦的是，走查这件事不会只有一次。同一个页面在迭代周期内可能被走查两到三轮。研发改完、一轮反馈后，你得把所有页面再从头看一遍，确认之前的问题改对了、没有引入新问题。

这还只是 UI 视角。换到研发视角也一样痛苦。

设计师给的反馈是截图，上面画了红框写了字。研发同学收到后，要对着图片找代码位置，再回头确认"这个颜色到底用哪个？像素偏差了多少？改成什么值？"问题描述如果比较模糊——"这里的间距好像不对"——哪里的间距？设计稿是多少？实现是多少？合法的档位是哪个？问题会来回多轮，效率低下。

而这些问题的本质是什么？

走查这件事，80% 的工作量是规则驱动的，就像你去菜市场买菜，每次都拿同一把尺子量茄子的长度——尺子没变、标准没变，但你得一个个量过去。

我一直在想能不能让 AI 来做这件事？

圆角在不在 9 个合法档位里？间距在不在 14 个合法档位里？深浅模式的颜色使用是否规范？这些规则公司的Design System 早就定义好了。完全可以利用skill总结规范，走查时对应到每个页面上，把这个机械、重复的工作交给 AI 。

二、破局：一个 Skill 引发的连锁反应

一开始我只是尝试性地截图发给 AI，让它来分析设计图和开发稿的区别。但因为没有一套完整的走查逻辑，再聪明的 AI 也无从下手。它只能从头到尾分析两张图片所有的差异点。连文案不一致、截图尺寸不同导致的元素位置偏移都被一一标注出来，一个页面能总结出一二十个问题。但真正有意义的却不到30%。

直到有一天我看到了一篇设计分享文章。作者也是一位设计师，被走查折磨后决定用 AI 破局。他的核心思路很朴素，加一句提示词：让 AI 走查时明确

忽略文字和图片内容差异，只关注样式还原度。然后再整理一套“

规则”，写成一个 Skill，再把自家设计规范（Design Token）注入进去，AI 就能按项目标准精准检查。他把 Skill 模板开源在了 GitHub。

我拿了作者的 Skill 模板，初步尝试了一下。发现，光是加了这一句提示词，误报率就降了 80%。但他的提供的只是一个很简易的常规模版，无法支持高精准的页面走查。而我们团队最近也已经沉淀出了一份完整的 Design Skill，目前更新了36 个文件（覆盖了 color-system、typography-system、spacing-grid、radius-elevation、iconography、component-library-map 等等）。

我把这套公司设计体系作为专属知识底座输入模型，让 AI 完整学习并适配内部规范，最终梳理输出全新文档《本公司版 - UI 走查 Skill.md》。

自此，团队全员可以使用这份统一的 Skill 文件开展 AI 自动化走查，所有人将共用同一套校验基准，彻底解决以往巡检标准不统一、判定口径混乱的问题。

告别逐像素比对——UI走查自动化的完整落地实践（图ZMTU3Mzk3NDg=） - 观点 - 站酷设计师大脸包纸原创素材 - 站酷ZCOOL

AI针对设计稿+实现截图输出的原始报告

Skill 调优后，走查报告的输出质量大大提升：

.md文件无法在线预览，见附件

除此之外，新版 skill 还重新定义了问题严重程度的判定逻辑。问题不再凭感觉区分"高/中/低"优先级，而是两维评分：

视觉感知度 × 功能影响度

。

能 3 秒内看出来但不影响功能 → 中。
需要叠图精确测量才发现的 → 低。
影响到操作路径或品牌视觉的 → 高。
而且全局性问题（同一问题在页面多处重复出现）自动提升一级。

这两步做完后，AI 走查的输出开始有了"viaim 味"。每个问题不再说"间距不对"，而是说"内边距 18px，不在 viaim 14 档间距内，最近合法档位为 16px 或 20px"。不再是模糊的判断，而是可以直接丢给研发执行的修改指令。

三、展现形式优化：从 .md 到 HTML 报告

AI 能输出合格的走查内容了，但展现形式还是个问题。最初生成的是 Markdown 文本，虽然结构清晰，但阅读体验一般。几十条问题拉下来很容易看花眼。而且对图片的支持度不够。

相关文章分享：https://claude.com/blog/using-claude-code-the-unreasonable-effectiveness-of-html

我们为何不试试 HTML 格式呢？这才是能被人长期阅读并接受的东西呀～

HTML 带来的改变是全方位的：

结构化的页面布局-可读性更好：
报告的问题按优先级分组，用卡片承载所有信息。再也不用在几百上千行文字里翻，一眼扫过去就知道哪里严重。
截图标注-md无法完成的功能：
增加截图手动上传和标注的功能。这样不改变之前的走查习惯，标注后的截图嵌入报告中，研发同事看到的不只是文字描述，还有可视化标记。
删除和筛选功能-更高效的编辑报告内容：
在实际工作中，不是所有发现的问题都值得推到云效。有些可能是误判，有些可能优先级太低，有些可能需要和产品先讨论。有了多选和删除功能，在推送之前我们可以先手动过一遍，去掉不需要的问题条目。
可视化的一键推送按钮：
筛选好需要推送的问题后，可以点击按钮一键推送，整个过程清晰可视，不黑盒。

告别逐像素比对——UI走查自动化的完整落地实践（图ZMTU3Mzk3NTI=） - 观点 - 站酷设计师大脸包纸原创素材 - 站酷ZCOOL

html格式的走查报告

从 Markdown 到 HTML，看起来只是格式变了，但背后解决的是工作流问题：

走查不只是"发现问题"，还要"呈现问题"和"筛选问题"。

HTML 让这三步能在一个页面里完成。

当然，这些功能都是让 Claude 给实现的～你只需要在终端工具里和它对话解决功能性的落地问题（这里不展开如何使用cc这些AI工具的问题）。

四、中间过程：半自动推送，完成流程最小闭环

走查做得再好，如果问题进不了研发的工作流，前面的一切都是自嗨。

这是整个项目最难的一步，也是最关键的一步。

项目前期我已经初步实现了推送的半自动化，需要每次推送时在前端页面手动按 F12 复制 Cookie 和 CSRF Token 给AI，它再帮我推送过去。

虽然半自动已经能跑通闭环，但说到底是”人机配合”——每次推送前还得手动去浏览器拿 Cookie。走查一多，这个”最后一公里”反而成了新的瓶颈。必须要让这一步也自动化！

五、迭代：从能用到好用

路径都跑通了，接下来就是让走查体验从"能用"到"好用"的打磨了。

5.1 利用AI搞定全自动推送

完成缺陷自动推送目标：在 HTML 报告里勾选问题 → 点一下"推送"按钮 → 缺陷自动创建在云效对应项目里。

听起来很简单，但这个"点一下推送"功能 AI 前后帮我试了不下 20 种请求格式、3 套认证方案、4 种图片嵌入方式，累计消耗了约 40 万 Token （claude给我总结的数据）才把这最后一步彻底跑通。云效的 API 文档几乎为零——没有公开的接口说明，没有标准的认证方式，创建缺陷的 Payload 字段全靠试。如果没有AI，我这个技术小白是绝不可能解决这个专业性问题的。

告别逐像素比对——UI走查自动化的完整落地实践（图ZMTU3Mzk3NTY=） - 观点 - 站酷设计师大脸包纸原创素材 - 站酷ZCOOL

真正关键的一次突破，是 AI 帮我写了一个 Chrome 扩展。它利用浏览器的 webRequest 能力，自动拦截发给云效的真实请求头，一次性抓取全部 23 个 Cookie 和 CSRF Token。没有这一步，推送永远过不了认证。至此，自动同步这条路才算真正走通了。

告别逐像素比对——UI走查自动化的完整落地实践（图ZMTU3Mzk3NjA=） - 观点 - 站酷设计师大脸包纸原创素材 - 站酷ZCOOL

chrome插件

告别逐像素比对——UI走查自动化的完整落地实践（图ZMTU3Mzk3NjQ=） - 观点 - 站酷设计师大脸包纸原创素材 - 站酷ZCOOL

chrome插件

5.2 扩展边界-增加多种走查方式

在原来只能通过2张图片进行走查的方法上，新增2种更高效的走查方式。

告别逐像素比对——UI走查自动化的完整落地实践（图ZMTU3Mzk3Njg=） - 观点 - 站酷设计师大脸包纸原创素材 - 站酷ZCOOL

目前支持的走查方式

增加源码走查方式：
不是所有场景都有设计图和截图。可以通过代码仓库直接获取源代码，和 viaim 规范对比，输出走查报告。这当中还有一个关键省钱点：为了防止AI在网页和代码中乱看消耗不必要的token，skill规定了走查前 AI 需要先询问审查模块，用 grep 定位，只读 UI 文件，跳过所有业务逻辑，不读整本字典。
增加导航逻辑检查。
除了之前只能走查静态视觉之外，页面之间的跳转关系也支持验证。可以像 AI 描述预期的跳转流程（"登录页 → 点击登录 → 首页"），AI 去代码里读路由配置，确认每个跳转目标是否存在、跳转方式是否正确、返回路径是不是闭环。

5.3 优化多个体验小点-能用变好用

缺陷标题规范化。
之前推送的缺陷标题是【UI走查-演示测试页】xxx，页面名是写死在代码里的。现在每次走查前 AI 会主动问你"项目名和版本号？"，标题变成【海外移动端-v2.1.0】xxx，项目和版本一目了然。
截图走查支持批量化。
最初只能一次走查一个页面。但实际工作中经常需要同时走查四五个页面——登录、首页、设置、个人中心、详情页。现在支持一次性发 10 张图（5 个页面 × 每组 2 张），AI 按顺序自动配对，一报告覆盖全部页面。
批量截图顺序约定。
走查方式1：截图对比走查中，每组图的第一张必须是设计稿，第二张是实现截图。AI 会按这个规则配对。如果图片数量是奇数，会主动提醒你。"嘿，是不是漏了一张？"
html页面交互细节优化：
按钮颜色、缩略图位置、成功推送toast提示、支持实时获取云效项目列表...
其他优化迭代会持续ing...