概念位置

HITL 三種觸發時機：

跟其他相關概念對照：

設計責任

讀 AI 應用設計或 agent paper 看到「HITL」「human-in-the-loop」「approval flow」「appeal」就是這個機制。實作判讀：

1. 位置由 risk 跟 validator 能力決定：risk 高 + validator 弱、HITL 頻率高；risk 低 + validator 強、HITL 頻率低。
2. 三時機可組合：pre-act 擋高代價、mid-stream 處理 agent 不確定性、post-hoc 收回饋。三者各擋不同 risk class、不互斥。
3. 避免橡皮圖章化的四條件：分級不同 risk 走不同 gate、approval UI 強制 show diff、reject 有明確 fallback、approval 訊號回饋進系統。任一不滿足、HITL 退化成形式。
4. 跟 jagged frontier 的關係：frontier 外的任務該強制 HITL、不交給 user 自由心證。
5. 跟 fuzzy engineering 典範的關係：HITL 是 fuzzy 行為的 deterministic guardrail 一種、不是預設要有、看 risk 跟自動 validator 能力決定。

完整 HITL 拓樸設計見 4.5 人機協作拓樸。

本章寫人機協作的拓樸設計：兩種工作模式（centaur / cyborg）、能力邊界的不規則性（jagged frontier）、三種 HITL 觸發時機、跟 4.4 agent 自主度分層 的對應。這層問題是跨產品 / 跨領域通用、跟具體 framework 無關。

本章目標

讀完本章後你能：

1. 區分 centaur 跟 cyborg 兩種工作模式、判斷哪種適合哪種任務。
2. 描述 jagged frontier、解釋為什麼「全自動」是錯題。
3. 在 pre-act / mid-stream / post-hoc 三個時機點選對 HITL 設計。
4. 設計確認流程、避免人類變橡皮圖章。
5. 把這層設計對應回 4.4 agent 架構 的自主度分層。

兩種工作模式：Centaur 跟 Cyborg

Centaur 跟 cyborg 是兩種人類跟 LLM 共事的姿態。概念起源於 Kasparov 2010 提的 advanced chess（人類 + AI 配合下棋）、HBS / UPenn / Wharton 對 BCG 顧問使用 AI 的研究把這對 framing 套到 knowledge work、觀察到兩種使用模式都存在且各有適用。

Centaur 模式

人類把整段任務委派給 LLM、等結果回來再審。

• 比喻：人馬獸——上半身人、下半身馬、清楚的職責分工。
• 典型場景：「寫一份這個主題的 PPT 大綱、含三個案例、按以下風格、做完給我」、LLM 跑幾分鐘、人類審結果。
• 適合：任務邊界清楚、人類能事先描述完整需求、結果可離線審。
• 失敗模式：任務描述漏細節、LLM 跑偏到沒注意、結果不能用。緩解：先給小範圍試跑、確認方向再放手。

Cyborg 模式

人類跟 LLM 緊密協作、快速來回、人類隨時調整方向。

• 比喻：半機械人——人類跟 LLM 融合、邊做邊改。
• 典型場景：寫 code 時 IDE 內 inline completion、寫文章時邊輸入邊看 LLM 建議、debug 時來回問。
• 適合：任務探索性、需求邊做邊浮現、無法事先完整描述。
• 失敗模式：頻繁打斷思路、context switch 成本高、最後產出反而比 centaur 慢。緩解：對熟悉的任務 cyborg、不熟的任務 centaur。

該用哪種

學生 / 個人開發更常 cyborg 工作、企業自動化更常 centaur 工作。看到一個產品設計時、問「它鼓勵 user 走 centaur 還是 cyborg」、就能判讀它的設計取向。

Jagged Frontier：AI 能力的不規則邊界

Jagged frontier 是觀察 AI 能力分佈的 framing。直覺上「AI 能做的任務」應該是一個 smooth 的連續區、簡單的能做、難的不能。實際上不是——AI 能做的任務分佈是鋸齒狀（jagged）：某些看起來難的任務 AI 做得很好、某些看起來簡單的任務 AI 反而做不好。

這張表是 2024-2025 的觀察、frontier 會隨模型升級漂移——reasoning model + tool use 普及後、算術跟計數已經部分往「能做」那邊移、URL 也可以靠 web search tool 補救。表的價值在於 framing「能力分佈不規則」、不是把具體 4 個 case 當定論。

每個例子背後的失敗機制各不相同：

• 精確算術：靠符號操作、訓練資料中算術佔比小、tokenizer 把數字切成多 token 也加難度。Tool use（呼叫 calculator）能補救。
• 計數：要對 input 做精確 traversal、跟 LLM 的並行 attention 機制不對盤、容易少算多算。對 needle in long context 的失敗模式類比見 needle in haystack 卡。
• 嚴格遵守冷僻格式：format 沒在訓練分佈中見過、模型回退到「我熟悉的格式」。Constrained decoding（見 3.10）能補救。
• 引用真實 URL：模型沒辦法區分「真實存在」跟「看起來合理」、hallucinate 出格式對但內容假的 URL。靠 tool（web search、URL validator）才能驗證。

整體看：能力分佈跟訓練資料分佈、tokenizer 行為、推論機制相關、跟人類直覺的「難易」沒對齊。這給三個實務啟示：

• 不要用「人類直覺難易」推測 AI 能力。試跑、看結果、不要預判。
• 「全自動」是 over-trust 假設：frontier 鋸齒、總有些子任務落在 frontier 外、需要人介入或 tool 補。設計時要假設「有部分子任務 AI 會失敗」、而不是「都會成功」。
• 失敗在 frontier 外的任務、再加 prompt iteration 通常無效：那是模型能力邊界問題、不是 prompt 問題。對應 4.0 prompt 技術光譜 的 systematic vs random error 診斷。

Falling asleep at the wheel：frontier 外的隱性風險

研究發現一個跟 jagged frontier 互動的人類行為模式：人類傾向不分辨任務是否在 frontier 內、對 AI 結果一律低度審查。結果 frontier 內的任務 AI 做得好、人類審不審差別不大；frontier 外的任務 AI 做得差、但人類也沒審出來、產出帶錯送出。

