信息框：三栏 — 格式、规则与示例

三栏信息框在一个统一主题下展示三个平行的要点。当读者需要同时看到一个真正的三部分模型时非常有用：三项职责、三个标准、三种结果，或三个协同的工作流。各栏承诺同等的编辑地位，因此每个要点必须以相似的深度完成相同类型的工作。

该渲染元素有一个共享标题和三个项目。所有三个标题都是名词短语，三个正文都描述了一种信心类型，图标增加了节奏感但不承载含义。移除图标后模型不变。

为什么这个元素很重要

读者不会仅仅因为一个密集的段落包含三个分句就将其视为一个模型。他们必须先将第一个分句记在脑中，察觉过渡到第二个，然后判断第三个是同等的、从属的，还是仅仅附加上去的。三栏信息框使这种关系变得明确。共享标题指明了不变的内容；三个有边界的项目展示了完整的分立；匹配的视觉重量告诉读者在将模型视为已理解之前，先检查每个项目。

这通过「分块」——将相关信息组织成可管理单元——来实现。三个足以揭示一个体系，而不会产生一个目录。读者可以浏览三个标题，从最相关的要点进入，然后比较详细程度。当散文体文本会三次重复同一主题，或将区分隐藏在一个长句内时，该元素尤其有效。

机器可提取性是指软件能够在不丢失主题或关系的情况下，隔离出一个内容单元。一个类型化的三栏信息框暴露了一个父主题和三个有序的子项。搜索系统、内容 API 和 AI 检索工具可以保留共享标题、每个项目标题、每个正文以及源顺序，而无需猜测一个段落是否包含列表。明确的标题也为每个项目提供了有用的检索标签。

提取只有在文字自包含的情况下才能起作用。“技术信心意味着页面可渲染且链接可解析"可以独立于布局而存在。“第三部分负责这个"则不能。结构也无法制造出第三个想法。请遵循元素编写规则 ：在选择渲染器之前先确定内容模型。正好三个项目的元素特定要求优先于任何关于可重复项目的一般性许可。

何时使用

仅当以下五个条件都满足时，才使用三栏信息框：

1. 一个共享标题可以准确地统御整个元素。
2. 主题自然地分为正好三个要点。
3. 所有三个要点回答同一个隐含问题。
4. 每个要点值得相似的深度、证据和视觉重量。
5. 每个要点可以用一两个短段落解释，无需嵌套结构。

强有力的用途包括：一个框架的三个组成部分、三个所有者职责、质量的三个维度、一个能力带来的三种结果、或在同一阶段执行的三个检查。关系可以是互补的、顺序的或分类的，但必须加以说明。如果作者无法完成"这三个之所以在一起是因为……"，那么这个分组很可能只是视觉填充。

最常见的近似错误是一个真正的配对加上一个薄弱的第三项。“人、流程以及其他"不会因为布局有三个槽位就变成一个三部分模型。“速度、准确性和价值"也是如此——当文章只定义了速度和准确性，而将价值视为它们的结果时。保留这一对，在散文中解释结果，或选择其他元素。

不要将此信息框用于三个顺序指令。栏会削弱顺序性，尤其是在窄宽度下堆叠时；当完成顺序重要时，请使用步骤列表。不要将其用于在多个标准下评估的三个产品；请使用对比表。不要将其用于一个今天刚好包含三个事实但下次更新可能增加第四个的列表。一个固定的三栏契约仅在「三」是该想法的固有属性时才适用。

其他近似错误包括：一个标题加两个真实项目、一个项目包含所有注意事项、三个没有机制或证据的促销宣称、以及将一个受众群体分成三个随意的人口统计段。在每种情况下，布局夸大了内容尚未赢得的某种关系。

放置位置

将信息框放在引入父想法的段落之后。该段落应解释为什么三向视图有所帮助；共享标题随后命名模型，各项目定义其组成部分。在元素之后跟上解读、证据或适用于整个组的过渡。

当 H2 标题提供了共享标题并且没有段落或组件插入时，它可以直接出现在 H2 下方。它也可以在一个定义之后出现，此时三个项目展开该术语的各个维度。它不得打断一个主张及其引用、一个警告及其触发条件、一个步骤及其预期结果、或者引入一个常规列表的句子。这些关系必须保持连续。

