design-review

设计评审

检查渲染后的界面是否存在视觉和交互缺陷，并在收到修复请求或已获授权时修复已确认的问题。仅评审请求只需提供发现和证据，不修改源代码。

范围

确定目标 URL 和变更的路由；对于感知差异的评审，使用实际的基准提交或合并基准提交。按照共享的 QA 探索指南进行浏览器访问、快照采集、角色和视口覆盖以及安全交互。保留无关的未提交更改；必要时使用单独的检出目录，而不是暂存或提交所有更改。

对于请求的产品界面，使用 Full 模式；对于关键屏幕或状态，使用 Quick 模式；对于明确要求范围更广的交互或无障碍审计，使用 Deep 模式。记录检查内容。只解决一次真正的范围歧义；重复使用用户的答复和授权。

检查

根据 DESIGN.md、设计令牌、组件、品牌素材和渲染后的页面进行校准。使用相关的设计检查项：层级、排版、间距与对齐、文案、状态、响应式重排、键盘与焦点、对比度、动效和支持的主题。

区分可见或计算得出的缺陷与审美建议。字体、网格、颜色或边框半径本身并不能证明存在缺陷。保留有意为之的品牌设计。检查实际的文本与背景颜色，以及字号和字重：18px 的常规文本属于普通文本，在 WCAG AA 下需要达到 4.5:1。大号文本的阈值为 24px 常规字重，或约 18.67px 粗体。

跨页面追踪关键交互。确认焦点顺序、错误与恢复状态以及连续性，不要只检查静态截图。如果浏览器工具支持脚本求值，则每次导航后通过一次脚本求值收集控制台错误、失败请求、对比度、字体加载和焦点顺序，并在一次检查中捕获所有相关视口；检查内容不变，只减少往返次数。证据支持同一原因时，将重复症状归纳为系统性问题。记录严重程度、用户影响、截图或计算结果等证据、复现步骤和建议的修正方案。

修复与验证

在修复模式下，仅修改最小范围内且归你负责的内容，验证受影响的路由和相邻状态，并采集修复前后的证据。最终文件只运行一次相关的已配置检查。仅在明确授权时提交经过验证且归你负责的更改；遵守不提交模式。修复回归问题，或仅撤销你自己的编辑。不要自动还原 HEAD，也不要使用臆造的概率公式来决定是否继续。

出现回归、重复修复失败、原因不明或范围变更时，重新评估。达到请求的验收标准或商定的预算后停止，并报告所有未解决事项。不要为了追求 10/10 的分数而处理无关的润色工作。

交付

报告测试过的路由、视口和状态、发现的问题、已验证的更改、剩余阻塞项和证据链接。区分验证不完整与缺陷。只有运行了相关检查，才能给出无问题的结论。如果用户要求评分，请将其标明为定性评估，且评分不得掩盖阻塞项。分别说明源代码修复、提交状态和可选的待办建议。