FAQ 板块：格式、架构与示例

FAQ是一种收尾内容元素，用于回答页面主体部分尚未解决的一组有据可查的小问题。其问题使用读者的语言，每个30–60词的答案独立成篇。下方的实况板块是从本页面的[[faq]]前页元数据渲染而来，而非在Markdown正文中重复编写。

上方的可见问题及其FAQPage结构化数据共享同一来源。编辑前页条目即可同时更改两种表现形式，这可以防止精美的页面内答案与机器可读版本发生漂移。

为什么这个元素很重要

读者通常在阅读页面末尾时带着一个狭窄的不确定性，而非需要另一个完整的解释。购买者可能理解某个产品的功能，但仍然想知道注册是否要求提供信用卡。遵循操作流程的人可能知道每个步骤，但仍需要确认当某个必填输入缺失时会发生什么。FAQ为这些高频的、后期阶段的问题提供了一个可预测的位置，而无需强迫每位读者再经历另一个冗长的章节。

这个元素之所以有效，是因为问题的措辞是一种识别线索。扫描"我可以导出数据吗？“的读者，能比解读一个模糊的标题如"附加信息"更快地识别出自己的关切。答案随即立即解决该关切。这是读者心理，而非装饰：该组件缩短了具体疑问与其解答之间的距离。

FAQ还创建了有边界的问题-答案对，便于机器提取。机器可提取性意味着软件可以隔离一个单元并在完整页面之外保留其含义。一个真实问题后跟一个自包含的答案，比将答案隐藏在一个杂乱的收尾段落中更容易被搜索系统、内部搜索、支持工具和AI智能体识别。仅当语言保持明确时，边界才有帮助；“是的，如上所述"在视觉上位于FAQ内部，但被提取后就变得毫无用处。

前页元数据是发布源，因为相同的记录必须服务于三种用途：可见板块、FAQPage结构化数据和语料库级分析。语料库级分析意味着将所有页面作为集合进行查询——例如，查找每个关于取消的答案，或检查哪些页面类型通常超过六个问题。将条目保存在类型化的[[faq]]记录中使得这些检查成为可能。将问题复制到正文中则创建了两个可编辑版本，从而引发漂移。

何时使用它

当研究表明存在几个与页面相关但过于狭窄而不值得另立完整章节的重复性问题时，使用FAQ。好的候选问题涉及边缘情况、资格条件、兼容性、时机、读者经常混淆的定义、购买异议或安全的下一步行动。每个问题必须帮助同一受众完成页面的主要决策或任务。

问题研究应先于写作。从搜索建议、站内搜索、客服工单、销售通话记录、社区讨论和追踪的AI提示中收集确切的用语。提示追踪 很有用，因为它记录了企业在各AI引擎中选择监控的问题；重复出现的提示可以揭示潜在客户如何询问某个品类、功能或进行比较。该记录是措辞和需求的证据，而非将无关提示强行塞入页面的许可。

不要仅仅因为模板提供FAQ就使用它。诸如"为什么我们的平台很棒？“这类编造的问题，不过是披着问号外衣的营销文案。“FAQ架构的好处？“这类关键词片段听起来不像读者会问的话。两者都会削弱信任，并且对机器了解真实的信息需求帮助甚微。

FAQ不是用来堆放未能纳入大纲的段落的垃圾场。如果一个答案引入了核心论点、解释了必要步骤、承载了页面最强的证据，或者需要超过60个词，那么它正在承担实际工作，很可能值得一个命名的章节。应将其移至主体结构中。然后FAQ可以回答剩下的那个更小的问题。

不要以问题形式重复文章内容。“什么是X？"、“为什么X很重要？“和"X如何工作？“当这些已经是页面前三个章节时，不是好的收尾问题。重复会使页面变长而不增加覆盖面，并且有可能对同一问题产生略有不同的答案。

常见的接近失误是提出了一个相关问题但其答案属于核心内容。在症状类页面上，“这种情况什么时候严重？“可能看起来像一个自然的FAQ，但警示信号涉及安全，应出现在每个读者都能看到的主体部分。FAQ既不能重复警示列表，也不能给出一个较弱的摘要。相反，应使用一个狭窄的未解决问题，例如某个特定情况是否会改变推荐的下一步行动。

放置位置

FAQ是一个收尾元素，其任务是在页面传达了主要答案后解决剩余问题。将其放在实质性主体、示例和支持证据之后。当FAQ依赖于某些来源时，将这些来源紧邻放在其前面；将主要行动号召和相关内容链接放在其后面。这种顺序让读者在决定下一步做什么之前，先解决最终的不确定性。

不要将实际使用的FAQ直接放在首屏区域、引言内部、步骤之间，或声明及其证据之间。本规范顶部的实况板块是元素库要求的展示，而非正常页面的规定位置。

每个页面使用一个FAQ板块。它不能与第二个手风琴式组件、包含相同材料的"常见问题"章节，或改写为问题形式的总结并列。避免将其放在一个大型术语表列表旁边：两套密集的短条目会争夺相同的扫读行为。如果两者都必要，将定义保留在相关的正文章节中，并将收尾板块保留给未解决的问题。

