之字形板块——格式、规则与示例

之字形板块以重复的图文配对形式呈现一系列并列功能，在宽屏上交替变换视觉内容的位置。使用这种模式可以在精心构思的产品叙事中创建清晰的视觉检查点，而不是把短列表拉伸成一个冗长的着陆页。

上述渲染示例展示了这种节奏，但其灰色区域仅为本文档中的说明性 UI。实际生产实例必须包含真实、有信息量的视觉内容。

为何该元素重要

长页面会带来导航问题。读者需要地标来告诉他们一个想法在哪里结束、下一个从哪里开始。之字形节通过重复提供了这些地标：图片、标题、说明；然后相同的结构以不同的宽屏对齐方式呈现。重复的结构使每个板块更易于理解，而交替则防止相邻项目合并成一列。

当项目真正并列时，这种心理益处最为显著。读者看到第一对，学会模式后，便可以浏览后续的标题和视觉内容，再决定在哪里深入阅读。视觉内容提供识别，标题命名能力，正文解释其影响。交替只需增加足够的位置变化来重置注意力，而不改变信息模型。

但这种益处有其限度。每一对都会占用大量垂直空间，尤其是在手机列叠放的情况下。如果说明只有一句话，而视觉内容不提供任何证据，这种模式只会让读者花费更多精力而没有学到更多。装饰性的交替也可能让人感觉像是销售模板，而非合理的序列。只有当每个视觉内容都能帮助读者理解一个独特的功能、状态、结果或工作流程时，这个元素才值得占据那么多空间。

机器可提取性意味着软件可以在不丢失使其准确的上下文的情况下分离出内容单元。一个编写良好的之字形板块是一组明确的项目集合，每个项目都有标题、自包含的说明、视觉描述和可选链接。检索系统可以提取出一个项目作为一个连贯的功能陈述，因为其含义不依赖于"它是左边那个"。源顺序（而非 CSS 布局）决定了序列。

请先应用元素写作规则 ，再应用本页规则：先起草完整的说明，然后在单独的结构化步骤中应用类型化元素。当本页对项目数量、媒体要求、正文映射或嵌套限制有更严格的设置时，以这些元素特定规则为准。

何时使用

当以下所有条件都满足时，使用之字形板块：

1. 页面包含三到六个并列的功能、能力、结果或非顺序的工作流程视图。
2. 每个项目都有一个能说明或展示其主题的真实视觉内容。
3. 每个项目需要的解释比卡片所能容纳的更多，但比完整的独立章节更少。
4. 读者在阅读每个细节之前，能从扫描序列中获益。
5. 顺序有助于理解但不是程序性的；单独提取一个项目仍然可以理解。

强用例包括：产品导览（每个能力对应一个界面视图）、解决方案页面（将每个运营问题与其相应的工作流程配对）、或终极指南（展示多个并行模型）。视觉内容可以是截图、图表、曲线图或照片——只要该媒介承载信息。当原始界面截图会让读者费力寻找相关控件时，可在项目内部使用带注解的截图 。

常见误用情况。不要将之字形板块用于编号说明：改变侧边会削弱步骤所需要的方向信号。不要用于对比，因为交替排列产品会妨碍按标准逐项评估。不要用于十二个各需一句话的优势；卡片、项目符号或汇总表能更好地利用空间。不要用于每个板块都依赖前一个结论的论证；连贯的散文和标题更能保留这种逻辑。

最有效的检验方法是移除图片。如果剩余的标题能形成一组连贯的同级项，且每个缺失的图片都留下了有意义的证据缺口，那么之字形板块可能是合适的。如果文字变成了通用的优势列表且没有丢失重要信息，那么图片只是装饰，该元素被误用了。

放置位置

将之字形板块放在页面已定义共同问题并命名了能力组之后。读者应该在遇到第一个大视觉内容之前就知道这个序列为何重要。在产品或解决方案页面上，这通常在英雄区、直接答案或简短概述之后，在证据、详细规格、定价或最终行动号召之前。

用一个 H2 和一段简短的框架性文字来介绍整个序列。不要在每个项目前单独添加 H2；每个项目标题都是共享板块内的子标题。保持所有项目连续，以便交替节奏传达这是一个集合。如果需要较长的限定条件打断序列，则完成之字形板块后，在其后另起新板块。

