项目符号列表：写作规则、结构与示例

项目符号列表是一组相关且独立的无序要点。它让读者一次识别类别，然后逐项扫描，无需从段落中提取。仅当各项目属于同一逻辑层级且顺序不改变含义时，才使用项目符号。

• 以相同的语法形式开始每个项目。
• 使每个项目保持在相同的长度区间内。
• 在第一个项目符号之前介绍该集合。
• 在最后一个项目符号之后回归推理。

以上渲染示例是一个真正的列表：四条对等规则，均以祈使句表达，不依赖位置关系。上方的段落确立了类别；下方的句子说明了该集合证明的内容。项目符号改善了对话论的访问，而不取代它。

为什么这个元素很重要

读者不会将段落当作句子的集合来扫描。他们寻找主张，遵循观点之间的关系，并判断解释是否值得关注。项目符号列表改变了这种阅读行为。它的垂直节奏传达出"这些要点是并列的；你可以逐一检查它们"。这降低了寻找相关要求、选项、症状或特性所需的努力。

同样的边界也提高了机器可提取性——搜索引擎、AI 系统或内容转换器在保留共享上下文的同时隔离项目的能力。语义化的无序列表显式地暴露了集合及其成员。平行的开头词语也有助于机器推断这些项目执行相同角色。“需要管理员权限”、“需要已验证域名"和"需要有效订阅"比三个在问题、片段和评论之间交替的项目形成了更清晰的集合。

项目符号并不自动比散文更清晰。段落通过句子和过渡词表达原因、对比、限定、顺序和结论。将其转换为项目符号可能会抹去这些关系。这时列表看起来更容易阅读，但传达的信息却更少。这是该元素的核心风险：视觉可扫描性可能掩盖丢失的推理。

元素写作规则 具有优先权。在选择表现形式之前，先确定段落的功能。结论的总结应归入关键要点 ，即使该元素也渲染成项目符号。有序指令应归入步骤列表 。仅当目的是在周围论证中呈现一组无序的并列项目时，项目符号列表才是正确的元素。

何时使用

当一个引导句可以准确地统领三个或更多项目，且每个项目独立阅读时仍然有用，就使用项目符号列表。典型的用途包括：要求、特性、同一类别的示例、非顺序性选项、故障症状、入选标准以及优先级相同的简洁推荐。

在将散文转换为列表之前，执行三项测试：

1. 对等测试： 每个项目是否能回答同一个隐含问题？
2. 顺序测试： 相邻的两个项目能否互换位置而不改变指令或结论？
3. 上下文测试： 引导句是否为每个项目提供了足够的上下文，而无需每个项目重复说明？

如果三项测试均通过，项目符号可能有所帮助。如果顺序测试失败，使用编号指令或按时间顺序的散文。如果对等测试失败，将内容拆分为单独的段落或标题。如果上下文测试失败，每个要点都需要自己的解释。

边界情况尤其需要注意：

• 一组操作在某个操作解锁下一个操作时，不是项目符号列表，而是有序流程。
• 一组主张在第二个主张限定第一个、第三个得出结论时，不是列表，而是论证。
• 一组产品在读者需要逐项标准评估时，不一定是列表；请使用对比表格 。
• 一组完成关卡在读者必须逐一验证时，不仅仅是信息性的，而是核对清单。
• 两种备选方案很少需要项目符号。除非每种方案都需要大量解释，否则写"当……时使用 X；当……时使用 Y”。

不要在用项目符号挽救一个过长的段落之前，先诊断它为什么长。该段落可能包含多个主张、缺少标题或存在未发展的因果链。先修复其结构。项目符号不是万能的整理工具。

放置位置

将项目符号列表紧接在一个完整的引导句之后，该句子应说明集合名称并解释读者为何需要它。“迁移需要：“语法正确但力度不足，因为它没有说明后果。“请收集迁移所需的这四个输入项，以便回滚可以恢复原始状态：“则告诉读者这些项目是什么以及它们为什么重要。

当项目支持某个决定或主张时，在列表之后立即放置解释。结束段落应指出该集合所体现的模式、优先级、例外或后续行动。当目的纯粹是列举时，列表可以结束一个小的参考章节，但绝不能使论证悬而未决。

精确的位置规则：

• 将引导句和列表放在同一章节中；切勿让读者跨过标题去发现项目符号列举的内容。
• 将证据放在其所支持的主张旁边。不要将列表插入在主张与其引用、计算或限定之间。
• 不要将无序列表直接放在有序列表旁边，除非有过渡词解释含义的变化。
• 不要将两个项目符号列表背靠背堆叠。加入解释，合并真正的并列项，或为每个集合添加描述性小标题。
• 不要将泛化的项目符号列表直接放在关键要点框下方（当两者总结相同材料时）。
• 不要将行动号召放在最后一个项目符号内。关闭集合，解释结论，然后单独呈现行动。