不要将其紧挨着另一个三栏网格、价格表、标签控件、卡片组或三选项「行动号召」放置。重复的几何形状会使编辑性解释看起来像是交互式或商业性的，迫使读者推断哪个分组更重要。请插入解释性散文，或选择一种结构来承载整个关系。避免在同一短章节中放置第二个信息框；重复将一个有意的模型变成了装饰性家具。

在一个长页面上，多个三栏信息框只有在不同标题下且针对真正不同的模型时才可接受。不应将其用作复制品中每个三人组的默认处理方式。

结构

该结构包含一个父区域和三个重复的项目区域。标注截图应识别语义部分，而非颜色、圆角或间距标记，以便规范在重新设计后仍然适用。

1. 外部边界： 将标题和三个项目作为一个编辑单元进行分组。
2. 共享标题： 命名被三个项目划分的想法。它不是第四个项目。
3. 可选图标槽位： 每个项目可放置一个经批准的装饰性图标；三个槽位要么全部使用，要么全部省略。
4. 项目标题： 以与其他两个标题平行的语言，命名集合中的一个成员。
5. 项目正文： 以匹配的深度解释该成员，并在提取时保持其含义完整。
6. 布局关系： 在空间允许时使用三个等宽列，在窄屏上按项目一、项目二、项目三的顺序堆叠。

作者控制标题、正文、图标令牌和源顺序。渲染器控制列宽、间距、断点、边框、背景和排版。

设计示例

存在一个语义元素，有四种支持的变体和一个响应式状态。所有变体都不改变严格的三个项目契约。

默认带标题变体： 适用于解释性内容。共享标题和三个项目标题使层级关系清晰；无图标。

图标变体： 为每个项目添加一个装饰性图标。图标必须在系列、大小和视觉重量上保持一致。不支持图标、照片和空白槽位的混合使用。

上下文标题变体： 紧邻的前一个 H2 提供共享标题。仅当容器能够以编程方式引用该可见标题，且标题与元素之间无任何分隔时，才允许使用此变体。

紧凑变体： 适用于三个简短定义或检查。每个正文仍然是一个完整的句子，而非标语或标签片段。

窄视口状态： 项目按编写顺序垂直堆叠。任何文字不得依赖于左、中、右的位置。

参数

契约将作者表达的含义与呈现方式分开。响应式列和图标样式属于渲染器；内容字段和语义顺序属于源代码。

标题是必需的，除非紧邻的前一个标题提供了相同的父主题并为容器做标签。项目正文可以包含强调、内联代码和一个相关的文本链接。不得包含嵌套标题、表格、超过三个短要点的列表、媒体、表单、「行动号召」或其他组件。

语法与代码示例

所有三种表示法都保留相同的标题、三个有序项目、可选图标令牌和正文。便携式 Markdown 指令是规范来源。Hugo 和 WordPress 是适配器契约，必须拒绝任何不是三个的项目数量。

便携式 Markdown 指令

:::infobox-3-columns
## 一个可发布的页面需要三种信心

::item{icon="reader"}
### 读者信心

答案清晰、完整且足够具体，能够指导决策或行动。
::

::item{icon="editorial"}
### 编辑信心

主张有依据，术语一致，所有必要的限定条件都保留完整。
::

::item{icon="technical"}
### 技术信心

页面可渲染，链接可解析，元数据映射正确，机器能够恢复其结构。
::
:::

第一个父级标题映射到 title。每个 ::item 将其第一个标题映射到 item.title，剩余正文映射到 item.content，可选的 icon 属性映射到经批准的图标令牌。即使布局是堆叠的，也需要三个嵌套项目。

Hugo 短代码映射

{{< infobox-3-columns title="A publishable page needs three kinds of confidence" variant="icons" >}}
  {{< infobox-item title="Reader confidence" icon="reader" >}}
  The answer is clear, complete, and specific enough to guide a decision or action.
  {{< /infobox-item >}}
  {{< infobox-item title="Editorial confidence" icon="editorial" >}}
  Claims are supported, terminology is consistent, and every required qualification remains attached.
  {{< /infobox-item >}}
  {{< infobox-item title="Technical confidence" icon="technical" >}}
  The page renders, links resolve, metadata maps correctly, and machines can recover its structure.
  {{< /infobox-item >}}
{{< /infobox-3-columns >}}

