design-qa

设计 QA

在交付前，使用此内部辅助工具对比原型的源设计与渲染后的实现。

请勿将此技能用于广泛的 UX 评审、设计评审、产品审查或流程评审。对于面向用户的此类请求，请使用 audit。

每次 Product Design 构建交付前都必须使用此技能。

通过 QA 需要同时具备：

• 源视觉目标：Figma 节点、图像、屏幕截图、模型图或源截图
• 渲染后的实现：本地 URL、已部署的 URL、应用屏幕、组件或屏幕截图

如果任一产物无法打开、截取或对比，请编写 design-qa.md，注明 final result: blocked 并说明阻碍原因。不得让构建技能将交付标记为已完成。

关键覆盖规则

遵循 critical-overrides。

工作流程

以产品质量评审者的视角对比预期设计与实现，而非泛泛地评判美观程度。输出必须是有优先级的修复清单，并以两个产物中的证据为依据。

不得仅凭记忆、代码或文件路径撰写 QA 评审。先打开或截取源设计和实现，再对比实际可见内容。

不要假装分别查看两张图就等于并排对比。将源图像和实现的屏幕截图放在同一个对比输入中，再根据该组合输入判断可见差异。

设计 QA 是一个迭代循环。只有在未发现任何可执行的 P0/P1/P2 差异，且未因此进行任何视觉修复时，首次对比才能通过。

若对比发现任何 P0/P1/P2 问题：

• 记录问题并保持当前结果为阻塞状态。
• 应用修复。
• 在相同视口和状态下截取修订后的实现。
• 再次将修订后的截图与源设计进行对比。

后续通过时，必须指出先前发现的问题、所做的修复以及修复后的视觉证据。构建、依赖、lint、部署和预览故障排查不算设计 QA 迭代。

1. 确定对比目标。

   • 确定源设计：Figma 节点、图像、设计板、屏幕截图、规范或模型图。
   • 确定实现：本地 URL、已部署的 URL、应用屏幕、组件、屏幕截图或由代码渲染的视图。
   • 评审前，确保视口、状态、主题、设备密度、路由、内容、身份验证状态和交互状态相同。
   • 如果产物呈现的状态不同，先指出这一点，并避免给出不准确的精细判断。

2. 收集证据。

   • 对于 Figma，在可用时使用设计上下文和屏幕截图工具。
   • 对于 Web/应用实现，请遵循 index 中的 Browser Choice 规则。在 ChatGPT Work Mode 中，打开本地实现前，请遵循当前构建技能的“在 ChatGPT Work Mode 中预览原型”部分。然后在目标视口下截取屏幕截图。
   • 在相关时截取其他状态：移动端/桌面端、悬停/焦点/激活、空状态/加载中/错误、深色/浅色以及关键响应式断点。
   • 在可用时保存屏幕截图的路径或 URL，以便在问题描述中引用证据。
   • 仅截取屏幕截图还不够。评审前，必须将源图像和实现的屏幕截图放在同一个对比输入中。

3. 对比前进行规范化。

   • 对齐裁剪范围、视口大小、比例和设备边框。不要在未指出差异的情况下，将带设备边框的模型图与不带边框的页面进行对比。
   • 优先对比内容区域，而非完整浏览器界面或周围画布。

4. 在合适的细节层级进行比较。

   • 使用全视图比较，判断整体构图、层级、布局、信息密度和响应式结构。
   • 如果在全视图比较中无法判断重要细节，请使用局部区域进行比较。
   • 根据实际源稿和实现选择局部区域。当保真度取决于精确的排版、对齐、图像、素材、图标、徽标、控件、表单、导航、表格、密集 UI 或可见交互状态时，请使用局部区域。
   • 如果不需要局部区域，请在 design-qa.md 中说明原因。
   • 如果全视图比较无法清楚呈现重要细节，不要仅凭全视图比较通过 QA。

5. 系统化审查。

   • 如果 QA 审查不只是快速目视检查，请阅读 qa-rubric。
   • 检查信息架构、布局、间距、排版／字体、颜色、图像、图像质量、图标、文案、易用性、交互状态、响应能力、无障碍性和润色效果。
   • 务必专门检查五个必需的保真度方面：字体／排版、间距／布局节奏、颜色／设计令牌、图像质量和文案／内容。即使用户没有明确提及这些方面，也要检查。
   • 如果样稿未涉及你发现的问题（例如空状态），请将其作为样稿需要解决的独立缺陷指出。
   • 你的另一项目标是判断实现效果是否“与样稿一样出色”。如果存在风格问题，请明确指出。如果用户的提示内容渗入了实现，而应用本身本应独立呈现，也请指出。
   • 区分设计偏差与有意为之的产品／代码限制。如果某项偏差可能是有意的，请用问题或假设的方式表述。

