不寫程式做出你的第一個 AI 工作流（Chinese original）

這篇要解決的問題很具體：一個不寫程式的人，如何在幾個工作日內，親手做出一個「真的有人在用」的 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 合規與風險邊界。