F5.13.1Color scale resolution设计
色阶级数需要在精细控制与维护成本之间取舍
别名: 色档数量 · 13 档色阶 · palette resolution
概念解释
一套蓝做成 13 档，悬停、按下、禁用、洗底都能精确落到某一档。三个月后，每个色相都要在浅色、深色、高对比里各维护 13 个值，还要给每档找合法前景，没人改得动。色阶级数是分辨率：档越密，局部越好控，整表越贵。要按真会用到的状态数来取，而不是按生成器默认输出多少档。
机制
维护成本随「色相数 × 主题数 × 档数 × 要配对的前景」涨，不是随档数线性涨那么简单。多出来的档若没有对应状态，会变成设计师的玩具——同一悬停，有人用 400，有人用 450，组件开始分叉。档太少则多个状态挤在同一枚色上，按下和禁用分不开。合适的分辨率是「每个需要被叫出名字的状态有独立的一档，再留很少的空档给将来」，不是「看起来很专业的十二条」。
生成便宜、维护贵。算法一秒出 21 档，评审和回归跟不上，多出来的档会在产品里老化：没人敢删，也没人记得为什么在。
边界
- 只有一两个色相的极小产品，多档的成本几乎为零，可以密一点。
- 数据可视化的连续色标是另一套尺子，不该和界面状态色阶比档数。
- 高对比主题往往用不了那么多中间档，同一产品可以浅色密、高对比疏，但要承认两套分辨率，不能假装还是 13。
怎么落地
- 先列出状态：默认填充、悬停、按下、禁用、浅洗、深字。状态有几类，档就从这里加起，而不是从 50–950 的模板加起。
- 新档必须写用途；写不出用途的档不进表。
- 每个季度数实际被引用的档，长期零引用的合并掉。
- 验证办法：打开色阶表，遮住编号，问每个色块「它在产品里干什么」；答不上来的那些就是多出来的分辨率。