通知：双栏——规则与示例

双栏通知将一个共同主题下的两条简短标签通知并列展示。通知可以对比操作、解释两种条件或区分相关状态，但每条通知在独立阅读时仍必须准确且有用。

这个渲染后的元素之所以有效，是因为"草稿页面"和"已发布页面"是真实的条件，而非装饰性标题。共享标题定义了决策，每条通知提供完整的指导，且不要求读者从颜色或水平位置推断含义。

为什么这个元素很重要

读者在浏览时经常需要找到适用于自己条件的指导。一个冗长的段落说"草稿可能包含标注的示例，而已发布页面需要已验证的值"会让读者在记忆一个分句的同时测试另一个分句。两个有边界的通知减少了这种认知负担。标签首先展示分支，读者可以识别相关条件，然后阅读其指导。

其心理益处在于选择性注意。人们并不总是同等需要两条信息；他们需要确信自己注意到了正确的那一条。共享标题确立问题，而不同的标签使可用状态可见。并排呈现也使有意义的对比显而易见，而不会过度强调为输赢关系。

当作者强行制造虚假对称时，这种益处便消失了。虚假对称是指布局暗示两个想法具有相同的范围、重要性或有效性，而内容本身并非如此。一句简短提醒放在六步安全流程旁边不是配对。一项强制性法律限制放在一个可选的生产力提示旁边也不是。等宽列可能使不相等的消息看起来可互换——这恰恰是错误的信号。

机器可提取性是指软件在保留内容关系的同时隔离内容的能力。类型化的双栏通知暴露一个父主题和两个带标签的子通知。搜索引擎和AI系统可以提取"对于已发布页面，使用带有来源和验证日期的已验证值"，而无需猜测哪个标题控制哪个句子。明确的标签、源顺序和自包含的正文能够适应响应式堆叠和纯文本提取。

在选用此组件之前，请遵循元素编写规则 。目的优先于外观。严重风险仍然使用警告框 ，逐行为的行为纠正仍使用正确做法与错误做法块 ，而两条事实不会仅仅因为设计可以将它们放入列中就变成通知。

何时使用

当一个共同主题恰好包含两条简短通知，且同时看到两者有助于读者分类、对比或避免混淆时，使用此元素。合适的关系包括：

• 两种条件： 已登录与未登录、草稿与已发布、迁移前与迁移后。
• 两类受众： 账户所有者与被邀请用户，前提是两者都收到关于同一事件的指导。
• 推荐与不推荐的行为： 仅当每侧是一条简短通知而非匹配行为列表时。
• 可用与不可用状态： 当标签说明了产生每种状态的条件时。
• 当前与即将到来的行为： 当日期或版本边界明确时。

以下所有条件必须满足：

1. 一个标题可以准确介绍两条通知。
2. 恰好存在两个条件或消息；来源并未隐藏第三种情况。
3. 每条通知都有具体的标签和完整的后果或操作。
4. 在窄屏幕上的源顺序中可以理解这对通知。
5. 每条通知不需要嵌套的步骤、表格、表单或长篇限定说明。

近似用例揭示了误用情况。当第二条陈述只是第一条的延续时，请使用普通散文。当读者必须评估多个标准时，使用对比表格。当超过两个条件分支，或一个答案引出另一个问题时，使用决策树。当错过消息可能造成伤害、数据丢失、法律风险或不可逆操作时，使用独立警告。当多个错误行为各自需要对应的纠正时，使用正确做法与错误做法块。

不要无中生有地制造对立面。如果诚实的指导是"在迁移前备份数据库"，添加"迁移后：继续工作"创造了对称但没有价值。同样，不要将一条通知拆分为"重要"和"也重要"。标签必须命名真实的条件、状态、受众或立场。

放置位置

将元素紧接在定义共同情境的段落之后。读者在遇到分支之前，必须知道通知限定的是哪个决策或状态。当配对放在操作之前时，将其放在更改数据或使读者做出选择的第一个步骤之前。

