时间线：如何按顺序呈现事件和阶段

时间线是按顺序记录的事件、里程碑或命名阶段的集合，其中位置传达了某事发生的时间或某个主题如何发展。读者观察顺序；他们不被指示去重现它。

1. 1
   2025年3月 — 研究获批

   团队在数据收集开始前确定了群体、问题和比较方法。
2. 2
   2025年4月至5月 — 基线收集

   在定义的收集窗口内对每位参与者记录了相同的测量指标。
3. 3
   2025年6月 — 发现发布

   报告发布了其结果，包括方法、局限性和下一次审查日期。

这个渲染示例描述了一个已完成的研究序列。其顺序解释了批准、收集和发布之间的关系，但其中没有任何条目命令读者执行这些操作。

为什么这个元素很重要

人们通过提出三个问题来重构变化：发生了什么、何时发生、以及它导致或促成了什么？ 时间线用一个重复的模式回答这些问题。日期或阶段标记创建了定位，事件标题为变化命名，描述解释了其意义。读者可以扫描已知的里程碑、比较事件之间的间隔，或理解为什么当前状态不可能更早存在。

这种视觉节奏也减轻了记忆负担。在普通散文中，日期可能与其限定的事件分离，读者在构建时间顺序之前必须在脑海中记住多个句子。一个有边界的时间线将每个标记与其事件保持在一起，并使遗漏或无法解释的跳跃变得可见。当段落的论断依赖于顺序时，它尤其有用：干预后观察到的结果与干预前收集的结果含义不同。

机器可提取性是指爬虫、搜索引擎、AI 问答系统或发布适配器能够在不丢失顺序或字段的情况下隔离每条记录的能力。一个语义化的有序列表，具有一致的日期、标题和描述区域，比散布在段落中的日期为机器提供了更强的结构。系统可以识别第三个事件是第三个事件，保留"2025年6月"和"发现发布"之间的关系，并引用描述而不会错误地将其附加到四月。

使用元素编写规则 作为优先级规则。如果一段内容的目的是记录随时间的变化，即使标题和几个段落看起来类似，也应使用类型化时间线。如果其目的是指令、比较或独立验证，则相应的元素优先，无论设计者是否可以在其旁边画出垂直线。

何时使用

当排序是论断的一部分且每个条目代表一个事件、里程碑、状态转换或记录在案的阶段时，使用时间线。合适的主题包括公司历史、产品发布、法规的采纳和执行日期、已完成案例研究的各个阶段，或报告背后的收集和发布阶段。

在选择之前应用两个测试：

1. **交换测试：**交换两个相邻条目。如果描述在历史上变得不真实、在因果关系上具有误导性或时间上令人困惑，则顺序承载着意义。
2. **观察者测试：**询问读者是在了解发生了什么还是被告知该做什么。观察表示时间线；执行表示步骤列表 。

接近但不适用的情况需要不同的结构：

• 操作步骤：“导出数据、清理数据，然后上传"是在指示读者。它需要操作、成功信号和恢复路径，而不是历史事件描述。
• 检查清单：“确认所有者、日期、来源和状态"包含独立的验证关卡。它们的顺序不创造意义。
• 功能列表：“推出了报告、集成和警报"可能只是枚举能力。只有当有日期的发布及其后果重要时才成为时间线。
• **前后对比论断：**两个状态通常以直接比较的形式更清晰。不要添加装饰性的中间点来达到最小条目数量。
• **项目计划：**计划中的日期仅当明确标记为已排定或预测时才可使用时间线。不要将意图呈现为已完成的历史。
• **流程概览：**当页面描述流程如何组织时，命名阶段可以使用时间线。如果读者必须执行这些阶段，请改用步骤列表或检查清单。

仅有日期是不够的。一个不相关的会议日期列表是日历或清单。时间线需要一个主题和一条连贯的发展线索。

放置位置

将时间线放置在一个简短的句子之后，该句子说明其主题、范围和方向。“以下里程碑从成立到当前产品"就足够了。读者永远不需要推断第一个条目是最旧的、最新的、已完成的还是计划中的。

确切位置取决于其作用：