之字形板块不能紧邻另一个大型视觉序列、图片画廊、产品轮播、时间线或重复的卡片网格。连续的展示模式会造成视觉疲劳，并模糊哪个集合是主要的。不能将声明与其证据分开、不能将警告与其限定的说明分开、不能将价格与其购买条件分开。不能出现在有序列表、表格单元格、折叠面板或另一个之字形板块内部。

默认情况下每页使用一个之字形板块。只有当两个集合针对明显不同的问题、使用独立的板块标题、并且之间有散文或证据时，才允许使用第二个。绝不要仅仅为了模仿模式而交替不相关页面板块的对齐方式；集合边界是该元素含义的一部分。

结构

1. 集合标题： 命名每个项目所涵盖的共同问题或分类。
2. 集合介绍： 解释项目为何归为一组以及读者应注意什么。
3. 项目容器： 在编程和视觉上将视觉内容与文本区域关联在一起。
4. 项目标题： 用具体的语言命名一个特定的功能、结果或视图。
5. 项目正文： 解释项目的作用、为何重要以及正确理解所需的任何边界条件。
6. 信息性视觉内容： 展示与文本相同的内容，并配有有用的替代文本或无障碍说明文字。
7. 可选项目链接： 在说明之后提供一个相关的深入内容或操作。
8. 展示交替： 在宽屏上改变视觉内容的侧边，但不改变 DOM 顺序或含义。

间距、颜色、圆角、图片裁剪和断点属于渲染层。作者提供语义顺序、完整的文案和无障碍媒体信息。

设计变体

以下是支持的变体。它们共享同一内容契约；仅起始对齐方式、视觉处理方式或视口行为有所不同。

媒体优先： 默认宽屏变体，第一个视觉内容从左侧开始。当第一个视觉内容能提供即时识别，且周围页面未在该侧放置大图时使用。

文本优先： 从左侧文本开始，然后交替。当开头的说明必须在第一个视觉内容之前确立含义，或者这样能更好地与前一板块保持平衡时使用。

容器媒体： 将截图或图表置于一致的框架内。适用于产品界面、图表和图形（其边缘和标签很重要）。即使原始图片尺寸不同，所有项目也使用相同的框架逻辑。

边缘媒体： 允许照片或非界面插图填充其区域。裁剪可能随响应式布局变化，但不得移除主体或任何文案描述的信息。

移动堆叠： 移除左右交替，每个项目使用一致的阅读顺序。这是必需的响应式行为，而非可选的编辑变体。

没有纯文本、自动播放或轮播变体。移除有意义的媒体即移除了使用之字形板块的理由；动效和隐藏幻灯片引入了不同的交互契约。

参数

父级正文将其第一个标题映射到 title，其后的段落映射到 intro，每个嵌套项目映射到一个重复对。项目的第一个标题映射到 item.title；剩余正文映射到 item.content。媒体引用和替代文本保留在项目上，因为它们仅描述该项目。作者不能为每个项目设置左或右：渲染器根据源位置和 start 推导宽屏对齐方式。

语法与代码示例

所有适配器必须保留一个父级标题、一个介绍、有序的项目以及稳定的源顺序。示例将集合缩写为三个项目（最小有效数量）。

可移植 Markdown 指令

:::zigzag{start=media mediaFit=contain}
## 将内容决策转化为可重复的系统

从完整的内容清单，到优先的生产安排，再到可衡量的成果。

::item{media="inventory-view" alt="按状态和所有者分组的内容清单。"}
### 查看完整清单

在决定更改之前，将每个 URL、所有者、状态和性能信号汇集到一个视图中。
::

::item{media="priority-view" alt="按业务价值和投入排序的优先级队列。"}
### 优先处理有价值的工作

按业务价值和投入对机会进行排序，使团队能够按合理的优先级行动。
::

::item{media="impact-view" alt="带发布注解和性能变化的报告视图。"}
### 衡量发布的影响

将每次更改与一条注解和一个稳定的报告窗口关联起来，以便后续变化可被追溯分析。
::
:::

这些标识符记录了可移植契约；生产适配器将每个标识符解析为已批准的资产。作者必须在发布前确认已解析的资产存在。

Hugo 短代码

