高级配色:用 HSL 与 OKLCH 调出舒服的 Codex 主题色
2026-10-05
Codex HSL 配色改起来轻松,是因为每个属性都能读懂:hsl(210 60% 45%) 一眼就是偏蓝、中等饱和、明度偏暗。相比之下,十六进制把红绿蓝压进六个字符,改一个字符三个通道一起动。这篇讲 HSL 和 OKLCH 怎么用在 Codex 主题上,老主题怎么迁,以及动手前该做哪些检查。
十六进制为什么不适合调色
一个色值把三个通道打包成六个字符。你改一个字符,红绿蓝同时移动,方向还不能从字符串上判断出来。想要「稍微深一点」,唯一办法是打开取色器碰运气。
- #3fb950 只告诉你这个绿在 sRGB 里的位置,不告诉你它看起来多亮
- 两个你以为亮度接近的颜色,到屏幕上可能差十几分
- 每次微调都要往返一趟取色器
- 字符串里没有任何线索提示你要改哪一位才能变暗
HSL 的三个数字分别管什么
hsl(210 60% 45%) 读出来是:偏蓝的色相、中等饱和度、明度落在中线以下。想更暗就把第三个数字往下拉,想更灰就把第二个往下拉。相信这层对应关系之后,整套配色可以手写出来,不用在取色器里反复点。
- 色相 hue:色轮上的角度,0 到 360。动它就换了颜色家族
- 饱和度 saturation:离灰有多远。0% 是灰,100% 是当前色域能吼到的极限
- 明度 lightness:黑与白之间的位置,也是你改得最多的一个
- 暗色主题里的正文,明度一般落在 70% 到 85% 之间
OKLCH 差在哪,值不值得换
OKLCH 是感知均匀的色彩空间:同一个明度数值,在不同色相上看起来就是一样亮,这件事 HSL 做不到。两段 HSL 都设成 60% 明度,黄色会比蓝色明显更亮;在 OKLCH 里它们基本对齐。做主题时这意味着你排的那条明度阶梯是真的阶梯。
第二个不同是它用彩度(chroma)替代饱和度。彩度不会被显示器色域裁掉,换色相时数值可以保持不变。代价在工具链:跑得动 Codex 的浏览器都能渲染 oklch(),但老一些的设计软件预览不了,所以每条 oklch() 声明上面最好留一行 hex 或 hsl() 兜底。
- oklch(65% 0.13 250):依次是明度、彩度、色相
- 明度是感知的,65% 在蓝色和黄色上读起来一样亮
- 彩度超过大约 0.37 就出了 sRGB,多数屏幕会直接裁剪
- 每条 oklch() 上面保留一行 hex 或 hsl() 作为兜底
把现有主题迁过去
- 先把主题文件里的颜色全列出来,注明每个填充的是哪个位置
- 逐个转成 HSL,记下得到的三个数字
- 按角色分组:背景、正文、语法高亮、强调色
- 先给每个角色定好明度阶梯,别急着动色相
- 结构定下来之后再迁到 OKLCH,一次转一个角色
提前发现问题的几个检查
- 拿正文明度和背景明度对比,OKLCH 下落差建议保持在 40 以上
- 眯眼看屏幕:两个语法颜色糊在一起时,动色相而不是动明度
- 把屏幕亮度调到很低再看一遍,低对比主题往往倒在这一步
- 亮色和暗色两套都要看,任何你漏掉的角色都会退回默认值
- 留意滚动条和行号槽,它们通常是最晚被上色的地方
配色是主题里唯一每行代码都会碰到的部分,值得先花一小时把它排好。想对照成品可以直接翻开主题画廊 https://codex-skin-studio.shop/zh/gallery/ 里的现成预设,改完回到 https://codex-skin-studio.shop/zh/ 也能看到其余入口。
常见问题
主题该写成 OKLCH 还是继续用 hex?
打算长期调整的部分用 OKLCH,并在每条声明上面保留一行 hex 或 hsl() 兜底。已经定型、不会再改的主题用 hex 没问题。凡是还想手工微调的颜色,换成感知均匀的色彩空间之后会省很多事。
OKLCH 在所有能跑 Codex 的浏览器上都能用吗?
当前版本的 Chrome 和 Safari 都支持。Codex 通过 Chromium 渲染,所以只要你的 Codex 能跑,oklch() 就能解析。问题出在外部工具,老版本设计软件可能预览错误,这正是兜底那行存在的理由。
一套主题配色应该有多少个颜色?
舒服的区间是八个到二十个。少于八个,各种元素会挤在同几个位上互相打架;超过二十个,你维护的是读代码的人根本察觉不到的差别。
为什么我的 HSL 配色在不同色相上看起来深浅不均?
因为 HSL 的明度不是感知均匀的。60% 明度的黄色看起来比 60% 明度的蓝色亮得多。这正是 OKLCH 要解决的具体问题,也是结构定下来之后值得迁过去的原因。