緩解：

• 明確標 frontier：對團隊 / 產品 user 標出「AI 在這類任務可靠 / 不可靠」、不要假設 user 會自己分辨。
• frontier 外的任務強制人類審查：把「該審 vs 不該審」做成 deterministic 規則、不交給 user 自由心證。
• 抽樣審查：即使 frontier 內任務、隨機抽樣審查、偵測 frontier 漂移（模型升級或 prompt 變動後 frontier 可能移動）。

HITL 三種觸發時機

人類介入的時機決定 HITL 的型態。三個時機點各有適用場景：

Pre-act：動作執行前確認

LLM 決定要做某個 action、但 action 真的執行前停下來、給人類審 + approve。

1LLM decides: 「我要刪除 user_id=123 的 record」
2   ↓
3[HUMAN APPROVE?]
4   ↓ (approved)
5Execute deletion

• 適用：不可逆 / 高代價的 action。對應 4.4 agent 的「step-by-step approval」協作模型。
• 失敗模式：approval 流程太頻繁、人類疲勞、最後變橡皮圖章。緩解見後面「避免橡皮圖章化」段。

Mid-stream：執行過程中介入

Agent loop 跑到一半、發現自己不確定、主動停下來問人類。

1Agent: 「我有兩個方案、不確定哪個、請選 A 還是 B？」
2   ↓
3[HUMAN PICKS]
4   ↓
5Agent continues with chosen path

• 適用：任務有多個合理路徑、選擇影響後續策略、不該由 agent 自決。
• 跟 pre-act 的差異：pre-act 是「我準備做 X、你 approve 嗎」（agent 已決定方向）、mid-stream 是「我不確定該做什麼、你決定」（決策權交給人類）。
• 失敗模式：agent 不知道自己該不知道（unknown unknowns）、該問沒問、自己亂走。緩解：在 prompt 內 enumerate 常見的「該問人類」情境、降低 agent 自決的範圍。

Post-hoc：事後申訴 / 校正

Agent 已執行、結果交付、user 看完後可以申訴 / 校正。

1Agent produces result → User sees result
2                              ↓
3                       [USER APPEALS?]
4                              ↓ (yes)
5                       Human reviews + adjusts
6                              ↓
7                       Feedback loop → 改 prompt / fine-tune

• 適用：行為層次的細節調整、評分類任務（如自動打分後 user 申訴）、預先審不可行的場景。
• 跟 pre/mid 的差異：post-hoc 不擋執行流、執行完才介入；前兩者擋在執行前 / 執行中。
• 典型例子：自動評分系統的 appeal 流程——LLM 打分完、user 對分數有異議時、走人類審查、結果不只改這次分數、還回饋進系統改善後續評分。
• 失敗模式：appeal rate 過高（系統信任度差）、或 appeal rate 過低（user 不知道可以申訴 / 申訴成本高）、回饋訊號失真。

三個時機的選擇

實務多重組合：pre-act 擋高代價、mid-stream 處理 agent 的不確定性、post-hoc 收 user 回饋改善系統。三者各自處理不同 risk class、不互斥。

有效 HITL 的四個設計條件

HITL 要真的擋住失敗、不退化成 rubber-stamp approval、設計上要滿足四個條件。每個條件對應一個常見退化模式、可以同時當 checklist 用。

條件一：分級、不同 risk 走不同 gate

高 risk 動作（push、deploy、production change）強制 step-by-step approval；中等 risk（檔案寫入、本機 commit）每 N 步 checkpoint；低 risk（read-only、本機 sandbox）full auto。對應 4.3 tool use 副作用範圍 的等級分類。

對應反例：每個 tool call 都要 approve、不分高低代價、user 每天按 100 次 approve、按到下意識、根本沒看內容。

條件二：approval UI 強制 show diff

審查的具體內容（準備寫的檔案內容、準備執行的 SQL、準備發的 email 草稿）必須在 approval UI 上呈現、user 看得到才能做出有意義的判斷。

對應反例：「approve this action?」按鈕、但 user 看不到 action 的具體內容、只能盲簽。沒有 diff 就沒有審查、不要假裝有審查。

條件三：reject 有明確 fallback 路徑

User reject 後 agent 該怎麼處理（換方案、停下來、escalate）要在設計時確定、不能讓「reject 等同流程斷」。

對應反例：只能 approve、reject 的話 agent 不知道怎麼辦、user 怕 reject 後續流程斷、就一律按 approve、HITL 失去意義。

條件四：approval 訊號要回饋進系統

User 的 approve / reject pattern 進 trace、定期 analyze、把「總是 approve 的動作」自動降級、「總是 reject 的動作」進 prompt 改變 agent 預設行為。

對應反例：User 一直 approve / reject、但訊號沒回饋、agent 下次還是問一樣的問題、user 疲勞累積。

跟 Agent 自主度分層的對應

4.4 agent 架構 列了五種人類審查協作模型：full auto、checkpoint、step-by-step approval、plan first then auto、human-in-the-loop。本章三種 HITL 時機跟這五種協作模型的對應：

選哪一層、看 4.3 工具副作用範圍 等級：等級 1-2 用 full auto + post-hoc、等級 3 用 checkpoint、等級 4-5 強制 step-by-step。

跟 Fuzzy Engineering 典範的關係

0.8 Deterministic vs Fuzzy Engineering 講 fuzzy 邊界要包 deterministic guardrail。HITL 是 guardrail 的一個 case——把人類判斷當成 deterministic check 來包 fuzzy LLM 行為。

判讀 HITL 該存在的訊號：

• 任務的 fuzzy 行為輸出進入不可逆 deterministic 系統（DB write、API call、實體 action）。
• LLM 在這類 boundary 上的失敗代價遠高於 HITL 的人類 cost。
• 沒有可靠的自動 validator（用 LLM judge 風險也太高）。

三者俱備時、HITL 是必要的 guardrail。任一不滿足、可能用 schema validation / output validator / distribution monitoring 替代、不需要人類在 loop 內。

