寫作 / UI 中的問題分三層、不同層需要不同修法：

核心：修視覺工具預設錯誤就在視覺層。當症狀其實來自語意 / 邏輯層、用視覺工具修 = 蓋掉表面、根因還在 + 作者誤以為解決了（false confidence、跟 #82 的 hook 心理同病）。

修法的順序是 深層 → 淺層：先問「是不是邏輯 / 語意層的下游症狀」、是的話改結構；確認純視覺、再用視覺工具。

為什麼視覺工具對語意 / 邏輯問題無能為力

視覺工具（CSS、emoji、顏色、字體、間距、圖示）的本質是 呈現層的調整 — 它能改變字怎麼顯示、不能改變字本身代表的概念。能改的、跟改不到的、有清楚的界線：

能改的（純呈現）：

• 文字在窄視窗會不會換行
• 兩個區塊的視覺距離
• 不同類型用什麼顏色標

改不到的（結構 / 語意 / 邏輯）：

• 兩個概念該不該擠在同一行（結構層）
• 用 emoji 區分是否足夠承載語意（語意層）
• 論證有沒有完整（邏輯層）

當作者試圖用視覺工具解語意 / 邏輯問題、結果是 症狀被表面平整、但下次同類問題會用新形狀冒出來 — 因為根因（概念混淆 / 結構錯位）沒動。

反模式：用視覺修補蓋住下游症狀

False confidence 比沒修更危險

修了 CSS 之後、心理上會覺得「處理完了」。實際上 CSS 只擋了表面斷行、語意混淆照舊存在 — 但作者不再警覺、因為「我修過了」。

下一個讀者在不同 viewport / 不同設備 / 用螢幕閱讀器時、同樣的語意問題會用不同形狀重新出現（換行錯位、TTS 讀錯、複製貼上格式跑掉）。

第二行是最危險組合 — 跟 #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 規則膨脹同骨。

三層優先序：邏輯 → 語意 → 視覺

為什麼是這個順序

深層問題的影響範圍大、修不到根因的代價高。所以修法順序是先問深層、確認沒問題再修淺層。

修法的順序

 1看到症狀
 2   ↓
 3這是邏輯層問題嗎？（兩個獨立概念被擠在一起？論證有缺口？）
 4   是 → 重新分概念 / 補論證、結構改了之後語意 / 視覺問題自然消失
 5   否 → 下一層
 6   ↓
 7這是語意層問題嗎？（依賴視覺標記傳達唯一資訊？emoji 是唯一區分？）
 8   是 → 改表達結構、加文本標籤、用列表 / 分段
 9   否 → 下一層
10   ↓
11純視覺問題（容器寬度、字體大小、顏色對比）
12   是 → CSS / media query / 渲染配置

反向（從視覺往邏輯推）會 false confidence：先用 CSS 補了、表面平整、誤以為解決了、下次換 context 復發。

何時視覺修補真的足夠

某些情境純視覺就夠、用 CSS 是對的：

五類共通：內容本身沒爭議、只是顯示方式要調。其他情境視覺工具都會在某個時點走到 ceiling。

識別 ceiling：什麼時候該換手段

ceiling 訊號：

看到任一訊號、不是「再加一條 CSS / 換個 emoji」、是 接受視覺工具對這個層次的問題無能為力、改修結構。

跟其他抽象層原則的關係

本卡是 #82 的 sibling — 兩者都在說「工具有能擋的層 / 擋不到的層、超出 ceiling 是 false confidence」。組合理解：

套用到本系統的 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 當成獨立檢查維度。

判讀徵兆

核心：視覺工具的 ROI = 跟問題層次對齊 × 不超出 ceiling。CSS / emoji / 顏色不會理解語意、所以只能擋呈現；語意 / 邏輯問題需要改結構 / 改概念分組、不靠視覺工具。試圖用視覺工具蓋語意 / 邏輯問題 = 假裝修了、實際比沒修更危險（false confidence 阻止下次警覺）。