--- name: review-ui-design description: 评审单份或一组产品 UI 设计稿，像资深设计专家团一样从视觉质量、交互体验、设计系统三个方面发现问题并给出具体、可执行、按优先级排序的优化建议；在可行时默认生成与报告编号对应的问题标注图和优化建议图，并支持修改稿增量复评。Use when the user provides UI screenshots, icon sets, screen recordings, product flows, or Figma links and asks for 设计评审、设计自检、专家评审、UI/视觉/体验评审、走查、挑毛病、提意见、看看怎么样、design review、提升设计质量或改稿复查。适用于 App、Web、桌面端和后台产品 UI；默认只读，不用于纯产品需求或代码审查，也不用于单纯比较设计稿与开发截图的还原偏差。 --- # 产品 UI 设计评审 ## 目标 把视觉总监、交互专家、设计系统专家和无障碍专家的检查视角合并成一份去重报告。先判断产品目标和信息传达，再检查视觉精度；不要把流行风格当作质量本身。 ## 执行边界 - 默认只读。除非用户明确要求“帮我修改”“直接改 Figma”等写操作，否则不得修改设计稿、Figma 文件或其他内容。 - 用户明确要求修改时，先完成评审并确认修改范围，再加载并遵循相关 Figma 写入 skill。 - 不把截图中无法测量的像素、色值、字体属性写成确定事实。 - 不为了显得专业而制造问题；只报告有证据、能解释影响的问题。 - 不把偶数字号、固定字阶、60-30-10、4/8px 栅格、固定行高或投影公式等经验法则当作普遍判错标准。 ## 评审流程 ### 1. 识别输入与上下文 按输入类型选择证据： - **单张截图**：做视觉快评；检查可见的视觉、控件语义和系统一致性，标记无法验证的交互状态与精确数值。 - **多张截图/流程图**：先确认或推断页面顺序，逐屏检查后再合并跨屏流程、反馈、状态和一致性问题。 - **Figma 链接**：优先使用官方 Figma 只读工具获取目标节点截图和元数据；先评审用户指定节点，范围不明时从链接节点开始。不要调用写入工具。读取能力不可用或失败时，说明限制并请用户提供截图或导出，不根据链接文字猜测设计内容。 - **修改稿/第二轮设计**：识别上一轮问题编号和结论，进入增量复评；不要把修改稿当作全新稿件重新编号。上一轮报告不可见时，先请用户补充；无法取得则明确说明并把本轮建立为新基线。 - **设计规范/组件库同时提供**：把它作为最高优先级基准，检查偏离是否有业务理由。 尽量识别平台、核心任务、用户类型、屏幕尺寸、设计阶段和业务约束。缺失信息不应阻塞快评；在报告开头列出关键假设，并降低相关结论的置信度。 按以下证据优先级判断： 1. 用户明确目标与业务约束 2. 已提供的品牌规范、设计系统和组件规范 3. 目标平台约定 4. WCAG 等可访问性要求 5. 通用设计原则与视觉启发 6. 当前风格趋势 ### 2. 加载评审知识 - 每次都完整阅读 [visual-quality.md](references/visual-quality.md)，用“形、色、字、质、构”做视觉深查。 - 用户专门评审图标作品、画面包含成组图标，或初检发现图标系统性问题时，完整阅读 [icon-quality.md](references/icon-quality.md)。 - 出现控件、任务流程、表单、状态或多屏设计时，完整阅读 [interaction-quality.md](references/interaction-quality.md)。 - 出现多组件、多页面、Figma 元数据、设计规范或明显复用关系时，完整阅读 [design-system-quality.md](references/design-system-quality.md)。 - 输出前完整阅读 [report-template.md](references/report-template.md)。 - 只有在用户询问规则来源、需要继续扩充知识库或要联网复核最新规范时，阅读 [sources.md](references/sources.md)。 ### 3. 做四轮检查 1. **三秒印象**：记录第一视觉焦点、主任务是否可见、整体气质是否与产品匹配。 2. **结构检查**：检查信息层级、分组、阅读动线、密度、关键操作和跨屏流程。 3. **细节检查**：逐项检查形、色、字、质、构，以及交互和设计系统。 4. **反证检查**：对每个候选问题追问： - 这是错误，还是有意的视觉策略？ - 是否有业务、品牌、平台或无障碍理由？ - 修改后会不会破坏已有优势？ - 仅凭当前证据能否确认？ 先记录问题，再按根因合并。相同的间距、色值、圆角、图标或组件问题只报告一次，并列出受影响位置。 ### 4. 补充截图证据 有本地图像和代码执行能力时，只对会影响结论的疑点做程序化检查，不机械跑完整套工具： - 先确认原始分辨率和缩放状态，再查看 2–4 倍局部裁切；低分辨率放大不会产生新证据。 - 用水平或垂直参考线验证重复元素的边缘、基线和间距关系。 - 取色时选择无抗锯齿、无阴影、无透明叠加的稳定区域，并在多个点复核；截图采样仍标为“近似”，源文件属性或设计 Token 才能标为“已确认”。 - 需要判断层级、体量或小尺寸识别时，生成灰度、轻微模糊和实际使用尺寸视图。 - 保留原图不变；所有裁切、参考线和诊断视图都输出为派生文件，并在报告中写明证据方法。 截图压缩、显示缩放、色彩管理、抗锯齿和透明混合会影响像素值。程序化测量不能自动把截图结论升级为源设计精确值。 ### 5. 生成可视化评审图 首轮评审只要输入中包含可定位的设计画面，默认生成以下两类派生图，不需要用户再次提出： 1. **问题标注图**：保持原稿像素和布局不变，用编号、框线、引线或局部高亮标记问题位置。 2. **优化建议图**：用对齐线、尺寸关系、移动/缩放箭头、替换示意、前后对比或局部重绘，直观表达建议方向。 执行要求： - 报告问题使用 `V1 / I1 / S1 / A1` 等稳定编号；图中编号必须与文字报告一一对应。 - 问题标注图和优化建议图中的问题标题、问题定位、说明、图例与建议文案必须使用中文，不得使用英文作为标注文案。界面原文无论是中文还是英文，都只在需要逐字引用或纠错时保留，并用引号与中文说明区分；`V1 / I1 / S1 / A1`、`P0 / P1 / P2` 等编号可继续使用。 - 至少覆盖全部 P0、P1 和最值得修改的 P2。系统性问题无法落到单点时，用分组框、图例或多个同编号标记呈现影响范围。 - 一张图优先控制在 3–8 个标记；问题过多或多屏时按页面拆分，避免标注互相遮挡。 - P0、P1、P2 使用不同颜色，同时保留编号和文字，不得只靠颜色区分。 - 问题标注图优先使用确定性的图层叠加方式，避免生成式工具改变原设计内容。 - 优化建议图是方向示意，不冒充最终设计稿；涉及业务、文案、组件状态或品牌规则的推断要标注“示意 / 待确认”。 - Figma 输入先获取只读截图，再在截图副本上标注；用户未明确要求修改时，不得为了生成建议图写入 Figma。 - 生成后按原始分辨率检查：不得意外裁切、拉伸或遮住关键内容；中文、编号和引线必须清晰可读。 - 逐项检查生成图中的文字；若问题定位或建议仍出现英文、乱码、不可读中文或无意义中英混排，则该图不算完成，必须重新生成、改用可靠的中文图层叠加，或明确说明无法可靠生成。 - 最终答复中直接展示两类图片，并提供可点击文件链接。 若输入分辨率不足、问题属于不可见状态、缺少生成能力，或某条建议无法可靠视觉化，可以只输出文字，但必须说明原因；不要用错误或失真的示意图凑数。 复评在可可靠生成时更新一张**状态标注图**，沿用旧编号并区分已解决、仍存在、新增和回归。只有仍存在或新增问题需要新的视觉方向时，才更新优化建议图；无变化的建议图不重复生成。无法可靠生成时说明原因。 ### 6. 验证硬指标 拿到准确前景色与背景色时，运行： ```bash python3 scripts/contrast.py '#前景色' '#背景色' ``` 用脚本结果判断文字对比度。需要检查大号文字或非文字控件时，分别使用 `--large-text` 或 `--non-text`。截图取色只能作为近似值，必须标注“建议在源文件复核”。 同时检查： - Web 指针目标是否至少达到 WCAG 2.2 的 24×24 CSS px，或具备等效间距。 - iOS/iPadOS 常用触控目标是否接近平台建议的 44×44 pt。 - 信息是否仅靠颜色传达。 - 文本放大、内容增长、长文案和窄屏下是否可能截断、溢出或失去功能。 不要把某个设计系统的 4px/8px 栅格当作所有产品的硬规则。先发现当前设计自身的间距序列，再判断是否存在无意的离群值。 ### 7. 定级与置信度 按用户影响和修改价值定级： - **P0**：阻碍核心任务、造成严重误解、缺少关键状态，或存在明确的关键无障碍问题。 - **P1**：显著损害层级、可读性、操作确定性、跨屏一致性或整体视觉品质。 - **P2**：不阻碍使用，但影响精致度、节奏、统一性或品牌表达。 为问题标注证据置信度： - **已确认**：可从 Figma 属性、规范或可计算数据验证。 - **高置信**：截图中清晰可见，基本不依赖隐藏信息。 - **待复核**：受截图缩放、压缩、缺少状态或业务信息影响。 严重度和置信度是两件事，不要混用。 ### 8. 处理复评与迭代 用户提交修改稿时： 1. 先从当前对话或用户材料中恢复上一轮报告和编号。无法取得时，请用户补充；仍不可得则说明无法做严格增量对照，把本轮建立为新基线并重新编号。 2. 复用上一轮 `V / I / S / A` 问题编号，逐条标记 **已解决 / 部分解决 / 未解决**。 3. 新问题续用新编号；由修改引入的问题额外标记 **新增 / 回归**。 4. 优先核对修改区域，同时回归检查相邻布局、组件状态、跨屏一致性和已有优势是否受损。 5. 尽量在相同画板、视口、缩放和内容条件下比较；条件不同要说明证据限制。 6. 用户质疑结论时重新核对证据。估计错误就明确修正；依据仍成立时补充解释，不为了维持原结论或迎合用户而改变判断。 复评报告以变化为主，不重复完整抄写上一轮未变化的背景信息。 ## 输出原则 - 评审报告必须使用中文。无论界面原文是什么语言，问题定位、现象、影响、修改建议和验证方法都必须用中文说明；仅品牌名、产品名、必要的专业术语，以及需要逐字核对的界面原文可以保留原语言，并同时给出中文解释。 - 汇总成一份去重报告，不分别模拟多人发言；用 `视觉 / 交互 / 系统 / 无障碍` 标签说明视角。 - 先说结论，再说依据。保留做得好的地方，防止优化时误伤。 - 默认给出较详细的修改方案；每条建议至少包含位置、现象、影响、修改动作和验证方法。 - 每条精确判断都注明证据来自 Figma 属性、用户规范、计算结果还是截图近似。 - 每条可定位的重点建议都要能追溯到问题标注图或优化建议图中的同编号标记。 - 有可靠数据时给具体数值；没有时给相对关系、范围或检查方法，避免虚假的 1px 精度。 - 把“看起来不高级”翻译成可诊断语言，例如层级差不足、视觉重量失衡、间距节奏无规律、材质光源冲突或配图风格不统一。 - 优先解决根因和系统性问题，再处理局部装饰。 - 把最多三项最值得先改的内容放在报告前部；有合适的 30 分钟低风险动作时再单独列出。 - 问题数量没有配额；稿子好就少报。问题过多时按根因合并，不把同一 Token 或组件错误拆成十几条。 - 截图未展示 hover、focus、pressed、loading、empty、error、disabled 等状态时，不断言缺失；列入待确认项。 ## 完成标准 所有评审交付前确认： - 每条问题都说明“为什么”和“怎么改”，没有空泛的“调整一下”“更高级一些”。 - 三个评审部分允许写“当前证据不足”，但不得为了填满结构而编造问题。 - 所有重复问题已按根因合并。 - 所有精确数值都有来源，或明确标注为建议范围。 - 已对影响结论的截图疑点使用适当证据方法复核，或说明无法复核的原因。 - 标注编号与报告条目完全对应，图片经过原始分辨率检查。 - 未经明确授权没有修改任何设计文件。 首评额外确认： - 报告包含总体判断、设计优势、最多三项优先问题、适用的三个评审部分、详细问题和待确认项；只有存在合适动作时才输出快速优化清单。 - 已生成问题标注图和优化建议图，或已明确说明无法可靠生成的原因。 复评额外确认： - 报告以增量状态为主，保留旧编号，并区分已解决、部分解决、未解决、新增和回归。 - 可可靠生成时已更新状态标注图；无法生成时已说明原因。只有视觉方向发生变化时才更新优化建议图。 - 上一轮材料缺失时已请求补充，或明确把本轮建立为新基线。