信息框：双栏 — 格式、规则和示例

双栏信息框将一个想法拆分为恰好两个平行的要点，使读者一眼就能理解两者之间的关系。当这两个要点并排展示比埋没在段落中更有用时使用它：两种职责、两个阶段、两种视角，或一个答案的两个互补部分。

上述渲染示例即为一个信息框、一个共享标题和恰好两个条目。两个条目以相当的深度回答了同一类问题。该元素并不声称这两种需求是对立的；它表明一份有用的简报必须兼顾两者。

为什么这个元素很重要

密集的散文迫使读者自行重建关系。在诸如"内容简报必须为读者服务——解决一个任务，同时为业务服务——支持一个有资格的操作"这样的句子中，两个职责确实存在，但它们的边界是模糊的。双栏信息框使共同主题一次性可见，并为每个职责提供了一个命名的区域。读者可以扫描两个标题，选择从哪一栏开始，并在无需重读一个复合句的情况下，比较细节的数量和类型。

心理上的好处来自分块：将相关信息分组到有边界的单元中。共享标题告诉读者什么是不变的，而条目标题则显示什么在变化。当两个要点都不应占据主导地位时，这种层次结构尤为有用。普通的散文自然会让第一个要点更突出，并可能使第二个要点感觉像事后补充；而并排的栏目则表明同等的编辑权重。

机器可提取性是指软件在保留含义的前提下隔离内容单元的能力。一个类型化的信息框暴露一个父主题和两个明确的子条目。检索系统可以保留共享标题、条目标题、正文内容和源码顺序，而不是猜测一个从句在哪里结束、另一个从哪里开始。每个条目仍需自成一体：“业务需求是支持有资格操作的证据"在提取后仍能成立，而"另一方面"则不行。

结构并不能拯救薄弱的思考。如果来源中有一个充分阐述的要点和另一个仅为对称而添加的句子，渲染器只会让这种不平衡更加明显。请遵循元素写作规则 ：先写出完整的推理，然后仅在最终想法确实具有两个平行部分时才选择此元素。本页面的元素特定规则在定义其精确的条目映射和限制时优先适用。

何时使用

当以下四个条件全部满足时，使用双栏信息框：

1. 有一个清晰的主旨想法，可以作为整个信息框的标题。
2. 该主旨想法自然分为恰好两个条目。
3. 两个条目执行相同的信息职能，例如解释职责、阶段、受众视角或维度。
4. 每个条目可在大约 30–90 词内理解，且无需嵌套结构。

好的用途包括"发布前 / 发布后”、“读者信号 / 业务信号”、“变化的 / 不变的"和"负责人职责 / 审核人职责”。标签应揭示真实的关系。如果读者无法说出"这两者属于一起，因为……“这句话，那么这个分组很可能是装饰性的。

临界情况也很重要，因为双栏布局几乎可以让任何配对看起来是刻意的。不要将一个想法在任意句子边界处拆分开来使用。不要仅仅为了节省垂直空间而将四个条目的列表变成两个长栏；源码顺序和可扫描性会变得模糊。不要在涉及多个标准的详细产品对比中使用，因为对比表格为每个标准提供了显式的行。不要在利弊数量不同或读者需要权衡多个因素时用于优缺点对比。不要将定义与促销性行动号召配对：这些块执行不同的职能，不应被同等对待。

最危险的警示信号是如"其他”、“更多"或"附加信息"这样的标签。这些标签表明拆分是基于可用空间而非意义驱动的。将内容恢复为散文，或在使用该元素前找到实际的区别。

放置位置

将信息框放置在引入共同思想的段落之后。读者在遇到拆分之前需要一句上下文背景，但不应该穿过无关的证据或另一个子章节才能到达。在信息框之后，继续对两个条目都适用的分析、示例或说明。

当 H2 本身提供了主旨想法且信息框有自己更具体的标题时，它可以位于 H2 正下方。它也可以跟随一个简短的定义，当两个条目解释了该定义的各个维度时。它不得出现在主张与其引文之间、步骤与完成该步骤所需的条件之间，或有序列表项内部。这些位置会破坏本应连续的关系。

不要将其放置在另一个双栏信息框、对比表格、选项卡集或优缺点块旁边。相邻的平行结构迫使读者决定哪个视觉关系更重要，并可能在宽屏上创建四个明显的栏目。在不同结构之间插入解释性散文，或将这些材料合并为一个更适合的表格或章节。避免将其放置在双栏行动召唤之前或之后；相同的几何形状可能使编辑性解释看起来像促销。

在一个短章节中使用不超过一个双栏信息框。重复会将有用的对比变成页面装饰。当一篇长文章包含多个真实的配对时，将它们放在不同的标题下，并确认每个配对都有不同的主旨想法。

结构

结构包含一个父区域和两个重复的子区域。截图应标注语义部分，而非内边距或颜色标记，以便在视觉系统发生变化时，规范仍然可用。