结构解析

标注截图将语义区域与视觉处理区分开来。图例保留在此页面中，以便在图片调整大小或替换时其标签仍然可读。

1. 板块标题： 将集合命名为常见问题；它是文档层级中的一个真实标题。
2. 问题： 使用读者的话语作为完整的疑问句，并以问号结尾。
3. 展开控件： 在可折叠变体中，可操作按钮指示其答案是否已展开，并标识受控的答案区域。
4. 答案： 首先给出直接回应，然后提供一个有用的限定、区分或下一步行动。
5. 条目边界： 在视觉上和编程上将每个问题与恰好一个答案关联起来。
6. 前页记录： 将question和answer配对的非视觉来源；同时提供展示和FAQPage输出。

设计示例

变体改变的是呈现方式，而非内容归属。每个版本都读取相同的[[faq]]记录，并保留相同的问题-答案对。

标准响应式变体

桌面端在同一列中对齐显示问题和答案；较小屏幕使用展开控件以节省垂直空间。当设计系统提供响应式行为时，此为默认设置。

折叠移动端变体

问题作为按钮保持可见，答案在原地展开。控件必须传达展开状态、保留键盘访问权限，并保持答案在阅读顺序中相邻。

长问题压力变体

自然的问题可能会折行为两行。布局必须保留问号、控件目标和答案对齐，而不进行截断。

无FAQ状态

当没有经研究得出的问题时，不渲染任何内容。不要显示空标题、占位行或通用生成内容。

参数

参数即内容契约。设置限制是为了保持每个配对的可提取性，并防止收尾元素变成第二篇文章。

证据引用无需公开显示，但必须经得起编辑审查。一个客服工单编号、通话记录链接、查询导出或追踪的提示记录即可。“作者想出来的"不符合要求。

语法和代码示例

所有三种形式都将FAQ条目视为结构化页面元数据。渲染指令中不包含重复的问题或答案。

可移植Markdown指令

:::faq{source="frontmatter" heading="常见问题"}
:::

可移植文档模型将记录存储为页面元数据：

[[faq]]
question = "我可以将报告导出为CSV吗？"
answer = "可以。导出会创建一个包含报告当前数据集的CSV文件。在分享之前请检查导出范围，因为屏幕筛选器和账户权限可能影响包含哪些记录。"

Hugo短代码

{{< faq-side-by-side title="常见问题" >}}{{< /faq-side-by-side >}}

Hugo短代码读取.Page.Params.faq；它不接收JSON正文。添加内联内容会创建第二个来源，此元素禁止这种做法。

WordPress区块或短代码

<!-- wp:amicited/faq {"source":"post-meta","heading":"常见问题"} /-->

[amicited_faq source="post-meta" heading="常见问题"]

在WordPress中，每个问题和答案属于可重复的帖子元数据，同时供区块渲染器和JSON-LD发射器使用。将相同的配对粘贴到区块HTML或短代码正文内容中，即使页面看起来正确，也会破坏一致性。

示例

好示例

我可以在导出报告后更改报告周期吗？
可以。先更改报告中的报告周期，然后创建新的导出，使文件反映修改后的范围。现有的CSV是静态快照，不会在仪表盘筛选器稍后更改时自动更新。

这个示例有效，因为问题听起来像是用户在遇到导出工作流程后会问的问题。第一句回答"可以"并说明操作。第二句解释了后果边界：之前的文件不会自我更新。30个词的长度使答案完整，而不会变成隐藏教程。

差示例

报告导出CSV下载？
如上所述，我们强大的平台使导出变得容易。请参阅报告章节以获取有关所有可用优秀选项的更多信息。

问题是一个关键词片段而非口语化表达。答案既没有说明导出是否可行，又依赖于缺失的上下文，添加了未经支持的主张，并将读者引向别处。仅重新措辞是不够的；作者必须验证真实问题并提供实际行为。

第二个差模式是一个180词的答案，包含前提条件、五个步骤和一条警告。即使每句话都准确，这些内容也应归属于操作流程章节。FAQ应回答更狭窄的剩余问题，否则应删除。

架构标记与无障碍性

架构标记 是标准化的机器可读代码，用于标识页面内容的意义和关系。FAQ条目映射到Schema.org的FAQPage。每个可见问题成为mainEntity中的Question；其答案成为acceptedAnswer，类型为Answer并带有text值。站点以JSON-LD （一种用于链接结构化数据的JSON格式）形式输出此结构。

标记必须与可见内容在含义和措辞上完全匹配。不要添加仅存在于架构中的问题、仅在标记中缩短可见答案，或在编辑页面后将旧答案留在JSON-LD中。仅使用前页元数据的规则通过从同一记录派生两种输出来防止这些错误。结构化数据描述内容；它不能弥补薄弱、编造或隐藏的内容，也不能保证获得丰富的搜索结果。

