站点历史

这个页面记录站点内容如何形成、何时整理和怎样维护。它不是用来制造“运营年限”的装饰，而是帮助读者区分 项目发生时间、文章整理时间与站点维护时间。

时间线

2023：开始保留可复现的设备日志

串口调试、设备重启和现场问题催生了第一批结构化记录。原始材料主要是代码提交、测试笔记、日志与截图，并未全部以公开文章形式发布。后续整理为《从串口日志到可视化：第一版设备调试台》等补档内容。

2024：嵌入式排查逐渐形成固定方法

记录重点从“最后改了什么”转向“怎样证明原因”。BLE 断连、I2C 总线异常、ST7789 初始化和 ESP32 工程边界分别形成了测试矩阵、故障注入与验收清单。年末复盘把方向概括为：少做只能运行一次的演示，多做可以重复使用的工具。

这一阶段的站内文章是根据可确认的旧资料重新整理，并非声称网站当时已经连续公开更新。

2025：工具开始面向交付与恢复

蓝牙上位机加入明确状态机，Python 发布流程开始关注干净环境、启动时间、诊断包和配置迁移。自托管记录也从“服务已运行”转向“备份能恢复”，逐步建立服务清单和分层备份思路。

2026 年上半年：重新建立写作结构

站点明确四条内容主线：嵌入式与硬件、桌面工具、AI 与自动化、自托管与运维。博客记录带时间背景的过程，知识库保存当前有效步骤，项目档案负责连接同一项目的文章、验证和后续计划。

LLM API 相关实验开始采用结构化输出、本地校验、错误分类、检查点与回滚分层，批处理的幂等和失败恢复进入固定清单。

2026 年 8 月：恢复原 Halo 数据

服务器上曾出现新旧两套 Halo 实例，反向代理一度指向空实例，页面看起来像被清空。恢复过程保留现状备份，识别原数据库、附件和 Joe3 主题，内部验证后再切换 Nginx upstream。相关技术过程整理为公开故障复盘。

2026 年 9 月：统一域名与 HTTPS，开始系统补档

站点公开地址统一到 https://maomao.autos/，根域名与 www 使用有效证书，HTTP 跳转到 HTTPS，Halo 外部地址与反向代理保持一致。随后重新整理分类、标签、页面、菜单和旧项目文章。

补档规则

补档文章遵循以下约定：

1. 发布日期用于原实验或项目阶段的归档；
2. 标题或正文显式写明“旧记录整理”“补档”或“归档说明”；
3. 不把后来的理解伪装成当时已经得出的结论；
4. 不补写无法确认的访问量、用户数、合作、收益或第三方评价；
5. 代码、截图和数据只使用能够脱敏并确认来源的部分；
6. 若旧方法已经失效，在顶部增加修订说明并指向当前做法。

修订记录怎样写

小范围错字直接修正；影响结论、命令或安全性的修改会增加日期、原因和替代步骤。文章不会因为方案失败就删除，失败路径对于理解边界仍然有价值。已经归档的方案会保留，但明确说明不再推荐。

站点维护清单

• [x] 站点标题、描述与内容方向一致
• [x] 分类和标签具有稳定命名
• [x] 关于、现在、项目档案与工具箱各司其职
• [x] 补档文章明确说明整理性质
• [x] 域名、TLS 与 Halo 外部地址统一
• [ ] 定期检查站内链接、附件与图片
• [ ] 完成数据库和附件的隔离恢复演练
• [ ] 为重要配置变更保留差异与回滚记录

为什么公开这段历史

技术站点也需要可追踪的上下文。读者看到一篇标注 2023 年的文章，应该知道那是旧实验的整理，而不是被引导相信网站当时已有完整公开档案。透明时间线不会削弱内容，反而让每条结论的来源和成熟度更清楚。

站点会继续变化，但这条原则保持不变：用细节建立可信度，而不是用虚构的年限、数字或评价制造热闹。