設計一個只負責記錄的 LINE 機器人，幫你我整理資料

TL;DR：專案討論散在好幾個 LINE 群組，手動匯出容易漏、容易忘。我做了一個記事機器人：入群時只發一句自我介紹，之後在群組裡只收不回；雲端只當中繼，本機腳本定時把訊息與附件拉回來，寫成跟手動匯出同格式的文字檔，放進專案資料夾。設計重點有四個：本機是唯一長期副本、寫入驗證後才通知雲端刪除、先收訊後分類、用心跳分辨「沒人說話」和「機器人壞了」。它做不到的事也要先說：進不了一對一對話、拿不到加入前的歷史，而且它存的是全文加附件，不是摘要。另外要老實說：我自己就遇到過資料夾放在雲端同步位置、寫入持續失敗的情形，細節在最後一節。

專案討論散在 LINE 群組裡，要怎麼留下來？

我同時待在好幾個專案群組。工作的決定、待辦、對方丟來的檔案，大多是在 LINE 裡發生的。

LINE 有手動匯出，能把一段對話存成文字檔。但每次都要有人記得執行，還要確認各個群組的紀錄有沒有更新。工作一忙，就可能少匯出一個群組，或漏掉一段時間的紀錄。之後要找那段期間的一句話，還得回到 LINE 裡一路往上翻。

我要的結果很單純：每個群組的對話，自動變成專案資料夾裡一份文字檔，格式跟手動匯出一樣，這樣舊檔和新檔可以接在一起。

一句話講完做法，加一張圖

做法一句話：用一個 LINE 官方帳號當收訊員，它入群那一句自我介紹之後，在群組裡就只收不說；訊息與附件先經雲端中繼暫存，再由我電腦上的腳本定時拉回，寫進專案資料夾。

它只有一個例外會開口：我在一對一對話裡用「傳送聊天記錄」分享給它時，它會回一則收據。它不回答問題，也不聊天。

flowchart LR
  A["LINE 群組"] --> B["官方帳號 webhook"]
  B -->|"驗簽、寫入、回 200"| C["雲端中繼（暫存）"]
  C -->|"定時拉取"| D["本機同步腳本"]
  D --> E["專案資料夾 LINE紀錄/群組名.txt"]
  D -->|"寫入並驗證後才通知刪除"| C

幾個名詞。webhook 是 LINE 把群組裡的每個事件即時推給你指定網址的機制，LINE 官方文件要求在處理事件之前先驗證簽章，文件說明在此。我的雲端這端是一支小函式，加一個暫存用的資料庫、放附件的物件儲存、記群組名稱的快取。本機這端是一支只用 Python 標準函式庫寫的同步腳本，我讓它每三小時跑一次。

這個架構裡，雲端不是檔案庫。它只是轉運站，檔案庫是我電腦上的資料夾。

想自己做，先從哪裡開始？

LINE 端的設定，可以先按這個順序讀官方文件。以下是官方英文說明，操作畫面與欄位以文件為準。

這些文件介紹的是 LINE 平台設定；要做出本文的記事流程，仍需要自己的收訊與同步程式。

雲端與本機的安裝，下面提供一般建議。我這套的實際完成狀態與未解問題，寫在文末。

雲端先分清楚接收、暫存與同步三個工作。 如果採用 Cloudflare，可以從 Workers 入門讀部署方式，以 D1暫存訊息、R2暫存附件。建議先用獨立專案測試，權限只開到這個專案所需的資源。收 LINE 事件的 webhook 必須讓 LINE 連得到，並在處理事件前驗簽；讓本機拉取資料、確認寫入的同步端則要另外驗證身分。網址難猜不能取代這兩種驗證。

憑證與附件都要有自己的存放方式。 LINE 的 channel secret、access token 和本機同步憑證分開保管，雲端敏感值使用 Workers Secrets，不要直接寫進程式或公開設定檔。本機只保留同步所需的憑證，限制能讀取它的帳號。附件儲存保持私有，避免開啟公開下載；R2 的公開存取說明列出哪些設定會把內容曝露到網路。訊息和附件的保存、清除規則要一起核對，避免一邊還在等待同步，另一邊已先到期。

本機先手動跑通，再交給排程。 選一個不同步到雲端、也不進版本庫的普通資料夾當寫入位置，確認執行腳本的帳號能讀寫。用系統排程定期執行時，要把同步或確認失敗寫進可檢查的日誌。備份另做一份、限制存取並加密，再實際試一次能否還原；讓資料夾避開雲端同步，只解決寫入位置的問題，不會自動產生備份。

