兩個月零當機 — 我把 Telegram 變成 Claude Code 的指揮中心，學到 4 件事
大多數人的個人 AI 助理活不過一週
如果你用過 Claude Code、Cursor、或任何「桌面 AI 助理」一段時間，你會發現一個共通模式：
剛裝好的前 3 天，興奮。 一週後，遇到一次小 bug 或關機重開，AI 突然斷線。 兩週後，你發現它只在「你坐在電腦前」才有用 — 出門就斷掉。 一個月後，你已經懶得開了。
我一直懷疑是不是只有我這樣。後來跟其他 solo founder 聊，發現幾乎大家都一樣。AI 助理變成「我可以打開那個視窗問問題」的工具，而不是「我隨時可以下指令的指揮系統」。
兩個月前，我做了一個有點極端的設計選擇 — 把 Telegram 變成 Claude Code 的主控介面，而不只是輸出 channel。
到今天剛好 60 天。零次當機（小 incident 都被自動處理掉沒到我面前）。在德國旅行的兩週、半夜睡覺、廁所裡、餐廳排隊時 — 我隨手打開 TG 就能 drive 8 個 AI agent 的艦隊。
這篇把這 60 天我學到的事完整 dump 出來。文末有開源的 toolkit（MIT License），你可以直接 fork。
設計選擇 #1：Telegram 是指揮台，不是輸出 channel
大多數人把 Claude Code 當「工具」用 — 坐在桌前，打開 VS Code，在 Claude chat panel 裡打字、讀回應。離開桌子，就失去了 AI。
我的設定相反：Telegram 是主要介面。Claude 透過官方 telegram MCP plugin 讀我傳的 TG 訊息、用 TG reply 回應，桌面終端機只是其中一個可能的 session runner。
這意味著我可以：
- 在公車上手機打字
- 跨時區從旅館房間打字
- 一邊煮飯一邊用平板打字
- 坐在桌前用 terminal 打字
四種路徑都流經同一個 channel。只有一份歷史紀錄（TG chat history），不是「我今天在不同 surface 上跟 AI 有過的 session 碎片」。
下游後果：每個 Claude 產生的 substantive deliverable 都必須 mirror 到 TG，不只是印在終端。忘記這條規則就是 failure mode #1（後面會講我怎麼自動偵測它）。
設計選擇 #2：可靠性是分層的，不是單點
Windows 上的 Telegram 會用很多種具體的方式掛掉。沒有任何單一失敗會致命，但任何一種都會讓你「指揮台」當天 GG。
我的設定堆了 4 層防線，每層擋不同類的失敗：
| 層 | 防什麼 |
|---|---|
| 開機腳本 + 靜默 launcher | Windows 重開機後 Claude 永遠 offline（Startup 資料夾任何 .bat 都會跳 console；用 .vbs 隱藏起來） |
zombie-killer.ps1（每 2 分鐘排程） |
兩個 bun.exe 都在 poll getUpdates，inbound 訊息隨機掉進舊 zombie 進程 — 靜默部分故障 |
| Liveness watchdog | 單一 bun.exe 看起來 alive 但其 websocket 卡死 — Telegram getWebhookInfo 顯示 inactive |
tg-mirror-check.py（今天才裝的 hook） |
Claude 透過終端回答你的 TG 問題 — 但你手機什麼都沒收到 |
沒有任何單一層能擋全部。重點是 layers covering distinct failure classes，不是「盡力做到可靠」。
真實 incident #1：兩個 bun.exe 偷訊息
第一次遇到是某天早上，我在 TG 問 Claude 「昨晚的 fleet report 結論是什麼」。等了 10 分鐘沒回，覺得奇怪。然後我發了第二則「在嗎？」 — 又等 10 分鐘。
打開終端機看 process list — 兩個 bun.exe 都在跑。其中一個是我前晚開過的 VS Code Claude session 殘留的 zombie，另一個是當下這個 session 的。兩個都在 poll Telegram getUpdates，輪流搶我的訊息。第一則訊息被 zombie 接走，扔進 nowhere。
修法不是「殺 bun」— 那是治標。治本是讓 zombie-killer 每 2 分鐘巡邏，看到超過一個 wrapper 就殺舊的。寫了 60 行 PowerShell，從此沒再遇到這問題。
真實 incident #2：6 次 TG-forget
今天最爽的 incident — 我自己 6 次在大段工作後忘了把回答 mirror 回 TG。原因：在大量 Bash/Edit/Read 工具呼叫之間切換到「回答老闆問題」時，我預設用 markdown 印在 transcript 裡。
老闆每次都要 catch 我（「你又沒回 TG??」），這對 trust 是消耗。
修法：寫了一個 Stop hook（每次 assistant turn 結束自動跑）：
條件：
- 上一則 user message 含 <channel source="plugin:telegram:telegram">
- 我的 response 沒呼叫 mcp__plugin_telegram_telegram__reply
→ 直接透過 TG bot API 推 ⚠️ 警告給用戶
裝完當天，0 次 漏發 — 因為知道有 hook 在看，紀律突然回來。系統性問題用系統性解法。
設計選擇 #3：兩個 stateless workaround
LLM session 本質 stateless。每次新 Claude Code session 從零開始 — 不記得昨天聊什麼、不知道你手上哪些 project。
我的設定有兩件事配合 Claude Code 內建的 memory file 系統來繞過這點：
| 元件 | 保留什麼 |
|---|---|
tg-log.py inject (SessionStart hook) |
最近 ~20 則 TG 訊息 — 自動注入每個新 session 開頭，所以助理直接從你停的地方接 |
你自己的 ~/.claude/projects/<project>/memory/ markdown 檔 |
長期事實：用戶身份、feedback 修正、project 狀態、外部系統 reference。手動策展，非自動生成。 |
兩者合起來：新 session 開始時 就有：短期 TG 歷史（從 inject hook）+ 長期 curated memory（從你的 memory 資料夾）。淨效果是助理感覺有狀態，雖然本質沒有。
我的 memory 累積到目前 60+ 筆。包括：
- 我是誰（一人公司、語言偏好、客戶名單）
- 過去 incident（哪些 PR 不該再開、哪個用戶被 escalate 過）
- 專案脈絡（UDomain 6/1 規格、Germany trip 反思、UltraProbe portfolio）
- Anti-patterns（哪些 framing 我不要再用、哪些技術 trap 不要踩）
每次重大 incident 變成一條 memory。慢慢累積，AI 對我的理解越來越精確。
設計選擇 #4：先鎖通道再信任它
Telegram bot 預設開放 — 任何知道 bot username 的人都能 DM 它。讓 Claude Code 在另一頭接，就是等著被 prompt injection 攻擊。
官方 telegram MCP plugin 已支援 allowlist（access.json 含 allowFrom）+ dmPolicy: pairing 設定，要求你手動 approve 每個新對話。在你把任何重要東西放進 bot 之前，先 set 這兩個。
這是容易忽略的攻擊面。我 day 1 就鎖了。沒有它，今天 Claude 可能在某個被釣到的 prompt injection 裡幫陌生人 leak 客戶資料。
Adversarial reviewer — 對抗 confirmation bias 的最後一道
寫完 v3 architecture 文件、ship 出去之後，我問自己：「這份夠專業齁？不會被人家看破手腳吧？」
問題是：我自己寫的東西，我自己 review 永遠有 confirmation bias。看了 10 遍都看不出 bug。
所以我寫了一個 critic agent。它的單一工作是「找洞」 — 用 grep / curl / Read / WebFetch 實際 verify 每個 claim。不准 hand-wave。找不到問題就直接說「找不到」，不准假裝有問題。
第一次用在我自家剛寫的 OSS repo 上（就是本文末尾要分享的那個）。它抓到 2 個 CRITICAL bug：
- 我的 hook 安裝步驟用
~/.claude/hooks/...寫 path — 但 Windows cmd / Python 都不會展開~。所有新用戶照我文件裝會靜默 no-op。 - 我把自己的 Telegram chat_id
781284060leak 進兩個檔案。第一個 fork 的用戶會配置成 alert 我手機。
如果我直接 merge，這 OSS repo 第一天就會難用。Critic 救了我一次。
這是這次驗證最有意義的事：critic 真的會放行品質有問題的東西嗎？答案是不會 — 它把 verdict 設成 BLOCK，我必須先修才能 merge。如果 critic 對自家設定就放水，未來對 deliverable 就更不可信。
60 天真實失敗紀錄
最後給數據。這是 4 層防線都上線後，過去 60 天的失敗模式 + 頻率：
- TG-forget (6 incidents)：我用終端答用戶但忘了 mirror。今天裝 hook 解決。
- 手機 TG sync 異常 (2 incidents)：Telegram 在手機上幾小時不同步。解法：force-close 手動重啟 app。伺服器端沒有 tooling 能修這個。
- Zombie bun 進程 (~每週，自動處理)：被
zombie-killer.ps1每 2 分鐘巡邏抓掉。沒任何一次到達用戶層。 - Windows 重開機 (計劃 + 臨時)：開機腳本自動恢復。零手動動作。
60 天就這些。其他都是 noise。
老實說，這個設定 NOT 解決什麼
避免讀者誤會：
- Cost / token 用量監控：這設定不告訴你 Claude API token 燒了多少。重度用戶要自己做 cost dashboard。
- 多裝置冗餘：手機 TG sync 在旅行時掛了，指揮台就 offline 到你能開瀏覽器或重啟 app。有些用戶用 email mirror / Discord 第二 channel 解。我還沒做（cow 是現成備援足夠用）。
- 輸出正確性：這設定讓 Claude 可達，不讓 Claude 對。critic agent 是針對這個的工具，但它需要你主動 invoke。
承認問題，比假裝沒問題好。
怎麼複製：開源 toolkit
完整 toolkit 開源在：https://github.com/ppcvote/claude-tg-windows
claude-tg-windows/
├── boot-scripts/ # Phase 1: 開機 + 靜默 launcher
├── scripts/ # Phase 1: zombie-killer + health-check
├── hooks/ # Phase 2: tg-log + tg-mirror-check (今天加的)
├── agents/ # Phase 2: critic.md
├── examples/ # Phase 2: settings.json 模板
├── docs/ # workflow-architecture.md + setup-walkthrough.md
└── install.ps1 # 一鍵 Phase 1 安裝
安裝步驟（Phase 1 + Phase 2 加起來約 20-25 分鐘）：
git clone https://github.com/ppcvote/claude-tg-windows.git
cd claude-tg-windows
powershell -ExecutionPolicy Bypass -File .\install.ps1
# 接著手動執行 docs/setup-walkthrough.md 的 Phase 2 步驟
前置條件：Windows 10/11、Claude Code 已裝且 telegram MCP plugin 已 configure、Bun on PATH、Git for Windows、Python 3.9+。
MIT License。歡迎 fork、PR、報 bug。
一句話收尾
個人 AI 助理活不過一週的根本原因不是技術不夠強，是設計選擇錯了。
把它當「工具」，它就是工具 — 開著的時候有用，關了就沒。 把它當「指揮台」，它就是指揮台 — 24/7 在線，從你口袋裡能 drive。
差別在 4 個設計選擇 + 4 層防線 + 2 個 stateless workaround + 1 個 adversarial reviewer。code 加起來不到 1000 行。
如果你也是 solo founder / 一人公司，這套值得花 25 分鐘裝起來。
Min Yi · Ultra Lab 創辦人。MDRT 美國百萬圓桌會員 × AI 安全開源貢獻者（Microsoft / Cisco / OWASP / UK Gov AISI 11 個 PR merged）。在 Telegram 上 7×24 接客戶問題 + drive 8 個 AI agent fleet。