Skip to main contentSkip to footer
Search
LY Corporation Tech Blog

支持 LY Corporation 和 LY Corporation Group (LINE Plus, LINE Taiwan and LINE Vietnam) 服務，宣傳技術和開發文化。

國立臺中科技大學 x LINE PROTOSTAR 創新創業競賽 授課課程 - LINE 技術應用說明 與 LINE API應用介紹

📌 關於作者
大家好，我是 Evan Lin，目前負責 LINE Taiwan 的開發者關係與技術推廣。

這次很高興受邀參加由「國立臺中科技大學創新創業教學產業辦公室」與「LINE PROTOSTAR」共同舉辦的 LINE AI 應用工作坊。

這篇文章整理了當天分享的幾個重點，包括 LINE Messaging API、LIFF、LINE Login， 以及現在很熱門的 LLM Agent 應用。除了介紹 API 怎麼用，我也想分享一個更重要的觀念： 技術不是越多越好，而是要放在對的地方，真的解決使用者的問題。

💡 前言：為什麼把 LINE 和 AI 放在一起？

做創新競賽或產品開發時，很容易先想到：「現在 AI 很熱門，我們要不要加 AI？」

但我在工作坊裡最想提醒大家的一件事是： 不要為了用 AI 而用 AI。

評審真正想看的，通常不是你用了多少最新技術，而是： 你到底解決了誰的什麼問題？使用者真的會需要嗎？這件事有沒有機會變成一個可以持續發展的服務？

LINE 在台灣是一個大家已經很熟悉的使用介面。很多服務如果放進 LINE 裡， 使用者不用另外下載 App，也不需要重新學一套操作方式，打開聊天室就可以開始使用。

再加上現在生成式 AI（Large Language Model, LLM）已經可以處理文字、圖片、語音， 甚至透過 Agent 串接外部工具，很多原本操作複雜的服務，都有機會變成一句話就能完成。

所以真正值得思考的不是「LINE + AI 可以做什麼」，而是： 哪些原本很麻煩的事情，可以因為 LINE + AI 變得更簡單？

一、先別急著寫程式：先想清楚你的服務要解決什麼

1. 用 PULAVB 檢查你的點子

如果你正在準備創業競賽、Hackathon，或只是想做一個自己的 LINE Bot， 我很推薦先用 PULAVB 把想法跑過一次。

  • Problem｜痛點
    你到底想解決什麼問題？這個問題真的存在嗎？
  • User｜使用者
    誰會遇到這個問題？他通常會在什麼情境下需要你的服務？
  • LINE｜平台
    為什麼要放在 LINE？用了 LINE 之後，比另外做一個 App 或網站好在哪裡？
  • AI｜人工智慧
    AI 在這個服務裡真正負責什麼？拿掉 AI 之後，服務還成立嗎？
  • Value｜價值
    使用者用了之後，到底省下了什麼？時間、成本，還是操作上的麻煩？
  • Business｜商業模式
    如果未來真的要營運，誰會願意付錢？服務要怎麼持續下去？

這六個問題不一定要一次回答得很完美，但如果其中有兩三個完全答不出來， 那通常代表現在更需要做的不是開發，而是重新確認題目。

2. 從 LINE 在台灣的服務生態找題目

LINE 在台灣早就不只是聊天工具，目前的服務已經涵蓋許多不同的生活場景，例如：

  • Communication｜通訊：聊天、貼圖、社群互動。
  • Mobility｜移動：LINE TAXI、LINE GO 等移動服務。
  • Fintech｜金融科技：LINE Pay、LINE Bank 等數位金融服務。
  • E-Commerce｜電商：LINE 購物、LINE 禮物、LINE POINTS 等服務。
  • Enterprise Solutions｜企業解決方案：LINE 官方帳號與企業服務整合。
  • Content｜內容：LINE TODAY、LINE VOOM、LINE WEBTOON 等內容服務。

對參賽團隊來說，不一定要發明一個世界上從來沒有人做過的東西。 反而可以先看看這些既有情境： 有沒有哪一段流程仍然很麻煩？有沒有哪一件事可以因為 AI 而少做三個步驟？

3. AI 時代，懂平台本身反而更重要

