malganiswu/red-bean-nian-gao/design-system-visual-review

Design System 视觉评审

本 Skill 只定义可重复的评审工作流。设计原则、token、组件规范与开发门禁以仓库中适用的 AGENTS.md、Foundation、Showcase 和真实实现为准，不在此复制。

建立评审上下文

1. 确认仓库根目录，完整读取根 AGENTS.md、design-system/AGENTS.md；涉及真实业务页面时同时读取 frontend/AGENTS.md。
2. 明确评审对象、用户目标、已有方案、目标页面或组件，以及本次是“仅评审”还是“评审并优化”。未授权修改时保持只读。
3. 找到权威实现与消费链路：设计 token、Foundation、真实组件、Showcase、前端消费页面。不要把静态视觉副本当成真实组件。
4. 优先检查可运行的真实页面，并收集 Light/Dark、关键交互状态和必要响应式尺寸的同条件证据。无法访问页面时使用已有截图和源码，并明确证据限制。
5. 阅读并使用 统一评分量表。

双专家独立评审

对实质性视觉评审，在平台支持时并行启动两名只读子 Agent，并向两者提供相同的目标、约束、页面证据和权威文档：

• 视觉与品牌专家：重点检查视觉层级、排版、颜色、间距、密度、节奏、品牌识别及 Light/Dark 协调。
• UX 与设计系统专家：重点检查信息架构、可发现性、操作路径、状态反馈、一致性、无障碍、响应式及落地风险。

两名专家必须独立工作，评审前不得看到对方结论，也不要预先告知主 Agent 偏好的方案。两者都使用同一量表、引用具体页面区域或组件，并分别给出分项分数、总分、问题优先级、保留项和建议。

若当前客户端不支持子 Agent，以相同证据完成两轮相互隔离的专家视角评审，并在结果中披露这一降级，不得伪装成独立 Agent 结论。

综合结论

主 Agent 对两份意见进行证据核对，而不是简单投票：

1. 合并两者一致确认的问题和应保留的设计。
2. 单独列出方向性分歧、总分相差超过 10 分的情况，以及各自依据。
3. 剔除违反权威设计规范、缺乏界面证据或超出产品范围的建议。
4. 按 P0/P1/P2 给出最小可行修改顺序，说明预期收益、影响范围和验证方式。
5. 对多个方案分别评分，不用平均分掩盖阻断性问题；P0 可以否决高总分方案。

最终报告必须包含：评审范围与证据、双专家评分表、共识、分歧、保留项、问题清单、推荐方案及是否建议进入实现。

从评审进入优化

• 仅评审：输出结论后停止，不修改代码、文档或线上状态。
• 评审并提出方案：可制作独立 Mock 或对比稿；Mock 不得冒充仓库设计文档，也不得建立第二套正式 token 或组件实现。
• 评审并实现：只有用户已经授权实现或确认方案后，才按照 design-system/AGENTS.md 从 Design System 的权威组件、token、Foundation 与 Showcase 开始修改。
• Design System 变更完成后必须经过人工目视确认，再验证真实前端消费效果；不得以两个专家的评分代替人工确认。

实现阶段完成后，按适用 AGENTS.md 检查设计文档同步和验证命令，并在交付中区分“评审建议”“已确认方案”“已实现结果”。