何時過時 / 何時不過時

不會過時的部分：

• Centaur vs cyborg 兩種工作模式的分類。
• Jagged frontier 概念、「全自動」是錯題的論證。
• 三種 HITL 觸發時機（pre-act / mid-stream / post-hoc）的分類。
• 橡皮圖章化的四個反模式跟緩解。
• 跟 agent 自主度分層、fuzzy engineering 典範的對應結構。

會變的部分：

• Jagged frontier 的具體位置（哪些任務在 frontier 內、隨模型能力進步會移動）。
• HITL 的 UI / UX 工具（隨產品 framework 演化）。
• Approval 自動化的程度（更強的 distribution monitoring 可能讓部分 HITL 變得不必要）。

下一章

下一章：4.6 應用層協議、把 function calling / structured output / MCP 三個概念放回正確層級、銜接 agent 跟外部系統的協議設計。Agent 自主度分層完整討論見 4.4、工具副作用範圍見 4.3、HITL 在 fuzzy engineering 中的定位見 0.8。

選項清單按使用者掃描順序排序、不按資料來源預設。 短清單先看完、長清單花更多時間 — 把短清單放前面讓使用者先排除一個維度、再面對長清單。字母排序對「找已知名稱」有效；多選 facet 場景下使用者通常不知道確切選項名、需要 scan，這時候掃描成本主導。

為什麼掃描成本優先於字母排序

商業邏輯

當清單有多個選項供使用者挑選，選項數量影響掃描時間。使用者在 facet UI 的行為不是「找已知 tag」、是「看到有什麼可選、選有興趣的」 — 這是探索式行為、不是查找式行為。

字母排序是資料庫思維（穩定、可預測），掃描成本排序是 UX 思維（縮短決策時間）。Facet 場景幾乎都是後者。

兩條維度收斂的順序

當有多個 facet 維度可選、使用者通常逐維度收斂：先用一個維度砍掉一半結果、再用第二個維度精選。短清單放前面讓「第一刀」決策快速。

這次任務的應用

觀察

Pagefind filter 預設按 filter key 字母排序：tag < type，所以 Tag 先顯示。

實際內容：

判讀

Type 短、Tag 長 — 預期使用者行為是「先按 type 收斂（這是 post 還是 glossary？）、再進 tag 找主題」。Tag 在前等於要使用者先面對 80 個選項，認知成本高。

把順序倒過來：Type 先顯示讓使用者先用 section 收斂、再進 Tag 找。

執行

 1function reorderFilters() {
 2  var blocks = filter.querySelectorAll('.pagefind-ui__filter-block');
 3  var desiredOrder = ['type', 'tag'];
 4  var byKey = {};
 5  blocks.forEach(b => {
 6    var key = b.querySelector('.pagefind-ui__filter-name').textContent.trim().toLowerCase();
 7    byKey[key] = b;
 8  });
 9  desiredOrder.forEach(k => byKey[k] && filter.appendChild(byKey[k]));
10}

內在屬性比較：四種排序策略

選擇順序：有 analytics → 頻率排序；沒有 → 掃描成本排序；都不適用 → 字母排序。

排序原則的延伸應用

同類 facet 內的選項排序

Tag 內部的 80 個 tag 怎麼排？

當前接受 pagefind 的字母排序（成本最低、且 80 個 tag 做計數排序需要額外索引處理）。

選項數量門檻

短清單跟長清單的邊界沒有絕對值，常用啟發：

• ≤ 7 個選項：可一眼掃完、放前面
• 8-20 個：中等、需要結構（縮排、分組）
• 20+ 個：長清單、放後面或加搜尋框

Type 5 個落在「短」、Tag 80 個落在「長」 — 順序明顯。

設計取捨：選項清單的排序策略

四種做法、各自機會成本不同。預設依使用者行為性質選 — 探索式 → A、查找式 → B、有 analytics → C、有子類別 → D。

A：掃描成本排序（短先長後）（探索式 facet 的預設）

• 機制：選項數量少的維度放前面（type 5 個 → 先；tag 80 個 → 後）
• 選 A 的理由：使用者先用短清單收斂一刀、再面對長清單；認知成本低
• 適合：探索式 facet（使用者不知道確切選項名）
• 代價：需要主動覆寫資料來源預設（不能直接用 DB 順序）

B：字母排序

• 機制：按 alphabetical 排
• 跟 A 的取捨：B 對「找已知名稱」高效（二分查找）、A 對「探索式選擇」高效；但 facet 場景幾乎都是探索式
• B 比 A 好的情境：使用者通常知道確切選項名（國家清單、語言清單）

C：使用頻率排序（最常用在前）

• 機制：按 analytics 統計、最高頻選項在前
• 跟 A/B 的取捨：C 比 A 更精準（用真實資料）、但需要 analytics + 冷啟動時無資料
• C 比 A 好的情境：有足夠 analytics、且使用者偏好集中（80/20 分布明顯）

D：語意分組排序

• 機制：把選項分子類別、組內再排
• 跟 A 的取捨：D 對「選項有明顯子類別」更直觀（產品類別 / 功能類別）、A 對純扁平清單夠用
• D 比 A 好的情境：選項有清楚的層級結構（電商 facet：類別 > 子類別 > 選項）

判讀徵兆

核心原則：UI 排序是設計決策、不是技術選擇。預設順序通常反映資料來源結構、不反映使用者行為 — 主動覆寫是常態、不是例外。

跟 #55-#66 Filter × Source 系列 的關係：本卡是「filter UI 的排序」、Filter × Source 系列是「filter 行為的層級」 — 兩個維度互補。設計 filter UI 時兩者都要顧：本卡決定「哪個選項放前面」、#58 決定「篩選的定義域是哪一層」、#59 決定「filter 跟 source 怎麼合成」。

Mode（模式）跟 Facet（多面向篩選）是兩個語意層級、UI 區域必須分開。 Mode 決定「如何搜」、Facet 決定「篩選什麼結果」 — 兩者作用點不同、混在同一 UI 區會讓使用者誤以為是同層的選項、產生「為什麼勾這個結果這麼少」的困惑。

