做完 remotetools（Telegram / Discord 版的手機遠端 Claude Code）之後，下一個自然的問題是：能不能接進 LINE？claude_linebot 就是答案。這篇講為什麼要做、以及 LINE 這個平台帶來的三個根本性難題如何反過來塑造了整個設計。
系列文：本篇（動機）→ 架構與實作 → 部署與 Cloudflare 設定。
動機：訊息軟體裝在哪，工具就該在哪
remotetools 已經證明「傳訊息 → 家裡電腦的 Claude Code 動起來」這個模式可行。但 Telegram 和 Discord 在台灣終究是「為了某個目的才裝」的 app——真正天天開著、通知永遠會看到的是 LINE。工具的價值跟「拿出來用的摩擦力」成反比：如果指揮家裡電腦這件事能發生在最常用的聊天軟體裡，它才會真的被用。
另一個動機是技術上的：LINE 的平台限制跟 Telegram/Discord 完全不同，移植過程等於強迫重新檢視原本設計裡哪些是本質、哪些只是平台恰好允許。
LINE 帶來的三個根本難題
| Telegram / Discord | LINE | |
|---|---|---|
| 連線方式 | long polling，躲在 NAT 後面就能跑 | webhook——必須有公開 HTTPS URL |
| 進度顯示 | 每 2 秒編輯同一則訊息做 streaming | 訊息發出後不能編輯 |
| 回覆成本 | 免費、無上限 | reply 免費但一次性，push 吃官方帳號月額度 |
難題一：webhook 表示你的電腦要露出在網路上
Polling 是 bot 主動去問「有沒有新訊息」，家裡電腦躲在 NAT 後面完全沒問題。LINE 只支援 webhook——LINE 的伺服器要能主動打到你，代表你需要一個公開的 HTTPS endpoint。這個專案用 Cloudflare Tunnel 解決：不開防火牆 port、不需要固定 IP，一條 outbound 連線把本機的 8000 port 安全地掛到公網上。這也是為什麼第三篇部署教學有一半篇幅在講 Cloudflare。
難題二：不能編輯訊息，streaming UI 整個作廢
Telegram/Discord 版最舒服的體驗是看著 bot 每兩秒更新「Claude 正在做什麼」。LINE 的訊息送出就是送出，不能改。替代方案是 LINE 的 loading animation（打字中動畫）——資訊量少得多，但至少讓你知道它還活著。這是平台限制下的誠實妥協。
難題三：回覆是要錢的
LINE 官方帳號免費方案每月只有固定則數的 push 訊息額度，但 reply（用一次性的 reply token 回覆）免費無上限。麻煩在於 reply token 約一分鐘就失效，而 Claude 跑一個任務動輒好幾分鐘。於是「怎麼回覆」變成一個經濟學問題：50 秒內跑完就用免費 reply，超過就認命扣一則 push；長回覆只送前五段，剩下的等你用 /more 拿（/more 是新訊息、帶新 token，所以免費）。這套決策邏輯（ReplyContext）是整個專案最精巧也最容易改壞的部分，下一篇細講。
設計原則：跟參考專案刻意保持一致
claude_linebot 不是從零開始，而是 remotetools 的有紀律的移植：指令名稱、state 檔格式、session/usage 語意刻意跟 Telegram/Discord 版完全一致。好處很實際——
- 兩邊可以互相對照，bugfix 可以同步（
claude_runner.py兩邊幾乎逐字元相同） - 使用者換平台不用重新學指令
- 「哪些不同」變得非常清楚：所有差異都是 LINE 平台特性逼出來的，不是隨手重新發明
它能做什麼
- 傳訊息就是 prompt，
--resume維持連續對話；1:1、每個群組、每個聊天室各自獨立的 session - 傳圖片和檔案：先貼圖再提問，Claude 會連圖一起看（這是 Telegram/Discord 版沒有的功能，因為 LINE 圖片沒有 caption，反而逼出了更通用的兩段式設計）
/project切換要操作的 repo、/model切換模型、/cancel中止、/retry重跑- 群組模式：訊息以
claude開頭才觸發，其他人正常聊天完全不受打擾 - fail-closed 白名單、每日/每分鐘用量上限、webhook 簽章驗證——安全模型與 remotetools 相同
留言