一個下午，把你的知識搬進來
代理需要知道的東西，大部分早就寫下來了——在你的網站上，也在你的團隊每週寄給客戶的那幾份 PDF 裡。用網址匯入處理公開的那一半，用上傳處理其餘的。
試辦專案卡住最常見的原因不是模型，而是得有人坐下來「把知識庫準備好」——而這件工作從來沒有負責人，所以它從來沒開始。
而且它其實沒必要。那些素材幾乎一定早就存在了。它在你的網站上，也在你的團隊每週用電子郵件寄給客戶的那幾份 PDF 裡。要做的不是寫，是搬進來。
兩種入口，對應兩種素材
**你的網站——用網址匯入。**把平台指向你的網站，它會讀取公開頁面，把每一頁變成一份文件。這涵蓋的是你早就為客戶寫好的東西：服務說明、價格頁、常見問答、政策解釋，以及那些真的回答了大家會問的問題的文章。
**其餘的——把檔案上傳。**費率表、產品手冊、那份寫著你的團隊可以承諾什麼、不能承諾什麼的內部單頁說明。任何需要登入才看得到的、任何只以 PDF 形式存在的、任何頁面上從來不會明講的東西。
這個切分不是隨便分的。網站匯入快而廣，但淺——它只看得到訪客看得到的東西。上傳才是那些讓你的代理不同於「一個對著你網站的搜尋引擎」的素材所在。
匯入做不到的事
規劃之前先知道比較好。
用 JavaScript 產生內容的頁面會抓回空的——匯入器抓的是 HTML，它不跑瀏覽器。任何需要登入的都碰不到。網站上連出去的 PDF 會被略過，那些走上傳這條路。它會遵守 robots.txt。而且它是一次性匯入，不是訂閱：網站改了，知識庫不會跟著改。要更新就再匯入一次。
讀取頁面本身不花錢。在任何東西被加進去之前，你會先看到確切的頁數與字元數，以及預估的 token 成本——而且不點頭，就什麼都不會加進去。
如果你的網站是一般的伺服器端渲染網站——WordPress、Webflow、Squarespace，以及多數用 CMS 架的行銷網站——匯入讀得到。會失敗的情況是全部在瀏覽器端渲染的單頁應用，而且它會直接報錯，不會默默匯入一堆空白頁面。
一個實際跑過的例子
一家房貸經紀商，網站是雙語的，共用硬碟裡塞滿了費率表。
**只匯入英文版網站。**他們把匯入器指向首頁，並把路徑前綴設成 /en/。不這麼做的話，頁數額度會被同樣八篇文章的三個語言版本吃光——同樣的內容、三倍的成本，檢索時還會撞出一堆近乎重複的結果。這次匯入透過 sitemap 找到八個頁面：四篇長文、資源索引頁、團隊與關於我們，還有聯絡頁。大約 45,000 個字元。他們按下確認，一分鐘後知識庫裡就有八份文件了。
到這裡，代理已經答得出「你們有做醫師專案貸款嗎？」和「線上對保是怎麼進行的？」——因為那些文章幾年前就寫好，一直躺在部落格上。
**上傳網站上永遠不會講的那四樣東西。**最新的費率表。自營作業者申請人的文件檢核清單。那份寫著貸款專員在對話中不得承諾什麼的單頁說明。還有一份州政府揭露文件的掃描檔。這些網站上都沒有，其中兩份也不該有。
**寫界線，不是寫事實。**在知識庫指示裡：*這是我們目前的政策，其效力高於一般業界慣例；報利率一律要附生效日期；任何涉及特定申請案的問題都必須轉交真人。*事實住在文件裡，指示講的是該怎麼對待這些事實。
總共花掉的時間：一個下午，而且大部分花在判斷哪些內部文件放進去是安全的——那正是真正值得人來判斷的部分。
工作真正落在哪裡
注意這個例子沒有做的事：沒有寫新內容、沒有排版、沒有下標籤，也沒有建分類架構。檢索這一層不需要那些。
它做的是兩個沒有任何工具能替你做的決定。哪些內部素材可以安全地透過代理讓客戶取得。以及代理不被允許承諾什麼。你的時間應該編給這兩件事，而不是編給匯入。