该元素可以在长页面上出现多次，但散文必须承载这些列表之间的关系。当每个章节都变成标题加项目符号时，页面就出现了孤立列表故障：集合存在，但没有任何内容解释它们之间的联系。

结构

一个完整的项目符号列表包含五个语义区域：

1. 上下文： 使该集合相关的前文主张或解释。
2. 引导句： 说明共享类别的完整句子。
3. 列表容器： 一个确立项目关系的语义化无序列表。
4. 项目： 具有平行语法和一致详细程度的并列陈述。
5. 解释： 将集合重新连接到论证的后置句子或段落。

标记符号、缩进和间距使层级可见，但它们并不定义层级。当样式、脚本和视觉标记缺失时，源代码结构必须保持为无序列表。

设计示例

设计系统支持三种变体。其内容约定保持不变；仅密度和布局发生变化。

默认

对完整陈述和大多数编辑内容，使用默认的单列变体。它为每个项目提供了足够的间距以便扫描，同时保持集合在视觉上连接。

紧凑

对标签、简短要求或 3–12 词的值使用紧凑间距。紧凑并非允许将推理压缩成片段；周围的散文仍需提供上下文。

双列

仅当有六到十个简短、独立且在渲染器的阅读顺序中仍然可理解的项目时，才使用双列。在窄宽度下，布局必须折叠为单列。不要将其用于已解释的要点、手动跨列排序或暗示排名的项目。

任何变体不得用装饰性图标和无关容器替换原生列表语义。视觉定制必须保持每个陈述对应一个集合和一个项目。

参数

以下限制防止列表在应成为章节之前不断扩展。“来源"标识规范值的编写位置。

渲染器不会从引导句中推断标题。标题命名一个可重用或文章类型定义的块；引导句完成周围散文与项目之间的句子级关系。大多数内联列表不需要标题。

语法和代码示例

所有三种映射保持相同的引导句、项目、变体和解释。可移植指令是规范形式。Hugo 和 WordPress 示例描述平台适配器；它们不授权页面特定的样式。

可移植 Markdown 指令

:::bullet-list{variant=default}
发布前检查以下条件：

- 主张指明其范围和时间段。
- 来源支持所使用的准确措辞。
- 页面解释任何实质性限制。

这些检查共同确保一个可辩护的主张不会变成夸大其词。
:::

Hugo 简码

{{< bullet-list variant="default" >}}
发布前检查以下条件：

- 主张指明其范围和时间段。
- 来源支持所使用的准确措辞。
- 页面解释任何实质性限制。

这些检查共同确保一个可辩护的主张不会变成夸大其词。
{{< /bullet-list >}}

在项目注册该适配器之前，将内容渲染为普通的语义化 Markdown，而不是发明本地简码。源代码仍然满足编辑约定。

WordPress

<!-- wp:amicited/bullet-list {"variant":"default"} -->
<p>发布前检查以下条件：</p>
<ul>
  <li>主张指明其范围和时间段。</li>
  <li>来源支持所使用的准确措辞。</li>
  <li>页面解释任何实质性限制。</li>
</ul>
<p>这些检查共同确保一个可辩护的主张不会变成夸大其词。</p>
<!-- /wp:amicited/bullet-list -->

如果不存在自定义块，原生 WordPress 列表和段落块是正确且可访问的回退方案。仅当主题支持时，才保留包装器的变体。

示例

优秀：平行发布检查

在批准比较之前，验证每个选项都得到相同的对待：

• 对每个选项应用相同的评估标准。
• 使用来自同等时期的证据。
• 在受影响的主张旁边说明实质性限制。
• 将测量的事实与编辑判断分开。

这些项目之所以有效，是因为它们回答了一个问题——什么使比较公平——并且每个都以祈使动词开头，后跟一个宾语。它们的长度相似，顺序可互换，结束句解释了共同的标准。

糟糕：拆分为项目符号的论证

• 读者会扫描页面。
• 因为扫描很常见，所以列表很有用。
• 但列表去除了过渡词。
• 因此，谨慎使用列表并测试无障碍性，这对屏幕阅读器也很重要，并且有几个实现细节。

这样做很糟糕，因为这些项目不是并列的。它们构成了前提、推论、限定和结论，因此改变它们的位置会改变论证。它们的语法和长度也在变化。将段落重新写成项目符号去除了连接性的推理，同时保留了揭示隐藏段落的过渡词。应将其写成散文：读者会扫描页面，因此列表可以帮助他们定位并列要点；然而，列表会去除过渡词，这意味着作者必须在集合前后保留推理。

结构化数据标记和无障碍性

普通的项目符号列表不需要独立的结构化数据标记。它仍然是包含它的 Article、TechArticle、产品描述或其他页面级类型中的可见内容。不要仅仅因为 HTML 包含 <ul> 就创建 ItemList 标记；结构化数据应表示有意义的实体集合，而不是每个视觉枚举。

