以前，如果想開發一套 CRM、客服系統、知識庫或工作流程平台，大部分人都會想： 「是不是要找工程師？」 但到了 2026 年，我的答案已經變成： 先去 GitHub 找找，有沒有已經做好的 AI Native 專案。 這半年，我一直在研究各種 AI Agent、n8n、自動化工作流，也開始大量使用 Codex 和 Claude Code 協助開發。我慢慢發現一件很有趣的事情：現在很多開源專案不只是免費，而是一開始就是為 AI 設計的。 它們不是傳統 SaaS 加上一個聊天機器人，而是從架構開始就考慮： AI Agent MCP (Model Context Protocol) Workflow API 串接 流程自動化 多模型整合 也就是大家最近常說的：AI Native（AI 原生）。 如果你正在學 Vibe Coding，我非常建議：不要一開始就叫 AI 幫你從零寫一套 CRM。 因為現在 GitHub 已經有很多成熟的底座，你真正要做的，是把它們完美串接起來。 什麼是 AI Business OS？中小企業的終極自動化解方我最近開始把這些工具統稱為：AI Business OS（AI 公司作業系統）。 它不像傳統 ERP 那麼龐大，也不是單一功能的 CRM。它是把公司每天會用到的工具，全部換成「AI Ready」的狀態。系統的運作邏輯如下： 12345AI Agent (負責大腦思考) │n8n Workflow (負責神經網路與流程傳遞) │CRM / 客服 / 知識庫 / 文件 / LINE / Email (負責肢體行動與資料儲存) AI Agent 負責思考，n8n 負責流程，其他系統負責儲存與互動。這就是我認為未來中小企業最容易、也最高效導入 AI 的方式。 一、AI CRM：如何用 AI 重新定義客戶關係管理？🥇 Twenty CRM（強烈推薦：原生 AI 打造）如果今天只能推薦一套 CRM，我絕對會選 Twenty CRM。它不像傳統 CRM，它從一開始就是 AI Native。它很像把 Salesforce 用現代技術重新做了一次。 核心特色： 現代化介面、GraphQL API、MCP Server 支援、AI Agent 可直接操作 CRM、Docker 輕量部署、自訂資料物件。 適合對象： AI 開發者、Vibe Coding 實踐者、Codex / Claude Code 使用者。 最佳搭配： n8n、OpenRouter、LiteLLM、Gmail、LINE OA。 🥈 Cordys CRM（專注 AI 助理與工作流）最近在 GitHub 非常熱門的新專案，主打 CRM + AI Assistant + Workflow。內建豐富的 AI 技能，例如：AI 摘要客戶對話、AI 分析商機、AI 建議下一步行動、AI 自動撰寫 Email。未來想做企業 CRM 應用的話，極具研究價值。 🥉 EspoCRM（適合傳統企業的成熟選擇）偏向傳統企業架構，發展非常成熟且 API 完整，Docker 部署也很穩定。唯一的缺點是 UI 介面稍微具有年代感。 二、AI 客服：如何打造 24 小時全自動回覆系統？很多人還在辛苦地自己寫聊天機器人，其實 GitHub 已經有極其成熟的開源方案。 Chatwoot（開源版的 Intercom）它支援全通路的客服整合，包含：Email、網站客服、LINE（透過 API）、WhatsApp、Facebook Messenger。 搭配 n8n 的自動化玩法：收到新客服訊息 ➡️ GPT 自動分類情緒與意圖 ➡️ 於 CRM 建立工單 ➡️ 觸發 LINE 通知客服人員 ➡️ 自動寄送 Email 安撫信。 整個流程幾乎不需要寫任何一行程式碼！ 三、AI 知識庫：如何建置公司的第二大腦？AFFiNE（AI 版的 Notion）除了強大的文件編輯功能，它還支援 Mind Map、白板、AI 自動摘要與 AI 輔助寫作，非常適合用來製作企業內訓講義或產品說明。 Outline（企業專屬 Wiki）這套系統非常適合用來建立企業 Wiki。如果你的公司有大量嚴謹的 SOP 需要管理，Outline 絕對是首選。 四、AI 工作流：串接所有系統的核心樞紐n8n（自動化流程必備神器）這套工具已經不需要多做介紹，我現在幾乎所有 Demo 都會用它！在 AI 時代，你不一定要會寫程式，但一定要會串流程。 你可以輕鬆透過拖拉完成以下自動化：Google 表單收到新資料 ➡️ 呼叫 GPT 進行資料分析 ➡️ 在 CRM 建立客戶檔案 ➡️ 自動寄送 Welcome Email ➡️ 建立 Google Calendar 行程 ➡️ 傳送 LINE 通知給業務。 五、AI Agent 入口：統一管理你的 AI 模型Open WebUI它絕對不只是一個單純的聊天介面，而是 AI Agent 的總入口。透過它，你可以統一介面管理並串接各種模型： 本地端 Ollama OpenAI GPT Anthropic Claude Google Gemini 六、AI RAG：讓 AI 讀懂你的企業文件Dify（新手最友善的知識庫平台）如果你想建立公司專屬的 RAG（檢索增強生成）知識庫，Dify 目前仍然是我最推薦的新手平台。它支援上傳 PDF、一鍵建立知識庫、AI Chat 介面與 Workflow 視覺化設計，完全免寫程式。 七、低程式碼平台 (Low-Code)：一個下午完成後台開發如果需要快速建立企業內部管理後台，我推薦以下專案： Appsmith ToolJet Budibase 只要資料庫準備好，一個管理系統往往一個下午就能拉出來。 新手該如何無痛起步？部署順序建議很多人看到 GitHub 開源專案，第一反應就是：「我不會 Docker、我也不懂 Linux！」 其實現在一點都不難。如果你跟我一樣使用像 Zeabur 這樣的現代化雲端主機，我建議第一步先這樣部署： 先裝核心基礎： n8n、Open WebUI、PostgreSQL。 循序漸進： 先不要一次裝十幾套系統，等熟悉基礎後，再慢慢加入 Twenty CRM、Chatwoot、Dify。這漾循序漸進的成就感最高，也最不容易放棄。 如何利用 Claude Code 與 Codex 加速開發？在打造 AI Business OS 的過程中，我幾乎都是這樣跟 AI 協作的： Claude Code（資深架構師）： 負責規劃整體架構、撰寫 PRD（產品需求文件）、系統分析、資料庫 (Database) 設計與 Workflow 流程設計。 Codex（全天候工程師）： 負責抓 Bug、新增特定功能、Code Review、Docker 環境微調與 API 串接實作。 兩者搭配起來，開發效率呈現指數型成長。 專家結論：別再重造輪子，站在巨人肩膀上起飛以前我們總覺得：「我要找人做一套 CRM。」現在，我的想法已經完全改變。 CRM、客服系統、知識庫、工作流，GitHub 上早就備妥了成熟的開源底座。你真正該投入時間思考的是： 如何讓 AI Agent 自動完成繁瑣工作？ 如何用 n8n 順暢地串起所有流程？ 如何讓 Codex 和 Claude Code 幫你完成 80% 的客製化開發？ 如何將這些工具組裝成一套真正屬於你們公司的 AI Business OS？ AI 時代最大的競爭優勢，不再是「從零開始硬幹」，而是懂得站在巨人的肩膀上，快速拼圖、優雅上線。 🚀 預告：Zeabur AI Business OS 實戰系列如果大家對這套架構有興趣，下一篇我將開啟 Zeabur AI Business OS 實戰系列！我會一步步帶大家免寫程式部署 n8n、Open WebUI、Twenty CRM、Chatwoot、Dify、PostgreSQL、Qdrant 與 LiteLLM。 我們只需要一台像 Zeabur 這樣的雲端主機，就能利用開源專案免費開始，打造一套真正能協助業務、客服、行銷與管理的 AI 員工團隊。敬請期待！ 常見問答 (FAQ)Q：我完全沒有工程背景，也不懂 Docker，真的能架設這些開源專案嗎？A：絕對可以！現在有許多像 Zeabur 這樣的 PaaS 雲端服務，支援「一鍵部署」GitHub 專案。你不需要手動敲 Linux 指令或寫 Dockerfile，只要將專案匯入平台，系統就會自動幫你搞定底層環境。建議新手從部署 n8n 開始體驗。 Q：打造這套「AI Business OS」的成本會很高嗎？A：相比於購買傳統的企業級 SaaS（如 Salesforce 或 HubSpot），成本非常低。文中介紹的工具皆為免費開源專案，你只需要支付「雲端主機的租用費」以及「API 使用費」（如呼叫 ChatGPT 或 Claude 的 Token 費用），極度適合預算有限的中小企業。 Q：既然 AI 寫程式那麼強，為什麼不直接叫 ChatGPT 幫我從零寫一套 CRM？A：從零開發會耗費大量時間在「修 Bug」、「刻 UI」與「設計基礎架構」上，這不符合 AI 時代的敏捷精神。使用像 Twenty CRM 這樣成熟的開源專案作為底座，再利用 AI (如 Claude Code) 去寫 API 腳本將它們串接起來，才是目前最省時、最穩定的 Vibe Coding 最佳實踐。

