前端设计评审

要解决什么问题

团队里常见两类前端痛点：一是实现已经落地，但和 Figma、设计 token、组件库对不齐，评审靠肉眼和口头约定，问题优先级也不统一；二是从零做界面时，模型容易滑向 Inter + 紫渐变 + 对称卡片这类「AI 套路」，和真实产品语境、设计系统约束脱节。

本技能把 设计评审 与 创意前端设计 放在同一套话术里：前者按设计系统与三大质量支柱做结构化检查；后者在写代码前先定美学方向，再按指引落地排版、配色、动效与空间构成。

技能如何工作

模式 1：设计评审

• 实现前：在 Storybook / 组件库核对 API，用 Figma Dev Mode 取间距与 token，用设计系统组件实现。
• 评审中：对照 Figma，验证 token 而非硬编码，检查变体/状态，标记需设计审批的偏差。
• 流程：识别用户任务 → 匹配设计系统模式 → 评估美学与范围 → 按三大支柱打分并分级（阻断 / 重大 / 次要）→ 给出带设计系统示例的建议。

三大支柱：无摩擦（任务是否 ≤3 次交互、主操作是否清晰）、精良工艺（合规、美学、无障碍 WCAG）、可信赖（AI 与错误信息的透明度）。

模式 2：创意前端设计

编码前明确目的、基调（极简/复古未来/编辑风等）、约束与差异化；在排版、CSS 变量调色、纯 CSS 动效、打破网格的空间与背景层次上执行，并刻意避开通用字体与可预测布局。复杂度与愿景对齐——极繁要精致代码，极简要克制精准。

详细评审模板、评审类型修饰符、快速清单与正反例见技能内 references/ 文档。

适用边界

• 强依赖你方已有的 设计系统、Figma 与组件库；没有 token 与规范时，评审只能停留在通用 UX 与无障碍层面。
• 创意模式解决的是「审美方向与执行纪律」，不替代信息架构、用户研究或品牌策略的最终拍板。
• 致谢中说明：创意原则受 Anthropic frontend-design 启发；质量支柱框架来自 @Quirinevwm，用于系统化 UI 评估。