視覺手段對齊錯誤層次：CSS / emoji 修不到語意 / 邏輯問題
結論
寫作 / UI 中的問題分三層、不同層需要不同修法：
| 問題層次 | 例子 | 適合手段 | 不適合手段 |
|---|---|---|---|
| 邏輯 | 概念劃分混亂、論證不完整、兩個概念擠在一行 | 重新分概念、改結構 | CSS / 排版 / emoji（蓋不到根因） |
| 語意 | 用 emoji 作為唯一區分、用顏色傳達唯一資訊、用視覺替代結構 | 改表達結構、用文本標記、加分段 | CSS 規則（false confidence） |
| 視覺 | 容器寬度、字體大小、顏色對比、跨瀏覽器排版 | CSS、media query、渲染工具 | 改文章結構（過殺） |
核心：修視覺工具預設錯誤就在視覺層。當症狀其實來自語意 / 邏輯層、用視覺工具修 = 蓋掉表面、根因還在 + 作者誤以為解決了（false confidence、跟 #82 的 hook 心理同病）。
修法的順序是 深層 → 淺層：先問「是不是邏輯 / 語意層的下游症狀」、是的話改結構；確認純視覺、再用視覺工具。
為什麼視覺工具對語意 / 邏輯問題無能為力
視覺工具（CSS、emoji、顏色、字體、間距、圖示）的本質是 呈現層的調整 — 它能改變字怎麼顯示、不能改變字本身代表的概念。能改的、跟改不到的、有清楚的界線：
能改的（純呈現）：
- 文字在窄視窗會不會換行
- 兩個區塊的視覺距離
- 不同類型用什麼顏色標
改不到的（結構 / 語意 / 邏輯）：
- 兩個概念該不該擠在同一行（結構層）
- 用 emoji 區分是否足夠承載語意（語意層）
- 論證有沒有完整（邏輯層）
當作者試圖用視覺工具解語意 / 邏輯問題、結果是 症狀被表面平整、但下次同類問題會用新形狀冒出來 — 因為根因（概念混淆 / 結構錯位）沒動。
反模式：用視覺修補蓋住下游症狀
False confidence 比沒修更危險
修了 CSS 之後、心理上會覺得「處理完了」。實際上 CSS 只擋了表面斷行、語意混淆照舊存在 — 但作者不再警覺、因為「我修過了」。
下一個讀者在不同 viewport / 不同設備 / 用螢幕閱讀器時、同樣的語意問題會用不同形狀重新出現（換行錯位、TTS 讀錯、複製貼上格式跑掉）。
| 狀態 | 警覺度 | 同類問題復發率 |
|---|---|---|
| 沒修任何東西 | 高（看到症狀） | 中 |
| CSS 修了視覺、根因（語意混淆）還在 | 低（誤以為修了） | 高（換 context 就復發） |
| 改結構修了根因 | 適中 | 低 |
第二行是最危險組合 — 跟 #82 的「Hook 抓不到的範圍誤以為有保護」同病。
症狀堆疊：「再加一條 CSS 規則」永遠補不完
視覺修補的直覺反應是「加一條規則」。但語意 / 邏輯下游的症狀無限多、規則永遠補不完。實際軌跡：
1emoji 在窄 viewport 斷行
2 → 加 white-space: nowrap
3 → 文字溢出容器
4 → 加 overflow: hidden
5 → 文字被截斷看不見
6 → 加 text-overflow: ellipsis
7 → 螢幕閱讀器讀出「...」沒語意
8 → 加 aria-label 補語意
9 → 翻譯版本 aria-label 沒翻
10 → ...每加一層 CSS、根因（兩個概念擠在一行）更深埋、修起來更貴。
→ CSS 規則膨脹是「用錯工具」的訊號、不是「規則寫得不夠細」的訊號。跟 #82 的 hook 規則膨脹同骨。
三層優先序：邏輯 → 語意 → 視覺
為什麼是這個順序
| 層次 | 影響範圍 | 修起來成本 | 修不修的代價 |
|---|---|---|---|
| 邏輯 | 整篇 / 整個 feature 的可理解性 | 高（要重新分概念） | 高（讀者根本看不懂、抓不到重點） |
| 語意 | 段落 / 區塊的表達精度 | 中（要改結構） | 中（讀者抓得到但要花力氣推） |
| 視覺 | 局部呈現 | 低（改 CSS / 排版） | 低（讀者覺得醜、但能讀） |
深層問題的影響範圍大、修不到根因的代價高。所以修法順序是先問深層、確認沒問題再修淺層。
修法的順序
1看到症狀
2 ↓
3這是邏輯層問題嗎？（兩個獨立概念被擠在一起？論證有缺口？）
4 是 → 重新分概念 / 補論證、結構改了之後語意 / 視覺問題自然消失
5 否 → 下一層
6 ↓
7這是語意層問題嗎？（依賴視覺標記傳達唯一資訊？emoji 是唯一區分？）
8 是 → 改表達結構、加文本標籤、用列表 / 分段
9 否 → 下一層
10 ↓
11純視覺問題（容器寬度、字體大小、顏色對比）
12 是 → CSS / media query / 渲染配置反向（從視覺往邏輯推）會 false confidence：先用 CSS 補了、表面平整、誤以為解決了、下次換 context 復發。
何時視覺修補真的足夠
某些情境純視覺就夠、用 CSS 是對的：
| 情境 | 為什麼 CSS 夠 |
|---|---|
| 跨 viewport 排版適配（手機 / 桌面） | 內容沒變、只是顯示尺寸要適配 |
| 字體大小 / 行高 / 顏色對比 | 純呈現參數 |
| 容器溢出 / 滾動條 / 換行控制 | layout 行為 |
| 跨瀏覽器渲染差異 | 引擎差異、不是內容問題 |
| 主題切換（dark / light mode） | 純呈現變數 |
五類共通：內容本身沒爭議、只是顯示方式要調。其他情境視覺工具都會在某個時點走到 ceiling。
識別 ceiling：什麼時候該換手段
ceiling 訊號：
| 訊號 | 該換的手段 |
|---|---|
| 「修了 CSS、換個 viewport / 設備又壞了」 | 不是純視覺、有結構問題、改結構 |
| 「加了 CSS rule 但又冒出新症狀」 | 症狀堆疊、退回問層次 |
| 「emoji / 顏色 / 圖示是唯一區分方式」 | 語意層問題、加文本標記 |
| 「需要 aria-label 補語意才能讀懂」 | 結構層問題、aria 是補丁、根本要重排 |
| 「同樣的內容、列表 vs 引用區塊閱讀差很多」 | 結構層問題、選擇承載結構錯了 |
| 「螢幕閱讀器讀出來的順序跟視覺順序不同」 | 視覺順序跟邏輯順序錯位、改 DOM order |
| 「複製貼上後格式跑掉、語意也跟著跑掉」 | 依賴視覺渲染傳語意、把語意寫進文本 |
看到任一訊號、不是「再加一條 CSS / 換個 emoji」、是 接受視覺工具對這個層次的問題無能為力、改修結構。
跟其他抽象層原則的關係
| 原則 | 關係 |
|---|---|
| #82 字面攔截 vs 行為精煉 | 本卡的 sibling — #82 是「驗證工具 vs 錯誤層次」、本卡是「呈現工具 vs 內容層次」、同骨不同領域 |
| #83 Writing 的 multi-pass review | 本卡是 #83 缺的垂直軸 — #83 的 5 輪是 horizontal frame、本卡的 3 層是 vertical layer、兩軸正交 |
| #67 寫作便利度跟意圖對齊反相關 | 用 emoji 區分概念是「便利寫法」、改結構是「對齊意圖」 — 本卡是 #67 在呈現選擇上的具體實例 |
| #44 Single Source of Truth | 用 emoji 替代結構區分 = 把語意分散在「文字 + emoji」兩處、違反 SSoT、emoji 不渲染時語意就遺失 |
| #39 Native HTML 優先於 ARIA role | 同骨：semantic HTML 把語意寫進結構、ARIA 是補丁；emoji 是視覺補丁、文本標記 / 列表是 semantic 結構 |
| #56 視覺完成 ≠ 功能完成 | 本卡是 #56 在「呈現層」的擴展 — 視覺驗收訊號早於語意驗收成立、容易誤判修好 |
| #80 Yes/No 二選是隱式 collapse | 「emoji 區分」是把多概念 collapse 進視覺維度、跟 yes/no collapse 同骨（多維度被壓成 1 維） |
本卡是 #82 的 sibling — 兩者都在說「工具有能擋的層 / 擋不到的層、超出 ceiling 是 false confidence」。組合理解：
| 軸 | #82 | 本卡 |
|---|---|---|
| 領域 | 驗證 / 防呆 | 呈現 / 寫作 |
| 工具 | hook / lint / CI | CSS / emoji / 顏色 / 排版 |
| 該擋的層 | 字面（typo / schema） | 視覺（容器 / 字體 / 顏色） |
| 抓不到的層 | 行為（思考偏差） | 語意 / 邏輯（概念 / 結構） |
| False confidence | 「CI 通過 = 沒事」 | 「視覺修了 = 沒事」 |
| 規則膨脹 | 「再加一條 lint 規則」 | 「再加一條 CSS rule」 |
| 正解 | multi-pass review / spiral | 改結構 / 重新分概念 |
套用到本系統的 case
Case 1：blog 文章 mermaid + emoji 圖例
寫 git rebase 搬部分檔案 文章時、用 mermaid gitGraph 配 emoji 圖例：
1> 🟢 HIGHLIGHT = 接收檔案變更的目標 commit（A）
2> 🔴 REVERSE = 含有不該屬於它的檔案變更的 commit（C）某 viewport 下 emoji 跟文字之間斷行錯位、🔴 在前一行、REVERSE = … 在下一行。
第一直覺（錯）：修 emoji 渲染、加 white-space: nowrap。
追問層次：
- 視覺層：emoji 斷行 → 改 CSS 可以擋
- 語意層：HIGHLIGHT 跟 REVERSE 是兩個獨立概念、被擠在
> 引用區塊的兩行 + 用 emoji 作為唯一區分 — emoji 不渲染（終端 / 老瀏覽器）就完全失語意 - 邏輯層：兩個獨立概念本就不該擠在引用區塊裡、引用區塊的語意是「附加說明」、但兩個概念都是主要資訊
根因在邏輯層：兩個概念該分開承載。
正解：拆成獨立列表項、每項獨立一個概念：
1**四個 commit 的角色**：
2
3- **A**（接收目標）：commit C 中對檔案的修訂應該屬於這裡
4- **C**（變更來源）：同時改了目標檔案和其他 6 個檔案修了之後、emoji 斷行、aria-label、複製貼上格式、螢幕閱讀器順序等所有下游症狀同時消失 — 因為根因被處理了。
Case 2：mermaid gitGraph type 顏色設定
跟 Case 1 同篇文章的另一個議題：mermaid 的 type: HIGHLIGHT / type: REVERSE 自訂顏色不渲染（mermaid_gitgraph_type_color_config）。
這個 是 純視覺問題 — 內容本身沒爭議、只是 mermaid themeVariables 缺配置。修 CSS / themeVariables 是對的。
兩個議題在同一篇文章、但層次不同 — 一個是邏輯層下游症狀（誤判為視覺）、一個是真視覺問題（CSS 修對位）。判讀層次比修法重要。
Case 3：multi-pass review 的層次盲點
#83 的 5 輪 frame（生成 / 意圖 / 語氣 / grep / 反例）是 horizontal — 同一份文字、5 個視角輪流看。但這 5 輪都可能落在同一個 vertical layer（例如全部在看視覺層）、漏掉語意 / 邏輯層。
本卡補的是垂直軸：每輪 frame 內、要意識到問題在哪一層。第 1 輪生成可能寫出語意混淆、第 2 輪對意圖如果只看視覺呈現、整個 review 就停在視覺層。
實際軌跡：blog 文章寫完跑了 #83 的多輪 review、catch 到 emoji 斷行（視覺層）、但沒 catch 到 HIGHLIGHT/REVERSE 概念混淆（語意層）— 因為每輪 frame 都沒把 layer 當成獨立檢查維度。
判讀徵兆
| 訊號 | 該做的事 |
|---|---|
| 看到視覺異常、第一直覺是改 CSS | 先問「換個 viewport / 設備會不會復發」、會的話是更深層 |
| 用 emoji / 顏色 / 圖示作為唯一區分 | 語意層問題、加文本標記 + 改結構 |
| 加了 CSS 但又冒出新視覺症狀 | 症狀堆疊、退回問層次、根因在更深層 |
| 「需要 aria-label 補語意才能讀懂」 | 結構層問題、改 DOM order / 重排 |
| Multi-pass review 跑了、但只 catch 視覺問題 | layer 沒當獨立維度、補垂直軸檢查 |
| 一個改動「視覺好了、但語意感覺怪」 | 語意層問題沒解、別停手 |
| 「之後在不同設備 / 螢幕閱讀器再驗證」 | 是 #72 結構性跳過、補 trigger |
| Commit 訊息只寫「fix layout / fix emoji」 | 訊息層級停在視覺、檢查根因是不是更深 |
核心：視覺工具的 ROI = 跟問題層次對齊 × 不超出 ceiling。CSS / emoji / 顏色不會理解語意、所以只能擋呈現；語意 / 邏輯問題需要改結構 / 改概念分組、不靠視覺工具。試圖用視覺工具蓋語意 / 邏輯問題 = 假裝修了、實際比沒修更危險（false confidence 阻止下次警覺）。