决策树：分支指南规则与示例

决策树是一系列问题，每个答案选择下一个问题或最终建议。当正确的操作确实根据读者能够识别的事实而变化时使用它——而不是作为对每个人都相同的建议的装饰。

选择数据导出失败后的第一反应

1. 导出是否显示错误信息？
是 → 复制确切的错误信息，然后进入问题2。
否 → 检查任务是否仍显示为"处理中"。如果是，等待所述的处理时间窗口；如果不是，重新启动导出一次。

2. 错误信息是否提示权限被拒绝？
是 → 请管理员授予导出权限。停止。
否 → 缩小日期范围并重试一次。如果仍然失败，将错误信息和导出ID发送给支持团队。停止。

渲染后的元素展示了基本的约定：每个选择都是可区分的，每条路径都向前推进，每条路径都以一个后续操作或升级告终。

为什么这个元素很重要

“看情况"虽然诚实但不完整。遇到这个短语的读者必须自行发现答案取决于什么，判断哪些条件适用，并从散文中重建建议。决策树将这些依赖关系明确化。它将模糊的条件判断转化为有边界的序列：观察一个事实，选择一个分支，然后执行终点的操作。

这减轻了工作记忆的负担。读者只需评估当前的选择，而不必在脑海中记住所有例外情况。它也让不确定性变得可见。如果一个人无法回答某个节点，树可以引导他们进行检查、测量或咨询专家，而不是让他们猜测。这对于故障排除、资格判定、购买选择和政策解读尤为重要，因为一个有信心但错误的分支可能浪费时间或带来风险。

机器可提取性意味着爬虫、搜索系统、AI 问答系统或内容转换工具可以恢复每个问题、其允许的答案以及下一个节点或终点。连续的"如果这样，也许那样，除非……“的散文将这些关系隐藏在语法中。类型化的树将它们暴露为具有稳定标识符和明确目标的记录。机器可以保留路径 start → has-error → permission-denied → request-access，而无需推断哪个段落修改了哪个条件。

在应用该模式之前，请先遵循元素写作规则 。目的优先于外观：当每个人都按顺序执行相同操作时，序列仍然是步骤列表；当读者需要并排检查选项时，比较仍然是比较。仅当先前的答案改变了接下来应发生的事情时，才使用决策树。

何时使用

当满足以下所有条件时，使用决策树：

1. 至少一个有意义的建议取决于读者或其情况提供的答案。
2. 每个决策可以用可观察、互斥的选择来表达。
3. 遵循一个分支会消除不相关的选择，而不仅仅是隐藏有用的上下文。
4. 每条路径终止于一个操作、结论、指定的备选方案或升级路径。
5. 作者能够解释为什么每个条件会改变建议。

强有力的用途包括：诊断已知症状、选择产品类别、检查政策适用性、选择实施路径，以及决定何时需要将常规流程升级。

近似情况应保留在更简单的形式中：

• 一个建议有多个理由： 使用普通的说明性散文。没有答案会改变结果。
• 固定流程： 使用有序步骤。每一步内的分支使主要路径更难看清。
• 读者需要按共享标准比较的选项： 使用比较表格。树可以在比较后推荐一个选项，但它不能替代证据。
• 性格测试： 偏好可能重叠，评分可能是累积的。这是评估模型，而非排他性树。
• 受众细分列表： 当读者只需选择其角色并接收平行内容时，使用角色切换器。
• 复杂计算： 当多个数字输入组合时使用计算器。将范围转换为数十个分支会失去精度。
• 伪装的销售漏斗： 如果每条路径都推荐相同的产品，树就制造了一种诊断的假象。直接陈述建议及其限制。

放置位置

在读者理解决策、其范围以及回答第一个节点所需的任何事实之后，立即放置树。在故障排除文章中，将共享安全检查和相关症状放在树之前。在购买指南中，在引导读者进入类别之前定义标准和符合条件的选项集。在政策内容中，在通过例外条件进行分支之前，陈述权威规则和管辖范围。

确切的位置规则：

• 用 H2 和一句话介绍树，说明它解决的决策。
• 将定义、测量方法和前置条件放在第一个节点之前；绝不要让分支标签依赖于未定义的术语。
• 将支持性证据放在其证明的终点附近，或链接每个终点到同一页面上的可见证据部分。
• 在长树之后放置摘要，以便读者确认选定的终点并了解下一步操作。
• 将树放在最终行动号召之前。行动应跟随结论，而不是中断诊断。

