【豆漿筆記】用 Zeabur + n8n + Gemini + LINE做名片辨識與查詢：輕便免裝 App

一、前言｜為什麼會做？

每個部門都有資料、每個系統都有資料，但如果資料彼此不相通那就是浪費。

名片的資料特別明顯，直接散在每個部門與人的抽屜中。於是需要跨部門合作、離職退休需要交接、需要找窗口時，就要重複的詢問一次、重找、重建。資訊明明存在，卻無法被其他部門使用，也無法變成公司的共同資產。

1. 資料必須在公司可控雲端
2. 入口要低門檻，不增加同仁學習成本
3. 使用者可共享雲端與資料

我決定用一個「最低阻力」的方式試著解：入口用 LINE、流程用 n8n、辨識用Gemini 提供的 AI、存檔進公司雲端。這篇文章會把設計、實作、踩雷一次整理出來。希望未來的人可以照著做或者給我建議交流改進。

本文主要使用的工具為n8n

二、架構與實作｜用最低阻力跑起來

0. 目標與 MVP 邊界

目的

建立一套以 LINE 為入口、n8n 為後端工作流、並串接 AI 辨識 的名片管理系統，達成：

• 名片資料儲存在公司可控雲端
• 使用者免裝 App、用 LINE 即可上傳/查詢
• 可共享資料、可擴充更多 LINE 功能

範圍

• LINE webhook → n8n 接收事件
• 事件分流（文字/圖片）
• 圖片：Bearer 取圖 → AI 抽取 → 寫入 n8n DataTable → 原圖存 Google Drive
• 文字：回覆（包含基本回覆 與 查詢名片諮詢）
• 錯誤：Error Trigger 觸發寄信

1. 系統架構概覽

元件

• LINE Developers / Messaging API
• • 接收使用者訊息並以 webhook 將事件送到 n8n
• n8n（部署於 Zeabur）
• • 接收 webhook、分流、串 AI、寫入資料、回覆 LINE
• AI（Google Gemini）
• • 以 API Key 串接，用於抽取/解析名片欄位
• 資料儲存
• • n8n 內建 DataTable：存結構化名片資料
  • Google Drive：存取使用者上船的原始圖片，包含名片與其他資料

資料流

• LINE 使用者 → LINE Webhook → n8n Webhook → 判斷 type → text：回覆 → image：Bearer 取圖 → AI 抽取 → 寫入 n8n Table → 上傳 Google Drive → 回覆 LINE
• 錯誤由 Error Trigger 收斂並寄信通知

自己繪製的流程圖，歡迎高手給我建議

2. 前端（LINE）設定流程

2.1 建立 LINE Developers 專案

• 在 LINE Developers 建立帳號/Provider/Channel（Messaging API Channel）

2.2 主頁外觀（可選）

在功能設定前先設定顯目顏色頭像：

• 建立明確識別，降低同仁導入與辨識成本
• 也為未來擴充「更多 LINE 功能」預留一致入口

2.3 回應設定與 Webhook 依賴

• 在回應設定中打開聊天功能
• Webhook 無法直接啟用：必須先啟用 Messaging API 並填入 Webhook URL 才能開啟

2.4 填入 Webhook URL 與驗證

待 n8n webhook 建好後：

• LINE Developers → Webhook settings → 填入 Webhook URL
• 按 Verify 確認連線成功
• 開啟 Use webhook

zeabur 真的是部署好救星

3. 後端（n8n + Zeabur）建置流程

3.1 平台選型

• 考慮開發人我希望專注在功能開發與快速上線，選擇直接在 Zeabur 上部署 n8n

3.2 建立 Webhook Workflow

1. n8n 建立新 workflow
2. 新增 Webhook 節點
3. 設定 method：POST
4. 取得 Webhook URL
5. 回填至 LINE Developers（見 3.4 Webhook URL 與驗證）

4. Credential（憑證）配置

設定 credential 才能串 LINE / AI / Drive。

4.1 Google Drive（OAuth）

目的：名片照片存公司雲端

步驟：

1. Google Cloud Console（API 和服務）
   在 已啟用的 API 點 啟用 API 和服務
   啟用 Drive API
2. n8n Credentials
   選 Google Drive
   填入： OAuth Redirect URL Client ID Client Secret

啟用完成

4.2 Google Gemini（API Key）

目的：AI 辨識與欄位抽取

步驟：

1. 進入 AI studio
2. 選擇專案 → 建立新的 API Key
3. n8n Credentials → 選 Google Gemini → 貼入 API Key

4.3 LINE Bearer Auth（Channel access token）

目的：呼叫 LINE API（取圖、回覆等）

步驟：

1. LINE Developers → 取得 Channel access token
2. n8n Credentials → 建立 Bearer Auth → 輸入 token

5. 核心工作流設計

5.1 事件分流（text/image）

在 n8n 解析 webhook 的 message type：

• text：直接回覆
• image：走取圖 → AI → 存檔 → 回覆流程
• 其他：如貼圖、檔案，目前設定為請給我圖片與指令。

並使用 n8n 的 if 協助分流。

實際分流更多，但本文重點談文字與圖片兩個格式

5.2 圖片流程（image）