現在很多開發者都會用 AI 協助寫程式，這當然很好用。

不過實際使用時會發現一件事：如果你自己完全不了解 LINE Platform 的基本概念， AI 也很容易產生「看起來很合理，但其實不能用」的程式碼。

例如 Provider、Channel、Webhook、Reply Token、Flex Message、LIFF， 這些名詞如果你自己先搞懂，再去跟 AI 說：

「我要建立 Messaging API Webhook，收到使用者訊息後用 Reply Message 回傳一張 Flex Message。」

AI 產出的結果通常就會比單純說「幫我寫一個 LINE Bot」精準很多。

所以現在開發者的能力，不只是「自己會不會把每一行程式碼打出來」， 還包含： 能不能正確描述需求、知道系統有哪些元件，以及判斷 AI 給你的答案到底對不對。

二、Messaging API：LINE Bot 最重要的基本功

1. 先搞懂 Provider 和 Channel

在 LINE Developers Console 裡，最常碰到的兩個基本概念就是 Provider 和 Channel。

  • Provider
    可以把它想成服務的「擁有者」，可能是個人、公司或組織。
  • Channel
    代表一個實際使用 LINE Platform 的服務，例如 Messaging API Channel。

這裡有一個很容易踩到的坑： Channel 建立之後，不能再換到其他 Provider。

所以如果是正式產品，建議一開始就先想好 Provider 應該放在哪一個組織與權限架構下， 不要等服務做大之後才發現當初建錯地方。

2. Reply Message 和 Push Message 差在哪？

Messaging API 裡最常使用的訊息方式，可以先分成兩類： Reply 與 Push。

💬 Reply Message

使用者傳訊息給 Bot 之後，LINE Platform 會透過 Webhook 把事件送到你的 Server， 事件裡會帶一個 replyToken。

你的服務就可以拿這個 replyToken 回覆使用者。

很多「使用者問一句、Bot 回一句」的服務，都會以 Reply Message 為主要互動方式。

📣 Push Message

Push Message 則是由 Bot 主動發送，例如提醒、通知或行銷訊息。

常見方式包括：

  • Push：傳給單一使用者。
  • Multicast：一次傳給多位指定使用者。
  • Broadcast：傳給官方帳號的所有好友。
  • Narrowcast：依條件進行分眾推播。

Push Message 會和官方帳號的訊息方案與當月發送量有關。 如果開發時遇到 HTTP 429，除了檢查 API 呼叫頻率之外， 也要確認官方帳號目前的訊息額度與相關限制。

3. 不要只讓 Bot 回純文字

LINE Bot 好玩的地方，就是它不只是「文字進、文字出」。

Messaging API 支援許多不同格式：

  • Text
  • Sticker
  • Image
  • Video
  • Audio
  • Location
  • Flex Message

🎨 Flex Message

如果你的 Bot 需要呈現商品卡片、餐廳資訊、行程、訂單、AI 搜尋結果， 我會很推薦研究 Flex Message。

Flex Message 本身是 JSON 結構，但可以自由控制文字、圖片、按鈕與版面配置。 LINE 也提供 Flex Message Simulator， 不需要每改一個 padding 就重新部署 Server，直接在瀏覽器裡就可以先調整畫面。

⚡ Quick Reply

Quick Reply 很適合拿來減少使用者輸入。

例如你的 AI Bot 問：「今天想查什麼？」

下方可以直接提供：

  • 📍 附近餐廳
  • 🚗 找停車場
  • 📷 上傳照片
  • 📍 傳送位置

比起要求使用者自己輸入完整指令，這種方式通常更容易上手。

📋 Rich Menu

Rich Menu 就是固定出現在聊天室下方的圖文選單。

如果你的服務有三到六個最常使用的功能， 與其叫使用者記住指令，不如直接把入口放在 Rich Menu。

🎭 動態切換 Bot 的顯示名稱與 Icon

Messaging API 發送訊息時，也可以透過 sender.name 與 sender.iconUrl 調整該則訊息顯示的名稱與圖片。

這對 AI Agent 特別有意思。

例如同一個 Bot 背後可能有「旅遊 Agent」、「客服 Agent」和「理財 Agent」， 就可以透過不同名稱與 Icon，讓使用者更清楚現在是誰在回答。

