前幾天，我們已經完成：

• Day 6：把需求轉換成 User Story 與 MVP
• Day 7：建立資料契約與資料字典
• Day 8：使用 RAG 讓 AI 根據專題資料回答

但是，如果 RAG 只能在聊天工具裡展示，評審可能會繼續問：

• 使用者要在哪裡輸入問題？
• 系統正在處理時，畫面會顯示什麼？
• AI 的答案來自哪份資料？
• 沒有找到答案時，使用者會看到什麼？
• API 失敗或超時時，網站會不會整個壞掉？
• 推薦結果是否真的能完成專題的核心流程？

因此，今天要把 RAG 從「後端技術」轉換成「使用者可以操作的網站功能」。

今天的目標

我們要完成一個最小可行的 AI 查詢介面：

1. 使用者輸入問題與條件。
2. 網站將資料送到後端 API。
3. 後端驗證輸入內容。
4. 系統搜尋專題資料。
5. AI 根據搜尋結果產生回答。
6. 網站顯示回答與來源卡片。
7. 發生錯誤時，網站顯示清楚的處理方式。

今天不追求漂亮動畫，而是先確保：

使用者知道自己輸入了什麼、系統正在做什麼，以及答案根據哪裡的資料。

RAG 網站的基本架構

網站不要直接把 API 金鑰放在瀏覽器裡。

比較安全的架構是：

使用者
-> 網站介面
-> 後端 API
-> 資料檢索
-> AI 模型
-> 回傳回答與來源
-> 網站顯示結果

請在下方位置插入今天的架構圖。

圖 1：RAG 網站從使用者輸入、後端驗證、資料檢索、AI 生成，到來源卡片、錯誤處理及操作紀錄的完整流程。

圖片替代文字：

RAG 網站由使用者介面、後端 API、檢索器與 AI 模型組成，並將來源卡片、安全錯誤及操作紀錄回傳給使用者。

製作方式：自行繪製 SVG 並輸出為 1800 × 1100 PNG，未使用來源不明的網路圖片。

為什麼不能讓前端直接呼叫 AI API？

初學者可能會想：

網頁按鈕
-> 直接呼叫 AI API
-> 顯示回答

這樣做的主要問題是：

• API 金鑰可能被使用者看到
• 任何人都可能複製金鑰使用
• 無法統一限制請求次數
• 無法記錄錯誤與使用版本
• 使用者輸入可能繞過後端檢查
• 未來很難更換模型或檢索方式

比較好的方式是：

前端只呼叫自己的後端 API
後端再呼叫檢索服務與 AI 模型

前端只需要知道：

• 要送出什麼資料
• 回來的結果有哪些欄位
• 發生錯誤時要顯示什麼

先設計 API 契約

在寫網站之前，先決定前端與後端如何溝通。

請求格式

{
  "question": "晚上還有 100 元以下的素食餐點嗎？",
  "budget": 100,
  "diet_tags": ["vegetarian"],
  "time": "2026-09-23T18:30:00+08:00",
  "dataset_version": "places_v1.0"
}

成功回應格式

{
  "status": "success",
  "answer": "目前資料中有兩個可能符合條件的項目。",
  "sources": [
    {
      "source_id": "SRC001",
      "title": "校園餐廳公告",
      "url": "https://example.edu.tw/dining",
      "verified_at": "2026-09-22T09:00:00+08:00"
    }
  ],
  "retrieved_count": 3,
  "dataset_version": "places_v1.0"
}

沒有結果的回應

{
  "status": "no_result",
  "answer": "目前資料中沒有完全符合條件的項目。",
  "suggestions": [
    "放寬預算條件",
    "移除飲食限制",
    "改變搜尋時段"
  ],
  "sources": [],
  "dataset_version": "places_v1.0"
}

錯誤回應

{
  "status": "error",
  "error_code": "SERVICE_TIMEOUT",
  "message": "目前查詢時間較久，請稍後再試。",
  "retryable": true
}