{{< zigzag title="将内容决策转化为可重复的系统" intro="从完整的内容清单，到优先的生产安排，再到可衡量的成果。" start="media" mediaFit="contain" >}}
  {{< zigzag-item title="查看完整清单" media="inventory-view" alt="按状态和所有者分组的内容清单。" >}}
  在决定更改之前，将每个 URL、所有者、状态和性能信号汇集到一个视图中。
  {{< /zigzag-item >}}
  {{< zigzag-item title="优先处理有价值的工作" media="priority-view" alt="按业务价值和投入排序的优先级队列。" >}}
  按业务价值和投入对机会进行排序，使团队能够按合理的优先级行动。
  {{< /zigzag-item >}}
  {{< zigzag-item title="衡量发布的影响" media="impact-view" alt="带发布注解和性能变化的报告视图。" >}}
  将每次更改与一条注解和一个稳定的报告窗口关联起来，以便后续变化可被追溯分析。
  {{< /zigzag-item >}}
{{< /zigzag >}}

Hugo 适配器仅使用命名参数。它根据项目位置推导交替类，且不得重写源顺序来实现视觉模式。

WordPress 区块

<!-- wp:amicited/zigzag {"title":"将内容决策转化为可重复的系统","intro":"从完整的内容清单，到优先的生产安排，再到可衡量的成果。","start":"media","mediaFit":"contain"} -->
  <!-- wp:amicited/zigzag-item {"title":"查看完整清单","media":"inventory-view","alt":"按状态和所有者分组的内容清单。"} -->
  <p>在决定更改之前，将每个 URL、所有者、状态和性能信号汇集到一个视图中。</p>
  <!-- /wp:amicited/zigzag-item -->
  <!-- wp:amicited/zigzag-item {"title":"优先处理有价值的工作","media":"priority-view","alt":"按业务价值和投入排序的优先级队列。"} -->
  <p>按业务价值和投入对机会进行排序，使团队能够按合理的优先级行动。</p>
  <!-- /wp:amicited/zigzag-item -->
  <!-- wp:amicited/zigzag-item {"title":"衡量发布的影响","media":"impact-view","alt":"带发布注解和性能变化的报告视图。"} -->
  <p>将每次更改与一条注解和一个稳定的报告窗口关联起来，以便后续变化可被追溯分析。</p>
  <!-- /wp:amicited/zigzag-item -->
<!-- /wp:amicited/zigzag -->

WordPress 应将内部区块限制为之字形项目，并提供列表重排序功能，但不提供手动左右控制。编辑器预览和前端必须使用相同的项目顺序。

示例

优秀示例

标题：了解内容更新的每个阶段

1. 发现下降页面 — 趋势图显示同一 URL 在可比时间段内的表现。文案说明如何区分持续下降与常规周度波动。
2. 诊断原因 — 查询和页面视图显示哪些主题失去了可见性。文案区分意图偏移、竞争对手增强、信息过时以及技术故障。
3. 记录干预措施 — 注解视图显示发布日期和确切更改内容。文案解释为何记录的干预措施使后续衡量可信。
4. 审查结果 — 报告视图显示约定的观察窗口。文案说明成功、无变化和进一步下降各自触发的后续动作。

这个示例行之有效，因为四个项目描述了同一更新系统中的并行视图，每个视觉内容提供了文案无法高效复制的证据，且仅标题本身就给读者提供了有用的扫描信息。顺序支持叙事，而不会把元素变成操作指令。

糟糕示例

标题：为什么我们的平台更好

1. 简单易用 — 一张微笑人物的装饰性照片，配文"我们的平台易于使用。"
2. 功能强大 — 一个装饰性的抽象形状，配文"更快获得强大结果。"
3. 灵活适配 — 一张库存照片，配文"灵活功能适合每家企业。"
4. 联系我们 — 一个大型表单要求填写七个字段。
5. 值得信赖 — 一个标志列表，未说明这些标志代表谁。
6. 更多功能 — 八个不相关的项目符号填满了最后一长行。

这个示例失败的原因是：声明过于笼统，图片不承载任何信息，项目各司其职却不统一。嵌入的表单打断了集合，而最后一个项目将列表隐藏在一个本应用于专注说明的格式中。页面变长了却没有变得更清晰。将前三个声明替换为有证据支持的散文或紧凑的优势卡片，将表单放在说明性板块之后，标识信任证据，并为其余功能提供合适的列表或表格。

结构化数据标记与无障碍