无障碍性取决于展开行为。展开是一种显示或隐藏关联内容的控件。问题在切换答案时应使用原生button，并配合aria-expanded反映当前状态，aria-controls指向答案的唯一ID。ARIA（可访问的富互联网应用）在原生HTML本身无法表达时提供状态和关系。

键盘用户必须能够访问每个问题，通过回车或空格键展开它，并以逻辑顺序继续浏览页面。焦点必须保持可见。答案应在文档顺序中紧随其问题之后，标题不得跳级。不要仅依赖箭头旋转、颜色或动画作为展开状态的信号。如果答案在桌面端始终可见，它们仍必须通过dt和dd或等效的语义关系与其问题保持关联。

写作规则

典型的FAQ使用四到六个问题。四是实际下限，因为更少的问题很少能单独构成一个收尾界面；一到三个答案通常可以放在相关的正文章节旁边。六是实际上限，因为更长的集合难以扫读，且通常表明主要主题被从文章中扣留了。例外情况需要证据支持：受监管的产品可能需要更多狭窄的资格问题，而简洁的产品页面则可能完全省略该板块。

每一条目都要以读者的话语写成真实的问题。保留来源中有用的词汇，但移除个人数据、账户特定细节和会话噪音。仅当真正的重复问题的答案也相同时才合并。“我可以按月取消吗？“和"我会收到退款吗？“可能出现在同一次销售通话中，但它们代表不同的决策，不得合并。

每个答案写30–60个词。第一句回答问题；第二句用最有用的条件、区分、理由或下一步行动进行阐述。指明主题，使答案在提取后仍能独立存在。切勿将"是的，可以”、“见上文”、“如前所述"或"联系我们了解更多"作为完整答案。

使用冷静、事实性的语气。在答案中定义必要的技术术语，但不要堆砌术语。仅当目标页面能够实现下一步行动或提供必要细节时才包含链接；可见答案在不点击链接的情况下仍须完整。不要包含推荐语、营销口号、不相关的关键词、嵌套表格、多步骤流程或缺乏支持的声明。

每种文章类型都声明了其FAQ必须涵盖的意图类别。意图类别是问题背后的决策类型，而非关键词主题。症状类页面可能声明原因、自我处理、严重性和购买类别，其中至少一个问题覆盖警示信号。因为警示信号涉及安全，主体部分仍必须呈现它们；FAQ类别检查确保收尾问题不会只讨论轻松的商业主题。

应推广该方法而非将这四个类别随处复制。对比类页面可能需要切换成本、兼容性、合同和最佳匹配类别。操作指南可能需要前提条件、故障恢复、完成验证和维护。只有当声明的类别反映页面的搜索意图 和真实证据时，覆盖才算成功，而不是每个页面都重复一套通用的问答题。

使用该元素的文章类型

postTypes前页元数据记录了已注册的关联关系。下表将每个关联关系转化为覆盖和放置规则；它并不使FAQ在研究未发现有用剩余问题的情况下成为强制要求。

“通常需要"意味着该文章类型通常会引发剩余问题，而非编辑应人为制造它们。证据门槛仍然适用。

QA检查清单

审阅者在判断视觉样式之前先检查来源记录。

• 单一来源： 每个可见配对来自[[faq]]前页元数据；没有问题或答案在Markdown正文中重复。
• 真实需求： 每个问题在搜索建议、站内搜索、支持、销售、研究或追踪的AI提示中有可追溯的来源。
• 自然措辞： 每个问题都是读者语言中的语法正确的问题，而非关键词片段或产品主张。
• 直接回答： 第一句解决问题；第二句添加最有用的限定或行动。
• 独立含义： 没有答案依赖于"上文”、“之前”、“此"或另一个缺失的指代对象。
• 长度： 每个答案包含30–60个词；每个问题不超过120个字符，除非自然措辞确实需要更多。
• 数量： 该板块通常包含四到六个条目，任何例外都有记录在案的理由。
• 无移位的章节： 没有答案包含应属于主体部分的核心论点、必要流程、主要警告或证据集合。
• 无重复： 问题不重复已经完整回答的标题，答案也不再次总结文章。
• 声明的覆盖： 该集合涵盖了文章类型所需的意图类别，包括在主题需要时包含风险或警告类别。
• 正确放置： 实际使用的板块位于实质性内容和来源之后，并在主要CTA和相关内容之前。
• 可见-架构一致性： FAQPage.mainEntity包含与渲染板块相同的问题和答案，没有隐藏或过时的条目。
• 无障碍控件： 切换按钮暴露展开状态，答案ID唯一，键盘操作正常，焦点可见，文档顺序保持逻辑性。
• 空状态： 没有合格问题的页面不渲染任何FAQ标题或占位内容。
• 截图状态： 捕获注释在指定资源存在之前保持为注释；不存在任何不存在的路径被渲染为图片。

FAQ

顶部的实况示例和FAQPage数据是由本页面前页元数据中五个经审核的[[faq]]记录生成的。它们涵盖了必要性、来源、答案长度、独立措辞和可见-架构一致性，而无需在此处维护第二份副本。