為什麼你需要專屬的政府標案監控系統？大家好，我是想哥，致力於用 AI 改變世界。對於經常參與政府標案的企業或個人來說，每天到「政府電子採購網」搜尋案子是例行公事。然而，傳統的搜尋介面往往不夠直覺，手動查找不僅耗時，還極易錯失黃金商機。 為了解決這個痛點，坊間推出了許多標案監控的付費平台。這些平台確實好用，但通常需要支付一筆不小的年費（例如每年高達 8,800 元）。這促使我思考：既然我們已經處於 AI 時代，何不透過 Vibe Coding 自己打造一套專屬的監控系統？ 這不僅是一個能幫你「精準賺錢」的工具，若你自己動手開發，更是一個能立即「省錢」的解決方案。今天，就帶大家來開箱我透過 Vibe Coding 完成的 MVP 作品——**Tender Radar (政府標案監控平台)**。 如果你想先看看實際成果，也可以直接前往體驗網站：Tender Radar。 每年省下近萬元！Tender Radar 核心功能解析透過 Tender Radar 系統，你可以完全掌握標案資訊。以下是系統的三大核心應用場景： 1. 串接公開 API，打造直覺的高效搜尋介面系統底層串接了 g0v 與政府公開的 API 數據，目前已成功匯入超過兩千多筆的標案資料。我們將傳統複雜的介面，轉化為簡潔的資料看板（Dashboard）。你可以透過關鍵字快速檢索，並直接點擊連結跳轉回政府電子採購網查看原始公告，大幅縮短前置作業時間。 2. 建立個人化追蹤條件與 AI 智能評分門檻這是本系統最具價值的地方。你可以建立「個人追蹤條件」，精準定義你想要的商機： 關鍵字設定： 包含字（如：工程、設備、系統、維護）與排除字。 精細篩選： 設定履約地區、預算上下限、截止天數等。 智能評分系統： 系統內建了「分數門檻」與「通知門檻」。透過 AI 輔助設計的評分權重機制，當標案高度符合你的條件時會獲得高分。你可以設定只有達到特定分數（例如命中多個關鍵字）才觸發通知，徹底避免垃圾資訊干擾。 3. LINE 與 Email 自動化精準推播再也不用每天主動刷網頁了！系統會在每天早上 8 點執行排程掃描（也可手動一鍵觸發）。當偵測到符合你高分門檻的新標案時，系統會自動透過以下管道推播給你： LINE 推播： 傳送摘要卡片，包含標案名稱、預算、截止日與直達連結。 Email 通知： 將詳細的標案清單整理成列表，寄送至你的信箱。所有通知紀錄、成功與失敗狀態，甚至熱門機關與類別的數據分析，都能在後台的視覺化報表中一覽無遺。 如何擁有這套自動化標案系統？這個 Tender Radar 系統目前已經具備了完整的 MVP（最小可行性產品）架構。未來，我計畫將其發展成兩種模式： SaaS 訂閱服務： 提供給不想寫程式，但需要高效工具的企業使用。 實戰教學課程： 將這套系統的開發過程包裝成課程，教導大家如何利用 Vibe Coding 與 AI 工具，一步步建構出屬於自己的自動化系統。 如果你對這套系統的部署、SaaS 服務，或是未來的教學課程有興趣，歡迎隨時與我聯絡！ 常見問答 (FAQ)Q：這套標案監控平台的資料更新頻率與準確度如何？A：系統底層直接串接政府電子採購網與 g0v 的公開 API，資料與官方同步。配合每日早上的自動化排程掃描，能確保你在第一時間獲取最新、最準確的標案公告，不會有漏接的問題。 Q：設定中的「分數門檻」與「通知門檻」具體是如何運作的？A：這是一種防干擾的智能過濾機制。當標案符合你的「包含關鍵字」或「特定地區」時會累加分數。你可以設定「分數門檻」（例如 12 分才算及格被收錄）以及更高的「通知門檻」（例如 20 分才主動發 LINE 通知）。這套計分邏輯也可以請 AI 幫忙撰寫與優化，確保推播給你的都是精準的高價值商機。 Q：我完全沒有程式基礎，也能學會用 Vibe Coding 做出這個系統嗎？A：絕對可以！Vibe Coding 的核心精神就是讓 AI 成為你的工程師。只要你能清楚定義商業邏輯與需求（如：需要什麼欄位、用什麼方式通知），配合適當的 AI 工具引導，即使是零基礎也能一步步建置出這套自動化系統。 相關連結 Tender Radar 體驗網站