决策树不得直接放在另一个决策树、人物标签集或隐藏选择分支所需信息的折叠面板旁边。它不得将警告与所限定的危险条件分开，不得在没有明确"返回步骤"终点的情况下中断有序流程，也不得出现在为树建议提供证据的比较之前。不要在节点内放置促销卡片；商业压力会使中立路由难以取信。

结构

结构包含八个部分：

1. 标题： 将决策命名为读者的目标，例如"选择导出恢复路径”。
2. 范围声明： 说明树覆盖哪些情况以及排除哪些情况。
3. 开始节点： 提供一个明确的入口点。
4. 问题节点： 询问一个可观察到的事实，而不是一个包含多个条件的意见。
5. 分支标签： 在同一逻辑类别中提供互斥的答案。
6. 连接器： 通过稳定的标识符将每个答案映射到一个下一个节点或终点。
7. 终端端点： 给出结论、行动、证据链接或安全的升级路径，并明确标记路径已完成。
8. 备选方案： 处理"未知”、“均不适用”、数据缺失或不安全情况，而不强迫猜测。

视觉箭头是呈现方式，而非关系本身。即使渲染器在窄屏幕上垂直布局树，源数据也必须标识每个分支的目标。

设计示例

每个设计变体都使用相同的节点-目标契约。根据推理结构和视口选择，而非视觉新颖性。

二元诊断树

每个节点有"是"和"否"分支。当一个事实确实是布尔值时使用：状态存在、测试通过或权限存在。避免否定问题，因为"否"会变得难以解读。

多选选择树

一个节点提供三个或四个不重叠的类别，例如合同期限、环境或主要约束。在标签中定义类别边界；“小型”、“中型"和"大型"在没有范围的情况下无法使用。

分阶段资格判定树

早期节点移除不合格的路径；后续节点在合格的选择中进行细化。用于政策、服务或集成适用性判断。将取消资格的安全和法律条件放在首位，因为后续偏好不能覆盖它们。

带异常出口的线性树

主路径通过正常序列继续，同时偶尔的分支退出到恢复或升级路径。当大多数读者遵循一条路径且例外情况很少时使用。如果异常路径重新加入流程，需精确标注返回点。

交互式单问题视图

仅在完整树对视口过于密集时，一次显示一个当前节点。包括进度上下文、返回、重新开始、文本结果摘要和非交互式可访问视图。完整的源树必须在不依赖客户端获取的情况下可用。

参数

父级拥有树的标识和起始点。重复节点拥有自己的提示或终点内容，而分支记录拥有答案标签和目标。

终点没有分支。一个问题至少有两条分支，每个目标解析为同一树中的一个节点。数据必须是无环的：没有分支可以返回到祖先节点。重新加入流程的恢复路径应以"返回到步骤3"终止，而不是在树内创建循环。

语法和代码示例

所有三种形式描述相同的规范记录。渲染器可以更改布局，但它们必须保留源顺序、标签、目标、终点和完整的非交互式阅读路径。

可移植 Markdown 指令

:::decision-tree{id=export-recovery variant=binary start=has-error}
## 选择导出恢复路径

::item{id=has-error kind=question branches="yes:permission-error|no:still-processing"}
### 导出是否显示错误信息？
从导出历史中显示的状态进行选择。
::

::item{id=permission-error kind=question branches="yes:request-access|no:retry-smaller"}
### 错误信息是否提示权限被拒绝？
::

::item{id=still-processing kind=endpoint}
### 检查处理时间窗口
等待所述时间窗口结束，然后重新启动导出一次。
::

::item{id=request-access kind=endpoint}
### 请求导出权限
在重试之前请管理员授予访问权限。
::

::item{id=retry-smaller kind=endpoint}
### 重试较小的导出
缩小日期范围一次；如果失败，将错误信息和导出ID发送给支持团队。
::
:::

紧凑的 branches 属性使用由 | 分隔的 label:target 对。标签不能包含任一分隔符。支持嵌套分支记录的平台可以结构性地存储相同的值，但导出时必须重现显式的标签到目标映射。

