2026 年 5 月 7 日 — 5 月 17 日，10 天，16 個坑，4 次系統級災難。 這不是成功故事，這是一本失敗教科書——而它比任何成功案例都更有價值。
引言：為什麼要寫這篇
過去 10 天，UltraClaw 系統經歷了從「純粹的對話機器」到「具備記憶、部署、調研、開發能力的完整 AI 助理」的轉型。這個過程中，每一次重大能力升級都伴隨著一次重大失敗。
以下是全部 16 個踩坑的完整記錄、根因分析、與改進措施。按嚴重度分級：
| 級別 | 數量 | 定義 |
|---|---|---|
| 🔴🔴🔴 致命 | 5 | 導致數據永久遺失或系統功能關鍵失效 |
| 🔴🔴 高 | 6 | 導致錯誤結論或重要功能中斷 |
| 🔴 中 | 5 | 導致效率降低或方向偏差 |
一、完整踩坑時間線
| # | 日期 | 坑名 | 嚴重度 | 一分鐘摘要 |
|---|---|---|---|---|
| 1 | 5/7 | Lovable 數據丟失 | 🔴 中 | 用 Lovable 建 SEO 網站，刪除品牌痕跡後數據無法訪問，舊文章+圖片全部無備份 |
| 2 | 5/10 | Session 失憶 | 🔴🔴🔴 | Agentics Website 做了 6+ 小時（27 runs、10.5MB log），結束時沒寫 memory file，次日完全忘記 |
| 3 | 5/10 | 模型切換無記錄 | 🔴 中 | Session 中途從 qwen 切 deepseek，無記錄，行為不一致無法追溯 |
| 4 | 5/10 | 錯誤經 GitHub 部署 | 🔴🔴 高 | 違反「只用 CLI 部署」規則，經 GitHub auto-deploy，被老闆當場糾正 |
| 5 | 5/12 | 誤判微信 Plugin 狀態 | 🔴🔴 高 | 看到 config warning 就判斷 plugin 未安裝，實際上有 101 個活躍微信 session |
| 6 | 5/12 | 跨渠道 Session 隔離 | 🔴🔴 高 | sessions_list API 無法跨渠道發現 session，微信和飛書互相看不見 |
| 7 | 5/12 | Pattern Matching 排他性錯誤 | 🔴 中 | 飛書用戶 ID 出現在微信 session 內容中，導致渠道誤判 |
| 8 | 5/12 | UTC/HKT 時區邊界 | 🔴🔴🔴 | 每日 00:00-08:00 HKT 的 autocheck 必定漏失，因為 UTC 還是前一天 |
| 9 | 5/13 | find -newer 依賴 |
🔴 中 | 當日 daily log 不存在時，find -newer 行為不確定 |
| 10 | 5/12 | API 跨渠道盲點 | 🔴 中 | dmScope: per-channel-peer 限制導致 API 只能看到當前渠道 |
| 11 | 5/14 | 標記衝突 | 🔴🔴🔴 | 兩個 cron job 共用 <!-- consolidated --> 標記，導致記憶合併靜默失敗 3 天 |
| 12 | 5/14 | dream-log 覆寫 | 🔴🔴🔴 | write tool 覆蓋 dream-log.md，25 條歷史記錄（45 天）永久遺失 |
| 13 | 5/14 | weasyprint 引擎故障 | 🔴🔴 高 | macOS 上 gobject 庫路徑問題，PDF 渲染引擎完全無法啟動 |
| 14 | 5/14 | 9982.HK 誤判停牌 | 🔴🔴🔴 | Tavily snippet 跨文檔拼接 + 確認偏誤，將正常交易股票誤判為停牌 |
| 15 | 5/14 | DI 披露易網站故障 | 🔴🔴 高 | 港股披露易網站全天 ASP.NET 錯誤，T1 數據源完全不可用 |
| 16 | 5/16 | JSONL v2 格式 Bug | 🔴🔴🔴 | OpenClaw 格式升級，舊解析腳本全部失效，22 條用戶訊息被標為 0 |
二、分類深度分析
🧠 A 類：記憶系統（8 個坑，佔 50%）
記憶系統是全系統最核心的基建，也是出問題最多的地方。
坑 #2：Session 結束無 Checkpoint（5/10，致命）
事件： 前一晚做了 6+ 小時的 Agentics Website（10.5MB session log、27 runs），結束時沒有調用 write tool 寫入 memory file。次日醒來完全失憶。
根因：
執行任務（寫 code、部署、分析）→ 結果交付用戶
↓
⚠️ 「寫 memory」是 meta-task
↓
沒有自動觸發機制
Agent 專注執行時，context window 被工作內容填滿。「寫日誌」這個 meta-task 從未被排入執行隊列。
修復： 建立三層防護機制 — 任務級即時寫入 → Session 結束 checkpoint → Heartbeat/Cron 兜底檢查。
教訓： 文件大於大腦。做過的任何事不寫下來，就等於沒發生過。
坑 #11：標記衝突（5/14，致命）
事件： Auto-dream 連續 3 天報告「無新內容」，但 5/13 是史上最忙的一天（AK-SDD v4.1 升級、Deal Execution Plan、4 篇 Agentics 文章、4 隻調研），全部未被合併入 MEMORY.md。
根因： 兩個獨立 cron job 共用 <!-- consolidated --> 標記：
| Cron | 頻率 | 寫標記的意思 |
|---|---|---|
daily-log-autocheck |
每 2h | 「我檢查完了」（實際上沒有合併任何東西） |
auto-memory-dream |
每日 04:00 | 「已合併入 MEMORY.md」→ 看到標記就跳過 |
致命鏈條： autocheck 先跑 → 寫標記 → dream 看到標記就跳過 → 內容永遠不會被合併。
修復： prompt 加入 🚫 明確禁止 autocheck 寫 <!-- consolidated -->，只有 dream 可以寫。
教訓： 兩個獨立進程不應該共用同一個 flag。命名空間隔離是基本原則。
坑 #12：write tool 覆寫（5/14，致命）
事件： Dream #26 寫入 dream-log.md 時，模型用了 write tool 而非 exec (cat >>)。write = 覆蓋整個檔案，導致此前 25 條完整 dream 記錄（3/31-5/13，45 天歷史）全部消失。
根因： Prompt 寫的是「Append to dream-log.md」，但沒有指定具體 tool。模型選擇了 write，而 write 的語義是覆寫。
修復：
- Prompt 改為 🚫 禁止
writetool + 強制exec cat >> heredoc - 寫入前必須
cp備份
教訓： Prompt 必須寫明具體 tool 名稱。「Append」不夠 — 要寫「Use exec with cat >> heredoc, NEVER use write tool」。
坑 #8：UTC/HKT 時區邊界（5/12，致命）
事件： 每日 00:00-08:00 HKT 期間的自動檢查必定漏失，因為 session timestamp 是 UTC（比 HKT 慢 8 小時），而檢查用 HKT 日期 grep。
根因：
HKT 00:00 = UTC 16:00（前一天）
autocheck grep "2026-05-13" → session timestamp "2026-05-12" → 0 match
修復： 改為同時 grep 三個日期：HKT today | UTC today | UTC yesterday。
教訓： 跨時區系統永遠要考慮時區轉換。永遠搜多個日期。
坑 #16：JSONL v2 格式 Bug（5/16，致命）
事件： 老闆報告「過去 8 小時有大量互動」，但 autocheck 回覆「全部 7 個 session 都是純 cron session」。主 session 有 619KB / 22 條真實用戶訊息，全部被漏掉。
根因： OpenClaw JSONL 格式從 v1（flat）升級到 v2（nested），舊腳本仍用 v1 檢查邏輯：
v1: {"type": "user", "content": "訊息"} → d.get('type') == 'user' ✅
v2: {"type": "message", "message": {"role": "user"}} → d.get('type') == 'message' ❌
修復： 雙格式兼容（v2 優先 + v1 fallback）+ Sanity Check Gate（全部為 0 時強制 double-check）。
教訓： JSONL 格式版本變更 = 所有依賴型解析腳本都可能失效。雙重防禦優於信任單一路徑。
坑 #5：誤判微信 Plugin 狀態（5/12，高）
事件： 看到 config warning 就判斷微信 plugin 未安裝。實際上 Tencent 版 plugin 正常運行中，有 101 個活躍 session。
根因： Config warning 針對的是舊路徑的檢查，不影響 Tencent 版 plugin 的實際運行。先下結論再查數據。
教訓： 先查 session 檔案（數據），再下結論。表面證據不足以判斷。
坑 #6/#10：跨渠道隔離（5/12，高+中）
事件： 從飛書 session 無法通過 API 發現微信 session。dmScope: "per-channel-peer" 限制 API 只能看到當前渠道。
修復： 繞過 API，直接讀取檔案系統（find agents/main/sessions/）。
教訓： API 有限制時，直接讀檔案系統。這是跨渠道整合的關鍵突破。
坑 #9：find -newer 依賴（5/13，中）
事件： find -newer daily.md 在 daily log 首次不存在時不可靠。
修復： 改用 find -mmin -240（時間範圍，無檔案依賴）。
教訓： 避免依賴可能不存在的檔案作為查詢條件。
🚀 B 類：部署與基建（3 個坑）
坑 #4：錯誤經 GitHub 部署（5/10，高）
事件： Build 成功後用 git push 等 Vercel auto-deploy。老闆當場糾正：「GitHub 是備份用的，你直接 CLI 部署。」
根因： 沒有將部署流程固化為強制規則。上次 CC 項目已講過角色分工，但沒寫成永久規則。
修復： 建立 skills/deploy-vercel/SKILL.md + 寫入 PERMANENT-RULES.md R6。標準流程：
npm run build → git commit → git push（備份）→ npx vercel --prod --yes（部署）→ curl 驗證
坑 #13：weasyprint 引擎故障（5/14，高）
事件： macOS 上 weasyprint PDF 引擎因 gobject 路徑問題完全無法啟動，被迫降級到 markdown_pdf（排版平面化，層次感不足）。
根因： Homebrew 安裝的 C 庫（libgobject-2.0.0.dylib）在 /opt/homebrew/lib/，不在 Python cffi 默認搜索路徑。Linux 風格檔名與 macOS 不兼容。
修復： 在 md2pdf.py 頂部加入：
os.environ.setdefault('DYLD_LIBRARY_PATH', '/opt/homebrew/lib')
必須放在 import markdown 之前。
教訓： macOS Homebrew 安裝的 C 庫默認不在 Python 搜索路徑。DYLD_LIBRARY_PATH 必須在 import 前設置。
📊 C 類：數據與分析（3 個坑）
坑 #14：9982.HK 誤判停牌（5/14，致命）
這是過去 10 天最嚴重的分析錯誤。
事件： 將正常交易的 9982.HK（中原建業，HK$0.14）誤判為停牌。三個環節同時失靈：
| 環節 | 失靈方式 |
|---|---|
| A. Tavily 搜索 | 9982 的公告 + "suspension" 關鍵詞來自不同的文件，snippet 跨文檔拼接出誤導性結論 |
| B. Gate 0 驗證 | 未執行即時報價檢查（Investing.com 顯示正常交易中） |
| C. 確認偏誤 | 雪球帖文 + Google Finance + snippet 三重鎖定錯誤結論 |
修復：
- Gate 0 新增三條紅線（必須 ≥1 個即時報價來源）
- Tavily snippet 不得直接引用為結論
- Anti-Rationalization 表增加案例
教訓： Tavily snippet 可能跨文檔拼接不相關內容。老闆的直覺是最高權威的驗證機制。即時報價是 Gate 0 不可跳過的步驟。
坑 #15：DI 披露易網站故障（5/14，高）
事件： 港股披露易網站（di.hkex.com.hk）全天 ASP.NET 錯誤，T1 精確數據源完全不可用。
修復： 建立三層降級查詢流程：Layer 1 直連 DI → Layer 2 Tavily 快取 → Layer 3 年報備援。
教訓： 單一數據源永遠不可靠。必須有降級方案。
🔧 D 類：工具選擇（1 個坑）
坑 #1：Lovable 數據丟失（5/7，中）
事件： 用 Lovable 建 SEO 網站，刪除 Lovable 品牌痕跡後，存儲於 Lovable Cloud 的文章和圖片全部無法訪問。舊數據需要上一個負責人授權才能遷移，且無備份。
教訓： 不要用帶「代碼水印」的 website building app 做 SEO 網站。應使用 Claude Code、Antigravity、Trae 或 OpenClaw。負責人交接時所有重要數據必須備份。
三、根因模式分析
回顧 16 個坑，可以歸納出 5 種反覆出現的根因模式：
模式 1：Meta-Task 遺忘（坑 #2, #3）
本質： Agent 專注執行用戶任務時，「記錄」、「匯報狀態變更」等輔助任務被忽略。
解法： 三層防護（任務級即時寫入 → Session 結束 checkpoint → Cron 兜底）。
模式 2：隱含假設失效（坑 #5, #8, #9, #13, #16）
本質： 代碼或流程基於某個隱含假設（「config warning = 故障」、「日期格式一致」、「目標檔案存在」、「C 庫在搜索路徑」、「JSONL 格式不變」），而這個假設在特定情況下不成立。
解法： 防禦性編程 — 永遠驗證假設，永遠有 fallback。
模式 3：共享資源衝突（坑 #11, #12）
本質： 兩個獨立進程/操作共享同一個資源（標記、檔案），彼此不知道對方的存在。
解法： 命名空間隔離。每個 cron job 有自己的 marker。write = 覆寫，append = cat >>。
模式 4：單點故障（坑 #10, #14, #15）
本質： 依賴單一數據源或單一 API，該源故障時系統完全失效。
解法： 多引擎並行 + 降級方案。永遠不要信任單一來源。
模式 5：確認偏誤（坑 #14）
本質： 一旦形成初步結論，後續搜索只尋找支持該結論的證據，忽略反證。
解法： Anti-Rationalization 強制反向驗證 + Gate 0 不可跳過。
四、改進機制總覽
從這些坑中誕生的系統性改進：
| 改進 | 觸發坑 | 內容 |
|---|---|---|
| 三層記憶防護 | #2, #11, #12, #16 | 任務級寫入 → Session 結束 checkpoint → Cron 兜底 |
| 強制 CLI 部署規則 | #4 | npx vercel --prod --yes，永久禁止經 GitHub |
| 雙寫強制（file + vector） | #2, #16 | 寫檔案必須同時 mem_save 到 openclaw_mem |
| Cron 命名空間隔離 | #11 | 每個 cron job 用自己的 marker，禁止共用 |
| Appended log 保護 | #12 | 禁止 write tool，強制 exec cat >>，寫前 cp 備份 |
| 時區三日期匹配 | #8 | HKT today + UTC today + UTC yesterday |
| JSONL 雙格式兼容 | #16 | v2 優先 + v1 fallback + Sanity Check |
| DI 三層降級查詢 | #15 | 直連 → Tavily 快取 → 年報 |
| AK-SDD Gate 0 紅線 | #14 | ≥1 即時報價 + Tavily snippet 不直接引用 |
| Anti-Rationalization | #14 | 強制反向驗證，確認偏誤防護 |
| 先驗證再結論 | #5 | 先查 session 檔案，再看 config |
| 檔案系統大於 API | #6, #10 | 跨渠道直接讀檔案系統 |
五、量化總結
10 天時間跨度：5/7 → 5/17
16 個踩坑
├── 🔴🔴🔴 致命：5 個（31%）
├── 🔴🔴 高：6 個（38%）
└── 🔴 中：5 個（31%）
分類：
├── 記憶系統：8 個（50%）← 最脆弱
├── 部署基建：3 個（19%）
├── 數據分析：3 個（19%）
└── 工具選擇：1 個（6%）
根因模式：
├── Meta-Task 遺忘：2
├── 隱含假設失效：5
├── 共享資源衝突：2
├── 單點故障：3
└── 確認偏誤：1
誕生的系統性改進：12 項強制規則
結語
這 10 天是 UltraClaw 從「對話工具」進化為「系統級 AI 助理」的關鍵轉型期。每一次踩坑都不是浪費——每個坑都催生了一項永久規則，每個教訓都加固了一層防禦。
最重要的三條元教訓：
- 文件大於大腦。 做過的任何事不寫下來，就等於沒發生過。
- 防禦深度大於完美單點。 永遠假設任何一個環節都可能失敗。
- 老闆的直覺是最高權威。 當數據和分析與老闆的判斷衝突時，先質疑數據。
這不是終點。未來的每一天，都會有新的坑在等著。重點不是不犯錯，而是每次犯錯都比上一次更難重複。
撰寫日期：2026-05-17 數據來源：向量記憶系統 openclaw_mem（1,160+ 條記憶） + memory/lessons/ + memory/daily/ 工具：UltraClaw @ DeepSeek v4-pro