更优先的事情，通常是把页面之间的本地连接做强。目标不是模仿推荐流，而是让已经落到文章页上的读者，更容易继续读下去。
最便宜、也最容易解释的信号，通常本来就已经在内容模型里：
这些信号构建成本低，可以在构建期完成，而且读者也更容易理解“为什么这里出现了这几个链接”。
当内容集合还比较小、而且整体是人工整理过的时候，确定性路径其实很好用。
它至少能给读者三种明确的下一步：
很多时候，这已经足够提升继续阅读的概率，而不需要先引入更重的客户端搜索或索引方案。
当站点已经大到读者经常是为了“找回一篇具体旧文章”而来时，搜索的优先级才会明显上升。
在那之前，放置得当的元数据驱动链接，往往已经能承担大部分发现任务，而且更透明、更轻，也更容易长期维护。
]]>Giscus + GitHub Discussions 上。
这样做的原因很直接：第一版先把评论落到维护成本最低、审计路径最清楚的平台侧能力上，后续如果确实需要更细的私有规则、账号体系或更强的自动过滤，再考虑迁到自建后端。
以下内容不适合保留在评论区：
自动化只处理非常窄的一类情况：
命中这类规则后，评论可能会在 GitHub 侧被自动最小化，并保留平台可见的原因，例如 spam 或 abuse。
除此之外，自动化不会尝试替代人工判断。边界模糊、需要上下文解释、或者只是观点尖锐但仍在讨论范围内的评论，不会因为自动规则直接被处理。
如果你的评论被最小化，但你认为这是误判，可以：
我会优先按公开规则复核，而不是让隐藏规则替代说明。
]]>对一个内容规模还不大的站点来说，读者往往会在归档页上快速判断三件事：这里是不是还在持续更新、内容有没有阶段感、以及值不值得继续点开更多文章。如果页面只是一串平铺标题，这些判断都会变得更费力。
博客天然拥有的强信号里，时间几乎是最稳定的一个。
按年份分组、再把节点做得更可扫描之后，归档页能更快回答这些问题：
这比“单纯倒序列表”更像一个真正的发现入口。
时间线式归档，至少应该让三件事变得便宜：
对双语站点来说，这一点更重要，因为读者会自然判断不同语言下的归档是不是同样完整、是否能形成连续阅读路径。
这一阶段的归档页不需要直接变成搜索引擎。
只要它能把时间结构讲清楚，保持静态优先，并为后续文章页的上一篇、下一篇和相关文章提供更强的上下文，目标就已经成立。
]]>我选择 Astro + Retypeset 作为第一版基础设施，原因很直接。
作为对照，普通静态引用会尽量保持安静 [1]。启用预览的引用则可以在桌面端就地补足上下文 [2]。
GitHub Pages 成本低、维护轻。sitemap、Open Graph、RSS 和结构化元信息能力。接下来我会继续补齐这些内容：
如果你正在读这篇文章，说明这个博客已经从想法进入了运行状态。
Astro 官方文档 明确把 Astro 定位为适合内容型、静态优先网站的框架，这和这个博客当前的部署方式与维护目标是一致的。
Retypeset 演示站 所呈现的字距、留白和长文阅读体验，是我判断这套主题适合写作场景的重要依据。