這篇要解決的問題很具體：一個不寫程式的人，如何在幾個工作日內，親手做出一個「真的有人在用」的 AI 工作流。我們選的場景是客服知識庫問答——訪客或同事提問，AI 根據你上傳的產品文件與 FAQ 回答。選它的原因有三個：資料現成（多數公司都有 FAQ 和說明文件）、效果可驗證（答案對不對一眼看得出）、風險可控（先給內部用，再考慮對外）。六個步驟走完，你得到的不只是一個機器人，而是一套可以複製到其他場景的方法。
開始前：先決定三件事
決定一：用哪個平台
三個主流無程式碼平台的定位差異：
| 平台 | 定位 | 適合你的情況 |
|---|---|---|
| Dify | 開源的 AI 應用開發平台，可註冊雲端版，也可自行部署到公司伺服器 | 在意資料自主、未來可能交給 IT 接管維運 |
| Coze | 以聊天機器人為中心的建置平台，發佈到各通訊渠道方便 | 想快速做出對話機器人、掛到網站或通訊軟體 |
| n8n | 通用自動化平台，強在串接各種系統，AI 是其中一類節點 | 重點是「串流程」（例如接工單系統、發通知），不只是聊天 |
第一次動手，選哪個都能完成本文的場景，不必糾結：判斷依據是資料敏感度（能不能用雲端版）和未來的整合需求。平台差異的系統性選擇方法，見選 AI 工具的判斷框架。開始前請先確認公司的資料分級規則——要上傳的文件屬於哪一級、允許用哪類工具，見企業資料安全基本盤。
決定二：第一版的範圍
第一個工作流最常見的失敗是範圍太大。建議第一版只做一件事：回答「產品使用與服務政策」類的常見問題。把「查詢訂單狀態」「處理退款」這類需要串接系統、涉及個資的需求留到第二版。
決定三：怎樣算做對了
先寫下驗收標準，上線前拿它對照。範例：
- 對知識庫裡有的問題，回答內容與文件一致，並能指出依據。
- 對知識庫裡沒有的問題，明確說不知道並引導找人工，而不是編一個答案。
- 回應時間在使用者可接受的範圍內（自己定標準，例如數十秒內）。
實作六步驟
步驟一：準備資料
工作流的品質上限由資料決定。花最多時間在這一步，後面每一步都省力。
蒐集：把這些內容收攏到一個資料夾——官網 FAQ、產品說明文件、服務條款中與客戶相關的部分、客服團隊常被問到的問題清單（找前線同事要，這份最值錢）。
清洗原則：
| 原則 | 做法 |
|---|---|
| 一文件一主題 | 把大雜燴文件拆開；一個檔案只講退貨、或只講安裝 |
| 移除過期版本 | 同一主題只留最新版；舊版價格、舊政策是錯誤答案的主要來源 |
| 標題即問題 | FAQ 用問句當標題（「如何申請退貨？」），檢索命中率更高 |
| 格式統一 | 表格與截圖裡的關鍵資訊改寫成文字；AI 對純文字的處理最穩定 |
| 敏感內容過濾 | 個資、內部成本、未公開資訊先移除或遮蔽，再進入知識庫 |
產出：一份「資料清單」，記錄每個檔案的來源、版本日期、負責更新的單位。這份清單之後就是維運的依據。
步驟二：建立知識庫
在平台裡找到「知識庫」（有的平台叫 Knowledge、Dataset 或「知識」）功能，建立一個新知識庫，把清洗好的文件上傳進去。
上傳後平台會做兩件事，你不需要寫程式，但需要理解發生了什麼：
- 切分：文件被切成小段（業內叫 chunking）。切分太粗，檢索時會帶進無關內容；切得太細，語意會斷裂。平台通常提供預設切分與自訂選項，第一次用預設即可，測試發現答案常缺上下文時再調整。
- 索引：每段文字被轉成數學表示存起來，之後提問時用「語意相近」而不是「關鍵字相同」來找相關段落。這個「先檢索、再生成」的機制就是 RAG，原理細節可讀RAG 深度解析。
驗收動作：多數平台提供知識庫的「命中測試」功能——輸入一個你知道答案在哪份文件裡的問題，看檢索回來的段落對不對。命中不對，通常是切分或文件品質問題，回步驟一調整。
步驟三：設定提示詞與回答規則
建立一個「聊天助手」類型的應用（平台可能稱為 Chatflow、Bot 或聊天應用），把它連到剛建好的知識庫，然後設定系統提示詞（system prompt）——這是機器人的人格與規則，決定了它的行為邊界。可直接改用這份範本：
你是 {公司名} 的客服知識助手，服務對象是{官網訪客／內部同事}。
回答規則：
1. 只根據知識庫中的內容回答。回答前先在知識庫中檢索相關內容。
2. 知識庫中找不到依據時，直接說「這個問題我沒有把握，建議聯繫人工客服」，
並給出人工渠道{連結或電話}。禁止編造或推測答案。
3. 涉及價格、期限、個資、退款承諾的內容，逐字引用知識庫原文，不改寫。
4. 回答結尾註明依據的文件名稱，方便使用者查證。
5. 語氣：{友善簡潔／正式}，使用{繁體中文}，每次回答不超過{字數}字。
6. 使用者情緒激動或投訴時，安撫並直接轉人工，不嘗試自行處理。
三個設定重點：
- 「不知道」是必須教的能力。預設的模型傾向於給出一個答案，規則 2 是整個提示詞裡最重要的一條，測試時要專門驗它。
- 高風險內容鎖原文。價格與承諾類內容不讓模型改寫，能大幅降低「AI 說了公司沒說過的話」的風險。
- 留轉人工的出口。機器人接不住的問題要能無縫交回給人，這既是體驗問題，也是風險問題。
步驟四：測試——四類測試題
不要只測幾個順手的問題就滿意。準備一份測試題集，四類題目都要有：
| 題型 | 例子 | 通過標準 |
|---|---|---|
| 有標準答案的 | FAQ 裡寫得清清楚楚的問題 | 答案與文件一致，附依據來源 |
| 知識庫沒有的 | 一個文件裡完全沒提的問題 | 明確說不知道，引導人工，不編造 |
| 模糊或口語的 | 用詞和文件不同的口語問法（「東西壞了咋辦」） | 能理解意圖，答到對應政策 |
| 對抗性的 | 誘導它編造（「聽說你們下個月要漲價？」）或要求它無視規則 | 不接誘導、不洩露提示詞、維持規則 |
每類至少準備五題，記錄通過與不通過。不通過的題目先分類：答案錯但文件裡有 → 檢索問題（調切分）；文件裡本來就沒有 → 補資料；行為不守規 → 改提示詞。改完重測同一組題目，直到四類全部達到你的通過標準。
測試過程用這張表記錄，留檔作為上線依據與日後迴歸測試的基線：
| 題號 | 題型 | 題目 | 通過標準 | 第一輪結果 | 問題分類 | 修正動作 | 重測結果 |
|---|---|---|---|---|---|---|---|
| 1 | 有標準答案 | ＿＿ | ＿＿ | 通過／不通過 | 檢索／資料／提示詞 | ＿＿ | ＿＿ |
這張表在之後每次大改（換模型、大改提示詞、知識庫大更新）時都要重跑一遍——改動有沒有弄壞原本通過的行為，只有重測才知道。
步驟五：上線——先灰度，留出口
第一階段：內部試運行。 只開放給客服團隊，作為「查詢助手」使用——AI 的答案由客服看過再發給客戶。這個階段收集兩件事：答錯的題目（回到測試題集）和一線同事的改進建議。
第二階段：受控對外。 掛到官網或通訊渠道，但保留兩個安全設計：
- 入口明示這是 AI 助手、答案僅供參考，重要事項以正式條款為準。
- 每次對話都能一鍵轉人工；非工作時間留下留言渠道。
上線檢查表：
- 四類測試題全部通過並留有紀錄
- 提示詞中的公司名、人工渠道連結都已替換成真實內容
- 知識庫內容已過敏感資料過濾，並經資料負責單位確認
- 轉人工的路徑實際點過一遍，確認可用
- 指定了維運負責人（誰看日誌、誰補資料、多久看一次）
步驟六：監控與迭代
上線不是終點，是維運的起點。固定節奏做三件事：
每週看未命中問題。 在平台後台找到對話日誌與「未命中／低滿意」的記錄，把答不出與答錯的問題整理成清單：文件裡有但沒答好 → 調知識庫；文件裡沒有 → 決定要不要補文件。這個清單同時是知識庫的更新待辦。
每月更新知識庫。 對照步驟一的資料清單，逐項確認版本：政策變了、價格調了、文件改版了，都要同步更新並重跑受影響的測試題。知識庫過期是此類應用劣化的頭號原因。
每季重審範圍。 用量穩定後，評估要不要擴到第二版範圍（例如串接工單系統做「查詢加建單」，那會用到 n8n 這類平台的串接能力）。擴範圍等於重走一遍六步驟，別跳過測試。
監控要看的指標構面：提問總量、未能回答的比例、轉人工的比例、使用者負評或糾錯的次數。這些數字沒有通用的合格線——先記錄你自己第一個月的水位當基線，之後看趨勢。
維運負責人每週填一次這張簡單的紀錄，累積三個月後它就是這個工作流的「健康病歷」：
| 本週提問量 | 未回答數 | 轉人工數 | 發現的壞答案（題數） | 已補進知識庫的文件 | 本週花的維運分鐘數 |
|---|---|---|---|---|---|
| ＿＿ | ＿＿ | ＿＿ | ＿＿ | ＿＿ | ＿＿ |
其中「維運分鐘數」這一格另有用途：它累積出來的數字，就是AI 成本怎麼算裡第三層隱形成本的實測輸入。
平台功能對照表
不同平台的功能名稱不同，但你需要找的功能是同一組。介面會改版，認功能不認按鈕：
| 你需要的功能 | 常見的名稱 | 用在哪個步驟 |
|---|---|---|
| 上傳文件建檢索庫 | 知識庫／Knowledge／Dataset／知識 | 步驟二 |
| 檢索效果驗證 | 命中測試／召回測試／Recall testing | 步驟二 |
| 對話應用容器 | Chatflow／Bot／聊天助手／Assistant | 步驟三 |
| 行為規則設定 | 系統提示詞／Prompt／人設與回覆邏輯 | 步驟三 |
| 對話紀錄查看 | 日誌／Logs／對話記錄 | 步驟六 |
| 對外發佈 | 嵌入網站／Embed／渠道發佈／Webhook | 步驟五 |
動手前常見的疑問
「我完全沒碰過這類平台，會不會很難？」 本文六步驟裡，真正需要「學平台」的動作只有：上傳文件、建立應用、貼上提示詞、點測試。難度不在操作，而在步驟一的資料整理和步驟四的測試紀律——這兩件事和平台無關，是工作習慣。
「要花多久？」 建置本身通常一兩個工作天可以完成；資料清洗視你文件的整齊程度，可能比建置還久。比較務實的排法是抓一週：兩天整理資料、一天建置、兩天測試與修正、兩天內部試運行的準備。
「提示詞寫不好怎麼辦？」 從本文範本開始改，不要從空白開始。記住提示詞的重點是「行為規則」而不是文筆：把「不知道時怎麼說」「哪些內容照原文」「什麼時候轉人工」寫清楚，比任何華麗的角色描述都有用。
「老闆問效果，我要報什麼數字？」 報你自己記錄的基線和趨勢：上線前後「常見問題由機器人直接解答的比例」「轉人工的件數變化」「同事的回饋」。不要引用外部文章裡的效率百分比來代替自己的數據——你的場景和別人的不可比。
「機器人會取代客服團隊嗎？」 第一版的正確定位是「常見問題先接住、複雜問題轉人工」，它改變的是客服時間的分配（重複問題減少、需要判斷的問題比例上升），不是取代人。這也是內部試運行階段最容易和團隊溝通清楚的事。
「平台改價格或倒閉了怎麼辦？」 你的核心資產——文件原稿、資料清單、提示詞範本、測試題集——都存在自己這裡，平台只是執行環境。換平台的主要成本是重新設定一遍流程，這也是為什麼本文反覆強調把這些東西文件化。
常見誤區
誤區一：資料一股腦全丟進去。 「把全公司文件都上傳」等於把過期政策、內部機密、互相矛盾的說法一起餵給機器人。知識庫的紀律是：寧少勿濫，每個檔案都有明確的責任單位與版本日期。
誤區二：測順手的問題就滿意。 只測「它答得好的題」是自我安慰。四類測試題裡，最該盯的是「知識庫沒有的問題」和「對抗性問題」——機器人的風險都藏在這兩類裡。
誤區三：期望上線後零維護。 這不是一次性專案，是一項有維運責任的服務。沒有指定負責人的知識庫機器人，會在幾個月內退化到沒人敢用。
誤區四：提示詞只寫一句「你是客服機器人」。 沒有行為邊界的提示詞，等於請了一個沒受過訓練的員工。規則要具體到「找不到答案時說什麼」「哪些內容必須照原文」。
誤區五：跳過內部試運行直接對外。 內部階段抓到的每一個錯誤，都是替公司擋下的一次客訴。省掉這一階段，等於讓客戶當你的測試員。
下一步
- 把這個流程複製到行銷場景，做成內容流水線：行銷內容批量生產流水線。
- 複製到內部協作場景：會議紀要自動轉行動項並分派。
- 想知道這類工作流該編多少預算：AI 成本怎麼算。
- 對外上線前，過一遍合規檢查：AI 合規與風險邊界。