為什麼語意層級要對應視覺分區

商業邏輯

搜尋 UI 包含的控制看起來都是「縮小結果」、語意層級實際不同：

Mode 在「搜尋」之前生效、Facet 在「搜尋」之後生效 — 兩者在 query pipeline 的位置不同。

混在一起的失敗模式

把 mode 跟 facet 放在同一 UI 區域、使用者預設兩者作用相同：

使用者看不出「為什麼結果差異這麼大」 — 因為以為換了一個 facet、實際換了搜尋演算法。

UI 慣例位置

慣例位置反映語意層級 — mode 屬於「query 構造」、facet 屬於「結果處理」。

這次任務的應用

觀察

搜尋頁有兩類控制：

判讀

把 scope 放進 filter 區會讓使用者把它當第三種 facet — 但「全部 / 標題 / 內文」不是篩選現有結果、是換搜尋範圍：

• 勾「標題」：搜尋只跑標題欄位、內文有的字直接 0 結果
• 取消「標題」（切回「全部」）：搜尋範圍擴大、結果集完全不同

如果使用者以為這是 facet、預期「取消會稍微多幾個結果」 — 實際結果集大幅變動會困惑。

執行：分區擺放

兩者視覺上明顯分開、使用者可區分「這是改搜尋方式」vs「這是篩結果」。

內在屬性比較：三種 mode/facet 擺放

優先選「分區 + 視覺暗示」 — 不需要文字說明、靠位置即可辨識。

進階：多個 mode 並存的處理

當有多個 mode（搜尋範圍 + 排序方式 + 語言）：

每個 mode 跟它影響的範圍視覺鄰近 — 影響搜尋範圍的靠 input、影響結果排序的靠結果。

Facet 也可以分多區（type/tag 在 sidebar、價格區間在結果上方）— 但 mode 與 facet 之間永遠保持區域分離。

設計取捨：搜尋控制的擺放策略

四種做法、各自機會成本不同。這個專案選 A（Mode 靠 input + Facet 靠結果）當預設、其他做法在特定情境合理。

A：Mode 緊貼 input + Facet 靠近結果（這個專案的預設）

• 機制：mode 控制（搜尋範圍 / 排序）放 input 旁；facet 控制（type / tag）放結果區或 sidebar
• 選 A 的理由：位置就是契約 — 靠 input 的影響搜尋本身、靠結果的篩選結果；使用者靠位置辨識語意層級、不需文字說明
• 適合：搜尋 UI、有 mode + facet 兩種控制
• 代價：UI 拆兩個區、空間使用多一些

B：所有控制集中 sidebar

• 機制：mode + facet 都放 sidebar 一起
• 跟 A 的取捨：B 集中管理視覺乾淨、A 分區語意清晰；但 B 使用者區分不了哪個影響 query、哪個影響結果
• B 是反模式：mode/facet 混淆是 UX 痛點 — 使用者區分不了哪個影響 query、哪個影響結果

C：所有控制集中 input 旁

• 機制：mode + facet 都靠 input、結果區無控制
• 跟 A 的取捨：C 操作集中、A 按語意分；但 C facet 跟結果脫鉤、視覺暗示錯
• C 比 A 好的情境：facet 數量極少（< 3 個）、放 input 旁不擁擠

D：加文字說明取代位置暗示

• 機制：UI 加「此項目影響搜尋演算法」「此項目篩選結果」說明
• 跟 A 的取捨：D 文字精確、A 靠位置直覺；但 D 增加閱讀負擔、使用者通常跳過說明
• D 比 A 好的情境：複雜搜尋介面（多種 mode、多層 facet）— 純位置暗示不夠

判讀徵兆

核心原則：搜尋 UI 的控制不是同層的「篩選器」 — 語意層級不同、視覺分區也應不同。位置就是契約：靠 input 的影響搜尋本身、靠結果的篩選結果。

跟 #58 篩選類指令的澄清時機 的關係：mode 跟 facet 是兩種不同的「篩選類指令」。Mode（如「title-only / content / both」）通常重塑 query → 對應 #58 三問的「定義域 (c) 重新搜尋」；Facet（如「type=post tag=js」）通常加 filter 條件 → 對應「定義域 (b) 在所有結果裡找」。語意分區是視覺面、定義域選擇是行為面 — 兩者一起設計才完整。

「Loading」「Empty」「End」是三個語意不同的狀態、UX 必須區分。 三者在資料層代表完全不同的事實、使用者根據哪一個決定下一步動作；共用畫面 = 使用者沒辦法決定。

混為一談 = 使用者該等的時候改 query、該改 query 的時候等、該停的時候繼續點 load more。

為什麼三狀態容易被混為一談

視覺上類似

Loading 跟 Empty 都是「空白為底」、容易共用畫面。實作時如果只寫 {{ if results }}...{{ else }}<empty />{{ end }}、Loading 跟 Empty 會被當成同一件事。

資料層常常沒提供區分訊號

1const r = await fetch();
2if (r.length === 0) showEmpty();

r.length === 0 只區分有 / 無、不區分「為什麼無」。要區分「還沒抓」vs「抓完無命中」、需要顯式追蹤 fetch 的狀態（pending / done / error），不是看 result。

End 狀態類似：results.length > 0 && !hasMore 才是 End、跟「還可以 load more 的當前結果」不同。

三狀態的可區分訊號

實作上至少需要：

• 一個 fetch state machine（不能只看 results）
• 一個「還有沒有下一批」的訊號（hasMore / cursor / total count）
• UI 對三種組合各畫一個樣子

多面向：三狀態的延伸

面向 1：Filter 加進來、狀態空間擴張

當 view 層有 filter、三狀態擴張為五狀態（Loading / Empty-raw / Empty-filter / Partial / End）。「Empty-filter」跟「Partial」是 #55 層錯位 的 UX 表現 — 共用同個 empty 畫面 = 使用者無法判斷「再 load more 會不會有」。