1. 外边界： 将父标题和两个条目作为一个编辑单元进行分组。
2. 共享标题： 命名两个条目共同解释的想法。它不是第三个要点。
3. 第一个条目标题和正文： 以完整、可提取的语言说明配对的第一个成员。
4. 第二个条目标题和正文： 以匹配的深度回答同一类问题。
5. 布局关系： 空间允许时使用等宽列，窄屏时按条目一在前、条目二在后的顺序堆叠。

边框、背景、间距、圆角、字号比例和断点属于渲染器。作者控制的是内容层次结构和顺序，而非视觉标记。

设计变体

有一个语义元素，四种受支持的内容和视口变体。变体改变标题处理或响应式呈现；它们从不改变对恰好两个条目的要求。

默认有标题变体： 独立使用时的首选。共享标题命名主旨想法，两个子条目都有简洁的标题。

上下文标题变体： 紧接上方的 H2 可作为共享标题。仅当 H2 与信息框之间没有段落或组件分隔，且信息框具有从该标题派生的可访问名称时，才允许使用此变体。

紧凑变体： 用于两个简短的定义或职责。每个正文仍然构成完整的句子；布局不会变成一对标语。

窄视口变体： 条目垂直堆叠。顺序无需借助"左”、“右”、“上"或"旁"的引用也能保持意义。

图标并非内容变体。如果设计系统添加了装饰性图标，它们应使用空的替代文本，且不得替代条目标题。如果每个条目需要信息性图片，请使用面向图片的元素，而不是扩展此信息框的约定。

参数

参数约定防止该元素演变为通用网格。描述含义的值属于创作内容；响应式布局保留在渲染器中。

标题是必需的，除非紧接上方的文档标题提供了相同的父主题，并且能够以编程方式标记容器。条目正文允许强调、内联代码和一个有用的链接。不允许嵌套标题、表格、媒体、手风琴组件、表单、行动号召或另一个信息框。

语法和代码示例

所有三种标记法都保留相同的父标题、两个有序条目、条目标题和条目正文。可移植的 Markdown 指令是规范来源。Hugo 和 WordPress 形式是适配器约定；它们的渲染器必须生成等效的语义 HTML 和响应式顺序。

可移植 Markdown 指令

:::infobox-2-columns
## 一份有用的内容简报回答两个问题

::item
### 读者需要什么？

说明页面必须解决的问题、决策或任务，包括改变答案的上下文背景。
::

::item
### 业务需要什么？

说明页面应支持的有资格的操作，以及赢得该操作所需的证据。
::
:::

第一个父标题映射到 title。每个 ::item 将其第一个标题映射到 item.title，其余正文映射到 item.content。这种精确的双条目映射覆盖了基础规则中的通用可重复条目允许项。

Hugo shortcode

{{< infobox-2-columns title="一份有用的内容简报回答两个问题" >}}
  {{< infobox-item title="读者需要什么？" >}}
  说明页面必须解决的问题、决策或任务，包括改变答案的上下文背景。
  {{< /infobox-item >}}
  {{< infobox-item title="业务需要什么？" >}}
  说明页面应支持的有资格的操作，以及赢得该操作所需的证据。
  {{< /infobox-item >}}
{{< /infobox-2-columns >}}

适配器仅使用命名参数。它必须拒绝第三个条目而非静默包裹，并且在布局堆叠时必须保持作者指定的条目顺序。

WordPress 块

<!-- wp:amicited/infobox-2-columns {"title":"一份有用的内容简报回答两个问题"} -->
  <!-- wp:amicited/infobox-item {"title":"读者需要什么？"} -->
  <p>说明页面必须解决的问题、决策或任务，包括改变答案的上下文背景。</p>
  <!-- /wp:amicited/infobox-item -->
  <!-- wp:amicited/infobox-item {"title":"业务需要什么？"} -->
  <p>说明页面应支持的有资格的操作，以及赢得该操作所需的证据。</p>
  <!-- /wp:amicited/infobox-item -->
<!-- /wp:amicited/infobox-2-columns -->

WordPress 应暴露两个固定的条目槽位，而非一个不受限制的"添加块"区域。编辑器可以重新排序两个条目，但不能在它们之间插入无关的块或添加第三列。

示例

好例子

这个例子之所以有效，是因为共享标题确立了一个想法，时间边界创造了一个真实的配对，并且两栏都指定了可比的测量工作。每个条目在堆叠或独立提取时仍然有意义。

坏例子

改进你的内容

写好内容： 创建有用、权威、引人入胜的内容，让你的受众喜爱，搜索引擎也会给予回报。

其他事情： SEO 还包括技术工作、链接、转化设计、分析、品牌建设、分发、维护以及许多其他重要活动。

这个例子之所以失败，是因为配对是人为的。“写好内容"是一个模糊的指令，“其他事情"是一个杂项类别，第二个条目包含的范围远大于第一个。该信息框暗示存在同等、平行的概念，但实际上并不存在。将其替换为定义实际内容目标的散文，然后使用列表或单独的章节来处理不同的工作流。

