用好这个Skill，帮你快速提升设计走查效率！

一、全文速览图

AI 几乎是每个同学都关注的话题！我们准备做一个新系列，叫“设计师 AI 大改造”。这篇算第一期，主题是设计走查。

其实在一个月之前，我就已经在视频平台分享过一套设计师使用 Codex 做 AI 设计走查的方法。

但当时思路比较简单。大量同学使用后，我们发现，它的走查只能做到基础的模块对比，很多时候走查不够细、不够准，还很慢……导致这个 Skill 整体的使用率就偏低。

经过不断摸索研究，这次我想和大家聊聊这个 Skill 的迭代思路、我们中间遇到了哪些问题，最后又有哪些收获。

也算是一个复盘，让大家能够了解 AI 的全貌，正视它、学习它、掌控它。

二、上一版为什么不够准？

上一版 Skill 为什么不好用？我们来复盘一下它的设计逻辑。

上一版的方式，本质上就是对比两张图片找不同。我提供一张设计稿，再提供一张开发页面截图，让 AI 做横向对比。

这种方式能用：如果页面少了一个模块、内容放错了、整体布局发生偏移，AI 基本都能看出来。

但是想要更精准地比对，问题就会出现。

比如视频里我拿一个页面做演示：这个投影到底有多大？描边是多粗？图标是什么颜色？字体、行高和卡片间距又分别是多少？

这些信息并不会直接写在图片里。AI 知道这是一张页面截图，却不知道截图背后的真实参数，只能通过视觉去猜。

所以你会发现，上一版 Skill 更适合检查页面布局和信息结构，却很难真正进入精细化的项目验收。

这时候我意识到，想要 AI 走查得好，必须得让 AI 看见才行。

三、让 AI 看见截图背后的真实参数

那问题就来了：有没有办法让 AI 拿到结构化属性？

所谓结构化属性，就是我们在 Figma 里可以直接看到的字号、行高、颜色、描边、圆角和尺寸。它们是明确的数据，不需要再靠眼睛估算。

桌面端网页其实最容易拿到这些信息。视频里我打开飞书官网，直接通过浏览器的“检查”功能，就能看到文字大小、颜色、卡片宽高、投影色值等真实 CSS。

但新的问题又来了。如果让 AI 一个元素一个元素地检查，页面一复杂，操作次数和 Token 消耗都会非常高。

所以我们需要的，不是让 AI 在浏览器里慢慢翻，而是想办法一次性把网页结构拿出来。

这时我们想到 Figma 最近推出的浏览器插件。是的，你没听错，这个插件就叫 Figma。

安装以后，我们可以直接复制网页里的页面元素，再粘贴到 Figma 文件中。粘贴完成后，它不是一张扁平图片，而是一组包含自动布局、文字、尺寸和样式的 Figma 节点。

这一步很关键。因为我们的走查逻辑终于从“图片与图片对比”，变成了“设计文档与网页节点对比”。

过去是在看两个页面像不像，现在可以直接比较字体、颜色、宽高和间距到底是否一致。

四、先做一次最小验证

有了这个思路后，我们没有马上把它写进 Skill，而是先做了一次简单测试。

我们一边准备原始设计稿，另一边准备从线上页面捕获到 Figma 的网页节点，随后让 Codex 对两套内容做横向走查，看看它能不能读到过去容易漏掉的细节。

测试结果还不错。原来只能说“这里看起来有点不一样”的地方，现在已经可以进一步定位到具体元素和属性。

不过，它也不是一次就能把所有问题都找出来。像按钮宽度、卡片间距这类很小的细节，AI 仍然可能漏掉。

这时候需要提前告诉它，本次走查重点检查什么。也就是说，结构化数据解决了“AI 能不能看见”的问题，但具体“看什么”，仍然需要我们把范围说清楚。

确认这条路径能够实现以后，我们才继续往下走。

五、网页端跑通了，移动端怎么办？

做到这里，我马上想到：网页端可以通过这种方式走查，那移动端能不能一起覆盖？

我们尝试了一圈，结果并不理想。

