AI 應用系列 0｜起源：從一場面試的需求討論到自建AI工作流實建

一切從一個需求開始

一次與外貿公司面試的需求討論中，面試官提到想為外銷產品建立技術服務網站，內容包含知識庫，並希望做到自動應答。

這個需求描述很簡短，但是可以被展開成一連串問題：

• 客戶最常問的是選型、加工參數，還是交期與價格？
• 技術資料散落在 PDF、型錄、Excel、業務經驗和 LINE 對話裡，要怎麼整理？
• 自動應答是不是接一個 LLM 就好？
• 答錯了誰負責？沒有答案時怎麼辦？
• IM Bot 與網站同時服務客戶時，資料能不能共用一套？

這個需求剛好落在近期持續研究的幾件事交會處：AI LLM、IM Bot、網站、RAG、工作流自動化。就用這個主題來做相關實驗了。

想法的三段演變

第一階段：先把基本需求滿足

起初只有一個判斷標準：能不能快速驗證需求。不求完美，只想知道客戶會不會用、員工願不願意維護、答案可不可靠。

第二階段：開始考慮長期成本及數據主權的掌握

時間拉長，問題就變了。若每月都在付席位費、AI 回覆費與通路費，資料又放在別人的平台，未來想換模型、接 ERP 或客製頁面時就可能被限制。於是出現兩個關注點：

1. 長期費用能不能被控制。
2. 核心技術與資料能不能掌握在自己手上。

這不代表現成產品不好，現成產品往往是最快的起點。重點是先看清楚哪些能力值得買、哪些最好自己會。

第三階段：從單一公司延伸到行業應用

針對工業刀具的需求拆開後，並不只屬於某類公司。許多 B2B 製造商與經銷商可能都有類似問題：產品資料複雜、技術問題重複、客戶分散在不同時區與通路、業務窗口有限。都可能需要能滿足內部外部的技術服務與知識庫工作流，未來有機會複製到其他行業。

先建立全局觀，再看現成產品

因此我動手前，先用 AI 調查並生成一份建議方案《工業品技術知識庫_智能客服建議方案》，當成全局地圖而非最終答案。它把問題拆成策略、架構、技術、落地四層，幾個重點如下：

• 先分清楚使用者：終端加工廠、經銷商、內部業務、網站 AI 客服，需要的內容深度完全不同。
• 高頻需求先集中在選型與加工參數。
• 刀具資料適合用分類、屬性標籤、內容類型三個維度交叉檢索。
• 參數應保存為「範圍加條件」，不要寫成單一數字。
• 價格、交期等敏感資訊更適合走規則查詢，不應完全交給 AI 生成。
• 沒有乾淨的結構化資料，AI 客服只會一本正經地胡說八道。

下一步是讓 AI 協助調查市場上現有產品，產出《技術服務網站／知識庫／自動應答 產品評估報告》，只看三件事：費用、導入複雜度、適合情境。

報告整理的公開價格參考包括：Freshdesk Growth 每席每月 29 美元、Dify Cloud Professional 每年 590 美元、Chatbase Hobby 每月 40 美元、Intercom Fin 每次 outcome 0.99 美元、Jira Service Management Standard 每位 agent 每月 20 美元。

導入規模方面，報告概念上把 POC 放在每月約 NT$0–5,000 加模型用量、一次性約 3–10 人日；小型正式版約每月 NT$3,000–20,000、一次性 10–30 人日；中型整合版約每月 NT$20,000–80,000、一次性 30–90 人日。真正的成本不只看月費，還包含文件整理、教育訓練、模型用量、通路、維運與資料遷移。

這一輪調查得到一個結論：

買現成服務，買到的是速度；自己搭建，買到的是掌握度。

兩者不是對立關係，而是看目前處在驗證期、成長期還是差異化期。

為什麼決定自建 MVP（Minimum Viable Product）

最後的決定是：不先追求完整客服系統，而是自建 MVP，並把過程當成 AI 工作流搭建的實踐。原因有四個：

1. 需要真的理解流程。只看產品報告知道「能做什麼」；自己做才知道資料、權限、回答來源與通路卡在哪裡。
2. 長期成本與客製化很重要。工業品技術服務不是通用客服，型號、材料、工況、替代品、ISO 代碼與參數範圍都很專業。
3. 先驗證小閉環。讓一個 Bot 能依知識回答、附上來源、找不到就承認不知道，比一次接 LINE、Email、ERP 與工單更有價值。
4. 可以變成經驗資產。每次踩坑、修正與整理，都能沉澱成文章與行業方案的素材。