精确位置规则如下：

• 将双条件配对放在前置条件之后、条件特定的指导之前。
• 将操作前对比放在它所限定的控件、命令、下载或步骤之前。
• 将结果状态配对放在结果已定义之后、故障排除详情之前。
• 当证据或来源仅支持某条通知时，将其放在该通知内；共享证据放在完整配对之后。
• 在重复的文档章节中，使用相同的源顺序，使重复出现的状态不会交换位置。

该元素不得与另一个双栏组件、对比表格、标签页控件、定价网格或拆分行动号召并列。相邻的网格使边界模糊，可能暗示四向选择。它不能将声明与其引用分开、步骤与其所需警告分开，或表单控件与其标签分开。不要将其放在编号步骤内：嵌套分支可能使顺序和责任不明确。

切勿将严重警告放在一栏中，而将常规建议放在另一栏中。相等的几何布局降低了警告的权重，暗示读者可以在两者之间选择。将风险提升为相关操作前的独立警告，然后仅当两个安全条件仍需澄清时再使用此元素。

结构

1. 共享标题： 命名两条通知所共同管理的一个情境或决策。
2. 通知容器： 将配对作为一个编辑元素分组，但不暗示它是一个单一的警示。
3. 通知标签： 用2–6个词命名条件、状态、受众或行为。
4. 通知正文： 在需要时按顺序陈述相关事实、后果和下一步操作。
5. 可选图标： 增强可见的文本标签；绝不能仅靠图标来区分。
6. 可选来源注释： 在其所限定的通知内支持变化、受监管或外部定义的声明。
7. 源顺序： 决定屏幕阅读器、复制和移动端顺序；视觉样式不得反转此顺序。

作者提供共享标题、两个标签、两个正文、语气和任何来源。渲染器提供响应式网格、间距、视觉强调、语义容器和装饰性图标处理。

设计示例

以下是所有支持的变体。变体更改标签和强调，而非双通知数据模型。

对比操作

当有一侧推荐操作和一侧不推荐操作，且每侧只有一条消息时使用。说明操作及其原因；不要将此变体扩展为匹配列表。

条件状态

当正确的指导取决于互斥的条件（如"现有账户"和"新账户"）时使用。在每个标签中命名条件，并将最常见或优先条件放在前面。

配对澄清

当两条相关事实防止不同的误解但并非对立时使用。对两者采用中性样式，使设计不会制造认可、严重性或偏好。

紧凑状态配对

用于状态已解释后的简短状态后果。每个正文一句话。不要移除标签或将正文缩减为未经解释的值。

移动端堆叠配对

所有变体在窄宽度时都会堆叠显示。保持第一条通知紧接在第二条之前，并保留共享标题。不要创建滑动交互或标签页，因为隐藏一条通知会违背该元素的用途。

参数

“来源"指明了适配器从哪里获取每个值。正文映射特意存储两条完整的通知记录，而非两个视觉定位的列。

父正文的第一个标题映射到 title。每个嵌套项将其第一个标题映射到 label，之后的所有内容映射到 content；通知属性包含 tone 和 icon。渲染器必须拒绝一条、三条或空的通知项，而不是静默填充或丢弃一列。

语法与代码示例

所有格式保留相同的标题、通知顺序、标签、正文、语气和来源。“第一列"和"第二列"是呈现术语，不是字段名称。

便携式 Markdown 指令

:::notification-two-column{variant=conditional}
## 根据发布状态选择指导

::notice{tone=neutral icon="draft"}
### 草稿页面

仅当示例值明确标注为示例时才可使用。发布前请移除或替换所有示例。
::

::notice{tone=caution icon="publish"}
### 已发布页面

使用带有来源和验证日期的已验证值。如果验证不完整，请暂不发布该声明。
::
:::

