FAQ（Frequently Asked Questions）页面看似简单，实际是信息架构中最容易被低估的一环。它处在「用户已产生疑问、但不愿或不便联系人工」的决策岔路口，做得好能显著降低客服压力、提升转化率；做得差则会让用户直接离开。
问题的来源决定内容质量
很多网站的 FAQ 是「坐在办公室里想出来的」，结果回答了没人问的问题，却漏掉了真实高频疑问。可靠的问题来源有三类：
- 客服与工单记录：真实咨询的重复率极高，把近三个月的高频问题做聚合，就能得到一份高价值清单；
- 站内搜索词：用户搜了却没搜到，说明内容缺口就在那里；
- 售前与售后的分界：售前关心「能不能用、贵不贵、快不快」，售后关心「怎么用、出问题怎么办」，两者应分区呈现。
结构设计：从「列表」到「可检索」
当条目超过二十条，纯平铺的列表会让查找变得低效。建议按主题分组，并在组内保持由浅入深的顺序。
分组与排序
把问题归入三到六个语义清晰的组，每组五到十条。组标题用用户的语言，而不是内部部门的名字；组排列按业务重要性，而非历史沉淀顺序。
折叠交互的取舍
折叠面板适合条目多、且用户只关心其中少数几条的场景，能显著缩短页面长度；但如果大多数用户需要通读全部内容，折叠反而增加了点击成本。判断标准很简单：平均每位用户会看几条？答案是「一条」就用折叠，答案是「全部」就直接展开。
表述撰写：把「我们」换成「你」
- 首句即结论：先给答案，再给原因和前提，用户没有耐心读铺垫；
- 避免内部术语：内部代号、缩写、系统名对用户毫无意义，应替换为结果描述；
- 给出下一步：答案结尾附上具体操作入口或联系方式，让链路可以继续。
与搜索和结构化数据配合
FAQ 内容适合以 FAQPage 结构化数据标注，帮助搜索引擎理解内容语义；同时页面内的锚点应可被直接分享，方便客服在回复中给出精确链接。内容更新后应同步复查标注，避免标注与页面内容不一致。
持续迭代而不是一次性交付
FAQ 是活文档。建议建立固定节奏：每月从工单与搜索词中提取新增问题，每季度清理已失效条目，每次产品变更后同步检查受影响条目。把这些动作写进流程，FAQ 才会真正成为降低服务成本的基础设施。