• 将历史时间线放在主题的定义或当前状态总结之后，以及分析其历史为何重要之前。
• 将案例研究时间线放在起始情况和范围之后，但在详细结果之前，以便读者能够区分基线、干预和测量。
• 将发布时间线放在当前发布摘要之后。当发现最新变化是主要任务时，使用最新优先的顺序，并标明该方向。
• 将实施或政策时间线放在规则范围之后和当前义务之前。生效日期必须在任何折叠界面之外保持可见。
• 将研究时间线放在方法摘要之后和发现之前，当收集时机影响解释时。

时间线不得紧挨着关于同一主题的步骤列表，除非有过渡说明哪个块记录历史、哪个块指示操作。不得插入论断与其支持来源之间、警告与其后果之间，或比较单元格内部。不要将两个时间线并排放置；当它们共享主题和规模时将其合并，或用分析隔开以解释为什么第二个序列是不同的。

避免在事件之间放置促销性行动号召。它会破坏时间顺序流和有序列表语义。将促销放在完整的时间线及其解释之后。

结构

标记的结构包含七个部分：

1. **范围标题：**命名集合所代表的主题和时间跨度。
2. **方向提示：**当周围上下文不能明确说明时，说明是从最旧到最新还是从最新到最旧。
3. **有序轨道：**在视觉上连接记录，同时底层的 <ol> 在不依赖样式的情况下保存顺序。
4. **日期或阶段标记：**以最诚实的可用精度标识事件发生的时间。
5. **事件标题：**用紧凑的过去时或现在时短语说明变化或里程碑。
6. **描述：**解释发生了什么变化以及为什么此事件属于该序列。
7. **状态：**可选地用文字（而非仅用颜色）区分已完成、当前、已排定、延迟或取消的事件。

线条、圆点和图标是装饰性的。日期、标题、描述、顺序和状态是内容，必须在文本、打印和无 CSS 输出中保持可用。

设计示例

每个支持的变体都保留一个有序列表和相同的条目字段。变体改变密度或强调，而非含义。

标准垂直

对于三到八个带有单句或双句描述的事件，使用默认样式。它为可变长度的文本提供了换行空间，并在窄屏上可靠工作。

紧凑变更日志

对于简短频繁的记录（如发布），使用紧凑间距。标题在前；描述保持在一个句子内。仅当标题或方向提示说明时才允许最新优先的顺序。

里程碑强调

当两到六个转折点比它们之间的间隔更重要时，使用里程碑强调。高亮的当前里程碑必须包含可见的文字"当前”；仅靠大小或颜色是不够的。

阶段化时间线

当精确日期不可用或不如生命周期位置有用时，使用命名阶段。阶段标记必须互不相同且粒度一致：“发现”、“收集"和"发布”，而不是"发现”、“5月12日"和"稍后”。

水平宽屏

仅在有三到五个简短里程碑时使用水平展示，且仅当它能在小屏幕上变为垂直有序列表且不改变源顺序时。绝不需要水平滚动来发现事件。

混合状态路线图

当需要包含已完成和计划中事件的真实路线图时，使用此变体。每个条目都需要文本状态，不确定的日期使用诚实的范围（如"2026年第四季度”）而非编造的日期。

参数

契约将集合设置与重复的事件记录分开。第一个父级标题提供集合标题；每个条目的第一个标题提供其事件标题。

marker 是可见的，可以包含读者能理解的精度日期，例如"2025年5月"或"2026年第三季度”。仅当来源支持机器可读的日历日期时才提供 date。像"2025年春季"这样的标记不得转换为编造的 ISO 日期。在阶段化变体中，marker 包含阶段名称，date 通常省略。

语法和代码示例

以下三种形式都编码了相同的已完成时间顺序记录。可移植指令是规范的创作者结构；平台适配器必须保留顺序、字段和可见措辞。

可移植 Markdown 指令

:::timeline{variant=vertical direction=ascending}
## 研究和发布时间线

::item{marker="2025年3月" date="2025-03-01" status=completed id="research-approved"}
### 研究获批

团队在数据收集开始前确定了群体、问题和比较方法。
::

::item{marker="2025年4月至5月" status=completed id="baseline-collected"}
### 基线收集

在定义的收集窗口内对每位参与者记录了相同的测量指标。
::

::item{marker="2025年6月" date="2025-06-18" status=completed id="findings-published"}
### 发现发布

