怎麼設計零伺服器的 QA 系統？從 YAML 知識庫到 Netflix 卡片的啟發

原文（蒸餾精華 第 6 段 + 第 9 段）

第 6 段：QA 導向的檔案命名

檔案名稱用問句，不用主題。命名本身就是搜尋的入口。

壞：第一章_人工智慧概論.txt
好：什麼是AI-機器學習與深度學習的定義.txt

第 9 段：YAML 知識庫 + rg 搜尋

101 個 YAML 檔案就是一座知識庫。不需要資料庫，不需要後端，rg（ripgrep）搜尋 101 個檔案只要 0.1 秒。檔案就是資料庫。

Claude 的白話解釋

檔案命名：問句 > 主題

「什麼是AI-機器學習與深度學習的定義.txt」比「第一章_人工智慧概論.txt」好在兩個地方：

1. 對機器好：語意搜尋時，問句型檔名的關鍵字密度更高。rg "機器學習" 會直接命中檔名，不用打開檔案才知道裡面講什麼。
2. 對人好：瞄一眼就知道這個檔案回答什麼問題。不用打開、不用猜、不用記。

一個好的檔名，應該讓你不用打開就知道裡面在講什麼。問句型命名天然做到這件事。

YAML + rg：檔案就是資料庫

101 個檔案是不是很多？不是。對 rg 來說，這連熱身都不算。rg 搜尋 101 個 YAML 檔案只要 0.1 秒——比任何資料庫的冷啟動都快。

不需要 MongoDB，不需要 PostgreSQL，不需要任何 ORM。YAML 檔案放在資料夾裡，rg 就是你的查詢引擎。新增知識？新增一個 .yaml 檔。刪除知識？刪掉一個檔案。版本控制？git log。

整個系統的複雜度等於零。

我的提問：我的 blog 似乎沒有按照 QA 命名準則吧？

讀完第 6 段，我突然回頭看自己的部落格。19 篇文章，標題長什麼樣？

數位轉型第一步：先有數位身分
品牌信任不是 Logo 好不好看
學習平台到底該怎麼設計

全部都是陳述句。我一邊講 QA 命名有多好，一邊自己的文章全是「主題式命名」。

我直接問 Claude：「我自己的 blog 標題是不是違反了剛才說的原則？」

Claude 的回答：對，16 篇是陳述型，只有 3 篇接近問句型

Claude 掃完我全部 19 篇文章，結論很直接：

• 16 篇：陳述型（像教科書章節名）
• 3 篇：接近問句型，但也不夠到位

舉幾個改前改後的例子：

問句型標題做到兩件事：

1. 讀者一看就知道這篇回答什麼問題——不用猜、不用點進去才知道
2. 搜尋引擎更容易匹配——使用者搜尋時通常用問句，標題是問句 = 天然 SEO

我當場就把 19 篇全部改了。不是未來改，是那次對話結束前就改完。

我又追問：融合之前學的誠實介面概念，QA 問答集應該用 Stripe 搜尋欄形式

改完標題之後，我腦子裡開始串東西。

之前在第 4 段（誠實介面）學到一個核心原則：介面的外型就是承諾，能力不到就別用那個外型。 Stripe 的搜尋欄是「良好案例」——放大鏡圖示、單行輸入框、回傳文件連結清單。搜尋的外型 = 搜尋的能力。

現在第 9 段告訴我：YAML 檔案就能當知識庫，rg 就能當查詢引擎。

兩段串在一起，我看到了一個具體的產品：

• 搜尋欄（不是聊天框）——誠實地告訴使用者：這是搜尋，不是對話
• 透明顯示捕捉到的關鍵字——讓使用者看到系統「聽到了什麼」
• 回傳 QA 模板卡片——使用者自己讀，不是 AI 幫你「生成」答案
• 底層是 YAML 檔案——零伺服器、零資料庫

我跟 Claude 說：「我覺得可以把第 4 段和第 9 段接起來，做成一個真正的產品。」

Claude 的回答：你把四段學習串成了一個完整產品

Claude 說我其實串了四段，不是兩段：

串起來的架構：

使用者輸入問題
  ↓
搜尋欄（不是聊天框）
  ↓
顯示捕捉到的關鍵字（透明）
  ↓
rg 搜尋 YAML 檔案
  ↓
回傳 QA 模板卡片（使用者自己讀）

Claude 還加了一個我沒想到的增強：當搜不到結果時，讓使用者修正關鍵字。因為關鍵字已經透明顯示了，使用者可以直接看到「系統聽錯了什麼」，自己修正再搜一次。

