[🛠] 把 GitHub Pages 博客重新恢复成可工作的系统

✨ GPT-5.5 的摘要 　

重新打开停滞的 GitHub Pages 博客，将 Daily Review 和 AI 对话归档拆分开，并把它作为公开记录系统重新启动的记录。

今天，我重新打开了博客。

这并不是简单地写一篇文章而已。它是把已经停滞的 GitHub Pages 博客，重新恢复到可以继续工作的状态。

起点是 2026 年 5 月 25 日的 Daily Review。那篇文章既是重新开始每日记录的宣言，同时也一次性承载了太多东西。对预备役死亡事件的愤怒、对政治的厌恶、对信仰和执行的自我检查、把 AI 当作自我管理工具使用的想法、重新启动博客的决心，全部都塞进了同一篇文章里。

一开始，我以为这样没问题。

毕竟是重新开始的第一天，我觉得把那天推动我行动的对话也全部留下就好。可是真正打开文件之后，我发现这并不是 Daily Review。与其说是一天的记录，不如说更接近一份对话归档。如果把几千行的完整对话贴进 Daily Review，那篇文章就不再是一个可以每天持续下去的记录。

所以今天的第一个决定很简单。

把 Daily Review 和 AI 对话归档分开。

先定下条件

要重新启动博客，比起漂亮的宣言，更需要一个能运营下去的结构。

条件是这样的。

• Daily Review 要保持轻量，轻到每天都能写。
• 很长的 AI 对话要拆成单独的归档文章。
• 对话归档不能看起来像 exporter 的原始 dump。
• 脏话和激烈表达要为了公开阅读做遮罩处理。
• 用户发言和 AI 回复要在视觉上区分开。
• 在归档列表里，要能立刻看出文章所属的分类。
• 在移动端，代码块或很长的对话卡片不能把屏幕撑出去。

写成文字，看起来像是在做整理。

但实际上，这是在清理阻碍博客重启的最大问题。如果重启第一篇文章本身太大，第二天开始又会写不下去。今天的核心不是把文章做大，而是把博客恢复成可以继续写下去的状态。

把完整对话从 Daily Review 里拿出来

一开始，我把完整对话以折叠形式放进了 2026 年 5 月 25 日的 Daily Review。

但这种方式很快就暴露出限制。

Daily Review 应该记录当天的胜负、产出、身体记录和逃避记录。可是如果里面塞进接近 2,900 行的完整对话，文章的性质就会变得模糊。读者会混乱，我自己第二天也不想继续用同样的格式。

所以我把对话拆成了单独的文章。

_posts/daily-review/2026-05/2026-05-25-2026-05-25.md
_posts/diary/ai/2026-05-25-reservist-anger-to-blog-restart.md

在 Daily Review 这一侧，我减少了巨大的对话 dump，并把 单独的对话归档 建了出来。

这就是核心。

一天的记录就作为一天的记录留下。对话归档就作为对话归档留下。两者不要混在一起。

把 exporter dump 改成像文章一样的东西

AI 对话 export 原样贴上去会很难读。

搜索日志、可能过期的图片链接、反复出现的元信息、对话中间夹杂的杂乱结构都会混在一起。原样发布的话，确实算是“记录”了，但不是“文章”。它可以留在博客上，却不会被人读下去。

所以我把对话归档改成了卡片结构。

<section class="conversation-entry conversation-entry--user">
  <div class="conversation-meta">我 · 2026.05.25 09:12:38</div>
  <div class="conversation-body">
    ...
  </div>
</section>

用户发言用偏黄色的色调强调，AI 回复则放在更安静的背景里。我创建了 conversation-meta、conversation-body、conversation-mask、conversation-code 这样的类。脏话以 *** 的形式保留下来，但不会在公开文章里直接跳出来。

这不只是 CSS 装饰。

