better-colors

OKLCH 色彩

OKLCH 是一種感知均勻的色彩空間，其中明度、彩度與色相是實用的設計控制項。當專案已使用 OKLCH、建立新的色彩系統，或使用者要求轉換或色板工作時使用。否則請保留專案既有的 token 與標記法：一致的 hex 或 RGB token 系統，勝過為單一修正引入第二種色彩表示法。若要互動探索，請造訪 oklch.fyi。

快速參考

類別	使用時機	參考文件
轉換	Hex/rgb/hsl 轉 oklch	color-conversion.md
色板	產生色階、多色相、深色模式	palette-generation.md
對比度	APCA/WCAG 檢查、回報失敗、依要求修正	accessibility-contrast.md
色域與 Tailwind	P3 降級方案、@theme 色階、色域裁切	gamut-and-tailwind.md
使用方式	語意 token、一色一義、主要動作強調、外觀變體	color-usage.md

核心原則

1. 使用感知色彩空間

• 尊重既有系統。 不要因為載入此技能就轉換標記法。除非任務包含色彩系統遷移，否則請重複使用專案的語意 token 與撰寫格式。
• 感知均勻性。 相等的 L 步階 = 相等的亮度。oklch(0.5 ...) 在視覺上是中間值。HSL 的 lightness: 50% 會因色相而有劇烈變化。
• 穩定的色相。 HSL 藍色在明度變化時會偏向紫色。OKLCH 色相在整個明度範圍內保持不變。
• 獨立的彩度。 彩度是色彩鮮豔度的絕對度量，不依賴明度。HSL 的飽和度則不然。
• 有限的色域。 並非每個 oklch 值都能對應到可顯示的 sRGB 色彩。某些色相的高彩度值會被裁切；需要具備色域意識。

2. 一致地撰寫與格式化 OKLCH

oklch(L C H)
oklch(L C H / alpha)

通道	範圍	說明
L（明度）	0–1	0 = 黑色，1 = 白色。感知均勻。
C（彩度）	0–~0.4	色彩鮮豔度。0 = 灰色。最大值取決於 L 與 H。
H（色相）	0–360	色相角度，單位為度。
alpha	0–1	選擇性透明度。使用斜線語法。

oklch(0.637 0.237 25.331)
oklch(0.8 0.05 200 / 0.5)

L 與 C 使用三位小數，H 最多三位。去除尾隨零，並將 -0 格式化為 0。OKLCH 是 Baseline 2023；當支援需求異常廣泛時，請檢查目標專案的瀏覽器矩陣，而非依賴固定的全域覆蓋率百分比。

3. 測量對比度、色域與色板行為

規則	數值
淺色/深色邊界	L > 0.73 = 淺色背景 → 深色文字；低於此值時，淺色文字仍得分較高
明度差距（淺色背景）	背景 L > 0.9 時，前景 L < 0.35
明度差距（深色背景）	背景 L < 0.25 時，前景 L > 0.9
色相偏移閾值	色板各階之間色相差 > 10° = 可見偏移
APCA 正文	|Lc| >= 75 最低，>= 90 建議
APCA 非正文	|Lc| >= 60 最低
WCAG 2 一般文字	4.5:1 AA，7:1 AAA
對比度修正（僅在被要求時）	先調整 L；盡可能保留 C 與 H，然後重新測量渲染後的配對

常見錯誤

問題	修正方式
原始色彩繞過專案的語意 token 系統	以專案既有標記法重複使用或新增正確的角色 token
在 hex/RGB 程式碼庫中引入孤立的 OKLCH 值	保留既有標記法，除非任務包含色彩系統遷移
具有色相偏移的 HSL 色板漸層	以固定的 oklch 色相重建
對比度失敗（使用 APCA 檢查前景與其背景）	回報該配對、測得的 Lc 以及未達到的閾值；僅在被要求時才更改色彩（然後調整 L，保留 C 與 H）
高彩度未經色域檢查	裁切至 sRGB 中該 L/H 的最大彩度
不同色相使用相同的絕對 C 值	使用相同的 C%（最大值的百分比）以獲得一致的鮮豔度
P3 色彩沒有 sRGB 降級方案	加入 @media (color-gamut: p3) 模式
深色模式由機械式反轉淺色色板產生	以淺色色板為起點，然後調整彩度與明度，並重新檢查每個前景/背景配對
Tailwind v4 @theme 中使用 Hex	轉換為 oklch 值
使用逗號語法的 Alpha	使用斜線：oklch(L C H / alpha)
相同色相代表兩種不同意義（連結顏色重複用於裝飾）	一色一義；為第二種用途賦予中性色
語意 token 用於其角色之外（分隔線當作文字）	為缺少的角色新增 token；絕不借用數值
單一畫面中有多個彩色控制項背景	僅填滿單一主要動作；次要動作保持中性
色板僅在淺色模式下驗證	在兩種外觀下重新檢查每個前景/背景配對

審查輸出格式

僅在使用者要求獨立色彩審查時使用此格式。當 better-interface 協調審查時，請將領域證據與發現提供給該技能，並讓其輸出格式、嚴重性等級、合併規則、上限與結論優先。

以兩部分呈現獨立審查。

發現

按原則分組所有確認的發現。使用包含嚴重性、位置、修改前、修改後與原因欄位的 Markdown 表格。絕不使用獨立的「修改前：」/「修改後：」行。

• 嚴重性：HIGH 使內容無法閱讀或賦予誤導的語意色彩；MEDIUM 造成明顯的主題、色域或一致性失敗；LOW 為孤立的修飾問題。
• 位置：引用 path/to/file:line。若成品沒有原始檔案，則引用確切的畫面與元件。
• 修改前 / 修改後：顯示目前的值或 token 以及確切的取代內容。
• 原因：指出違反的原則，並在相關時包含測得的對比度或色域證據。

將重複的系統性問題合併為一行，並列出所有受影響的位置。省略沒有發現的原則。

嚴重性	位置	修改前	修改後	原因
MEDIUM	src/theme.css:18	color: #3b82f6	color: oklch(0.623 0.188 259.815)	新專案色彩使用 OKLCH token
MEDIUM	src/palette.ts:31	不同色相使用相同絕對 C 值	使用各色相最大彩度的相同 C%	相等的彩度值在不同色相下看起來並不同等鮮豔
HIGH	src/theme.css:52	P3 色彩無降級方案	在 @media (color-gamut: p3) 之前加入 sRGB 降級方案	該色彩在非 P3 顯示器上會失敗

驗證與結論

在發現之後：

1. 驗證：列出執行的確切檢查及其觀察結果，包括對比度測量、色域檢查，以及適當時的淺色與深色外觀。若某項檢查未執行，請說明仍需驗證的項目。
2. 結論：若仍有任何 HIGH 發現則為 Block；若僅有 MEDIUM 或 LOW 發現則為 Needs changes；僅在沒有任何可處理的發現時才為 Approve。

當沒有任何發現時，省略表格，陳述「無可處理的色彩發現」，回報驗證，並以 Approve 結束。