这是一个便携式适配器规范，并非承诺当前站点注册了这些短代码。它只使用命名参数，保留源顺序，验证图标令牌，并在遇到额外项目时失败于创作验证，而不是静默丢弃或包裹。

WordPress 区块

<!-- wp:amicited/infobox-3-columns {"title":"A publishable page needs three kinds of confidence","variant":"icons"} -->
  <!-- wp:amicited/infobox-item {"title":"Reader confidence","icon":"reader"} -->
  <p>The answer is clear, complete, and specific enough to guide a decision or action.</p>
  <!-- /wp:amicited/infobox-item -->
  <!-- wp:amicited/infobox-item {"title":"Editorial confidence","icon":"editorial"} -->
  <p>Claims are supported, terminology is consistent, and every required qualification remains attached.</p>
  <!-- /wp:amicited/infobox-item -->
  <!-- wp:amicited/infobox-item {"title":"Technical confidence","icon":"technical"} -->
  <p>The page renders, links resolve, metadata maps correctly, and machines can recover its structure.</p>
  <!-- /wp:amicited/infobox-item -->
<!-- /wp:amicited/infobox-3-columns -->

编辑器应暴露三个固定的项目槽位。它可以允许作者重新排序项目，但不得提供允许添加第四个子项或不相关区块的非限制性插入器。

示例

好示例：一个真正的三向运营模型

这个示例之所以有效，是因为共享标题定义了一个责任模型，三个角色是明确的，每个正文回答了同一个问题：该负责人必须验证什么？项目使用了平行的名词标题和可比的深度。没有一个项目只是为了填满一行而存在。

坏示例：一个配对被填充成三个

改进着陆页的三种方法

明确主张： 用读者可验证的语言命名受众、问题、机制和预期结果。

证明主张： 添加相关证据，解释其局限，并将引用保持在其支持的主张之后。

让它更吸睛： 添加有吸引力的颜色以及其他感觉有吸引力的东西。

前两项是可观察输出的编辑要求。第三项是模糊的视觉建议，没有匹配的证据标准，并且做了不同的工作。它之所以被添加，是因为设计需要三栏，而不是因为模型有三个部分。移除此第三项并使用两部分结构，或者定义一个真正的第三项需求（例如减少交互摩擦）并以相同的深度予以支持。

架构标记与无障碍

三栏信息框没有专门的 Schema.org 类型，也不会创建独立的结构化数据。其文本仍然是所在 Article、TechArticle 或 WebPage 的一部分（当该页面符合条件时）。不要仅仅因为有三项就将子项标记为 ItemList，也不要从听起来像是顺序的标签中推断出 HowTo。只有当底层内容独立满足该模式的要求时，才提供页面级别的模式标记。

使用一个带标签的语义容器，其中包含三个子区块。当模型是主要论证的一部分时使用 <section>，当它是补充性的时使用 <aside>。使用 aria-labelledby 连接可见的共享标题，并为每个子项提供文档层级正确的真实标题。粗体文本不能替代标题。

源顺序就是阅读顺序。屏幕阅读器、键盘导航、复制文本和移动端布局必须依次遇到项目一、项目二、项目三。CSS 可以创建列，但不得使用排序规则重新排列它们。切勿使用"左”、“中"或"右"这些词；当项目堆叠时这些位置会消失。

图标是装饰性的，除非它们传达了标题中没有的信息。装饰性图标在 HTML 中使用 aria-hidden="true"，或在渲染为图像时使用空替代文本。如果图标具有信息性，其含义也必须在可见文本中出现；隐藏于视线之外的辅助功能名称对能看到页面但无法解读符号的读者没有帮助。颜色和图标形状绝不能是项目之间的唯一区分方式。

在窄宽度下，在文本变得过于拥挤之前堆叠项目。支持文本缩放，不裁剪、不重叠、不产生页面级水平滚动。三栏截图不能替代响应式语义内容。

编写规则