具體 UX 模板（三數字、五狀態各別 UI）見 #62 Pattern：誠實進度 UX。

面向 2：Streaming / SSE 的「無更多」很難判斷

1for await (const item of eventSource) { ... }
2// 跑完了還是斷線了？

Streaming 通常沒明確的 End 訊號 — 需要 server 主動送一個 event: end、或 client 用 timeout / heartbeat 判斷。否則使用者看到一段時間沒新資料、不知道是「沒了」還是「還在等」。

面向 3：錯誤狀態應該獨立、不混進三狀態

把 Error 顯示成 Empty = 使用者誤以為「沒結果」、不會 retry。

設計取捨：UX 該怎麼呈現三狀態

A：每個狀態獨立的 UI 元件

• 機制：Loading 顯示 spinner、Empty 顯示 illustration + 「改 query」CTA、End 顯示「all results loaded」、Error 顯示 retry button
• 選 A 的理由：四個狀態語意完全清楚、使用者下一步明確
• 代價：UI 元件多、設計成本高

B：用文字 + 細節區分、共用 layout

• 機制：同一個 container、不同狀態填不同文字（“Loading…” / “No results for X” / “Showing all 23 results”）
• 跟 A 的取捨：B 設計簡單、但區分性弱（使用者要讀文字才知道狀態）
• B 才合理的情境：簡單 UI、使用者願意讀文字

C：只用視覺 cue（spinner / 空白）

• 機制：spinner = loading、空白 = 沒結果、結果列表 = 有
• 跟 A 的取捨：C 沒區分 Empty vs End vs Partial
• C 才合理的情境：source 沒分批、結果一次給完

D：完全不區分三狀態（反模式）

• 為什麼是反模式：把「使用者下一步該做什麼」這個決策丟給使用者自己猜、違反「UI 必須回答下一步問題」原則
• 看起來吸引人的原因：UI 寫起來最簡單、不用畫 Loading / Empty / End 三版、{{ if results }}...{{ else }}empty{{ end }} 一行解決
• 實際發生的代價：使用者操作不知所措、support tickets 增加、使用者信任損失（「這網站到底有沒有在 load」）

判讀徵兆

核心原則：三狀態（Loading / Empty / End）是不同事實、不同 UX。共用畫面 = 把「使用者該做什麼」這個決策丟給使用者自己猜。實作要從資料層追蹤 state、不能只看 results。

跟 #38 動態內容變動的 aria-live region 設計 同源：兩者都是「狀態變動需要告知使用者」、本卡告訴的是 sighted 使用者（視覺區分）、#38 告訴 screen reader（aria-live 廣播）。

當 filter 必然有層錯位、用「已掃 N / 命中 K / 共 M」三數字 + 「再掃一批」按鈕讓使用者看見掃描範圍、自己決定要不要續抓。

對應 #59 Filter × Source 合成策略 的策略 D。

何時用、何時不用

用

• Source 不支援 server-side filter（A 不可行）
• 不能或不值得重 index（C 不可行）
• Match 稀疏或不可預期、自動續抓（B）會拉爆
• 工程量限制、原型期 / MVP

不用

• Filter 是主要互動模式（使用者預期「自動全找完」）
• 三數字會讓 UI 太複雜
• 使用者完全不在意「掃描範圍」

三數字的語意

最少要顯示「已掃 N / 命中 K」 — 沒有 N 使用者不知道掃描範圍、沒有 K 使用者不知道有沒有命中。

「共 M」可選 — 有的 source（pagefind）會給 total count、有的（streaming）不會。

UI 模板

基本版

1<div class="filter-status">
2  已掃 <strong>24</strong> 筆 / 命中 <strong>3</strong> 筆
3  <button>再掃一批</button>
4</div>

含總數

1<div class="filter-status">
2  已掃 <strong>24</strong> / <strong>~150</strong> 筆 — 命中 <strong>3</strong>
3  <button>再掃一批</button>
4</div>

含結束狀態（呼應 #57 三狀態）

 1<!-- Loading -->
 2<div class="filter-status">掃描中... 已掃 <strong>24</strong> / 命中 <strong>3</strong></div>
 3
 4<!-- Partial（還可續） -->
 5<div class="filter-status">已掃 <strong>24</strong> / 命中 <strong>3</strong>
 6  <button>再掃一批</button>
 7</div>
 8
 9<!-- End（掃完） -->
10<div class="filter-status">已全部掃完、共命中 <strong>12</strong> 筆</div>
11
12<!-- Empty (filter) -->
13<div class="filter-status">已掃 <strong>24</strong>、沒有命中
14  <button>再掃一批</button> 或 <a>清除 filter</a>
15</div>

進度更新時機

即時更新（每筆）

1for (const item of stream) {
2  scanned++;
3  if (matches(item)) {
4    matched++;
5    appendResult(item);
6  }
7  updateUI(scanned, matched);  // 每筆更新
8}

UX 順、但 DOM 操作頻繁、可能 jank。

批次更新（每批）

1const batch = await fetchNext();
2scanned += batch.length;
3const m = batch.filter(matches);
4matched += m.length;
5appendResults(m);
6updateUI(scanned, matched);  // 每批一次

DOM 操作少、但 UX 不夠順（一段時間沒動）。

推薦：每批 + 載入中 spinner

批次後更新數字、批次間顯示 spinner。最平衡。

跟自動續抓（B）的混合

可以做成「初始自動續抓 N 批、之後切誠實 UX」：

1async function searchWithFilter(query) {
2  // 初始自動續抓 3 批（湊一些結果）
3  await fetchUntilQuota(3, autoBatches: 3);
4
5  // 之後使用者手動點「再掃一批」
6  showHonestProgressUI();
7}

混合的好處：使用者一進來就有結果（不是空畫面）、之後續抓由使用者決定。

反例

反例 1：只顯示「命中 K」、不顯示「已掃 N」

1<div>找到 3 筆結果</div>

使用者不知道是從多少筆裡找的、不知道「再掃會不會有」。

反例 2：只顯示「共 M / N」進度條、沒分「已掃」「命中」

