"抽象層" 2026-04-25
2 次門檻:第一次是運氣、第二次是訊號
同一個問題出現第 2 次時、就該停下來把處理層級升一階 — 從推理升到量測、從手動驗證升到自動化、從同方向嘗試升到換思路。第 1 次失敗的資訊不足、第 2 次提供「重複出現」的證據、值得付出升級成本。本文是 #11 / #15 / #20 / #23 四篇實作的共同抽象。 2026-04-25
最小必要範圍是 sanity 防線:保護行為可預測性
縮 selector 範圍、observer 範圍、JS 操作範圍 — 不是為了效能、是為了讓行為可預測、不被未來變動打破。本文是 #13 / #14 / #29 三篇實作的共同抽象。 2026-04-25
Single Source of Truth:值的住址只能有一處
同一個值(CSS token、視覺基準、runtime 量測)的權威來源只能有一個位置 — 多源時會分歧、會漏改、會讓讀者不知道哪個生效。本文是 #3 / #26 / #27 三篇實作的共同抽象。 2026-04-25
跟外部組件合作的層次:離介面越近、合作越穩
客製外部組件的穩定性與「離組件作者保證的對外介面多遠」成反比。每往內推一層、依賴前提增加、升級風險上升、可逆性下降。本文是 #1 / #5 / #19 / #24 四篇實作的共同抽象。 2026-04-26
寫作便利度跟意圖對齊反相關
寫程式時最容易寫出的版本、通常是離意圖最遠的版本。便利度建立在「現有上下文 / 已 materialize 資料 / 已存在 API」上、而意圖對齊需要找到正確的層、處理上游、跨抽象層 — 兩者方向相反。識別這個反相關 = 識別自己掉進「容易寫的陷阱」。 2026-04-26
Test-First:先看到 RED 才相信 GREEN
一個只看過 GREEN 的測試是「未驗證的訊號」、不是「會抓回歸的測試」。必須先在「該失敗的版本」上看到 RED、再在「該通過的版本」上看到 GREEN — 兩次跑都對、才能相信測試真的 catch 到該 catch 的東西。跳過 RED 等於把驗收標準降到「跑得通」、漏掉「測試自己有沒有 bug」這層。 2026-04-26
URL 是 stateful UI 的儲存層 — 哪些 state 該寫進 URL
互動式 UI 的 state 散落在多層(in-memory / URL / localStorage / server / index)、每層有不同特性。可分享 / 可恢復 / 可導航的 state 該寫進 URL — 不寫進 = silent 把這些特性犧牲掉。本文展開「state 的儲存層選擇」協議與 URL 的具體位置。 2026-04-26
Tab Order = DOM Order = Mental Model 三者對齊
Tab 順序由 DOM 順序決定(除非用 tabindex 強制覆寫)。三者該對齊:DOM 順序、tab 順序、使用者 mental model 的互動順序。三者不一致時、優先重排 DOM 而非用 tabindex — tabindex > 0 是反模式([#52])。 2026-04-26
高 ROI 無外部觸發的工作會被結構性跳過
工作有兩個獨立維度:ROI 高低 + 是否有外部觸發。高 ROI + 無觸發 = ROI 的承諾、拖延的現實。靠紀律不可行 — 結構性偏差需要結構性對策(外部觸發 / CI / hook / 排程 / pair)。本卡是 #67 便利反相關、#68 checkpoint 跳過、#69 RED 跳過的共同上位原則。 2026-04-26
主策略 + 補強策略:選擇不必互斥
多策略並非「五選一」、可分層疊加:root-cause fix(解結構問題) + UX 補強(解使用者感知)通常雙打比單選更穩。判準三條:解不同層 / 沒副作用衝突 / 增量成本可接受。把「策略選擇」預設成單選、會放掉互補可能、產生「結構修了但使用者體驗仍差」或「UX 蓋過去但結構還壞」。 2026-04-26
分批 ship:低風險可見價值先行、結構性下輪
「一次 ship 全部」的衝動 vs 「分批 ship」的設計:判準三軸(使用者可見性 / 風險暴露面 / 驗證需求)。低風險 + 高可見 = 立刻 ship;高風險 + 需驗證 = 下輪。對抗「完整才完整」的全做衝動、避免一次塞太多 review surface 拖延上線。 2026-04-26
決策對話的五個維度:保持完整選擇空間
對話中的「決策」不是單一動作、是多維度選擇空間:呈現格式 / 策略疊加 / 批次邊界 / 時間軸 / 選項類型。預設多半 collapse 到最窄格(開放問 + 單策略 + 一次完成 + 立刻決 + 單選)、塞使用者進最少自由度的盒子。本卡是 #74-#78 的上層串連 — 五張卡各對應一個維度的鬆綁。 2026-04-26
卡片系統的迭代浮現:原子卡 → meta-卡 → reference 三層展開
知識卡片系統不是一次寫成、是 dialogue → 原子卡 → meta-卡 → reference 的迭代浮現。每一輪迭代解決上一輪的 over-fit / under-fit、串連分散的卡片、抽出 meta-原則、最後沉澱成可直接套用的 reference 文件。本卡是 cards-skills 系統設計的 process-level 元原則。 2026-04-26
字面攔截 vs 行為精煉:驗證手段跟錯誤層次的對齊
驗證手段必須跟錯誤層次對齊:字面錯誤(typo / syntax / 缺欄位)用 hook / lint / CI 攔截;行為錯誤(思考偏差 / 判斷錯位 / collapse 反模式)用 multi-pass spiral 收斂。強行用 hook 蓋行為錯誤 = 給出 false confidence、反而比沒保護危險。本卡是 #72 結構性對策在「驗證粒度」維度的 ceiling — 不是所有錯誤都該被攔截。 2026-04-26
Methodology 的 multi-pass 該升級為 pillar 層:核心結構才會被執行
任何「教做事方法」的 methodology / SKILL / playbook、應該把 multi-pass refinement 放在 pillar / 核心原則層、不是放在末尾「附帶提醒」段。Pillar 層 = 結構性必跑、appendix 層 = 看心情選擇 = 永遠不跑。本卡是 #82 行為驗證 + #72 結構性對策在「方法論設計本身」這一層的展現。 2026-04-26
Capability gap 的對策三層階梯:expectation → augment → rebuild
系統有 capability gap(功能不滿足使用者預期)時、對策有三層階梯:L1 expectation alignment(UX hint、訊息精準)、L2 augmenting computation(補一層計算 close gap)、L3 structural rebuild(換 index / engine / 演算法)。三層成本、覆蓋率、脆弱度遞增、不必每次跳到 L3。本卡是 #75 主+補強策略的「不疊加、選層級」變種、跟 #59 五策略矩陣可疊加使用。 2026-04-26
Build-time 預處理 vs Runtime 計算的光譜:何時把成本前置
計算可放 build-time(預處理一次、runtime 0)或 runtime(per query 算)— 兩極之間有 hybrid 段(hot path 預算、cold path runtime)。判準四軸:query 頻率 / dataset 大小 / freshness 需求 / build pipeline 複雜度。Build-time 不是「永遠較好」、freshness / 多樣性高時 runtime 反而對。本卡把 #59 五策略中「query-side pushdown vs client-side fallback」的取捨抽象化、跨領域適用。 2026-04-28
視覺手段對齊錯誤層次:CSS / emoji 修不到語意 / 邏輯問題
修視覺問題的工具(CSS、emoji、顏色、排版)只能擋視覺層、不能修語意 / 邏輯層。把語意 / 邏輯問題當成視覺問題修 = 蓋住症狀根因不動 + false confidence、跟 #82 用 hook 蓋行為錯誤同骨。三層優先序:邏輯 → 語意 → 視覺、修法從深層往淺層走、不從症狀往回推。本卡是 #82 在「呈現層」的具體實例、是 #83 multi-pass review 缺的 vertical 軸。 2026-05-18
Collapse 是隱形預設:多維空間被壓成單格的三類典型
決策對話、決策呈現、批量輸出三個 surface 都有同一個 pattern — 高維選擇空間預設被 collapse 到 1-2 個窄格、且這個 collapse 因為「便利 / 合規 / 簡潔」被當成中性預設、不被覺察;#80 是 decision surface 上的極致 collapse、#79 是 dialogue 五維 collapse、#123 是 output framing 在 constraint 下 collapse;三者共骨:*某個高自由度空間被便利驅動 reduce 到最少格子*;對策不是去除 collapse、是讓 collapse 變顯性、由設計者決定要 collapse 哪一維、不是預設全 collapse 2026-05-18
寫作 review 是多軸完整性、不是單軸深度
寫作 review 的完整性不是單一軸越做越深、是多軸交集都對齊;#83 frame 軸 + #121 instance 軸 + #97 surface 軸 + #95 scope 軸 + #122 cadence 軸 + #124 timing 軸 + #114 granularity 軸、七軸正交、缺任一軸都會 systematic miss;review 設計時要 enumerate 七軸覆蓋狀況、不是只跑一兩個維度做深;是 #79 五維決策對話在 review 工具設計的姊妹卡 2026-05-19
Process content 結構由最大差異維度決定、不是 universal phased
跨 X process content(migration / upgrade / rollout / playbook)的結構由 source / target 之間 *差異維度組合* 決定、不存在 universal phased 模板;6 種 migration / process type 實證(schema 差 / drop-in / operational / multi-tool / paradigm / topology re-layout)跑出 6 種不同結構;寫作前必須做 *6 維 diff dimension audit* 才能決定結構、跳過會套錯模板 2026-05-19
Data topology 是 process content 的第 6 audit 維度
Process content 的 diff dimension audit 原本 5 維(schema / operational / paradigm / components / application change)漏了 *data topology* — 資料在 cluster / partition / region 之間的分佈拓樸;topology 不在既有 5 維任一個、但決定 re-sharding / partition redesign / multi-region rollout 的結構;本卡擴 audit 到 6 維、新增 Type F「Topology re-layout」結構 Tarragon (CC BY 4.0) | 使用 hugo 製作