Schema 标记与无障碍

双栏信息框没有专门的 Schema.org 类型，也不会创建独立的结构化数据。当页面符合标记条件时，其文本仍属于包含它的 Article、TechArticle 或 WebPage 的一部分。不要仅仅因为有两条就将两个条目标记为 ItemList；该元素表示一种关系，不一定是排名列表或完整列表。如果某个条目独立包含一个在结构化数据中其他地方使用的事实，则页面级别的 Schema 策略管束该事实。

语义 HTML 应表达一个带标签的容器和两个子部分。仅当该配对是对周围叙述的补充时使用 aside；当它是主要论证的一部分时使用 section。通过其可见标题和 aria-labelledby 为容器提供可访问名称。每个子标题必须是正确级别的真实标题，而不是为视觉效果选择的加粗文本。

源码顺序即无障碍顺序。键盘导航、屏幕阅读器、复制粘贴和窄屏都必须先遇到条目一，再遇到条目二。CSS 可以创建列，但不得在视觉上反转它们。切勿提及"左侧框"或"右侧框”，因为这些位置在堆叠时会消失。颜色、图标形状和背景不能是区分条目的唯一方式。设计必须支持文本缩放而不裁剪、水平滚动或重叠列。

写作规则

首先写出父句子：“这个想法包含两个部分：X 和 Y。“如果这个句子不准确，就不要使用该元素。为两个条目标题使用相同的语法形式——两个名词、两个问题或两个时间短语——因为平行的语言使关系一目了然。

使用恰好两个条目。每个标题保持在 2–7 个词，每个正文在可能的情况下保持在 30–90 个词，绝对最多 120 个词。相差一句话是可以接受的；一个 35 词的条目与一个 110 词的条目相邻则需要编辑或改用不同的结构。每个正文应回答相同的隐含问题，并使用可比的证据深度。匹配深度并不意味着用填充内容来延长一个简短的答案。

使用直接、中立的语言。在标题中陈述区别，在正文中解释其后果。优先使用"发布前 / 发布后"而非"第一 / 第二”，因为有意义的标签在提取后仍然可用。除非选择确实是排他性的，否则避免使用"要么/要么”；当条目是互补的时，避免使用"对比”。

切勿将以下内容放入元素内部：

• 第三个条目，即使渲染器可以包裹它。
• 多步骤操作流程、长项目符号列表、数据表格、定价网格、表单、推荐语或促销横幅。
• 独立的 H2 章节、嵌套信息框、选项卡、手风琴组件、视频或图片库。
• 仅适用于信息框外某一句话的必要法律文本、安全警告、来源列表或限定条件。
• 两个旨在看起来像相互竞争的行动号召但互不相关的链接。

如果任一条目需要子标题或超过两个段落，则将两个条目都提升为普通页面章节。如果读者需要在条目之间做出选择，在散文中添加决策标准或使用对比或决策元素；仅凭视觉对称性无法解释一个选择。

使用该元素的内容类型

postTypes 前端元数据字段是该用法集的来源。每个列出的格式都有一个自然的二分关系，但当内容不构成真实配对时，不应默认包含该元素。

QA 检查清单

• 一个主旨想法： 信息框有一个清晰的共享主题，解释了两个条目为何属于一起。
• 恰好两个条目： 源码和渲染输出中包含两个子条目——绝不是零个、一个、三个或空槽位。
• 真正的平行性： 两个条目回答同一类问题，并使用语法的平行结构。
• 深度匹配： 两个条目都不是象征性的配重或杂项大杂烩；细节和证据具有可比性。
• 适当放置： 信息框紧随引入语境，并且不将主张与证据或步骤与其条件分开。
• 安全的邻居： 它不与另一个平行网格、对比组件或双栏 CTA 相邻。
• 可提取的措辞： 父标题和条目标题命名了它们的主语，正文不依赖于"左”、“右"或附近的代词。
• 响应式顺序： 窄屏布局将条目一堆叠在条目二之前，不裁剪、不水平滚动、不进行视觉重排。
• 无障碍结构： 容器有可见的程序化标签，子标题是真实标题，颜色或图标不单独承载含义。
• 内容限制： 每个正文保持在两个段落以内，不包含嵌套的复杂组件、操作流程或促销控件。
• 标记法一致： 可移植 Markdown、Hugo 和 WordPress 保留了相同的标题、两个条目、正文和顺序。
• Schema 节制： 除非页面内容独立符合条件，否则不添加列表或对比标记。

当前四项检查中有任何一项失败时，审核者应拒绝该元素。这些失败表明概念性问题，而非样式缺陷，改变宽度或装饰无法修复。

常见问题

前端元数据中的 FAQ 条目回答了反复出现的实施问题：条目数量固定为两个，深度比字数相同更重要，详细对比需要表格，移动端保持源码顺序，以及该元素不生成结构化标记。将这些答案保留在结构化前端元数据中，可以让学院模板呈现经过批准的 FAQ 处理方式，而无需在正文中重复内容。