1<progress value="24" max="150"></progress>

進度條告訴使用者「load 進度」、但「load 進度 ≠ filter 進度」。沒命中時使用者不知道為什麼進度走了 24% 但畫面沒結果。

反例 3：「再掃一批」沒做

只顯示三數字、沒提供續抓 button — 使用者看到「已掃 24 沒命中」、不知道下一步。

跟 #57 三狀態的關係

誠實進度 UX 是 #57 Loading / Empty / End 三狀態的區分 在「filter + 分批」情境下的具體實作。三數字提供區分三狀態的訊號：

判讀徵兆

核心原則：誠實 UX 不是「lazy 解法」、是「sourcing 限制下的合理透明度」。給使用者三數字 + 行動選項、比假裝完美但 silent 失敗好。

跟 #19 覆寫深度的成本告知 同源：兩者都是「把實作的限制 / 代價攤給使用者、讓使用者參與決策」。差別在 #19 是「實作前告知工程成本」、本卡是「runtime 持續顯示掃描成本」 — 攤出來的位置不同、原則一致：silent 累積負擔是反模式。

當 filter 必然只在已載入子集上運作、用 UI 文字 / API contract / docstring 明確告訴呼叫者「範圍 = 已載入、不承諾全集」 — 不假裝是全集 filter。

對應 #59 Filter × Source 合成策略 的策略 E。

何時用、何時不用

用

• Source 不支援推進 query (A 不可行)
• 不能控 build pipeline (C 不可行)
• Match 稀疏、自動續抓會拉爆 (B 不可行)
• 工程量限制、做不了 #62 誠實 UX 的三數字
• 能接受「filter 範圍 = subset」這個語意縮小、但要使用者知道

不用

• Source 一次給完整 dataset（沒有 subset、不需要縮小）
• 使用者預期 filter 是「全集」、無法接受縮小
• 應用情境影響重大決策（finance、medical 等不能接受 silent 範圍縮小）

跟策略 D（誠實 UX）的差別

D 跟 E 都是「在 subset 上 filter」、差別在「怎麼告訴使用者」：

簡言之：D 是「持續顯示掃描範圍」、E 是「告訴一次、之後不再提」。

「明示」的具體做法

UI 明示

1<input type="search" placeholder="Filter loaded results...">
2<small class="hint">只在已載入的結果裡篩選。要看更多請先載入更多。</small>

「Filter loaded results」、「已載入的結果裡」、「載入更多」 — 三個 cue 讓使用者知道範圍。

API contract 明示

1/**
2 * Filter loaded results by predicate.
3 *
4 * NOTE: Operates on currently loaded subset only.
5 * Does NOT trigger fetch of un-loaded items. To filter the full
6 * dataset, use {@link searchAll} instead.
7 */
8function filterLoaded(predicate: (item: Item) => boolean): Item[];

JSDoc / TSDoc 把語意寫進 API、IDE 提示能看到。

Docstring / README 明示

1## Filter behavior
2
3`filter()` only operates on results currently loaded in client.
4If the source uses pagination, items not yet loaded are NOT included.
5For full-dataset filtering, the source must support server-side filter.

文件級的明示、給開發者讀。

反例

反例 1：Silent 縮小（不告訴）

1<input type="search" placeholder="Filter results...">

「Filter results」沒指明「only loaded」 — 使用者預設是全集 filter、實際是 subset → 撞回 #55 層錯位 的語意縫。

反例 2：明示位置使用者看不到

1/**
2 * Filter results.
3 * Note: subset only.
4 */

使用者只看 UI、不讀 docstring — 「明示」要在使用者會看到的位置（UI hint、tooltip、行為描述）。

反例 3：明示但不清楚

1<small>限定範圍篩選</small>

「限定範圍」太抽象、沒說明是什麼範圍。要寫具體：「已載入的 N 筆內」「不包含尚未載入的」。

何時 E 升級到 D

當以下任一觸發、把 E 升級到 D（誠實 UX 三數字）：

E 是「成本低的退路」、不是長期解。當需求成熟、應該升級到 D / A / C。

跟其他 Pattern 的關係

• E 是策略順序 A → C → B → D 之外的「最後退路」
• E 跟 D 都是「在 subset 上做」、差別在告知方式
• E 跟 #55 silent 反模式的差別：E 是 explicit 縮小、silent 是 implicit 縮小

選擇順序（重申）：A 推進 → C 多 index → B 自動續抓 → D 誠實 UX → E 明示縮小 → silent（反模式）

判讀徵兆

核心原則：能接受語意縮小是可以、但必須明示。Silent 縮小（沒告知就 subset）等於 #55 層錯位、是反模式。E 的價值在「明示」這個動作、不在「subset」這個事實。

State 的儲存層決定它的特性 — 可分享 / 可恢復 / 可導航 的 state 該寫進 URL、不寫進 = silent 把這些特性犧牲掉。

寫 stateful UI 時、每個 state 的儲存位置是個設計選擇 — 不選 = 預設用 in-memory = 預設犧牲所有上面五個特性。

為什麼 URL 容易被忽略

URL 是隱形維度

In-memory state 在 React useState / Vue ref / vanilla 變數裡 — 寫起來最便利、是「預設位置」。URL state 需要 URLSearchParams + history.pushState + popstate listener、寫起來成本高。

#67 寫作便利度跟意圖對齊反相關 直接解釋為什麼：URL state 是「對齊使用者期望」的位置（使用者預期 URL 包含 state、能分享）、in-memory 是「便利位置」。預設便利、要刻意才走對齊。

沒寫 URL state 的失敗訊號是 silent

使用者打開搜尋頁、輸入「pagefind」、選擇 title-only filter、看到結果。這時：

• 複製 URL 分享給朋友 → 朋友打開看到空白搜尋框（query 不在 URL）
• 重整頁面 → 自己也看到空白搜尋框
• 點 back → browser back 跳離搜尋頁、不是回到「沒 filter 的同個搜尋」

