前端设计读题与审查

工作模式

• review：默认模式。只报告具体视觉、层级、品牌和可用性问题，不修改文件。
• direction：给出一个推荐方向、关键设计语言和必要取舍，不生成多套泛化主题。
• implement：仅在用户明确要求修改页面时进入。沿用项目设计系统，修改后用实际渲染或截图复核。

最小流程

1. 确认模式、页面类型、受众、已有设计系统和用户给出的参考；只检查视觉外观时，不扩展到数据流或业务逻辑。
2. 用一句话声明页面理解和约束。若两个方向会产生实质不同结果，只问一个能决定方向的问题。
3. review/direction 模式按需阅读 审查与方向启发，只使用与当前页面有关的检查项。
4. review 模式基于真实截图、渲染结果或明确的代码位置排序问题；无法看到页面时说明证据缺口，不把代码推断写成已观察事实。
5. direction 模式只推荐一个方向，并解释它如何服务受众、品牌和使用频率。
6. implement 模式先记录现状和约束，再做最小修改；使用任何可用浏览器或渲染工具检查主要桌面视口、窄屏、溢出、遮挡、键盘焦点和关键交互状态。
7. implement 模式，或 review 需要给出具体 CSS、动效、组件或文案修改时，按需阅读 实现与交付检查：沿用已有组件、参考来源、默认禁用写法、动效、可访问性、内容真实性、渲染验证和选项。

如果用户给了明确设计稿且只要求机械实现，或问题只涉及 API、状态管理和业务逻辑，不使用本技能。后台工具仅需常规密度和可用性修正时，优先遵循项目已有设计系统。

输出要求

• review：页面理解、按影响排序的问题、证据位置和最小建议。
• direction：一个推荐方向、适用理由和关键设计变量；只有具体限制会改变选择时才说明。
• implement：修改内容、实际渲染视口和结果、未检查状态。

避免泛泛说“更现代”“更高级”；建议要落到布局、层级、颜色、字体、动效、资产或文案。没有实际渲染证据时，只能报告代码层修改，不能声称视觉结果已验证。