跳转到内容
搜索文档

常见问题解答

最后更新 查看 MarkdownAgent 设置

目的

常见问题解答(FAQ)的目的是针对常见问题提供简明的回答。

语气

指导性、直截了当、具有教育意义、权威性

内容类型 (content_type)

pcx_content_type: faq
products:
  - product-a
  - product-b
  - product-c

欲了解更多详情,请参考 pcx_content_type

概览

常见问题解答(FAQ)页面是 SEO 和数字营销的重点领域,也是改善用户导航的一种简单方式。

一个有效的 FAQ 页面应当:

  • 反映受众的需求
  • 涵盖广泛的内容
  • 经常更新
  • 解决问题
  • 提升页面浏览量
  • 展示专业知识、信任和权威性

常见问题解答页面中应该包含什么?

FAQ 应当包含针对特定主题的问题和答案列表,并且只有在您的页面确实包含一系列问题及对应答案时才使用。

确保每个问题都包含完整的问题文本。

确保答案中包含完整的回答,并且针对问题给出直接的回应(如果问题是以“是/否”形式提问的话)。

Frontmatter (前置内容)

---
pcx_content_type: faq
title: FAQ
description: Answers to common questions about <Cloudflare product>, including <key topic areas>.
---

结构

小型 FAQ 页面(5-10 个问题)

较小的 FAQ 页面不需要划分为不同的章节。

标题:FAQ

上下文:关于该章节以及用户可以从中期待什么的引导段落。

问题、答案

中型 FAQ 页面(10-15 个问题)

中型的 FAQ 页面需要划分为不同的章节,以方便内容的可读性和可发现性。

标题:FAQ

上下文:关于该章节以及用户可以从中期待什么的引导段落。

包含章节标题列表的导航菜单

章节标题

问题、答案

大型 FAQ 页面(超过 15 个问题)

大型 FAQ 页面(针对像 Teams/Cloudflare One 这样的产品套件)需要划分为不同的章节,并且每个章节都有自己的子页面,以方便内容的可读性和可发现性。

主 FAQ 页面

标题:FAQ

上下文(页面):关于该章节以及用户可以从中期待什么的引导段落。

章节标题

上下文(章节):一句话描述用户在该子章节中会看到什么

按钮:指向包含实际问题子页面的按钮

子 FAQ 页面

返回主 FAQ 页面的面包屑导航

标题:对应主 FAQ 页面的章节标头

问题、答案


问题类型

  • 是/否型(Yes/No)
    • 我可以做某事吗?
    • 产品可以做某事吗?
  • 程序型(Procedural)
    • 我该如何做某事?
    • 某事是如何运作的?
    • 某事是如何测量/计算的?
  • 定义型(Definitions)
    • 什么是...?
  • 场景型(Scenarios)
    • 如果...该怎么办?
  • 排障型(Troubleshooting)
    • 我看到了 <ERROR>
    • <PRODUCT> 发生故障,显示错误,

指南

常规

从客户的角度(POV)编写问题,因此请使用第一人称。

✅ 我在创建策略时可以使用通配符吗?

❌ 用户在创建策略时可以使用通配符吗?

是/否型

通过这种类型的问题,用户希望了解产品能力。产品是否能让他们做某事?产品能做某事吗?

  • 问题
    • 是/否型问题应以如下结构开头:
      • Can I...(我能...吗)
      • (Can/Does) the product...(产品能/是否...)
  • 回答
    • 以 Yes/No(是/否)开始回答。
      • ✅ Yes. Cloudflare Access supports several providers simultaneously.(是。Cloudflare Access 同时支持多个提供商。)
      • ❌ Cloudflare Access supports several providers simultaneously.
    • 之后始终紧跟简短的背景说明。向用户提供他们所需的所有信息。

程序型

这种类型的问题解决了关于如何使用产品实现目标或产品如何运作的疑问。通常,它们应通过主文档中的教程或操作指南来解决,但在 FAQ 中指出一些常问的程序型问题并链接回文档的其他区域也是值得的。

  • 问题
    • 程序型问题应以如下结构开头:
      • How do I...(我该如何...)
      • How does the product...(产品如何...)
      • How does ... work?(...如何运作?)
  • 回答
    • 给出简明但完整的答案
    • 链接到相关文档(教程、操作指南,甚至是博客文章)以获取更深入的信息

定义型

通过这种类型的问题,用户想知道某些元素是什么。虽然这类问题应该由词汇表解决,但在 FAQ 中指出一些基本定义也是有帮助的(例如产品中基本、循环出现的功能定义),并链接到文档的相关部分。

  • 问题
    • 定义型问题应以如下结构开头:
      • What is/are...(什么是...)
  • 回答
    • 类似于词典——简短、扼要、信息丰富的定义会有所帮助
    • 如果需要,链接到词汇表或其他相关文档

场景型

通过这种类型的问题,用户将了解如何将产品与他们已经发生或认为将会发生的特定实际场景联系起来。他们想知道产品在这些情况下是否也能为他们提供帮助。虽然教程应该解决这类问题,但在 FAQ 中也指出最基本的场景相关问题是值得的,以帮助用户决定该产品是否非常适合他们的需求。

  • 问题
    • 场景型问题应以如下结构开头:
      • What if...(如果...会怎样)
  • 回答
    • 第一句话给出相关的回答。产品在该场景下能起作用吗?
    • 在接下来的两三句话中添加简短背景。如果产品能起作用,是如何起作用的?
    • 链接到相关文档

排障型

这是一种特殊的问题类型,用户注意到产品出现了意外情况,并首先陈述其内容;问题可以隐含:“出了什么问题,我该如何解决?”

  • 错误
    • 我看到了...
    • <Product> 在...时无法按预期工作
  • 回答
    • 提供用户看到这些现象的原因
    • 提供简短、精简、可操作的步骤来解决错误
    • 链接到教程或操作指南以获取更多信息。

其他信息

如果 FAQ 包含超过 5-10 个问题,请重新审视用户工作流,并确定 FAQ 中的任何内容是否应该保存在文档集的其他地方。

如果您的产品庞大或合并了其他几个产品(如 Cloudflare One),请使用章节划分。尽量限制每个示例中的问题数量,如果 FAQ 的数量变得庞大难控,请重新审视用户工作流。

这篇文档对您有帮助吗?