# 設計一個只負責記錄的 LINE 機器人，幫你我整理資料
> 專案討論散在好幾個 LINE 群組，手動匯出容易漏、容易忘。我用一個入群只自我介紹一句、在群組裡只收不回的官方帳號，加上雲端中繼與本機同步，把對話與附件存成跟手動匯出同格式的檔案。這篇記下架構、四個設計決策、五個踩過或繞過的坑、它在每週工作報告裡怎麼被用到，以及我自己實際遇到的同步失敗。
- Author: Paul Kuo（郭曜郎）
- Date: 2026-10-02
- Pillar: 創造與建構 / Creation & Enterprise
- Tags: LINE, 記事機器人, 自動化, 資料留存, 一人公司, 實錄
- Canonical: https://paulkuo.tw/articles/line-note-taker/
- Site index for LLMs: https://paulkuo.tw/llms.txt
---
> **TL;DR**：專案討論散在好幾個 LINE 群組，手動匯出容易漏、容易忘。我做了一個記事機器人：入群時只發一句自我介紹，之後在群組裡只收不回；雲端只當中繼，本機腳本定時把訊息與附件拉回來，寫成跟手動匯出同格式的文字檔，放進專案資料夾。設計重點有四個：本機是唯一長期副本、寫入驗證後才通知雲端刪除、先收訊後分類、用心跳分辨「沒人說話」和「機器人壞了」。它做不到的事也要先說：進不了一對一對話、拿不到加入前的歷史，而且它存的是全文加附件，不是摘要。另外要老實說：我自己就遇到過資料夾放在雲端同步位置、寫入持續失敗的情形，細節在最後一節。
## 專案討論散在 LINE 群組裡，要怎麼留下來？
我同時待在好幾個專案群組。工作的決定、待辦、對方丟來的檔案，大多是在 LINE 裡發生的。
LINE 有手動匯出，能把一段對話存成文字檔。但每次都要有人記得執行，還要確認各個群組的紀錄有沒有更新。工作一忙，就可能少匯出一個群組，或漏掉一段時間的紀錄。之後要找那段期間的一句話，還得回到 LINE 裡一路往上翻。
我要的結果很單純：每個群組的對話，自動變成專案資料夾裡一份文字檔，格式跟手動匯出一樣，這樣舊檔和新檔可以接在一起。
## 一句話講完做法，加一張圖
做法一句話：用一個 LINE 官方帳號當收訊員，它入群那一句自我介紹之後，在群組裡就只收不說；訊息與附件先經雲端中繼暫存，再由我電腦上的腳本定時拉回，寫進專案資料夾。
它只有一個例外會開口：我在一對一對話裡用「傳送聊天記錄」分享給它時，它會回一則收據。它不回答問題，也不聊天。
Paul's Note Taker 的名稱與頭像。這張圖介紹帳號外觀。
```mermaid
flowchart LR
A["LINE 群組"] --> B["官方帳號 webhook"]
B -->|"驗簽、寫入、回 200"| C["雲端中繼（暫存）"]
C -->|"定時拉取"| D["本機同步腳本"]
D --> E["專案資料夾 LINE紀錄/群組名.txt"]
D -->|"寫入並驗證後才通知刪除"| C
```
幾個名詞。webhook 是 LINE 把群組裡的每個事件即時推給你指定網址的機制，LINE 官方文件要求在處理事件之前先驗證簽章，[文件說明在此](https://developers.line.biz/en/docs/messaging-api/receiving-messages/)。我的雲端這端是一支小函式，加一個暫存用的資料庫、放附件的物件儲存、記群組名稱的快取。本機這端是一支只用 Python 標準函式庫寫的同步腳本，我讓它每三小時跑一次。
這個架構裡，雲端不是檔案庫。它只是轉運站，檔案庫是我電腦上的資料夾。
## 想自己做，先從哪裡開始？
LINE 端的設定，可以先按這個順序讀官方文件。以下是官方英文說明，操作畫面與欄位以文件為準。
| 想完成的事 | 官方說明與閱讀重點 |
| --- | --- |
| 建立官方帳號、啟用收訊功能 | [Get started with the Messaging API](https://developers.line.biz/en/docs/messaging-api/getting-started/)：先建立 LINE 官方帳號，再從 Official Account Manager 啟用 Messaging API，之後到 Developers Console 管理通道。 |
| 準備憑證、設定與測試 webhook | [Build a bot](https://developers.line.biz/en/docs/messaging-api/building-bot/)：說明 channel access token、HTTPS webhook 網址、Verify 與 Use webhook，也有歡迎訊息和自動回覆的設定。只想記錄的用途，要特別看這些回覆設定。 |
| 讓機器人加入群組 | [Group chats and multi-person chats](https://developers.line.biz/en/docs/messaging-api/group-chats/)：說明 Allow bot to join group chats 開關，以及群組事件如何送到機器人。 |
| 確認收到的事件來自 LINE | [Verify webhook signature](https://developers.line.biz/en/docs/messaging-api/verify-webhook-signature/)：說明用 channel secret 驗證簽章；驗證前不能先改寫或重新組合請求內容。 |
我的帳號設定畫面：截圖當下允許帳號加入群組，也開放聊天中的媒體與檔案傳送。webhook 收訊與本機落檔仍需另外設定與驗證。
這些文件介紹的是 LINE 平台設定；要做出本文的記事流程，仍需要自己的收訊與同步程式。
雲端與本機的安裝，下面提供一般建議。我這套的實際完成狀態與未解問題，寫在文末。
**雲端先分清楚接收、暫存與同步三個工作。** 如果採用 Cloudflare，可以從 [Workers 入門](https://developers.cloudflare.com/workers/get-started/guide/)讀部署方式，以 [D1](https://developers.cloudflare.com/d1/get-started/)暫存訊息、[R2](https://developers.cloudflare.com/r2/get-started/)暫存附件。建議先用獨立專案測試，權限只開到這個專案所需的資源。收 LINE 事件的 webhook 必須讓 LINE 連得到，並在處理事件前驗簽；讓本機拉取資料、確認寫入的同步端則要另外驗證身分。網址難猜不能取代這兩種驗證。
**憑證與附件都要有自己的存放方式。** LINE 的 channel secret、access token 和本機同步憑證分開保管，雲端敏感值使用 [Workers Secrets](https://developers.cloudflare.com/workers/configuration/secrets/)，不要直接寫進程式或公開設定檔。本機只保留同步所需的憑證，限制能讀取它的帳號。附件儲存保持私有，避免開啟公開下載；R2 的[公開存取說明](https://developers.cloudflare.com/r2/buckets/public-buckets/)列出哪些設定會把內容曝露到網路。訊息和附件的保存、清除規則要一起核對，避免一邊還在等待同步，另一邊已先到期。
**本機先手動跑通，再交給排程。** 選一個不同步到雲端、也不進版本庫的普通資料夾當寫入位置，確認執行腳本的帳號能讀寫。用系統排程定期執行時，要把同步或確認失敗寫進可檢查的日誌。備份另做一份、限制存取並加密，再實際試一次能否還原；讓資料夾避開雲端同步，只解決寫入位置的問題，不會自動產生備份。
**測試要走到檔案真的落地。** 先在測試群組傳一則不含個資的文字與一個測試附件，確認雲端收得到、本機寫得進去，內容也對得上。再測重複事件、暫時無法寫入、重新執行與確認失敗，檢查是否會漏、會重複，或太早清掉雲端資料。本機寫入結果與雲端收訊狀態分開檢查，不能只看 webhook 測試成功或心跳正常。
如果要把安裝筆記公開，網址、帳號、群組與儲存資源名稱都用示意值，畫面也改用測試環境；不要附上真實憑證、完整設定檔或含對話內容的日誌。讀者需要的是如何設定與驗證，不需要照抄我的實際部署資訊。
## 該怎麼向群組成員交代這個機器人？
這一節要先講原則，再講我的做法。
機器人加進群組的那一刻，會自動發一句話。我刻意只發一句：
> I'm Paul's note-taking assistant, responsible for summarizing work activities. I do not participate in conversations.
中文大意是：我是 Paul 的記事助理，負責彙整工作動態，不參與對話。
有一次把它加進群組，兩分鐘後，我補充了一句：
> 這是幫我做工作紀錄的AI只會記錄不會發文。各位請放心。
一位成員回了「好強大」，接著直接標記機器人，用英文問它能如何協助整理資訊、連結想法，以及把洞見變成可執行的成果。他也問我：「他會回答嗎」。我回答：「有下了 咒術禁制。所以不會回答。」意思就是：它在群組裡負責記錄，不會回應提問。
不過，英文的「summarizing」容易讓人以為它只留下摘要，「做工作紀錄」也還沒有完整說明保存的內容。機器人實際存下的是對話全文，群組裡傳送的附件也會一併存下來；彙整成工作報告，是後續把紀錄交給 AI 整理的另一個步驟。這段入群說明交代了用途與角色，但保存位置、誰能讀取、保存多久，以及後續如何交給 AI 整理，都還需要另行向成員說明。
官方帳號發出去的訊息，沒有辦法事後改或收回：Messaging API 參考文件列出的訊息端點只有送出與統計這幾類，沒有修改或收回已發出訊息的端點；文件裡的 unsend 事件是使用者收回自己的訊息時通知機器人，不是機器人收回自己的訊息（[API 參考文件](https://developers.line.biz/en/reference/messaging-api/#unsend-event)）。所以自動說明的文字，要在機器人第一次進群組之前就定好。
LINE 開發者的使用者資料政策對這類資料的處理另有規定，[政策原文在此](https://terms2.line.me/LINE_Developers_user_data_policy)。這篇文章不對合規與否下結論，也不替任何人的情況背書。要做的人請自己讀完，再決定怎麼告知。
## 四個設計決策與理由
**一、雲端只當中繼，本機是唯一長期副本。** 我不想讓另一份完整對話長期留在雲端。代價是備份變成我自己的工作：資料夾壞了，就沒有第二份。這個取捨我在設計時就接受了，所以資料夾要照備份習慣處理。
**二、同步順序固定，失敗整批留著。** 腳本的順序是：從雲端拉取（唯讀）、寫入檔案、驗證寫入、更新本機紀錄，最後才通知雲端刪除。拉取與通知刪除是兩個分開的請求。任何一步失敗，雲端那批就不刪，下一輪重拉；本機另有一份已寫入編號清單，擋掉重複寫入。原則是寧可重複，不會遺失。這是我設計出來的行為，不是對結果的保證，所以才需要第一點的備份。
**三、先收訊，後分類。** 還沒登記的群組，訊息一律先落進 `_未分類` 資料夾，之後再登記路由：依群組編號對應專案，或依檔名片段對應專案。這樣新群組不必先設定才能收訊息，忘了設定也不會漏訊息，只是檔案暫時躺在未分類。輸出檔名由群組名稱決定，如果跟手動匯出時的檔名不同，同一場對話就會被拆成兩個檔。遇到這種情形要合併，不要並存。
**四、用心跳分辨「沒人說話」和「機器人壞了」。** 機器人被移出群組，或憑證失效，從外面看起來都只是「這個群組很安靜」。所以腳本每輪都會報告最後一筆事件是幾小時前，超過三天沒有任何事件就發出警告。另外它會列出近七天的加入與移出事件，以及還沒同步的筆數；LINE 不會告訴你是誰把機器人移出去，這一點要有心理準備。心跳有一個範圍要講清楚：它量的是雲端有沒有收到事件，本機這一段的寫檔失敗，它看不到，那一段只會留在同步日誌裡，要有人去讀。這個做法和我之前寫過的[巡檢的那一支自己壞掉](/articles/agentic-operations-silent-failure/)是同一個問題：沒有事件，要能分辨是真的沒事，還是看不見。
## 五個最反直覺的坑
**一、名稱要讓不同語言的夥伴看得懂。** 我第一個帳號用了純中文名稱。帳號加進有外國夥伴的群組後，對方看不懂這是什麼帳號，我後來換了新帳號。現在的建議是名稱取英文或中英並列，一看就知道用途。更名規則要另外看帳號類型：依 [LINE 台灣官方說明](https://tw.linebiz.com/faq/shop-store/shop96/)，未認證的一般帳號可以自行更名，改完七天內不能再改；認證帳號若需要更名，則要[向 LINE 審核團隊提出申請](https://tw.linebiz.com/faq/oa-operation/28/)。
**二、貼密鑰時用 `echo`，會得到難以理解的 401。** `echo` 會在尾端多帶一個換行，送進 HTTP 標頭後變成非法字元，症狀只是驗證失敗。我為此排查過很久。要用互動式輸入，或 `printf %s` 把值送進去。
**三、403 和 401 是兩回事。** 沒帶自訂 User-Agent 的請求，有時會在到達自己的函式之前，就被雲端平台層的機器人規則擋成 403。自己的函式只會回 401，所以看到 403，先懷疑平台層，不是密鑰。同步腳本裡已經處理了。
**四、日誌放在桌面，背景排程會啟動失敗。** 我踩過：排程的日誌檔放在桌面，系統因為權限標記，讓排程根本起不來。日誌要放在 `~/Library/Logs/` 底下，不要放在桌面或受雲端同步的資料夾。
**五、一個群組同一時間只能有一個 LINE 官方帳號。** 這是平台限制，不是我踩到的。官方文件寫的是「At any time, only one LINE Official Account can be in a group chat or multi-person chat」（[Group chats and multi-person chats](https://developers.line.biz/en/docs/messaging-api/group-chats/)）。群組裡已經有別家官方帳號時，你的機器人是加不進去、還是加入後被移出，會不會有提示，文件那一段沒有寫，我也沒有實測，這一點待確認。邀請之前，先看一眼成員名單。
## 存下來的紀錄怎麼用：以每週工作報告為例
我在一個非營利組織擔任職務，每週要交一份工作報告。進度與待辦的主要來源，就是各個 LINE 群組的紀錄。記事機器人存下來的資料夾，就是這份報告的原料。
流程大致是這樣：每週讓 AI 讀整個 `LINE紀錄` 資料夾，掃的是整個資料夾，不是寫死幾個群組名，所以新增的群組會自動納入。AI 產出一份草稿，包含 Markdown 版、PDF 版，以及一則準備貼回群組的訊息草稿。草稿由我審過才送，這是我給自己定的規矩。
把紀錄交給 AI 之前，有兩條紀律是踩過才補上的。
**第一，先檢查每份匯出檔的更新狀態。** 取材前先看檔案最後更新時間，再看檔案裡最後一則訊息的日期。若紀錄停在報告區間的前幾天，要標出待確認的範圍，核對同步日誌或 LINE 裡的原始對話。群組可能真的沒有新訊息，也可能是匯出或同步落後；還沒確認前，不能讓 AI 把這段空白寫成「沒有進度」。
**第二，儀表板空白不等於沒有進度，以本機檔案為準。** 有一次，我的草稿只讀了線上儀表板，寫出「本區間無新增交付」，但本機資料夾當時有大量異動。儀表板只反映有人記得去填的部分，檔案反映實際發生的事。
另外一個小坑：如果資料夾放在會自動同步到雲端的位置，檔案可能處於還沒下載的佔位狀態，讀取會失敗，錯誤訊息是 `Resource deadlock avoided`。讀之前要先用 `brctl download` 把檔案拉下來。同一個原因也會讓機器人寫檔失敗，我自己的狀況見下一節。
## 它做不到什麼？哪些情境不該用？
先講平台限制，這幾條沒有繞法：
- **進不了兩個真人的一對一對話。** 只能由我本人在 LINE 裡用「傳送聊天記錄」分享給機器人。機器人只會下載我本人分享的 `.txt`；如果分享進來的檔案比電腦上現有的檔案小，腳本不會覆蓋原檔，而是另存一份 `.incoming.txt` 讓我自己比對。
- **拿不到加入之前的歷史。** 加入前先手動匯出一次當基線。
- **成員沒同意提供個人檔案時，名字會顯示成「未知成員(xxxxxxxx)」。** 這是常態，不是故障，也不要去猜是誰。
- **LINE 上的檔案有保存期限。**
再講設計上的限制：本機是唯一長期副本，沒有備份習慣的人，這個架構等於把風險放在自己身上。如果資料夾放在雲端同步位置、檔案處於佔位狀態，寫入會失敗；腳本的行為是不通知雲端、下一輪再拉，不是當場補救。
**這一條我自己踩到了，10/2 當天才修。** 以下先是我修之前查本機同步日誌與資料夾的結果，修法與結果寫在最後。
- **失敗從 8/20 就出現，8/27 起明顯變多。** 日誌裡的錯誤是 `Resource deadlock avoided`。我用「每輪有幾個檔案寫不進去」來看，因為每天跑的輪數不固定（2 到 12 輪）。8/20 到 8/26，平均每輪約 0.3 到 3 個；8/27 起多半是每輪 4 到 13 個，10/1 是 13 個，10/2 是 12 個。只有 9/13 那一天，跑了 7 輪，一個失敗都沒有。
- **原因我判斷是桌面被同步到雲端。** 我的專案資料夾放在桌面，桌面有開雲端同步。10/2 那一輪寫不進去的 12 個檔案，全部都是還沒下載的佔位檔；`LINE紀錄` 底下 33 個文字檔裡，有 22 個是佔位檔。失敗的不只是 `_未分類`，專案資料夾底下的檔案也有。
- **它是部分失敗，不是全停。** 9/28 跑了 8 輪，其中 5 輪有寫進紀錄。但 10/2 上午 11:20 那一輪，從雲端拉到 687 則，12 個檔案都寫入失敗，本次寫入 0 則。10/1 到 10/2 我看的幾輪，每輪也都拉到六百多則，全部標成「新的」，符合同一批沒有被確認、一直留在雲端的行為。
- **心跳全程顯示正常。** 我查了 8/19 到 10/2 的全部日誌，258 行心跳，沒有任何一行不是「正常」。心跳只量雲端有沒有收到事件，雲端一直在收，它就一直正常；本機寫不進去，只會出現在同步日誌裡。
訊息有沒有遺失，我的判斷分兩層。照 Worker 程式碼，雲端暫存的資料只有在本機確認寫入後才會刪，我沒看到到期清除的程式碼；所以設計上，那批訊息應該還在雲端。但雲端附件儲存庫有沒有另外設定的保存期限，我沒有查，也還沒逐筆核對過。所以我只能說設計是這樣，不能說沒有遺失。
修法是把兩類紀錄資料夾（群組文字紀錄、群組附件）搬出有雲端同步的桌面，改放不同步、也不進版控的普通資料夾，腳本本身只改了一個路徑設定。搬之前我先把 572 個檔案逐一複製，核對每個檔案的大小相符，才切換。切換後我當場跑一輪：從雲端拉到 722 則，全部寫入，其中 89 個附件也存下來，寫入失敗 0 個，雲端確認並清空 722 筆；緊接著再跑一輪，沒有再拉到任何東西。這只證明積壓的那一批已經落到本機，不等於「沒有遺失」：修之前那幾週，有沒有訊息在保存期限到期前就沒了，我沒有逐筆核對。
截至 2026 年 10 月 3 日，還有兩件事沒解決：新位置的紀錄還沒有另行安排備份；心跳仍只看雲端有沒有收到事件，本機寫入失敗依然要查同步日誌。10/3 凌晨 02:46、05:51 的兩輪排程都沒有出現同步錯誤，但兩輪都沒有新訊息，因此這只能證明排程有跑，還不能據此判定有新資料時會持續正常寫入。雲端附件儲存庫的生命週期規則也仍未查證，所以我還不能把這次修復寫成「沒有遺失」。
最後講不適合的情境。以下是我的判斷，不是測試結論：如果你沒辦法向群組成員講清楚存什麼、存在哪、誰看得到，這個機器人就不該進那個群組。如果你需要的是多人共用、即時全文檢索的團隊知識庫，一份放在個人電腦上的文字檔不是對的形狀。
程式碼不公開，想要的人可以找我。更多一人公司的實作紀錄，在[創業與實作主題頁](/topics/startup/)。