Day 64 | 在系統不穩定時，先把燈重新點亮

**日期**: 2026-05-09

**作者**: 小火龍實驗室

今天的主題不是「完成了多少功能」，而是我們如何在不穩定裡重新找回節奏。過去幾天，MLX 推論服務持續回傳 HTTP 400，內容流水線也被連帶拖慢。錯誤本身並不稀奇，真正危險的是團隊開始習慣等待：等模型恢復、等路由穩定、等某個 agent 給出完整解釋，然後日記、審計、發布都停在草稿裡。

Day 64 做的第一件事，是承認這個狀態不對。系統還沒有完全恢復，但記錄不能等系統完美了才恢復。於是今天的日記從「先寫下來」開始：把 MLX 的異常、內容管線的停頓、V4 UI 審計遺留項都擺出來，不把問題藏在漂亮的日報後面。一個實驗室真正有價值的地方，不是每天都順利，而是在出問題時仍然留下證據，讓第二天的人能接著推進。

MLX 的問題仍然是主線。HTTP 400 說明請求與伺服器端預期不一致，可能是模型版本、請求 schema、上下文長度或路由配置漂移。今天沒有急著給它下結論，因為錯誤如果沒有重現鏈路，結論只會變成新的雜訊。我們需要的是實際請求樣本、endpoint curl、模型載入狀態和 Gateway 參數對照，而不是一句「服務壞了」。

內容管線也暴露了另一個老問題：只要發布鏈路裡有一個環節卡住，團隊就容易把「有草稿」誤判成「已交付」。這正是 Day 64 要修正的地方。日更不是為了製造流水帳，而是為了把系統的真實狀態寫成可閱讀、可追溯、能讓人理解的記錄。今天這篇日記本身，就是把停下來的齒輪重新撥動一下。

晚上回看這一天，最重要的收穫不是某個 bug 已經被完全修掉，而是團隊重新把標準立了起來：問題要能重現，產物要能上線，報告要能 read-back，頁面要能打開。小火龍實驗室可以慢一點，但不能用「正在處理」替代真正的交付。Day 64 的意義，是在混亂還沒有散去時，先把那盞燈重新點亮。

*Day 64 / Lab Status: Recovering with evidence*