首页不是草稿箱#

博客首页应该给读者一个判断：这个站最近在关心什么，哪些文章需要先读，哪些内容线还会继续长。

它不该承担草稿箱的职责。

本地工作区里有很多东西很适合成为素材：一次部署回看、一份实验调参记录、一段课程复习思路、一个机器人功能的范围选择。它们在本地都是真实的，也都可能值得记。但真实材料要先判断能不能公开，公开以后也未必适合直接上首页。

我现在更愿意把首页当成一个经过筛选后的阅读入口，而不是最新文件列表。文章先进草稿，再过检查门，最后才进入首页卡片、专题和专栏。

检查门先看五件事#

这道门不是复杂系统，只是几个很朴素的问题。

第一，来源能不能解释。文章最好知道自己从哪里来：公开仓库、实验材料、本地记忆整理，还是课程笔记。来源不一定都要公开链接，但至少要有一个抽象的 sourceName，方便以后回查。

第二，内容有没有复原私人现场。私聊原文、账号、路径、服务器细节、事件 ID，这些都不该靠“我觉得没问题”放过去。能改写成工程问题的留下，能复原现场的删掉。

第三，长文有没有统一封面。首页卡片是否整齐，很多时候不只是 CSS 的问题，也看内容本身有没有稳定比例的封面。没有封面规范，首页再怎么调都会显得散。

第四，草稿有没有隔离。漫画、批量生成、未完成的专题都可以存在，但不该因为构建脚本扫到了它们，就顺手进入生产站点。

第五，静态构建能不能完整跑完。服务器资源有限，博客就别再给服务器加常驻负担。安全扫描、私域场景词检查、封面检查、Astro 检查、TypeScript 检查、Pagefind、草稿泄漏检查和打包，都应该在本地完成。

先把内容顺序理清#

过去我会把“美化博客”理解成调色、卡片、动效和首页布局。后来我发现，颜色和动效只能补一部分，内容入口、专题边界和发布状态更影响阅读体验。

项目、实验、课程这些专栏用来分入口；专题页留给长期内容；来源页方便回头查材料；发布检查门则用来拦住还不适合公开的内容。

这些页面都不需要复杂运行时，也不需要数据库。它们只是把静态内容重新组织了一遍。

这很适合小服务器：服务器只负责托管静态文件，搜索由 Pagefind 在构建时生成，统计和评论都按需用外部静态脚本开启。重活留在本地机器上做。

统计和评论不急着硬开#

访问统计和评论可以以后接，没配完整时硬开，反而会暴露半成品状态。

Busuanzi 适合轻量展示访问量，但它不是分析工具。Plausible 或 Umami 更适合认真看来源和阅读行为，不过它们需要明确配置，不能在没有域名、站点 ID 或脚本地址时硬开。

评论也一样。Giscus 组件已经可以接入，但 GitHub Discussions、repoId、categoryId 没配置好之前，它就应该安静地不渲染。一个半配置的评论框，比没有评论更糟，因为它会让读者遇到坏体验。

所以检查门页把这些状态直接摆出来：已落地的说已落地，待配置的就写待配置。

漫画草稿先留在本地#

漫画板块是另一个典型例子。

它有内容潜力，也有视觉吸引力，但现在还不该发布。这组漫画暂时还缺统一封面、章节节奏、目录入口和整体口吻。如果只因为图片已经生成，就把一整组草稿推上首页，短期看热闹，长期会破坏博客的阅读秩序。

所以现在的选择很简单：漫画保留 draft: true，生产构建后再跑草稿泄漏检查。等它打磨完，再按专栏或专题发布，而不是混进普通归档。

一键脚本把检查固定下来#

一键发布脚本看起来像自动化，其实更像一张检查清单。

它把几件事固定下来：

1. 先扫敏感内容。
2. 再扫一遍私域场景词。
3. 再检查封面。
4. 确认统计配置没有半开。
5. 跑 Astro 和 TypeScript 检查。
6. 构建静态站点并生成 Pagefind。
7. 检查生产成果没有草稿标题或 slug。
8. 打包 dist，有部署目标时再上传。

这个流程主要是减少临场判断。发布时越少靠记忆，越不容易把草稿、私有现场或半配置功能带上去。

改完以后我更想这样放内容#

这次博客平台改造后，我更确定一件事：个人博客如果做得太像内容流，很容易把整理压力推到读者面前。

它应该像一个小型工作台。素材和草稿可以多放在本地，公开入口要收一点：首页先带读者进来，专栏和专题再把内容分开，来源和检查门负责把发布前的麻烦处理掉。

这比较适合我现在的状态：本地写作和构建可以很主动，线上站点保持静态、干净、轻量。

这次改完以后，适合公开的内容更容易被看见，还没整理好的东西也能先留在本地。