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*