Case studies - 從抽象構想至結構化需求：AI 助理的技術架構與實踐

在聯絡表單之前，先有一段對話

對多數人來說，委託一個網站或系統專案，最困難的一步發生在最前面：把腦中還很模糊的想法，整理成一段能寄出去的文字。該寫多詳細、用詞是否得體、預算要不要先提，在這些猶豫面前，許多本來有機會展開的合作，停在了一張空白的表單上。

這不是表單做錯了什麼，而是表單這個形式，要求訪客先獨力完成整件事裡最難的工作：需求釐清。但這件事，本來就應該由懂技術的一方陪著做。

這一次的客戶是我們自己。更準確地說，是每一位來到 helloio 官網、心裡有想法卻還說不清楚的訪客。我們決定把官網的需求入口，從一張表單，換成一段對話。

一次只問一題的需求釐清

我們在官網的 /start 打造了一款需求釐清助理：訪客用幾句話描述想做的東西，助理會先用自己的話把需求接住、確認理解沒有偏差，然後一次只問一個會影響專案範圍的關鍵問題，例如預約要不要審核、有沒有既有系統要整合、預期的規模到哪裡。它不會一次拋出整串問題，也不急著把對話收尾。

每一輪回覆之後，系統會即時生成幾個貼合語境的快速回覆選項，即使不擅長打字的訪客，也能順暢地完成整段對話。約莫四到七輪，助理會把整段對話收斂成一份結構化的需求摘要：核心目標、想做的功能、要整合的工具、初步的技術方向與規模感。訪客確認內容無誤，留下姓名與信箱一鍵送出，摘要與完整對話即時送進我們的內部信箱、Notion 客戶資料庫與 Discord 群組，同時一封確認信寄給訪客，四個管道並行。

訪客若想看實際案例，助理也會從我們的公開案例中挑選最相關的一個，附上可以直接點開的連結。整套體驗有完整的中英雙語版本，語言跟著站台版本走，行為一致、可以預期。

讓回答紮根在真實知識上

對話式介面最大的風險，是模型在知識的空白處編造答案。我們以檢索增強生成（RAG）來化解這個風險。

RAG 的概念其實很直觀：與其期待模型記得所有事，不如在它回答之前，先從自家的知識庫裡取出最相關的資料給它參考。模型負責理解與表達，事實由知識庫供應。對想把 AI 導入自家服務的團隊來說，這正是讓 AI 講你的事、而不是編故事的關鍵一塊。

我們把 helloio 的服務範圍、常用技術、開發流程與公開案例，逐條整理成精煉的雙語知識，人工編寫、人工校對，再交由 Voyage 模型轉換成可供語意檢索的向量，存入 PostgreSQL 的 pgvector 擴充。每一輪對話，系統會以訪客最近的訊息檢索出最相關的幾條知識，注入模型的背景脈絡。助理因此能引用真實案例、講出正確的能力邊界，而不是泛泛而談。

對話本體由 Claude Sonnet 負責，快速回覆選項交給更輕快的 Claude Haiku 並行生成；不變的人格與規則透過快取重複使用（prompt caching），讓每一輪的延遲與成本都維持在低點。

知識庫的底層，我們選擇 pgvector 向量資料庫，而非檔案式的簡易檢索。一方面，它正是我們對外提供 AI 整合服務時使用的架構；另一方面，它預留了成長空間：知識量從今天官網的規模，到未來成長數十倍、橫跨多條產品線，都能在同一套架構上勝任。若專案追求極致輕量，檔案式檢索同樣是可行的路線，這類取捨我們會依專案的規模與目標給出建議。

體驗的細節，使用者未必說得出來，卻能直接感覺到。助理的回覆以串流逐字呈現，我們用瀏覽器的 MutationObserver 實測每一幀的吐字數，把模型一陣一陣的輸出攤平成穩定的打字節奏。這類藏在底層的打磨，正是一段對話讀起來流暢與否的關鍵。

把成本與安全，築進系統的地基

一個免登入、對所有人開放、每次呼叫都會產生 API 費用的聊天端點，在攻擊者眼中，就是一個能不斷消耗你荷包的目標。這類風險有個專有名詞，叫 Denial of Wallet，收錄在 OWASP 大型語言模型十大風險的「無上限消耗」條目。從設計的第一天起，我們就把防禦它列為基本功。

防禦分三層。第一層在程式內：鎖死單一請求的最大成本，輪數、單則長度與總輸入量都有上限。這裡有個容易被忽略的關鍵：聊天端點本身不保存對話，完整歷史由瀏覽器端送上來，而模型參數只能限制「輸出」的長度；如果不在伺服器端封頂「輸入」，攻擊者偽造一段五百則的假對話，就能讓每一輪的成本急遽膨脹。

第二層是人機驗證閘門：訪客通過一次 Cloudflare Turnstile 驗證後，伺服器簽發一張短效通行證，之後的每一次對話請求都得出示，機器人在抵達付費端點之前就會被擋下。第三層是帳務端的支出上限，作為極端情況下的總保險。三層各司其職，任何一層被繞過，下一層依然守得住。

誠實，是設計出來的

比起讓 AI 什麼都答得出來，我們花了更多力氣讓它知道什麼不該說。助理不報精確金額，報價需要真人評估，它只給規模感；範圍之外的需求（例如原生 App）直接說明我們的主力不在這裡，並給出替代方向；被問「你是真人嗎」，它會坦然說明自己是 Claude 模型驅動的 AI 助理，最後接手的會是 helloio 的人。

這些行為不是模型的天性，是一條一條寫進系統指令的設計。同一份指令支撐中英兩種語言：英文站只疊加一層輕薄的語言覆寫，人格、規則與摘要格式完全一致，兩種語言共用同一個核心。

上線之後：讓數據說話，把隱私做對

助理上線的同時，我們在全站設置了七個入口：首頁的對話輸入框、頁尾的雙路徑行動區、流程頁與案例頁的情境連結，每一個都帶著來源標記。哪個入口帶來最多對話、哪個入口的訪客最終送出了需求，答案由數據給出，而不是憑感覺猜測。

對話內容會用於改善服務品質與補強知識庫；這一點在介面與隱私權政策中都有明確說明：未送出需求的對話九十天後自動刪除，紀錄不連結任何瀏覽器識別資訊。對待資料的方式，跟對待程式碼的方式，理當是同一種標準。

對外提供什麼，自己就先用什麼

這款助理上線後，helloio 官網的需求入口從「請訪客填表」變成「陪訪客釐清」。對外，它是每天實際接收需求的入口；對內，它讓我們對外提供的每一項技術，從 Claude 整合、向量檢索、串流介面到安全防護，都有一個隨時可以打開試用的實例。

對 helloio 而言，這個專案最大的收穫，是把一款 AI 助理該有的樣子，落成可以操作的工程細節：紮根真實知識、講明能力邊界、審慎對待使用者的資料。如果你正在評估把 AI 導入自己的產品或流程，這款助理就是我們交出的第一份答案，歡迎直接與它聊聊。

執行項目