内容写作 编辑复核
FAQ 问题簇与答案草稿
从真实咨询和页面内容中整理高频问题、回答边界和内部链接，减少重复客服劳动。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名知识库编辑。请从真实问题和已批准资料中整理 FAQ，不要为追求数量编造用户没有问过的问题或未确认的答案。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 按用户意图聚类问题
2. 每个问题的简洁答案、前置条件和限制
3. 来源、更新时间和需要人工处理的情况
4. 相关页面或下一步链接
5. 缺口问题和后续采集建议
输入变量：
- 真实问题（{{questions}}）：提供客服记录或搜索词的脱敏样本。
- 已批准事实（{{approved_facts}}）：提供可以公开引用的产品资料。
- 读者（{{audience}}）：说明 FAQ 面向谁和什么阶段。
- 站内链接（{{links}}）：提供可链接的页面和用途。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先按真实频率和业务影响排序，FAQ 数量不是质量指标。
- 答案涉及价格、权限和承诺时注明更新时间。
WHEN IT FITS
适用判断
适合这些情况
- 有真实的用户问题记录，知道大家实际在问什么。
- 客服重复回答同类问题，需要沉淀成文档。
- 要判断哪些问题该做成独立页面、哪些合并。
换个做法更好
- 你没有真实问题记录：编出来的 FAQ 没人搜也没人看。
- 问题数量很少：直接写在产品页里。
- 你想批量生成 FAQ 冲页面数：这属于低质量规模化内容，有被降权的风险。
FAILURE MODES
常见翻车与修正
- 模型生成了一批用户从没问过的问题。
要求所有问题来自你提供的真实记录，模型补充的建议问题单独列出并标注为待验证。
- 答案很短，只有一句话，页面内容单薄。
要求每个答案除了直接回答，还要说明适用条件和相关操作路径，撑不起来的问题合并到其他页面。
- 相似问题各建一页，互相竞争同一批搜索词。
要求先做问题聚类，同一意图的合并成一个页面，其余作为该页面内的子问题。
ACCEPTANCE
怎么判断输出合格
- 问题来自真实记录，模型补充的单独标注。
- 每个答案有足够的信息量，不是一句话敷衍。
- 相似问题做了合并，没有互相竞争的页面。
- 答案内容和产品实际行为一致。
SAFETY BOUNDARY
使用边界
- 答案涉及退款、时效和资质承诺时，措辞要由业务和法务确认，帮助中心的表述会被当作正式承诺。
- 模型会为了覆盖面而编造用户不会问的问题，问题清单要用真实工单验证。