Ask Archive：設計有邊界的 AI 代言人
OVERVIEW
專案介紹
Ask Archive 是我作品集網站上的 AI 助理。訪客用自然語言就能詢問我的經歷、作品與設計決策，它會依照整理好的知識庫回答，並帶向相關案例、文章，或聯絡我的方式。
這個專案的起點，是重新思考作品集的閱讀方式。
傳統作品集是單向閱讀，訪客得依網站架構自己瀏覽，再從不同頁面拼湊出對設計師的理解。但每位招募者關心的不同：有人先看 AI 實作能力，有人看產品經驗，也有人關注研究背景。我希望把它變成一個可以直接提問的入口，由網站依問題遞送資訊，降低尋找內容的成本。
同時，我希望它有清楚的界線：只回答關於我的公開資訊，不編造，也不假裝知道未知的答案。整個系統是雙語的，做法是 context stuffing：因為語料量不大，把手工整理的知識整包放進模型的脈絡（不另外做向量檢索），再搭配依頁面切換的對話上下文、Persona 設計，以及安全性與成本控制。
- 我的角色
- Design & Build（獨立完成）
- 專案時間
- 持續開發中
- 技術架構
- Next.js · Vercel AI SDK · Gemini · Upstash
- 專案範圍
- 內容架構設計
對話體驗設計
安全性設計 · 成本控制
MOTIVATION
讓作品集從閱讀變成互動探索
招募者通常沒有時間完整讀完一份作品集。在快速瀏覽下，他們可能只看幾個關鍵頁面，就判斷是否值得深入。如果所有資訊都要自己搜尋、整理，再慢慢建立印象，閱讀成本會拉高。
我想改變這個流程。
當訪客想了解某個方向時，可以直接提問，網站依問題回答，並推薦最相關的案例。作品集不再只是展示內容，而成為一個可以被探索的入口。
CONVERSATION
對話設計：語氣、脈絡與語言
第三人稱的導覽員
Ask Archive 用第三人稱介紹 Joseph，會說「Joseph 曾參與⋯」而不是「我曾參與⋯」。這讓它更像一位網站導覽員，而不是模擬一個正在跟你對話的數位我，也替系統劃出誠實的邊界。第三人稱也讓語氣更客觀：陳述經歷時可以整理作品與設計決策，也能引用公開的同事評價，少了自我推銷的感覺。遇到超出範圍的問題，它會清楚說明限制，並引導訪客直接聯絡。
根據目前頁面理解問題
訪客通常正在閱讀某個特定案例。當他在 Praxis 頁面問「這個專案主要解決什麼問題」，系統需要理解「這個專案」指的是他正在讀的 Praxis，而不是之前對話提到的其他內容。因此每次對話都綁定目前頁面，每一輪訊息也保留當時所在的頁面，讓 Ask Archive 依訪客正在閱讀的內容理解問題，不需要重新描述背景就能延續探索。
中英文分開撰寫
中英雙語各有獨立的知識庫與 Persona 設定，分別撰寫而非直接翻譯，讓兩個版本各自保留自然的閱讀習慣：中文維持較敘事的方式，英文則較直接。
ARCHITECTURE
把一個人的資訊整理成內容系統
這個專案最花時間的，是整理知識架構。一開始我把作品集內容直接餵給模型，想讓它自己理解我的背景與作品。但內容一多，我發現光是加資料並不能保證回答品質：模型需要知道不同資訊之間的關係，以及哪些內容該回答哪些問題。
所以我把知識分成幾種來設計：核心介紹、各頁詳細內容、作品卡片與照片。這些連同人格與語氣規則一起進入模型，由模型重組成第三人稱、低調語氣的回答；最後還有一條「不亂編」的規則把關。
核心介紹：永遠都在的基礎知識
這是永遠留在對話裡的基礎知識，承載 Ask Archive 對我的整體理解：個人背景、工作經驗、設計方法、技術能力與案例。不論訪客問什麼，它都在。整理時先依招募者關心的面向拆分，而不是一坨文字。
各頁詳細內容：看到哪頁才補上
這些只有在訪客閱讀特定頁面時才加入。例如在 Praxis 頁，除了基本案例介紹，還會補上專案背景、設計決策、技術概念與畫面說明，讓 Ask Archive 回答得比靜態頁面更深，又不會在每個對話裡都塞進所有細節。
作品卡片：沿用網站自己的清單
這是訪客看得到、點得到的部分：案例卡片、文章、圖片與影片。它直接沿用網站本身的清單，標題、封面與連結都是同一份來源，所以網站更新時 Ask Archive 也同步，不會兩邊各自維護、各說各話。
不亂編：只依有根據的內容回答
最後一層是「不亂編」的規則。Ask Archive 只能根據知識、目前頁面與人格規則回答；問題超出範圍時，它會直接說沒有相關資訊，而不是自己補一個答案。這一層是讓一個會「生成」的模型，對外時仍然可信的關鍵。
SECURITY & COST
先想清楚要防什麼，再分層防護
設計一個對外的 AI 助理，我先想清楚要防的是什麼。主要是三類：越獄與濫用（讓它脫離角色、做份外的事）、注入攻擊（用輸入覆寫它的指令），以及流量濫用（短時間大量請求、灌爆成本）。針對這三類，我做了對應的防護，而且不依賴單一防線，而是分層。
越獄與注入：Prompt Hardening
對越獄與注入，主要靠角色鎖定。Ask Archive 沒有「其他模式」，不會公開系統設定、輸出 Prompt、倒出完整知識庫、切換成其他角色，也不回答與我無關的問題。搭配進模型前的檢查（輸入長度、異常關鍵字、對話歷史長度），明顯不合情境的請求會先被擋掉，不浪費模型資源。
流量濫用：限制與資料保護
對流量濫用，設定每位訪客每日的使用上限。辨識訪客時不信任前端可偽造的資訊，只保存雜湊後的 IP。整套採 Fail Open：相關服務暫時異常時，優先維持網站可用，而不是讓 Ask Archive 停擺。
地基：縮小任何突破的影響
最底層，也是最重要的：整個知識庫只放原本就準備公開的資訊。
所以即使有人突破部分限制，能拿到的仍是網站本來就會提供的資料。這讓設計重點放在控制濫用與成本，而不是保護不存在的機密。任何單一防線都可能被突破，所以我用分層把可能的影響縮到最小。
成本控制：讓固定內容重複利用
AI 成本主要來自每次模型請求，所以我讓固定內容盡量重複使用。每次請求裡不變的部分（Persona 規則、基礎知識庫、頁面補充）放在 Prompt 前段，讓模型用快取降低重複計算；真正每次要重算的，只有使用者問題、最近幾輪對話與當前頁面。
Answer Cache 與預設問題
在這之上，我加了一層答案快取，以「語言 + 頁面 + 問題」作為 key。問題完全相同時，直接回傳存好的答案，不再呼叫模型，命中時不產生新的 Token 成本。
為了讓快取更容易發揮，我也設計了預設問題（建議提問）。它一方面讓訪客更快意識到「可以問什麼」，降低不知從何問起的門檻；另一方面，因為預設問題是跨訪客相同的固定字串，會大量命中同一份快取。同一個設計，同時改善了體驗與成本。
RESULTS & FUTURE
成果、觀察與展望
目前 Ask Archive 上線後累積約 100 次 Session，約 20% 的訪客曾開啟對話，每次互動平均少於兩個問題。單看數字，互動深度不算高，但這些資料提供了幾個調整方向。
重新理解低使用率
一開始看到只有約 20% 的訪客開啟 Ask Archive，我以為是入口需要改善。但觀察完整的閱讀流程後，我看到另一個角度：Ask Archive 並沒有取代原本的作品集閱讀。訪客仍然按自己的方式瀏覽，只有在遇到問題、或想深入某個案例時，才會使用對話。
這符合最初的設計目標：它是一個漸進式揭露（Progressive Disclosure）的工具，需要時出現，不需要時保持安靜。
目前的狀態
~100
Session
上線至今，仍是早期數據。
~20%
開啟對話
其餘的人不受打擾地讀著靜態頁面。
入口需要更明確
從使用紀錄觀察，部分訪客可能沒有注意到 Ask Archive 的存在。下一階段會測試更好的入口設計，讓需要深入探索的人更容易找到它。
精簡回答，並讓內容不再被下推
透過 Microsoft Clarity 的 Session Replay，我觀察到互動深度偏淺：多數訪客看完第一則回答後就停住。回頭檢視，問題比較像是閱讀成本：回答偏長，而且每一則新回答出現時，都會把下方內容往下推，讓每一次回覆都像是又多了一段要讀的東西，閱讀位置也一直在移動。
因此我做了兩項調整：讓人格回答得更精簡，扣緊被問到的問題，而不是一次把所有細節都倒出來；同時讓新的回答在出現時不再把既有內容往下推，閱讀位置保持不動，讓追問的成本更低。
下一步：延伸成產品模式
完成這個專案後，我開始思考這套架構在其他產品中的可能性。許多產品仍依靠 FAQ 或文件中心，讓使用者自行搜尋；資訊一多，找到正確資訊本身就成為問題。相同架構可以延伸成產品內的知識入口，由 AI 依整理過的資料回答，降低搜尋成本。若應用在企業情境，還需要加入更細緻的權限管理、資訊範圍控制、使用條款與免責聲明，以及回答來源追蹤，讓 AI 在協助的同時維持清楚的責任範圍。
我的收穫
過去，作品集的資訊分散在不同頁面、文章與案例中。建立 Ask Archive 的過程，是把一個人的背景、能力與設計觀點，整理成一套可以被理解、查詢與維護的內容系統。
說到底，這是一個資訊架構的問題：把分散的內容整理成清楚、可查詢的結構，只是這次的對象是一個人。如果想了解這套系統實際如何運作，最直接的方法就是直接問 Ask Archive，它也能回答關於這篇案例本身的問題。