API 契約的好處是：

• 前端與後端可以平行開發
• 組員知道每個欄位的意義
• 不同工具可以使用相同格式
• 測試時可以準備固定資料
• 出錯時能快速定位問題

網站介面至少需要五種狀態

一個 AI 查詢頁面不能只有「有結果」和「沒有結果」。

1. 初始狀態

使用者還沒有輸入問題。

畫面可以顯示：

請輸入你的預算、地點與需求。
例如：晚上 100 元以下的素食餐點

2. 載入狀態

系統正在搜尋資料或等待 AI 回覆。

畫面可以顯示：

正在搜尋專題資料...
正在整理符合條件的結果...

不要只顯示一個無限旋轉圖示，因為使用者不知道系統到底在做什麼。

3. 成功狀態

回答應該分成三個區域：

• AI 回答
• 推薦項目
• 來源卡片

4. 沒有結果

不要只顯示：

查無資料

應該提供下一步：

目前沒有完全符合的資料。

你可以嘗試：

- 放寬預算
- 更換搜尋地點
- 移除部分限制
- 改用較早的時段

5. 錯誤狀態

錯誤訊息應該讓一般使用者看得懂：

目前服務暫時忙碌，資料沒有遺失。
請稍後再試，或先查看目前可用的資料。

不要直接把伺服器錯誤內容顯示給使用者，例如：

Internal Server Error
Database Connection Failed

這些內容對開發者有用，對一般使用者沒有幫助。

來源卡片要顯示什麼？

如果 AI 回答沒有來源，使用者很難判斷可信度。

每張來源卡片至少應包含：

範例：

來源：校園餐廳公告
類型：官方網站
查證時間：2026-09-22
資料版本：places_v1.0
狀態：已查證
查看原始資料

來源卡片不應該只是裝飾。

評審點開來源後，應該能理解：

• 這筆資料從哪裡來
• 什麼時候取得
• 是否可能已經過期
• AI 回答引用了哪些內容

AI 回答不要只回傳一段文字

錯誤做法：

{
  "answer": "推薦校園素食坊。"
}

這樣網站不知道：

• 為什麼推薦
• 使用了哪一筆資料
• 這筆資料是否已查證
• 是否符合使用者條件

比較完整的格式：

{
  "status": "success",
  "answer": "目前有一個項目符合預算與飲食條件。",
  "recommendations": [
    {
      "place_id": "P0001",
      "name": "校園素食坊",
      "reason": "價格範圍符合預算，資料中標示為素食。",
      "matched_conditions": [
        "budget",
        "diet"
      ],
      "verification_status": "verified",
      "source_id": "SRC001"
    }
  ],
  "warnings": [
    "營業時間尚未完成今日查證"
  ]
}

這樣網站可以分別顯示：

• 店家名稱
• 推薦理由
• 符合條件
• 資料狀態
• 注意事項
• 來源連結

用提示詞要求 AI 回傳固定格式

請根據提供的專題資料回答使用者問題。

輸出必須包含：

1. status
2. answer
3. recommendations
4. matched_conditions
5. warnings
6. sources
7. dataset_version

規則：

- 只能使用提供的資料。
- 沒有證據時，請寫入 warnings。
- 不要自行補上價格、營業時間或地址。
- 每個推薦項目都要對應 source_id。
- 如果沒有完全符合的項目，status 使用 no_result。
- 如果系統無法完成查詢，status 使用 error。
- 不要輸出未定義的欄位。

提示詞可以幫助 AI 產生一致格式，但不能完全取代程式檢查。

後端仍應檢查：

• status 是否為允許值
• sources 是否為清單
• recommendation 是否包含必要欄位
• dataset_version 是否存在
• 回答是否超過預設長度

前端表單的基本欄位

第一版不需要做得很複雜。

建議包含：

送出前可以做基本檢查：

