跳到主要內容

部落格

不定期分享最新資訊文章

  • article-Skill 之後,下一個 AI 開發者一定要懂的詞:Agent Harness

    2026/8/22

    AI工具 AI Agent Codex
    Skill 之後,下一個 AI 開發者一定要懂的詞:Agent Harness

    最近如果你有在使用 Codex、Claude Code 或其他 AI Coding Agent,應該會一直看到一個詞:Skill。 我自己這陣子也花了不少時間研究 Skill,因為它解決了一個很重要的問題:怎麼把「我做事情的方法」交給 AI。 以前我們寫 Prompt,後來開始把 SOP、規則、範例與檢查標準整理成 Skill。這樣 AI 不只是知道我們想要什麼,也開始知道一件事情應該怎麼做。 但研究 Skill 到後來,我發現下一個同樣關鍵的概念已經浮現出來了:Agent Harness。 本文把 Agent Harness 當成一個工作架構來討論。這個詞在不同社群裡未必有完全一致的正式定義,以下採用的意思是:讓 Agent 能夠取得資訊、使用工具、執行任務、處理失敗並在權限邊界內持續工作的整套環境與機制。 Skill 解決「怎麼做」,Harness 解決「怎麼工作」假設今天我要一個 AI 幫我開發網站,我可以寫一個 frontend Skill,告訴它: UI 應該怎麼設計 React 元件怎麼拆分 Accessibility 怎麼檢查 測試怎麼執行 完成前要驗收哪些事情 這些內容是在教 AI:「怎麼把前端做好。」這就是 Skill。 但接下來還有一連串問題: AI 要怎麼讀取我的專案? 它要怎麼修改檔案與執行指令? 哪些工具可以使用? 執行失敗後要不要重試? 做到一半要怎麼保留狀態? 哪些事情可以自行完成,哪些事情一定要先詢問? 這些就不是單一 Skill 可以解決的問題。讓 Agent 真正「工作起來」的環境、流程與控制機制,就是 Agent Harness 所處理的範圍。 模型是大腦,Skill 是 SOP,Harness 是整間公司我現在會用下面這個方式理解 AI Agent: Model → Harness → Skills → Tools / MCP → Product 如果把 AI 想成一位員工: 元件 可以怎麼理解 主要作用 Model 大腦 理解、推理與解決問題 Harness 工作環境與管理制度 提供上下文、流程、權限、狀態與錯誤處理 Skills SOP 與專業方法 告訴 Agent 某一類工作應該怎麼完成 Tools / MCP 工具與外部連接 讓 Agent 搜尋資料、操作檔案、呼叫 API 或使用服務 Product 最終工作場景 把前面的能力組合成使用者真正需要的產品 因此,Harness 決定的不是某一個專業步驟,而是這個 AI 能不能從「想」走到「做」,再從「做」走到「驗收完成」。 為什麼同一個模型,在不同工具裡差這麼多?這是很多人使用 AI Coding 工具後都會遇到的疑問:明明底層可能使用能力相近的模型,為什麼放進不同 Coding Agent,體感卻可以差很多? 原因之一就在 Harness。 我們實際使用的從來不只是 Model,而是: Model × Context × Tools × Skills × Harness 你怎麼把檔案提供給它、怎麼讓它搜尋程式碼、怎麼讓它執行 Shell、怎麼把錯誤回饋給它、怎麼讓它修改後重新測試,以及怎麼讓它在長任務裡維持方向,都會直接影響最後結果。 所以未來比較 AI Agent 時,可能不能只問:「它用哪一個模型?」還要開始問:「它的 Harness 怎麼設計?」 為什麼 Codex 值得研究?OpenAI 的 Codex GitHub repository 是一個值得研究的 Coding Agent 實作樣本。 如果只把它看成「一個 AI Coding CLI」,可能會錯過更值得觀察的部分:一個模型是如何被組織成可以在專案裡工作的 Agent。 可以從以下幾個方向閱讀它的設計: Agent 的執行流程 Context 如何取得與整理 工具呼叫與結果回傳 Shell 與檔案系統操作 Sandbox、權限與 Approval MCP 與 Skills 的整合 長任務中的狀態與錯誤處理 這些能力加在一起,才構成一個真正可以工作的 Agent。模型本身很重要,但它只是整個系統中的一層。 Agent Harness 不只適合寫程式Agent Harness 的思維不一定只能拿來做 Coding Agent。只要一項工作需要多步驟執行、外部工具、領域規則與可驗收的結果,就可以思考如何組裝自己的工作環境。 應用方向 Harness 組合方式 可能的產品形態 SEO Agent Agent Harness+SEO Skill+Search Console/GA4 工具+網站資料 SEO 分析與優化助手 Google Ads Agent Agent Harness+投放策略 Skill+廣告工具+公司 SOP AI 投放助理 標案 Agent Agent Harness+標案 Skill+政府規範+PDF/Excel/Drive 工具 企業內部標案助手 這時候我們做的就不只是聊天機器人,而是在替不同工作組裝不同的 AI 員工。 Skill 其實只是其中一層一開始很容易以為:「只要把 Skill 寫好,AI 就會變專業。」這句話只說對了一半。 Skill 解決的是: AI 知不知道這件事情應該怎麼做? Harness 解決的則是: AI 有沒有能力沿著這套方法一路做到完成? 一個 Skill 即使寫得很完整,如果 Agent 沒有讀取檔案的能力、沒有適合的工具、沒有錯誤回饋、沒有驗收流程,最後仍可能只能產生一段看起來合理的回答,而不是完成一項工作。 反過來說,Harness 也不能取代 Skill。沒有專業方法與檢查標準,Agent 可能很會操作工具,卻不知道什麼才是好的結果。 AI 產品的競爭正在改變前幾年的 AI 產品,很多競爭集中在 Prompt:誰的 Prompt 寫得好,誰的結果看起來比較漂亮。 後來大家開始做 RAG、Knowledge Base 與 Tools,接著又出現 Skills、MCP 與 Agent。下一階段的競爭,很可能會落在如何把這些元件組成一套穩定工作的系統: Model + Harness + Skills + Tools + Domain Knowledge + Product UX 模型會持續變強,工具協定也會逐漸標準化,Skill 甚至可能大量開源。最後真正拉開差距的,反而可能是你怎麼替 AI 設計工作方式,以及能不能把結果穩定交付給使用者。 開始研究 Agent Harness,可以先問這五個問題如果你想開始設計自己的 Agent Harness,可以先從這五個問題開始: Agent 需要哪些專案資料與 Context? 它需要讀寫哪些檔案、資料庫或外部服務? 哪些工具可以自動使用,哪些操作需要 Approval? 指令失敗、工具回傳錯誤或結果不完整時,應該如何處理? 任務完成的驗收條件是什麼,誰負責最後確認? 這些問題會把討論從「我要一個會聊天的 AI」推進到「我要一個可以完成工作的系統」。 結語:從教 AI 回答,到設計 AI 完成工作如果你最近才剛開始研究 Skill,下一個關鍵字可以直接記起來:Agent Harness。 我們正在從「教 AI 怎麼回答問題」,進入「設計 AI 怎麼完成工作」的階段。 當大家都能取得差不多的模型、MCP,甚至差不多的 Skill 時,真正重要的就會變成:誰能替 AI 設計出更好的工作方式,讓它在清楚的邊界裡持續執行、修正與交付結果。 延伸閱讀: 從提示詞到 Skill:5 個實務做法打造高效率 AI 自動化工作流 AI 工具名詞全解析:一次搞懂 MCP、Skill 與 CLI 的差異與應用場景 GPT-5-Codex Prompting 完全指南:從新手入門到情境實戰 常見問答 (FAQ)Q1:Agent Harness 是什麼?Agent Harness 是讓 AI Agent 能在真實環境中工作的整套環境與機制,通常包含 Context 管理、工具呼叫、檔案與 Shell 操作、狀態保存、錯誤處理、權限與 Approval,以及任務驗收流程。 Q2:Skill 和 Agent Harness 有什麼差別?Skill 教 Agent 某一類工作應該怎麼做,像是 SOP 或專業方法;Agent Harness 則負責讓 Agent 取得資料、使用工具、執行步驟、處理失敗並在權限邊界內持續完成任務。 Q3:為什麼同一個模型放在不同 AI Agent 裡,效果可能不同?因為最後結果不只由模型決定,也受到 Context、Tools、Skills 與 Harness 影響。檔案怎麼提供、工具怎麼呼叫、錯誤怎麼回饋、權限怎麼控制,都可能改變 Agent 的工作品質。 Q4:設計 Agent Harness 時,最先要處理什麼?最先要定義任務邊界、可使用的資料與工具、需要人工核准的操作,以及明確的完成與驗收條件。這些規則確定後,再決定要加入哪些 Skills 與模型能力。 Q5:Agent Harness 只能用來開發網站或程式嗎?不只能。SEO 分析、廣告投放、標案整理等工作,只要具備多步驟流程、外部工具、領域規則與可驗收結果,都可以用 Agent Harness 加上對應的 Skill 與資料來源來設計。

  • article-Learning OS 是什麼?AI 如何打造專屬自己的個人化學習系統

    2026/8/14

    AI自動化 AI工具 AI Agent ChatGPT
    Learning OS 是什麼?AI 如何打造專屬自己的個人化學習系統

    昨天看到朱騏分享一篇文章,看完之後,我最大的收穫不是 ChatGPT Sites,而是突然想到一件事: AI 正在改變的,也許不是「課程」,而是「學習」本身。 這個想法讓我重新思考,我們未來真正需要的,可能不只是更多內容,而是一套能夠陪著自己持續運作、持續調整的學習系統。 以前我們找課程,未來我們建立課程以前想學一項技能,我們第一個反應通常是: 「有沒有推薦的線上課程?」 於是開始搜尋 YouTube、買課、看書、找部落格。最後收藏了一大堆內容,卻還是不知道: 到底該先學哪一個? 真正缺少的,其實從來不只是知識,而是一條適合自己的學習路徑。 每個人的背景、目標、程度與可投入時間都不一樣。對別人來說很適合的課程順序,未必適合現在的自己;一套設計給大多數人的教材,也不一定能回應每個人的實際問題。 AI 開始把零散知識整理成個人課程朱騏分享了一個很有啟發性的做法:利用 ChatGPT Sites 搭配 AI Agent,替自己建立一套專屬的穿搭課程。 輸入自己的身高、體重、身形特徵、常穿品牌與想改善的地方之後,AI 不只是推薦幾支 YouTube 影片,而是重新整理整個知識架構,依照難度安排順序,將原本散落在網路上的內容,整理成一套真正適合自己的課程。 我覺得,這才是 AI 最有價值的地方之一。 它不只是幫你找到資料,也可以協助你回答幾個更重要的問題: 我現在在哪一個程度? 我真正想解決的是什麼問題? 哪些內容應該先學,哪些可以晚一點再學? 我怎麼知道自己是真的理解,而不是只看過? 當 AI 開始處理這些問題時,它扮演的角色就不再只是搜尋工具,而更接近學習流程的規劃者。 Learning OS 是什麼?我想到的不是 Sites 本身,而是更大的概念:Learning OS(學習作業系統)。 Learning OS 不只是存放影片、文章或筆記的地方,也不只是一份課程清單。它更像是管理整個學習流程的一套個人系統,會把目標、資源、任務、測驗與成果串在一起。 一套理想的 Learning OS,可能包含以下能力: 學習流程 Learning OS 可以協助處理的事情 了解起點 分析目前能力、背景與程度 設定方向 建立符合目標的個人化學習地圖 整理資源 整合 YouTube、書籍、文章與最新資料 安排行動 設計每天或每週的學習任務 檢查理解 透過提問、練習與測驗確認是否真的學會 累積證據 記錄作品、心得與實作成果 持續調整 根據進步、弱點與新目標重新規劃內容 今天你是新手,它可以先協助你建立基礎;三個月後,它知道你已經進步,就能安排進階內容;半年後,它也可以根據你的作品與弱點,重新規劃下一階段的學習方向。 它不是一門上完就結束的課,而是一套會隨著你改變的學習流程。 從線上課程到 Learning OS,差異在哪裡?傳統線上課程通常先設計好內容、順序與進度,再交給一群背景不同的學習者使用。這種方式適合建立共同基礎,但不一定能即時回應每個人的差異。 Learning OS 的重點,則是把客製化從「教材內容」延伸到「學習流程」: 比較面向 傳統線上課程 Learning OS 內容安排 先由課程設計者固定 依照個人目標與程度調整 學習順序 大多數人共用同一條路徑 可以依照弱點與進步重新排序 資源來源 以課程內提供的內容為主 可整合影片、書籍、文章與其他資料 完成標準 看完課程或完成章節 以理解、練習與作品成果為依據 使用期限 課程結束後通常告一段落 持續追蹤並規劃下一階段 這不代表傳統課程沒有價值,而是兩者解決的問題不同:課程提供結構化內容,Learning OS 則試著管理從起點到成果的完整學習循環。 如果你想先建立一個明確的學習起點,也可以參考既有的結構化資源,例如 微軟《Generative AI for Beginners》課程。而當學習目標是 SEO 時,新手學 SEO 完整指南 也呈現了如何把免費資源、AI 工具與階段任務整理成學習地圖。 AI Agent 在 Learning OS 裡扮演什麼角色?AI Agent 最大的價值,不只是回答問題,而是協助執行一連串有前後關係的任務。 放進 Learning OS 裡,它可以成為一位會持續工作的 AI 教練,協助完成以下流程: 先理解學習者的目標、程度與限制。 將零散資料整理成可理解的主題與學習順序。 根據可投入的時間安排每日或每週任務。 用提問、練習或小測驗檢查理解程度。 根據作品、筆記與錯誤紀錄找出弱點。 依照學習成果調整下一階段的內容。 這種工作方式,和單次問答最大的差別在於:它關注的是整段學習流程,而不是某一個當下的答案。 未來真正客製化的,不只是教材,而是學習流程過去的線上課程,只能設計給大部分的人。但每個人的背景、目標與程度都不同。 有人缺理論,需要先補基礎概念;有人缺實作,需要直接做出作品;有人只想解決眼前的一個問題,不需要從頭看完一套完整課程。 AI Agent 的價值,就是能依照每個人的需求,重新建立一套屬於自己的學習流程。真正被客製化的,不再只是教材,而是: 學什麼 先學什麼 用什麼方式學 何時練習 如何驗證理解 下一步要往哪裡走 同樣的概念,也可以應用在不同主題: 想學 AI:從基本概念、工具操作到實作專案。 想學英文:依照程度、使用情境與口說弱點安排練習。 想學攝影:從構圖、曝光到拍攝作品與回饋。 想學健身:依照目標、經驗與可投入時間安排訓練。 想學寫作或簡報:從模仿、練習到作品修正與發布。 每個主題的內容不同,但核心都是同一件事:讓學習從「收藏資料」變成「持續完成任務並產生成果」。 Learning OS 仍然需要人的參與Learning OS 可以協助整理、規劃與追蹤,但知識被整理好,不代表能力就自動建立了。 學習者仍然需要做幾件重要的事: 說清楚自己真正想達成的目標。 真的完成練習,而不是只閱讀學習計畫。 提供作品、筆記或測驗結果,讓系統知道目前狀態。 判斷哪些建議符合自己的情境,必要時修正方向。 AI 可以讓學習流程更容易開始,也能降低整理資源與安排順序的成本;但最後能不能學會,仍然取決於是否持續練習、接受回饋與把知識用出來。 AI 的下一個戰場,也許就是教育我一直認為,AI 真正厲害的地方,不只是回答問題,也不是生成內容,而是幫我們建立一套可以持續運作的系統。 工作有 Workflow,開發有 Coding Workflow,未來學習也會有自己的 Learning Workflow。 想學 AI、英文、攝影、健身、寫作、投資或簡報,都可以建立一套專屬自己的 Learning OS。它會隨著你的程度、作品、弱點與目標變化,持續調整下一步。 未來我們買的可能不是一門「上完就結束」的線上課程,而是一套能陪著自己一起成長的學習作業系統。 最後,也謝謝朱騏分享這篇文章。好的文章,不一定是直接給你答案,而是讓你開始思考更多可能性。 如果你也對這個主題有興趣,可以看看朱騏分享的原文,也許會得到不同的啟發。 常見問答 (FAQ)Q1:Learning OS 和一般線上課程有什麼不同?一般線上課程通常提供固定的內容與學習順序;Learning OS 則把個人目標、程度、學習資源、任務、測驗與成果串在一起,並根據學習進度持續調整路徑。 Q2:建立個人化 Learning OS 需要先提供哪些資訊?至少需要提供學習目標、目前程度、背景、可投入時間、想改善的問題與偏好的學習資源。若能持續提供練習作品、筆記或測驗結果,系統就更容易依照實際進步調整內容。 Q3:AI Agent 可以保證我真的學會嗎?不能。AI Agent 可以協助規劃內容、安排任務、設計問題與追蹤成果,但真正學會仍需要學習者完成練習、接受回饋,並把知識應用在作品或實際問題上。 Q4:Learning OS 適合哪些學習主題?Learning OS 適合有明確目標、需要持續累積能力的主題,例如 AI、英文、攝影、健身、寫作與簡報。只要能定義學習階段、安排練習並留下成果,就有機會建立對應的學習流程。 Q5:Learning OS 會取代老師或線上課程嗎?不一定。線上課程仍然可以提供系統化教材,老師也能提供經驗、示範與深度回饋;Learning OS 比較像是把不同資源與學習行動串起來,協助學習者更有方向地使用課程與內容。

  • article-企業工作自動化不只有 ChatGPT!6 大 AI 自動化能力解析與導入指南

    2026/7/29

    商業策略 AI自動化 AI工具 AI Agent
    企業工作自動化不只有 ChatGPT!6 大 AI 自動化能力解析與導入指南

    為什麼企業自動化不能只靠 AI 聊天?很多人一提到 AI 自動化,第一個想到的就是 ChatGPT。但實際上,ChatGPT 只是整個企業工作自動化版圖中的其中一塊拼圖。 如果把企業每天的營運與工作流程攤開來看,你會發現真正的自動化能力,大致可以細分成六種類型。每一種類型解決的商業痛點都不同,唯有彼此互相搭配,才能形成一套完整且高效的 AI 工作流 (AI Workflow) 。 1. 如何透過「AI 助理自動化」倍增個人生產力?這是大部分人最先接觸到,也最熟悉的 AI 應用。像是 ChatGPT Projects、GPTs、Gemini Gems 等工具,都屬於 AI 助理的範圍。 它們最大的價值,在於協助個人完成「知識型工作」,例如: 知識問答與搜尋 大量文件閱讀與整理 文案與內容生成 長文摘要與跨國語言翻譯 策略企劃與腦力激盪 這項能力就像是聘請了一位全天候待命的數位助理,陪著你一起工作,從根本上提高員工每日的產出效率。 2. 「AI 技能自動化」:如何將專業 Know-how 變成專屬 Skill?如果 AI 助理是會聊天的得力助手,那麼 AI 技能 (Skill) 就像是替 AI 安裝特定領域的專業外掛。 透過如 Claude Skills、ChatGPT Plugins 等功能,企業能把一套專業方法論與邏輯封裝起來,讓 AI 每次都依照完全相同的標準流程執行。 適用場景: 封裝企業內部 SOP 產出高度格式化、規格化的報告 標準化客服與回覆流程 取代重複性高的專業審核任務 這代表 AI 不再只是隨機「回答問題」,而是將企業長年累積的經驗與 Know-how,轉化為可以無限反覆使用的數位資產。 3. 告別手工報表!「數據決策自動化」讓資料自己說話企業每天都會累積海量資料,但真正困難的是如何「快速看懂並採取行動」。像 Power BI、Tableau 等商業智慧工具,就是專門解決這類工作。 透過數據決策自動化,你可以建立: 即時更新的 KPI 儀表板 深度營運分析與預測 自動派發的高階管理報表 異常數據的即時監控系統 主管不用再苦苦等待員工每天整理 Excel,而是透過動態視覺化資料快速掌握公司營運狀況,讓決策更即時、更具科學依據。 4. 「應用生成自動化」與 Vibe Coding:讓 AI 幫你寫出專屬工具近年技術圈最熱門的趨勢就是 Vibe Coding。透過 AI 的輔助,即便是非傳統軟體工程背景的員工,也能快速建立專屬的應用: 日常作業小工具 企業內部管理系統 客製化管理平台 面向客戶的網頁應用程式與互動介面 以前需要工程團隊花上數週、甚至數月才能評估並開發完成的功能,現在透過 AI 輔助開發,可能幾小時或一天內就能產出 MVP(最小可行性產品),大幅降低企業的軟體開發與試錯門檻。 5. 打破系統孤島!「流程整合自動化」實現跨平台無縫協作企業最大的痛點通常不是「沒有系統」,而是「系統之間彼此不會溝通」。這時候就需要 Make、n8n、Zapier 這類強大的流程整合平台 (iPaaS)。 它們扮演企業數位大腦的角色,負責: 跨系統/跨平台的資料串接 條件觸發的自動化通知 跨部門資料同步更新 企業內部與外部 API 整合 實戰範例:當客戶填寫線上表單 → 系統自動在 CRM 中建檔 → 透過 Gmail 發送迎新信件 → 推送通知到業務部的 LINE/Slack → 同步更新 Google Sheets 總表。全程零人工介入,24 小時自動執行。 6. 突破舊系統限制:「桌面操作自動化 (RPA)」完成最後一哩路有些年代久遠的舊系統 (如老舊 ERP)、封閉的銀行後台系統,既沒有開放 API,也無法直接用現代化工具串接,這該怎麼辦? 這時候就需要 Power Automate、UiPath,或是近年崛起的 Computer Use、Browser Use 等 RPA(機器人流程自動化)技術。 它們能夠完美模擬真人的操作行為: 點擊按鈕與拖曳 開啟特定網站與軟體 帳號密碼登入系統 表單自動輸入與報表下載 即使系統再古老,只要「人類能用滑鼠鍵盤操作」,RPA 通常都能完美代替人工完成,補齊自動化版圖的最後一哩路。 總結:整合 6 大能力,打造專屬企業的 AI 工作流很多企業在導入 AI 時,往往只停留在第一層——把 ChatGPT 當作高級的聊天搜尋引擎。 但真正成熟且具備競爭力的數位轉型,應該是把上述六種能力進行有機整合: AI 助理自動化:賦能員工,提升個人產出。 AI 技能自動化:保存 Know-how,封裝專業技能。 數據決策自動化:即時分析,輔助管理層決策。 應用生成自動化:靈活開發,快速打造業務所需工具。 流程整合自動化:串連百大系統,建立無人工介入的運轉流。 桌面操作自動化:克服封閉系統,解決無法整合的痛點。 當這六大能力交織在一起,就能從個人層級的效率提升,擴展到跨部門的團隊協作,最終重塑企業的營運模式。AI 的真正價值,不僅是幫你回答問題,而是讓複雜的工作流程真正開始自己運轉。 常見問答 (FAQ)Q:我們公司已經購買了 ChatGPT 企業版,這樣還不算完成「AI 自動化」嗎?A:ChatGPT 企業版是非常強大的「AI 助理自動化」工具,能大幅提升個人與團隊的知識處理效率。但若要讓企業流程「自動運轉」(例如收到客戶信件自動建檔並發送報價),您還需要結合「流程整合自動化」(如 n8n、Make),將 AI 嵌入到工作流中,才算建立真正的企業 AI 自動化版圖。 Q:遇到沒有開放 API 的傳統老舊 ERP 系統,該如何達成自動化串接?A:針對無法透過 API 串接的封閉式或傳統系統,建議採用第 6 項的「瀏覽器/桌面操作自動化 (RPA)」技術。像是 Power Automate 或是支援 Computer Use 的新世代 AI 工具,能模擬真人移動滑鼠、輸入帳密並點擊按鈕,強行突破無 API 的限制。 Q:中小企業資源有限,這 6 大自動化能力應該從哪一個開始導入?A:建議採取「先個人,後流程」的策略。第一階段先從「AI 助理自動化」開始,培養員工的 AI 指令 (Prompt) 能力;第二階段盤點日常耗時最多的跨部門行政作業,優先導入「流程整合自動化」(如 Zapier / Make),針對報表轉移、自動通知進行無程式碼串接,這是成本最低且見效最快的切入點。

  • article-AI 工具名詞全解析:一次搞懂 MCP、Skill 與 CLI 的差異與應用場景

    2026/4/13

    AI自動化 AI工具 AI Agent
    AI 工具名詞全解析:一次搞懂 MCP、Skill 與 CLI 的差異與應用場景

    最近如果你常接觸 AI 開發、AI Agent 或開發者工具,應該很容易出現一種感覺:「怎麼每個東西一下叫 MCP,一下叫 Skill,一下又冒出 CLI?」明明都像是在「讓 AI 幫我做事」,為什麼名詞越來越多? 很多開發者一開始也常看得霧煞煞。例如明明已經知道某個工具有 Skill,結果又看到它推出 CLI,心裡就會冒出一個問號:所以我到底是要用哪一個?還是兩個都要用? 這不是大家故意把事情搞複雜,反而是因為 AI 協作時代真的來了,工具開始分層,於是名詞也跟著變多了。本篇文章將帶你深度解析這三者的定位,幫你建立清晰的 AI 工具觀念地圖。 核心觀念:釐清 CLI、Skill 與 MCP 的階層關係最簡單的理解方式是:這三個名詞不是互斥的競品,而是不同層級的入口。 CLI:給人類或 AI 直接操作的命令列入口。 Skill:給 AI 使用的能力封裝。 MCP:讓 AI 可以用標準方式接上外部工具和資源的協定。 如果要更白話一點: CLI 像是「工具的操作面板」 Skill 像是「AI 已經學會怎麼用的一招」 MCP 像是「AI 與工具之間的通用插座」 它們常常是在同一個生態系裡扮演不同角色,讓同一個能力能夠被不同使用者(人類或 AI)順利呼叫。 為什麼開發工具越來越重視 CLI 介面?因為 AI 很會處理文字,而 CLI 剛好就是純文字介面。 過去我們覺得 GUI(圖形化介面)很直覺,按鈕、選單對人類最友善。但對 AI 來說,GUI 的操作成本極高,它需要理解畫面、找按鈕、判斷狀態。相反地,CLI 非常單純:輸入是文字、輸出是文字、參數明確且結果結構化。 例如當你叫 AI 幫你部署專案、初始化設定或跑測試,如果背後有 CLI,AI 幾乎就能很自然地組出命令來執行。AI 操作 CLI 的成本極低、成功率高,且極易整合,這也是為什麼越來越多工具開始強化 CLI 支援。 時代演進:從「人機協作」到「AI Agent 獨立操作」以前的工具通常只有網站、後台與按鈕,由「人」手動操作。現在的工具則必須兼顧多重入口,包含 API、SDK、CLI、Skill 甚至 MCP Server。 這是因為現在的操作者不再只有人類,AI Agent 也要能操作工具。當一個工具想要同時服務一般使用者、開發者、自動化流程與 AI Agent 時,它自然就會長出不同層級的入口。 生活化比喻:用「餐廳點餐」秒懂工具分工假設你開了一家餐廳,同樣都是「點餐」,可以有很多入口: 客人現場看菜單點餐 打電話訂餐 外送平台下單 自動接單系統接 API 這些管道互不衝突,本質上都是同一個餐廳的能力。放到 AI 工具也是一樣: CLI:像打電話直接下明確的指令。 Skill:像店員已經會某套流程,知道怎麼幫你把事情處理好。 MCP:像統一的接單規格,外部平台都可以照這個標準格式接進來。 CLI 是什麼?為何它是 AI 最愛的溝通介面?CLI (Command Line Interface) 即命令列介面,讓你用文字指令直接操作工具。例如: 1234npm installgit commit -m "update"playwright testvercel deploy CLI 的核心優勢: 指令明確:一條指令做一件事,輸入輸出極度清晰。 容易自動化:非常適合 Shell Script、CI/CD 與批次流程。 易於被 AI 生成:AI 極度擅長根據需求組出合理的命令。 無須 GUI 依賴:對一次性任務與開發流程特別方便。 Skill 是什麼?如何讓 AI 具備專業技能?Skill 可以想像成「AI 已經包裝好的能力單元」。 它通常不只是某個工具本身,而是「AI 如何使用這個工具」的抽象化過程。當你請 AI「幫我用瀏覽器點開登入頁並檢查流程」時,如果 AI 具備對應的 Skill,它就會知道:該用哪個工具、先做什麼、後做什麼、以及如何處理回傳結果。 Skill 的重點在於:AI 是否已經具備這項能力,並知道怎麼把它用起來。 MCP 是什麼?解密 AI 串接外部資源的通用協定MCP (Model Context Protocol) 是一個讓 AI 能用標準方式接上外部工具的協定。 過去每個工具都要各自開發整合方法,對 AI 系統來說維護成本極高。有了 MCP 之後,工具只要照著標準規格暴露能力,AI 就能輕鬆理解這個工具提供哪些功能、參數該怎麼傳遞、結果如何取得。MCP 更像是「規格」或「接口標準」,而不是某個單一的執行功能。 觀念統整:建立你的 AI 工具腦中地圖怕混淆的話,請記住這個最簡單的框架: CLI 解決:「怎麼操作工具?」 Skill 解決:「AI 會不會用這個工具?」 MCP 解決:「外部能力怎麼標準化接進來?」 業界案例分享:Playwright、GitHub 與 Vercel 的應用案例一:Playwright 自動化測試 CLI:你自己下達 npx playwright test 指令跑測試或錄製腳本。 Skill:你對 AI 說「幫我測試登入流程」,AI 透過內建的 Skill 幫你操作 Playwright。 MCP:AI 系統需要用標準方式接入瀏覽器自動化能力時,將 Playwright 暴露成可呼叫工具。 案例二:GitHub 專案管理 CLI:你使用 gh pr create 來建立 Pull Request。 Skill:AI 自動幫你看 PR 差異、整理 Issue 並產生 Commit 訊息。 MCP:讓 AI Agent 可以標準化地接進 GitHub API,執行完整的 Repo 管理。 案例三:Vercel 雲端部署 CLI:手動輸入 vercel deploy 發布專案。 Skill:AI 幫你檢查部署設定、排查 Build Error 或修正環境變數。 MCP:把專案狀態查詢與部署能力標準化,提供給 AI Agent 隨時呼叫。 實用評估指南:如何判斷當下該使用哪一層級?當你看到一個新工具時,可以問自己三個問題: 操作對象是誰?自己操作先看 CLI;讓 AI 幫你操作先看 Skill。 任務性質為何?一次性任務用 CLI 通常最快;長期且複雜的系統整合則需要 API 或 MCP。 你的角色是什麼?如果你只是「使用者」,Skill + CLI 就足夠;如果你在「建立 AI 工具鏈」,就必須深入理解 MCP。 總結:打破競品迷思,擁抱 AI 工具新生態很多開發者一看到新名詞,就會擔憂「是不是舊工具要被取代了?」。但實際上,CLI、Skill 與 MCP 常常是分工關係,而非競爭關係。 同一個能力同時存在這三種入口,反而代表這個工具正在邁向成熟,能同時滿足人類開發者、AI 輔助與系統整合的需求。記住一句話:CLI 是操作入口,Skill 是 AI 能力,MCP 是整合標準。看懂了這個生態拼圖,你就能在 AI 時代輕鬆駕馭各種新興工具! 常見問答 (FAQ)Q:我只是個普通的終端開發者,沒有在開發 AI Agent,還需要了解 MCP 嗎?A:現階段你不一定要「開發」MCP,但了解 MCP 的概念非常有幫助。因為未來會有越來越多好用的開發工具採用 MCP 協定,當你懂 MCP,你就能輕易將各種外部資料庫或工具無縫接入你日常使用的 AI 編輯器(如 Cursor)中,大幅提升開發效率。 Q:既然 AI 已經可以透過 Skill 幫我做事,我是不是不用再學 CLI 語法了?A:兩者並不衝突,甚至相輔相成。雖然 AI 可以代勞,但當你需要進行本機精細除錯、手動重現問題、或者將腳本整合進無 AI 環境的 CI/CD 流程時,CLI 仍然是不可或缺的基石。Skill 幫你省去學習複雜語法的認知負擔,但 CLI 確保了你對系統的絕對掌控權。 Q:為什麼同一個工具會有 CLI 也有 Skill?這樣不會多此一舉嗎?A:不會。CLI 解決的是「可操作性」(讓機器或人可以透過文字執行),而 Skill 解決的是「好協作性」(讓 AI 知道流程與邏輯)。就算 AI 有了 Skill 去幫你執行任務,底層往往還是透過呼叫 CLI 或 API 來完成。提供多重入口是為了服務不同情境與不同角色。 Q:MCP 跟一般 API 有什麼差別?A:API 是開發者直接呼叫的介面,通常需要知道參數與程式流程;MCP 則是為 AI 設計的「通用語境協定」,它不只暴露能力,還描述用途、參數、回傳格式和行為限制,讓 AI 平台可以用一致方式理解、選擇與串接工具。簡單來說,MCP 是 API 的「AI 標準化版本」。 Q:我有一個任務,該先用 CLI、Skill,還是直接找 MCP?A:先看任務性質。 想要自己操作、確認每一步,或寫成 shell script:選 CLI。 想要讓 AI 直接用自然語言完成複雜流程:選 Skill。 想要把能力標準化、跨工具串接、讓多種 AI 都能呼叫:選 MCP。實際上,最常見的路徑是「先有 CLI,再包成 Skill,最後用 MCP 做標準化整合」。 Q:如果我現在只會用 CLI,未來是否還需要補上 Skill/MCP 的知識?A:是的。CLI 是基礎,但當你想讓 AI 幫你自動執行日常工作、把工具能力交給 AI 使用,Skill 能讓你更快實現;如果你要在企業內部整合多個系統,MCP 就能幫你避免「每個工具都要重新整合一次」的問題。這三者累積起來,才是真正的 AI 工具鏈能力。 Q:Skill 和 MCP 哪個更適合企業導入?A:兩者各有定位。 Skill 適合讓 AI 用自然語言執行特定任務,例如客服流程、內容生成、測試引導。 MCP 適合企業級資源整合,例如跨系統資料查詢、內部資源呼叫、AI Agent 需要訪問特定資料源。最理想的情況是:把穩定核心能力做成 MCP 工具,再在此基礎上為 AI 提供 Skill 層,實現既穩定又易用的自動化體驗。

  • article-如何用 n8n 打造 AI Agent 專屬記憶庫?Logging 實戰 | (EP.7) n8n 自動化 API 串接教學

    2026/3/31

    AI自動化 AI Agent n8n API串接
    如何用 n8n 打造 AI Agent 專屬記憶庫?Logging 實戰 | (EP.7) n8n 自動化 API 串接教學

    為什麼 AI 需要 Logging?告別「金魚腦」的專屬黑盒子當我們將 LINE 等通訊軟體與 AI 結合時,常常會遇到一個災難現場:AI 沒有記憶。它無法記住上一秒的對話,導致每次回覆都像初次見面,甚至引發錯誤(Error)。 Logging 的本質,就是系統的專屬「黑盒子」。一句話講完:Logging 就是為了讓你在事後「看得懂發生過什麼事」。 在 n8n 或任何自動化流程中,Log 不僅僅是無聊的資料,它是拯救開發者的五大超能力: 除錯 (Debug): 沒紀錄只能瞎猜,有紀錄就能精準抓蟲。 重現 (Reproduce): 還原當下觸發錯誤的 Prompt。 監控 (Monitor): 追蹤系統的成功率與 API 呼叫狀況。 優化 (Optimize): 作為未來訓練 AI 的精華資料。 稽核 (Audit): 有紀錄才有證據,知道哪個環節出錯。 記憶的進化:從「給人看」到「給 AI 看」Logging 的應用可以分為兩個階段: 階段一:只做 Logging(給人看)為了事後查看、稽核執行結果。我們開始把資料寫入 Google Sheets,方便我們進行 Debug 與狀態確認。 階段二:Logging + 給 AI 查(AI 也要看)當 AI 需要記得前文、參考歷史紀錄,或是做進階的資料檢索(RAG)時,Log 就直接升級成了 AI 的 Context(上下文)。這能讓 AI 瞬間恢復記憶,甚至做到個人化預測與專屬知識庫的搭建。 踩雷警告!為什麼讓 AI 自動撈資料(Tool Calling)是一場災難?很多新手會有一個致命誘惑:「既然 AI 這麼聰明,不要在 Workflow 查了,直接寫個 Tool 讓 AI 自己去 Google Sheet 撈資料(Tool Calling)不是更簡單?」 想法很完美,但對於新手與固定規則的任務來說,這是一個巨大的陷阱! 失控的可控性: AI 可能亂查太多的資料、查錯條件,甚至決定「不查了」,看它心情做事。 成本超級高: 先讓 LLM 判斷 → 呼叫工具 → 再回傳 LLM,速度極慢且狂燒 Token。 除錯大地獄: 出錯時你根本不知道是 Prompt 寫壞、工具沒寫好,還是 AI 邏輯當機。 架構大 PK:Workflow 先查 vs. AI Agent 自己撈 比較項目 Workflow 先查 (Pre-fetch / 固定 Context) AI Agent 自己撈 (Tool Calling / 動態查詢) 適用情境 固定規則(例:每次都查最新 3 筆對話) 動態條件(例:查閱特定主題的歷史紀錄) 穩定度 極高 (100% 執行) 較低(看 AI 心情決定是否呼叫) 除錯難度 簡單清晰 複雜地獄 花費成本 低 高 專家建議: 在進入 AI 節點前,先由 Workflow 流程預先整理好必要資訊(固定 Context),確保 AI 每次都有穩定、可控的上下文。只有在遇到「不確定需求」或「延伸問題」時,才交由 Agent 進行動態查詢。 完整 Workflow 架構解析本次實作的完整流程共分為 三大區段,以下逐一拆解。 區段一:接收與解析 LINE 訊息1Webhook1 → Edit Fields1 Webhook1 接收 LINE Messaging API 傳入的 POST 請求(路徑:line-0324)。 Edit Fields1 負責從 LINE 事件結構中提取三個關鍵欄位: 欄位 來源路徑 說明 input_text body.events[0].message.text 使用者輸入的訊息 userId body.events[0].source.userId 識別使用者身份 replyToken body.events[0].replyToken LINE 回覆用的一次性 Token 區段二:建立固定 Context(Pre-fetch 記憶)1Get User History → Build History Context → Debug History Preview 這是整個架構的靈魂——在 AI 介入前,由 Workflow 自行整理好歷史記憶。 Get User History:從 Google Sheets 的 logging 工作表中讀取所有紀錄。 Build History Context:透過 Code 節點對資料進行篩選與格式化: const current = $('Edit Fields1').first().json; const currentUserId = current.userId || ''; const rows = $input.all().map(item => item.json); // 只取同一位使用者、狀態為 success 的最近 3 筆紀錄 const filtered = rows .filter(row => row.userId === currentUserId && row.status === 'success') .sort((a, b) => { const ta = new Date(a.timestamp || 0).getTime(); const tb = new Date(b.timestamp || 0).getTime(); return tb - ta; }) .slice(0, 3); const historyContext = filtered.length ? filtered.map((row, idx) => { return `${idx + 1}.\n時間:${row.timestamp || ''}\n輸入:${row.input_text || ''}\n摘要:${row.summary || ''}\n分類:${row.category || ''}\n關鍵字:${row.keywords || ''}`; }).join('\n\n') : '無歷史紀錄'; return [ { json: { ...current, history_context: historyContext, history_count: filtered.length } } ]; 核心邏輯: 過濾條件為「userId 相同」且 status === 'success',排除失敗紀錄後,取最新 3 筆,確保注入 AI 的都是可靠的高品質記憶。 Debug History Preview:在此節點新增 debug_ 前綴欄位(debug_userId、debug_history_count、debug_history_context 等),讓你在 n8n 執行面板中可以直接確認「AI 即將收到的歷史資料長什麼樣子」,是開發初期排查問題的透明窗口。 區段三:AI 分析、回覆 LINE 與寫入 Log1AI Agent1 → HTTP Request1 → Prepare Log1 → Google Sheets Log1 AI Agent1(搭配 Google Gemini)接收完整的 Context 後進行分析。 Prompt 設計如下: 請讀取以下內容,輸出摘要、主題分類、3 個關鍵字。 本次使用者輸入:{{$json.input_text}} 以下是此使用者最近的互動紀錄,僅供理解上下文與延續語意。 若與本次輸入無關,請以本次輸入為主: {{$json.history_context}} System Message 明確規範 AI 行為,防止幻覺與格式失控: 你是資料整理助手。 規則: 1. 使用繁體中文。 2. 不要捏造未提供的資訊。 3. 請只輸出 JSON。 4. 欄位必須包含 summary、category、language、keywords。 5. 若有歷史互動紀錄,僅可用來補足上下文,不可把過去內容誤當成這次輸入內容。 6. 若本次輸入與歷史紀錄無明顯關聯,請忽略歷史紀錄。 7. 若資訊不足,也必須輸出合法 JSON。 Structured Output Parser 確保 AI 輸出符合以下 JSON Schema,強制欄位驗證,防止格式亂跑: { "type": "object", "properties": { "summary": { "type": "string" }, "category": { "type": "string", "enum": ["AI工具", "程式開發", "商業", "教育", "其他"] }, "keywords": { "type": "array", "items": { "type": "string" } }, "language": { "type": "string" } }, "required": ["summary", "category", "keywords", "language"], "additionalProperties": false } HTTP Request1 呼叫 LINE Reply API,將 AI 分析結果回傳給使用者。 Prepare Log1 + Google Sheets Log1 將本次執行的完整資料寫回 Google Sheets,包含以下欄位: 欄位 說明 timestamp 執行時間($now) workflow Workflow 名稱 status 執行狀態(success) executionId n8n 執行 ID userId / replyToken 使用者識別資訊 input_text 本次輸入 summary / category / language / keywords AI 分析結果 history_count 本次帶入的歷史筆數 history_context 實際注入 AI 的歷史文字 設計亮點: 記錄 history_count 與 history_context 讓你未來可以回溯「AI 當時看到的是什麼」,是除錯 Hallucination 的關鍵利器。 🎁 附錄:完整 n8n Workflow JSON 腳本你可以直接複製以下 JSON 程式碼,並匯入至你的 n8n 專案中進行測試。匯入後請記得將 Google Sheets 文件 ID 替換為你自己的試算表 ID,並重新設定 Google Sheets 與 LINE Bearer Token 的憑證(Credentials)。 { "nodes": [ { "parameters": { "httpMethod": "POST", "path": "line-0324", "options": {} }, "type": "n8n-nodes-base.webhook", "typeVersion": 2.1, "position": [-1392, -288], "id": "07a2efae-2d4c-4b63-ab6d-38366b22f782", "name": "Webhook1", "webhookId": "a6ff766a-b5f5-4d36-9066-963fc0e4407f" }, { "parameters": { "assignments": { "assignments": [ { "id": "820ce329-eb3e-46b7-8264-c13e6bab20e1", "name": "input_text", "value": "={{ $json.body.events[0].message.text }}", "type": "string" }, { "id": "b9d8194d-1c76-4ad3-a2ab-95fc0db6a001", "name": "userId", "value": "={{ $json.body.events[0].source.userId || '' }}", "type": "string" }, { "id": "6fbbf8c4-4044-41a6-9721-4f11ec8b0001", "name": "replyToken", "value": "={{ $json.body.events[0].replyToken || '' }}", "type": "string" } ] }, "options": {} }, "type": "n8n-nodes-base.set", "typeVersion": 3.4, "position": [-1152, -288], "id": "d03c1de9-2b49-4ed0-98a3-d79d0cf0bb96", "name": "Edit Fields1" }, { "parameters": { "documentId": { "__rl": true, "value": "YOUR_GOOGLE_SHEET_ID", "mode": "list", "cachedResultName": "google sheet logging" }, "sheetName": { "__rl": true, "value": "gid=0", "mode": "list", "cachedResultName": "logging" }, "options": {} }, "type": "n8n-nodes-base.googleSheets", "typeVersion": 4, "position": [-912, -288], "id": "0ff96efd-5db8-45c3-a43e-0b1db98e31b3", "name": "Get User History" }, { "parameters": { "jsCode": "const current = $('Edit Fields1').first().json;\nconst currentUserId = current.userId || '';\n\nconst rows = $input.all().map(item => item.json);\n\nconst filtered = rows\n .filter(row => row.userId === currentUserId && row.status === 'success')\n .sort((a, b) => {\n const ta = new Date(a.timestamp || 0).getTime();\n const tb = new Date(b.timestamp || 0).getTime();\n return tb - ta;\n })\n .slice(0, 3);\n\nconst historyContext = filtered.length\n ? filtered.map((row, idx) => {\n return `${idx + 1}.\\n時間:${row.timestamp || ''}\\n輸入:${row.input_text || ''}\\n摘要:${row.summary || ''}\\n分類:${row.category || ''}\\n關鍵字:${row.keywords || ''}`;\n }).join('\\n\\n')\n : '無歷史紀錄';\n\nreturn [\n {\n json: {\n ...current,\n history_context: historyContext,\n history_count: filtered.length\n }\n }\n];" }, "type": "n8n-nodes-base.code", "typeVersion": 2, "position": [-672, -288], "id": "fe67f1ce-515a-471c-8fda-cdabfe30b00b", "name": "Build History Context" }, { "parameters": { "assignments": { "assignments": [ { "name": "debug_userId", "value": "={{ $json.userId }}", "type": "string" }, { "name": "debug_input_text", "value": "={{ $json.input_text }}", "type": "string" }, { "name": "debug_history_count", "value": "={{ $json.history_count }}", "type": "string" }, { "name": "debug_history_context", "value": "={{ $json.history_context }}", "type": "string" } ] }, "includeOtherFields": true, "options": {} }, "type": "n8n-nodes-base.set", "typeVersion": 3.4, "position": [-432, -288], "id": "61c5f27f-f9e9-4eb1-93eb-3f18ea2b586f", "name": "Debug History Preview" }, { "parameters": { "promptType": "define", "text": "=請讀取以下內容,輸出摘要、主題分類、3 個關鍵字。\n\n本次使用者輸入:{{$json.input_text}}\n\n以下是此使用者最近的互動紀錄,僅供理解上下文與延續語意。若與本次輸入無關,請以本次輸入為主:\n{{$json.history_context}}", "hasOutputParser": true, "options": { "systemMessage": "=你是資料整理助手。\n\n規則:\n1. 使用繁體中文。\n2. 不要捏造未提供的資訊。\n3. 請只輸出 JSON。\n4. 欄位必須包含 summary、category、language、keywords。\n5. 若有歷史互動紀錄,僅可用來補足上下文,不可把過去內容誤當成這次輸入內容。\n6. 若本次輸入與歷史紀錄無明顯關聯,請忽略歷史紀錄。\n7. 若資訊不足,也必須輸出合法 JSON。" } }, "type": "@n8n/n8n-nodes-langchain.agent", "typeVersion": 3.1, "position": [-176, -288], "id": "e969d51a-4654-4d55-85ae-4c8efe0c3fa0", "name": "AI Agent1" }, { "parameters": { "options": {} }, "type": "@n8n/n8n-nodes-langchain.lmChatGoogleGemini", "typeVersion": 1, "position": [-224, -64], "id": "8454dd71-055e-43b5-b445-5289f37fc7f8", "name": "Google Gemini Chat Model1" }, { "parameters": { "schemaType": "manual", "inputSchema": "{\n \"type\": \"object\",\n \"properties\": {\n \"summary\": { \"type\": \"string\" },\n \"category\": {\n \"type\": \"string\",\n \"enum\": [\"AI工具\", \"程式開發\", \"商業\", \"教育\", \"其他\"]\n },\n \"keywords\": {\n \"type\": \"array\",\n \"items\": { \"type\": \"string\" }\n },\n \"language\": { \"type\": \"string\" }\n },\n \"required\": [\"summary\", \"category\", \"keywords\", \"language\"],\n \"additionalProperties\": false\n}" }, "type": "@n8n/n8n-nodes-langchain.outputParserStructured", "typeVersion": 1.3, "position": [16, -64], "id": "b9638a0d-bfc5-4af6-8dbc-91f225223b3a", "name": "Structured Output Parser1" }, { "parameters": { "method": "POST", "url": "https://api.line.me/v2/bot/message/reply", "authentication": "genericCredentialType", "genericAuthType": "httpBearerAuth", "sendHeaders": true, "headerParameters": { "parameters": [{ "name": "Content-Type", "value": "application/json" }] }, "sendBody": true, "specifyBody": "json", "jsonBody": "={\n \"replyToken\":\"{{ $('Webhook1').item.json.body.events[0].replyToken }}\",\n \"messages\":[\n {\n \"type\": \"text\",\n \"text\": \"【summary】{{ $json.output.summary }} \\n【category】{{ $json.output.category }} \\n【language】{{ $json.output.language }} \\n【關鍵字】{{ $json.output.keywords.join('、') }}\"\n }\n ]\n}", "options": {} }, "type": "n8n-nodes-base.httpRequest", "typeVersion": 4.4, "position": [208, -288], "id": "371bad55-6ecb-4cc0-8ef2-3a8a0d9ffdc7", "name": "HTTP Request1" }, { "parameters": { "assignments": { "assignments": [ { "name": "timestamp", "value": "={{ $now }}", "type": "string" }, { "name": "workflow", "value": "={{ $workflow.name }}", "type": "string" }, { "name": "status", "value": "success", "type": "string" }, { "name": "executionId", "value": "={{ $execution.id }}", "type": "string" }, { "name": "userId", "value": "={{ $('Webhook1').item.json.body.events[0].source.userId || '' }}", "type": "string" }, { "name": "replyToken", "value": "={{ $('Webhook1').item.json.body.events[0].replyToken || '' }}", "type": "string" }, { "name": "input_text", "value": "={{ $('Edit Fields1').item.json.input_text || '' }}", "type": "string" }, { "name": "summary", "value": "={{ $('AI Agent1').item.json.output.summary || '' }}", "type": "string" }, { "name": "category", "value": "={{ $('AI Agent1').item.json.output.category || '' }}", "type": "string" }, { "name": "language", "value": "={{ $('AI Agent1').item.json.output.language || '' }}", "type": "string" }, { "name": "keywords", "value": "={{ $('AI Agent1').item.json.output.keywords ? $('AI Agent1').item.json.output.keywords.join('、') : '' }}", "type": "string" }, { "name": "history_count", "value": "={{ $('Debug History Preview').item.json.history_count || 0 }}", "type": "string" }, { "name": "history_context", "value": "={{ $('Debug History Preview').item.json.history_context || '' }}", "type": "string" } ] }, "options": {} }, "type": "n8n-nodes-base.set", "typeVersion": 3.4, "position": [448, -288], "id": "920dbd89-1a14-47ce-85f2-cf2bd86b93ba", "name": "Prepare Log1" }, { "parameters": { "operation": "append", "documentId": { "__rl": true, "value": "YOUR_GOOGLE_SHEET_ID", "mode": "list", "cachedResultName": "google sheet logging" }, "sheetName": { "__rl": true, "value": "gid=0", "mode": "list", "cachedResultName": "logging" }, "columns": { "mappingMode": "defineBelow", "value": { "timestamp": "={{ $json.timestamp }}", "workflow": "={{ $json.workflow }}", "status": "={{ $json.status }}", "executionId": "={{ $json.executionId }}", "userId": "={{ $json.userId }}", "replyToken": "={{ $json.replyToken }}", "input_text": "={{ $json.input_text }}", "summary": "={{ $json.summary }}", "category": "={{ $json.category }}", "language": "={{ $json.language }}", "keywords": "={{ $json.keywords }}", "history_count": "={{ $json.history_count }}", "history_context": "={{ $json.history_context }}" } }, "options": {} }, "type": "n8n-nodes-base.googleSheets", "typeVersion": 4, "position": [704, -288], "id": "89ea098f-51c3-4aa2-8632-8c0114eb5b92", "name": "Google Sheets Log1" } ], "connections": { "Webhook1": { "main": [[{ "node": "Edit Fields1", "type": "main", "index": 0 }]] }, "Edit Fields1": { "main": [[{ "node": "Get User History", "type": "main", "index": 0 }]] }, "Get User History": { "main": [[{ "node": "Build History Context", "type": "main", "index": 0 }]] }, "Build History Context": { "main": [[{ "node": "Debug History Preview", "type": "main", "index": 0 }]] }, "Debug History Preview": { "main": [[{ "node": "AI Agent1", "type": "main", "index": 0 }]] }, "AI Agent1": { "main": [[{ "node": "HTTP Request1", "type": "main", "index": 0 }]] }, "Google Gemini Chat Model1": { "ai_languageModel": [[{ "node": "AI Agent1", "type": "ai_languageModel", "index": 0 }]] }, "Structured Output Parser1": { "ai_outputParser": [[{ "node": "AI Agent1", "type": "ai_outputParser", "index": 0 }]] }, "HTTP Request1": { "main": [[{ "node": "Prepare Log1", "type": "main", "index": 0 }]] }, "Prepare Log1": { "main": [[{ "node": "Google Sheets Log1", "type": "main", "index": 0 }]] } } } 常見問答 (FAQ)Q:為什麼不直接使用 OpenAI 或 Gemini 內建的 Memory 功能?A:雖然部分 LLM 提供內建對話記憶,但對於自動化流程開發者來說,那就像一個無法受控的「黑盒子」。將 Memory 獨立存放在 Google Sheets 或資料庫中,能讓你隨時監控、修改、除錯(Debug),並確保 AI 不會產生難以追蹤的幻覺(Hallucination)。 Q:Google Sheets 適合拿來當作長期的大型資料庫嗎?A:對於新手測試、輕量級專案或概念驗證(PoC),Google Sheets 是完美且直觀的工具,因為它「視覺化且易懂」。但當你的系統上線且流量增大時,建議將 Logging 系統轉移至 PostgreSQL、MySQL 或 Supabase 等正規關聯式資料庫,以確保效能與穩定性。 Q:什麼時候才真正需要用到 Tool Calling(動態查詢)?A:當用戶的需求不確定或需要跨時間區間搜尋時。例如,當用戶問:「幫我整理『上個月』關於『商業策略』的所有新聞」,這種條件不固定的問題,Workflow 先查(固定 Context)無法預測,此時才適合讓 AI 透過 Tool Calling 自行下達條件去資料庫撈取資料。 Q:為什麼過濾歷史紀錄時要加上 status === 'success' 的條件?A:這是防止「垃圾記憶污染」的關鍵設計。如果 AI 曾因為網路錯誤、格式異常或 Token 不足而失敗,那筆紀錄的 input_text 或 summary 可能是空的或不完整的。把這些「失敗記憶」注入 AI,反而會讓 AI 困惑或輸出錯誤的摘要。只保留 success 的紀錄才能確保記憶品質。 Q:Debug History Preview 節點有什麼用?正式上線後可以刪掉嗎?A:Debug History Preview 是一個「透明窗口」節點,讓你在 n8n 執行面板中可以直接看到「AI 即將收到的歷史資料長什麼樣子」,在開發初期排查問題時非常有價值。正式上線後可保留(幾乎沒有效能開銷),作為日後維護時的快速診斷工具。若確定不再需要除錯,可刪除以精簡流程。 Q:Structured Output Parser 是什麼?為什麼要用它?A:Structured Output Parser 的作用是強制 AI 必須按照你定義的 JSON Schema 格式輸出,而不是隨意回傳文字。如果 AI 輸出不符合格式(例如缺少 summary 欄位),n8n 會自動觸發重試。這對於後續的 keywords.join('、') 等欄位操作至關重要——若格式不穩定,後面的節點就會直接報錯。 Q:category 欄位為什麼要用 enum 限制固定選項?A:這是維持資料一致性的核心手段。如果不加 enum,AI 可能今天回傳「AI 工具」、明天回傳「人工智慧工具」、後天回傳「AI Tools」,同一個意思三種寫法,導致你在 Google Sheets 篩選或後續統計時出現資料亂象。使用 enum: ["AI工具", "程式開發", "商業", "教育", "其他"] 強制統一格式,是設計健壯資料管線的基本功。 Q:為什麼要在 Log 中記錄 history_count 和 history_context?A:這是為了讓未來的你能「重現 AI 當時的視角」。假設某次 AI 回傳了奇怪的摘要,你打開 Log 可以直接看到:「當時 AI 帶了幾筆記憶(history_count)」以及「那些記憶的完整內容是什麼(history_context)」。沒有這兩個欄位,你只能看到輸出結果,完全無法判斷問題出在 Prompt、歷史資料,還是 AI 本身。 Q:Prompt 中說「若與本次輸入無關,請以本次輸入為主」,這樣真的有效嗎?A:這條規則能降低 AI 誤用歷史資料的機率,但不能完全保證。因此 System Message 中同時加入了「不可把過去內容誤當成這次輸入內容」的明確規則,雙重防護。若主題相近偶爾仍可能混淆,此時可考慮在 Prompt 中加入更明確的分隔標記(如 ---歷史紀錄開始---)來強化區隔。 Q:replyToken 是什麼?為什麼要記錄在 Log 裡?A:LINE 的 replyToken 是一個一次性、有時效的 Token(約 30 秒有效),用來對應「這次訊息的回覆權限」。HTTP Request 節點使用它呼叫 LINE Reply API 回傳訊息給使用者。記錄在 Log 中,是為了當回覆失敗時,你可以確認 Token 是否正確傳遞(雖然過了時效無法重新使用,但至少能確認資料流程正確)。 Q:如果使用者是第一次傳訊息(沒有任何歷史紀錄),流程會出錯嗎?A:不會。Build History Context 節點在 filtered.length 為 0 時,會將 history_context 設為 '無歷史紀錄' 字串,並將此值傳給 AI Prompt。AI 收到這個明確的提示後,會直接以本次輸入為唯一依據進行分析,完全不受影響。

  • article-n8n 串接 Gemini API:從基礎節點到 AI Agent 結構化輸出 | (EP.6) n8n 自動化 API 串接教學

    2026/3/30

    AI自動化 AI Agent Gemini n8n API串接
    n8n 串接 Gemini API:從基礎節點到 AI Agent 結構化輸出 | (EP.6) n8n 自動化 API 串接教學

    在 n8n 的自動化工作流中,許多人習慣使用 ChatGPT 的 AI 模型。然而,隨著 Google Gemini 系列模型的強勢崛起(尤其是具備免費額度的優勢),越來越多開發者與行銷人開始轉向使用 Gemini 來節省成本並維持高效的運算能力。 本文將帶您手把手實戰,從申請 Gemini API 密鑰開始,完整解析在 n8n 中串接 Gemini 的兩種核心做法:基礎節點搭配 JavaScript 解析,以及免寫程式的 AI Agent 結構化輸出。 如何快速取得 Google Gemini API 密鑰?要讓 n8n 成功呼叫 Gemini,我們首先需要前往開發者後台申請 API Key。 進入開發者平台:前往 Google AI Studio。 尋找申請入口:在左側選單點擊 Get API key。 建立密鑰:點選 Create API key,系統會要求您選擇或建立一個 Google Cloud 專案(Project)。如果您之前尚未建立過,可以點擊 Create project 來創建一個新專案。 選擇計費方案: 若您有綁定信用卡並啟用了付費帳單,系統可能會預設給予 Tier 1 (Postpay) 權限,這在需要呼叫「生成圖片」等進階模型時非常有用。 若您想完全免費使用,請確保專案的計費狀態設定為 Free tier,這對於一般的文本處理與自動化任務已經非常夠用。 複製密鑰:成功生成後,將這串 API Key 複製下來,準備貼到 n8n 的憑證(Credentials)設定中。 實戰方法一:透過「Message a Model」節點與 JS 解析 JSON在 n8n 中,最直覺的呼叫方式是使用原生的 Google Gemini 節點(Message a Model 操作)。但在實際應用場景中,我們通常會要求 AI 輸出特定的 JSON 格式(例如:分類、摘要、關鍵字),以便後續串接 LINE Bot 或寫入資料庫。 步驟與痛點解析 建立 Credentials:在 Message a Model 節點中,新增 Google Gemini(PaLM) API account,將剛剛複製的 API Key 貼入並儲存。 設定 Prompt 與 System Message:在 Node 設定中,您可以要求它輸出 JSON,並開啟 Output Content as JSON 選項。 痛點(為何需要 Code 節點):即使勾選了輸出 JSON,Gemini 原生節點回傳的資料結構往往被包裝在一大包 JSON 陣列內(無法像 ChatGPT 節點那樣直接完美對應輸出規格)。 JavaScript 解析解法:為了解決這個問題,我們必須在後面加上一個 Code 節點,透過 JavaScript 將純文字轉換並萃取出我們需要的欄位。 Code 節點解析範例: 12345678910111213141516const raw = $json.content?.parts?.[0]?.text ?? '';let parsed;try { parsed = JSON.parse(raw);} catch (error) { parsed = { summary: '', category: '其他', keywords:[], language: 'zh-TW' };}return [{ json: parsed }]; 透過上述程式碼,我們才能確保後續的 HTTP Request 節點(例如推播 LINE 訊息)能正確讀取到 summary、category 與 keywords 等變數。這對於不熟悉程式碼的用戶來說,門檻相對較高。 實戰方法二:使用 AI Agent 輕鬆達成結構化輸出(專家推薦)為了避開繁瑣的程式碼解析,強烈建議使用 n8n 的 AI Agent 架構。透過「Agent + Model + Output Parser」的黃金三角,您可以讓系統自動將 Gemini 的輸出鎖定在嚴格的 JSON 規格內。 完美輸出的配置步驟: 加入 AI Agent 節點:在畫布中新增 AI Agent,並將輸入源連接至前置節點。 **連接語言模型 (Language Model)**:在 Agent 的 Model 輸入端,掛載 Google Gemini Chat Model 節點,並選定模型(如 gemini-2.5-flash)。 **強制結構化輸出 (Output Parser)**: 開啟 Agent 節點內的 Require Specific Output Format。 在 Parser 輸入端掛載 Structured Output Parser 節點。 在 Parser 內直接定義您期待的 JSON Schema(如下方範例)。 JSON Schema 定義範例: 1234567891011121314151617{ "type": "object", "properties": { "summary": { "type": "string" }, "category": { "type": "string", "enum":["AI工具", "程式開發", "商業", "教育", "其他"] }, "keywords": { "type": "array", "items": { "type": "string" } }, "language": { "type": "string" } }, "required":["summary", "category", "keywords", "language"], "additionalProperties": false} 使用 AI Agent 搭配 Structured Output Parser 的最大優勢在於:完全免寫任何一行解析用的 JavaScript 程式碼!系統會嚴格逼迫 Gemini 依照您提供的 Schema 回傳乾淨、格式化好的 JSON,極大地提升了工作流的穩定性與開發效率。 附錄:完整 n8n 工作流 JSON您可以直接複製以下 JSON 匯入您的 n8n 畫布中進行測試: { "nodes":[ { "parameters": { "promptType": "define", "text": "=請讀取以下內容,輸出摘要、主題分類、3 個關鍵字。\n\n內容:\n{{$json.input_text}}", "hasOutputParser": true, "options": { "systemMessage": "你是資料整理助手。\n\n規則:\n1. 使用繁體中文。\n2. 不要捏造未提供的資訊。\n3. 請只輸出 JSON。\n4. 欄位必須包含 summary、category、language。\n5. 若資訊不足,也必須輸出合法 JSON。" } }, "type": "@n8n/n8n-nodes-langchain.agent", "typeVersion": 3.1, "position":[352, -352], "name": "AI Agent" }, { "parameters": { "options": {} }, "type": "@n8n/n8n-nodes-langchain.lmChatGoogleGemini", "typeVersion": 1, "position":[288, -144], "name": "Google Gemini Chat Model" }, { "parameters": { "schemaType": "manual", "inputSchema": "{\n \"type\": \"object\",\n \"properties\": {\n \"summary\": { \"type\": \"string\" },\n \"category\": {\n \"type\": \"string\",\n \"enum\":[\"AI工具\", \"程式開發\", \"商業\", \"教育\", \"其他\"]\n },\n \"keywords\": {\n \"type\": \"array\",\n \"items\": { \"type\": \"string\" }\n },\n \"language\": { \"type\": \"string\" }\n },\n \"required\":[\"summary\", \"category\", \"keywords\", \"language\"],\n \"additionalProperties\": false\n}" }, "type": "@n8n/n8n-nodes-langchain.outputParserStructured", "typeVersion": 1.3, "position":[544, -128], "name": "Structured Output Parser" } ], "connections": { "Google Gemini Chat Model": { "ai_languageModel": [[{"node": "AI Agent","type": "ai_languageModel","index": 0}]] }, "Structured Output Parser": { "ai_outputParser": [[{"node": "AI Agent","type": "ai_outputParser","index": 0}]] } } } 常見問答 (FAQ)Q:為何在 n8n 中選擇使用 Gemini 而不用 ChatGPT?A:主要優勢在於成本與免費額度。Google AI Studio 提供了非常慷慨的 Free tier(免費層),對於剛開始建置自動化工作流、或需求量在中小型範圍的用戶來說,可以大幅降低 API 的呼叫成本,同時 Gemini 2.5 Flash 處理速度極快,非常適合自動化場景。 Q:為什麼使用基礎的「Message a Model」節點還需要額外寫程式碼?A:因為基礎的 LLM 節點雖然能設定輸出 JSON,但往往會包裝在複雜的結構層級中,無法直接無縫對接下一個節點的變數欄位。透過加入 JavaScript Code 節點進行 JSON.parse() 解析,才能精準拆解出所需的鍵值(Keys),讓後續推播或寫入資料庫的動作不出錯。 Q:如果不擅長寫程式,有什麼替代方案嗎?A:強烈建議採用本文示範的 AI Agent + Structured Output Parser 方法。這種架構屬於「宣告式」操作,您只需要在介面上填寫 JSON 格式規範(Schema),n8n 與 AI 就會自動溝通並轉換出完美對應的資料格式,徹底免除撰寫解析程式碼的困擾。 Q:Google Gemini 的免費額度真的夠做 n8n 自動化嗎?A:對大多數入門情境來說,通常夠用。若您的工作流主要是做摘要、分類、標籤整理、客服訊息初步回覆,Free tier 往往已足以支撐測試與小量正式使用。不過如果您開始大量處理長文本、頻繁排程,或同時有多個工作流共用同一組 API Key,就需要留意速率限制與用量上限。最穩健的做法是先用免費層把流程跑通,再依實際流量決定是否升級付費方案。 Q:什麼情況下該用「Message a Model」,什麼情況下該直接改用 AI Agent?A:如果您的任務只是單純的一進一出,例如摘要、翻譯、分類、改寫,且後面只要接一個 Code 節點就能順利整理資料,那麼 Message a Model 通常更簡單、成本也更低。但如果您已經明確知道後面要依賴固定欄位,例如 summary、category、keywords 去串接 LINE、Email、Sheets 或資料庫,那麼直接使用 AI Agent + Structured Output Parser 會更穩定,後續維護也更省力。 Q:為什麼我明明要求 Gemini 輸出 JSON,結果還是會多出說明文字或格式錯誤?A:因為單靠 Prompt 約束,模型仍可能在某些情況下額外補充說明,尤其當輸入內容較長、規則較複雜,或模型判斷需要「解釋」時更容易發生。這也是本文會把兩種方法拆開講的原因:如果您走基礎節點路線,就要準備用 Code 節點做容錯解析;如果您要的是更高穩定性,就應直接改走 Structured Output Parser,把格式控制交給系統,而不是只靠文字要求。 Q:匯入本文附錄的工作流 JSON 後,還需要手動修改哪些地方?A:需要,因為附錄的 JSON 是示範骨架,不是可直接上線的最終版本。至少要檢查三個地方:第一,Google Gemini Chat Model 是否已綁定您的 Gemini API Credential;第二,前置節點是否真的有提供 input_text 這個欄位;第三,後續節點若要讀取 Agent 的結果,是否使用正確路徑,例如 output.summary、output.category、output.keywords。如果其中任何一個欄位名稱對不上,流程就很容易出現空值或報錯。 Q:如果我的 JSON Schema 定義得太嚴格,會不會反而讓模型常常失敗?A:會有這種可能,尤其當您同時要求太多欄位、限制太多列舉值,或輸入內容本身資訊不足時。實務上建議 Schema 先維持「夠用就好」:只保留後續流程真正會用到的欄位,避免一開始就設計過多可有可無的結構。對自動化工作流來說,穩定輸出 4 個必要欄位,通常比一次追求 10 個欄位更有價值。 Q:如果後面我要把 Gemini 的結果寫進 Google Sheets、Notion 或資料庫,最重要的注意事項是什麼?A:最重要的是欄位名稱與值域要先標準化。不要讓模型今天輸出 AI工具、明天輸出 AI 工具、後天又輸出 AI Tool。一旦分類名稱不一致,後面做搜尋、篩選、儀表板統計都會變得很麻煩。因此像本文示範的 enum 設計就非常重要,它不是為了形式好看,而是為了確保資料落地後仍然可被穩定使用。

  • article-n8n AI Agent 結合 chatgpt model 與 JSON Schema 打造會思考的自動化工作流 | (EP.4) n8n 自動化 API 串接教學

    2026/3/27

    AI自動化 AI Agent ChatGPT n8n API串接
    n8n AI Agent 結合 chatgpt model 與 JSON Schema 打造會思考的自動化工作流 | (EP.4) n8n 自動化 API 串接教學

    如何將基礎 LLM 升級為強大的 AI Agent?在先前的 n8n 實作中,我們常用 Message a model 來處理 OpenAI API 的回覆。但只要流程開始牽涉到結構化輸出、節點串接穩定性、或後續還要交給其他系統使用,單純文字回覆通常很快就會碰到限制。 這次的做法不是只讓模型「回答問題」,而是讓它在 n8n 裡扮演一個可控的 AI Agent。搭配 Structured Output Parser 與 JSON Schema 之後,模型不只會回覆內容,還能穩定產出指定欄位,讓後面的 HTTP Request 節點可以直接把結果送進 LINE Bot 或其他 API。 如果你正在做的是「收到訊息 -> AI 分析 -> 結構化結果 -> 推播到外部服務」這種流程,那麼 AI Agent 會比一般對話節點更適合。 實作步驟:如何快速完成環境與節點部署?1. 建立工作流基本骨架根據附加的工作流 JSON,這個範例的核心節點順序如下: Webhook -> Edit Fields -> AI Agent -> HTTP Request 另外 AI Agent 下方還會再掛兩個擴充節點: OpenAI Chat Model Structured Output Parser 實作時可以照這個順序建立,會比較不容易接錯線。 2. 先用 Edit Fields 整理輸入資料這個範例不是直接把 LINE Webhook 的整包 JSON 丟給 AI,而是先透過 Edit Fields 抽出真正要分析的文字: 1{{ $json.body.events[0].message.text }} 並且將它命名為: 1input_text 這一步很重要,因為它可以讓後續提示詞更乾淨,也能降低你在 AI Agent 中直接處理深層 JSON 路徑的複雜度。 3. 配置 AI Agent 的提示詞與系統設定進入 AI Agent 的設定畫面,我們需要定義它的角色與任務: 設定 System Message:在 Options 中加入 System Message,建立固定規則。 設定 User Message:在 Prompt (User Message) 中用 Expression 模式動態帶入前一節點的資料。 這份工作流實際使用的 User Message 可整理成: 1234請讀取以下內容,輸出摘要、主題分類、3 個關鍵字。內容:{{$json.input_text}} System Message 的設計重點則是: 12345678你是資料整理助手。規則:1. 使用繁體中文。2. 不要捏造未提供的資訊。3. 請只輸出 JSON。4. 欄位必須包含 summary、category、language。5. 若資訊不足,也必須輸出合法 JSON。 如果你只是想讀取前一節點整理好的文字,也可以記住最核心的變數寫法: 1{{ $json.input_text }} 實作提醒:一定要切到 Expression 模式。若你停留在 Fixed,n8n 會把 `{{$json.input_text}}` 當成純文字,而不是變數。 4. 結合 Structured Output Parser 實現 JSON 格式化為了讓 AI 的輸出能被後續的 HTTP Request(例如發送到 LINE)完美讀取,我們必須規範它的輸出格式: 點擊 AI Agent 下方的 Output Parser 擴充節點,選擇 Structured Output Parser。 將 Schema Type 設為手動定義 JSON Schema。 使用標準 JSON Schema 來限制欄位格式。根據附加檔案,這次實作的 Schema 如下:1234567891011121314151617{ "type": "object", "properties": { "summary": { "type": "string" }, "category": { "type": "string", "enum": ["AI工具", "程式開發", "商業", "教育", "其他"] }, "keywords": { "type": "array", "items": { "type": "string" } }, "language": { "type": "string" } }, "required": ["summary", "category", "keywords", "language"], "additionalProperties": false} Schema 設計重點解析: **enum**:限制 category 只能從預定義的分類中選擇,避免 AI 自由發揮產生不一致的分類名稱。 keywords 陣列:讓 AI 自動提取 3 個關鍵字,方便後續做資料標籤或搜尋索引。 **required**:強制所有欄位都必須存在,防止 AI 漏掉任何一個欄位。 **additionalProperties: false**:禁止 AI 額外輸出未定義的欄位,確保 JSON 結構乾淨一致。 5. 串接 OpenAI Chat ModelAI Agent 就像一個大腦,需要連接特定的語言模型才能運作: 點擊 AI Agent 下方的 Chat Model 擴充節點。 搜尋並選擇 OpenAI Chat Model。 在模型設定中選擇對應模型版本。本次附加檔案使用的是: 1gpt-5-mini 如果你的任務是摘要、分類、關鍵字提取這類結構化整理工作,先從成本較低、速度較快的模型開始,通常就很夠用了。 6. 修正 HTTP Request 節點的輸出參數這是升級 AI Agent 後最容易踩雷的地方。因為節點改成 AI Agent 之後,輸出物件不再和原本 Message a model 一樣,後面的 HTTP Request 若仍沿用舊路徑,就很容易送出空值或直接報錯。 根據附加檔案,HTTP Request 送往 LINE Reply API 時,正文內容是從 output 物件裡取值,因此你至少要重新綁定以下欄位: 摘要:`{{ $json.output.summary }}` 分類:`{{ $json.output.category }}` 語言:`{{ $json.output.language }}` 若你也想把關鍵字一起送出去,可以再補上: 關鍵字:`{{ $json.output.keywords.join('、') }}` 另外,附加工作流中的 LINE 訊息模板有一個小細節值得注意:欄位名稱寫成了 languag,如果你要正式發布,建議順手改成 language,避免訊息文字看起來像拼字錯誤。 完成變數重綁後,執行 Execute workflow 測試,理想狀況下你就能在 LINE 收到一段由 AI 產生、而且格式固定的摘要結果。 觀念解析:一般模型 (Message a model) vs. AI Agent 差異在哪?為什麼我們不繼續用原本的 Message a model,而要大費周章換成 AI Agent?這兩者雖然看起來都是處理文字,但運作底層完全不同: 比較維度 一般對話模型 (Message a model) AI Agent 處理邏輯 **線性直出 (Linear)**:輸入問題 $\rightarrow$ 產出解答 $\rightarrow$ 結束。 **循環思考 (Loop)**:接收任務 $\rightarrow$ 思考 $\rightarrow$ 調用工具 $\rightarrow$ 驗證 $\rightarrow$ 產出。 擴充能力 僅能單純處理文字生成與回覆。 可串接多種工具 (Tools)、資料庫或記憶庫 (Memory)。 Token 消耗 極低(省錢),適合簡單明確的任務(如翻譯、改寫)。 較高(耗費 Token),因為會進行多次內部對話與工具反覆確認。 顧問建議:如果你的任務只是單純改寫、翻譯、生成一段文字,Message a model 通常更省成本;但如果你需要穩定輸出結構、後續還要串 API、或未來準備接工具與記憶能力,直接用 AI Agent 會更有擴充性。 常見問答 (FAQ)一、節點設定與資料流Q:為什麼這個流程要先用 Edit Fields,不能直接把 Webhook 內容丟進 AI Agent 嗎?A:可以直接丟,但不建議。LINE Webhook 的 JSON 通常層級較深,若直接在提示詞裡寫 `{{$json.body.events[0].message.text}}`,可讀性與維護性都比較差。先用 Edit Fields 把資料整理成 input_text,後續提示詞會更乾淨,也更容易除錯。 Q:AI Agent 的 Prompt 為什麼一定要切成 Expression?A:因為你要讀的是前一個節點動態傳入的值。若使用 Fixed,n8n 會把 `{{$json.input_text}}` 當成一般字串,而不是變數,模型收到的就不是實際訊息內容。 Q:系統提示詞已經寫「請只輸出 JSON」了,為什麼還要加 Output Parser?A:因為提示詞只是要求,Parser 才是約束。只靠提示詞,模型仍可能偶爾多說一句說明文字;加上 Structured Output Parser 與 JSON Schema,才比較能把輸出鎖定在你要的欄位結構內。 二、Structured Output 與 JSON SchemaQ:JSON Schema 裡的 required 和 additionalProperties: false 有什麼差別?A:required 是規定哪些欄位一定要出現;additionalProperties: false 是禁止模型額外加出沒定義的欄位。兩者一起用,才能同時做到「不能漏欄位」與「不能亂加欄位」。 Q:category 為什麼要用 enum?A:因為分類欄位很容易失控。若不限制,模型可能一下輸出「商業應用」、一下輸出「商務」、一下又寫「創業」,後續做篩選、分析或寫入資料庫時就會很麻煩。用 enum 能把分類名稱固定下來。 Q:keywords 是陣列,實際發送 LINE 訊息時要怎麼顯示?A:如果 LINE 訊息需要純文字顯示,可以把陣列轉成字串,例如: 1{{ $json.output.keywords.join('、') }} 這樣收到的訊息會比較適合一般使用者閱讀。 三、常見錯誤與除錯Q:為什麼把一般模型換成 AI Agent 後,最後的 HTTP Request 會報錯或變成空值?A:最常見原因就是資料路徑改了。切換成 AI Agent 後,輸出通常會包在 output 物件中,所以你原本綁的欄位若不是 `{{ $json.output.summary }}` 這類新路徑,就會抓不到值。 Q:如果 AI 回傳格式仍然不穩,應該先檢查哪裡?A:先檢查三件事: Structured Output Parser 是否真的接在 AI Agent 的 ai_outputParser 連線上。 JSON Schema 是否為合法格式,尤其是括號、逗號與 required 欄位名稱。 System Message 是否和 Schema 衝突,例如提示詞要求輸出欄位和 Schema 定義不一致。 Q:附加工作流裡 LINE 訊息的欄位名稱出現 languag,這會影響流程嗎?A:不會影響資料抓取,因為真正取值仍然是 `{{ $json.output.language }}`。但它會讓使用者在 LINE 看到拼字錯誤,所以建議改掉,這屬於顯示層的細節修正。 四、模型選擇與使用時機Q:這種摘要與分類工作,適合用哪一種模型?A:如果需求是摘要、分類、關鍵字提取、標籤整理這種中低複雜度任務,先用輕量模型通常最划算。像附加檔案採用的 gpt-5-mini,就很適合作為第一版驗證。 Q:什麼情況下我應該直接用 AI Agent,而不是 Message a model?A:當你符合以下其中一種情況,就很適合改用 AI Agent: 你需要穩定的 JSON 結構輸出。 你後面還要串接 API、資料庫或聊天平台。 你未來可能會加上工具調用、知識庫檢索或多步驟判斷。 如果只是一次性生成文字,Message a model 仍然比較省錢也比較簡單。

  • article-何時該用 LLM?何時該派 AI Agent 上場? | (EP.2) n8n 自動化 API 串接教學

    2026/3/26

    AI自動化 AI Agent n8n API串接
    何時該用 LLM?何時該派 AI Agent 上場? | (EP.2) n8n 自動化 API 串接教學

    在建立 n8n 的自動化工作流時,許多新手都會遇到一個核心痛點:畫面上同時有 LLM 節點和 AI Agent 節點,到底該拉哪一個? 如果你習慣將所有任務都塞給 AI Agent 處理,你可能會面臨 Token 費用暴增、執行流程不穩定,甚至是難以 Debug 的地獄。這篇文章將帶你深度解析 LLM 與 AI Agent 的本質差異,並教你如何針對不同的戰場,選擇最適合的自動化武器。 💡 核心對決:LLM 與 AI Agent 的本質差異在哪裡?要理解兩者的差異,我們可以用最簡單的「積木(Function)」概念來看: LLM (大型語言模型): 本質上它**只有一個大腦 (Model)**。它採取一問一答的線性模式(你問 → 他回),完全處於被動狀態。 AI Agent (智能體): 除了大腦 (Model) 之外,它還具備了 記憶 (Memory) 與 **工具箱 (Tools)**。它能夠根據你的目標,自主啟動 ReAct(理解目標 ➔ 規劃步驟 ➔ 呼叫工具 ➔ 檢查結果)的多步推理解迴路,直到任務完成。 🧠 為什麼 90% 的場景你只需要 LLM?(省錢又穩定)許多新手在初學 n8n 時,容易陷入「凡事皆用 Agent」的誤區。事實上,在日常的自動化任務中,有高達 90% 的時間你只需要使用單純的 LLM 節點。 適合 LLM 處理的任務特徵: 流程固定: 擁有明確的輸入(Input)與輸出(Output)。 純文字處理: 例如資料摘要、語言翻譯、語意分類(客訴情緒判斷)。 生成結構化資料: 幫你打草稿、生成 Email 內容、或是轉換成特定格式(JSON、SQL)。 LLM 的絕對優勢: 超便宜: 只要 Prompt 寫好,一次呼叫就解決,Token 消耗極低。 超好 Debug: 流程固定,出錯時一眼就能看出是哪個環節的問題。 可控性極高: 嚴格遵循你的指令,不會有意外的自主決策。 🦸‍♀️ 何時才需要派 AI Agent 上場?(處理不確定任務)如果你今天的任務沒有固定的標準流程,且需要「動態決策」或「與外部系統互動」,這時才是 AI Agent 發揮價值的舞台。 適合 AI Agent 處理的任務特徵: 不確定的流程: 無法事先寫死所有的判斷條件。 需要多步驟決策: 遇到問題需要反覆思考並修正。 依賴外部工具: 例如自動查訂單資料庫、上網搜尋最新資訊、或是直接操作 API 發送郵件。 ⚠️ 新手防坑警告:拜託不要濫用 Agent!AI Agent 雖然聰明,但會帶來高昂的代價。它在思考與嘗試的過程中會消耗大量 Token(成本直接爆炸),且由於具備自主決策權,非常容易產生「幻覺 (Hallucination)」導致過度行動。如果出錯,因為思考邏輯成謎,Debug 的難度將會非常高。 鐵則:能用 LLM 解決的問題,就絕對不用 Agent! 🏗️ 大師級實戰架構:如何打造「黃金混合生產線」?在實戰中,最強的架構不是全用 Agent,也不是全用 LLM,而是將兩者混搭,各司其職。我們以「智能客服工作流」為例: 讓 Agent 當「廠長」負責決策 (Decision):接收到客戶訊息後,由 AI Agent 判斷「是否需要回覆?」。如果需要,Agent 會決定去 Database 調出這筆訂單資料。 讓 LLM 當「作業員」負責處理 (Process):將訂單資訊與客訴內容交給純 LLM 節點,請它專心撰寫一封語氣誠懇的安撫 Email(生成內容)。 讓 Tools 當「輸送帶」確實執行 (Execute):最後,將 LLM 寫好的信件交給常規的 HTTP / Gmail 節點(不需要 AI),單純負責把信件送出。 這樣一來,Agent 不需要浪費 Token 去寫信,LLM 也不需要負擔決策的壓力,整個 n8n 流程既聰明、穩定又省錢! 常見問答 (FAQ)Q:為什麼我在 n8n 中使用 AI Agent 執行任務,費用會突然暴增?A:因為 AI Agent 具備「ReAct(推理與行動)」機制。為了解決一個問題,它會在背後不斷自我對話、反覆呼叫工具並驗證結果,每一次的內部迴圈都會消耗大量的 Token。如果沒有嚴格限制它的行動次數或提供精確的 Prompt,成本就會直線上升。 Q:我該如何決定一個新流程要用 LLM 還是 Agent?A:你可以問自己兩個問題:第一,「這個任務的流程是否固定不變?」第二,「任務需要自行判斷並呼叫外部工具來查資料嗎?」。如果流程固定且只需純文字轉換,請召喚 LLM;如果需要多重判斷與操作工具,再指派 Agent。 Q:如果我的 AI Agent 流程一直報錯,該如何優化?A:遇到 Agent 報錯或產生幻覺,首要之務是「把它牢牢限制住」。你可以在 System Prompt 中給予極度明確的目標與角色設定,限制其最大思考與行動次數,並確保給予的 Tools (工具箱) 只有它絕對需要的工具,避免它漫無目的地亂猜。若還是難以 Debug,建議將複雜流程拆解,改用「Agent 決策 + LLM 執行」的黃金混合架構。

  • article-SaaS 的下一站?深度解析 Agent-as-a-Service (AaaS) 如何重新定義企業軟體

    2026/3/20

    商業策略 AI自動化 AI工具 AI Agent
    SaaS 的下一站?深度解析 Agent-as-a-Service (AaaS) 如何重新定義企業軟體

    這幾年大家很習慣用 SaaS 來理解企業軟體。你買 CRM、買 ERP、買 Helpdesk、買行銷自動化平台,本質上都是買一套可以被操作的系統。資料放進去、流程建起來,再由人去點按鈕、查資訊、跑報表、送審核、追進度。說穿了,SaaS 賣的是工具。 但 AI Agent 的出現,正在慢慢改變這件事。 未來企業採購的,可能不再只是「一套讓員工操作的軟體」,而是「一個能自己理解任務、自己呼叫工具、自己執行流程、必要時再請人核准的數位工作者」。這種模式,可以叫做 Agent-as-a-Service (AaaS)。它不是單純把聊天機器人換個名字而已,而是企業軟體邏輯的一次根本轉向:從賣功能,變成賣結果。 為什麼說 SaaS 賣介面,而 Agent 賣的是「工作能力」?我們先把差異講清楚。 在 SaaS 時代,人是流程的中心。系統提供介面,員工負責操作。你要查客戶資料,自己進 CRM;你要處理請款,自己比對發票、訂單和驗收單;你要安排面試,自己來回寄信、協調時段、更新系統狀態。 Copilot 時代往前走了一步。AI 會幫你摘要、寫初稿、提出建議,但主導權還是在人手上。它像副駕,會提醒你、幫你補齊,但方向盤還是你在握。 到了 Agent-as-a-Service 時代,邏輯徹底不同了。人不再負責一個個步驟地操作系統,而是直接下達目標: 「幫我準備這個客戶的續約會議。」 「幫我處理這批請款。」 「幫我找出最近結帳 (Checkout) 變慢的原因並提出修正。」 接著由代理自己拆解任務、選用工具、執行流程,最後再把結果交回來,或是在關鍵節點請你核准。這時候你買的不是 CRM、不是 ERP 外掛、不是 Chatbot,而是某種可交付工作成果的能力。 一句話總結:SaaS 賣的是工具介面,Agent-as-a-Service 賣的是可衡量的工作成果。 AI 補足了「行動力」:從回答器進化為執行者為什麼這件事現在開始變得真實?因為過去幾年,AI 最缺乏的是「行動能力」。 大型語言模型 (LLM) 很會寫、很會總結、很會回答問題,但它本來不會真的做事。它可以告訴你怎麼報帳,卻不能幫你進系統送出;可以幫你草擬客服回覆,卻不能自己查訂單、發退款;可以幫你整理會議重點,卻不能主動幫你排下次會議、更新 CRM。 而 Agent 的核心,正是把這些能力補上。現在的代理系統,通常開始具備以下特徵: 目標理解:能理解較高階的目標,不只回單一問題。 任務拆解:能把一件事拆成多個步驟。 工具整合:能呼叫外部工具與 API。 上下文串聯:能讀文件、查知識庫、整合上下文。 記憶留存:能保留短期或長期記憶。 分工協作:能在多個代理之間分工合作。 安全卡控:能在高風險步驟加入核准與限制。 這讓 AI 從「回答器」慢慢變成「執行者」。無論是 NVIDIA 提出的 Agentic AI、Microsoft 的完整 Workflow 執行,還是 Salesforce 包裝的 Agentic Enterprise,都指向同一件事:企業軟體的價值,開始從 UI 轉移到自動完成工作。 10 個 Agent-as-a-Service 顛覆企業流程的真實應用場景要理解 AaaS 的威力,我們可以從企業中最常見的 10 個職能來看: 1. 客服代理 (Customer Service Agent)客戶說:「訂單還沒到,我想取消。」Agent 能自己查狀態、確認規則、發退款、寄通知,只在超出權限時才轉交真人。企業買的不再是客服介面,而是處理一線任務的服務。 2. IT 支援代理 (IT Helpdesk Agent)員工說:「VPN 壞了。」代理會先驗證身分,檢查裝置狀態、重設憑證、建立 Ticket 並通知管理員。它不是單純回答 FAQ,而是直接執行 IT SOP。 3. 業務代理 (Sales Agent)下達指令:「幫我準備 A 客戶續約會議。」代理會去抓 CRM 紀錄、整理未解決問題、估算流失風險、做簡報初稿並順手排會。你買的是「續約推進能力」。 4. 財務與採購代理 (Finance & Procurement Agent)代理自動比對 PO、發票與驗收單,抓出重複請款或異常金額。低風險自動送審,高風險交主管。這是在處理真正的交易流程,而非只是產出報表。 5. 招募代理 (Recruiting Agent)從讀履歷、排序候選人、寄邀約、協調面試到整理下一輪建議,整條招募鏈路都能由代理協助執行。它是「招募流程專員」,而不僅是 HR 工具。 6. 行銷代理 (Marketing Agent)設定目標:「下週為這篇文章帶來 300 個 Demo Leads。」代理自己拆解策略、寫文案、分眾投放、監測 CTR/CVR、調整預算並每日回報。企業買的是「投放成果」。 7. 工程代理 (Engineering Agent)指令:「找出 Checkout 變慢的原因,修掉並開 PR。」代理會翻 Git 歷史、看 Logs、跑 Benchmark、定位問題並建立 PR。此時 UI 只是監督面板,價值在於解決問題。 8. 法務代理 (Legal Agent)代理能初步審查 NDA、MSA,標記風險條款、比對標準條文並提出紅線 (Redline) 建議。買的不是文件管理系統,而是「初階合約審查服務」。 9. 供應鏈代理 (Supply Chain Agent)監測缺料風險、預測延遲、模擬替代料件、重新計算排程並通知廠端。它不只是儀表板 (Dashboard),而是供應鏈的協調者。 10. 個人幕僚代理 (Personal Assistant Agent)整理郵件、追 Deadline、摘要會議、建立部落格草稿、安排日程,並記住你的偏好。你是在培養一個數位幕僚,而不是使用一個聊天視窗。 揮別單一大腦:多代理協作 (Multi-Agent) 才是未來企業架構真正有意思的地方,不是單一超級代理,而是多代理協作。 企業裡本來就不是只有一種角色,客服、財務、法務各有不同工具與權限。未來更合理的型態,不是一個全知全能的大腦,而是: 前台代理:負責跟人互動。 流程代理:負責執行 SOP。 資料代理:負責查詢、驗證、彙整。 審核代理:負責風險與合規。 協調代理:負責派工與整體規劃。 這樣的系統看起來就像一間虛擬公司。人類不會消失,而是從「逐步操作系統」轉變為「設定目標、管理例外、監督結果」。 Agent 會吃掉 SaaS 嗎?系統架構的四層演進AI 會殺死 SaaS 嗎?答案是:不會完全取代,但一定會重組。 SaaS 會從前台產品,慢慢退居為 Agent 背後的基礎設施。因為很多 SaaS 的真正價值,原本就不是 UI 本身,而是背後的資料模型、商業規則、權限設計與 API。未來的系統演進會呈現四個層次,一層疊一層: System of Record:記錄資料 (傳統資料庫/核心系統)。 System of Workflow:讓人跑流程 (傳統 SaaS/BPM)。 System of Intelligence:提供建議 (Copilot 輔助)。 System of Action:直接執行工作 (Agent-as-a-Service)。 Agent 不是把所有系統砍掉重練,而是坐在它們上面,變成全新的「操作層」。 企業導入的真正痛點:治理、權限與人機協作很多人談 Agent 時只關注模型推理能力。但企業實際上線時,最痛的往往是以下幾點: 權限控管:代理到底能不能改資料、退費或碰付款?權限設計是核心。 **可追蹤性 (Auditability)**:它為何做這決策?用了哪些工具?在哪裡失敗? 成本控制:多步推理與工具呼叫都是成本。Token 花費、延遲與重試都會變成營運議題。 人機分工:哪些全自動?哪些半自動?哪些必須人工核准? 短期內,最現實的落地形態通常是:半自動代理 + 明確權限邊界 + 關鍵節點人工核准 + 完整 Audit Log。 產品設計的重點將從「操作介面」轉向「可被代理使用的系統」與「讓人監督代理的介面」。 開發者與商業模式的雙重典範轉移Agent-as-a-Service 不僅改變技術,也將重寫企業軟體的計價方式。 傳統 SaaS 多為按人頭訂閱 (Seat-based)。但如果工作主要是 Agent 在做,更合理的收費方式可能會變成: 基本授權費 + 每月代理執行次數 每完成一筆任務/Ticket 收費 每產出某種可驗證結果收費 產品經理將不再只盯著 DAU,而是關注「代理完成了多少工作」、「自動化率是否提升」、「錯誤成本是否可控」。AaaS 其實很像把 B2B SaaS 推向更接近顧問服務或流程外包 (BPO) 的方向,只是執行者變成了 AI。 結語:迎接「數位員工」的新時代SaaS 的核心是讓人更有效率地操作系統;AaaS 的核心則是讓系統直接替人完成工作。 這不表示人會消失,而是人的角色將往上提升:成為定義目標、監督風險、做最後判斷的管理者。企業採購的項目,也將從單純的「軟體授權」,進化為「可被管理、可穩定交付成果的數位工作能力」。在 Agent 時代,SaaS 依然存在,但它可能不再是舞台中央唯一的主角了。 常見問答 (FAQ)Q:企業導入 Agent-as-a-Service 會完全取代現有的 SaaS 系統嗎?A:不會。SaaS 不會消失,而是會「退居幕後」成為 Agent 的基礎設施。SaaS 系統內建的資料模型、權限與 API 將成為 AI 執行的基石,人類直接操作介面的頻率會降低,取而代之的是透過 Agent 來呼叫這些系統完成工作。 Q:目前 AI Agent 落地企業最關鍵的挑戰是什麼?A:最大的挑戰並非 AI 模型的聰明程度,而是「治理與安全」。包括精細的權限控管(Agent 能不能碰付款)、可追蹤性(決策過程是否留存稽核軌跡)、成本控制(Token 花費)以及人機分工的界線(關鍵決策需人工介入核准)。 Q:Agent-as-a-Service 會如何改變現有軟體的計價模式?A:它將顛覆傳統 SaaS 按人頭計費(Seat-based)的模式。未來的計價將更傾向「按工作成果(Outcome-based)」或「按任務執行次數(Task-based)」收費,企業實質上是在為 AI 代理交付的商業價值與自動化率買單。

  • article-從提示詞到 Skill:5 個實務做法打造高效率 AI 自動化工作流

    2026/3/20

    AI自動化 AI工具 AI Agent
    從提示詞到 Skill:5 個實務做法打造高效率 AI 自動化工作流

    為什麼你的「萬能提示詞」越來越不管用?很多人剛開始接觸 AI 自動化時,習慣用一大段提示詞(Prompt)把整個流程包起來:角色設定、執行步驟、輸出格式、限制條件,全部塞進同一段文字裡。初期這樣做很直覺,只要 Prompt 寫得夠完整,確實能產出不錯的結果。 但隨著自動化工作流變長、變複雜,你會發現:提示詞可以完成單一任務,卻無法穩定承擔完整的工作流。 這通常不是因為 AI 模型不夠聰明,而是你把太多不同層級的要求,全綁死在同一段文字裡了。 這會導致三個致命的痛點: 產出不穩定: 同一段提示詞換了一份輸入資料,AI 的理解方式可能就跟著變。你以為交代的是嚴謹的 SOP,AI 卻常常在「臨場發揮」。 缺乏靈活度: 流程中只要有一個小環節需要微調(例如:先摘要再分頁,改成先抽重點再套模板),整份 Prompt 就牽一髮動全身,極難修改。 維護成本高昂: 每次執行任務都要把相同的規則、格式、限制重新輸入一次,不僅浪費 Token 算力與上下文空間,也讓後續的調整變得異常笨重。 破解迷思:Skill 真的只是「提示詞升級版」嗎?從自動化工作流的角度來看,Prompt 比較像「一次性的流程描述」,而 Skill 則是「可按需調用的任務模組」。 很多人誤以為 Skill 只是把 Prompt 寫得更長、包裝得更完整,再塞幾個範例進去。這其實還是停留在「提示詞升級」的思維。 真正的本質差異在於: Prompt 是把所有要求塞進一段話。 Skill 是把不同性質的要求,拆解成不同的功能模組。 以前你可能會寫出這樣的「大雜燴」指令: 123456你是一位專業教案設計師(角色設定)幫我讀這份教材(任務目標)先摘要、再切段、再產生簡報(處理步驟)每頁 3–5 行(格式規則)優先保留案例、不要太像 AI(風格限制)最後輸出 markdown(輸出模板) 這段指令能運作,但資訊全混在一起。Skill 的價值,就是將這些層級俐落拆分。例如: 任務與使用時機: 放進 SKILL.md 格式與品質規則: 歸檔於 references/ 輸出骨架: 建立在 templates/ 前處理與機械式整理: 交給 scripts/ 修正經驗與檢核重點: 累積在 logs/ 或 checklists/ 透過模組化拆分,AI 不需要每次都重新消化整包複雜規則,流程也不需要因為微調而整包重寫。這才是具備長期維護價值的自動化工作流。 實戰教學:從 Prompt 走向 Skill 的 5 大核心策略如果你手邊已經有一堆 Prompt 在跑流程,不需要全部推翻重來。建議逐步將裡面重複、固定、機械式的部分抽離出來。以下是 5 個最容易落地的做法: 1. 抽離固定規則:建立專屬的 Rule 文件很多 Prompt 越寫越長,是因為你一直在重複交代「長期成立的原則」(例如:每頁一個重點、避免長段落、不要照抄原文)。 這些內容不該佔用每次對話的篇幅,應該抽成獨立的規則檔。例如建立一份 references/slide_rules.md。未來只要涉及簡報整理任務,直接讓 AI 讀取這份規則即可。 專家心法: 將不常變動的原則,從「對話指令」轉移到「可重複引用的規則文件」。 2. 模組化輸出格式:讓 AI 填空取代通靈很多長篇 Prompt 其實都在描述「輸出該長什麼樣子」。與其用自然語言費力描述排版,不如直接給定結構模板。 例如,建立一份 templates/lesson_slides_template.md,直接定義: 第 1 頁:主題頁 第 2 頁:概念說明 第 3 頁:操作步驟 AI 不需要猜測你的排版邏輯,只要把產出的內容「填」進結構裡,穩定度將大幅提升。 3. 腳本化前處理:淨化雜亂的輸入資料AI 表現不穩,常常是因為輸入的原始資料太過混亂(如:逐字稿混雜、表格欄位不一)。如果把清理工作也丟給 Prompt,AI 一邊理解任務、一邊做清理工,極容易失控。 正確的做法是先用 Python 等腳本語言處理「機械式工作」,例如:長文切片、清理雜訊空白、抽出特定標題區塊。讓 AI 專注處理結構化後的乾淨素材。 4. 拆解龐大工作流:建立單一功能的 Skill 節點不要試圖用一段 Prompt 一口氣完成「讀教材 → 摘要 → 分頁 → 套模板 → 檢查字數」。這只會導致「前面理解錯,後面整串歪」。 將大流程拆解為單一功能的 Skill 模組: content-extractor:專門抽重點與段落。 slide-planner:負責規劃頁次。 slide-writer:依模板寫出內容。 這樣不僅能局部重跑、除錯,還能隨時插入人工審閱點。 5. 累積修正經驗:將「踩坑紀錄」化為系統資產以前你可能每次遇到產出太長,就在 Prompt 補一句「控制在 8 頁內」,下次遇到又得重講。在 Skill 架構下,你可以將這些除錯經驗記錄下來,轉化為系統知識。 把這些踩坑經驗放進 logs/revision_notes.md 或 checklists/output_checklist.md,讓過去的錯誤變成未來系統自動避開的防護網。 進階應用:6 種高價值的 Skill 應用場景除了基本的範本套用,Skill 在實務工作流中還能扮演不同角色: 檢核型 Skill: 不負責產出,專職驗收。檢查字數、案例密度或是否具有濃厚的「AI 腔」。 轉換型 Skill: 將既有內容轉換載體。例如:逐字稿轉講義、SOP 轉 FAQ、長文轉社群貼文。 萃取型 Skill: 從生肉資料中精準抽離定義、步驟、案例或 KPI 數據,供後續生成模組使用。 路由型 Skill: 根據輸入資料的屬性,決定下一步該走哪條工作流(Workflow Orchestration)。 風格型 Skill: 內容骨架不變,僅抽換語氣模組以適配不同受眾(如:企業內訓版 vs. 社群貼文版)。 資料準備型 Skill: 負責前置的去識別化、刪除敏感資訊、欄位標準化等低調卻極度重要的工作。 自我檢核:5 個問題幫你釐清 Skill 設計方向想從「會寫提示詞」進化到「會設計 Skill 架構」,請試著用這 5 個問題檢視目前的工作流: 哪些內容我每次都在重講? 把它抽成規則檔(Rule)。 哪些格式我每次都在重複描述? 把它抽成模板(Template)。 哪些整理動作其實是機械式的? 把它交給腳本前處理(Script)。 哪些步驟其實可以獨立成一段流程? 把它拆成單一功能節點(Node/Skill)。 哪些錯誤我已經修過很多次? 把它寫成檢核表(Checklist)。 常見問答 (FAQ)Q:為什麼原本寫得很完整的 Prompt,換了一份資料產出就不穩定?A:因為過長的 Prompt 將「任務邏輯」與「格式規則」混雜在一起。當輸入資料改變時,AI 容易在龐雜的指令中迷失焦點,試圖在理解新資料與遵守舊規則之間尋找平衡,最終導致產出變成不可控的「臨場發揮」。 Q:我該如何開始第一步將現有的長 Prompt 轉換為 Skill?A:先從「抽離不變的元素」開始。不要急著重構整個流程,先把你每次都會寫到的「輸出格式規定」抽出來變成一個獨立的 Markdown 模板;接著,把「機械式的資料清理」交給簡單的腳本。這兩個動作就能立即有感提升 AI 產出的穩定度。 Q:將工作流拆分成多個 Skill 模組,會不會反而增加開發與執行的時間成本?A:短期內建立模板和規則檔確實需要一點設置時間,但長期來看是大幅節省成本的。多個 Skill 模組可以重複調用(例如你的「內容萃取 Skill」可以用於簡報,也能用於寫貼文),且當流程出錯時,你只需針對單一節點除錯,而不必浪費 Token 讓整段長 Prompt 重新跑一次。