這比聊天框的體驗更好。聊天框搜不到，你只能換句話說，但不知道系統哪裡沒聽懂。搜尋欄 + 關鍵字顯示，你一眼就看到問題在哪。

我又追問：應該要有動態追蹤機制，像不滿意回饋的飛輪

搜尋做出來了，但怎麼知道使用者滿不滿意？怎麼知道哪些問題缺答案？

我想到之前討論的知識庫飛輪——系統從使用者行為中學習，越用越聰明。QA 搜尋系統也應該有這個機制：

1. 使用者搜尋但沒結果 → 記錄下來，代表知識庫缺這個主題
2. 使用者看了結果但按「不滿意」 → 記錄下來，代表答案品質不夠
3. 使用者連續搜尋同一個主題 → 代表第一次的結果沒解決問題

從這些行為資料，反向工程出「缺少哪些 QA 模板」，然後補上。這就是飛輪。

Claude 的回答：漸進式揭露，Netflix 式三級回饋

Claude 說回饋機制最怕的是「問太多」。使用者搜尋完，你跳出一堆問題問他滿不滿意，他直接關掉。

解法是漸進式揭露（Progressive Disclosure）：

第一級：最輕量

搜尋結果旁邊只有兩個按鈕：

👍  👎

大多數人會點其中一個。一秒完成。

第二級：只有不滿意才展開

只有按了 👎 才顯示更多選項：

□ 答案不對
□ 答案太簡略
□ 不是我要問的問題

滿意的人不會被打擾，不滿意的人有管道表達。

第三級：可選的自由文字

勾選完之後，才出現一個小文字框：

想補充什麼？（可跳過）

再下面，一個連結：

想跟真人聊聊？→ 預約諮詢

從最輕（一個按鈕）到最重（預約諮詢），每一步都是可選的。不強迫，不打擾。

只追蹤三件事

Claude 說不要貪多，整個系統只需要追蹤三件事：

1. 搜尋詞（有結果 / 無結果）——知道知識庫覆蓋率
2. 👍 / 👎——知道答案品質
3. 連續搜尋——知道使用者是否真正解決了問題

三個數字就能驅動飛輪：無結果的搜尋詞 → 新增 QA 模板；👎 多的 QA → 改善答案；連續搜尋多的主題 → 拆分成更精確的子問題。

我又追問：Netflix 的卡片元素為什麼這麼精練？

討論到 QA 結果卡片的設計時，我想到 Netflix。Netflix 的影片卡片是全世界被 A/B 測試最多次的 UI 元素之一。每一個按鈕、每一個圖示，都經過幾百萬次測試才留下來。

我打開 Netflix，截了 8 張不同互動狀態的卡片截圖，仔細分析每一個元素：

基本狀態

滑鼠移上去（或手機長按），卡片展開，出現六個操作：

零多餘

我一開始以為 ✓ 和 ✕ 是相反的操作（加入 / 移除口袋名單）。但仔細看，它們做的事完全不同：

• ✓ My List：「我想看但不是現在」——正向策展，影響你的清單
• ✕ Not for me：「這個不適合我」——負向信號，影響推薦演算法

一個影響清單，一個影響演算法。兩個按鈕，零重疊。

三級讚

Netflix 的 👍 不是二元的（喜歡 / 不喜歡）。長按會展開三個選項：

👎 不合我的胃口
👍 我喜歡
👍👍 超愛！

為什麼要三級？因為「喜歡」和「超愛」對推薦演算法的權重不同。如果你對一部紀錄片按了「超愛」，Netflix 會大幅增加同類型紀錄片的推薦比例。只按「喜歡」的話，增加幅度小得多。

三個等級就足以捕捉品味的強度。不多不少。

進度條

已經看過的影片，卡片底部會有一條紅色進度條。這個設計看似簡單，但資訊密度極高：

• 有進度條 = 你看過
• 進度 30% = 你可能棄劇了（Netflix 會據此調整推薦）
• 進度 95% = 你看完了（可以推薦續集或類似作品）

一條紅線，三種判斷依據。

Claude 的回答：Netflix 卡片直接對照 QA 結果卡片

Claude 說 Netflix 卡片的設計可以直接映射到 QA 結果卡片：

關鍵洞察

Netflix 教我們的不是「做得像 Netflix」，而是一個設計原則：每個元素都要有不可替代的理由。