三、當聊天視窗不夠用：LINE Login 與 LIFF

1. LINE Login

LINE Login 的用途很直覺： 讓網站或 App 可以使用 LINE 帳號登入。

對開發者來說，可以減少自己建立帳號與登入系統的成本； 對使用者來說，也不用再多記一組帳號密碼。

在取得對應授權後，也可以取得使用者的基本 Profile 資訊， 例如 Display Name、User ID 與 Profile Image。

2. LIFF：直接把 Web App 放進 LINE

如果純聊天介面開始不夠用，就可以考慮 LIFF（LINE Front-end Framework）。

簡單來說，LIFF 可以讓 Web App 在 LINE 裡開啟。

這很適合一些不容易只靠聊天完成的場景，例如：

  • 預約日期與時間
  • 填寫完整表單
  • 電子會員卡
  • 商品選購
  • 訂單確認
  • 付款流程

LIFF 可以依使用情境使用不同顯示尺寸，例如 Compact、Tall、Full。

幾個實用的 LIFF API

  • liff.sendMessages()
    在符合相關條件與權限設定的情況下，可以讓使用者把 LIFF 裡的操作結果送回目前聊天室。
  • Share Target Picker
    讓使用者選擇好友或群組，把指定內容分享出去。
  • liff.scanCodeV2()
    使用相機掃描 QR Code，再把掃描結果帶回 Web App。

實務上，我很常把 LINE Bot 和 LIFF 想成兩個不同角色：

  • Bot：負責對話、提醒、通知與 AI。
  • LIFF：負責比較複雜的輸入、操作與視覺介面。

兩個搭配起來，通常會比硬把所有功能都塞進聊天室好用很多。

四、LINE × LLM Agent：可以做哪些有趣的事情？

講完 LINE API 的基本功能之後，接下來就是這次工作坊很多同學最有興趣的部分： 怎麼把 LLM 和 Agent 放進 LINE？

我自己覺得，LINE 很適合當成 Agent 的入口。

因為使用者本來就會傳文字、圖片、檔案、語音和位置， 這些剛好也是現在多模態 AI 很擅長處理的輸入。

1. 聊天訊息摘要

如果一個聊天室一天有幾百、幾千則訊息，要全部往上滑幾乎不可能。

AI 很適合先幫使用者整理：

  • 今天發生了什麼？
  • 有哪些重要決定？
  • 誰提到了需要處理的事情？
  • 有哪些事情還沒得到答案？

這種功能看起來不複雜，但其實非常貼近真實使用情境。

2. 名片小幫手

使用者直接拍一張名片傳給 LINE Bot。

AI 可以先辨識圖片裡的姓名、公司、職稱、電話與 Email，再整理成結構化資料。

接著可以用 Flex Message 讓使用者確認：「資料對嗎？」

如果電話錯了，甚至可以直接說：「電話改成 0912-XXX-XXX。」

Agent 再幫忙更新資料。

這就是很典型的 Multimodal + LLM + Tool Calling + LINE UI 使用方式。

3. 檔案小幫手

另一個很好理解的例子，是把 LINE 當成自己的檔案入口。

例如使用者把 PDF、圖片或文件傳給 Bot， Agent 可以自動將檔案整理並備份到 Google Drive。

之後你甚至可以直接問：

「我上週傳的那份報價單是哪一份？」

Agent 再去搜尋歷史資料，把結果找回來。

4. Research Agent 與 RAG

如果資料量開始變大，就會碰到 RAG（Retrieval-Augmented Generation）。

例如把公司文件、研究資料或技術文件存進搜尋系統， 再搭配 Qdrant、Milvus、Weaviate、pgvector 等向量資料庫， 讓 Agent 先找資料，再交給 LLM 回答。

這種架構比單純把所有內容一次塞進 Prompt 更適合處理大型知識庫。

5. 一個 LINE Bot，也可以串很多不同工具

Agent 真正有趣的地方，不只是回答問題，而是可以進一步做事情。