6. 生成以修复为导向的 QA 报告。

   • 先列出发现，并按严重程度和对用户的影响排序。
   • 每项发现都应包括：严重程度、位置、差异之处、证据、影响原因和具体修复方法。
   • 如果能获取实现上下文，请提供精确的 CSS／组件／令牌建议。
   • 将客观不匹配与主观润色建议分开。
   • 在检查完所有必需的保真度方面，并明确将所有剩余差异归类为可接受、预期或仍需处理之前，不要声称设计相符、工作已完成或效果已臻完善。
   • 最后附上简洁的实现清单。

必需的保真度方面

每份 QA 报告都必须明确评估以下方面：

• 字体与排版：字体系列、回退字体、字重、字号、行高、字间距、抗锯齿、层级、换行、截断，以及展示文本和小号 UI 文本是否采用恰当的视觉字重。字体保真度的检查极其重要，包括查找相似字体，或使用图像分析来找出字体差异。
• 间距与布局节奏：画布尺寸、裁切、对齐、边距、内边距、网格轨道、区块间距、组件间距、圆角、阴影／层级效果和纵向节奏。
• 颜色与视觉令牌：采样或推断出的调色板、渐变、不透明度、对比度、语义状态颜色、前景／背景平衡，以及 CSS 令牌与源设计的映射情况。
• 图像质量与素材保真度：主体是否正确、裁切、缩放、清晰度、压缩、透明边缘光晕、蒙版、背景处理、适合使用栅格还是矢量，以及生成的素材是否符合源稿的美术风格。如果将视觉目标中的徽标、插图、装饰图案、产品图像、非标准图标或其他可见图像素材替换成自定义内联 SVG、手工绘制的 SVG、HTML 元素、div／span 形状、CSS 绘图、渐变、表情符号、文本字形、占位形状或代码原生近似图形，则 QA 不通过。
• 应用专属文案与内容

严重程度

• P0：阻碍核心功能使用、造成严重的无障碍访问问题、布局损坏或任务无法完成。
• P1：存在重大的设计偏差或可用性退化，用户很可能会注意到。
• P2：存在中度视觉偏差、状态不一致、响应式问题或可修复的细节缺陷。
• P3：有助于提升还原度的细微改进，但不会阻碍验收。

对于隐藏持久应用控件的视口溢出，以及会实质性改变首屏内容、主要区域比例、文本换行或界面密度的偏差，应评为 P2 或更高。

输出格式

除非用户另有要求，否则请使用以下结构：

**Findings**
- [P1] Short issue title
  Location: screen/component/selector/file if known.
  Evidence: design does X, implementation does Y.
  Impact: why this matters.
  Fix: concrete change.

**Open Questions**
- Any ambiguity about intentional deviations, unavailable states, or missing artifacts.

**Implementation Checklist**
- Ordered fixes that can be executed directly.

**Follow-up Polish**
- P3 refinements that can improve fidelity after handoff.

如果没有实质性偏差，请明确说明，并列出任何尚未完成的测试。

在交付前使用此技能时，请将最新的 QA 报告保存到项目根目录下的 design-qa.md。

design-qa.md 必须包含：

• 源视觉依据的路径
• 实现截图的路径
• 视口
• 状态
• 完整视图对比证据
• 局部区域对比证据，或说明为何无需提供
• 发现的问题
• 每次 P0/P1/P2 迭代的对比记录：此前发现的问题、所做的修复以及修复后的视觉证据
• 最终结果

对于 ChatGPT Work Mode 构建，design-qa.md 必须包含浏览器渲染的实现截图、视口、已测试的主要交互、检查过的控制台错误以及最终结果。如果缺少浏览器渲染证据，则 final result 为 blocked。

final result 必须恰好为 passed 或 blocked。

如果没有可操作的 P0/P1/P2 问题，请使用 passed。可以将 P3 问题留作后续润色。 如果仍有可操作的 P0/P1/P2 问题，请使用 blocked 并指出阻碍项。

返回 QA 报告的文件路径。