---
title: "關於 n8n 的 LINE 社群節點"
date: 2025-10-24T00:00:00+08:00
publishDate: 2025-10-24T16:00:00+08:00
lastmod: 2025-10-24T16:21:29+08:00
tags: ["n8n","LINE","社群","心得"]
toc: true
permalink: "https://blog.aotoki.me/posts/2025/10/24/about-n8n-line-messaging-community-node/"
language: "zh-tw"
---


最近看到 [n8n](https://n8n.io)（自動化工作流程平台）的更新中加入了 [LINE Messaging](https://developers.line.biz/en/services/messaging-api/) 的社群節點，花了一點時間研究才發現好心人竟然是自己。

因為已經有 [n8n Line Messaging 社群節點教學](https://www.darrelltw.com/n8n-line-messaging-community-node/)以及 [n8n Line API 串接教學：從零開始，打造你的專屬 AI 通知機器人](https://lifecheatslab.com/n8n-line-api/)兩篇文章介紹使用方式，這篇文章就來聊一下作者角度的看法。

<!--more-->

## 動機 {#motivation}

今年開始 AI（人工智慧）的成本、使用都已經逐漸接近日常使用的狀況，為了鼓勵家人多使用來幫助改善過去需要人工處理的瑣事，而不是只停留在使用雲端服務生成的程度（因為我認為並不太實用）決定來教家人用 n8n 自動化處理一些事情。

以工程師的角度來看，在 2025 下半年使用 Coding Agent 來輔助進行開發是非常容易的，至少 LINE 提供的 Messaging API 開發套件生態系也非常完整，扣掉時間因素跟實際產生的幫助相比，還算是可接受的範圍。

然而，如果是要讓非工程師來用，沒辦法直接使用，以及要花力氣學習把 LINE 整合到 n8n 上都會變成門檻，那麼對於「嘗試看看」的阻力又更大。

雖然也有考慮接使用 n8n 的 Webhook（事件通知機制）串接的選項，但是「安全性」是非常差的，因為我們沒辦法檢查 LINE 提供的簽名（Signature）也就是說有心人士可以透過暴力嘗試猜出 Webhook 的位置，並且隨機發送訊息，那們很可能就把重要的資訊洩漏或者被濫用。

> 在社群節點被知道前，搜集到的資料大多是使用 Webhook 的做法，然而大多數人只會在意「能收到」而不會檢查「是不是 LINE 發送」的情況

## 挑戰 {#challenge}

如果要開發 n8n 的社群節點，就要看是要通過認證還是單純自用，來決定開發的策略。單純自用的話，只要知道怎麼發佈 npm（Node Package Manager）上就可以在「關閉檢查」的前提下使用，但通過認證就必須完全遵守 n8n 的[規範](https://docs.n8n.io/integrations/creating-nodes/build/reference/verification-guidelines/)。

其中最主要的限制在於，如果是通過官方認證的節點，不能依賴任何第三方套件。這就表示除了單純串接 API 之外，太過複雜的節點大多很難會被加入到上面，因為必須確保這個節點是乾淨、安全的。

那麼，在不使用 LINE Messaging SDK 的前提下要讓 n8n 可以順利支援 LINE Messaging 就只能進行功能的刪減，盡可能簡化到可以依靠最基本的 API 呼叫就能夠支援必要的機制，也因此在初期的版本只專注於「可以收發訊息」這樣的處理上。

另一個考量是 Flex Message 的支援，因為是一個很容易出錯的功能，再加上 n8n 的節點介面是固定的，也因此無法任意地調整成「容易編輯」的外觀，就決定先不進行處理。

倒是看到 LINE Messaging 社群節點消息推出後的討論，相比我預想的使用習慣有一點差異，因為過去連最基本的節點都沒有，所以早就習慣用 JSON 去組合這些內容，因此只要能提供支援就足夠，近期會處理另一個 JSON 資料轉換處理的問題，應該很快就能提供對應的選項。

最後，官方審核的流程意外的不困難。但要做好「錄影片」的心理準備，以 LINE 來說對國外公司可能是不熟悉的，因此在審核過程中需要用英文錄製影片解說整個節點的功能，確保 n8n 團隊可以理解這個節點在做什麼。

> 英文程度不用很好，即使英文面試會被面試官抱怨溝通有點困難的英文水準都可以通過檢查，所以如果想提交自己的節點認真，主要是確保功能簡單、好用，再用簡單的英文說明意圖就足夠

## 心得 {#experience}

整體上來說，會把社群節點做出來主要是等官方把 LINE Notify 替換掉等太久，再加上對於「安全性」的考量，才會選擇這樣的方式處理。

如果不是官方認證的社群節點，就表示可以在 n8n 上安裝任意的節點，很多時候是無法確保安全的，再加上 LINE Messaging 的 Webhook 在接受訊息時如果不對訊息來源驗證，是很有可能遭受攻擊而不被發現（如：申請另一個聊天機器人，串到其他人的 n8n 上就可以偷資料）

同時，因為這次社群節點算是少數除了我自己之外，真的有其他人在使用的情境。再次應證了「解決自己問題」跟「盡快收集回饋」兩個在開發產品上很重要的實踐，在消息傳出來後一天左右，我才發現 GitHub 的 [n8n-nodes-line-messaging](https://github.com/elct9620/n8n-nodes-line-messaging) 倉庫有人回報問題，但我一直沒有處理。

> GitHub 對 Issue 通知的判斷不知道是不是有修改，我在一部分的專案會收到，一部分的不會收到，大多是自己檢查才會發現，如果太久沒反應用 `@` 標記我會快很多

另一個很小的功能是「顯示讀取中」的動畫，我一直覺得那個很雞肋，沒想到對一些人來說卻是常用的機制，也就很快的追加上去。

總而言之，如果有需要的功能或者問題，都可以到 GitHub 上面找我討論，使用中文跟英文都沒問題，如果確認是能正常支援的我都會加到裡面。

> 圖片、聲音、影片需要另外處理上傳跟保存比較複雜，目前不會是優先的選項