此元素将通用嵌套项名称覆盖为 notice，因为记录具有通知特定的语气行为。第一个父标题提供共享标题；每条通知的第一个标题提供其标签。

Hugo 短代码

当前没有生产环境的短代码实现这个精确的配对通知契约。在适配器存在之前，使用语义HTML，如渲染示例。预期的Hugo符号记录如下：

{{< notification-two-column variant="conditional" >}}
## 根据发布状态选择指导

{{< notification tone="neutral" icon="draft" >}}
### 草稿页面
仅使用标注的示例值，并在发布前移除它们。
{{< /notification >}}

{{< notification tone="caution" icon="publish" >}}
### 已发布页面
使用带有来源和验证日期的已验证值。
{{< /notification >}}
{{< /notification-two-column >}}

斜杠注释形式防止此规范示例调用一个不存在的短代码。未来的适配器必须验证恰好两个子通知，并按源顺序渲染。

WordPress 块

<!-- wp:amicited/notification-two-column {"variant":"conditional"} -->
<h2>根据发布状态选择指导</h2>
<!-- wp:amicited/notification {"tone":"neutral","icon":"draft"} -->
<h3>草稿页面</h3>
<p>仅使用标注的示例值，并在发布前移除它们。</p>
<!-- /wp:amicited/notification -->
<!-- wp:amicited/notification {"tone":"caution","icon":"publish"} -->
<h3>已发布页面</h3>
<p>使用带有来源和验证日期的已验证值。</p>
<!-- /wp:amicited/notification -->
<!-- /wp:amicited/notification-two-column -->

WordPress 编辑器应呈现两个固定的通知插槽，允许重新排序，并在标签或正文为空时阻止发布。它不能因为网格块支持更多列就让作者添加第三条通知。

示例

好：两个真实条件与完整操作

导入前
下载当前记录并记录导出时间。副本为您提供一个恢复点，以防字段映射产生意外结果。

导入后
将导入的记录数与源记录数进行比较，然后检查至少一条包含所有映射字段的记录。数量检查可检测遗漏；完整记录可检测偏移值。

这对通知有一个主题——安全导入验证——和一个真实的时间边界。每条通知命名一个操作并解释它能防止什么失败。第二条由于包含两个相关检查而更长，但双方承担相当的责任，且在堆叠时仍然可理解。

差：将风险降级的虚假对称

实用提示
重命名导出的文件以便日后查找。

重要
使用"全部替换"导入会永久删除现有记录且无法撤销。在继续之前，请备份数据库、确认目标、获得批准并安排停机时间。

第一条通知是可选的日常维护；第二条描述了不可逆的数据丢失和多个前置条件。将它们放在等宽列中暗示了同等权重，使关键消息看起来像是两个备选方案之一。将数据丢失通知移至控件前的独立警告中，并将文件命名建议保留为普通支持性散文。

结构化数据标记与无障碍

双栏通知没有专门的 Schema.org 类型。其内容仍保留在外层 Article、TechArticle 或 WebPage 中。不要仅仅因为存在两条有界记录就输出 ItemList、HowToStep、Question 或 Answer。如果通知中包含独立符合结构化数据条件的内容，由外层文章类型的 schema 规则决定映射方式；此元素本身不添加任何结构化数据。

当配对属于主要解释时，使用一个带标签的 section；当两条通知都是补充性内容时，使用带标签的 aside。每个子项可以是带有正确文档级别的真实标题的 aside 或 section。不要使用 ARIA alert 或 alertdialog：这些角色用于宣告动态的时间敏感变化，不适用于静态编辑指导。

无障碍名称通过原生标题结构或 aria-labelledby 来自可见的共享标题。每个通知标签必须是文本。颜色、边框样式、位置和图标可以增强语气，但不能定义语气。如果图标是装饰性的，请对辅助技术隐藏；如果它传达了标签中没有的信息，请重写标签而不是依赖替代文本来修复设计。

