專案背景與業務目標

1.1 客戶輪廓

恆崇企業（品牌「金絲猴」）為台灣防水材料製造商，1989 年創立，全台約 300 家經銷據點。目標客群是遇到漏水、壁癌、隔熱問題的一般屋主與小型工程行——這群人的特徵是：問題發生在晚上與週末（下雨才漏）、不會描述問題（只能拍照）、需要的是解決方案而非單品（底漆＋主材＋面漆的組合）。

1.2 業務痛點

1.3 成效目標（KPI）

方案總覽

以 LINE 官方帳號為互動平台（目標客群滲透率最高、好友資產可再行銷），LIFF 全螢幕聊天為前端，雲端 AI 顧問服務負責意圖判斷、知識庫問答、圖片判讀與導購交接（由 Anthropic Claude 模型驅動）。lead 成立時自動完成三件事：推交接摘要進顧客對話串（業務同視窗接手）、推確認訊息給顧客、自動貼受眾標籤（地區／意願／品類，供後續分眾推播）。

系統架構

3.1 業務需求與方案對應

3.2 為什麼不直接用 LINE 聊天室對話

顧客本來就在 LINE 裡，讓 AI 直接在聊天室回覆看似最短路徑。實際評估後採用「LINE 為入口與交接管道、諮詢在獨立聊天網頁」的組合，關鍵在於三件事：真人接手會與 AI 搶同一條管道、對話節奏無法約束、記憶邊界無從界定——前兩者影響正確性，第三者影響成本與品質：

取捨與補償：這個選擇的代價是多一次點擊，且諮詢內容不會留在 LINE 聊天記錄裡。因應方式是——入口用常駐的圖文選單橫幅與歡迎訊息降低摩擦（見 §5.1）；lead 成立時把交接摘要推回 LINE 對話串，等於把該留下的脈絡補回顧客與業務都看得到的地方。

使用者旅程與系統流程

4.1 對話流程

4.2 LLM 節點與記憶設計

每個 LLM 節點依任務性質決定模型等級與是否帶入對話記憶——記憶帶得太少會失去脈絡、帶得太多則增加成本與干擾，逐一取捨如下：

4.3 受眾貼標流程

lead 成立的回覆送出之後執行（不影響顧客等待時間），任一環節失敗不回滾主流程：

4.4 真人交接旅程（核心敘事）

1. AI 對話中偵測購買意圖 → 逐項收集聯絡資料（一次只問一項）
2. 四項齊全 → AI 生成交接摘要（需求／屋況／已推薦產品／意願訊號）
3. 摘要以 push 進入顧客本人的 LINE 對話串——業務在 OA Manager 打開該對話，交接脈絡就在同一視窗，不需切換系統、不需重問
4. 顧客同時收到確認訊息（複述重點＋告知專人將聯絡），從 LIFF webview 被拉回 LINE 聊天串
5. 業務的 LINE 同步收到 OA 推送的新 lead 通知，點開 OA Manager 即達該筆對話
6. 業務以真人身分於 OA Manager 直接回覆 → 結單
7. 系統同步為顧客貼上「地區／意願／品類」受眾標籤 → 沉澱為可分眾推播的名單資產

線稿與實機畫面

本章集中所有畫面素材：入口與四條對話流程的分鏡、儀表板四頁線稿，以及實機截圖。線稿呈現設計意圖，實機截圖佐證交付結果。

5.1 對話流程分鏡

從進入到交接的完整旅程：入口分鏡＋四條對話流程，各以分鏡呈現關鍵畫面與互動原則：

5.2 儀表板四頁線稿

5.3 實機畫面

功能需求（FR）

非功能需求（NFR）

錯誤處理與例外情境

兩條設計原則：任何加值功能（推播、貼標、名稱查詢）的失敗，都不得影響顧客的對話；AI 不確定時寧可不答，導向真人。以下依情境列出系統行為與補救機制：

錯誤情境的驗收案例併入 §12.2 端到端驗收執行。

整合範疇與外部相依

資料設計

10.1 資料模型總覽

對話與 lead 為兩個核心實體：每一場對話可產出至多一筆 lead，lead 再延伸出標籤與跟進紀錄；護欄攔截、產品推薦、查無記錄則掛在對話下，供第 6 章的品質指標與知識庫維運使用。

知識側分為兩類，取用方式不同不可混用：kb_documents／kb_chunks 是檢索索引（語意搜尋用的衍生資料，可隨時由來源內容重建）；guardrail_rules 是規則，集中管理後常駐於回應節點的提示詞，不進檢索池——規則必須每次生效，不能取決於檢索是否撈到。回覆實際引用了哪些片段記於 message_citations，供依據率抽測與答錯追查。

10.2 資料表定義

資料庫採 PostgreSQL；主鍵一律 UUID（訊息類高頻寫入表用 bigint 序號），時間欄位一律 timestamptz 存 UTC。

