把橘色帶進淺色模式

Published: 2026 Jul 19 1 min read

起因

深色模式是這個部落格的「本體」：深藍 navy 底、橘色強調、連 header 底線和 hr 都是橘線，很有個性。但某天切到淺色模式一看——白底、藍色連結、灰色邊線，跟深色模式放在一起根本像兩個不同的網站。

追了一下原因，其實很單純：淺色模式從來沒被設計過。它就是 Astro Paper 佈景主題的預設淺色皮膚，當初只調了深色那一半，淺色一直原封不動。

檢視現況

好消息是全站顏色都收在 src/styles/global.css 的五個 CSS 變數裡，兩套定義一對照，問題一目了然：

Token	淺色（佈景預設）	深色（有調過）
`--background`	`#fdfdfd` 中性白	`#212737` 深藍 navy
`--foreground`	`#282728`	`#eaedf3`
`--accent`	`#006cac` 藍	`#ff6b01` 橘
`--muted`	`#e6e6e6` 中性灰	`#343f60` 藍灰
`--border`	`#ece9e9` 幾乎隱形	`#ab4b08` 深橘

--accent 影響的範圍最大：文章標題連結、hover、導覽列的波浪底線、清單 marker、blockquote 邊線、反白選取、focus 外框全部吃這個變數。identity 的斷裂主要就是它。

順便挖出兩個小發現：

PostGroup.astro 裡硬編了一堆 text-stone-600、text-black，是唯一脫離 token 系統的元件——結果一查根本沒有任何頁面在用它，是佈景遺留的殭屍元件。
typography.css 裡引用的 --shiki-light / --shiki-dark 變數其實不存在（astro.config.mjs 沒設 shikiConfig），所以程式碼區塊在兩種模式都是 github-dark。淺色模式下它是一塊深色島，這次先當作設計特色保留。

決策：把橘帶進淺色

方向有兩個：重新選一組兩種模式共用的 accent，或是把深色的橘帶進淺色。選了後者，因為 navy 加橘就是這個部落格現在的個性，沒理由丟掉。

但橘色不能直接搬。#ff6b01 在白底上的對比只有 2.8:1，連 WCAG AA 的 4.5:1 都過不了，當內文連結色會很吃力。所以拿同色相往深一階找：

#ff6b01 - 對比 2.8:1，不合格
#b45309 - 4.9:1，偏黃棕
#c2410c - 5.0:1，合格 <— 選了這個

其餘四個 token 跟著同一套邏輯調整——不改變亮度結構，只把色溫從中性拉向暖色，跟橘色 accent 呼應：

:root {
  --background: #fdfbf8; /* 中性白 -> 暖白 */
  --foreground: #282728; /* 不動 */
  --accent: #c2410c;     /* 藍 -> 橘（AA 合格） */
  --muted: #ede4da;      /* 中性灰 -> 暖灰（inline code 背景） */
  --border: #e8ccae;     /* 隱形灰 -> 焦糖色，呼應深色模式的橘線 */
}

--border 是意外的亮點。深色模式最有記憶點的元素就是那幾條橘色的 header 底線和 hr，淺色原本的 #ece9e9 根本看不見；換成焦糖色之後，「同一個網站」的感覺立刻出來了。

另外把殭屍元件 PostGroup.astro 的硬編顏色也一併改成 text-foreground 系列的 token，就算哪天又被撿回來用也不會走鐘。

成果

淺色模式：暖白底、橘色標題連結、焦糖色分隔線
深色模式：一個位元組都沒動
兩邊放在一起，終於像同一個部落格的日夜兩面

總結

這次的改動本體只有五行 CSS 變數，但前面的檢視花的時間比動手多：確認 token 的影響範圍、算對比度、排除殭屍元件的干擾。設計系統把顏色收斂在一處的好處在這種時候特別明顯——換皮只要換 token。

程式碼區塊的深色島和 shiki 雙主題的 dead code 這次先放著，之後想處理淺色 code block 的話再開一篇。

這次用的是 Claude Code 加上 Claude Fable 5，從檢視、討論配色到改完驗證在一個 session 內完成，順便產出這篇文章。