DOM 顺序控制含义。屏幕阅读器和移动端布局必须先遇到第一条通知，然后是第二条。不要通过 CSS 反转视觉顺序。在200%文本缩放和窄宽度下，通知必须堆叠显示而不剪切或产生水平页面滚动。链接需要描述性标签，多个链接不能压缩为一排无标签的图标。

编写规则

在编写通知之前先写关系：“读者需要两条消息，因为正确的指导因____而异。“如果空白处无法填入具体的条件、状态、受众、时间或行为对比，请使用散文。

• 在一个共享标题下恰好使用两条通知。
• 标题保持在3–12个词，每个标签2–6个词。
• 每条正文目标25–80词；120词是绝对上限。
• 每条通知使用一个或两个短段落，不超过一个短内联链接。
• 在同时存在时，先陈述事实或条件，其次是其后果，最后是操作。
• 使用平行标签语法：“启动前 / 启动后”，而非"启动前 / 管理员之后应做什么”。
• 直接命名条件。绝不使用"左侧”、“右侧”、“另一个选项"或"上方框”。
• 语气与证据匹配。中性配对事实不应继承绿色和红色处理。
• 变化中的声明应附带日期、版本、计划、管辖范围或来源（视情况而定）。

可比分量意味着两条消息值得读者给予同样的关注时刻。它不要求相同句子或字符数。不要为了匹配较长的内容而填充简短的真相。如果一条正文超过另一条的两倍左右，请检查较大的通知是否需要单独的章节，或者较小的通知是否是一个假的对位。

绝不要在通知内放置多步流程、表格、表单、定价卡片、推荐语、促销行动号召、长引用、代码示例、视频或嵌套组件。不要使用配对来软化法律、医疗、财务、隐私、安全或破坏性操作的指导。不要暗示两个条件是穷尽的，除非内容所有者已确认不存在第三种状态。

使用此元素的文章类型

postTypes 前置元数据数组是该表格的来源。收录意味着该元素可用于真实的双通知场景，而非该类型的每个页面都必须使用。

QA 检查清单

• 共同主题： 一个准确的标题管辖两条通知，不超出范围。
• 恰好两条通知： 来源包含两条完整记录，无隐含的第三种状态。
• 真实的关系： 标签命名了有意义的对比、条件、受众、状态或时间边界。
• 独立含义： 每条通知在提取时与共享标题一起保持清晰。
• 无虚假对称： 两条消息都值得相当的强调；既无填充内容，也无被降级的关键警告。
• 正确放置： 配对紧随其上下文，并置于它所限定的操作或详情之前。
• 安全的邻接： 不与另一个拆分布局、表格、标签页控件或双栏CTA相邻。
• 有用的标签： 标签使用平行语法，且绝不依赖左右位置或颜色。
• 长度控制： 正文保持在一到两个段落内，每条不超过120词。
• 内容约束： 内部无嵌套流程、表格、表单、媒体、推广或复杂组件。
• 响应式顺序： 移动端、键盘、屏幕阅读器和复制文本顺序与作者顺序一致。
• 无障碍语义： 可见标题标注父元素；子标签为标题；静态内容不使用警示角色。
• 语气完整性： 样式反映实际含义，不将中性事实变成好/坏判断。
• 表示一致性： Markdown、Hugo和WordPress保留相同的标题、标签、正文、属性和顺序。
• 结构化数据约束： 元素不创建不受支持的结构化数据。

如果共同主题、真实关系或虚假对称检查失败，则拒绝使用该元素。这些是渲染器无法修复的编辑缺陷。在调整呈现之前，将内容重写为散文、独立章节、独立警告或其他用途匹配的元素。

常见问题

前置元数据中的结构化FAQ涵盖了最容易被误解的实现决策：通知不需要相反或等长，移动端顺序遵循源顺序，严重风险保持独立警告，以及该元素本身不创建结构化数据标记。