論述基礎與限制

本卡抽自 infra 教學模組的知識卡建卡過程。最初建了 14 張卡（IaC、VPC、subnet 等雲端 infra 概念），後續補了 7 張（route-table、SCP 等進階概念），但 legacy 環境的工具（phpMyAdmin、FileZilla、.htaccess、.env）一直沒建卡——作者和 reviewer 都覺得「這些是常識、不需要建卡」。使用者指出「現代工程師不一定認識這些老工具，接手的工程師不一定是寫 PHP 的」後才意識到這是建卡判準的盲點。限制：evidence 來自單一教學模組。

核心原則

知識卡的建卡判準是「目標讀者群裡最不熟悉的那個人能不能理解」，不是「作者覺得這個術語夠不夠常見」。

常識是相對於背景的：

作者的盲點是：寫某個領域的教材時，作者已經熟悉該領域的術語，把自己的熟悉度投射成「讀者也知道」。reviewer 如果跟作者背景相似（同源），會有相同的盲點。

情境

infra 接手維運模組的文章大量使用 phpMyAdmin、FileZilla、.htaccess、.env、cPanel 等術語。三輪多輪審查（compliance / cadence / steelman）都沒有指出這些術語需要知識卡——因為 reviewer 跟作者都把它們當成「寫過 PHP 就知道的東西」。

使用者指出：「接手的工程師不一定是寫 PHP 的，他只是被叫來接專案。」這句話揭露了建卡判準的錯誤假設——教材的讀者不是「寫 PHP 的人」，而是「被指派接手一個 PHP 專案的任何背景的工程師」。後者的術語熟悉度遠低於前者。

理想做法

建卡判準用「最不熟悉的目標讀者」而非「作者的熟悉度」：

1. 定義目標讀者群的背景光譜（接手維運的讀者可能是 PHP / Node / Go / Python / 前端背景）
2. 對每個術語問：「光譜裡最不熟悉的那端，看到這個詞能理解嗎？」
3. 如果答案是「部分讀者需要查」，就建卡——卡的成本很低（40-50 行），但缺卡讓讀者卡住的成本很高（關掉頁面去 Google、可能找到不準確的解釋）

建卡的邊際成本判斷：一張 40 行的卡花 5 分鐘寫，讀者搜尋到一張不存在的卡花 10 分鐘去外部找答案（可能不準確）。建卡的 CP 值幾乎總是正的——除非術語真的只在一篇文章出現一次且已有完整 inline 解釋。

沒這樣做的麻煩

• 讀者流失：非 PHP 背景的工程師讀到第三個不認識的術語（phpMyAdmin → .htaccess → opcache）後放棄，因為教材假設了他沒有的背景知識
• 外部搜尋的風險：讀者離開教材去 Google「什麼是 .htaccess」，找到的解釋可能跟教材的上下文不一致（例如 Google 結果講的是 Apache 2.2 的語法，教材用的是 2.4+）
• review 結構性漏抓：同源 reviewer 跟作者有相同的「常識」盲點，加再多輪也抓不到——這是 outside-in 的 reader-persona frame 才能 catch 的問題

判讀徵兆

寫教材時如果某個術語「不需要解釋」的直覺反應來得太快，問自己：「一個完全不同背景的專業人士看到這個詞，能理解嗎？」如果要想超過三秒才能回答，建卡。

另一個徵兆：如果教材的目標讀者群跨越多個技術背景（如「任何被指派接手 legacy 專案的工程師」），幾乎所有領域特定的術語都需要建卡——因為沒有任何一個術語對所有背景都是常識。

跟其他抽象層原則的關係

• → 讀者是缺經驗的專業人士、不是外行人：讀者有系統思考能力、缺的是特定領域的術語和經驗。知識卡補的正是這個缺口——給他一個 40 行的快速入口，讓他回到教材繼續讀
• → 多輪審查缺 outside-in 讀者 frame：「作者覺得是常識」是 inside-out 盲點的又一個實例——inside-out 從內容看品質（術語用得對不對），outside-in 從讀者看缺口（讀者認不認識這個術語）
• → 原子筆記要有向上的議題入口：知識卡從情境進入（「你在接手 legacy 專案時會遇到這個工具」），不是字典定義