以这句话开头：“这个想法有三个部分：X、Y 和 Z。“在定义每个部分后，该句子必须仍然准确。如果其中一个部分是另外两个的结果、一个包罗万象的类别或一个次要示例，那么这个模型就不是真正的平行结构。

使用正好三个项目。将每个标题控制在 2–7 个词之间，并使用相同的语法模式：三个名词短语、三个疑问句或三个时间标签。尽可能将每个正文控制在 25–80 个词之间，绝不超过 110 个词。相差一句话是可以接受的。一个 25 词的项目旁边有两个 100 词的项目，这需要编辑或改用不同的结构。

匹配的深度意味着可比的解释性工作，而不是填充。每个正文应该回答相同的隐含问题，包含相似程度的细节，并在相似程度上说明后果。如果一个项目确实需要更多解释，请将模型移入普通的章节，在那里长度的差异可以诚实地呈现。

使用直接、中立的语言。标题应识别含义，而非位置：“发现/生产/评审"比"第一/第二/第三"更有力。顺序标签仅在每个项目总结一个阶段而非指导读者完成步骤时才可接受。避免使用最高级、无支持的效益宣称以及伪装成解释的三个口号。

图标是可选的。要么全部三个都使用，要么都不使用，从一个经批准的系列中选择，并保持视觉上的一致性。不要在标题之前选择图标、不要使用表情符号作为生产图标令牌、也不要让图标替代有意义的项目标题。

元素内部绝不允许出现以下内容：

• 两个或四个项目、一个空项目或一个"其他"类的第三个槽位。
• 详细的过程、对比矩阵、价格方案、表单、推荐轮播或促销横幅。
• 嵌套的 H2 章节、另一个信息框、标签、手风琴面板、视频或图片库。
• 长列表、来源列表、法律免责声明、安全警告或与其管辖的主张分离的限定条件。
• 三个不相关的链接被样式化为同等「行动号召」。

当内容超出这些限制时，将三个项目提升为普通页面章节。固定的布局绝不应成为压缩必要细节或隐藏限定条件的理由。

使用它的文章类型

postTypes 前置元数据字段是已注册的使用集。它标识了通常包含有意义的三部分模型的格式；当来源中没有真正的三人组时，它并不要求使用信息框。

QA 检查清单

• 一个父想法： 精确的共享标题解释为什么所有三个项目属于一起。
• 正好三个项目： 源代码和渲染输出包含三个完整的子项——从未是两个、四个或一个空的占位项。
• 真正的三向拆分： 移除任何一项都会使模型不完整；没有一个是填充物、结果或杂项类别。
• 平行标题： 所有项目标题使用相同的语法形式，识别含义而非屏幕位置。
• 匹配的深度： 每个正文以相似的细节和证据回答相同的隐含问题。
• 有用的放置： 元素紧跟其引入上下文，不分离主张、警告、步骤或引用与其依赖的内容。
• 安全的邻居： 不与另一个三栏网格、定价块、标签控件或三选项 CTA 相邻。
• 可提取的措辞： 共享标题和项目标题命名其主题；正文不依赖附近代词或视觉位置。
• 图标一致性： 三个项目全部使用来自同一系列的经批准图标，或全都不使用图标；含义保留在文本中。
• 响应式顺序： 移动端按项目一、项目二、项目三的顺序堆叠，不裁剪、不水平滚动、不使用 CSS 重新排序。
• 可访问语义： 容器具有可见的程序性标签，项目标题是标题，装饰性图标对辅助技术隐藏。
• 内容限制： 正文保持在两个短段落以内，不包含嵌套的复杂组件、过程或促销控制。
• 表示法一致性： 便携式 Markdown、Hugo 和 WordPress 保留相同的标题、三个项目、图标令牌、正文和顺序。
• 模式标记约束： 渲染器不会从三栏呈现方式中推断出列表、对比或如何做标记。

当项目数量、真正的三向逻辑或匹配深度失败时，审核者应拒绝该元素。这些是内容模型缺陷；视觉修饰无法修复它们。

常见问题

前置元数据中的 FAQ 条目涵盖了固定的项目数量、匹配的深度、可选的图标、移动端顺序和模式标记约束。学院模板可以渲染这些已批准的答案，而无需在正文中重复它们。