conversations｜對話場次

messages｜訊息

leads｜商機名單

tag_assignments｜分眾標籤

唯一鍵 (line_user_id, dimension)：同一顧客同一維度只保留最新標籤，避免地區改變時留下兩個互斥標籤。

guardrail_rules｜推薦護欄規則

FR-6 的護欄規則以資料表集中管理，避免散落於各處提示詞而難以維護與稽核。目前規則於回應節點載入提示詞後由模型執行，並以 rule_code 對應 guard_events 的攔截記錄；後續可加入送出前的程式比對，使護欄由模型自律升級為系統強制（見第 14 章）。

kb_documents｜知識來源文件

kb_chunks｜檢索單位

message_citations｜回答引用來源

記錄每則 AI 回覆實際注入了哪些片段。FR-1 的驗收條件「知識庫依據率抽測 ≥ 95%」需靠此表查證，答錯時亦可循此追查是內容缺漏或檢索未命中。

其他資料表

10.3 會話狀態（lead 草稿）

導購流程進行中的四個欄位存於 conversations 的 draft_*：每一輪自完整對話重新擷取後整批覆寫，因此已提供的資料不會因後續訊息而遺失，也不會被重複詢問。四欄皆非空時即建立 leads 記錄並觸發交接，草稿欄位保留供稽核比對。

10.4 知識庫內容分層

官網內容經爬取與整理後，依用途分為五層；每一層的檢索方式不同，這是知識庫設計的主軸：

第四層是最容易被忽略的設計決策：它在性質上是規則而非知識。若與其他內容一同進入檢索池，某次檢索沒撈到禁用規則時，護欄會靜默失效且不留痕跡。

10.5 檢索策略

知識庫查無資料的判定目前由模型依提示詞規範執行；後續可在檢索層加入分數門檻，使判定不再依賴模型自律（見第 14 章）。

10.6 受眾標籤詞彙表（控制詞彙，防標籤增生）

限制與已知風險

交付項目與驗收

12.1 交付項目

本案完成時須交付以下項目，缺一不得驗收：

12.2 端到端驗收案例（手機實測）

1. 加 OA 好友 → 歡迎訊息 → 開 LIFF 全螢幕聊天
2. 問「牆壁長壁癌怎麼辦」→ 依知識庫回答、無敬語、排版正確
3. 問「你是誰」與「今天天氣如何」→ 一句話回應後把話題帶回防水需求，不展開無關內容
4. 傳壁癌照片 → 辨識情境並推薦產品組合
5. 說「想約估價」→ 被逐項追問 → 留完四項資料
6. 顧客 LINE 對話串出現交接摘要與確認訊息（無 UID、顯示名稱正確）
7. OA Manager 打開該對話 → 同視窗看到摘要 → 真人身分回覆成功
8. OA 受眾清單出現「地區:／意願:／品類:」標籤，各含該顧客
9. 觸發護欄情境（磁磚面問 P-930）→ 改推安全替代品
10. 以內部帳號登入儀表板，切換四子頁與日期區間，數據與明細一致

工時與用量估算

13.1 工作項預估工時

以 1 人日＝8 小時計，逐工作項拆解如下：

13.2 流量與用量假設（容量規劃）

下列規模係依需求訪談確認的行銷投放計畫、現有 0800 話務量與官網流量推估，作為容量與成本規劃基準；上線後以儀表板實際數據逐月校準。

未來擴充（Roadmap）

1. 分眾推播旅程：以既有標籤發動 narrowcast（例：「品類:壁癌 × 意願:中」推雨季保養提醒），把名單資產轉為回購動能
2. 檢索品質強化：加入相似度門檻，使「查無資料」的判定不再依賴模型自律
3. 護欄硬化：回覆送出前依 guardrail_rules 做程式比對，命中才交由模型改寫；護欄由模型自律升級為系統強制，攔截次數亦成為可自動量測的事件
4. 儀表板進階分析：開放區間對比、經銷據點維度下鑽，並將 AI 洞察擴充為可訂閱的週報
5. 自建客服與客戶聊天後台：把對話、標籤、交接與真人回覆全部收進自有系統，取得官方帳號後台拿不到的資料——真人首次回覆時間、指派與轉派紀錄、標籤自由度（不受聊天標籤無 API 與受眾命名規則限制）；「最快回撥」「已聯絡率」等業務端指標即可自動量測，不再依賴人工標記
6. CRM 整合：lead 以 webhook 同步至客戶既有 CRM（Salesforce／HubSpot 或自建），對齊經銷據點指派邏輯
7. 多平台複用：對話引擎與知識庫皆與通訊平台解耦，可低成本擴充至 Messenger／IG DM
8. 標籤維度擴充：屋況（可拆磁磚與否）、身分（屋主／師傅／經銷）納入詞彙表

名詞對照