這三個動作沒有 error、沒有崩潰、就是「state 不見了」。使用者通常以為「網站就這樣」、不會 report bug。Silent 失敗 = 維護者永遠不知道有問題。

對照 #55 Filter × Source 層錯位 — 都是 silent 失敗、都是「該存在的東西不在」。

State 該寫進 URL 的判準

三問

1. 使用者會分享這個 state 嗎？— 是 → URL（複製連結即帶 state）
2. 使用者 reload 後預期 state 還在嗎？— 是 → URL 或 sessionStorage
3. 使用者期望 browser back/forward 在 state 之間導航嗎？— 是 → URL

任一個「是」 → URL。

反向判準：什麼不該寫進 URL

多面向：常見 UI 元素的 URL state 對照

面向 1：Search filter（這次任務的 case）

1Query string、scope filter、type filter、tag filter
2→ 都該進 URL：使用者會分享「我搜什麼 + 怎麼篩」

範例 URL：/search/?q=pagefind&scope=title&type=post&tag=js

面向 2：Tab / step navigation

1Active tab、wizard step
2→ 該進 URL：分享 = 直接打開該 tab/step

範例：/settings/?tab=notifications、/checkout/?step=payment

面向 3：Sort / pagination

1排序欄位、頁碼
2→ 該進 URL：分享 = 朋友看到同樣排序的同一頁

範例：/posts/?sort=date_desc&page=3

面向 4：Modal / drawer 開合

1看情境：
2- 重要 modal（圖片預覽、編輯對話框）→ URL（可分享 / back 關閉）
3- 純 UX 提示 modal（welcome tour）→ in-memory（不該分享）

面向 5：Theme / UI preference

1Dark mode、字型大小
2→ localStorage（跨 session 但不分享、跟 device 綁）
3不進 URL（不會「分享你的 dark mode 設定」）

URL state 的實作模式

讀：載入時從 URL 同步到 component state

 1function getInitialState() {
 2  const params = new URLSearchParams(location.search);
 3  return {
 4    query: params.get('q') || '',
 5    scope: params.get('scope') || 'all',
 6    type: params.get('type') || null,
 7  };
 8}
 9
10const initialState = getInitialState();
11// component 用 initialState 初始化

寫：state 變動時同步到 URL

 1function syncUrl(state) {
 2  const params = new URLSearchParams();
 3  if (state.query) params.set('q', state.query);
 4  if (state.scope && state.scope !== 'all') params.set('scope', state.scope);
 5  if (state.type) params.set('type', state.type);
 6  const url = `${location.pathname}${params.toString() ? '?' + params.toString() : ''}`;
 7  history.replaceState(null, '', url);
 8}
 9
10// 每次 state 變動觸發
11onStateChange((newState) => syncUrl(newState));

選擇 replaceState vs pushState：

• replaceState：每次 state 變動覆蓋當前 history entry — back/forward 跳過中間狀態
• pushState：每次 state 變動加新 history entry — back 回到上一個 state

通常 search filter / sort / pagination 用 replaceState（typing 太快、不該每個字符一個 history entry）；tab / step 用 pushState（每個 step 該 back 回上一個）。

雙向：聽 popstate 處理 back/forward

1window.addEventListener('popstate', () => {
2  const state = getInitialState();
3  applyStateToUI(state);  // back/forward 後、把 state 套回 UI
4});

沒 listen popstate = back/forward 不會觸發 UI 更新、URL 跟 UI 不同步。

不該套用本原則的情境

「URL 是 state 儲存層」原則在「公開可分享的 UI」成立、但有合理例外：

跟其他抽象層原則的關係

對應的實作篇

• 搜尋頁的 scope filter URL persistence — Phase 1+2 修完後 retrospective Checkpoint 1 才發現遺漏（#68 dogfooding）
• 任何 search / list / dashboard UI — 都該檢視 URL state coverage

判讀徵兆

核心原則：URL 是 stateful UI 的隱形儲存層。沒寫 URL state = silent 犧牲分享 / 恢復 / 導航三個 UX 特性。寫之前跑三問（分享？reload？back/forward？）、任一個是 → URL。

把 L1 expectation alignment + L2 augmenting computation 疊加 時、兩個 layer 給使用者的訊號要對齊、不是 redundant 也不是 conflicting：

設計三條原則：

1. L2 自動補時、訊號要明示「這是 fallback、不是 primary path」
2. L1 hint 要承認 L2 的存在（不要假裝 L2 不存在）
3. 使用者一直能 trace「這個結果怎麼來的」

為什麼疊加會打架

L1 跟 L2 各自設計、不協調時、訊號會相互削弱：

Conflicting 例：search

User 打 “pre” → 看到 backpressure 結果 → 困惑：「不是說要打 backpre？」 → 不確定下次該怎麼搜。

Redundant 例：retry with hint

User 看到 hint → 自己 manual retry → 但 system 已經在 retry → 操作冗餘 → 不確定 retry 是 user 觸發還是 system。

Conflicting 例：editor stale data

User 看到 banner、但每次資料其實都是 fresh（refresh 完成）→ banner 變 noise。Banner 撤掉後又會在某次 revalidation 失敗時 leak 出 stale data → 信任崩潰。

Layered Consistency 的三設計原則

原則 1：L2 自動補時、訊號明示「這是 fallback」

L2 不該無聲補強。當 L2 觸發、UI 應該標示：

關鍵：「自動補但隱形」是 silent UX、跟 #82 字面攔截 vs 行為精煉 的「false confidence」同骨。

原則 2：L1 hint 要承認 L2 的存在

L1 hint 不該假裝是「全部能做的事」：

1壞：搜尋為前綴匹配、找 backpressure 請打 backpre
2好：搜尋優先前綴匹配；找不到時會 fallback 到 substring（顯示時會標示）。
3   想精準找 backpressure 直接打完整詞、或打 backpre。

L1 講 capability + L2 講 fallback、合在一起 = 完整的 mental model。

原則 3：可 trace 「結果怎麼來的」

User 能（不必、但能）看到結果的來源層：

