MindThread 56 個帳號的真實 metrics — 跑兩年才看到的 3 個 pipeline bugs
MindThread 56 個帳號的真實 metrics — 跑兩年才看到的 3 個 pipeline bugs
我寫這篇的時候，飛機剛起飛。今天早上在桃機 Gate C2 等登機時，我請 Claude 派了個 agent 對 MindThread 的 56 個帳號做完整健檢。30 天 metrics、3,191 字的報告。
結果：我發現了 3 個我自己都不知道存在的 pipeline bugs。
這篇講這個故事，順便講「自己的 SaaS 跑兩年，第一次認真看裡面是什麼樣的感覺」。
規模 vs 我的認知
我自己的 CLAUDE.md 寫 MindThread 有「2 members, 16 accounts」。
實際看 threads_config.json：
- 56 個帳號
- 37 個 enabled
- 30 天內有 30+ 個帳號在發文
「我以為 16，實際 37 在跑」這個落差來自：我寫 doc 時是 6 個月前，沒同步到現實。又是一個 documentation drift。
更具體的活動度：
| 帳號 | 30d 篇 | 30d 讚 | 粉絲 | 最高 views |
|---|---|---|---|---|
| GinRollBT（業務導師） | 140 | 13,437 | 6,896 | 1.35M |
| 2021newken | 303 | 1,785 | 145 | 81K |
| oliewei（社群專家） | 132 | 637 | 310 | 41K |
| universe_signal_tw | 181 | 1,780 | 160 | 2.4K |
| workplace_truth_tw（社畜） | 175 | 891 | 760 | 11K |
第一名帳號單月讚數 13,437，這是 MindThread 跑了兩年才到的點。但我沒有「主動運營」過任何一個帳號。它們都是 AI 自動寫、自動發、自動回。
Bug #1：GinRollBT 發過空字串
最高互動的帳號，過去 30 天內 post 過：
""（空字串，0 字）"1"（單個數字，1 字）
兩篇加起來收到 0 讚 0 互動 0 觸及。
問題出在哪：MindThread 的 pipeline 是「Gemini → 內容 → posting API」。如果 Gemini 回傳空 / 無效內容，pipeline 沒有 skip-on-empty 守則，所以 "" 被當成正常 post 發出去。
這個 bug 跑了多久？ 大約跑了一整年。GinRollBT 從 2025 年 5 月開始跑到現在。每月可能發 1-3 個空字串。沒人發現是因為這帳號 4.7 篇/天，少數空文混在其他文章裡看不出來。
修復難度： 5 行 Python。在 posting 前 if not text.strip() or len(text) < 10: skip。
Bug #2：workplace_truth_tw 重複發了同一篇
過去 30 天，同樣文字（"社畜守則 第 88 條"）以 byte-identical 形式發過 2 次，間隔 7 天。
問題出在：沒有 queue-level deduplication。如果 Gemini 因為某些原因產出了「之前發過的內容」（temperature 設低、prompt 太狹隘、context 重複），系統會接受。
為什麼很難發現： 這需要對比 7 天前的同一帳號 post 內容，正常 dashboard 不會做這個檢查。
修復難度： 中等。需要建一個 30 天 post hash table，發文前查 dedup。可能誤殺合理的「同一主題不同寫法」，需要設模糊比對閾值。
Bug #3：2021newken `schedule_times` 格式錯，但仍以 10.1/day 在跑
這個帳號的 schedule_times 設成 start:07:00,interval:3h。
問題： MindThread 標準格式是 08:30,12:00,18:30 這種 comma-separated 時間。start:07:00,interval:3h 不是任何文件化的格式。
但它居然在跑。 30 天 303 篇 = 10.1 篇/天。
代表 schedule parser 有個 undocumented branch：解析失敗 → fallback 到某個 default → 變成「無限制猛發」。
這個 bug 不是壞掉，是「壞但有效用」。它讓 2021newken 變成發文最多的帳號（雖然粉絲只有 145）。
修復難度： 高。要先決定 — 是改 schedule 格式還是把 fallback 行為定義成正式 feature？
跨帳號 patterns（自動審視 36 個 enabled 帳號得到的）
除了上面 3 個 bugs，agent 跑出幾個跨帳號觀察：
1. 「⛔ 格式紅線」block 跟輸出遵循度高度相關。
GinRollBT（最高互動）的 prompt 開頭：
⛔ 字數限制：150-350字（超過350字=不合格，低於150字=太短）
明確的紅線、明確的後果。Gemini 遵循度極高。
而沒有「紅線」block 的帳號（如 2021newken 的 3 行「智慧格言家」prompt），輸出常常 drift 到不同主題、不同字數、不同結構。
結論： 越具體的 constraint，越穩定的輸出。「請以溫暖語氣寫」遠不如「字數 150-350」+「每段 ≤ 3 行」。
2. Persona 與實際拿讚的內容會 drift。
2021newken 寫的 persona 是「智慧格言家」。但拿讚的文章其實是「輕鬆遊戲反應」。
這個 mismatch 很有意思：當 prompt 抽象（persona-only），LLM 的「演員直覺」會跑去寫拿讚的內容（觀眾互動高）；當 prompt 具體（rule-based），LLM 會堅守設定。
結論： 如果你想「品牌一致性」，用 rule-based prompt。如果你想「最大化互動」，給 LLM 抽象 persona + 讓它隨流量信號自我調整。
3. 跨平台 follower 跟 prompt 字數沒有強相關。
最高互動的 GinRollBT prompt 是 923 字，但 prompt 200-400 字的帳號互動也很高。重要的是 prompt 的「結構密度」而不是字數。
300 字結構好的 prompt > 1000 字散漫的 prompt。
為什麼我自己沒發現這些 bugs？
老實講：因為我從沒主動審視過這些帳號。
MindThread 是「set it and forget it」的 SaaS。設好 → 跑兩年 → 都沒看裡面。
這跟昨天 OpenClaw 的 Moltbook bug 是同一個故事：自動化越多，盲點越大。
結構性教訓： 自動化系統需要每月「人工審視日」。跑個兩小時，看每個帳號最近 10 篇、看是否有 anomaly、看是否還有當初設定的味道。
我接下來會把這個排進 OpenClaw 的 weekly cron 裡：每週日請 Claude agent 對 MindThread 56 個帳號跑健檢，找 anomaly，TG 我。
你能拿走什麼
如果你也在跑類似的 AI-content 自動化：
- 加 sanity check： 每篇 post 前驗
if not text.strip() or len(text) < 30: skip + log - 加 dedup： 30 天 post hash table
- 檢查 config parser fallback： 你以為「設定錯應該失敗」其實可能「fallback 到某個非預期的 default」
- 每月強制人工審視： 看 prompt vs 真實輸出 vs 實際拿讚的，三邊有沒有 drift
- constraint 越具體越穩定： 不要寫「溫暖」，寫「150-350 字 + 每段 ≤ 3 行 + 結尾 1 句反問」
這篇是「Min Yi 在德國 Atlas」公開實驗系列第 3 篇。前兩篇：為什麼我做了 Atlas、OpenClaw fleet 公開。下一篇：「Spotify 換成 Last.fm 1 小時學到的事」。
寫於 2026-05-08，BR71 起飛後 1 小時，3 萬 5 千英尺。