AI 精准走查还原

设计稿交付后，设计工作还没有结束。页面真正做出来，还需要确认它是否符合设计。

按钮的高度、文字的换行、卡片里的间距，以及下拉面板展开后的布局，都需要逐项检查。发现差异之后，还要截图、标注、解释依据，再等修改完成后复查。

我构建 Design QA，就是希望把这段工作中的重复步骤交给 AI：按照设计师明确的方法检查页面，把差异和依据整理成可处理的反馈。

01　我想减少的，是重复劳动，而不是设计判断

设计走查里有两类不同的工作。一类需要设计师作出判断：采用哪一版设计、哪些差异可以接受、某个体验问题是否值得调整。另一类则是要求确定之后的重复执行：找到对应元素、读取数值、检查状态、标出位置，再整理成反馈。

我的目标，是让 AI 承担更多后者，而不是替设计师决定什么是好的设计。比如，设计明确要求按钮高 36 px，检查开发实现是否符合这一要求，是可以被规则化的；至于按钮是否应该改得更大，则是另一项设计决策。

因此，我把这个 Skill 的任务限定为：依据明确的设计要求，检查开发实现是否一致。每一条偏差都需要有设计来源和实际证据，修复建议也应围绕已确认的偏差展开。对于设计中没有明确规定的内容，不能仅凭主观偏好判定开发有错。

02　为什么做成 Skill，而不是只写一句提示词

一句“帮我检查页面还原度”，并没有说明该看哪些状态、按什么依据判断，以及证据不足时怎样处理。它表达了目标，却没有给出稳定的执行方法。

我把它做成 Skill，是为了把检查顺序、工具用法和反馈方式一起保存下来。它就像交给 AI 的一份工作说明：先读设计，再查页面；每一步做什么，遇到不确定的情况怎样处理，都有明确约定。

这套工作方式由三部分配合：Skill 规定方法，AI 助手通过已授权的设计读取和浏览器工具执行检查，本地脚本校验记录并生成报告。

所以，我构建的不是另一个独立平台，而是一套可以交给 AI 助手使用的走查方法。要执行检查，仍需要可访问的设计资料、开发页面和相应工具权限。

03　真正的工作，是把走查经验写成执行规则

构建这个 Skill，最重要的不是反复告诉 AI“仔细一点”，而是把“仔细”拆成具体动作。

先说清楚“应该是什么”，再检查“实际是什么”

我先让 AI 读取设计中明确的尺寸、样式和状态要求，形成“本次验收依据”，再对照开发页面。每条要求都要对应到具体元素和来源，避免检查时换了标准。

例如，卡片内距是多少，应当从设计规范中确认，而不是看开发页面的留白反推。只有截图、无法取得准确属性时，就把这一项留待确认。

先列出检查清单，再从最小元素逐层检查

一个页面看起来接近设计，并不代表细节都正确。一个按钮的高度符合要求，也不能证明它的字号、圆角和内距全部符合要求。

因此，我把检查范围拆成元素、属性、关系和状态。先看文字、图标、按钮等最小元素，再看彼此的间距与对齐，接着检查组合组件，最后回到模块和页面整体。

不同状态也分别检查。下拉面板打开后，我要求 AI 继续检查里面的文字、图标、操作区和留白，而不是停在“已经打开”这一步。

把“没有查到”保留下来，而不是自动变成通过

报告里有五个问题，可能是整页只发现五个问题，也可能是只检查了五处。因此，我要求先列出检查清单，再记录每项的执行结果。

这样，报告不仅能告诉我哪里有偏差，也能说明哪里已通过、哪里需要确认、哪里还没有检查。没有完成的部分会留下来，方便下一轮继续。

确认范围 → 提取设计依据 → 建立检查清单 → 采集并比对 → 输出报告 → 修改后重新取证

这条路径，把“帮我看看页面”变成了一套能够逐步执行、逐项复核的工作方法。

04　从“按钮有点小”，到一条可以执行的反馈

以图中的“创建投放”按钮为例：设计要求高度为 36 px，开发实现为 32 px。看起来只是矮了一点，但要让开发知道怎么改，反馈就不能停在“有点小”。

我让 AI 先确认两侧对应的是同一个按钮、同一种状态，并在一致的比较条件下核对数值。随后把设计要求、实际表现和修改方向放进同一条反馈。

这样，一句模糊的感受就变成了明确的修改目标：

“创建投放”按钮高度应为 36 px，实际为 32 px，少了 4 px。建议调整到 36 px，并在相同状态下重新检查。

这条反馈回答了四个问题：哪里不一致、应该是什么样、实际差多少，以及修改后怎样确认。开发不用再猜“偏小”究竟指高度、字号，还是内部留白。

我还要求每条反馈保留对应截图和数值来源。有人对结论有疑问时，可以回到具体位置核对，而不必只相信 AI 的描述。

高度检查完，字号、圆角和间距仍要分别继续。一个属性的结果，只回答这一项问题。

05　找到差异之后，还要让别人容易处理

对设计师来说，发现问题只是前半段工作。如果反馈仍需要开发反复寻找位置、猜测修改目标，自动化就没有把沟通问题解决。

因此，我把报告也当作一个需要设计的界面：左侧选择当前要处理的位置，右侧集中展示设计与实现的对照、具体差值和修改方向。来源、复现步骤等信息按需展开，让人先看懂问题，再追查依据。

我让标注只围绕当前问题展开：文字的问题标文字，间距的问题指出空隙和相关边界。比起把整张卡片框起来，这样更容易找到需要修改的地方；两侧图片也保留真实比例，方便直接比较。

对于有依据的同类偏差，我保留关联，但让每个发生位置独立处理。修好一个按钮，并不意味着其他按钮也已经修好。处理记录可以更新，是否符合设计仍要用新的截图和测量结果确认。

06　让走查结果顺利交给下一位

报告生成之后，设计师要核对，开发要修改，后续还要复查。因此，我没有把所有信息只留在一张截图或一段对话里。

我保留了三种输出：HTML 验收板用于查看对照和逐处处理问题；Markdown 修复清单便于交接；JSON 则保存结构化记录，供后续程序读取。三种文件来自同一份数据。

我也把任务保持在只读范围内：走查负责检查和记录，代码修改交给开发；支付、删除、发布等会改变业务数据的操作，不作为普通检查步骤执行。

验收人员可以记录“已完成”或“无需处理”，但这与检查是否通过是两回事。下一次复查，仍要回到同一设计依据和对应位置，重新检查修改后的页面。

我希望交接出去的，不只是一张问题清单，还有明确的复验方式：依据哪条要求，回到哪个位置，检查什么结果。

结语　我设计的不只是一个工具，也是一种工作方法

构建 Design QA，让我需要思考的不只是“怎样检查这个页面”，还有“怎样把检查方法写清楚，让 AI 能执行，让别人能复核”。

我要设计的，不只是最后的验收界面，也包括检查顺序、信息依据、异常处理，以及人与 AI 的分工。

把重复执行交给 AI，把设计判断留给设计师，让每一条反馈都说得清、找得到、能复查。