Netflix 卡片上的六個操作，每一個都影響不同的系統面向。沒有兩個按鈕做一樣的事。沒有「裝飾性」的元素。如果拿掉任何一個，系統就會少一個維度的資料。

QA 卡片也該這樣設計：每個按鈕、每個資訊，都要有不可替代的用途。不是為了好看，是為了功能。

我又追問：YAML QA 模板有沒有平庸 / 通用 / 頂尖的案例？

最後我問了一個實作問題：知道要用 YAML 當知識庫了，但 YAML 模板本身怎麼設計？有沒有等級之分？

Claude 給了三個等級：

平庸：扁平結構

question: 什麼是資安法
answer: 資安法全名為資通安全管理法，於2019年施行...

沒有 ID、沒有分類、沒有標籤。搜得到，但無法分類、無法關聯、無法追蹤。像一張散落的便條紙。

通用：結構化

id: SEC-001
category: 法規
tags: [資安法, 合規, 政府]
question: 什麼是資安法？適用對象有哪些？
answer: |
  資通安全管理法（簡稱資安法）於 2019 年 1 月 1 日正式施行。

  **適用對象：**
  - 公務機關
  - 特定非公務機關（關鍵基礎設施提供者）

  **核心要求：**
  1. 建立資通安全管理制度
  2. 通報資安事件
  3. 定期稽核
related:
  - SEC-002  # 資安法罰則
  - SEC-005  # 關鍵基礎設施定義

有 ID（帶前綴，方便識別領域）、有分類和標籤（方便篩選）、答案用 Markdown（方便渲染）、有關聯連結（方便延伸）。這是大多數場景的最佳選擇。

頂尖：帶分析鉤子

id: SEC-001
version: 3
category: 法規
tags: [資安法, 合規, 政府]
question: 什麼是資安法？適用對象有哪些？
answer: |
  （同上）
confidence: 0.95
source:
  - type: official
    url: https://law.moj.gov.tw/...
    retrieved: 2026-03-15
  - type: interpretation
    author: 資安署
    date: 2025-12-01
analytics:
  created: 2026-01-10
  last_matched: 2026-04-01
  match_count: 47
  thumbs_up: 38
  thumbs_down: 3
  last_reviewed: 2026-03-15
  review_cycle_days: 90
changelog:
  - date: 2026-03-15
    change: 更新適用對象，新增特定非公務機關
  - date: 2026-01-10
    change: 初始建立
related:
  - SEC-002
  - SEC-005

多了什麼：

• confidence 分數：系統對這個答案的信心程度。低於門檻就提醒使用者「此答案可能需要更新」
• source 來源標註：每個答案附上來源，可驗證。和 Perplexity 的設計精神一致
• analytics 分析鉤子：追蹤匹配次數、👍👎 比例、最後一次被搜尋的時間。飛輪的數據來源
• changelog 變更紀錄：知道答案改過幾次、改了什麼。git log 的替代方案
• review_cycle_days：每 90 天提醒審核。知識會過期，強制定期檢查

Claude 的建議：先用通用版啟動，邊用邊加欄位。 一開始就用頂尖版，反而會因為欄位太多而不想新增知識。先跑起來，再慢慢進化。

我學到的

一個 QA 系統從知識庫（YAML）到介面（搜尋欄 + 卡片）到飛輪（回饋 + 追蹤），可以完全零伺服器、零資料庫、零框架實現。

回頭看整條線：

QA 命名（第 6 段）
  → 檔名即問題，天然可搜尋
    → YAML 知識庫（第 9 段）
      → 檔案即資料庫，rg 即查詢引擎
        → 誠實介面（第 4 段）
          → 搜尋欄外型 = 搜尋能力
            → Netflix 卡片分析
              → 每個元素都要有不可替代的理由
                → 漸進式回饋飛輪
                  → 三個數字驅動持續改善

Netflix 教我們的不是「做得像 Netflix」，而是「每個元素都要有不可替代的理由」。拿掉一個按鈕，系統就少一個維度的資料。加一個沒用的按鈕，使用者就多一秒的遲疑。

零伺服器不是限制，是優勢。當你的知識庫就是一堆 YAML 檔案，你的查詢引擎就是 rg，你的版本控制就是 git，你的部署就是 git push——整個系統的複雜度趨近於零。複雜度趨近於零，意味著你的注意力可以全部放在內容品質上，而不是維護基礎設施。

這才是零框架的真正意義：不是買不起工具，是不需要。