2010 年老筆電復活！OpenClaw LINE 頻道配對實戰與解密

這幾天在測試 OpenClaw 的 LINE 頻道整合。說實話，我是在這台 MacBook Air 2010（我的老戰友，現在只能拿來當伺服器跑）上面測試的。雖然硬體已經是「古董」級別，但 OpenClaw 的反應速度真的驚豔到我。

不過，身為一個技術宅，我原本以為串接 LINE Bot 至少要寫個幾百行 Node.js 或 Python，處理那些煩人的 Webhook、什麼加密驗證之類的。結果… 我發現我根本是在「填空」。

🏗 解密 OpenClaw：為什麼不用寫程式就能動？

很多人（包括我一開始）都會好奇：『我什麼 Code 都沒寫，為什麼 LINE 訊息傳過去，OpenClaw 就會回我？』

這就要聊聊 OpenClaw 的 Provider / Channel 架構 了。

講直白一點，OpenClaw 就像是一個「萬用翻譯機」。它已經內置了 LINE 的 Messaging API 處理邏輯。

• Provider（供應商）：負責跟外部世界溝通（像是 LINE 的伺服器）。
• Channel（頻道）：負責定義這個對話在 OpenClaw 裡長什麼樣子。

所以，開發者（也就是我們）的事情變得很簡單：

1. 在 .env 填入 LINE Developer Console 給你的 CHANNEL_SECRET 和 CHANNEL_ACCESS_TOKEN。
2. 在 openclaw.json (或 config.json) 把 LINE 的門關打開 (enabled: true)。
3. 沒了。 剩下的 Webhook 建立、簽名驗證 (Signature verification)、訊息解析 (Message parsing)，OpenClaw 全部都幫你封裝好了。

這就是所謂的 「No Code / 0 Code」 優勢。你可以把省下來的時間，全部花在寫 SOUL.md 去琢磨你的 AI 人格，而不是在那邊 Debug Webhook 為什麼回傳 401。

🛡 為什麼配對這麼「麻煩」？（關於 Pairing 的安全感）

在實戰中，你會發現 OpenClaw 沒辦法「掃個碼就直接用」，它需要一個 Pairing（配對） 的過程。

你可能會碎碎念：『啊我就直接標記它，它回我就好啦，幹嘛還要我回 server 下指令？』

拜託，這是為了保命（和保錢）！
傳統的 LINE Bot 只要 Webhook 通了，誰傳訊息它都會回。但 OpenClaw 的定位是「個人助理」，它擁有的權限很高（可以讀你的文件、執行你的指令）。如果隨便一個路人甲加了你的 Bot，然後開始問它：『幫我列出這台主機上的所有密碼』，那還得了？

Pairing 機制的核心意義：將『LINE 帳號身分』與『AI 代理權限』綁定。
只有經過你手動 openclaw pairing approve 授權的人，AI 才會服務他。這種「只為授權者服務」的設計，才是真正的私有化 AI 安全感。

🛠 前置作業：Webhook 與環境變數

雖然不用寫程式，但基礎建設還是要搞好。老哥我在這行打滾這麼久，最怕的就是這種「看似簡單」的基礎設定卡死人。

1. 設定 JSON 與環境變數

OpenClaw 的 config.json 裡面，關於 LINE 的部分其實很簡潔：

老哥經驗談： 這裡有個關鍵，看到圖中那行 "bind": "process.env.GATEWAY_BIND" 了嗎？這不是隨便寫寫。OpenClaw 允許你引用系統環境變數，這樣你就不必把敏感的 IP 或 Port 寫死在 JSON 裡。gateway.bind 決定了你的服務要在那一個網址「紮營」，對於容器化部署來說，這行代碼縮短了你修改配置的時間。記得把 Token 放到 .env 裡，保護好你的密鑰，別讓它在 GitHub 上裸奔。

2. ngrok 的神救援

因為我在家裡跑，沒有固定 IP，這時候 ngrok 就是救星。

老哥經驗談： 很多人看到畫面上那串隨機生成的 .ngrok-free.app 網址會覺得心煩，但這可是 Webhook 的生命線！它就像是在你的老筆電與外面的 LINE 伺服器之間炸開了一個「蟲洞」。你把這個網址填到 LINE Developer Console，LINE 的訊息就能躲過你家路由器的防火牆，直接精準打到你的 OpenClaw 身上。

啟動！觀察 Gateway 的呼吸

啟動 openclaw gateway 後，我習慣一直盯著 log 看。看到 [line] 顯示 starting LINE provider 的時候，那種成就感真的無與倫比。

老哥經驗談： 別小看這些日誌，裡面藏著很多驗證碼。比如 Pairing session started 後面的那一串隨機 ID，它是用來確保你的配對請求不是「冒牌貨」。只有當你看到 Pairing session completed 出現在螢幕上時，才算大功告成——這意味著 AI 已經在後台領到你的通行證了。

