博客文字增长趋势

2017-06—2022-03 按文章发布日期回填，2022-04 起按 Git 月末快照统计。
截至 2026-10，共记录 67 篇文章和 16 条说说，累计约 72,767 字。
按内容日期统计（2017-06—2026-10）：文章优先使用显式 updated，没有则使用 date；说说使用每条记录的 date。每篇内容的当前完整字数归入对应月份。

初心

这个博客嘛!估计一般人都看不到,也没有做SEO,也没有做推广,也没有想着推广啥的,一个人慢慢的写着,有事没事写一点,开心不开心写一点,可能很些错别字,肯能也会有些句子念不通的,也可能一看全程懵逼的,也肯能思维跳跃的有点摸不着头脑,应该就是当着像写日记一样,这上班也不像冒险一样每天都能遇到不同都事情,通常时间都是工作上班,下班回宿舍,然后就这样如此反复,实在是没有太大的意思!

以前也写了些博客,在简书,在Github,用Hexo,到现在才真正的相用WordPress,以前也用过,没有认真去折腾,以前用,也是为了瞎折腾,看看到底是个什么鬼东西,域名续费了两年,服务器续费了三年,还是真的有点想法,博客一直开着,3年以后,我可能都已经结婚了

那时候要是无聊的时候,或者像现在抗疫的时候,有更多的整个的时间,来回头看看,也是个极好的故事,这一眼,就能看到年轻时候的每个瞬间了

但是生活不能困住我,起码不能困住年轻,还有挣钱能力的我,在这个时候,更多的时候,还是想要到处走走,看看世界,也看看祖国的大好河山,留念下老人

如果你看到这个页面,回复一下吧!在这里等着我喜欢的姑娘,和志同道合的伙伴

嘤嘤嘤

关于这个博客

这个博客主要用来记录我的生活、工作、旅行和一些零散的想法。它不是一个专门追求流量或者搜索排名的网站，更像是一份长期保存的个人档案。

这里的文章不一定完整，也不一定都是经过精心设计的主题。有些是长篇记录，有些只是当天发生的一件小事。多年以后再回来翻看时，我希望还能从文字、照片和时间里，重新找到当时的生活。

随着记录不断增加，这里也不再只是许多彼此独立的文章。发生在不同年份的旅行、人物和生活片段，会通过系列文章、站内链接和具体段落之间的关联重新串在一起。新写下的一件小事，有时也会让我回头找到一年前甚至更早的经历，让这个博客逐渐变成一份互相关联的个人档案。

我也越来越觉得，生活中的小事应该尽量在还记得的时候写下来。一次出门前要不要关灯、一笔坚持了几个月的存款、一张刚收到的银行卡，或者某年国庆节的一段行程，当时看起来都不是什么大事，但过一段时间以后，很多细节就再也想不起来了。博客保存的不只是结果，也包括当时的想法、情绪和那些以后可能消失的记忆。

随着内容越来越多，这个博客也逐渐形成了一套自己的写作和维护规范。除了文章本身，我也会记录网站的技术架构、图片处理方式、发布流程，以及使用 AI 协助维护博客时需要遵守的规则。

AI 如何参与这个博客

现在我会使用 AI 协助维护博客，但 AI 并不是内容的作者。

文章中的经历、观点和情绪仍然来自我本人。AI 主要负责一些偏整理和技术性的工作，例如：

  • 检查错别字、语句不通和可能的拼音输入错误；
  • 核对文章里的日期、星期和前后时间线；
  • 根据已经确认的信息统一人名和称呼；
  • 整理系列文章，并在相关内容之间建立自然的站内链接；
  • 整理文章格式、图片链接和页面结构；
  • 压缩并上传图片；
  • 检查博客能否正常构建和访问；
  • 记录已经确认的维护规范，避免以后重复踩坑。

对于不确定的人名、地点、时间和事实，AI 不应该自己猜测或者擅自修改，而是先保留原文并交给我确认。对于我已经忘记的经历，AI 也不会根据零散线索替我补写；它可以帮助找到旧记录、建立关联，但不能代替我制造记忆。

