这个博客要像维护记录，而不是服务展台；每篇文章都应该留下真实取舍、素材来源和发布前检查。

\n
我希望 bbong9's blog 像一本长期维护的工作笔记，而不是服务截图合集。一个页面能打开，一段配置能复制，都不等于文章有价值。真正能帮到后来者的，是当时为什么这样选、踩过什么坑、哪些边界不能碰、出了问题如何回到可验证状态。

这篇不写任何假服务，也不拿不存在的 Compose 片段凑篇幅。它只记录我给博客内容定下的编辑规则。

文章先写适用场景

每篇文章开头都应该回答：这套做法适合什么机器、什么家庭环境、什么维护能力。低配 NAS、单人使用、多人同步、需要外部访问、只在局域网用，写法都不一样。如果场景不清，读者很容易把一个局部经验当成通用方案。

我也会写清不适用的情况。比如某些方案只适合小规模数据，某些服务不建议随意暴露，某些升级必须先备份。边界不是扫兴，它是文章的可信度来源。

素材要能回到原始记录

截图、命令输出、错误日志、目录结构、版本号，都应该有原始记录。文章里可以只放整理后的重点，但本地素材要按文章归档。以后有人问“这个错误当时怎么判断的”，我能找到日志时间点、命令输出和修改前后的差异，而不是只剩一句“我记得是这样”。

素材归档可以很简单：每篇文章一个目录，里面放截图、草稿、命令输出摘要、参考链接和最终 Markdown。重要的是可回溯，不是形式漂亮。涉及密码、令牌、私有地址和家庭成员信息的内容，发布前必须删掉或打码，本地归档也要控制范围。

不用模板句撑篇幅

批量文章最容易出现的问题，是每篇都有同一套过渡句、同一张表、同一段“心得”。读起来像生成器，不像真实维护记录。我的规则是：每篇至少要有几个只属于这个主题的判断。qBittorrent 就写工作区、限速和 Web UI；PostgreSQL 就写初始化、备份和恢复；博客定位就写内容规范和复盘，不硬塞 Docker 片段。

如果一段话换个标题还能放进另一篇，基本就该删。文章短一点没关系，2200 到 3200 字符足够把一个具体问题讲清楚。为了字数重复表达，只会降低可信度。

人工编辑还要留下判断痕迹。哪些段落是从真实维护记录改写的，哪些是为了补足上下文新写的，哪些旧句因为太模板被删掉，最好在本地草稿里能看出来。这样下一轮编辑接手时，不会误以为所有句子都同等可靠。

我也会把被删掉的套话单独记一行，提醒自己下一批文章不要再沿用同一种口吻。

发布前检查清单

我会在发布前做一轮人工检查：

• 标题是否准确，不夸大；
• 摘要是否说明主题，不堆关键词；
• 图片是否和正文相关，alt 和说明是否可读；
• 正文是否包含真实场景、风险边界和验证方法；
• 命令是否有目的，不只是摆样子；
• 是否泄露私密路径、账号、令牌或家庭信息；
• 是否出现不适合公开传播的内容；
• 是否有多篇重复段落。

这份清单比自动生成更多段落重要。博客文章不是越长越像经验，越能解释取舍才像经验。

后续复盘比一次发布更重要

服务部署类文章很容易过期。镜像版本会变，官方文档会变，自己家里的目录也会调整。所以每篇文章发布后都应该留下复盘入口：什么时候验证过，哪个步骤后来改了，哪些命令已经不推荐，哪些风险变大了。

复盘不一定要重写全文。可以在文章末尾加更新记录，也可以另写一篇维护笔记。但不能假装发布那天的状态永远正确。家庭服务器文章最大的价值，是把变化过程留下来。

我会给复盘保留三个字段：验证日期、变化原因、是否影响旧读者。验证日期说明这篇文章最近一次被认真看过；变化原因说明是软件升级、目录调整还是使用习惯改变；是否影响旧读者，则提醒我需不需要在开头加醒目的更新说明。

复盘也要允许承认旧判断不够好。早期文章可能写得太像清单，也可能低估了备份、权限或入口风险。发现问题后直接修正文稿，比继续维护一个看似完整但不准确的旧版本更负责。博客不是一次性作品，它应该跟着真实维护经验长大。

我想保留的写作气质

这个博客不需要炫技。它应该像一个愿意把现场说清楚的人：哪里确定，哪里不确定；哪里适合照着做，哪里只能作为参考；哪里失败过，后来怎么恢复。读者看完不一定复制我的配置，但应该能学会怎么检查自己的环境。

如果一篇文章只有漂亮结论，没有失败现象、验证动作和边界说明，我会把它退回去重写。真实博客的味道不来自口头上说“真实”，而来自具体细节：目录怎么命名，备份怎么校验，日志怎么看，发布前删掉了什么。把这些留下来，文章自然会像人写的。