Hugo shortcode

{{< decision-tree title="选择导出恢复路径" id="export-recovery" variant="binary" start="has-error" >}}
  {{< decision-node id="has-error" kind="question" title="导出是否显示错误信息？" branches="Yes:permission-error|No:still-processing" >}}
  从导出历史中显示的状态进行选择。
  {{< /decision-node >}}
  {{< decision-node id="permission-error" kind="question" title="错误信息是否提示权限被拒绝？" branches="Yes:request-access|No:retry-smaller" >}}{{< /decision-node >}}
  {{< decision-node id="still-processing" kind="endpoint" title="检查处理时间窗口" >}}
  等待所述时间窗口结束，然后重新启动导出一次。
  {{< /decision-node >}}
  {{< decision-node id="request-access" kind="endpoint" title="请求导出权限" >}}
  在重试之前请管理员授予访问权限。
  {{< /decision-node >}}
  {{< decision-node id="retry-smaller" kind="endpoint" title="重试较小的导出" >}}
  缩小日期范围一次；如果失败，将错误信息和导出ID发送给支持团队。
  {{< /decision-node >}}
{{< /decision-tree >}}

这是 Hugo 适配器规范，而非用任意嵌套列表模仿树的指令。它只使用命名参数，并要求渲染器拒绝缺失目标、重复 ID、循环以及分支不足的问题节点。

WordPress 区块

<!-- wp:amicited/decision-tree {"title":"选择导出恢复路径","id":"export-recovery","variant":"binary","start":"has-error"} -->
  <!-- wp:amicited/decision-node {"id":"has-error","kind":"question","title":"导出是否显示错误信息？","branches":[{"label":"是","target":"permission-error"},{"label":"否","target":"still-processing"}]} -->
  <p>从导出历史中显示的状态进行选择。</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"permission-error","kind":"question","title":"错误信息是否提示权限被拒绝？","branches":[{"label":"是","target":"request-access"},{"label":"否","target":"retry-smaller"}]} /-->
  <!-- wp:amicited/decision-node {"id":"still-processing","kind":"endpoint","title":"检查处理时间窗口"} -->
  <p>等待所述时间窗口结束，然后重新启动导出一次。</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"request-access","kind":"endpoint","title":"请求导出权限"} -->
  <p>在重试之前请管理员授予访问权限。</p>
  <!-- /wp:amicited/decision-node -->
  <!-- wp:amicited/decision-node {"id":"retry-smaller","kind":"endpoint","title":"重试较小的导出"} -->
  <p>缩小日期范围一次；如果失败，将错误信息和导出ID发送给支持团队。</p>
  <!-- /wp:amicited/decision-node -->
<!-- /wp:amicited/decision-tree -->

WordPress 父区块将内部区块限制为决策节点，在发布前验证目标，并服务端渲染完整列表或等效的可访问结构。仅编辑器可见的连接线不是事实来源。

示例

良好示例

一个购买指南问：“设备是否必须在不接电源的情况下运行？” 是 引导到电池供电选项；否 问：“它会固定在一个位置吗？” 该答案引导到安装式或便携式选项。每个终点命名一个类别，解释决定性约束，并将读者引导到合格产品的可见比较。“不确定"则引导到测量预期位置和检查插座使用情况。

之所以有效，是因为问题涉及读者可以观察到的事实，分支不重叠，每个答案移除了不合适的类别。树推荐的是一个类别，而不是假装在没有价格、功能和证据比较的情况下选择特定产品。

不良示例

一个软件页面问：“您想要更好的结果吗？” 是 和 尚未 都引导到"预约演示”。下一个问题询问访问者是否重视速度、质量还是节省成本，尽管大多数买家三者都重视。每个终点重复相同的产品声明。

之所以失败，是因为这些选择既不互斥也不改变决策。问题收集的是认同而非诊断需求，分支掩盖了单一的号召性用语。应替换为直接的价值主张和证据。如果不同的实现确实适合不同的约束条件，请询问那些可衡量的约束条件，并允许一个诚实的终点，例如"此产品不适用。”

Schema 标记和无障碍