• Search result 標 “prefix match” / “substring fallback”
• API response 標 from_cache: true 或 freshness_seconds: 30
• LLM response 標「來自 RAG retrieval / 來自 base model knowledge」

可 trace ≠ 強制顯示、是「想知道時可以知道」。預設可隱藏、debug / 進階 user 可展開。

反模式

何時 conflicting / redundant 是合理的

少數情境：

三類共通：訊號重複的成本 < 訊號漏掉的成本。其他情境追求 layered consistent。

跟其他抽象層原則的關係

套用到當前 search planning case

D + C1 疊加 case：

Bad（conflicting）：

1D hint: "搜尋為前綴匹配、找 backpressure 請打 backpre"
2C1 fallback: 打 "pre" 自動 substring 找到 backpressure、跟其他 prefix result 混排

Good（layered consistent）：

1D hint: "搜尋優先前綴匹配。找不到時自動 fallback 到 substring（會標示）。"
2C1 fallback UI:
3  - Prefix matches（標準）：[後跟前綴匹配 results]
4  - Substring matches（fallback）：[標示後跟 fallback results]

User 看到的：

• 打 “pre” → 立刻看到 prefix matches（如「prefetch」）
• 同頁標 “Substring fallback” 段、列「backpressure」等 substring 命中
• 看 hint 也知道為什麼有兩段

訊號對齊、user mental model 完整。

判讀徵兆

核心：L1 + L2 疊加不是「兩個獨立 layer 各自做事」、是一個 capability gap 上的兩個訊號。訊號要對齊、否則使用者收到的 mental model 是 broken。Silent fallback 看起來簡潔、實際是 false confidence。

使用者連上遠端終端機後、無法返回首頁。

這是設計遺漏。Terminal 畫面的 connected 狀態沒有 disconnect 按鈕也沒有 back 按鈕。error 和 disconnected 狀態也沒有。使用者被困在畫面裡，唯一的出路是殺掉 app。

這不是「忘記加按鈕」的問題。回頭看企劃文件，操作盤點段確實列了「連線失敗顯示無法連線」這個失敗情境，但沒有系統性地問：這個畫面有幾個狀態？每個狀態能做什麼操作？怎麼離開？

本文整理畫面狀態機設計的方法、示範用狀態矩陣捕捉導航缺口、歸納 mobile app UX 的三個設計原則。

實際案例：Terminal 畫面的五個狀態

Terminal 畫面有一個 TerminalScreenUiState enum 定義了五個狀態：

1enum TerminalScreenUiState { idle, connecting, connected, error, disconnected }

實機測試前、這五個狀態各自的 UI 長這樣：

五個狀態、零個退出路徑。使用者一旦進入 Terminal 畫面就出不去。

問題不在按鈕、在設計方法

加 back 按鈕是 5 分鐘的事。真正的問題是：企劃階段沒有工具強制你為每個狀態想退出路徑。

操作盤點表長這樣：

「前端引導」只有一句話。它沒有被展開成畫面狀態。「連線失敗顯示無法連線」這句話覆蓋了 error 狀態的顯示，但沒有回答操作（重連？返回？）和退出（怎麼離開這個畫面？）。

畫面狀態矩陣

把狀態機設計變成一張表，強制回答每個狀態的四個面向：

表格的威力在「退出路徑」欄位：如果這格是空的，這就是一個 UX 死胡同。

三個 Mobile App UX 設計原則

從這個案例提煉出的三個原則，適用於所有 mobile app：

原則 1：每個畫面的每個狀態都需要退出路徑

沒有例外。即使是「connecting」這種過渡狀態，使用者也可能想取消。iOS 的 HIG 和 Material Design 都要求 modal 畫面提供 dismiss 機制 — 如果使用者進不了某個狀態的下一步（連線失敗、timeout、服務無回應），他至少得能退出。

反模式：假設使用者只走 happy path。「connected 之後使用者不會想回首頁」是開發者的假設，不是使用者的需求。

原則 2：Gate 必須有 fallback

Gate = 使用者必須通過的關卡（biometric、network、auth）。每個 gate 的設計不只是「成功時怎麼做」，還包含「失敗時的替代路徑」。

biometricOnly: true 就是缺少 fallback 的典型案例 — Face ID 不可用（戴口罩、光線差、指紋模糊）時使用者直接被擋住，沒有替代方案。改為 biometricOnly: false 讓系統提供密碼 fallback。

原則 3：輸入機制是設計產物，不是實作細節

「手機打字操作 CLI」的輸入設計決策比想像的多：

這些決策在企劃階段就應該做，因為它們影響 UI layout（是否需要輸入框？工具列放什麼鍵？）和 protocol 設計（逐字元還是整行？）。事後補的 TextField 參數列表（enableSuggestions: false, autocorrect: false, enableIMEPersonalizedLearning: false）全是散落的 hotfix，不是設計產物。

系統性方法：從操作盤點到畫面狀態矩陣

操作盤點是 BDD 的起點（使用者做什麼、成功時發生什麼、失敗時發生什麼）。但盤點到「前端引導」就停了 — 它回答了「顯示什麼」但沒回答「能做什麼」「怎麼離開」。

補上的步驟：

1. 從操作盤點列出所有畫面：每個操作涉及哪些畫面？（首頁 → 配對畫面 → QR 掃描 → 終端機畫面）
2. 每個畫面列出所有狀態：這個畫面有哪些 enum 值或邏輯分支？
3. 填畫面狀態矩陣：顯示 / 可用操作 / 進入條件 / 退出路徑。退出路徑欄位為空 = UX 死胡同
4. 每個 gate 標注 fallback：biometric / network / auth 各有什麼替代方案？
5. 輸入機制列決策表：keyboard type / submit model / IME policy / special keys

這是操作盤點本來就該產出的下一層。一張表能在 10 分鐘內暴露所有 UX 死胡同，省掉實機測試才發現的成本。

延伸閱讀

本文的觀察和判讀在 UX Design 畫面設計 教學系列中展開為系統性的教學模組：畫面狀態矩陣的定義與填寫方法、Gate 分類與三問設計法、輸入機制決策表。