之字形是一种展示模式，而非 Schema.org 类型。其文案仍属于包含它的 Article 或 WebPage，产品事实仅在页面和事实独立满足相应要求时，才能贡献给有效的 Product 或 SoftwareApplication 标记。不要因为元素重复项目就输出 ItemList，当项目为并行功能而非必需步骤时绝不要输出 HowTo。

为集合使用带无障碍标题的 section，为每个项目使用语义化的 section 或 article。保持 DOM 顺序逻辑合理且在各断点间一致。CSS 网格排序可能改变图片的视觉位置，但键盘、屏幕阅读器、复制粘贴和搜索引擎提取顺序必须保持一致。切勿写"如左图所示"或"如右侧图片所示"，因为这些位置在较小屏幕上会反转或消失。

每张有信息量的图片都需要替代文本，说明该图片在上下文中提供了什么信息。不要逐字重复相邻段落。如果复杂的图表、界面或示意图无法简洁描述，请添加可见的说明文字或附近的长描述。不鼓励使用装饰性图片，因为每个项目都需要证明其视觉内容的合理性；如果渲染器添加了装饰性点缀，则它们应使用空的替代文本。

标题必须遵循页面层级结构，而非硬编码为视觉尺寸。项目链接需要使用描述性标签，如"查看库存工作流程"，而非重复的"了解更多"。不要将整个图文行做成一个大链接：嵌套链接和模糊的激活区域会造成键盘和屏幕阅读器问题。尊重减少动效偏好，且绝不要依赖滚动触发的动画来展示内容。

写作规则

集合标题使用 3–12 个词，介绍使用 20–60 个词。每个项目标题使用 3–9 个具体词汇，正文使用 40–120 个词。支持三到六个项目。这些限制的存在是因为该元素需要足够的内容来支撑大面积的视觉区域，又不至于让每一对变成独立的小论文。

使项目标题在语法上保持平行。如果第一个以动词开头——“发现下降页面”——其他的也应以动词开头。每个正文应按自然顺序回答三个问题：这是什么、为什么在此处重要、读者应在视觉内容中注意什么？使用具体的名词、界面标签、条件和后果。避免使用无限制的超级词汇，如"最佳"、“强大"或"革命性”。

保持深度平衡。一个 110 词的项目旁边有两个 40 词的项目，表明集合可能在混合不同的抽象级别。拆分宽泛的项目、合并浅显的项目，或将细节移至链接页面。链接是可选的，每个项目限制为一个，以便序列保持说明性而非变成导航目录。

绝不在之字形项目内放置以下内容：

• 表单、新闻通讯订阅、价格表、优惠或主要行动号召。
• 对比表格、折叠面板、标签页、轮播、画廊、视频播放器或另一个之字形板块。
• 顺序对成功至关重要的编号步骤。
• 为填充视觉高度而添加的几个不相关的功能项目符号。
• 无来源和上下文的不支持的声明、推荐片段或标志。
• 仅因布局有图片位置而添加的图片。

使用该元素的帖子类型

postTypes 前置元数据是此关系的权威来源。在每种列出的类型中，之字形板块是可选的，仅当页面有合格的并行视觉序列时使用。

QA 检查清单

• 序列包含三到六个真正并行的项目。
• 一个 H2 和简短介绍说明项目为何归为一组。
• 每个项目都有具体且语法平行的标题。
• 每个正文保持在 40–120 词且深度相当。
• 每个视觉内容都存在、传递信息且与其项目匹配。
• 替代文本或无障碍说明文字传达了每个视觉内容的有用信息。
• 默认 DOM 顺序即使没有 CSS 或图片也逻辑合理。
• 宽屏交替是自动推导的；作者未分配任意侧边。
• 移动端保持一致堆叠顺序，无水平滚动。
• 没有措辞依赖于左、右或其他特定视口的位置。
• 项目内不含表单、表格、嵌套展示组件或步骤。
• 集合不紧邻另一个大型重复视觉模式。
• 链接具有描述性且限制为每个项目一个可选链接。
• 不单纯依据交替布局推断任何 schema 类型。
• 当动效禁用且图片加载缓慢时，页面仍然可用。
• Markdown、Hugo 和 WordPress 表示保留相同的字段和项目顺序。

在并行想法值得并行证据时使用之字形板块。交替应帮助读者注意到每个连贯的项目；它绝不应成为项目存在的原因。