Google 近期推出的 Stitch 在開發者社群中引起了廣大迴響，其強大的 UI 生成能力令人驚豔。透過結合 MCP (Model Context Protocol) 協定，我們可以讓 AI Agent 自動化處理繁瑣的前端切版工作。 本文將以一個「美甲美容預約系統」的 Next.js 網站為例，帶你一步步拆解如何從零開始，利用 Google Stitch MCP 快速產出具備高質感的網頁 UI。 先收藏 3 個官方入口如果你想快速上手，建議先把下面 3 個官方資源打開，後續安裝與操作時會用得到： Stitch 官網：先了解 Stitch 的整體能力，包含從提示詞生成 UI、調整版型與匯出成果的核心流程。 Stitch MCP 官方安裝文件：用來設定 MCP Server、完成 API Key 綁定，這是讓 AI Agent 真正能呼叫 Stitch 的關鍵步驟。 stitch-skills GitHub 倉庫：Google Labs 提供的 Agent Skills 集合，能讓 Cursor、Claude Code、Gemini CLI 等工具更有效率地配合 Stitch 工作。 如何快速完成 Stitch MCP 環境部署？要讓 AI 能夠直接呼叫 Stitch 的生成能力，我們需要先完成 MCP 伺服器的安裝與 API 金鑰設定。 安裝 Stitch MCP 伺服器在您的 AI 代理開發環境（例如 Cursor、Antigravity 等支援 MCP 的工具）中，開啟 MCP Servers 管理介面，搜尋 stitch 並點擊安裝 (Install)。這一步將會自動化載入所需的環境設定。若想對照完整流程，可以直接參考 Stitch MCP 官方安裝文件。 獲取 API 金鑰 (API Key)安裝過程中，系統會引導您前往 Stitch 的官方網頁設定。請在設定頁面中點擊「建立金鑰」，生成專屬的 API 金鑰，並將其貼回您的 MCP 設定中妥善儲存以完成身分驗證。 擴充 AI 開發火力：安裝 Stitch Skills光有基礎 MCP 還不夠，為了讓 AI 具備更專業的前端工程師思維，我們需要導入 stitch-skills。 這是一個專為 Stitch MCP 伺服器設計的 Agent 技能函式庫，相容於 Gemini CLI、Claude Code 與 Cursor。透過安裝 GitHub 上的 stitch-skills 擴充套件，AI 就能夠遵循更嚴謹的開發標準進行作業，大幅減少生成過程中的邏輯錯誤。 根據該 GitHub 倉庫說明，stitch-skills 內建多種實用能力，例如： stitch-design：負責 Stitch 設計工作流的統一入口。 stitch-loop：可從單一提示詞延伸成完整多頁網站流程。 design-md：協助整理設計系統與 DESIGN.md 文件。 react:components：將 Stitch 畫面轉成 React 元件系統，並維持設計 Token 一致性。 如果你平常就是用 AI 編輯器協作開發，這一層 skills 幾乎就是把 Stitch 從「會生成畫面」升級成「更懂前端交付流程」。 實戰演練：從需求規劃到自動生成 Next.js 網站環境建置完畢後，我們就可以開始向 AI 下達開發指令 (Prompt)。以下為本次美甲預約網站的標準化生成流程： 1. 啟動 SDD (軟體設計文件) 開發流程不要讓 AI 直接寫程式碼，而是要求它先執行 SDD (Software Design Document) 流程。AI 會依序產出結構化的規格文件（Spec）、開發計畫（Plan）與任務清單（Task）。這能確保 AI 清楚理解版面規劃，包含：導覽列 (Navbar)、Hero 區塊、服務項目、作品集與顧客評價等區塊。 1我想做一個美容美甲的預約系統，使用next.j做，先做首頁就好 ，執行 SDD 開發流程，依序產出結構化的 spec、plan 與 task 等規劃文件 2. 制定設計規範 (Design Tokens)在產出程式碼前，AI 會依據主題（如：柔和女性化、優雅高質感）自動建立設計系統。例如設定主色為「玫瑰粉 (#D4A5A5)」、背景色為「奶油米」，並指定字型（Playfair Display 與 Inter）。這些 Tokens 將成為後續 UI 生成的核心基準。 3. 呼叫 create_project 執行 UI 生成當規劃完成後，AI 會調用 Stitch MCP 的 create_project 方法。系統會自動下載所需套件（如 Tailwind CSS）、處理字型與圖標，並開始生成首頁的設計稿與原始碼。 完美還原設計稿：如何解決排版誤差？在初步生成後，您可能會發現瀏覽器渲染的畫面（localhost:3000）與 Stitch 原始設計稿有些微出入。這時不需要手動調整 CSS，只需遵循以下步驟： 反饋錯誤訊息： 將終端機或畫面上的報錯資訊直接貼給 AI 進行初步修復。 要求零誤差校正： 明確指示 AI：「網頁呈現與 Stitch 原始設計稿不太一樣，請幫我確認並修正」。 自動重構： AI 會重新比對 Tailwind tailwind.config.ts 中的顏色設定、全域 CSS 屬性與各個 Component（如 Navbar、Hero Section）的 HTML 結構，確保最終輸出的 Next.js 程式碼與設計稿達到 100% 零誤差轉換。 開發者反思： 當 AI 已經能包辦 UI 介面設計與繁瑣的切版工作時，未來的軟體工程師應將重心轉移至「架構設計」、「需求分析」與「商業邏輯整合」，這才是人類開發者無可取代的價值。 常見問答 (FAQ)Q：Google Stitch 的使用額度限制是什麼？A：目前系統每日提供 400 個額度 (Credits)。根據實測，透過 AI 完整生成一個包含豐富區塊（Hero、作品集、評價等）的高質感首頁，大約就會消耗掉 4 個額度。 Q：Stitch MCP 支援哪些 AI 開發工具？A：只要是支援 MCP (Model Context Protocol) 協定的開發工具皆可使用，主流工具包含 Cursor、Gemini CLI、Claude Code 以及 Antigravity 等。 Q：AI 生成的網頁設計如果不滿意可以修改嗎？A：可以的。您可以透過對話框下達新的提示詞 (Prompt)，例如「請將按鈕顏色改為深色」或「調整作品集區塊的排版」，AI 會自動調用相關程式碼進行局部更新。 相關連結 Stitch 官網 Stitch MCP 官方安裝文件 stitch-skills GitHub 倉庫

為什麼前端工程師應該開始往 FDE 邁進？—— AI 時代下，你的價值正在改變多數人對前端工程師的理解，還停留在： 切版 寫 UI 串 API 這些當然重要，但有一件事正在發生：這些能力，正在變得越來越「不稀缺」。 前端開發，正在被重新定義這幾年最明顯的變化，就是 AI 對開發流程的影響。現在你已經可以做到： 用 AI 生成 React / Vue 元件 自動把設計稿轉成程式碼 快速補齊 CRUD 邏輯 幫忙 debug、重構 這些能力的共同特徵是：它們都集中在「寫功能」這件事上。也就是說，「寫畫面」正在變成基本能力，而不是競爭優勢。 那什麼才是下一個關鍵能力？當開發變得越來越快，有一件事情會變得更重要：如何讓這些功能「穩定上線並持續運作」。這正是 FDE（Front-End Deployment Engineer）在解決的問題。 FDE 在做的，其實是這些事如果你把視角從「寫程式」往後看，你會發現很多關鍵環節： Build 怎麼設計才快、才穩？ Deploy 出問題時怎麼回滾？ Cache 怎麼設計才不會爆掉？ Staging 跟 Production 為什麼不一致？ Release 頻率變高時，風險怎麼控制？ 這些問題不是 UI 層能解的，它們屬於「系統運作層」。而這一層，過去在前端領域是被忽略的。 台灣的現況：不是沒有需求，而是沒有被定義在台灣，很少看到「FDE」這個職稱。但實際上，這些工作一直都存在，只是被分散在不同角色： 前端工程師： 負責一部分 build / deploy。 DevOps： 負責基礎架構，但不一定熟前端。 後端： 偶爾支援部署流程。 結果會變成：沒有人完整負責「前端上線品質」。 這樣的結構，會帶來什麼問題？很多團隊其實都遇過： Deploy 時很緊張，因為不確定會不會壞。 Cache 設錯，整站行為異常。 Build 時間過長，影響開發節奏。 發現 bug 卻很難快速回滾。 不同環境行為不一致。 這些問題不一定每天發生，但一旦發生，影響都很大。而且隨著系統變大，只會越來越頻繁。 AI 反而會放大這些問題這點很關鍵。AI 讓開發變快之後，會帶來兩個結果： 功能產出速度提升。 Release 次數增加。 當 Release 變頻繁，Deploy 次數變多，出錯機率隨之上升，系統複雜度也提高。整個壓力會往「部署與穩定性」集中。也就是說：AI 不是取代這個領域，而是讓它變得更重要。 前端工程師可以怎麼準備？如果你開始意識到這個趨勢，可以從幾個方向調整： 1. 把「上線」當成工程的一部分很多人會把 deploy 當成最後一步。但實際上，deploy 本身就是系統設計的一環。當你開始這樣看，你會自然注意到很多細節。 2. 理解 build 與部署背後的原理不只是會用工具，而是理解： Build 在做什麼？為什麼會變慢？ Bundle 怎麼影響效能？ 環境變數如何影響行為？ 3. 開始接觸「前端以外的邊界」例如： CI/CD 流程 CDN 與 cache 機制 簡單的雲端部署（像 AWS 或 Vercel） 不用變成基礎架構專家，但要知道「前端是怎麼被服務的」。 4. 練習處理「出問題的時候」平常寫功能很順，但真正的能力差異，通常出現在系統出問題時，能不能快速定位與處理： 如何 rollback？ 如何確認問題在 client 還是 CDN？ 如何避免問題再次發生？ 一個正在發生的轉變未來的前端工程師，大致會分成兩種類型： 第一種： 擅長寫功能的人（這部分 AI 會越來越強）。 第二種： 能讓系統穩定運作的人。 這兩者的價值會逐漸拉開差距。而 FDE，就是往第二條路發展的其中一種方向。 結語前端工程不會消失，但它的重心正在改變。從「做出功能」，走向「讓系統可靠地運作」。當寫程式變得更容易，讓系統穩定，反而變得更難，也更有價值。這個轉變不會一夕之間完成，但已經開始發生了。 常見問答 (FAQ)什麼是 FDE (Front-End Deployment Engineer)？FDE 主要專注於前端應用的「系統運作層」，負責解決建置 (Build) 速度、部署 (Deploy) 流程、快取 (Cache) 策略以及環境一致性等問題，確保前端功能在頻繁更新的狀態下依然能穩定運作。 AI 工具普及後，前端工程師會面臨失業嗎？不會失業，但工作重心必須轉移。AI 能大幅提升「寫功能」與「切版」的效率，使這些純開發技能不再稀缺。未來的核心競爭力將在於如何確保系統穩定上線、跨環境部署的除錯能力，以及整體架構的風險控管。 從一般前端工程師轉型 FDE，該如何跨出第一步？建議從「把上線當成工程的一部分」開始。你可以先深入理解專案目前的 Build 流程、接觸 CI/CD 工具（如 GitHub Actions 等）、學習 CDN 與快取機制，並嘗試使用 Vercel 或 AWS 獨立部署專案，逐步培養宏觀的系統架構思維。

為什麼需要自動化留言回覆？在進行社群行銷時，我們經常會在貼文下方設計 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 的異常偵測機制。

哈囉大家好，我是享哥。今天想跟大家分享我近期使用 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 應用，或是如何規劃這類系統的架構有興趣，都歡迎提出來一起討論！

前言：打造每日自動選股網站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 應用有任何新的想法，都非常歡迎隨時跟我討論與分享。希望今天這個「每日自動選股網站」的實戰經驗，能帶給大家一些不一樣的想法與靈感！

大家好，我是享哥，今天要跟大家分享 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 自動化與相關應用的內容，請記得關注與訂閱，我會持續跟大家分享更多實用的技巧。謝謝大家！

哈囉，大家好！我是享哥。今天又要來跟大家分享一個全新的 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 相關的實作作品與應用技巧！

大家好，我是享哥。今天要來分享一個非常實用的 Vibe Coding 擴充工具 (Skill) —— 專門用來串接台灣第三方金流的開源專案。這個工具涵蓋了台灣常見的藍新金流、綠界科技與統一金流，讓你在使用 AI 進行程式碼開發時，能更輕鬆地完成付款流程的整合。 Demo 網站展示 為什麼需要台灣金流 Skill 工具？在開發電商或銷售網站時，串接在地化金流往往是一大痛點。這個發布在 GitHub 上的開源專案 paid-tw/skills 整理了台灣主流的第三方支付模組，讓開發者可以直接透過指令將金流能力導入專案中。 無論你是使用 Claude Code、Codex 還是其他 AI Coding Agents，都可以透過安裝這個 Skill 來大幅節省查閱 API 文件與手動刻寫串接邏輯的時間。 如何快速安裝金流 Skill？你可以直接使用 npx 指令來安裝需要的金流模組。如果你不知道如何操作，也可以把 GitHub 網址直接丟給 ChatGPT，請它教你如何使用。 以下是幾種常見的安裝指令： 12345678910# 查看可用的 skillsnpx skills add paid-tw/skills --list# 選擇特定金流安裝npx skills add paid-tw/skills --skill newebpay # 只安裝藍新金流npx skills add paid-tw/skills --skill ecpay # 只安裝綠界科技npx skills add paid-tw/skills --skill payuni # 只安裝統一金流# 安裝全部npx skills add paid-tw/skills --all 實戰示範：用 Cursor 快速建立一頁式銷售網站為了驗證這個 Skill 的效果，我使用 Cursor 進行了實際測試。我請 AI 幫我建立一個一頁式的服飾銷售網站，並指定使用高品質網路圖庫。最重要的是，我要求 AI 使用剛安裝的 Skill 來建置「綠界科技」的金流功能，並預設使用綠界的測試帳號進行開發。 AI 接收到指令後，會先產出一份完整的開發計畫（包含建立 Next.js 專案、設計頁面、串接金流 API 等），接著便開始自動建置。建置完成後，我們就有了一個具備購物車結帳功能、且畫面美觀的一頁式網站。 綠界金流測試卡號與結帳流程驗證進入結帳畫面後，填寫基本資料並選擇信用卡付款，系統便會自動跳轉至綠界科技的付款測試環境。 請注意，在測試環境中，務必使用官方提供的測試信用卡號，切勿輸入真實的信用卡資訊。 綠界常用測試信用卡資料：123卡號：4311-9522-2222-2222有效年月：填寫大於今天的未來日期即可 (例如：12 / 28)安全碼：222 輸入測試卡號與姓名後，系統會要求輸入手機號碼以接收測試用的 OTP 驗證簡訊。輸入收到的驗證碼並送出，即可看到付款流程完成的結果頁面，並取得測試的訂單編號與交易編號。這些交易紀錄也都能在綠界測試金流的後台查詢到。 (小提醒：由於目前是在本地端測試，若沒有設定公開的 Webhook 回呼網址如 Cloudflare Tunnel 或 ngrok，訂單狀態可能會停留在 pending，這是正常的測試現象。) 內網穿透與後續應用因為我們是在本機測試環境，並沒有設定公開的 API 回呼網址。如果大家要在開發環境中實際接收金流狀態，推薦使用內網穿透工具。例如 Cloudflare Tunnel 就是個絕佳的選擇，能輕鬆解決回呼問題。 進階技巧：如何提升 Codex 開發的成功率？在這次測試中，我也發現了一個實用的小技巧。當我們使用 Codex 處理如串接金流這類較複雜的任務時，建議大家在介面上進行以下兩個設定優化： 提高推理程度 (Reasoning Effort)： 將模型的推理程度設定為「最高」或「超高」(Extra high reasoning depth for complex problems)。雖然 AI 思考和產出程式碼的時間會變長，但犯錯的機率會大幅降低。 開啟規劃模式 (Planner Mode)： 讓 AI 在動手寫程式碼之前，先擬定好清楚的實作步驟，確認無誤後再執行。 這兩個設定能顯著提升 AI 自動化開發的成功率。透過 Vibe Coding 結合開源的台灣金流 Skill，我們能以極高的效率完成以往繁瑣的支付串接工作。大家有興趣的話趕快去測試看看，有任何心得也歡迎一起討論！ 常見問答完全不會寫程式，也能用 AI 串接綠界科技金流嗎？可以，但前提是你願意照著步驟操作，並理解每一段流程在做什麼。這篇分享的重點不是手刻所有程式，而是善用 AI 與現成 Skill，幫你快速建立一個可運作的付款流程雛型。即使你不是工程師，也能先做出測試版，再逐步優化。 這篇教學適合哪些類型的網站？很適合一頁式銷售頁、課程報名頁、小型電商網站、活動售票頁，或任何需要信用卡付款與訂單流程驗證的專案。只要你的網站需要台灣在地金流，這種做法就很有參考價值。 為什麼要搭配台灣金流 Skill，而不是自己從頭研究 API？因為自己從零研究第三方支付文件，通常要花很多時間理解欄位、簽章、測試流程與回呼設定。透過已整理好的 Skill，能先把常見整合邏輯快速建立起來，再把時間放在畫面設計、商業流程與例外處理上，效率會高很多。 綠界科技測試環境可以直接用真實信用卡付款嗎？不行。測試環境只能使用官方提供的測試卡號與測試流程，不能輸入真實信用卡資訊。你應該先在測試環境完成流程驗證，確認訂單建立、付款頁跳轉與回傳資料都正常後，再進一步處理正式環境設定。 如果金流付款成功，但網站沒有收到訂單狀態更新，通常是什麼原因？最常見的原因是本機開發環境沒有公開可被綠界回呼的網址，因此金流平台雖然完成付款頁流程，網站後端卻收不到伺服器通知。這時可以透過 Cloudflare Tunnel、ngrok 等內網穿透工具，先建立測試用公開網址來驗證回呼機制。 用 AI 做金流串接，還需要自己檢查哪些重點？需要。像是訂單金額是否正確、測試與正式環境參數是否分開、回呼網址是否可連通、付款成功與失敗頁是否正常導回、敏感金鑰是否妥善保管，這些都還是要人工確認。AI 可以大幅加快開發，但不能省略驗證與安全檢查。