Schema.org 没有 DecisionTree 类型。除非页面独立包含一个有序流程，否则不要将该元素标记为 HowTo；当问题的答案仅仅是分支控制时，不要将问题节点标记为 FAQPage。树可能有助于生成内部内容数据——节点、选择、目标和终点建议——但默认情况下它不提供任何公开的 schema 属性。

针对无障碍性，使用标题作为树标题，使用有序或嵌套列表呈现完整的静态形式。每个问题和终点需要有可见文本；连接器不能仅依赖颜色、线条方向或空间位置。在关系中重复答案标签，例如"如果是，继续到权限检查"。屏幕阅读器应在不解读图表的情况下理解路径。

如果树是交互式的，使用原生按钮作为选择。在带标签的区域中暴露当前问题，将焦点移动到新问题或通过受限的 live 区域宣布，并提供返回和重新开始控件。不要禁用浏览器缩放、锁定焦点或在焦点上更改选择。在终点处以文本形式保留所选路径，以便读者验证结果的得出过程。

所有节点和终点应出现在服务端渲染的 HTML 中，即使非活动节点在视觉上被隐藏。如果性能使得对于非常大的专家系统来说不切实际，请发布一个完整的可访问备选方案，并将交互式应用程序视为一个单独的工具，而不是此内容元素。

写作规则

目标是尽可能短的合理路径，而非表面上的复杂。

• 将标题写为决策：“选择……"、“检查是否……“或"找到合适的……"。保持 3–12 个词。
• 每个问题询问一个事实，使用 5–18 个词。拆分由"和"或"或"连接的条件，除非它们总是有相同的可观察答案。
• 每个问题使用两到四个分支，不超过五个决策层级。深度过大会使读者迷失路径，并使移动端图表难以处理。
• 使同级分支互斥，并在预期范围内共同充分覆盖。当不确定性存在时，添加"不确定"或"以上都不是”。
• 使用同一类别的平行标签：全是是/否、全是范围、全是环境、全是所述约束。
• 精确说明数值边界。使用"少于50个地点"而非"小型企业”。避免边界值上的范围重叠。
• 为每个终点提供 2–10 个词的操作标题和最多 80 个词的解释，说明为什么如此、该做什么以及何时升级。
• 将最安全、成本最低的甄别检查放在前面。在可见状态或权限检查已确定路径之前，不要询问专业测量指标。
• 保持证据、限制和后果可见。树组织决策，但不证明建议是正确的。
• 将每条路径作为句子大声朗读：“因为答案是 X，继续到 Y。“如果该句子不合逻辑，则分支是错误的。

绝不要在节点内放置机密个人数据、不合格的医疗或法律诊断、隐藏价格、安全警告、多字段表单或不可逆操作。绝不要创建死胡同、未标记的连接器、仅说"看情况"的终点，或使读者无休止重复问题的循环。

使用此元素的文章类型

postTypes 前置元数据定义了支持的类型。此表中的存在意味着当内容真正分支时，该文章类型可以使用树；它不使该元素在每个页面上成为强制项。

QA 检查清单

• 页面包含真正的依赖关系：至少一个答案会改变下一个问题或终点。
• 标题和范围准确说明树解决和排除的决策。
• 只有一个起始节点，每个问题有两到四个分支，每个目标都存在。
• 同级选择互斥，使用平行标签，并涵盖现实的不确定性。
• 每条路径在五个层级内终止于一个操作、结论、备选方案或升级路径。
• 没有终点是孤立的，没有节点指向自身或祖先，没有读者可以无限循环。
• 每个终点解释为什么如此，并保持证据或限制可用。
• 树不替代固定流程、并排比较、计算、警告或直接建议。
• 所有文本和关系都出现在服务端渲染的 HTML 中，且无需连接线即可理解。
• 键盘用户可以选择、返回、重新开始，并通过可见焦点到达结果。
• 焦点和状态变化会被宣布，而不会锁定焦点或重复中断屏幕阅读器。
• 窄屏幕渲染保留源顺序，标记每个连接器，且不需要水平滚动。
• 静态备选方案和交互式结果为相同的答案产生相同的终点。
• 审阅者已走过每条路径，测试了边界值，并对任何导向相同结果的分支提出质疑。

常见问题

以下问题涵盖的那些实现选择往往只有在树已被起草后才会出现。核心测试仍然很简单：分支必须代表改变结果的事实，每条路径必须安全结束。