搜尋 UX 模式

Fri, 19 Jun 2026 00:00:00 +0000

搜尋輸入的核心決策是「使用者輸入到什麼程度觸發搜尋」。這和 terminal 輸入的 submit model 維度相同 — 差別在 terminal 場景的選項是「整行 vs 逐字元」，搜尋場景的選項是「按送出 vs 即時 vs debounce」。

三種觸發模式

按送出觸發

使用者打完搜尋詞、按搜尋按鈕後觸發一次搜尋。最簡單的模式 — 一次搜尋、一次 API 呼叫、一次結果顯示。

適合搜尋成本高的場景：資料庫全文搜尋、外部 API 呼叫（有速率限制或費用）、搜尋結果需要複雜運算。

即時觸發（instant）

使用者每輸入一個字元就觸發搜尋。結果即時更新，使用者可以在輸入過程中看到搜尋結果逐漸精確。

適合搜尋成本低的場景：client 端的本地過濾、記憶體內的資料集篩選、已快取的少量資料。

即時觸發在搜尋成本高的場景會產生問題：使用者輸入 hello 的過程中觸發五次 API 呼叫（h、he、hel、hell、hello），前四次的結果在使用者看到之前就被覆蓋。浪費的 API 呼叫增加 server 負載和使用者的網路流量。

Debounce 觸發

使用者停止輸入一段時間後（通常 300-500ms）觸發搜尋。平衡即時回饋和 API 呼叫次數 — 使用者連續打字時不觸發，停下來時觸發一次。

Debounce 是遠端搜尋場景的常見選擇。延遲時間的設定是 UX trade-off：太短（100ms）接近即時觸發，API 呼叫次數多；太長（1000ms）使用者感覺到明顯延遲。300-500ms 是多數場景的合理區間。

搜尋結果的顯示

Suggestion list（建議列表）

在搜尋框下方即時顯示候選結果。使用者可以點選候選項完成搜尋，不需要打完整個搜尋詞。

Suggestion list 適合搜尋詞有限且可列舉的場景（城市名、產品名、使用者名）。搜尋詞無限（全文搜尋）時 suggestion list 的候選項品質依賴搜尋演算法。

結果頁

使用者送出搜尋後導航到獨立的結果頁面。適合結果量大、需要分頁、每筆結果需要較多空間展示的場景。

即時過濾（filter）

在現有列表上即時隱藏不符合搜尋條件的項目，不導航到新頁面。適合「在已經看得到的清單中找到特定項目」的場景。

keyboard type 和 textInputAction

搜尋框的 keyboard type 通常用 text（一般文字），搭配 textInputAction: search 讓鍵盤的 Enter 鍵顯示搜尋圖示（放大鏡）而非換行或送出圖示。

這個細節影響使用者的操作直覺 — 看到搜尋圖示的按鈕，使用者知道按下去會觸發搜尋；看到換行圖示，使用者可能猶豫按下去會不會換行。

下一步路由

四維度決策表總覽 → 輸入機制決策表
Terminal 場景的 submit model → Terminal app 輸入設計
表單場景的驗證設計 → 表單 UX 模式

搜尋引擎的匹配模式跟使用者預期的對齊

Sun, 26 Apr 2026 00:00:00 +0000

核心原則

搜尋引擎的「匹配模式」是個經常被忽略的維度 — 工具的預設行為跟使用者的 mental model 不對齊時、產生 silent 失敗：使用者打字、看不到預期結果、誤以為「沒有」、不會 report bug。

匹配模式	例：query「pre」會匹配	典型來源
Exact	`pre`（不含「pre」這個 token）	DB `=` 比較
Prefix	`pre`、`prefix`、`prefetch`、`presence`	Pagefind / Lunr 預設
Substring	上面 + `backpressure`、`SuperPress`	DB `LIKE '%pre%'`
Fuzzy	上面 + `prv`、`pre1`（編輯距離）	Algolia、TypeSense
Semantic	上面 + `before`、`prior`（語意相近）	Vector search / LLM

使用者被 Google / 桌面搜尋訓練、預期 substring 或更高層級。預設拿到 prefix 的 site search → 「pre」找不到 backpressure → 看起來像 bug 但其實是 capability 落差。

為什麼預設是 prefix

Static site search engines（Pagefind / Lunr / MiniSearch 預設）選 prefix matching 的原因：

因素	Prefix	Substring
Index size	O(N)	O(N²)（要 index 所有後綴）
Query speed	快（trie）	慢（全掃 substring）
跨語言支援	容易	中文 / CJK 邊界不明確
Build time	快	慢

對 static site（沒 server）、index 是要下載到 client 的 — substring index 可能 5-10x 大、unacceptable。Pagefind / Lunr 選 prefix 是「對齊 size constraint」、不是「對齊使用者意圖」。

這是個典型的 #67 寫作便利度跟意圖對齊反相關 — 工具預設是「實作便利位置」、不是「使用者意圖位置」。

為什麼這個 gap 是 silent

跟 #55 Filter × Source 層錯位共用結構：使用者打字看到結果列表、結果不空、看起來「有東西」、不會懷疑 engine 沒在做完整 search。

silent 失敗的條件：

Prefix matching 對某些 query 仍能回到結果（排版上看起來「有用」）
使用者不知道「沒看到的還有什麼」
只有當 query 剛好不是任何 token 的 prefix、才會 0 結果（極少見、這時才會懷疑）

對照 #55 silent 失敗條件三條件 — 完全一樣的結構：「有部分結果掩蓋了缺口」。

多面向：跨工具的匹配模式對照

前端 client-side search

