我在 Subspace Builder 里搭起了自己的串联动态

自己搭网站最让我喜欢的一点，是我也能搭起自己的串联动态。它不是别人拥有的社交信息流，也不是围绕别人默认选项打造的产品。我可以决定什么算一次更新，它如何与其他更新关联，以及发布后呈现什么样子。

我喜欢它，因为一切都在自己的掌控下，也留出了自由创作的空间。我也不必在通常的意义上守时：可以边做边记，之后再回来补上中间缺失的部分，像时间旅行者一样略带非线性地写作。这比严格的时间顺序更接近工作真正发生的样子。

还有一个更简单的原因：我真的很喜欢开发 Subspace Builder 本身。用 Markdown 写作和创作，以 Git 仓库作为后盾，仍是我最喜欢的技术组合之一。时间线条目为这套流程提供了更轻的发布形式，而关联条目又向前推进了一步，把平面日志变成串联起来的工作记录。

如果你想了解功能本身的开发过程，实现位于 PR #17。

这是实际使用时的效果：一眼就能看出条目类型和串联上下文的时间线信息流。

# 时间线条目增加了轻量发布层

此前网站一直缺少一个介于完整文章和私有草稿笔记之间的空间。有些更新值得公开，带上时间戳，方便日后回看，却不需要长文的分量。

时间线条目解决了这个问题。它们存放在 timeline/，使用熟悉的 front matter，并渲染到独立的 /timeline/ 页面，形成按日期排列的更新流。条目类型由标签驱动，而非自定义字段，让写作模型保持简单。

---
title: Shipped the timeline page
date: "2026-04-14"
time: "15:42"
tags:
  - timeline
  - shipped
---

这种格式有两点意义。首先，它与其他内容的模型接近，写时间线条目就像在项目里写任何一篇 Markdown。其次，明确的 time 字段让集合拥有稳定的同日排序，当一天内有多条更新时，这一点必不可少。

标签在视觉上也发挥作用。shipped、published、wip、idea 和 thinking 各有颜色，读者还没读正文，就能知道某条内容是已发布成果、构想还是进行中的工作。

# 关联条目把时间线串起来

平面的时间线很有用，但一项工作经历多次更新后，它就有些力不从心。每条记录都看得到，彼此的关系却仍然需要读者在脑中整理。

关联条目就是为了解决这一点。现在，时间线条目可以在 front matter 中使用另一个条目的 URL 路径，将其设为父条目。

---
title: Published relational timeline entry
date: "2026-04-16"
time: "10:30"
parent: "/timeline/2026-04-14-shipped-timeline/"
tags:
  - timeline
  - published
---

引用格式因此非常简单：直接使用站点上已经存在的条目 URL。无需维护额外的 ID 系统，关系在 Markdown 中也一目了然。

构建过程现在也会校验这些关系。parent 必须指向真实存在的 /timeline/.../ 条目，不能指向自身，也不能形成循环。错误关系会立即导致构建失败，而不是悄悄生成错误界面。

# 信息流现在既有顺序，也有上下文

/timeline/ 页面也做了调整，让这些关系一眼可见。上下文不再藏在详情页里，信息流会直接提示某条内容承接了前文，或拥有后续更新。

子条目显示 Continues from 标签，父条目显示后续更新数量。这既保留了时间线快速浏览的感觉，又明确告诉读者：某些条目属于更长的一条链。

时间线条目现在直接在主信息流中显示关系提示。

这个小提示很重要。读者不用猜某条记录是否独立，也不必盲目打开详情页，才知道它之前或之后是否还有上下文。

# 条目页现在更像一条串联记录

更大的体验变化发生在条目页本身。点击某条内容后，页面现在会展示它在整条记录中的位置。

祖先条目显示在 Earlier in thread 下，直接子条目显示在 Follow-ups 下。界面复用了信息流里的时间线卡片，因此关系视图像是时间线的延伸，而不是另一套不相干的布局。

时间线条目现在可以同时展示之前的上下文和之后的更新。

这种复用比听起来更有意义。它让同一套视觉语言贯穿各处：无论快速浏览主时间线，还是详细追踪关联链，时间戳、彩色圆点、标题样式和标签都保持一致。

祖先条目现在也支持多层展示。如果某条记录承接另一条，而后者又承接更早的内容，详情页就能按顺序显示整条链，不再只展示一层父条目。

嵌套的父条目链现在可以完整呈现，不再缩减为单次父级跳转。

父条目也会显示后续更新，让整条记录可以双向浏览。

结果更接近串联对话或开发日志，而不是传统归档页。这正是这个功能应该前进的方向。

# 这对 Builder 有什么意义

它带来的不只是更好看的时间线页面，也给 Subspace Builder 提供了更有用的发布形式。

当一个想法值得组织结构、配上截图、详细解释和打磨时，长文仍然承担主要工作。时间线条目则覆盖周围那些更小的时刻：最初的想法、进行中的阶段进展、交付更新，以及功能再次演进后的后续记录。

当条目可以互相关联，这些小时刻就不再显得随手可弃。它们成为相互连接的公开轨迹，记录一个功能如何逐渐成形。

这让网站无论作为读者体验，还是维护者工具，都更有用。读者可以跟随功能的故事，不丢失上下文；作者可以发布渐进进展，不必把每次更新都硬塞进完整文章的框架。

# 时间线终于像真正的开发日志了

时间线最初是一种更轻的发布形式。有了关联条目，它开始成为更明确的东西：网站自身可以串联起来的开发日志。

这是我最喜欢的部分。它为公开思考腾出了空间，不必把一切都压成“短小笔记”或“完整发布文章”。有些工作适合用一连串小更新来记录，现在网站有了原生表达它的方式。

配上截图后，从平面更新到串联式开发日志条目的变化，就更容易看清了。