原因很简单。桌面网页可以从浏览器拿到 DOM 和 CSS，但设计师在移动端通常只有安装包、镜像画面或者截图，很难读取应用内部每个元素的真实属性。

除非开发把完整代码库交给你，并且能够在本地运行，否则移动端暂时还是只能通过图片进行基础对比。

所以这次我们做了一个取舍：先把网页端的精准走查做深、做稳，移动端暂时拆出去，后续再单独寻找更合适的方法。

这里并不是功能越多越好。我们的目的，是拿到一个稳定、准确的走查结果。

六、把设计走查流程完整串起来

前面的测试证明方法是可行的，但操作上还有很多断点：打开网页、调用插件、复制内容、切换 Figma，再回到 Codex。

所以我又问了 Codex 一个问题：这些步骤能不能直接在 Codex 里面完成？

结果有点出乎我的意料：它可以做到。

Codex 告诉我，这个能力叫“网页捕获”。它可以直接捕获静态网页，再通过 Figma MCP 把内容放到 Figma 中，接着完成设计稿和线上页面的匹配与走查。

知道“网页捕获”这个关键词以后，后面的沟通就顺畅很多。整个流程也终于可以被自动串起来：

1. 提供需要走查的网页链接、设计稿和页面范围；
2. 由 AI 捕获网页内容；
3. 根据设计稿调整页面分辨率和画布尺寸；
4. 将实际页面与设计稿中的元素进行匹配；
5. 校验页面结构、样式和视觉效果；
6. 输出走查结果、修改建议和复验方式。

你会发现，我们最终沉淀的并不是一句更复杂的提示词，而是一条从输入、捕获、匹配、校验到输出的完整路径。

精准走查跑通以后，我也纠结过一个问题：既然结构化校验更准确，那原来的图片对比是不是应该直接删掉？

最后我没有删，因为它们本来就是两种不同的校验方式。

第一种是快速校验。 更适合日常开发、自测和频繁迭代。直接提供截图，让 AI 快速检查明显的布局、颜色、内容和组件差异，成本更低。

第二种是精准校验。 更适合上线前验收或者重点页面。AI 会读取节点和样式，进一步检查尺寸、间距、字号、圆角、描边和阴影，并给出更具体的依据。

想快速看一遍，就走图片对比；想检查得更细，就走结构化校验。不是每一次都要调用最复杂的流程，也不是有了新方法，旧方法就完全没有价值。

最后，我用 Semi Design 做了一次实际网页走查。

这一次输出已经不再只是“页面整体比较接近”“某个位置好像有点问题”。它会继续往下检查：有些区域高度不一致、页面中存在按钮缺失、输入框的高度和宽度不匹配、表格列宽不同，甚至连背景颜色的差异也能被读出来。

更重要的是，它不仅告诉你哪里有问题，还会给出对应的修改方向。开发调整以后，也可以在相同页面状态下重新走查。

在 Figma 中，我们也能同时看到原始设计稿和线上捕获的页面节点。设计师不需要再凭感觉反复核对，而是可以直接看具体元素和属性。

这才是新版 Skill 真正的变化：不是单纯发现更多问题，而是让问题更容易定位、更容易修改，也更容易验证。

七、一个好 Skill，是怎样迭代出来的？

完成这次升级后，我最大的收获，其实不是做出了一个新的设计走查 Skill，而是重新理解了 AI 产品应该怎么迭代。

很多时候，只要 AI 的结果不好，我们第一反应就是模型不行，或者提示词还不够好。

但这次模型并没有发生变化。我们只是把输入从两张图片，变成了网页结构、真实样式和设计节点，再重新梳理了一遍工作流，最后的结果就完全不同。

所以设计师真正需要理解的，可能不只是某一个提示词或者某一种模型，而是一个任务的链路和 AI 的能力边界。

一个好 Skill 真的是迭代出来的。先拿到真实反馈，再找到问题原因，再验证新的路径，最后把有效方法沉淀下来。

不要只让 AI 更努力地“看图找不同”，而是想办法给它更容易理解和验证的信息。

Skill 网址：https://github.com/youthce/web-design-audit-skill

这就是我这次重新迭代设计走查 Skill 的完整过程。