这个项目中的 AGENTS.md 可以理解为一份写给 AI 的博客维护手册。里面记录了目录结构、写作规范、图片流程、部署方式、排查入口，以及已经确认过的人物和时间线。这样即使隔了一段时间再继续维护，AI 也能沿用之前确定的规则，而不是每次重新开始。

写作和内容规范

博客目前主要包含文章、日记、说说和图库。

日记会按照固定目录保存；说说按月份拆分；文章中出现的人名或昵称会使用行内代码样式突出显示。涉及具体日期和星期时，会通过系统工具核对，避免因为手写日期造成时间线错误。

新增文章或修改文章图片后，也会同步更新图库页面。图库并不是一个独立上传图片的地方，而是博客中已经使用过的图片集合。

这些规范不是为了把文章写得像正式出版物，而是为了让多年积累下来的内容仍然容易查找、维护和理解。

整理站内关系时，链接会尽量放在正文原本就有的自然词句上，不为了添加链接而额外改变叙述。重要内容还会链接到文章里的具体段落，让后来回看时能够直接找到当时所指的那件事。

图片处理流程

博客文章中的图片不会直接放进代码仓库，而是统一存放在独立的图床中。

通常的处理流程是：

  1. 检查图片中是否包含不适合公开的信息；
  2. 将图片压缩并转换为 WebP；
  3. 尺寸过大的图片会适当缩小，避免影响加载速度；
  4. 上传到 S3 图床；
  5. 在文章和图库中使用 img.mmzcg.com 的公开链接；
  6. 清理 Cloudflare 缓存并检查线上图片是否能够正常访问。

图片原则上会控制在 1MB 以内，但不会为了追求极端的小体积而明显损失画质。

由于图片使用了较长时间的浏览器缓存，已经上线的图片文件名会被视为不可变。如果需要替换图片，应该使用新的文件名并更新文章引用，而不是直接覆盖原文件。Cloudflare 可以清除边缘缓存，但无法清除已经保存在访客浏览器里的旧图片。

网站技术架构

这个博客目前使用 Hexo 和 Butterfly 主题生成静态页面。

日常发布流程是：

1
2
3
4
5
6
7
本地写作和检查
        ↓
提交到 GitHub main 分支
        ↓
Cloudflare Pages 自动构建
        ↓
发布到 mmzcg.com

Cloudflare Pages 使用 pnpm run build 生成网站，最终发布 Hexo 输出的 public 目录。

文章图片和视频使用独立的 img.mmzcg.com 域名。这个域名经过 Cloudflare 代理，后面直接连接位于新加坡区域的 AWS S3 存储桶。

1
2
3
访问者
  ├── mmzcg.com       → Cloudflare Pages → 博客页面
  └── img.mmzcg.com   → Cloudflare CDN   → AWS S3 图片

图片的 Cloudflare 边缘缓存和浏览器缓存目前都设置为一年。这样可以减少重复加载，提高图片访问速度，但也意味着图片发布以后应尽量避免使用相同文件名覆盖。

为了减少首屏加载时间，博客使用到的部分前端资源已经改为本站托管，包括字体、灯箱、打字效果和图库加载组件。字体文件也根据网站实际使用的图标做了精简。

安全和隐私

博客维护过程中使用的 S3、Cloudflare 和图片压缩服务凭证只保存在本机，不会写入文章、代码仓库或公开文档。

AI 在执行上传、缓存清理和网站验证时可以使用这些凭证，但不应该显示、记录或者复制凭证内容。

发布包含邮件、账户、订单、地址或其他个人信息的截图前，需要先完成裁剪或者遮挡。对于已经公开过的敏感图片，仅仅覆盖原文件并不能保证旧版本立即消失，因为访客的浏览器可能已经缓存了原图。最安全的处理方式仍然是更换文件名、更新引用，并停止继续使用旧地址。

为什么记录这些

一开始写博客只是想留下生活里的片段。后来文章、图片和功能越来越多，博客也慢慢变成了一个需要长期维护的小项目。

把这些规范记录下来，不只是为了方便 AI，也是在给未来的自己留一份说明书。

也许多年以后，我已经忘记这个网站是怎么搭起来的，但只要这些文字还在，就仍然可以知道文章放在哪里、图片去了哪里，以及这个博客为什么会变成现在的样子。

评论