当列表本身是一个主要的、有限的集合时——例如声明的包含地点集或排名产品——并且每个可见项目映射到一个真实的 ListItem，ItemList 可能是合适的。对于无序集合，不要通过 position 发明排名或暗示偏好。Schema 输出必须匹配可见的数量和名称。大多数编辑性项目符号不直接提供任何 schema 属性。

无障碍性始于 <ul> 和每个项目一个 <li>。不要将项目符号字符输入段落中，不要插入换行符来模仿项目，也不要用一系列 <div> 元素仅因为 CSS 可以绘制标记。屏幕阅读器会宣布原生列表边界和项目计数，这给了用户与可视读者相同的类别信号。

保持嵌套仅一层，且仅当每个子项属于其父项时。嵌套列表至少需要两个项目；单个缩进的项目通常只是另一个句子。当自定义图标是装饰性的时，确保它们没有竞争性的可访问名称。链接必须描述其目标位置，含义不得依赖于标记的颜色、形状或列位置。双列输出必须保留可预测的源代码和键盘阅读顺序。

写作规则

为列表选择三种项目长度区间之一，并贯穿整个列表使用：

• 扫描标签：3–12 词。 用于工具、要求、症状或紧凑的类别成员。
• 完整陈述：8–25 词。 用于规则、好处、标准和独立存在的推荐。
• 已解释的要点：20–45 词。 当每个项目需要一个理由或限定时使用；将更长的解释移入散文或子章节。

通常使用三到七个项目。两个项目适合一个句子或对比。八到十个项目需要明确的理由、有意的分组，通常还需要紧凑或双列变体。超过十个项目迫使读者自行建立分类；拆分集合或引入小标题。

平行结构是强制性的。以相同的词性开始每个项目，并保持相同的主语。好的集合使用祈使动词（“确认”、“记录”、“测试”）、名词（“权限”、“证据”、“所有权”）或完整的陈述句。不要以一个动词开始一个项目，以"你应该"开始第二个，以一个问题开始第三个。

匹配语气、时态、标点、大小写和详细程度。使用句子大小写。完整句子以句号结束；简短片段省略句号。将区分性词语放在前面，而不是重复一个长而相同的开头。加粗可以标识后接解释的短标签，但每个项目必须使用相同的标签模式。

切勿将以下内容放入普通项目符号列表中：

• 顺序影响结果的必需有序操作。
• 每个项目的多个段落、多个标题或独立的微型文章。
• 表格、表单、视频播放器、用户评价或推广卡片。
• 依靠项目外上下文才能保持准确性的未经限定的主张。
• 要求、示例、结论和行动号召的混合。

避免孤立列表故障。它发生在几乎所有段落都被转换为项目符号时，没有留下散文来建立原因、冲突、证据或结论。一个实用的审查信号是连续三个章节各自包含一个简短引导句和一个列表，但没有解释性段落。将最强的主张恢复为散文，合并重叠的集合，只保留通过对等、顺序和上下文测试的列表。

使用该元素的文章类型

以下行由 postTypes 前端变量驱动。“使用"描述项目符号的角色，并非要求将其强制放入每个页面。

QA 核对清单

发布前，验证每个项目：

• 引导句说明一个类别并解释该集合为何重要。
• 每个项目回答相同的隐含问题，并处于相同的逻辑层级。
• 重新排列项目不会改变指令、时间顺序或论证。
• 所有项目使用平行的语法、语气、时态、大小写和标点。
• 每个项目保持在所选的一个长度区间内，且列表包含 3–7 项，或存在合理的例外。
• 列表输出使用语义化 <ul> 和 <li>，而非装饰性项目符号字符。
• 嵌套项目止于一层，同时列保留可预测的阅读顺序。
• 链接具有描述性、已验证，且每个项目仅限于一个主要目标位置。
• 当集合支持论证时，列表后的段落说明了解释。
• 列表不与类型化摘要、核对清单、步骤列表、表格或其他特定用途元素重复。
• 页面包含足够的散文来承载集合之间的推理，避免孤立列表故障。
• 可移植 Markdown、Hugo 和 WordPress 映射保留相同的项目和含义。

常见问题

项目符号列表应包含多少项？ 通常使用三到七项。对更长的集合进行分组或拆分，而不是让读者自行分类。

每个项目符号应多长？ 为整个列表选择一个区间：3–12、8–25 或 20–45 词。一致性比达到最大值更重要。

项目符号项是否应以标点结尾？ 完整句子使用句号，简短片段省略结尾标点。保持一致的应用。

项目符号列表中可以包含链接吗？ 可以，但需使用描述性锚文本，通常每个项目不超过一个主要链接。

何时应将项目符号改为编号步骤？ 当顺序影响结果时使用数字。无序项目符号承诺顺序无关紧要。

项目符号列表在展现真实集合并让散文继续执行推理工作时最为有效。目标不是最大化每一行的可扫描性，而是使并列要点易于查找，同时不破坏使它们具有意义的关系。