design-system-ui

设计系统 UI

构建符合产品现有组件、视觉风格和交互模式的 UI。

对于多步骤工作，首先简短告知用户你将先检查哪个产品背景。

目标

让用户更容易阅读和使用所请求的屏幕或组件，同时保持其与产品其他部分一致。通过层级、分组、间距和交互反馈，支持其主要任务。

上下文预算

编码前，只检查让 UI 与产品风格契合所需的上下文：

• 用途相似的相邻页面
• 共享组件和页面外壳
• 设计令牌、主题文件、Tailwind/CSS 配置和字体排版
• 间距、圆角、边框、阴影、表面、图标和动效
• 现有的加载、空、错误、禁用、焦点和响应式模式

只要对产品背景、可复用基础组件、样式系统和验证方式有足够了解，就停止探索。只有缺失的模式会实质影响正确性、视觉契合度或无障碍性时，才继续探索。

产品方向

对于常规生产环境变更，沿用产品既定方向，只针对所请求的界面解决必要的设计选择。小幅调整不需要引入新概念、新配色或标志性细节。

对于新屏幕或大幅重新设计，应根据现有背景确立简明的设计方向：

• 用途：界面要完成什么任务
• 用户：谁会使用界面，以及他们要作出什么决定或完成什么任务
• 现有模式：要沿用的布局、字体排版、颜色和交互
• 有效改进：能帮助用户完成任务的具体改动
• 特色细节（如有用）：简报中要求或支持的细节；不要只为让屏幕显得不同而添加装饰

只有在需要更多字体排版、布局、颜色、表面、动效或状态示例时，才使用 references/design-moves.md。

工艺标准

使用层级、对齐、分组、对比度和留白，让所请求的界面在产品背景中清晰易懂。对于页面级工作，先确定整体构图，再打磨细节；对于组件变更，检查其与周围页面的契合度，不要重新设计整个页面。仅应用恰当的设计令牌并不能保证视觉质量。请使用下方的视觉检查来指导优化。

约束

• 编写遵循项目规范且可实际运行的前端代码。
• 除非用户要求重新考虑，否则将用户提供的文案、业务声明、交互含义、截图和现有信息架构视为产品约束。不要通过删除必需内容、弱化声明或改变产品语义来解决呈现问题。
• 将变更限制在所请求的屏幕和组件内。只有在有证据表明共享基础组件是问题根源，或所请求的结果确实需要时，才修改它；随后验证受影响的使用方。
• 优先使用现有基础组件、设计令牌、图标集、动画工具、无障碍 HTML、便于键盘操作的交互、响应式行为、清晰的组件结构和作用域明确的样式。
• 只有在能改善设计并自然融入产品系统时，才添加新的视觉基础组件。
• 不要为静态或同步内容引入异步行为、加载状态或布局偏移。
• 避免随意自定义样式、没有产品目的的装饰、现有基础组件足以满足需求时额外添加组件、默认使用居中的卡片布局、将每组内容都变成带边框的卡片、虚假的交互提示、畏缩而平均分布的颜色，以及把紫色渐变效果生硬套用到无关产品上。

没有明确设计系统时

只定义实现所请求界面所需的缺失视觉选项，例如颜色角色、字体层级、间距、控件样式，以及响应式或交互行为。小任务不需要完整的新设计系统。

通过少数明确的选择来保持一致，而不是叠加许多彼此无关的效果。

视觉验证

在可以访问时，通过真实的应用路由和交互检查实现效果。在优化过程中和最终验收时使用以下检查；如果相关实现、内容和状态没有变化，则重复利用已有观察结果：

• 使用有代表性的数据量、符合实际的本地化文案、较长的值，以及可能改变布局或交互模式的缩放条件。
• 检查相关视口尺寸下的响应式行为，以及工作引入或影响的可达状态，包括键盘和焦点行为。不要为了面面俱到而凭空设计状态。
• 检查整体布局和细节：视觉焦点顺序、分组、密度、留白、对齐、嵌套内边距、文本换行、基线、图标与标签组合，以及控件尺寸。与相邻产品界面比较，确保字体排印、表面样式和交互语言一致。
• 检查新增的表面、图标、徽标和反馈是否能传达有用的关联或状态。修正意外的空隙、布局偏移、误导性 affordance，以及干扰任务的装饰。

同时运行适用的代码验证，但不要把构建、类型检查或组件级测试当作视觉质量的证明。如果无法检查真实路由，请说明这一限制，并指出下一步最佳验证方式，而不是声称 UI 已得到全面验证。

输出

实现时，提供适用于用户技术栈且可直接运行的限定范围代码。在最终回复中，先说明已完成的结果，然后概述重要的设计选择、主要变更文件、执行的验证，以及会影响结果的假设。不要为常规更改另造概念。

停止规则

当所请求的界面已实现，影响行为、可用性、无障碍性、响应式表现或产品契合度的重要差异已解决，且适用的验证已完成或其限制已说明时，即可停止。进一步优化必须针对具体的剩余差异；不要仅为追求主观上的完美而反复调整位置或添加装饰。