为什么重新开始写技术博客

我并不是缺少笔记。相反，电脑里有很多：串口截图、临时 Markdown、聊天记录、代码注释、提交信息和命名随意的压缩包。真正缺少的是一个能在半年后回答问题的入口。于是重新整理这个博客，不追求高频更新，也不把它当作作品陈列柜，而是把技术决策、失败样本和验证过程放到可检索的位置。

什么值得写下来

第一类是花了很久才确定的事实。例如某块屏幕为何偏移、某次蓝牙断开究竟发生在哪一层。结论也许只有一句话，但排除过的路径、使用的测量方法和失败条件对未来更有价值。

第二类是反复使用的小系统：工程目录、发布脚本、备份恢复、状态机约定。它们不一定新颖，却会不断节省时间。写作迫使我说明输入、输出、边界和不适用场景。

第三类是阶段复盘。项目结束时记下做对、做错和仍未知的部分，避免过几个月只记得成功画面。复盘不会补写不存在的数据，旧文整理会明确标记“补档”。

一篇记录的最小结构

我为自己定了五个问题：当时要解决什么；看到了哪些可验证现象；尝试过什么；为什么选择当前方案；别人如何重复验证。代码只保留能说明边界的片段，完整实现回到仓库。截图必须配文字，不让关键信息只存在图片里。

技术文章也要写失败。若一个方案因性能、复杂度或维护成本被放弃，我会说明触发决定的证据，而不是用“最终优化”把曲折抹掉。未知项明确写未知，后续验证再更新。

站点整理约定

• [x] 旧记录使用原实验时间归档，并标注整理日期或“补档”
• [x] 标题描述实际问题，不使用夸张结论
• [x] 命令与配置注明适用版本和前置条件
• [x] 外部资料尽量链接原始来源
• [x] 文章更新保留变更说明，不悄悄改写历史
• [x] 不公开密钥、个人数据和未脱敏现场信息

博客与知识库的分工

知识库保存会持续维护的操作步骤，例如部署和恢复手册；博客保存带时间背景的过程和判断。前者追求当前正确，后者保留当时如何抵达结论。项目档案则作为索引，把相关日志、文档和版本串起来。

想保持的节奏

不设“每周必须几篇”的压力。完成一次值得复用的排查，就整理一篇；形成一个稳定工具，就补齐使用与恢复说明；遇到旧文失效，就公开更新原因。宁可少而可验证，不追求看起来热闹。

重新写博客，本质上是在为未来的自己减少上下文恢复成本。代码告诉我系统做什么，文章记录为什么这样做、哪里曾经出错。只要某篇记录能让下一次排查少走一步，它就已经完成了任务。