1. 使用 Bearer Auth 呼叫 LINE content API 取得圖片
2. AI 處理（Gemini）第一次：確認是否為名片，如是則進入下一步，否則直接回覆此非名片
3. AI 處理（Gemini）第二次：讀取內容並依據我給的格式抽取欄位
4. 寫入 n8n DataTable
5. 上傳名片照片至 Google Drive（原圖保存）
6. 回覆 LINE：建檔成功 + 摘要資訊

5.3 文字流程（text）

1. 收到文字先判斷內容需求
2. 1. 文字聊天：簡短回覆後，引導給予名片或者問句
   2. 詢問問題：AI 處理後，如為查詢名片相關內容則，查詢 DataTable 並回覆結果。

6. 資料儲存：n8n DataTable

目的

追求快速輕便上線使用，先以 n8n 內建 DataTable儲存，不需額外建 DB，。

寫入

• AI 讀取名片資訊 → 輸出指定欄位 → 寫入DataTable

n8n有內建DataTables真的是輕鬆許多

7. 回覆 LINE（HTTP Request + Bearer Auth）

回覆前端 LINE ：

• 使用 n8n 的 HTTP Request 節點 Method 設定 POST
• 使用對應的 replyToken + LINE 指定的 Json 格式回覆

8. 名片原圖保存：Google Drive

在圖片流程中，將名片照片上傳到 Google Drive：

• 使用 Google Drive credential（OAuth）

9. 錯誤告警：Error Trigger → Email

目的

當 workflow 發生錯誤時，能自動通知維運者

作法

• 新建一條 workflow：使用 Error Trigger 作為起點
• 一旦觸發就發訊息到對應節點，因為我 credential 使用Google 所以我這裡選用 Gmail。
• 建議信件內容包含：workflow 名、節點、錯誤訊息、時間、execution id

有錯誤就傳信件，非常直覺

三、收到的回饋與下一步

• 查詢大表：目前只有使用文字查詢的功能，沒辦法一次瀏覽所有名片
• 編輯功能：資訊只有寫入跟複寫，沒辦法針對單一
• 透明觀測：每次讀取時間從1~15秒不等，使用者並不清楚處理中是成功或失敗

四、結論與反思：從「研究 n8n」到「做出能用的工具」

一開始我只是單純研究 n8n，但剛好遇到業務端有「名片判斷與共享」的需求，我索性採取做中學：把學習的成果直接做成一套可用的內部工具。

這種方式最大的好處是：學到從需求、資料、權限、導入到維運一整段產品化的思考。

製作過程的三個發現

1）資料表先搞懂業務需要什麼

先搞懂業務需要的欄位格式，再決定資料表架構，效率高很多，減少建錯 schema 的彎路。題外話，我原本想用 Google Sheet 當資料表，後來發現 n8n 內建 DataTable 更適合 MVP。

2）想要 Credential 一開始就到位，就要先想好架構

這次串了 LINE Bearer、Gemini API Key、Google Drive OAuth。我的體感是：credential 如果做到一半才補，會嚴重打斷開發節奏，甚至影響士氣。為了避免這個情況，是必要在一開始就想好大架構，就能提前知道要開啟那些 Credential，後面才會更有力地進行功能迭代。

3）節點命名是 n8n 專案可維護性的生命線

n8n 雖然拖拉很快，但節點一多、重複節點一多，名稱複雜與雷同程度會很快迷路。這次我最深的教訓是沒有命名導致我找不到 token ，找了半天才發現抓錯導致訊息無法回傳，還怪n8n是不是有問題。

除了 n8n，我也是人生第一次串接 Google API、處理 OAuth、還要理解 LINE 官方帳號的圖文訊息與 webhook 行為。

真正的難題：使用者願不願意使用

最後我發現，真正卡住的不是技術，而是推廣：

• 即使入口是大家熟悉的 LINE，為什麼業務要養成拍照上傳的習慣？
• 市面上已有不少名片軟體，為什麼要用我這套 LINE 系統？

這些問題值我也還解答，儘管知道我要開發的不只是「能辨識名片」的工具，而是「能讓業務工作更快」的流程，但這個命題還是不構支持回答以上兩題。

所以就留給後續思考囉。

n8n中的Agent長得很可愛，特此截圖跟各位分享

五、QA

• n8n 可以接 LINE webhook 嗎？
  可以。LINE Developers 設定 Webhook URL，n8n 建立 Webhook Trigger，Verify 成功後開啟 Use webhook 即可開始收事件。
• LINE 的圖片訊息怎麼取得原圖？
  需用 Channel access token 當 Bearer Token 呼叫 LINE content API 拿到圖片。
• 為什麼用 LINE 做名片管理入口？
  因為不用裝 App、台灣夥伴很習慣使用 line 作為工具，導入成本最低，適合內部工具 MVP。
• n8n 內建 DataTable 適合當資料庫嗎？
  適合 MVP：快速上線、欄位迭代方便。但若要大量資料或複雜查詢，還是會建議搬到正式 DB。
• Google Drive 怎麼跟 n8n 串接上傳檔案？
  用 OAuth 建立 Google Drive credential：在 Google Cloud 啟用 Drive API，填入 Client ID/Secret 與 Redirect URL 後授權即可。
• n8n 怎麼做錯誤告警？
  建立 Error Trigger workflow，發生錯誤時觸發 Gmail/Email 節點寄信，信件內容放 workflow、節點、錯誤訊息與 execution id 便於追查。