这是把对话变成公开资料的过程。我不想把原文完全抹掉，同时也希望博客读者能跟上“话题在哪里发生了变化、是谁在说话、为什么这段对话会走向重启博客的宣言”。

元数据也重新整理

文章拆开之后，又看到了另一个问题。

如果归档列表里只显示标题和日期，很难马上判断一篇文章是 Daily Review、AI 归档、开发日志，还是技巧文章。博客要继续扩展，就必须从列表阶段开始显示上下文。

所以我在 _includes/archive-single.html 里加上了分类显示。

把 daily-review 显示成 Daily Review，把 diary 显示成 日记，把 ai 显示成 AI，把 github-pages-blog 显示成 GitHub Pages Blog。不是直接输出 raw category，而是转换成真实读者会看到的名称。

一开始，我把分类标签放在正文元信息下面，但很快看起来太分散。后来又改了一次，把日期元信息和分类标签放到同一行。

日期 / 分类标签 / 摘要

这个小修改提高了归档列表的信息密度。从作品集角度看也有意义。它让博客不只是一个写文章的地方，而更像一个区分内容类型、改善探索体验的系统。

移动端会崩的部分也顺手修了

加上对话卡片和代码块之后，移动端问题也跟着出现了。

长句、引用、代码块、复制按钮如果把屏幕横向撑出去，博客马上就会显得粗糙。尤其是 Minimal Mistakes 的代码复制按钮很方便，但在窄屏里，按钮本身有时也会制造 overflow。

所以我马上修了几处。

.conversation-entry {
  overflow-wrap: break-word;
}

.conversation-body {
  min-width: 0;
}

.clipboard-copy-button {
  overflow: hidden;
}

我也调整了对话卡片内部标题、blockquote、首段和末段的 margin。在移动端，则减少了卡片 padding 和内部标题字号。

这些修改不太显眼。但如果从作品集角度看，反而很重要。它说明我不是把功能接上就结束，而是继续追到真实屏幕上会崩掉的地方，把它们一起打磨掉。

今天改变了什么

今天的改动大致可以这样整理。

用 AGENTS.md 和 _project/blog-system/README.md 整理博客运营规则
从 Daily Review 中移除完整对话
创建单独的 AI 对话归档文章
添加基于 conversation-entry 的对话卡片样式
整理脏话遮罩和附件图片省略规则
在归档列表中添加分类标签
整理日期元信息和分类标签的布局
统一对话 timestamp 为韩国式时间格式
应用对话卡片
修复移动端对话卡片和代码复制按钮的 overflow

从提交脉络来看，短时间内做了相当多的事情。

d3fb3d5  clean blog project files
1d36a01  clean #87 transcript
1d9ab13  restore #87 toc
ccb9139  archive #87 transcript
310b3af  show archive categories
4579858  refine archive post metadata
fb3516b  localize conversation timestamps
0564866  apply conversation cards
244a4a5  prevent mobile copy-code overflow

一句话概括就是：

我把博客重启宣言，变成了一个实际可运营的记录系统。

结果

今天，博客重新打开了。

但更重要的是，不只是多了一篇文章，而是结构重新站了起来。

Daily Review 作为可以每天延续的记录留下，很长的 AI 对话则拆成了单独归档。对话归档不再是 exporter dump，而是变成了可阅读的公开资料。归档列表加上了分类上下文，移动端会崩的部分也修掉了。

这不是华丽的功能追加。但作为重新让博客活过来的第一步，它是准确的。

如果我要重新写下去，博客就不能只是情绪的仓库。它必须是一个可以运营的系统。今天做的事，就是恢复这个系统的最小骨架。

从作品集角度看，我也喜欢这个点。

问题很明确。重启第一篇文章变得太大，有可能破坏每日记录系统。解决方式也不是简单删除。我拆分了内容类型，做了 UI，整理了元数据，还打磨了移动端渲染。

“我要重新开始写博客”这句话很容易说。

今天，我把这句话变成了文件结构、模板、样式、元数据和移动端画面。