• 問題不可為空白
• 預算必須是合理數字
• 地點必須選擇
• 飲食標籤不可使用未定義值
• 不允許一次送出過大的文字

前端檢查是為了改善使用體驗。

真正的安全檢查仍然必須放在後端。

常見錯誤一：把 API 金鑰放在前端

不要把秘密金鑰寫進：

• HTML
• React 元件
• 公開 JavaScript
• GitHub 儲存庫
• 前端環境變數

即使名稱叫做 secret，只要被打包到瀏覽器，使用者仍可能看到。

API 金鑰應該只存在後端服務的環境設定中。

常見錯誤二：沒有處理超時

AI 查詢可能受到：

• 網路不穩
• 服務繁忙
• 檢索速度變慢
• 請求內容太長
• API 額度不足

影響。

網站至少要提供：

查詢時間過久，請稍後重試。

同時記錄：

• 請求時間
• 使用者問題的識別碼
• 使用的資料版本
• 錯誤類型
• 是否可以重新嘗試

不要自動無限重試，否則可能造成更多請求與額外成本。

常見錯誤三：只測試正常情況

至少要測試：

• 空白問題
• 超長問題
• 沒有符合條件
• 資料來源失效
• AI 回傳格式錯誤
• API 超時
• 使用者連續按下送出
• 網路中斷
• 使用舊資料版本

AI 專題的 Demo 不只要展示成功案例，也要能說明失敗時如何處理。

常見錯誤四：把錯誤訊息藏起來

如果網站查詢失敗，不能只顯示空白畫面。

使用者需要知道：

• 目前發生什麼事
• 資料是否遺失
• 是否可以重新嘗試
• 是否有替代操作

透明的錯誤狀態會比假裝系統永遠成功更可靠。

建立一份前端驗收表

今天的實作練習

任務一：畫出網站流程

請畫出以下流程：

輸入條件
-> 前端檢查
-> 顯示載入狀態
-> 呼叫後端 API
-> 顯示回答
-> 顯示來源

另外畫出：

API 失敗
-> 顯示錯誤
-> 提供重新嘗試

任務二：定義 API 契約

完成：

• 請求欄位
• 成功回應
• 沒有結果回應
• 錯誤回應

任務三：製作三種畫面

至少完成：

1. 初始畫面
2. 成功結果畫面
3. 錯誤或沒有結果畫面

任務四：設計來源卡片

每張卡片至少顯示：

• 來源名稱
• 資料類型
• 查證時間
• 資料版本
• 原始連結

任務五：進行五次測試

測試：

• 正常問題
• 空白問題
• 沒有結果
• API 失敗
• 使用手機操作

今日重點

把 RAG 接到網站，不只是增加一個聊天輸入框。

一個可靠的 AI 網站必須同時處理：

使用者輸入
-> 後端驗證
-> 資料檢索
-> AI 生成
-> 來源回傳
-> 狀態顯示
-> 錯誤處理
-> 人工驗收

今天的核心觀念是：

AI 的回答只是結果，網站還必須讓使用者理解結果如何產生。

能得獎的 Demo 通常不只展示成功回答，也能展示：

• 資料來源
• 查詢條件
• 目前版本
• 沒有答案時的處理
• 系統失敗時的替代方案

下一篇預告

Day 10，我們將使用 Vibe Coding 加速製作網站，學習如何把需求、資料契約與 API 規格交給 AI 協助開發，同時避免產生看似能跑、實際無法驗收的程式。

官方參考資料

1. OpenAI API
   https://developers.openai.com/api/

2. OpenAI File Search
   https://developers.openai.com/api/docs/guides/tools-file-search

3. Google Cloud RAG Engine
   https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/rag-overview

4. GOV.UK API 設計指南
   https://www.gov.uk/service-manual/technology/application-programming-interfaces-apis

5. MDN Fetch API
   https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

以上資料於 2026 年 9 月 23 日查閱。API 功能、模型方案、免費額度與價格可能變動，使用前請以官方最新文件為準。