圖中可以看到我目前使用的是 ollama-cloud/gemini-3-flash-preview 模型，這對於老筆電來說壓力小很多。

📱 配對實戰流程：

1. 觸發配對： 在 LINE 群組裡面隨便標記一下機器人.
2. 獲取驗證碼： 機器人會丟出一串驗證碼，像是一封求婚信。
3. 主機端審批：
   這時候你回到伺服器，開個新視窗執行：
   openclaw pairing approve line <你的驗證碼>

看到那個可愛的 OpenClaw 標誌跳出來，恭喜你，配對成功！

🍪 助理人格：餅乾 🍪 現身

配對成功後，我幫我的助理設定了一個 「餅乾」 的人設。

除了在 SOUL.md 中定義語氣與性格，我們還可以透過 IDENTITY.md 來明確規範 AI 的名稱、物種與氛圍（Vibe），使其行為更具一致性。

在人格設定中增加了一些語氣引導：

「Hi NiJia！我是餅乾 🍪✨
今天有什麼精準回擊的任務需要我處理嗎？」

我還測試了 quick_replies（快速回覆按鈕）。雖然截圖專注在對應 Pairing，但設定完成後，讀者可以在 LINE 介面下方配置實用的 Quick Replies 快捷按鈕。

#結語：個人研究與技術實踐

本次串接 LINE 頻道的過程顯示，OpenClaw 的架構對於需要快速部署 AI 助理的開發者非常友善。透過標準化的 Provider 機制，我們可以省去底層協議的實作成本，專注於 AI 整體邏輯與人格設計。

以上內容為個人研究心得，若有任何問題或建議，歡迎在下方留言或透過 GitHub 交流。

前言

最近把身邊幾台 OpenClaw 從穩定（但已經快變遺產？）的 2026.3.1 升級到 2026.4.2。本來以為是個 pnpm install 就能解決的小事，沒想到這中間的配置變更跟環境限制，還是讓我小坐了一下牢。

特別是我的主力戰友——那台 MacBook Air 2010 款。雖然它年紀比很多讀者的貓還大，但我已經把它加爆到 16GB RAM 了！老兵不死，只是需要在升級時多給它一點關愛。寫這篇主要就是想把這些踩坑經驗留下來，給同樣擁抱老設備或追求極致省錢（守護荷包）的大家一個參考。

或是說，先把信用卡準備好就好(?)。

前言

早就聽說 Niseko 是亞洲滑雪聖地，每年冬季吸引世界各地的雪友前來朝聖，乾燥的粉雪讓人念念不忘。趁著這次有機會，第一次踏上北海道的雪地，順便測試一下自己的單板到底進步了多少 🏂

前言

最近在用 Claude Code 玩一些 side project，踩到了兩個工具：spec-kit 跟 superpowers。

老實說一開始看到這兩個工具的介紹時有點懶，又是一堆新東西要學😂，而且看起來好像功能差不多？但用了一陣子後發現它們的定位其實差很多，而且搭配起來用還滿有意思的。

前言

近期在 Maple Royals(RMS) 的炸圖賺錢時從兩隻法師升級到四隻，跟遊戲裡的前輩習得
的心得透過以下文章做個分享

Introduction

這陣子經歷太多內心上的變化，想說趁著出差期間，回顧並整理來台北後第五年的一些經歷，好好思考一下這些日子來的想法，希望未來在回顧這篇時不會太尷尬 😆

前言

最近從私服轉戰繁中版的 Artale 楓之谷，享受過四倍經驗值之後來玩真的痛苦萬分ＸＤ，不過在經歷一陣子之後發現越來越多朋友進來一起玩了！因此坐牢起來就覺得還行～

前言

近期在開發 LLM 應用時，常需要讓模型與網頁進行互動，無論是自動填寫表單、爬取資料或執行測試。過去這類任務往往依賴於截圖或視覺模型，不僅效率低下且易出錯。今天要介紹的 Playwright Model Context Protocol (MCP) 提供了一個全新的解決方案，讓 LLM 能夠直接透過結構化的方式與瀏覽器互動，大幅提升自動化效率。

前言

本來預計跨年就要來北海道，但在腳受傷之後，原先的計劃就泡湯，多了三個月的恢復期才來到的北海道。

這次安排了三天的滑雪日，一天一雪場的計畫，也將這次的內容記錄下來，給未來有需要的朋友參考看看喔！

前言

事情是這樣的，由於我跟家人個別有一台 PC，參考了巴哈上面的說法(URL)，為了省錢登入同樣的帳號，想說用離線模式就可以一起玩，但殊不知…操作上出了點失誤，結果我從 9/9 ~ 9/14 的記錄都消失(被覆蓋)，找了一下網路上的做法，看了檔案路徑中發現 Steam 居然有備份(超感動)，以下介紹一下如何救回來～