报告发布了其结果，包括方法、局限性和审查日期。
::
:::

范围"2025年4月至5月"没有 date 属性，因为单一的 ISO 日期会歪曲跨月事件。

Hugo 短代码

{{< timeline_with_icon >}}
[
  {"title":"2025年3月 — 研究获批","description":"团队在数据收集开始前确定了群体、问题和比较方法。"},
  {"title":"2025年4月至5月 — 基线收集","description":"在定义的收集窗口内对每位参与者记录了相同的测量指标。"},
  {"title":"2025年6月 — 发现发布","description":"报告发布了其结果，包括方法、局限性和审查日期。"}
]
{{< /timeline_with_icon >}}

现有的 Hugo 渲染器接受一个带有 title 和可选的 description 字段的 JSON 数组，并按源顺序渲染记录。将标记和标题合并到 title 中是其当前的适配器映射；更丰富的渲染器可以分离这些可见区域而不改变规范内容。

WordPress 区块

<!-- wp:amicited/timeline {"variant":"vertical","direction":"ascending"} -->
<!-- wp:amicited/timeline-item {"marker":"2025年3月","date":"2025-03-01","status":"completed","id":"research-approved"} -->
<h3>研究获批</h3>
<p>团队在数据收集开始前确定了群体、问题和比较方法。</p>
<!-- /wp:amicited/timeline-item -->
<!-- wp:amicited/timeline-item {"marker":"2025年4月至5月","status":"completed","id":"baseline-collected"} -->
<h3>基线收集</h3>
<p>在定义的收集窗口内对每位参与者记录了相同的测量指标。</p>
<!-- /wp:amicited/timeline-item -->
<!-- wp:amicited/timeline-item {"marker":"2025年6月","date":"2025-06-18","status":"completed","id":"findings-published"} -->
<h3>发现发布</h3>
<p>报告发布了其结果，包括方法、局限性和审查日期。</p>
<!-- /wp:amicited/timeline-item -->
<!-- /wp:amicited/timeline -->

WordPress 必须将记录存储为一个有序的父级区块及其子条目，而不是在编辑过程中顺序可能漂移的不相关视觉卡片。

示例

正确：法规的实施历史

2024年1月 — 规则发布。 监管机构发布了最终文本并确认了范围内的组织。

2024年7月 — 过渡期开始。 涵盖的组织可以采用新报告格式，同时旧格式仍然被接受。

2025年1月 — 要求生效。 新提交必须使用已发布的格式；过渡选项结束。

2025年4月 — 指南澄清。 监管机构解释了修正后的提交应如何标识原始报告期间。

这是一个正确的时间线，因为每个条目描述了一个记录在案的事件，精度一致，顺序解释了从发布到过渡、执行和澄清的演变。读者可以理解当前的义务，而不会将未来的截止日期误认为过去的事件。

错误：文章优化时间线

1 — 添加示例。 在文章中包含有用的示例。

2 — 检查标题。 确保标题描述每个部分。

3 — 添加内部链接。 链接到相关内容。

这是错误的，因为它既不是时间顺序记录也不是合理的程序。这些数字没有日期或阶段，且这些操作可以按不同顺序执行而不改变结果。称其为时间线是用虚假的顺序来装饰独立的检查项。对独立的审查关卡使用检查清单；仅当依赖关系使执行顺序成为必要时才使用步骤列表。

Schema 标记和无障碍

Schema.org 没有通用的 Timeline 类型。不要输出编造的属性或仅仅为了让区块看起来有结构而添加 ItemList。时间线可以在适当的词汇表已经存在时，为页面级结构化数据提供可见事实——例如，在软件相关页面上提供已发布的发布日期——但该映射由页面的 schema 契约决定，而非由视觉组件决定。结构化数据绝不能包含从可见时间线中省略的事件、日期或状态。

可靠的机器可读基线是语义化 HTML：一个按预期阅读顺序排列的 <ol>，每个事件对应一个 <li>。仅当机器日期有来源支持时，才使用 <time datetime="2025-06-18">2025年6月</time>。如果可见标记是季度、季节、范围或命名阶段，纯文本比编造的 datetime 值更真实。