測試要走到檔案真的落地。 先在測試群組傳一則不含個資的文字與一個測試附件，確認雲端收得到、本機寫得進去，內容也對得上。再測重複事件、暫時無法寫入、重新執行與確認失敗，檢查是否會漏、會重複，或太早清掉雲端資料。本機寫入結果與雲端收訊狀態分開檢查，不能只看 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 參考文件）。所以自動說明的文字，要在機器人第一次進群組之前就定好。

LINE 開發者的使用者資料政策對這類資料的處理另有規定，政策原文在此。這篇文章不對合規與否下結論，也不替任何人的情況背書。要做的人請自己讀完，再決定怎麼告知。

四個設計決策與理由

一、雲端只當中繼，本機是唯一長期副本。 我不想讓另一份完整對話長期留在雲端。代價是備份變成我自己的工作：資料夾壞了，就沒有第二份。這個取捨我在設計時就接受了，所以資料夾要照備份習慣處理。

二、同步順序固定，失敗整批留著。 腳本的順序是：從雲端拉取（唯讀）、寫入檔案、驗證寫入、更新本機紀錄，最後才通知雲端刪除。拉取與通知刪除是兩個分開的請求。任何一步失敗，雲端那批就不刪，下一輪重拉；本機另有一份已寫入編號清單，擋掉重複寫入。原則是寧可重複，不會遺失。這是我設計出來的行為，不是對結果的保證，所以才需要第一點的備份。

三、先收訊，後分類。 還沒登記的群組，訊息一律先落進 _未分類 資料夾，之後再登記路由：依群組編號對應專案，或依檔名片段對應專案。這樣新群組不必先設定才能收訊息，忘了設定也不會漏訊息，只是檔案暫時躺在未分類。輸出檔名由群組名稱決定，如果跟手動匯出時的檔名不同，同一場對話就會被拆成兩個檔。遇到這種情形要合併，不要並存。

四、用心跳分辨「沒人說話」和「機器人壞了」。 機器人被移出群組，或憑證失效，從外面看起來都只是「這個群組很安靜」。所以腳本每輪都會報告最後一筆事件是幾小時前，超過三天沒有任何事件就發出警告。另外它會列出近七天的加入與移出事件，以及還沒同步的筆數；LINE 不會告訴你是誰把機器人移出去，這一點要有心理準備。心跳有一個範圍要講清楚：它量的是雲端有沒有收到事件，本機這一段的寫檔失敗，它看不到，那一段只會留在同步日誌裡，要有人去讀。這個做法和我之前寫過的巡檢的那一支自己壞掉是同一個問題：沒有事件，要能分辨是真的沒事，還是看不見。

五個最反直覺的坑

一、名稱要讓不同語言的夥伴看得懂。 我第一個帳號用了純中文名稱。帳號加進有外國夥伴的群組後，對方看不懂這是什麼帳號，我後來換了新帳號。現在的建議是名稱取英文或中英並列，一看就知道用途。更名規則要另外看帳號類型：依 LINE 台灣官方說明，未認證的一般帳號可以自行更名，改完七天內不能再改；認證帳號若需要更名，則要向 LINE 審核團隊提出申請。

二、貼密鑰時用 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）。群組裡已經有別家官方帳號時，你的機器人是加不進去、還是加入後被移出，會不會有提示，文件那一段沒有寫，我也沒有實測，這一點待確認。邀請之前，先看一眼成員名單。

存下來的紀錄怎麼用：以每週工作報告為例

我在一個非營利組織擔任職務，每週要交一份工作報告。進度與待辦的主要來源，就是各個 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 的兩輪排程都沒有出現同步錯誤，但兩輪都沒有新訊息，因此這只能證明排程有跑，還不能據此判定有新資料時會持續正常寫入。雲端附件儲存庫的生命週期規則也仍未查證，所以我還不能把這次修復寫成「沒有遺失」。

最後講不適合的情境。以下是我的判斷，不是測試結論：如果你沒辦法向群組成員講清楚存什麼、存在哪、誰看得到，這個機器人就不該進那個群組。如果你需要的是多人共用、即時全文檢索的團隊知識庫，一份放在個人電腦上的文字檔不是對的形狀。

程式碼不公開，想要的人可以找我。更多一人公司的實作紀錄，在創業與實作主題頁。