长时间盯着物流调度台、仓储管理界面的操作员，每天面对密集的数据表格和状态标签，眼睛酸涩几乎是标配。京东物流用户设计部在 B 端色彩体系上的沉淀，指向一个核心命题：色彩不只是"好看"，它是信息层级和认知负荷的工程问题。
B 端视觉疲劳的根源
B 端界面和 C 端最大的区别不是审美偏好，而是使用时长和信息密度。一个仓储管理员可能连续操作 8 小时，页面同时呈现几十列数据、多种状态标签、嵌套弹窗。在这种场景下：
- 高饱和度的强调色持续刺激视网膜，加速疲劳
- 缺乏灰阶过渡的黑白对比，让边界识别变得吃力
- 状态颜色没有统一语义，每次切换页面都要重新"学习"颜色含义
京东物流设计团队在梳理现有界面后发现，不同模块对"警告"的定义至少出现了 4 种红色——饱和度、明度各不相同，用户无法形成稳定认知。这比"丑"更严重：它直接拖慢操作判断。
科学色彩系统的三层结构
一个可落地的 B 端色彩系统，至少需要三层：
| 层级 | 内容 | 作用 |
|---|---|---|
| 品牌层 | 主品牌色 + 1-2 辅助色 | 强化京东物流品牌印象，出现在导航、Logo、关键按钮 |
| 功能层 | 语义色（成功/警告/错误/信息）+ 中性色阶 | 信息传达，状态标识，降低认知成本 |
| 场景层 | 低饱和变体、暗色模式适配 | 长时间使用场景下的疲劳缓解 |
关键决策点：品牌色可以高饱和，但功能色必须克制。京东物流的品牌红在 Logo 和首屏导航上出现一次就够了；表格里的 200 个状态标签，应该用降低饱和度后的变体。
用 Design Token 把色彩系统工程化
色彩系统如果只停留在 Figma 文件里，前端落地时必然走样。京东物流的做法是建立 Design Token 体系，让设计决策以结构化数据的形式贯穿设计到开发。
下面是一个可直接用于项目的 Design Token 配置示例（JSON 格式，兼容 Style Dictionary 等工具链）：
{
"color": {
"brand": {
"primary": { "value": "#E2231A", "comment": "京东物流品牌红，仅用于Logo和主导航" },
"primaryLow": { "value": "#FDE8E6", "comment": "品牌红低饱和背景，用于hover/浅底色" }
},
"semantic": {
"success": { "value": "#2DA44E", "comment": "操作成功、已完成状态" },
"successLow": { "value": "#E6F9E6", "comment": "成功状态浅底色" },
"warning": { "value": "#D4A017", "comment": "需关注、待处理状态" },
"warningLow": { "value": "#FFF3CD", "comment": "警告状态浅底色" },
"error": { "value": "#CF222E", "comment": "错误、失败、超时状态" },
"errorLow": { "value": "#FFEBE9", "comment": "错误状态浅底色" },
"info": { "value": "#0969DA", "comment": "提示、帮助信息" },
"infoLow": { "value": "#DDF4FF", "comment": "信息状态浅底色" }
},
"neutral": {
"gray1": { "value": "#F6F8FA", "comment": "表格斑马纹背景" },
"gray2": { "value": "#EAEEF2", "comment": "分割线、卡片边框" },
"gray3": { "value": "#CCD1D6", "comment": "禁用态边框" },
"gray4": { "value": "#8B949E", "comment": "次要文字、placeholder" },
"gray5": { "value": "#57606A", "comment": "正文文字" },
"gray6": { "value": "#24292F", "comment": "标题文字" }
}
}
}
用 Style Dictionary 将这份 JSON 转成多平台输出：
# 安装 Style Dictionary
npm install style-dictionary --save-dev
# 初始化配置
npx style-dictionary init
# 构建——自动生成 CSS 变量、SCSS 变量、JS 常量等
npx style-dictionary build
构建后产出的 CSS 自定义属性，可以直接在组件中使用：
/* style-dictionary 自动产出 */
:root {
--color-brand-primary: #E2231A;
--color-brand-primary-low: #FDE8E6;
--color-semantic-success: #2DA44E;
--color-semantic-success-low: #E6F9E6;
--color-semantic-warning: #D4A017;
--color-semantic-warning-low: #FFF3CD;
--color-semantic-error: #CF222E;
--color-semantic-error-low: #FFEBE9;
--color-neutral-gray1: #F6F8FA;
--color-neutral-gray5: #57606A;
--color-neutral-gray6: #24292F;
}
/* 组件中使用 Token，而非硬编码颜色 */
.status-tag--success {
color: var(--color-semantic-success);
background: var(--color-semantic-success-low);
}
.data-table tr:nth-child(even) {
background: var(--color-neutral-gray1);
}
这样做的好处：设计师调整 Token JSON，前端零改动自动同步。色彩系统从"口头约定"变成"版本化数据"。
缓解疲劳的三个实操策略
1. 功能色降饱和，品牌色收范围
B 端界面上 80% 的面积应该是中性色，品牌色只在导航栏和主操作按钮上出现。功能色的饱和度建议控制在 60%-70%，比品牌色明显"退一步"：
/* 品牌色：全饱和 */
.btn-primary {
background: var(--color-brand-primary); /* #E2231A, 鲜明 */
}
/* 功能色：降饱和变体——更柔和，长时间注视不刺眼 */
.alert-warning {
color: var(--color-semantic-warning); /* #D4A017, 饱和度约65% */
background: var(--color-semantic-warning-low);
}
2. 用灰阶梯度替代黑白硬切
表格斑马纹、卡片边框、分割线——这些"结构色"不要用纯黑纯白，而是用 6 级灰阶过渡。上面 Token 中的 gray1 到 gray6 就是这个用途。视觉上边界柔和，眼球不需要频繁做强对比切换。
3. 语义色全局统一，一处定义处处一致
"警告"在调度页面是黄色，在库存页面变成橙色——这种不一致比颜色本身更让人疲劳。Design Token 的语义命名强制全局统一：只要用 --color-semantic-warning，任何模块的警告态都是同一个色值。
落地检查清单
在项目里推行色彩系统时，可以按这个清单逐项确认：
- [ ] 品牌色是否只在 ≤3 种组件上使用（导航、主按钮、Logo）？
- [ ] 功能色是否每个语义只有 1 个色值 + 1 个浅底色变体？
- [ ] 中性色是否至少有 4 级灰阶，覆盖背景、边框、次要文字、正文？
- [ ] Token 是否以结构化数据维护，而非散落在各组件 CSS 里？
- [ ] 是否有暗色模式 Token 集合（将品牌色和功能色进一步降低明度）？
- [ ] 新页面走查时，是否用 Token 变量而非硬编码 hex 值？
色彩系统的价值不是让界面"更漂亮"，而是让操作员在第 6 小时依然能快速识别状态、不误读数据。把配色当成工程问题来做，用 Token 管理决策、用灰阶缓解对比、用语义色统一认知——这三件事做到，视觉疲劳的改善是可量化的。