你可能已經試過「丟一段提示詞，讓 AI 回答問題」。真正上線時才發現：
- 客戶問到邊界題就開始亂掰
- 客服同仁不信任，最後還是回到人工
- 老闆問「可以控管風險嗎？」你答不出驗收標準
這篇文章的目標很明確：7 天做出一個「可以上線」的 Dify FAQ 客服助理。不是 Demo，而是具備 對話邊界、失敗回覆策略、人工交接（handoff） 的可交付版本。下一篇（系列第 4 篇）再把資料接進來做知識庫/RAG。
核心結論（先給你可交付的判斷）
- 先上線的版本，不需要很聰明，但一定要可控。可控的關鍵不是模型，而是你設計的「流程」：能答什麼、不能答什麼、答不出來怎麼辦、何時交給人工。
- 提示詞不是文案，是規格書。把角色、範圍、輸出格式、拒答規則、handoff 條件寫清楚，才能把客服風險變成可驗收。
- Dify 的價值在 Workflow。用流程把「問答」包起來：分類→檢查資訊→給答覆或追問→失敗回覆→人工交接→留紀錄。
摘要
- 你會得到一條 7 天實作路線（每天 60–90 分鐘也能推進）
- 你會拿到一份可直接貼進 Dify 的 提示詞骨架
- 你會拿到可落地的 handoff 腳本（交接給真人時說什麼、要帶哪些資訊）
- 文章內附 驗收清單 與一張表，讓你跟主管/老闆對齊「可上線」標準
Dify 系列閱讀順序
這篇是 Dify 系列第 3 篇，負責把第一個用例做成可上線原型。建議先確認用例已經被主管認可，再進入本文的 7 天實作。
| 順序 | 文章 | 你會解決的問題 |
|---|---|---|
| 1 | 為什麼台灣中小企業先從 Dify 做可控內部 AI 應用 | 先判斷 Dify 是否適合你的公司 |
| 2 | 用 Dify 選第一個較容易驗證用例 | 在客服、業務、內勤中挑第一案 |
| 3 | 本文 | 把提示詞變成可交付流程 |
| 4 | 知識庫 / RAG 實戰整理法 | 讓 Dify 依據 SOP、型錄與報價規則回答 |
| 5 | Dify 上線前治理清單 | 把權限、日誌、個資與供應商條款講清楚 |
| 6 | Dify 上線後怎麼證明有用 | 用 KPI 證明成效並規劃擴張 |
完整路線整理在：Dify AI 工作流導入路線圖。
目錄
- 為什麼「能聊」不等於「能上線」
- 上線版 FAQ 助理的最低規格（你要先定義的 5 件事）
- 7 天實作計畫（Day 1–Day 7）
- 提示詞骨架（可直接套用）
- 失敗回覆策略：三段式降風險
- 人工交接（handoff）怎麼設計才不會變成客服黑洞
- 驗收清單與常見踩坑
- FAQ
- 延伸閱讀
- CTA：預約 FAQ 助理流程健檢並銜接第 4 篇（知識庫/RAG）
1) 為什麼「能聊」不等於「能上線」
在台灣中小企業的真實現場，上線的壓力往往不是技術，而是：
- 風險誰扛？（亂答、承諾錯誤、退換貨/保固說錯）
- 客服怎麼用？（要不要接手？怎麼接？接到哪一步？）
- 主管怎麼驗收？（不能只說「看起來很像真人」）
所以你要交付的不是「聊天機器人」，而是一個有流程的助理：
- 能回答的範圍清楚
- 不確定就追問或拒答
- 該交給人工就交，且交接資訊完整
這就是你用 Dify 做 Workflow 的最佳切入點。
2) 上線版 FAQ 助理的最低規格（先定義 5 件事）
在你打開 Dify 之前，先把這 5 件事寫在同一張文件（Google Doc/Notion 都可）。沒有它，你後面只是在「試手氣」。
- 服務範圍（Scope）：只回答哪三類問題？例如：
- 付款方式/發票
- 配送/運費/到貨時間
- 退換貨流程
- 禁答清單（Hard No）：哪些絕對不能回答或不能承諾？例如：
- 個資查詢（訂單地址、電話）
- 法律/醫療建議
- 「一定」「不保證」「100%」等承諾
- 需要追問的欄位（Missing Info）：例如要先問：
- 訂單編號（若無則走人工）
- 購買通路（官網/蝦皮/門市）
- 失敗回覆規則（Fail Policy）：答不出來時要怎麼說、怎麼引導。
- 人工交接點（Handoff）：什麼條件下一定轉人工？
3) 7 天實作計畫（Day 1–Day 7）
下面是一條「最短交付路徑」。你不需要一次做完所有功能；你只要在第 7 天能交付「可上線的 MVP」。
| 天數 | 你要完成的成果 | Dify 內要做的事（非工程師版本） | 驗收標準 |
|---|---|---|---|
| Day 1 | 服務範圍 + 禁答清單 + 追問欄位 | 建一個 App（建議從 Chat / Workflow 擇一；本文以 Workflow 思路） | 文件可給主管確認、可簽核 |
| Day 2 | 提示詞骨架 v1 | 客服規則草稿完成 + 回覆格式固定 | 10 題測試不亂跑格式 |
| Day 3 | 對話邊界（能答/不能答） | 加上「分類」或「意圖判斷」節點（可先用 LLM 判斷） | 超出範圍能拒答/轉人工 |
| Day 4 | 失敗回覆策略 | 加入 fail-safe：不確定→追問→仍不確定→handoff | 不會硬掰、不會鬼打牆 |
| Day 5 | Handoff 腳本 + 交接資料包 | 設計輸出「交接摘要」模板（含客戶問題、已蒐集資訊） | 人工接手能 30 秒看懂 |
| Day 6 | 測試腳本 + 風險題庫 | 建 30 題測試集（含刁鑽題）跑完整流程 | 命中率與失敗行為可被描述 |
| Day 7 | 上線前驗收 + 觀測指標 | 設定版本、導出設定、建立營運 SOP | 有 KPI 與回訓流程 |
所以你現在可以怎麼做（第 1 次）
- 今天先不要碰任何「接資料」「知識庫」功能。
- 先開一份文件，照第 2 節把 5 件事寫出來，約 30–45 分鐘。
- 寫完直接丟給主管/老闆確認：你要做的是哪個範圍的客服助理。
4) 提示詞骨架（可直接套用）
下面這份不是宣傳文案，而是一份「讓模型可控」的客服規則模板。你可以拿去做 Dify 的初始設定，再依你的業務資訊補上內容。
```text # 角色 你是【公司/品牌】的「FAQ 客服助理」，主要目標是快速解答客戶常見問題，並在不確定或超出範圍時安全地交給人工客服。
# 服務範圍（只回答以下類別） 1) 付款與發票：例如【可提供的付款方式】、【發票開立規則】 2) 配送與運費：例如【出貨天數】、【物流方式】、【運費規則】 3) 退換貨流程：例如【退換貨期限】、【退貨條件】、【處理時間】
# 禁止事項（務必遵守）
- 不要捏造政策、費用、期限、庫存、保固承諾。
- 不要要求或處理敏感個資（例如：身分證字號、完整地址、信用卡號）。
- 不回答法律/醫療/投資建議。
- 不使用「不保證、一定、100%」等承諾字眼。
# 回覆原則
- 優先用精簡條列，讓客戶手機好閱讀。
- 若資訊不足，先提出 1–2 個最必要的追問。
- 若仍不確定或超出範圍，使用【失敗回覆策略】並提供人工交接。
# 失敗回覆策略（三段式） 1) 先說明目前資訊不足或不在可回答範圍 2) 提供可行替代方案：追問/提供官方連結/建議轉人工 3) 產出「交接摘要」供人工客服接手
# 固定輸出格式 請以以下格式輸出： 【回覆給客戶】
- ...
【需要客戶補充的資訊（若無則寫：無）】
- ...
【是否需要轉人工】
- 是/否
【交接摘要（僅在需要轉人工時輸出）】
- 客戶問題：...
- 已提供資訊：...
- 已追問：...
- 風險點/注意：...
```
你會發現：當你把「輸出格式」固定住，後面做 workflow 編排會容易非常多。
5) 失敗回覆策略：三段式降風險（避免「亂掰」與「鬼打牆」）
上線最常見的翻車點是：模型不知道就硬答，或一直追問同一件事。
建議你把失敗回覆做成三段式，並明確定義「最多追問幾次」。
建議規則
- 最多追問 2 輪（避免無限迴圈）
- 第 3 次仍不足：直接轉人工
範例（客戶問：我昨天買的怎麼還沒到？）
【回覆給客戶】
- 我可以先協助你確認「出貨與配送的常見狀況」。
- 為了避免查錯訂單，請你補充以下其中一項：訂單編號 或 購買通路（官網/平台/門市）。
【需要客戶補充的資訊】
- 訂單編號（或購買通路）
【是否需要轉人工】
- 否
若客戶回覆仍無法提供、或涉及查詢個資/訂單細節：
【回覆給客戶】
- 這題需要人工客服協助查詢訂單狀態（會涉及訂單資料），我先幫你轉接。
- 你可以先提供：訂單編號 / 購買通路 / 方便聯絡方式（不建議提供信用卡等敏感資訊）。
【是否需要轉人工】
- 是
【交接摘要】
- 客戶問題：未到貨查詢
- 已提供資訊：...
- 已追問：訂單編號/購買通路
- 風險點/注意：涉及訂單資料，需人工查詢
6) 人工交接（handoff）怎麼設計才不會變成客服黑洞
很多團隊做了「轉人工」按鈕，但現場還是炸裂，原因是：交接不完整。
你要把 handoff 當成「工單的最小資料包」。
Handoff 必帶 6 欄（建議固定）
- 客戶原句問題（不要改寫過度）
- 問題分類（付款/配送/退換貨/其他）
- 客戶已提供資訊（訂單編號、通路、日期…）
- 助理已做過的動作（已追問什麼、已給什麼規則）
- 為何轉人工（超出範圍/需要查個資/風險題）
- 建議人工下一步（請客服查哪個系統、要跟客戶說什麼）
可直接用的 Handoff 腳本（給客戶看）
```text 我可以理解你現在想盡快解決。 這題需要人工客服協助確認（會涉及訂單/帳務資料），我先幫你轉接。
為了讓你不用重複說明，請你回覆其中一項即可： 1) 訂單編號 2) 購買通路（官網/平台/門市）與大約購買日期
提醒：為了保護你的資料，請不要在這裡提供信用卡號、身分證號等敏感資訊。 ```
所以你現在可以怎麼做（第 2 次）
- 先挑 3 種「高風險必轉人工」情境寫進你的規格：
1) 要查訂單狀態、地址、電話 2) 要改收件資訊/取消訂單 3) 客訴升級（情緒性、退款爭議）
- 把上面的 handoff 六欄做成固定模板，讓客服同仁參與 10 分鐘共編：他們最知道缺什麼資訊會卡住。
7) 驗收清單與常見踩坑
你需要一張能「跟主管對齊」的驗收表，避免最後變成主觀印象。
上線 MVP 驗收清單（建議至少做到）
- [ ] 只回答三大類 FAQ（超出範圍能拒答）
- [ ] 不捏造政策、不做承諾（測試題能擋住）
- [ ] 最多追問 2 次，之後必 handoff
- [ ] handoff 會產出交接摘要（人工 30 秒看懂）
- [ ] 有 30 題測試集（含 10 題刁鑽/越界題）
- [ ] 有營運指標：轉人工率、首次解決率、客戶滿意度（先用人工標記也可）
常見踩坑（你可以提前避掉）
- 先做知識庫，結果流程沒控住：資料再多也會亂答。
- 禁答寫成「不要亂講」：要改成可執行規則（不能答什麼、遇到就 handoff）。
- 沒有固定輸出格式：workflow 後面難串、客服也難接。
補充：若你的情境會碰到個資（訂單查詢、會員資料），建議把「個資與權限」列為必轉人工；本文不提供法律意見，但務必跟內部資安/法務確認流程。
FAQ
Q1：我不會寫程式，真的能做出「可上線」的 Dify 應用嗎？
可以，但你要把目標從「功能很多」改成「風險可控」。非技術窗口最有效的貢獻是：規格清楚、邊界清楚、handoff 清楚。這三件事決定能不能上線。
Q2：我應該用 Chat App 還是 Workflow App？
若你只是想快速試聊，Chat 很快；但你要「上線可控」，建議優先用 Workflow 思路（即使介面上仍是對話）。因為你需要：分類、追問、失敗回覆、轉人工、輸出模板。
Q3：怎麼避免模型胡亂編政策？
三層一起做： 1) 提示詞寫明「不可捏造」與「不確定就 handoff」 2) 流程上設計「最多追問兩次」 3) 測試集放入「誘導題」（例如：你們保固是不是一定兩年？）驗證是否守規則
Q4：轉人工會不會讓客服更忙？
一開始可能會，但如果你把 handoff 的「交接資料包」做好，客服會感覺是被幫忙而不是被丟包。你也能用轉人工率來找出：哪些問題其實可以在第 4 篇用知識庫/RAG 解掉。
參考來源與審核說明
資料時間：2026-05-28。本文涉及工具、商業、學習、法規、財務或健康相關內容時，僅供一般資訊與流程設計參考，不構成法律、投資、醫療、心理治療或財務建議；正式採購、投資、導入或決策前，請以官方文件、合格專業人士與你自己的實際數據為準。
導購揭露：本文可能包含推薦、合作或聯盟連結；若你透過連結洽詢、註冊或購買，我們可能取得分潤，但不會增加你的成本。本文不因分潤保證任何工具、課程、投資或商業成效。
延伸閱讀（站內）
- 別急著買一堆 AI 工具：台灣中小企業為什麼先從 Dify 做「可控的內部 AI 應用」
- 用 Dify 選第一個「較容易驗證」用例：客服、業務、內勤三條線，怎麼挑才不會一上來就失敗？
- 未來領航者專區總覽（依主題找文章）
CTA：預約 FAQ 助理流程健檢（並銜接第 4 篇：接資料做知識庫/RAG）
如果你希望更快落地，我們把本文可直接複製的內容整理成一份可下載版本：
- 提示詞骨架（含禁答清單欄位、固定輸出格式）
- Handoff 腳本（客戶版 + 內部交接摘要版）
下一篇（系列第 4 篇）會帶你做最關鍵的一步：把資料接進來（知識庫/RAG），讓這個 FAQ 助理從「有流程」進化成「有依據」。
你可以先把第 1–7 天做完，再用第 4 篇把命中率拉上來，這樣最穩。
SEO Meta
- Title: 7 天做出第一個可上線的 Dify 應用：FAQ 客服助理從提示詞到流程編排｜FlyPig AI
- Description: 給非技術窗口的 7 天落地路線：用 Dify 做出可上線的 FAQ 客服助理。重點包含提示詞結構、對話邊界、失敗回覆策略與人工交接（handoff）設計，先交付可用版本，再銜接知識庫/RAG。
- Keywords: Dify, AI客服, Workflow, 提示詞, 客服流程, handoff人工交接