色阶的价值在于形成一套可复用关系
UI Colors 从基础色生成由浅到深的多个等级，并把结果放进真实组件和页面示例中。相比只挑五个看起来协调的色块，这种方式更容易分配背景、边框、悬停、正文和强调状态，也能直接映射到 Tailwind 项目。
我不会把生成结果原样全部投入设计系统。先选一个主色，检查 50、100 是否适合淡背景，500、600 是否适合按钮，800、900 是否能承载深色文字，再删除用不到的等级。颜色令牌越多，团队越容易随意选错。
在组件预览中寻找对比问题
单独看色块时很漂亮的组合，放到小字号、禁用按钮或图表图例中可能难以阅读。利用网站、仪表盘和组件视图检查正文、链接、边框与状态色，并用对比度工具验证，不要只凭肉眼。
- 先定义主色用途，再输入品牌颜色；
- 分别检查浅背景、正文、按钮和悬停状态；
- 增加成功、警告、错误色时保持语义一致；
- 在亮色与深色模式中都验证文字对比度。
生成色阶之后还需要语义命名
组件代码如果到处写 blue-600，品牌换色会很痛苦。将最终色阶映射为 primary、surface、border、text、danger 等语义令牌，再由主题决定具体数值，维护起来更清楚。Tailwind 版本变化时也应核对配置格式。
若还在寻找多组配色灵感，可先用 Coolors 组合色相，再回 UI Colors 为关键颜色补齐层级。前者偏灵感和组合，后者偏系统化色阶，使用阶段不同。
颜色系统要接受内容和设备的检验
把示例中的占位文字换成真实中文标题、长段落、表格和错误信息，再看密集页面是否仍清晰。低质量屏幕、户外亮光和色觉差异都会改变体验，因此状态不能只靠颜色表达，还应配合文字或图标。
导出后保存基础色、生成日期和手工调整记录。UI Colors 能加快第一版，但最终设计系统仍要由真实组件、无障碍要求和品牌规则共同决定。不要为了让色阶数学上整齐，牺牲按钮可读性或信息层级。
