Appearance
理解色彩空间（如何表示颜色）与可访问性（如何让颜色可用），是把色彩理论落到实处的关键。本文梳理常用色彩空间、WCAG 对比度标准，并推荐 GitHub 上的优质配色工具。2026-09 更新：补充感知空间 OKLCH 与现代工具生态。
常用色彩空间
| 色彩空间 | 用途 | 说明 |
|---|---|---|
| RGB | 屏幕显示 | 红绿蓝三通道（0-255），相加混色，用于 CSS/hex |
| HEX | Web | RGB 的 16 进制表示（如 #FF5733） |
| HSL | 人眼直观 | 色相(H)+饱和度(S)+亮度(L)，调色模型的传统主流 |
| CMYK | 印刷 | 青品黄黑，相减混色 |
| LAB | 感知均匀 | 接近人眼感知，用于高精度色彩管理 |
| OKLCH / OKLAB | 现代感知空间 | 感知均匀性优于 LAB/HSL，色彩插值、渐变、生成的首选 |
为什么现代推荐 OKLCH 而不是 HSL：HSL 的 lightness（亮度）轴不符合人眼真实感知——同样步长的 HSL 亮度变化，肉眼看起来不均（"HSL lightness is a lie"）。OKLCH（由 Bjorn Ottosson 提出）基于感知均匀性设计，是 CSS Color 4 及主流色彩工具（Tailwind v4、Radix、Evan You 等）的新标准。做色彩插值、渐变、生成色阶时，应优先在 OKLCH 中运算，避免 HSL 的"假均匀"导致渐变发灰、色阶不均。HSL 仍可用于快速理解色相关系，但不应作为生成与插值的运算空间。
OKLCH 常见坑：超色域（Gamut Mapping）
OKLCH 最常见的使用错误是选了目标色域装不下的彩度：如 oklch(70% 0.3 150) 的彩度 0.3 超出了 sRGB（甚至 P3）能显示的范围，会被静默截断——结果通常变灰、色相偏移。
- CSS 会自动色域映射：浏览器对
oklch()/color()自动处理，写 CSS 很少出问题 - JS 转换不会：
oklch → hex这类转换是直接截断通道，不保留色相 - 正确做法：降彩度（chroma）而不是降明度/改色相——向色域边界收彩度能保住颜色身份；用 Culori 的
clampChroma(color, 'oklch')或toGamut()而非朴素的 RGB 截断 - 按目标测试：
inGamut('rgb')与inGamut('p3')结果不同——P3 合法不代表 sRGB 合法
（2026-09 由 color-expert 技能共识补充）
可访问性：WCAG 对比度
颜色不仅要好看，还要让所有人都能读。Web 内容无障碍指南（WCAG 2.1）规定文字与背景的对比度：
| 场景 | 最低对比度 |
|---|---|
| 正文 / 小字号文本 | 4.5 : 1 |
| 大文本（≥18pt 或 14pt 粗体） | 3 : 1 |
| UI 组件、图标、图形边界 | 3 : 1 |
要点：
- 不要只用颜色传达信息（如"红色=错误"），需配合图标/文字/形状
- 浅色背景用深色文字、深色背景用白字，保证对比度达标
- 对比度不能靠运气：实测约 281 万亿个随机 hex 颜色对中，仅约 11.98% 通过 WCAG AA（4.5:1）、约 0.08% 通过 APCA 90。AI 生成色板后必须显式校验，不能"看起来还行"就交付
- 下一代标准 APCA（感知对比算法，WCAG 3 基础）比 WCAG 2.x 的简单比值更贴近人眼，社区工具已可用
配色工具生态（GitHub）
直接教 AI 用色的项目（接入 AI 工作流首选）
| 工具 | 能力 | 仓库 |
|---|---|---|
| color-expert skill | Agent 技能：色彩命名/理论/空间/可访问性，144 篇参考（约 28.6 万字） | meodai/skill.color-expert（npx skills add meodai/skill.color-expert） |
| design-for-ai | Claude Code 插件：教 AI 版式/色彩/构图，内置 OKLCH 色板生成器 | ryanthedev/design-for-ai |
| AI-color-system | 品牌情感词 → 完整 UI 色彩系统（亮/暗双模式 + WCAG AA 校验） | yuqizhang1228-blip/AI-color-system |
色彩科学引擎（转换/运算）
| 工具 | 能力 | 仓库 |
|---|---|---|
| color.js | CSS Color 规范编辑者维护的转换/运算库 | color-js/color.js |
| culori | 轻量色彩运算库（clampChroma 处理超色域、OKLCH 全套操作） | culori/culori |
| oklch-picker | OKLCH 感知空间取色器 | evilmartians/oklch-picker |
| spectral.js | Kubelka-Munk 颜料物理混合 | rvanwijnen/spectral.js |
| colorcet | 感知均匀 colormap（科学绘图） | holoviz/colorcet |
| color-space | 色彩空间集合 | colorjs/color-space |
调色板生成器（真算法生成，非预设色卡）
| 工具 | 能力 | 仓库 |
|---|---|---|
| tints.dev | 11 色阶生成器 + API（Tailwind 系） | SimeonGriggs/tints.dev |
| poline | 笛卡尔空间 HSL 插值生成 | meodai/poline |
| palx | 自动 UI 调色板 | jxnblk/palx |
| harmony | 和谐色板 | evilmartians/harmony |
| dittoTones | 复制 Tailwind/Radix 设计系统的感知 DNA | meodai/dittoTones |
| smart-color-palette-generator | 按和谐规则（Analogous/Triadic 等）生成 | Hhhpraise/smart-color-palette-generator |
对比度与无障碍校验
| 工具 | 能力 | 仓库 |
|---|---|---|
| radix-ui/colors | 可访问色彩系统 | radix-ui/colors |
| SAPC-APCA | 感知对比算法（WCAG 3 基础） | Myndex/SAPC-APCA |
| gka/palettes | 感知正确 + 色盲安全 | gka/palettes |
| apca-w3 | APCA 规范落地版 | Myndex/apca-w3 |
设计系统落地：语义 Token 层
色彩进入产品/设计系统时，不要直接在各处写死 hex 值，按三层结构组织（2026-09 由 color-expert 技能共识补充）：
- Reference Token（参考色板）：定义具体颜色值，如
ref.red = #f00 - Semantic Token（语义角色）：把意义映射到颜色，如
semantic.warning = ref.red——主题换色只改这一层 - Component Usage（组件消费）：组件只引用语义 token，不碰原始色值
编码决策而非冻结数值：文字色 = bestContrastWith(surface, palette)（色板重生成时自动重算）、强调色 = mostVivid(palette, {minContrast: 4.5})、hover = colorMix(accent, ink, 0.12)（按底色明度自适应明暗）。这样色板重生成后，整个系统仍然可读、不塌陷。
落地工具：CSS 用
var()+color-mix()+ 相对颜色语法；设计 token 可用 Design Book（npm install design-book，约束式 token 图）。
一句话总结
色彩落地就三件事：运算一律放 OKLCH（HSL 的 lightness 是假的）、对比度过 WCAG 4.5:1、设计系统走 Reference→Semantic→Component 三层 token。
关联概念
- 基础：色彩理论-基础与色轮（色轮与配色方案）
- 实战：色彩理论-AI用色指南（给 AI 的 7 条可执行用色原则）
- 应用：设计类 Agent / 工具界面同理可参考