跳到主要內容

部落格

不定期分享最新資訊文章

  • article-n8n 雲端部署:2026 Zeabur 伺服器選擇與實戰指南 | (EP.2) n8n 自動化新手教學

    2026/3/17

    AI自動化 n8n n8n新手教學 Zeabur
    n8n 雲端部署:2026 Zeabur 伺服器選擇與實戰指南 | (EP.2) n8n 自動化新手教學

    大家好,我是享哥,我們又回來了!在上一堂課中,我們已經了解如何透過 NPM 在本地端安裝 n8n,但實務上,我們通常不建議將本地端的 n8n 作為正式應用。 為什麼不建議在本機端使用 NPM 部署 n8n?如果你將 n8n 安裝在個人電腦(本地端),當你需要串接外部服務的 Webhook 時,外部系統是無法直接連線到你的本地主機的。除非你額外搭配 Cloudflare Tunnel 或是 ngrok 等內網穿透工具,否則像是 LINE、Slack 等需要外部 Webhook 觸發的服務,都將無法正常運作。 為了解決這個問題,將 n8n 部署到雲端平台是最佳選擇。目前開發者社群中最推薦的方式之一,就是使用 Zeabur 這個 PaaS (Platform as a Service) 平台來進行線上部署。 Zeabur 最新收費機制:共享叢集退場在使用 Zeabur 之前,必須先了解一項重大的政策更新。Zeabur 在 2026 年 2 月 23 日正式宣布:「共享叢集將不再開放新專案」。 過去,使用者可以免租用獨立主機,直接在共享叢集上透過「用多少付多少」的方式架設 n8n。但現在登入的新帳號,已經無法使用這項服務。官方的用意是希望使用者能擁有更好的效能與穩定性,因此強制要求使用者必須綁定信用卡(訂閱 Developer 開發者方案),並在平台上自行租用一台專屬的雲端伺服器 (VPS),才能將 n8n 架設在上面。 高 CP 值雲端伺服器 (VPS) 推薦與規格建議在 Zeabur 上購買伺服器時,你可以自由選擇偏好的供應商。以下是我實際測試過多家雲端服務商的心得總結: n8n 建議主機規格要讓 n8n 順暢運行,強烈建議主機規格至少要達到: CPU:2 vCPU 以上 記憶體 (RAM):4 GB 以上(2GB 勉強可用,但 4GB 較為保險) 各大伺服器供應商評比 供應商 價格區間 (約) 穩定度 翔哥評價與建議 AWS / GCP $12 - $20+ / 月 極高 不推薦。價格過於昂貴,隨便一台符合規格的主機都要 $12 到 $20 美金起跳,性價比太低。 火山引擎 / 騰訊雲 $2 - $5 / 月 低 不推薦。雖然價格極度甜美(甚至有 $2 美金的方案),但我個人實測購買過兩三次,部署起來非常容易當機,穩定度堪憂。 Hetzner $5 - $6 / 月 高 強烈推薦。來自德國的老牌廠商,2 vCPU / 4GB RAM 的規格每個月只要約 $6 美金,價格親民且連線穩定。 Linode $12 / 月 高 推薦。老牌穩定,雖然價格比 Hetzner 稍高,但整體品質有保障。 💡 延遲小提醒:挑選主機時,通常會建議選擇離亞洲較近的節點(如日本東京、新加坡)。我目前使用的是 Hetzner 的德國主機,實測延遲大約在 200ms 到 350ms 之間,實際操作起來的體感並不會覺得卡頓,大家可以安心選擇。 Zeabur 部署 n8n 實戰教學 (圖文步驟)決定好伺服器後,我們就可以開始進入部署流程了。 步驟一:註冊與帳號設定 前往 Zeabur 官網,點擊登入。 選擇使用 Google 帳號 進行快速登入並授權。 選擇語言介面(如繁體中文)。 手機驗證:系統會要求輸入手機號碼進行簡訊驗證(請注意,一個手機號碼只能綁定一個 Zeabur 帳號)。 步驟二:設定付款方式 (Developer 方案)要租用主機,必須先開通付款權限: 進入帳戶設定中的「付款設定」。 將方案升級至 Developer (開發者) 權限。 綁定一張有效的信用卡。系統會採用預先儲值或月結的方式,從信用卡中扣款。 步驟三:購買並建立伺服器 在左側選單點選「伺服器 (Servers)」,然後點擊「建立」。 選擇「購買新伺服器」。 根據前面的建議,挑選 Hetzner(或其他你偏好的供應商),選擇 2 vCPU / 4GB RAM 的規格,點擊購買。 建立完成後,你的伺服器列表就會出現一台運行中的主機(例如:德國主機)。 步驟四:使用模板部署 n8n 在左側選單點選「專案 (Projects)」,點擊「建立專案」。 系統會詢問你要將專案建置在哪台伺服器上,請選擇你剛剛購買的主機。 進入專案後,點擊「部署新服務」,搜尋 n8n。 在眾多模板中,建議選擇部署次數最多、由「五倍學院 (5xRuby)」製作的 n8n 模板。 設定你的專案網域 (Domain Name),例如:n8n-try.zeabur.app。 點擊「部署」。系統會自動在後台開始安裝 n8n 所需的資料庫與相關服務(如 PostgreSQL)。 步驟五:確認網路連線 等待幾分鐘,直到專案面板上的網址按鈕變成綠色的 PROVISIONED。 點擊進入服務設定,切換到「網路 (Network)」頁籤。 這裡會顯示綁定的公開網域與通訊埠配置,確認無誤後,直接點擊你的網域連結。 取得並開通 n8n 社群版免費授權順利開啟你的 n8n 專屬網址後,還差最後一個步驟,就是設定管理員帳號並開通免費的進階功能。 建立管理員帳號:在首次啟動的畫面上,輸入你的 Email、姓名並設定登入密碼。 進入工作區:完成登入後,你就會看到 Start from scratch 的 n8n 歡迎畫面。 解鎖免費進階功能: 點選左側面板底部的「Settings」。 進入「Usage and plan」選單。 你會看到目前處於 Community Edition,下方有一個解鎖功能區塊(Unlock selected paid features for free)。 輸入你的 Email,點擊送出。 收取授權碼: 前往你的信箱,會收到一封來自 n8n 的信件,內含一組 License key。 點擊信中的啟動按鈕,或複製該組 Key。 啟動授權:回到 n8n 後台,點擊 Enter activation key,將剛剛取得的序號貼上並啟用。 看到綠色勾勾提示 License activated,就代表大功告成了! 現在,你已經擁有一個建立在雲端、穩定且具備完整功能的 n8n 自動化環境。趕快點擊畫布,開始建置你的第一個 n8n 工作流吧! 常見問答 (FAQ)為什麼現在使用 Zeabur 部署 n8n 一定要綁定信用卡?因為 Zeabur 已於 2026 年 2 月 23 日取消了「共享叢集」的免費建置服務。為了確保所有專案的運行效能與穩定度,現在要求使用者升級為 Developer 方案,並自行租用獨立的雲端伺服器 (VPS) 來架設服務,因此需要綁定信用卡來支付主機的月租費。 我可以為了省錢選擇最便宜的雲端主機嗎?雖然市場上有像是火山引擎或騰訊雲提供低至每月 $2 到 $5 美金的主機,但實測經驗顯示,這類極低價主機非常容易發生當機或部署失敗的問題。考量到自動化工作流需要長期穩定運行,強烈建議至少選擇 Hetzner 這類每月約 $5-$6 美金(2 vCPU / 4GB RAM)的高 CP 值且穩定的主機。 如果我選擇的主機在德國,連線延遲會不會很高?伺服器的物理位置確實會影響連線延遲。實測 Hetzner 的德國主機連線至台灣,延遲大約落在 200ms 到 350ms 之間。對於 n8n 這類以後台自動化處理為主的工具來說,這樣的延遲在日常操作上體感並不明顯,可以安心使用。若您有極高的即時性需求,則可考慮加價租用位於日本或新加坡的亞洲節點主機。

  • article-什麼是 n8n?新手必看的自動化工具介紹與 AI 輔助安裝教學 | (EP.1) n8n 自動化新手教學

    2026/3/17

    AI自動化 n8n n8n新手教學 Antigravity
    什麼是 n8n?新手必看的自動化工具介紹與 AI 輔助安裝教學 | (EP.1) n8n 自動化新手教學

    哈囉大家好,我是享哥,一個熱愛 AI 自動化的男人!今天要跟大家分享的是 n8n 自動化新手入門班的第一堂課。我們將從「什麼是 n8n」開始,一路帶大家了解它的特色,並實際透過最新的 AI 工具,帶你一步步輕鬆完成安裝。 什麼是 n8n?自動化流程的幕後推手簡單來說,n8n 是一個「自動化流程工具」。 它的核心功能是幫你把各種不同的服務(例如:API、各類 APP、資料庫)全部串接起來。只要設定好流程,事情就能自動執行,讓你徹底告別手動、重複性的繁瑣操作。你可以把它想像成一個不知疲倦的虛擬數位助理,只要是具有固定邏輯、工讀生能做的重複性事務,都非常適合交給 n8n 來自動化處理。 舉例來說,只要按下一個按鈕或設定一個觸發條件,n8n 就能自動幫你把後續的十幾個步驟一次跑完。 為什麼選擇 n8n?(vs. Zapier / Make)在自動化工具的領域中,大家可能常聽到 Zapier 或是 Make。那麼,為什麼越來越多工程師和企業愛用 n8n 呢? 最核心的原因就是成本(CP 值極高)。 像 Zapier 或 Make 等同類型軟體,通常會依照執行次數或任務量來收費。而 n8n 最大的亮點在於它是開源的(Open Source),它提供了極高的自由度。 n8n 的主要優勢 支援串接的服務極多:幾乎你想得到的 API 或軟體都能對接。 部署彈性大:你可以選擇官方的 n8n Cloud,也可以自行架設在本地端(Localhost)、VPS 或雲端主機上。 長期成本低:一旦上手並選擇自行架設,幾乎可以省下每個月高昂的訂閱費用。 n8n 常見的應用場景企業或個人通常拿 n8n 來做什麼呢?以下是幾個常見的使用場景: 自動化排程工作:設定每天固定時間執行的任務(類似 cron jobs)。 串接各類 SaaS 服務:例如將 LINE、Slack、Google Sheets 互相連動,建立自動通知或資料彙整系統。 AI Agent 工作流:結合大型語言模型,打造專屬的 AI 客服或資料處理工作流。 概念驗證(POC)與 MVP 開發:透過拖拉積木的方式,快速建立自動化系統,甚至取代部分傳統寫程式的開發工作。 如果你的流程具備商業潛力,甚至可以搭配 Vibe Coding 的方式,進一步加上權限管理或金流串接,發展成類似 Netflix 的訂閱制服務。 部署 n8n 的方式與成本考量如果你到 n8n 的官網,最簡單的使用方式是購買 n8n Cloud。但對於新手來說,這並不推薦。 為什麼?因為最便宜的 Starter 方案每個月要價 20 歐元(約台幣 740 元)。雖然前 14 天免費,但長期下來是一筆開銷。 既然 n8n 有提供 GitHub 開源版本,我們完全可以自己架設。常見的架設方式包括 Docker、Zeabur 等,但今天我們要介紹一個對新手最友善、最簡單的方式:透過本機端 npm 安裝,並交由 AI 來幫我們代勞! 如何透過 Google Antigravity (AI Agent) 輕鬆安裝 n8n?以往要透過 npm 安裝,你需要對終端機(Terminal)指令有一定程度的了解。但現在有了 AI,一切都不一樣了。 我們將使用 Google Antigravity —— 這是 Google 推出的一款結合了 Gemini 大語言模型(AI Agent)的新一代 IDE 瀏覽器。透過它,你可以直接請 AI 幫你寫指令並執行安裝。 步驟一:下載並設定 Google Antigravity 搜尋並下載 Google Antigravity。 安裝完成並開啟後,畫面會有點像 VS Code。 點擊 Open Folder。強烈建議在「桌面」建立一個專屬的全新資料夾(例如命名為 n8n),然後選擇開啟它。 系統會跳出提示,詢問是否信任此資料夾的作者,請點擊 「是,我信任作者」。(⚠️ 注意:給予 AI 的權限會限制在這個資料夾內,所以千萬不要直接開在根目錄,以免誤刪重要檔案。) 步驟二:呼叫 AI Agent 幫你安裝 在畫面右側的 Agent 面板中,確認已選擇 Gemini 3.1 Pro (High) 模型。 在對話框輸入:安裝 n8n,然後送出。 AI 思考後,會自動幫你生成檢查 Node.js 版本(node -v)以及安裝 n8n 的指令(npm install -g n8n)。 你只需在畫面上點擊 Run 授權執行即可。 遇到報錯或額度用盡怎麼辦?如果在執行過程中看到類似 Quota reached(額度用滿)的錯誤,別緊張。你可以點擊右上角切換另一個 Google 帳號登入,開一個全新的 Conversation 再次輸入 安裝 n8n 即可。 步驟三:接受安裝指令與更新AI 會開始在背景跑安裝流程。如果你想看詳細的執行過程,可以點擊右上角的 Relocate 將終端機視窗拉出來看。如果 AI 發現你的 Node.js 版本較舊,或是需要安裝特定版本的環境,它會提出建議。此時只要點擊 Accept / Run,相信 AI 並讓它自動處理完成即可。 啟動與初始設定 n8n1. 啟動 n8n 服務安裝完成後,在 Google Antigravity 的 AI 對話框輸入:啟動 n8n。AI 會下達啟動指令(如執行 n8n)。當你看到終端機顯示 Editor is now accessible via: http://localhost:5678 時,代表服務已成功啟動!你可以直接在終端機內按下 o 鍵,或是點擊畫面上 AI 提供的連結。 2. 建立擁有者帳號 (Set up owner account)瀏覽器開啟後,會要求你設定第一組帳號: 輸入真實的 Email(後續需收信)。 輸入 First Name、Last Name。 設定登入密碼。 完成後點擊 Next。 3. 取得免費授權金鑰 (License Key)進入系統後,按照以下步驟開通完整功能: 畫面會提示你需要 License Key,輸入你剛剛註冊的 Email 並點擊發送。 前往你的信箱,會收到一封來自 n8n 的信,裡面包含一串 License key。 將這串 Key 複製起來。 回到 n8n 介面,點選左下角的 Settings -> Usage and plan。 在 Unlock 區塊點選 Enter activation key,貼上金鑰並點選 Activate。看到 License activated 就代表大功告成了! 4. 個性化設定 (更換亮色/暗色主題)如果你跟我一樣,覺得預設的暗色主題(Dark Theme)看久了不習慣,可以到 Settings -> Personal。在 Personalisation 區塊,將 Theme 改為 Light theme 並按下 Save,畫面就會變成清爽的白底了。 建立你的第一個工作流 (Workflow)回到首頁 (Overview),點擊 Add first step,你就可以開始建立自動化流程了: 設定觸發條件 (Trigger):例如選擇 Trigger manually(手動點擊執行),這是測試流程最常用的起點。 新增節點 (Nodes):點擊畫面的 + 號,你可以加入各種 AI 模組(例如 OpenAI、Gemini 節點)或應用程式。 命名你的 Workflow:點擊左上角的預設名稱,將其改為 test 或你喜歡的名稱。 到這裡,你已經成功踏入 n8n 的世界了!後續還有非常多強大、有趣的節點與自動化玩法,我們未來的教學會再一步步帶大家深入探索。趕快動手試試看,打造你的第一個自動化小幫手吧!

  • article-零人公司:不是沒人,而是沒有「當下做決策的人」

    2026/3/17

    商業策略 AI自動化
    零人公司:不是沒人,而是沒有「當下做決策的人」

    很多人以為「零人公司」就是把人全部拿掉。 但我最近越來越確定一件事: 👉 零人公司不是沒有人,而是沒有人在「即時做決策」。 問題不在人力,而在於「決策」現在大家談自動化,大多在解決以下這些已知的事物: SOP 自動化(n8n、Zapier) 知識查詢(RAG、向量資料庫) 任務執行(AI Agent) 這些工具與技術都很好,但本質上都在處理同一件事:👉 把「已知的事」做得更快、更省人。 但公司真正卡住的瓶頸,往往不是這些重複性工作,而是:👉 那些沒有 SOP 的決策。 決策者:公司營運中最大的變數公司裡最不可取代的角色,通常不是工程師,也不是業務,而是:👉 決策者。 因為在多數企業中: SOP 可以寫成文件 流程可以透過工具自動化 知識可以存進資料庫 但「決策」呢?多半是這樣的情況: 沒寫下來 沒人知道怎麼來的 甚至決策者自己也說不清楚 零人公司的關鍵:建立「決策系統」而非純粹依賴 AI現在的 AI 其實已經具備強大的輔助能力,可以: 幫你找資料 幫你整理資訊 幫你執行任務 但它有一條明確的界線:👉 它不負責做決策。 所以只要碰到以下情境: 要不要接案? 要不要開發這功能? 要不要擴張? 最後的結果一定會是:👉 呼叫人來處理。 企業自動化的轉折點:把決策「結構化」如果公司要走向真正的「零人」,你要做的不是:👉 讓 AI 更聰明。 而是:👉 把決策「結構化」。 什麼是「沒有即時決策」的運作模式?零人公司的運作方式,會將所有決策轉變為系統化的評估機制: 1234567891011121. 事前定義 - 決策邏輯 - 權重分配 - 評估方式2. 事後可追蹤 - 為什麼做這個決定? - 當時依據是什麼?3. 可被模擬 - 如果條件改變,結果會怎樣? - 如果當時用另一套邏輯,會不會更好? 人類角色轉變:從「做決策」到「設計決策系統」人在零人公司中會消失嗎?不會。但角色的定位會徹底改變: 👉 人不再「做決策」👉 而是「設計決策系統」 從「駕駛員」變成「自駕系統設計師」如果把公司比喻成一台車: 傳統公司:老闆是駕駛。 一人公司:老闆還是駕駛,只是變得更忙。 零人公司:👉 沒有人在開車,只有人設計怎麼開。 決策系統化:企業轉型最艱難的挑戰因為你要做的,不再只是寫幾份簡單的 SOP,而是要把原本存在於腦海中的抽象概念具體寫出來: 你怎麼評估風險? 你怎麼衡量機會? 你怎麼在短期與長期之間取捨? 這些東西,過去被稱為老闆的「直覺」。現在,你要把它變成:👉 可以被機器執行的邏輯。 終極解法:為什麼決策最終會走向「數學邏輯」?當你開始推推動決策系統化,你會發現自然語言不夠精確、規則太模糊且例外太多。最後一切會收斂到一件事: 👉 用數學描述決策。 因為數學具備極高的確定性: 可以計算 可以比較 可以優化 可以模擬 結語:從「人即決策」到「決策即系統」「零人公司」並不是一個單純探討「自動化程度」的問題,而是一個根本性的商業模式轉換: 👉 從「人即決策」轉換為「決策即系統」。 如果這條路走通了,老闆終於可以真正休假,而公司還能維持正常運作。甚至: 👉 比你在的時候,做得更穩定。 常見問答 (FAQ)Q1:什麼是「零人公司」?真的不需要任何員工嗎?A:零人公司並非把人全部拿掉,而是沒有人在「即時做決策」。人的角色不會消失,而是徹底改變——從「當下做決策」的駕駛員,轉變為「設計決策系統」的工程師。 Q2:既然有 AI 和各種自動化工具,為什麼還需要「決策系統」?A:目前的 AI 工具(如 n8n、Zapier、AI Agent)非常擅長處理「已知的事」,把它們做得更快、更省人力,但 AI 有一條明確界線:它不負責做決策。遇到如「要不要接案」、「要不要擴張」等缺乏 SOP 的情境,最終仍需依賴人類。因此,唯有建立能處理這些變數的「決策系統」,才能真正走向零人化。 Q3:如何開始建立公司的決策系統?A:關鍵在於把過去依賴老闆「直覺」的判斷結構化。你必須明確定義並寫下來:如何評估風險?如何衡量機會?短期與長期如何取捨?並將這些邏輯賦予權重與評估方式,最終收斂為可以用數學描述、計算並模擬的系統邏輯。

  • article-自動化社群留言回覆:CommentFlow 教學與開發者之路

    2026/3/16

    Vibe Coding 社群自動化 Facebook機器人
    自動化社群留言回覆:CommentFlow 教學與開發者之路

    為什麼需要自動化留言回覆?在進行社群行銷時,我們經常會在貼文下方設計 CTA(呼籲行動),例如:「想學 +1」、「索取懶人包請留言」。這類互動能有效提升貼文熱度與觸及率。然而,傳統上這往往需要人工一一回覆,或依賴市面上如 BotBonnie 等第三方聊天機器人服務。 雖然第三方服務功能強大,但通常伴隨著每個月數千元不等的訂閱費用。透過 CommentFlow 等自建或輕量級自動化工具,我們不僅能省下高昂的月租費,還能針對自身需求客製化回覆邏輯,打造屬於自己的自動化客服流程。 CommentFlow 系統教學與設定步驟 立即前往 CommentFlow 系統:https://comment-flow.skypassion5000.workers.dev/ 要開始使用自動留言回覆功能,請遵循以下設定流程: 1. 系統登入與 Facebook 粉專綁定首先進入 CommentFlow 系統並完成登入。系統的核心運作需要存取您的 Facebook 粉絲專頁權限。 進入後台的「設定」選項。 點擊 [連結 Facebook] 進行授權。 依照系統提示,完成 Meta for Developers 應用程式綁定、設定 Webhooks、取得 Page Access Token 及 App Secret。 將所需的 META_APP_ID 與相關金鑰配置完成,確保系統能正常監聽粉專的留言動態。 2. 建立自動回覆規則與關鍵字綁定完成後,就可以開始設定自動回覆的規則。社群上最常見的關鍵字包含:+1、資料、懶人包、教學、PDF 等。 以設定「懶人包」為例: 在後台選擇 [建立規則]。 規則名稱: 輸入「懶人包」。 選擇粉專: 選擇您要套用的 Facebook 粉絲專頁。 比對方式: 選擇「包含關鍵字」或「完全符合」。 回覆方式: 選擇「公開留言回覆」(目前因 Facebook 政策限制,多數建議先使用公開回覆,而非私訊)。 關鍵字列表: 新增 懶人包。 公開留言回覆模板: 填寫您想回覆的內容,例如: 123完整內容都在這裡,歡迎來挖寶! https://blog.es2idea.com/ 可以設定「每位用戶只回覆一次」以避免重複洗版,最後點擊 [更新規則] 或 [啟用規則]。 3. 測試與執行紀錄查詢設定完畢後,建議直接前往粉絲專頁進行測試。 使用個人帳號或測試帳號,在貼文下方留言「我要懶人包」。 系統若偵測到關鍵字,便會自動以粉絲專頁的身份回覆您設定的模板內容。 您可以回到 CommentFlow 後台的 [執行紀錄] 查看觸發狀況。系統會記錄每一筆 Comment ID、觸發的關鍵字及執行狀態(成功或略過)。 從概念到規模化:開發者之路 (Vibe Coding)開發這樣一套自動化工具,其背後蘊含著標準的軟體開發進程: POC (技術可行性測試): 證明技術上可行(It works!),例如寫一小段腳本成功回覆了留言。 Prototype (原型): 流程打通,可以將小工具給內部或少數人測試使用。 MVP (最小可行性產品): 市場買單,開始有人願意為了這個解決方案付費或投入使用。 SaaS (規模化營運): 規模化擴展,加上了前端網站、登入系統、權限管理與付費訂閱機制(如月費/年費),讓一般不具技術背景的用戶也能輕鬆上手。 透過 Vibe Coding 的理念,開發者能將自身驗證過的內部小工具,進一步包裝成具有商業價值的 SaaS 產品。這不僅是技術的實踐,更是將解決問題的能力「產品化」並推向市場的關鍵過程。 常見問答Q1:CommentFlow 需要我有技術背景才能使用嗎? 不需要。CommentFlow 的 SaaS 版本已提供視覺化後台介面,一般用戶只需完成 Facebook 授權綁定、新增關鍵字與回覆模板,即可啟用自動回覆,無需撰寫任何程式碼。 Q2:為什麼系統建議使用「公開留言回覆」而不是私訊? 這是因為 Facebook 的 Messenger 政策限制,非 24 小時內的互動窗口通常無法主動發送私訊給用戶,否則帳號可能面臨封鎖風險。公開留言回覆目前是最穩定且合規的自動回覆方式。 Q3:如果同一則留言包含多個關鍵字,系統會觸發幾次回覆? 系統通常依照規則優先順序執行,符合第一條規則後即停止比對(視系統設定而定)。建議您在後台確認規則的優先序,避免同一留言被重複觸發不同規則。 Q4:「每位用戶只回覆一次」設定如何運作? 開啟此設定後,系統會記錄已回覆過的用戶 ID。同一位用戶在同一規則下重複留言時,系統會略過不再回覆,防止洗版並維持貼文的版面整潔。 Q5:CommentFlow 可以同時管理多個粉絲專頁嗎? 可以。系統支援多粉專管理,您可以在建立規則時選擇要套用的特定粉絲專頁,或為不同粉專設定獨立的自動回覆規則,非常適合代理商或多品牌經營者使用。 Q6:使用 CommentFlow 是否符合 Facebook 的使用規範? CommentFlow 透過 Meta for Developers 官方 API 運作,屬於合規的整合方式。不過,建議避免過度頻繁的自動回覆或明顯的機器人行為,以免觸發 Facebook 的異常偵測機制。

  • article-建立電子書 AI 知識庫的完整實務:VLM + Hierarchical RAG 架構

    2026/3/16

    RAG VLM 向量資料庫
    建立電子書 AI 知識庫的完整實務:VLM + Hierarchical RAG 架構

    近年很多人開始把電子書、PDF、技術文件做成 AI 知識庫。但如果只是「把 PDF 文字丟進向量資料庫」,通常效果會不太好。 原因很簡單:書籍本身是有結構的。 例如一本完整的書通常包含: 章節 小節 段落 圖表 表格 公式 頁面排版 如果忽略這些結構,搜尋品質會下降很多。本文整理一套目前常見、實務上效果不錯的架構,包含 VLM(Vision-Language Model)、Hierarchical RAG、Metadata augmentation 與 Hybrid search,能讓電子書知識庫的搜尋與回答品質明顯提升。 為什麼電子書知識庫不能只依賴「文字向量搜尋」?最常見的 RAG 做法是: 12PDF → 抽文字 → chunk → embedding → vector DB 然後在查詢時: 12query → embedding → vector search → 找到 chunk → LLM 回答 這種方式在短文件通常沒問題,但在處理書籍時會遇到三個核心問題: 書本內容很長:一本 400 頁的書可能有 2000+ 個 chunks。 Chunk 會失去上下文:段落被強制切開後,單一區塊的語意可能不完整。 使用者問法和書本寫法不同: 書本裡的專業用語可能是:token embedding 使用者查詢的口語可能是:文字向量化如果沒有額外的語意補強,純文字搜尋很容易發生 miss(漏找)。 電子書 AI 知識庫的推薦架構 Pipeline為了達到高精準度,完整的知識庫處理流程可以這樣設計: 123456789101112131415161718192021222324252627電子書 PDF / EPUB ↓ 文件解析 ↓ 章節結構抽取 ↓ 段落 chunk ↓LLM 產生 Metadata - summary - keywords - possible questions ↓ VLM 解析頁面 - page summary - figure caption - table summary ↓ 建立向量索引 - chapter index - chunk index - page index ↓ Hybrid search ↓ LLM 組成答案 Hierarchical RAG:長文件搜尋的關鍵處理長篇書籍最常用的技巧是 Hierarchical RAG(階層式檢索)。其核心概念是:先找章節,再找段落,而不是直接在整本書的所有 chunk 中大海撈針。 一般 RAG 流程12query → vector search → 所有 chunks 如果一本書有 2000 個 chunks,搜尋範圍過大,容易引入雜訊。 Hierarchical RAG 流程建立兩層索引: Level 1:chapter / section (章節) Level 2:paragraph / chunk (段落) 查詢流程則改為: 12345678910query ↓搜尋 chapter vectors ↓找到最相關的章節 ↓只在該「特定章節」內搜尋 chunk ↓LLM 回答 架構優勢: 大幅降低搜尋範圍 提升檢索精準度 回答內容更符合書本原有的邏輯結構 為每個段落增加 Metadata 語意補強高品質的 AI 知識庫都會對每個 chunk 增加額外的語意資訊(Metadata),通常包含: summary (摘要) keywords (關鍵字) possible questions (可能的問題) entities (專有名詞 / 實體) Metadata JSON 結構範例: 123456789101112131415161718{ "chapter": "Self Attention", "section": "Attention Score", "page": 121, "content": "Attention score 計算為 softmax(QKᵀ / √d_k)", "summary": "說明 Transformer attention score 的公式", "keywords": [ "transformer", "attention", "softmax", "QK" ], "possible_questions": [ "attention score 怎麼算?", "Transformer attention 公式是什麼?" ]} 為什麼要加入 Possible Questions?因為使用者問問題時,通常不會使用書中的原句。如果書本寫 token embedding,而使用者問 文字向量化,只要在該 chunk 的 Metadata 補上: 123possible_questions: - Transformer 如何將文字轉成向量? 搜尋命中率就會產生質的飛躍。 為什麼 Embedding 不建議只做一個?很多系統會偷懶,把所有內容合併成一段文字再做 embedding (summary + keywords + content)。但更好的做法是建立多個獨立向量: content_vector (偏向細節) summary_vector (偏向抽象概念) question_vector (偏向使用者真實語言) 這三種內容的語意分布完全不同,分開建立索引能帶來更精確的比對結果。 Chunk 大小設定建議切分文本的顆粒度對結果影響甚鉅。以下是一個常見的 Baseline 參考: 內容類型 Chunk Size (Tokens) Overlap (Tokens) 一般文字書 300 – 700 50 – 100 技術專業書 200 – 500 50 – 100 實務提醒: 如果文章內容包含大量的程式碼、表格或數學公式,Chunk 通常需要切得更小,以確保每個區塊的資訊足夠聚焦。 VLM 在電子書知識庫扮演的角色傳統 OCR 無法處理複雜版面,而 VLM(Vision-Language Model) 可以深入理解視覺元素,例如:圖表、表格、UI 截圖、架構圖與流程圖。 處理流程: 12PDF page image → VLM → 產出 page summary / figure caption / table summary 將這些圖表解說文字一併做 embedding 後,當使用者提問:「這張架構圖在講什麼?」時,系統才有能力精準作答。 Hybrid Search:向量與關鍵字的完美結合單純依賴向量搜尋(Vector Search)並不一定最穩定。實務上最強悍的檢索組合是: Vector Search (語意) + BM25 Keyword Search (關鍵字) + Reranker (重新排序) 查詢流程: 12345678910query ↓Vector search 與 Keyword search 雙軌並行 ↓合併候選名單 (Candidates) ↓Rerank (利用重排模型選出最相關的 Top K) ↓LLM 回答 這個做法能完美互補語意搜尋與精確字詞比對的缺點,大幅降低 miss 機率。 建議的資料表 Schema 設計為了配合上述架構,建議的資料庫 Schema 可設計如下: Chapters (章節層級資料)123456789{ "chapter_id": "ch05", "title": "Self Attention", "summary": "介紹 self-attention 原理", "keywords": ["transformer", "attention"], "page_start": 101, "page_end": 145} Chunks (段落層級資料)123456789101112{ "chunk_id": "ch05-sec03-p02", "content": "...", "summary": "...", "keywords": ["attention score"], "possible_questions": [ "attention score 怎麼算" ], "page_start": 121, "page_end": 122} Pages (頁面層級資料)1234567{ "page_number": 121, "page_summary": "...", "figures": ["transformer attention diagram"], "tables": []} 常見問答 FAQQ:如果用 NotebookLM,還需要這些技術嗎?不一定。 NotebookLM 的特點是可以直接讀 PDF、支援長 context,且會自動建立引用。 適合直接使用 NotebookLM 的情境: 文件數量不多、每本書僅幾百頁、不需要自己建置系統。 必須自己建構 RAG 的情境: 準備打造自己的 AI 產品、需要支援大量文件庫、要整合企業內部搜尋系統、需要建立 API 或自訂檢索邏輯。(備註:NotebookLM 本質上也是在使用類似的技術,只是 Google 已經幫你完美封裝好了。) Q:是不是可以直接把整本書塞進 LLM?有時可以。 如果書本總字數不大(例如 < 200k tokens),某些支援超長 Context 的模型確實可以直接吃下全文。 優點: 不用做 RAG,省去 chunking 的麻煩。 缺點: Token 成本極高、無法應付跨多份大文件的全庫搜尋。 Q:RAG 效果不好,通常是哪裡出問題?實務上最常見的 5 大地雷: Chunk 切得不好(斷句生硬或長度不對)。 沒有做 Metadata 語意擴充。 忽略了書籍原有的章節結構。 只依賴 Vector Search,沒用 Hybrid Search。 沒有使用 Reranking 進行最終排序。 結論: RAG 表現不佳通常不是 LLM 模型本身的問題,而是資料處理與結構設計的問題。 總結建立電子書 AI 知識庫時,決定最終品質上限的往往不是你用了多強大的 LLM,而是: Chunk 的切割策略 Metadata 的語意補強 (Augmentation) Hierarchical RAG 的階層式設計 Hybrid Search 的雙軌檢索 VLM 對於圖文內容的深度理解 只要將這些基礎工程扎實做好,即使是搭配輕量級的開源模型,也能打造出極具水準的知識問答系統。

  • article-Vibe Coding 實戰:打造專屬線上報價單系統與電子簽署功能

    2026/3/13

    AI自動化 Vibe Coding Cloudflare
    Vibe Coding 實戰:打造專屬線上報價單系統與電子簽署功能

    哈囉大家好,我是享哥。今天想跟大家分享我近期使用 Vibe Coding 實作的「報價單系統」。 你可以直接前往 報價單測試網站 進行實際體驗! 這個報價單系統是我很久以前就非常想做的專案,過去因為卡在一些技術問題,一直沒有動手實作。這次藉由 Vibe Coding 的協助,我成功開發出了這個具備後台編輯、公開報價頁、商務型電子簽署,以及 JSON / PDF 匯出功能的 MVP(最小可行性產品)。 系統核心定位與開發理念這套系統的核心在於提供一個流暢的線上報價流程。從後台建立報價單開始,到生成專屬的公開連結發送給客戶,客戶檢視無誤後能直接在線上完成簽名,最後系統會自動產生 PDF 留存。此外,我也加入了 JSON 的匯出與匯入功能,方便進行資料的備份與快速搬移。 後台管理與核心功能展示進入管理員登入介面後(我預設了一個 demo 測試帳號,大家可以在測試網站中登入),系統的總覽頁面會清楚劃分出幾個核心區塊,方便業務與管理人員操作: 1. 客戶與產品服務建檔 客戶名單:可以事先新增、管理客戶的聯絡資訊,在建立報價單時就能直接透過下拉選單帶入,省去重複輸入的麻煩。 產品與服務:可以預先建立好公司的各項產品或服務模組,包含計價單位、單價等。 2. 報價單範本設定在撰寫報價單時,經常會用到重複的條款或項目。系統支援建立「範本」,你可以將常用的預設條款(例如:付款條件、智慧財產權歸屬、保固範圍等)或是專案明細存成範本,未來開立新報價單時只要一鍵套用即可,大幅提升效率。 3. 權限控管設計在系統設定部分,我特別區分了「管理員」與「業務」的權限。一般業務帳號可以建立報價單、管理客戶與產品,但無法進入核心的系統設定頁面,藉此確保資料與系統的安全性。 線上報價與電子簽署流程這是整套系統最核心的運作流程: 建立報價單:選定客戶、套用範本、確認服務項目與金額無誤後進行儲存。 發送公開連結:系統會產生一個專屬的「公開報價頁連結」。雖然正式環境應該直接串接 Email 系統寄出,但為了 Demo 方便,目前採用生成公開連結的方式,讓業務可以直接複製並發給客戶。 客戶線上檢視:客戶點擊連結後,會看到一個排版專業、乾淨的報價單頁面,包含雙方資訊、報價明細、條款與匯款帳號等。 電子簽署:若客戶確認無誤,可以在頁面底部直接進行簽名。系統支援三種簽名方式: 手寫簽名:直接在畫布上滑鼠/手指簽名。 輸入姓名:由系統生成標準字體。 上傳圖檔:適合習慣使用公司大小章圖檔的企業客戶。 生成並下載 PDF:送出簽署後,系統會自動跳轉並生成一份包含簽名的完整 PDF 報價單,雙方皆可下載留存。一旦完成簽署,該份報價單在後台就會被鎖定,無法再被修改或刪除,確保合約的有效性。若需修改,只能複製一份新的報價單重新跑流程。 系統上線的挑戰:Cloudflare PDF 匯出踩坑經驗在開發這個專案時,我遇到最大的困難其實是「上線(Deployment)」。 我在本地端(Localhost)測試時,所有功能包含 PDF 匯出都運作得非常順暢。但當我將系統部署到線上,並串接資料庫與 Cloudflare 時,卻發生了許多 Bug。 這主要是因為我使用了 Cloudflare 內建的 PDF function 來生成檔案。這類雲端服務的功能在本地環境和實際線上環境的運作邏輯有時會有落差,導致我花了不少時間在解決上線後才冒出來的錯誤。 如果你未來也打算開發類似的系統,特別是會用到 PDF 套版或是需要部署到線上環境的專案,請務必有心理準備:你需要具備一定的線上環境部署與除錯能力。 AI 自動化開發心得與 Debug 建議這是我花了兩三天時間,透過 Vibe Coding 密集開發出來的成果。我最大的心得是:遇到問題、處理問題的能力依然是核心。 就算有 AI 輔助,程式還是會報錯。當你在線上環境遇到問題時,我的 Debug 建議是: 在瀏覽器按下右鍵,選擇「檢查(Inspect)」。 切換到 Console(主控台) 標籤頁。 查看裡面出現的紅字錯誤訊息。 將這些錯誤訊息完整複製下來,丟給 AI,請它幫你分析這些問題出在哪裡,然後一步一步去修正。 無論你今天是部署在 Cloudflare、AWS 還是 GCP,每一個雲端環境都會有自己獨特的毛病與設定問題(例如我遇到的上線後 PDF 無法生成)。只有自己實際走過一次流程,下次才會知道坑在哪裡。 常見問答 (FAQ)Q1: 這套線上報價單系統適合哪些使用情境?很適合接案工作者、小型工作室、數位服務公司,或是本來就有大量客製化報價需求的團隊。尤其當你常常需要反覆製作報價單、傳送給客戶確認,再追蹤簽署狀態時,這類系統能明顯減少來回溝通與人工整理文件的時間。 Q2: 電子簽署完成後,為什麼報價單不能再直接修改?因為一旦完成簽署,這份文件就已經進入具有合意證明意義的狀態。如果簽完還能直接改內容,等於破壞文件的可信度。所以系統在簽署後會鎖定該筆報價單,若真的需要調整內容,正確做法是複製一份新的版本重新送出,這樣才能保留完整的歷程。 Q3: 為什麼系統要支援手寫、輸入姓名、上傳圖檔三種簽名方式?因為不同客戶的習慣差很多。有些人偏好直接手寫簽名,有些人只想快速輸入姓名,也有些企業客戶會習慣蓋公司章或使用既有簽名圖檔。把三種方式都提供出來,可以降低客戶完成簽署的門檻,也比較符合真實商務場景。 Q4: PDF 匯出在本地正常,但部署到 Cloudflare 後出問題,常見原因是什麼?最常見的問題不是程式本身完全不能跑,而是「本地環境和正式環境的執行條件不一樣」。像是 Cloudflare 的執行限制、函式支援差異、路由設定、資源存取方式,甚至字型與 PDF 生成流程都有可能不同。所以只要牽涉到 PDF、檔案處理、第三方服務或部署平台特殊功能,就一定要預留線上除錯時間。 Q5: 如果我也想做自己的報價單系統,最應該先做好哪幾件事?我會建議先把流程想清楚,而不是一開始就追求功能很多。至少先定義好「客戶資料」、「產品/服務項目」、「報價單範本」、「公開頁面」、「簽署完成後的鎖定規則」這幾個核心模組。只要主流程先跑通,後續再慢慢補上通知、權限細分、更多匯出格式或 CRM 整合,會比一開始就做很大更實際。 希望這次的專案分享對大家有幫助!如果你對於 AI 自動化開發、AI 應用,或是如何規劃這類系統的架構有興趣,都歡迎提出來一起討論!

  • article-Vibe Coding 實戰:整合 Cloudflare 與 TWSE API 打造每日自動選股網站

    2026/3/11

    AI自動化 Vibe Coding Cloudflare
    Vibe Coding 實戰:整合 Cloudflare 與 TWSE API 打造每日自動選股網站

    前言:打造每日自動選股網站Hello,又見面啦!我是享哥。今天要跟大家分享的是我的自動選股網站專案——Daily Stock Picks。 最近發現只要是跟「錢」有關的內容,大家似乎都比較感興趣,所以我決定做一個選股網站來試試水溫。這個網站的核心概念非常明確:系統每天會定時去撈取 API 資料,並利用預設好的交易策略,自動篩選出符合條件的台股清單,方便投資人參考。 網站核心:三大選股策略這個網站主要包含了三種不同的選股策略,每天下午五點會自動執行篩選機制: 1. 均線多頭篩選出目前呈現多頭排列趨勢的股票。這可以幫助我們找到正處於上升趨勢、動能較強的投資標的。 2. 高殖利率針對喜歡穩定配息的投資者,這個策略會篩選出具有高殖利率的股票。從網站實際運作的畫面上可以看到,這個條件通常會命中滿多檔股票的。 3. 60 日突破這個策略會尋找近期突破 60 日新高的股票。不過,因為這個策略需要較長天期(60 日)的歷史交易資訊,如果資料庫還沒有累積足夠的歷史資料,畫面上可能暫時會沒有符合條件的標的呈現。 開發細節:API 串接與資料獲取在資料來源方面,我是使用公開的 臺灣證券交易所 OpenAPI 來獲取每日交易資訊。 如果要做到極度即時的交易訊號,通常需要串接銀行或券商的專屬 API;但因為我們目前的目標只是一個每日盤後更新的「公開資料選股清單」,所以每天去拉取一次盤後資料就已經非常夠用了。 不過,這裡也有一個實務上的限制:如果一次想抓太大量的歷史資料,API 端有機會直接擋下來。因此我實際上是用「分批排程」的方式,慢慢把歷史資料補齊,而不是一次把全部資料硬拉回來。這也代表像 60 日突破 這種仰賴長天期資料的策略,從系統剛上線到真正完整運作,中間本來就需要一些時間累積。 在資料累積方面,網站的設計分為兩個階段: 第一階段:剛上線時,會先抓取當天的最新交易資料。 第二階段:隨著時間推移,歷史資料會逐漸累積完成。當擁有超過 60 天的資料後,依賴歷史紀錄的策略(如 60 日突破)就能夠精準運作。 自動化關鍵:Cloudflare 每日定時排程這個網站最重要的技術亮點,在於使用了 Cloudflare 的排程設定。 我在 Cloudflare 中設定了一個 Cron Trigger 觸發活動。由於 Cloudflare 使用的是 UTC 時間,而我們需要配合台灣時間(UTC+8)每天下午五點來抓取盤後資料,所以在排程時間上,我設定為 0 11 * * 1-5(每天早上 11:00 UTC),這正好會對應到台灣時間的下午五點。透過這個自動化排程,系統就能每天準時幫我們更新最新的選股清單。 後台管理:手動觸發更新機制在開發或測試的過程中,常常會遇到一個痛點:我們不可能總是慢慢等每天下午五點的排程自動執行,才去確認程式有沒有寫錯。 為了增添系統彈性,我特地做了一個簡單的後台監看介面。在這裡,開發者只要輸入設定好的 ADMIN_TOKEN,就可以透過「手動抓取今日資料」的按鈕,隨時觸發撈取資料的動作。比起自己去打 API 更新資料,透過這個小工具能省下很多麻煩。 常見問答 (FAQ)Q1: 這個每日自動選股網站適合拿來做即時當沖或盤中交易嗎?比較不適合。這個專案的定位是「盤後更新的公開資料選股網站」,重點在於每天固定整理出一份可參考的候選清單,而不是提供秒級更新的交易訊號。如果你要做盤中策略、即時警示或自動下單,通常還是要串接更即時的券商或專業行情 API。 Q2: 為什麼網站要等累積超過 60 天資料後,60 日突破 策略才會比較準?因為這個策略本身就依賴至少 60 個交易日的歷史價格資料來判斷是否創高。如果資料庫才剛建立,歷史資料還不完整,就算程式邏輯正確,也可能因為樣本不足而抓不到符合條件的股票。再加上公開 API 大量抓取時可能會擋請求,所以我實際上是用分批排程慢慢回補歷史資料;也因此這類策略通常要讓系統先跑一段時間,效果才會穩定。 Q3: Cloudflare Cron 為什麼不是直接設定成台灣時間下午五點?因為 Cloudflare Cron Trigger 使用的是 UTC 時區,所以要自行換算成台灣時間(UTC+8)。文中設定的 0 11 * * 1-5,意思是每週一到週五的 UTC 11:00 執行,剛好對應台灣時間下午五點。這是很多人在做排程時最容易搞混的地方。 Q4: 如果我想測試資料更新流程,一定要等排程時間到了才知道有沒有成功嗎?不用,這也是後台手動觸發功能存在的原因。你可以在開發或除錯時,先透過後台輸入 ADMIN_TOKEN 手動執行一次更新,確認 API 串接、資料寫入與策略計算都正常,這樣就不用每天等到固定時間才能驗證。 Q5: 這份選股清單可以直接當成投資建議嗎?不建議直接照單全收。比較好的做法,是把它當成「初步篩選工具」,幫你先從大量股票中找出可能值得進一步研究的標的,後續還是要搭配基本面、產業趨勢、風險承受度與自己的交易策略一起判斷。系統可以幫你省時間,但不能取代投資決策本身。 結語:透過 Vibe Coding 實現創意這次的專案很高興也是透過 Vibe Coding 的方式獨立完成的。 每天實踐 Vibe Coding 其實都需要不斷去思考:到底有什麼樣的新題材、新應用是可以吸引大家目光的?如果你對 AI 自動化開發或是更多有趣的 AI 應用有任何新的想法,都非常歡迎隨時跟我討論與分享。希望今天這個「每日自動選股網站」的實戰經驗,能帶給大家一些不一樣的想法與靈感!

  • article-n8n MCP 完整安裝教學:讓 AI 幫你自動生成 n8n 工作流 (Vibe n8n)

    2026/3/11

    AI自動化 Vibe Coding
    n8n MCP 完整安裝教學:讓 AI 幫你自動生成 n8n 工作流 (Vibe n8n)

    大家好,我是享哥,今天要跟大家分享 n8n 的 MCP (Model Context Protocol)。 你有沒有想過,我們在用 n8n 拉節點、建構工作流的時候,如果可以透過 Vibe Coding 的方式,直接請 AI 幫我寫好程式,甚至透過 n8n 的 MCP,直接在 n8n 伺服器上幫我建立好 Workflow,是不是更好呢? 以往我們的作法是:請 AI 幫我們寫好 Workflow 的 JSON 檔,然後手動 Import (匯入) 到 n8n Server 上去除錯 (Debug)。發生問題時,又要回到 AI 那邊修改,修完再匯入。這樣的過程其實滿困擾的。 網路上很多關於 n8n MCP 的教學通常都是使用 Cloud 服務,但常看我影片的朋友就知道,我很少用 Cloud,我大部分都是自建 (Self-hosted)。為了解決這個痛點,我研究了一段時間,發現透過 npx 的方式也能順利達成。今天就來帶大家實作! 為什麼選擇 npx 方式安裝?官方 GitHub (czlonkowski/n8n-mcp) 的 Quick Setup 本來就主推 npx n8n-mcp,而且它會自動抓取最新版。這也相仿於部分 Cloud Shell 教學採用的 npx 當式執行方式。只要把依賴環境準備好,後續執行起來就會非常順暢。 前置準備:檢查 macOS 環境因為我是使用 macOS,以下以 Mac 環境做示範(如果是 Windows 用戶,可以依據概念自行轉換)。 首先,你必須確認你的 Node.js 與 npm 版本。網路上許多測試指出,至少需要 Node.js 22.17 以上的版本才不會有問題(我自己測試時使用的是 22.22,運作正常)。 打開 Terminal,執行以下指令確認版本: 1node --version && npm --version 步驟一:下載並編譯 n8n-mcp 專案確認 Node 版本沒問題後,我們要把官方 GitHub 上的專案 Clone 下來。為了配合 MCP Server 的讀取,建議將其放置在根目錄 (Root Directory)。 1. 下載專案12cd ~git clone https://github.com/czlonkowski/n8n-mcp.git 2. 安裝依賴模組 (Node Modules)下載完成後,進入資料夾並安裝依賴: 12cd ~/n8n-mcpnpm install 3. 編譯專案安裝完模組後,執行編譯: 1npm run build 這一段是為了先把依賴與快取準備好,讓後面透過 npx 或直接跑編譯後的檔案時能夠更加穩定。 步驟二:取得 n8n API Key接下來,我們需要一組 API Key 讓 MCP Server 能夠與你的 n8n 實體溝通。 進入你的 n8n 後台。 點擊左下角的 Settings。 在選單中找到 n8n API。 點擊 Create an API Key。 重要提醒: 建立後請務必立刻把這串 API Key 複製並保存起來,因為視窗關閉後就再也看不到了。 測試 n8n API 端點在我們開始設定 MCP 之前,我建議大家先測試一下 n8n API 端點是否正常運作。這樣可以避免後續設定時遇到莫名其妙的問題。以下是我整理的簡單測試方法和錯誤代碼解釋: 因為 401 代表「API 存在,但你沒有授權」,這其實正是我們測 API endpoint 時想看到的結果。 換句話說: 401 Unauthorized= 伺服器存在= API route 存在= 只是缺少 API Key 所以代表 URL 是正確的,API 有開啟。 n8n API 正常流程例如你直接打: https://你的-n8n-網址/api/v1/workflows 但沒有帶 API Key。 伺服器會回: 401 Unauthorized 意思是: 我知道 /api/v1/workflows但你沒有權限。 這代表: • n8n server 正常 • /api/v1 route 正常 • reverse proxy 沒擋 • API 功能有開 如果 API 有問題會出現什麼❌ 404 404 Not Found 代表: • URL 錯 • proxy 沒轉 /api • path 不存在 例如: https://你的-n8n-網址/workflows (少了 /api/v1) ❌ 502 / 503 代表: • n8n server 沒啟動 • reverse proxy 壞掉 • docker container 掛了 ❌ 403 403 Forbidden 代表: • 被 WAF / Cloudflare 擋 • IP 被限制 正常 API 呼叫會是什麼如果帶 API Key: 12curl -H "X-N8N-API-KEY: your-api-key" \https://你的-n8n-網址/api/v1/workflows 回: 12345{ "data": [ { "id": "1", "name": "workflow1" } ]} 為什麼很多人用 401 當健康檢查因為這個測試可以一次確認: • server 存在 • API route 存在 • proxy 沒壞 • API 功能開啟 但 不需要 API key。 所以很多 automation / agent setup 都用這招。 快速判斷表 回應 代表 401 API 正常,只是沒登入 404 API path 錯 502 server 掛 403 被防火牆擋 在實作中,我發現很多人會忽略這個測試,但它真的很重要。測試通過後,我們就可以放心進入下一步驟了。 步驟三:設定 MCP Server 配置文件 (JSON)接下來要將 n8n MCP 加入到你的 AI 助手 (如 Claude Desktop, Cursor 等) 中。我們需要編輯 MCP 的 JSON 設定檔。 請將以下的 JSON 格式複製起來,並替換成你自己的參數: 123456789101112131415{ "mcpServers": { "n8n-mcp": { "command": "npx", "args": ["-y", "n8n-mcp@latest"], "env": { "MCP_MODE": "stdio", "LOG_LEVEL": "error", "DISABLE_CONSOLE_OUTPUT": "true", "N8N_API_URL": "https://你的-n8n-網址", "N8N_API_KEY": "你的_API_KEY" } } }} 參數設定重點: N8N_API_URL: 請填入你正在使用的 n8n API 網址。如果你是本地端測試,就填 http://localhost:5678。如果是自建的伺服器,就填寫你的獨立網域。 N8N_API_KEY: 貼上剛剛在步驟二取得的 API Key。 步驟四:在 AI 工具中啟用 MCP以支援 MCP 的 AI 工具為例: 開啟工具的 MCP 設定選項 (通常在右上角或設定選單中的 MCP Servers)。 點擊 Manage MCP Servers,選擇編輯原始設定 (View raw config)。 將上述修改好的 JSON 貼上去。如果你原本就已經有其他的 MCP Server,只需將 "n8n-mcp" 這個區塊加入即可。 點擊 Refresh (重新整理)。 重新整理後,你就會看到 n8n-mcp 的服務被成功啟用 (Enabled)! 此時展開功能列表,你會發現多了非常多控制 n8n 的方法,例如 get_node、search_nodes 等等。其中最關鍵的一個功能是:n8n_create_workflow。有了它,AI 就能直接幫我們在伺服器上建立工作流。 實戰測試:讓 AI 自動生成「AI 新聞摘要」工作流設定完成後,我們實際來測試一下。我給 AI 下了這樣一段 Prompt (提示詞): 「請創建一個 n8n 工作流,主題是 AI 新聞摘要。每天都收集最新的 AI 新聞,透過 LLM 整理摘要並加入專家的切角,最後寄信到我的 Gmail 給我。」 按下送出後,AI 思考了幾秒鐘,便開始自動調用 n8n-mcp 的各項 Tools: 它先去搜尋 Schedule Trigger (每天定時執行)、RSS Read (抓取新聞)、OpenAI (整理摘要) 以及 Gmail (寄信) 相關的節點架構。 接著,AI 擬定好了一個實作計畫,包含這五個節點的連線邏輯。 驗證 JSON 語法無誤後,AI 直接調用 n8n_create_workflow 指令。 結果:AI 成功幫我部署上去了! 它還直接回傳了建立成功後的 Workflow ID 給我。 此時我回到我的 n8n 後台查看,真的出現了一個名為「每日 AI 新聞摘要與專家分析」的工作流!打開一看,從排程、RSS 抓取、合併資料、OpenAI 處理到寄送 Gmail,所有的節點跟連線都已經拉好。 這意味著什麼?完全不需要手動 Import JSON 了! 我們現在可以直接在 AI 聊天室下達指令,讓 AI 幫我們把 n8n 工作流建置在伺服器上,我們只需要進去微調憑證 (Credentials) 或修改部分參數,就可以立刻啟用 (Active)。 常見問答Q1:一定要先 git clone 並 npm install 嗎?不是直接用 npx n8n-mcp@latest 就可以了嗎?理論上直接用 npx 就可以執行,但如果你是第一次安裝,或遇到套件抓取、編譯相依套件、快取異常等問題,先手動下載專案並完成 npm install、npm run build,通常會比較穩定。尤其是本地自建環境,先把依賴準備好,後面除錯會省很多時間。 Q2:如果 AI 工具裡看不到 n8n-mcp,該先檢查什麼?先檢查三件事: JSON 設定格式是否正確,特別是逗號、括號與雙引號。 N8N_API_URL、N8N_API_KEY 是否真的有填對。 AI 工具是否已經重新整理 MCP Servers,或重新啟動應用程式。 很多時候不是 n8n-mcp 壞掉,而是設定檔少一個字元,或 API Key 貼錯位置。 Q3:我用的是本機自建 n8n,也能這樣設定嗎?可以。如果你的 n8n 跑在本機,通常可設定成: 1"N8N_API_URL": "http://localhost:5678" 但要注意一件事:你的 AI 工具必須能夠連到這個本機位址。如果 AI 工具本身是裝在同一台電腦上,通常沒問題;如果是遠端環境或沙盒環境,就要另外確認網路可達性。 Q4:把 N8N_API_KEY 放進 MCP 設定檔,會不會有安全風險?會,所以你要把它當成正式憑證管理。建議至少做到以下幾點: 不要把含有 API Key 的設定檔上傳到 GitHub。 不要截圖公開自己的完整設定內容。 如果懷疑金鑰外洩,立刻回到 n8n 後台重新產生新的 API Key。 只要拿到這把金鑰,理論上就可能透過 MCP 對你的 n8n 做操作,因此一定要小心保存。 搭配 n8n-skills 讓操作更順暢為了讓 n8n-mcp 的操作更加順暢,建議搭配 n8n-skills 這個專案。它提供了額外的技能和工具,可以增強 AI 助手在處理 n8n 工作流時的能力。 結語這完美解決了我們以往使用 n8n 時,手動搬運與除錯的痛點。相信以上分享的內容,會對大家在使用 n8n 時有極大的幫助。 希望大家的 n8n Vibe Coding 體驗能夠越來越好,跟我一樣輕鬆用嘴巴 (下指令) 就能完成自動化工作流!如果你有任何問題,歡迎在下方討論;如果你想了解更多 AI 自動化與相關應用的內容,請記得關注與訂閱,我會持續跟大家分享更多實用的技巧。謝謝大家!

  • article-n8n x LINE 自動化預約系統實作:無 AI 高效工作流指南

    2026/3/9

    AI自動化 n8n
    n8n x LINE 自動化預約系統實作:無 AI 高效工作流指南

    這篇文章將為大家介紹 n8n 自動化工作流的作品集首發:n8n LINE 預約系統。 本系統的最大亮點在於完全不使用任何 AI 介入。雖然曾考慮過導入 AI,但考量到 Token 成本與系統單純性,最終選擇單純透過流程規劃來完成。這不僅大幅降低了運行成本,也讓預約流程更為明確可控。 系統架構簡介這套系統主要透過 n8n 接收 LINE 官方帳號的 Webhook,運用 PostgreSQL 記錄使用者的狀態(State Machine)和預約資料,並串接 Google Calendar(Google 日曆)來查詢空檔、建立預約、查詢預約、修改預約與取消預約。 核心流程拆解整個工作流的運作包含以下幾個核心步驟: Webhook 接收:接收 LINE 使用者傳送的訊息。 防重送與 Session 管理:確保 LINE 的重試事件不會重複處理,並於資料庫中查找使用者當前的對話狀態。 意圖判斷 (Intent Resolver):透過簡單語法(如輸入「預約」、「查詢」或符合特定日期格式)引導進入不同的處理分支。 日曆操作:根據意圖分支,執行回覆詢問日期、查詢 Google Calendar 空檔、選擇時段,或是後續的修改與取消預約。 實際操作示範在 n8n 預約系統中,左側為使用者的 LINE 操作介面,右側則是即時同步的 Google 日曆。以下為實際操作的流程展示: 建立預約 在 LINE 官方帳號輸入預約指令後,系統會提示選擇預約的日期(例如:可直接選擇 3/12,或輸入特定格式 2026/03/10)。 系統會立刻比對 Google 日曆,列出當日可預約的時段(例如 09:00、11:00、14:00、16:00、19:00)。 若選擇的時段(如 19:00)剛好被他人預約走,系統會進行防呆檢查,並提示「該時段剛好被預約走了,請重新選擇」。 成功選定空檔後,依提示填寫姓名與電話,即可完成預約。同時,Google 日曆上也會即時新增該筆行程。 查詢與修改預約 查詢預約:點擊系統選單的「查詢預約」,系統會將你所有的預約紀錄以卡片輪播的方式列出,一目了然。 修改預約:針對單一卡片點擊「修改預約」,即可重新選擇新的日期與時段(例如從 3/10 改至 3/11 下午 4 點)。修改完成後,Google 日曆中的舊行程會自動更新為新時段。 取消預約若行程有變,只需在查詢預約的卡片中點選「取消預約」。系統會自動移除指定的預約紀錄,並同步釋放 Google 日曆上的該段時間。 實際體驗測試想要親自操作看看嗎?歡迎點擊下方連結,加入 LINE 官方帳號進行實際體驗: n8n 預約系統(測試中):https://lin.ee/wIKrF0k 結語以上是這套初步且功能完整的 n8n LINE 預約系統展示。透過單純的邏輯判斷與資料庫串接,就能打造出高效且實用的自動化工作流。 如果你想了解更多關於 n8n 自動化工作流的實戰技巧與開發心得,歡迎持續關注,未來將會分享更多進階的自動化應用!

  • article-用 Vibe Coding 打造自動化銷售頁:3小時完成 LINE 報名與 Google Sheets 串接

    2026/3/7

    AI自動化 Vibe Coding LINE
    用 Vibe Coding 打造自動化銷售頁:3小時完成 LINE 報名與 Google Sheets 串接

    哈囉,大家好!我是享哥。今天又要來跟大家分享一個全新的 Vibe Coding 課程實作影片。 這次的課程核心,是要帶你透過 AI,在短短 3 小時內,從零開始做出你的第一個「自動化銷售頁(Landing Page)」。你不僅能產出一個可以實際運作的 MVP(最小可行性產品),還能將後端的報名與追蹤流程完全自動化。 Demo 網站展示 3 小時實作:用 AI 寫出你的第一個銷售頁這個課程設計為 6 個核心步驟,將銷售頁的建置、成效追蹤、網站部署,以及 LINE 自動銷售流程完整串接起來。透過 Vibe Coding 的核心概念,你將學會如何利用 AI 輔助開發,實作出高質感的網頁。 課程中使用的前端技術棧包含了現代主流化工具,幫助你快速入門: Next.js Tailwind CSS 除此之外,我們還會教你如何設置追蹤像素(Pixel),精準掌握使用者的網頁動線與行為。 零成本部署與自動化 CRM 串接為了讓大家能以極低的成本啟動商業測試,課程會採用幾乎零成本的架構來完成部署與資料串接。 GitHub Pages 輕鬆部署網站我們會將完成的網頁專案,直接部署到 GitHub Pages 上。這不僅免除了昂貴的伺服器主機費用,對於初步測試市場水溫的銷售頁來說,是非常實用且高效的作法。 建立 LINE 自動銷售 CRM當銷售頁準備就緒後,訪客若想報名或購買,我們會引導他們掃描 QR Code,加入 LINE 官方帳號。透過 LINE 機器人,我們能打造一套自動化的客服與銷售系統(CRM)。 實際 Demo:自動化報名與查帳流程以下為你展示當顧客進入 LINE 官方帳號後的實際報名體驗: 觸發報名流程: 顧客輸入關鍵字「報名」或點擊選單,系統會自動跳出報名資訊(包含課程日期、地點、費用等)。 查看價格與匯款: 顧客可以選擇查看「早鳥優惠」、「單人票」或「雙人團報」等方案,並取得匯款帳號。 確認匯款完成: 顧客匯款後,點擊「我已完成匯款」,系統會要求顧客輸入帳號後五碼以利對帳。 Google Apps Script (GAS) 串接 Google Sheets顧客在 LINE 上提交的報名與匯款資訊,會怎麼處理呢?這裡就是自動化最核心的環節。 我們會透過 Google Apps Script (GAS) 撰寫簡單的腳本,將 LINE 收集到的資料自動同步至 Google Sheets 中。你的 Google 試算表就會變成一個強大的後台管理系統。 我們在試算表中設定了多種報名狀態,方便管理者進行後續追蹤: 狀態 (Status) 說明 (Description) Pending 等待確認中(剛提交匯款資訊) Confirmed 已核帳,確認收款完成 Notified 已發送報名成功通知給顧客 Refunded 已完成退款 Cancelled 顧客或管理者取消報名 課程的 4 大階段與課前準備為了讓學習更有系統,整個實作過程被拆解為 4 個階段,按部就班幫助你把架構建構起來: 階段 A:先把網站跑起來 目標:先看到畫面,知道你改動程式碼時會發生什麼事。 階段 B:把文案、價格、日期、按鈕換成你的內容 目標:快速做出一個「看起來像你的產品」的專屬頁面。 階段 C:串接 LINE 官方帳號 目標:讓網站的按鈕能真實將顧客引導至你的 LINE 進行互動。 階段 D:串接 GAS 與 Google Sheet 目標:將 LINE 傳來的資料,自動記錄下來並進行狀態管理。 你需要準備的工具帳號要完成這套零成本自動化銷售系統,你只需要事先準備好以下免費帳號: GitHub 帳號 Google 帳號 LINE 個人帳號 LINE 官方帳號 (Official Account) 常見問答完全不會寫程式,也適合上這堂課嗎?可以。這堂課的設計重點不是要求你先具備完整工程背景,而是帶你透過 AI 輔助,一步一步完成實作。你只需要能跟著操作、願意動手練習,就能做出自己的第一個自動化銷售頁 MVP。 課程中會實際做到哪些成果?你會完成一個可對外展示的銷售頁,並把報名流程串接到 LINE 官方帳號,再透過 Google Apps Script 與 Google Sheets 建立後台資料管理流程。也就是說,從前端頁面、名單收集到匯款回報與狀態追蹤,都會有一套可實際運作的雛型。 這套系統一定要花很多工具費用嗎?不一定。這次課程刻意選擇低成本甚至近乎零成本的工具組合,像是 GitHub Pages、Google Sheets、Google Apps Script 與 LINE 官方帳號,目的就是讓你先快速驗證市場,再決定是否要擴充更進階的商業化流程。 如果我已經有自己的課程或服務,也能套用這套方法嗎?可以,而且很適合。無論你要賣的是線上課程、顧問服務、講座活動、工作坊,甚至是需要先蒐集名單再成交的產品,都可以把這個流程當成基礎骨架,再替換成你的品牌文案、價格方案與報名資訊。 上完課之後,我可以自己修改內容與流程嗎?可以。課程會把整個架構拆成幾個清楚的階段,讓你知道網站內容、按鈕連結、LINE 關鍵字回覆、Google Sheets 欄位與 GAS 腳本之間是怎麼配合的。後續你要換圖片、改價格、調整表單欄位或新增追蹤流程,都會更有方向。 這堂課比較適合哪些人?如果你是想快速驗證產品想法的創業者、想把報名與客服流程自動化的講師或顧問、想練習 AI 協作開發流程的行銷人員,這堂課都很適合。它特別適合想先做出成果,而不是先花很多時間學完整套程式理論的人。 這些看似複雜的流程,在 Vibe Coding 的輔助下,實際上難度並不高。大約只要花費 3 個小時,你就能打造出專屬於你、從網頁前端到資料後台完全串接的自動化系統! 如果你對這個課程、或是對 AI 自動化工作流有興趣,歡迎留言告訴我你的想法,也請務必訂閱關注我,後續我會持續分享更多 Vibe Coding 相關的實作作品與應用技巧!