實驗平台選擇 AstrBot：它能接多種不同 IM、API 調用各種 LLM 模型、串接 OS 工具、自建插件與 Skill，也能掛知識庫（原生 RAG 或自定義）。AstrBot 不是終點，而是把AI + Bot + 知識 + 業務流程一起串接起來的實驗場。

用 AI 工作流技能地圖回頭檢驗

這段從需求到決策的過程，剛好就是「AI 工作流搭建」實戰的一次練習。先前整理發布過一篇文章（見《一個普通人能看懂的 AI 工作流搭建師技能地圖》），分為三層：人人必修的基本功、依服務對象補強、最難被工具取代的判斷力。核心觀點是：越是「按按鈕」的技能越快被工具取代，越是「靠判斷」的能力越難被取代。

第一層：基本功，決定流程能不能跑起來

第二層：服務對象不同，要補的東西也不同

第二層的重點是：服務誰，就要補哪方面的功課。這次的對象是工業產品外貿，要補的不是更多自動化技巧，而是產業語言：

• 客戶問的是選型與加工參數，不是泛泛的產品介紹。
• 刀具資料要能依分類、材料、工況、塗層、ISO 材質代碼交叉檢索。
• 參數要保存成「範圍加條件」，而不是一個寫死的數字。
• 價格、交期這類敏感資訊走規則查詢，不交給 AI 自由生成。

換句話說，同樣是做知識庫與自動應答，換成別的行業，第二層要補的東西就完全不同。但這個方案架構是可以重複使用的，這也是後來想把它延伸成可複用行業方案的原因之一。

第三層：判斷力，是這次最大的收穫

如果說前兩層是在「做出來」，第三層就是在「做對」。地圖裡的判斷力有五項，在這個案例的體會：

我很認同地圖那篇的結語：技術會一直換，但判斷力才是真正帶得走的資產。這次比較現成產品、決定自建 MVP，花時間最多的不是學新工具，而是想清楚「這件事哪裡該靠 AI、哪裡該靠規則、哪裡該靠人」。

順帶一提的兩個參考

整理這段思路時，我也看到兩篇與 AI 工作流相關的文章，剛好可以對照。陳韋安的《AI 工作流七大構件》提到，AI 工作流不是換一套全新的做事方法，而是在原本流程中找出適合導入 AI 的節點；雷蒙三十的《聊天型、協作型、代理型的三個階段》則把 AI 使用方式分成三個層次。對照之下，我目前這個 MVP 大概落在協作型，往代理型邁進之前，更需要先把資料、邊界與驗收標準整理好。

AI 工作流不是把工作全部丟給 AI，而是把人的判斷放在正確的位置。

設計原則與實作對照

起源篇提出的原則，在後續文章的落實程度並不一致。這裡先把狀態攤開，避免讀者誤以為都已完成。

為什麼系列會出現金融案例

原本的主線是工業刀具知識庫。第 2 篇另開一個金融分析案例，用意不在投資，而在試驗「AI扮演多個角色，取得外部資料來源，而互相討論並產出結論」這種工作流。

這種流程需要穩定、可程式取得的外部資料。TradingView MCP 接入的恰好是金融相關數據（行情、技術指標、新聞、回測），工具齊全、資料即時，很適合用來驗證三件事：

1. MCP 能不能把外部資料穩定接進 AstrBot。
2. Skill 能不能約束多角色的討論流程。
3. 結論能不能附上資料依據。

這套方法驗證後，才能轉用到產業情報這類商業場景。

本系列接下來的走向

• 第 1 篇（技術實作）：VPS 搭建 AstrBot 平台，AstrBot 串接 LINE Bot／Telegram 多種 IM 的環境 Setup、LLM Provider 測試、檔案式簡易知識庫插件設定與自動應答。
• 第 2 篇（技術實作）：MCP 外部資料接入、N8N、AstrBot 通過 Docker 網路連通、多角色討論 Skill 的試驗。
• 第 3 篇（商業考慮）：把工業刀具案例延伸為可複用的產業情報插件，評估合規的商業推薦與開發成本。

目前系列以 IM 通路為主；起源篇提到的「網站端共用同一套資料」尚未進入實作，會列在後續規劃。