无障碍性取决于在不依赖图形轨道的情况下保留顺序。标题命名主题和方向；有序列表提供计数和位置；每个事件将其标记、标题、描述和状态保持在一起。装饰性线条、圆点和图标使用空替代或对辅助技术隐藏。状态以文本形式编写，而不是仅通过绿色、琥珀色或实心圆来传达。

不应需要键盘交互来阅读时间线。如果单个事件链接到证据或详细信息，使用普通的描述性链接和可见的焦点状态。水平布局必须重新流动，而不是将键盘或触摸用户困在横向滚动器中。200% 缩放、窄视口显示、打印输出和无 CSS 输出必须保留相同的顺序。

编写规则

一个时间线中使用三到十二个事件。少于三个时，普通散文或直接的前后对比更清晰。超过十二个时，读者会失去整体形状；将事件分组为命名时代或创建具有独立范围的单独时间线。

每个事件标题写 2 到 10 个词，描述写 12 到 60 个词。标题以变化开头，而不是填充词：“要求生效"比"一个重要的新阶段"更有力。描述回答什么发生了变化以及为什么该事件重要。对已完成的事件使用过去时，对当前状态使用现在时，对计划事件使用将来或已排定的语言。

日期精度必须遵循证据。如果来源只支持年份，就发布年份。如果支持季度，不要为显示或元数据编造季度的第一天。在一个时间线内使用一种日期样式：“2025年6月18日"不得与"06/20/25"并列，当区域解释存在歧义时应避免使用数字日期。

保持粒度一致。一个结合了"公司成立”、六个小型每周补丁和"达到国际分销"的时间线，给常规变化赋予了比战略里程碑更多的视觉权重。要么一致地记录发布，要么一致地选择里程碑并说明选择规则。

绝不要将以下内容放入事件内部：

• 读者必须执行的多步骤指令；
• 不相关的促销性行动号召；
• 用作事件证据的客户推荐；
• 隐藏在展开区域后的必要警告；
• 为减少条目数量而合并的几个独立事件；
• 来源不支持的日期或状态。

语气应实事求是、紧凑且具体。避免庆祝性语言，如"改变游戏规则的里程碑”，除非页面将其作为引文引用并提供上下文。时间线通过可验证的顺序建立可信度，而非热情。

使用它的文章类型

以下行由 postTypes 前置元数据驱动，仅使用已注册的文章类型标识符。

不要为了满足文章类型的模板而在页面没有有意义的时间顺序记录时添加时间线。前置元数据表达了支持的关系，而非要求每个实例都必须包含该元素。

QA 检查清单

发布前，验证以下所有项：

• 每个条目记录一个事件、里程碑、状态或阶段，而不是指示读者。
• 交换相邻事件会使描述变得虚假、有误导性或更难理解。
• 引言说明了主题、范围和时间方向。
• 时间线包含 3–12 个条目，或记录了明确的分组决策。
• 日期精度和状态有来源支持；没有编造精确日期。
• 标题包含 2–10 个词，描述通常包含 12–60 个词。
• 事件使用一致的粒度级别和一种日期样式。
• 已完成、当前、计划中、延迟和取消的记录在可见文本中有所区分。
• 源是有序集合，输出为每个事件使用一个 <ol> 和一个 <li>。
• 标记、标题、描述和状态在打印、无 CSS 和窄屏输出中保持在一起。
• 装饰性线条、图标和颜色不携带文本中缺失的信息。
• 任何结构化数据完全匹配可见事件，且仅使用适合页面的词汇表。
• 可移植 Markdown、Hugo 和 WordPress 映射保留相同的顺序和含义。
• 放置不中断证据、警告、指令或最终解释。

常见问题

时间线和步骤列表有什么区别？ 时间线记录发生了什么；步骤列表告诉读者该做什么。观察者测试可以确定选择。

每个时间线条目都需要精确日期吗？ 不需要。使用证据支持的最精确标记，包括月份、季度、年份或命名阶段。

一个时间线应该包含多少个事件？ 使用三到十二个。将更长的历史分组为命名时代或单独的序列。

时间线有自己的 Schema.org 类型吗？ 没有。使用语义化有序列表 HTML，以及仅真实匹配适当词汇表的页面级结构化数据。

时间线可以从最新到最旧排列吗？ 可以，当最新优先的发现是读者的主要任务时。标明方向并保持一致性。