例如：

  • 社群內容小幫手
    傳入 YouTube 或文章網址，自動整理成 LinkedIn、Threads、X、Facebook 等不同版本。
  • Voice Agent
    串接 Gemini Live 等即時語音服務，直接和 AI 進行語音對話。
  • 附近搜尋
    使用者傳一個 Location，Agent 幫忙找附近停車場、加油站或餐廳。
  • 評論整理
    搜尋餐廳後，不只列星等，而是整理「大家最常稱讚什麼」、「有哪些常見負評」。

這些案例其實都有一個共同點： 使用者不用知道背後到底串了幾個 API，他只需要跟 LINE Bot 說自己想做什麼。

五、AI 幫你寫 LINE Bot，也要先讓它懂 LINE

現在大家很常用 Coding Agent 或 AI CLI 寫程式。

但如果直接叫 AI：「幫我做一個 LINE Bot。」

它有可能使用舊版 SDK、錯誤的 Endpoint，甚至漏掉 Webhook Signature Verification。

所以 LINE 也開始提供適合 AI Agent 閱讀的開發資訊， 例如 Messaging API 與 LIFF 相關的 Skills。

當 Coding Agent 先讀過這些規範，就比較能理解：

  • Webhook Signature 要怎麼驗證。
  • 哪些 API 使用 api.line.me。
  • 哪些資料 API 使用 api-data.line.me。
  • Webhook 收到之後應該怎麼正確回應。
  • Messaging API 與 LIFF 各自適合處理什麼工作。

對現在的開發者來說，這是一個很重要的轉變：

過去是人讀 Documentation 再寫 Code；現在則可能變成人先定義需求， AI 讀 Documentation，接著人再負責檢查架構與結果。

AI 可以讓開發速度變快，但前提還是你要知道自己在做什麼。

六、Q&A：除了技術，也聊聊工程師的下一步

工作坊最後，我們也透過 Slido 與聊天室回答了不少同學的問題。

有些人問 Messaging API，有些人問 AI Agent， 當然也少不了大家很關心的實習與工程師職涯。

LINE TECH FRESH 實習計畫

如果你還是學生，也對真正的產品開發有興趣，可以關注 LINE TECH FRESH。

TECH FRESH 是 LINE Taiwan 的長期技術實習計畫， 實習生會實際進入開發團隊，參與產品與專案開發，而不是只有做練習題或旁觀。

計畫特色包括：

  • 約一年的長期實習。
  • 彈性的工作安排，通常每週約三天。
  • 直接參與真實產品與工程專案。
  • 與 LINE Taiwan 工程團隊一起工作。
  • 表現優秀的同學，也有機會進一步挑戰正式職缺。

技術能力當然重要，但我們也很重視一個人在團隊裡怎麼合作。

  • Take Ownership
    不只是把被交代的事情做完，而是願意把問題一路追到真的解決。
  • Be Open
    願意分享資訊、接受不同意見，也願意和不同角色合作。
  • Trust & Respect
    尊重不同背景、文化與專業的人，建立彼此可以信任的合作方式。

🎯 最後想留給大家的一件事

如果這次工作坊只能記得一件事，我希望不是某一支 API 怎麼呼叫， 也不是哪一個 AI Model 最強。

我更希望大家記得： 先找到值得解決的問題，再選擇適合的技術。

LINE 的優勢是使用門檻低，而且使用者已經在這裡； AI 的優勢則是開始能理解更自然的輸入，並且協助使用者完成以前需要很多步驟才能完成的事情。

當這兩件事情放在一起，真正有意思的不是「做一個會聊天的 Bot」， 而是讓原本複雜的服務，變成一句話就能開始。

如果你正在準備這次競賽，也可以回頭再問自己一次：

我的使用者遇到了什麼問題？
為什麼用 LINE？
為什麼需要 AI？
最後，我到底幫他省下了什麼？

這幾個問題如果都能回答得很清楚，你的作品通常就已經有一個很不錯的起點了。

如果你也在開發 LINE Bot、LIFF 或 LLM Agent， 歡迎一起交流，也期待看到大家把這些技術做成真正有人會用的服務。

如果在開發 LINE Bot、LIFF、Messaging API，或其他 LINE Platform 功能時遇到問題， 也歡迎到 LINE Developers Taiwan 官方社團一起交流與提問： https://www.facebook.com/groups/linebot