工具	預設匹配模式	可調整為
Pagefind v1.5	Word-prefix	Exact only（`useExact`）
Lunr	Stem + prefix	Wildcard（`q+'*'`）
MiniSearch	Prefix	Substring（`prefix: false, fuzzy: 0.2`）
FlexSearch	Token-based	多種 tokenizer（含 ngram）
Fuse.js	Fuzzy	可關掉 fuzzy 變 substring

Backend / DB

工具	匹配模式
SQL `=`	Exact
SQL `LIKE '%X%'`	Substring（O(n) scan）
SQL FULLTEXT	Token + stem + (有時 prefix)
ElasticSearch	配置：term / match / wildcard / fuzzy / regexp
PostgreSQL trigram	Substring + similarity
Vector DB（Pinecone 等）	Semantic

命令列 / IDE 搜尋

工具	預設
`grep`	Substring（regex）
`rg`	Substring（smart-case + regex）
Vim `/`	Regex
VSCode 搜尋	Substring（含 fuzzy file search）

共通結構：每個工具預設不同、使用者帶著舊工具的 expectation 來、不對齊時 silent 失敗。

識別三問

寫之前 / debug 時、自問：

1. 這個工具的預設匹配模式是什麼？

讀 docs、不要假設。Pagefind docs 寫 “Pagefind matches by word prefix”。Lunr 文件寫 “Lunr does prefix matching by default”。預設不是直覺。

2. 使用者預期哪種匹配模式？

使用者被別的工具訓練。使用者基數越大、越接近 Google substring + fuzzy 預期。

使用者類型	預期匹配模式
一般使用者（被 Google 訓練）	Substring + fuzzy + semantic
開發者（用 grep / IDE）	Substring + regex
資料庫使用者（寫 SQL）	看你給的 hint
命令列重度使用者	預設 regex

3. Gap 多大？是否 silent？

工具預設 vs 使用者預期不一致時、評估「使用者會在多少 case 中遇到不一致」。

Prefix vs Substring：使用者只要打詞中間部分就 silent 失敗、頻率高
Prefix vs Fuzzy：使用者打錯字才會發現、頻率低
Substring vs Semantic：使用者用同義詞才會發現、頻率中

頻率高的 gap 必須有對策。

五種對策（跟 #59 Filter × Source 五策略同構）

A：選用支援目標匹配模式的引擎

Pagefind 不支援 substring → 換 MiniSearch / FlexSearch。Lunr 不支援 fuzzy → 換 FlexSearch / Fuse.js。

適合：早期決策、index size 不是 bottleneck、能接受工程量
代價：換引擎成本（API 不同、index 重建、UI 重整合）

B：在 build time pre-tokenize、增加替代 token

在 build pipeline 拆字、把 backpressure 加進 search index 的多個 token：back + pressure + backpressure + back-pressure。Pagefind 透過 data-pagefind-meta 或多份 hidden text 注入。

適合：少量已知關鍵詞 / 跨語言邊界（中文）/ 能控 build pipeline
代價：手動標記、index 變大、新詞要加進清單

C：Client-side fallback substring search

Pagefind 找不到時、fetch 一份頁面 metadata（title + slug）、做 client-side substring filter。

適合：頁面數量 < 10000、可接受第二層延遲
代價：需要額外 fetch + 客戶端 substring scan、兩種 result UI 整合

D：UX hint 明示匹配模式

把限制告訴使用者：「搜尋為前綴匹配、想找 X 請打 Y」。對應 #66 明示語意縮小。

適合：成本最低、只需文字 hint
代價：使用者要學新規則、不對齊 Google expectation

E：接受限制（不告知）

不做任何處理、silent 接受。這是反模式（同 #55 silent 失敗）— 使用者誤以為「沒有相關內容」、放棄。

跟其他抽象層原則的關係

原則	跟本卡的關係
#55 Filter × Source 層錯位	都是「使用者意圖跟工具實際行為的 silent gap」、本卡是 matching 維度的展現
#63 資料源的形狀	形狀是 source 的 capability 維度、本卡是「matching mode」這個 capability 維度
#67 寫作便利度跟意圖對齊反相關	工具預設是實作便利、使用者預期是 mental model 對齊、反相關
#68 驗收的時間軸 Checkpoint 1	「source capabilities 是否對齊使用者預期」屬意圖完整集 — 容易跳過
#72 高 ROI 無外部觸發	「讀 search engine docs 確認 matching mode」沒便利路徑、容易跳過

對應的實作篇

本 blog 搜尋頁的 Pagefind prefix-match 限制（這次 user 報的 case）
任何用 client-side search 的 SPA / 靜態站
內部 admin tool 的 search box（往往用 SQL LIKE 的 substring、跟使用者 Google 預期反方向）
ElasticSearch 配置時 term vs match query 的選擇

判讀徵兆

訊號	該做的事
寫 search feature、沒讀工具的 matching mode docs	跑識別三問、確認預設
使用者報「我搜 X 找不到、但是有 X」	多半是 matching mode gap、不是 bug
使用者打字、結果列表 0 筆、但確實有相關內容	不對齊的訊號明顯、需要對策
Search 跨多種使用者（Google trained / dev / DB user）	Mental model 異質、選擇性高（A/B + C 組合通常需要）
工具 docs 寫「matches by word prefix」這類字眼	警訊 — 預設不是 substring
Pagefind / Lunr / 任何 static site search	預設 prefix、要主動評估是否符合需求

核心原則：搜尋引擎的匹配模式是個容易被忽略的 capability 維度。工具預設多半是 prefix（為了 index size）、使用者預期多半是 substring 或更高（被 Google 訓練）。沒對齊 = silent 失敗：使用者誤以為內容不存在、不會 report bug。Checkpoint 1 列「使用者意圖完整集」要包含「使用者打字行為的預期」。

Search on Tarragon