FAQ 失败是因为它照团队心智模型写，而不是照用户原话写。搜索、工单、应用内提问、社区帖里才是真问题；团队凭空写的不是。下面 15 个 Prompt 覆盖从真实数据挖问题、懂导流的答案（链到该去的地方、但不挡掉真正需要人工的场景）、答案骨架模式、可扩展不变垃圾抽屉的帮助中心结构。
先把这组数字摆在眼前。2026 年各企业 CX 团队里，一线（tier-1）自助导流率中位数约 41%（公开 CX 基准里，前 25% 接近 59%，后 25% 接近 22%）。但 Gartner 那条常被引用的结论是：AI 能导走 45%+ 的提问，却只有约 14% 的问题是被自助”真正解决”的。用真实问题搭出来的帮助中心会把你推向高位段，靠拍脑袋写的只会停在低位段。这套 Prompt 要补的就是这个差距。
TL;DR
- 问题 backlog 来自工单 + 搜索日志（Prompt 1-2），绝不来自团队脑暴。
- 每个答案先放 1 句 quick answer；正文按类型搭骨架（步骤型 / 解释型 / 分支型，Prompt 4-7）。
- 保留可见的”还需要帮助”入口。硬导流会烧信任，并以 CSAT 下滑的形式暴露出来。
- 把 Prompt 跑在长上下文模型上（GPT-5.5、Claude Sonnet 4.6 或 Gemini 3.1 Pro——截至 2026 年 6 月均为 1M token），这样能一次粘进上百条原始工单。
- 注意：Google 已于 2026 年 5 月 7 日在搜索中下线 FAQ 富结果（rich results）。FAQPage schema 仍然有效、对 AI / 答案引擎仍有用，但别再指望 FAQ 能在 SERP 里出富摘要了。
适合哪些场景
写或重构 help center 的产品 / CX 团队、每周回答同样 12 个问题的创始人、想降工单量的 support lead、做应用内 help 文案的内容设计师。
什么时候不建议这样写 Prompt
法律披露、合规页等需要律师签字的不要用——FAQ 是用户面文案，不是政策。每周工单少于 50 也别用：这个量级下你应该逐条人工读、手写答案，因为规律还在快速变动，套模板反而失真。
该跑在哪个模型上
这里每条 Prompt 都要粘一份语料（工单、搜索日志、文章清单）。截至 2026 年 6 月，实用默认就是任意 1M token 模型：Claude Sonnet 4.6（1M 上下文，API $3/$15 每百万 token）、GPT-5.5（ChatGPT 默认，做聚类类 Prompt 时把选择器切到 Thinking），或 Gemini 3.1 Pro（1M 上下文，API $2/$12）。在 ChatGPT 应用内，Plus（$20/月）大约能容纳 320 页上下文；完整的 1M 应用内窗口只有 Pro（$200/月）才有。一次性的 backlog 聚类用聊天应用就够了；要做每晚读取新工单的常态流水线，就用更便宜的模型走 API。完整的”聚类到起草”工作流见 用 AI 从真实工单构建帮助中心 FAQ。
Prompt 结构公式
FAQ Prompt 一定带这六个要素：
- 角色：让 AI 扮演谁（资深 PM / 独立创始人 / 产品设计师 / 独立开发者 / 增长负责人）。
- 上下文：阶段（想法 / MVP / 增长 / 规模化）、团队规模、流量或 ARR、平台（web / iOS / Android）、受众、限制。
- 目标：一个具体交付物——一段 PRD、一组用户故事、一个实验设计、一篇上线公告。
- 限制：时间线（本 sprint / 本季度）、要砍的范围、不能动的东西（现有流程、计费、合规）。
- 输出格式：表格、清单、可贴 ticket 的 JSON、或带标签的段落，能直接粘到 Linear / Notion / Jira。
- 示例 / 信号：1-2 份你欣赏的参考或竞品、加 1 个想避开的反例。
这套 Prompt 适合用在哪
- 新帮助中心上线
- 功能改动后的 FAQ 刷新
- 高频 topic 的 Top 10 导流问题
- 应用内 help-tip 文案
- 搜索词驱动的内容 backlog
15 个可直接复制的 Prompt 模板
1. 从工单挖问题
写答案之前先跑。它产出 backlog。
You are a help-center content designer. Below are {N} recent support tickets. Extract the 25 most-asked underlying user questions, phrased the way users would type them into search (not how the team phrases them). For each: count, % of tickets, severity. Group into 5-7 topic clusters.
Tickets: {paste}可替换变量： N、工单语料
优化建议： 输出像转述时追加：“Each question must use the user vocabulary, not internal product terms. If users say login and we say sign-in, use login.”
2. 从搜索日志挖问题
Below are {N} internal search queries from our help center. Extract the 20 highest-intent question patterns. Mark each: has a published answer (yes/no), is the answer good (yes/no/unknown). Output as a backlog table.
{paste queries}3. 懂导流的答案骨架
For each of these 5 user questions, write an answer that (a) solves the problem in 80 words or less, (b) links to one deeper resource, (c) keeps a "still need help?" contact path visible but not pushed. Avoid forcing deflection — some questions belong with humans.
Questions: {paste}4. 一问三种长度的答案
Below is a single user question. Write the answer at 3 lengths: (a) 1-sentence quick answer (search-snippet ready), (b) 80-word standard answer, (c) 200-word detailed answer with troubleshooting steps. Use the same vocabulary in all 3.
Question: {paste}5. “step-by-step” 答案模板
For procedural questions like "How do I cancel" or "How do I add a teammate", write an answer that uses: (1) 1-line summary, (2) numbered steps (max 7), (3) what to expect after each step, (4) what to do if it does not work. Format as markdown.
Question: {paste}6. “为什么会 X” 解释型
For "why" questions ("Why was I charged twice?", "Why did my data disappear?"), write an answer that: (1) acknowledges the worry in one line, (2) explains the most likely cause, (3) tells the user the next action, (4) names the rare case it could be something else. Voice: clear, never defensive.
Question: {paste}7. 状态分支答案
For this question, the answer depends on user state ({plan tier, OS, account age}). Write a branching answer: 1-line intro, then "If X, do Y" for 3-5 branches. Format so the user lands on their branch within 8 seconds.
Question: {paste}8. 帮助中心信息架构
Below is our current FAQ list of {N} articles. Reorganize into a 3-level information architecture: top-level sections (5-7), sub-categories under each, individual articles. Mark any article that belongs in multiple places — those become candidates for splitting.
{paste FAQ list}9. 交叉链接审计
Below are 10 help articles. For each, recommend 2-3 articles to cross-link based on user journey (where they go next), not topical similarity. Mark any orphan articles that nothing links to.
{paste articles}10. 应用内 help-tip
For these 6 product screens, write the in-product help tooltip + the matching help-center article title. Tooltip: less than 15 words. Article title: question-shaped ("How to {action}"). Output as a 6-row table.
Screens: {paste}11. SEO 友好 FAQ 改写
Below is a help article. Rewrite for SEO without losing voice: H1 as a question matching real search query, first paragraph answers in 40 words, headings break into scannable sections, internal links to 3 related articles. Maintain accuracy.
{paste}12. 失败模式诚实度审计
For each of these 5 FAQ answers, audit for "honesty about failure modes": does the answer acknowledge when the feature does not work, when the user might still need to contact support, when an alternative is better? Rewrite any that hide failure modes.
{paste FAQs}13. 新功能 FAQ 生成
We are launching {feature} on {date}. Anticipate the 10 most-likely user questions before launch. For each: write a draft answer. Mark questions where the answer depends on undecided product decisions — those go to PM for input.
Feature spec: {paste}14. 多语 FAQ 本地化
Adapt these English FAQs for {Japanese, Spanish, German, Simplified Chinese}. Rules: do not translate literally — adapt cultural expectations ({formality, directness, contact preferences}). For each FAQ, mark whether it needed full rewrite or just translation.
{paste FAQs}15. 帮助中心质量仪表盘
Design a help-center health dashboard with 8 metrics: total articles, articles updated last 90 days, search queries with no result, top 10 articles by traffic, top 10 articles with low deflection, articles with negative feedback, average response time after FAQ visit, ticket volume per topic before/after FAQ change. Define each metric and the threshold that triggers action.容易踩的坑
- 按团队心智模型写，而不是按真实工单和搜索写。
- 强行导流——有些问题就该到人；硬挡会烧光信任。
- 答案太长、没有 quick answer 先行。
- 类似问题用不同格式答（procedural 和 explanatory 混）。
- 到处互链——用户不导航，他们搜索。
- 功能变了不更新 FAQ——过期 FAQ 比没有 FAQ 更糟。
- 多语直译，不做文化适配。
怎么衡量有没有效
只看导流率会骗人。2026 年 CX 团队的共识是把它和两个更硬的指标配对：完整解决率（用户是真的停下来了，还是只是离开了）和单次解决成本。可对照的参考值：
| 指标 | 健康区间（2026 年 6 月） | 来源 / 说明 |
|---|---|---|
| 一线导流率 | 35-59%（中位约 41%） | 前 25% 约 59%；超过 80% 要拿准确率反查 |
| 自助”完整解决”的问题占比 | 约 14% | Gartner——导流不等于解决 |
| 用真实数据重建 FAQ 后的导流提升 | 30-60 天 +15 到 +25 个百分点 | 厂商案例多落在此区间；更高的宣称要存疑 |
| 自助会话的 CSAT | 必须持平或上升 | 导流涨了但 CSAT 掉了，那是信任损失，不是胜利 |
如果你把”答题层”外包给厂商 AI agent、而不是写静态 FAQ，那么单位经济就很关键：Intercom Fin 按每次”解决”收 $0.99（只在它真正闭环时才收费），公布的解决率约 50-65%；Zendesk 的 Advanced AI 加购是 $50/坐席/月，叠在坐席价（$19-$115/坐席/月）之上，在已配置意图上的导流率大致落在 38-45%（截至 2026 年 6 月）。当你的转人工率偏高时，按解决计费比按会话计费更划算。
优化技巧
- 问题 backlog 来自工单 + 搜索，不来自团队脑暴。
- 每个答案都先放 1 句 quick answer；AI 答案引擎和站内搜索都会抓它。
- 每页保留”还需要帮助”入口——硬导流反噬，并以 CSAT 下滑暴露出来。
- 功能改动后立即更新对应 FAQ；过期比没写更伤。
- 追踪哪些文章降工单、哪些反而增工单，重写后者。
- 用真实用户原词；用户说 “login” 不要写 “sign-in”。
- 建一小组 procedural / explanatory / branching 模板，不要每条都重写。
- 即便 Google 已于 2026 年 5 月 7 日下线 FAQ 富结果，也把 FAQPage schema 留在标记里——它仍喂给 AI Overviews 和答案引擎，且 Google 确认留着标记不会有副作用（见 Google FAQPage 结构化数据文档）。
FAQ
- help center 应该多少篇？: 质胜量。50 篇好的、能对上搜索词的文章，打败 200 篇平庸的。狠砍——每篇过期文章都是导流的负债。
- FAQ 要替代人工 support 吗？: 不。现实目标是导走重复型的一线工单中 35-59%（2026 年基准区间），其余路由到人工。记住 Gartner 的提醒：AI 能导走 45%+ 的提问，却只有约 14% 的问题被自助”完整解决”，所以要为”优雅地转人工”而设计，而不是奔着零人工去。
- 怎么知道 FAQ 在起作用？: 看 FAQ 上线前后某 topic 的工单量，并把导流率和 CSAT、完整解决率配对。30-60 天内导流提升 15-25 个百分点、且 CSAT 不掉，就是健康结果；导流涨了但 CSAT 掉了，那是披着胜利外衣的信任损失。
- FAQ 页在 Google 里还有富结果吗？: 没有了。Google 已于 2026 年 5 月 7 日在搜索中移除 FAQ 富结果（搜索展现、报告、富结果测试的支持也在 2026 年内陆续退役）。FAQPage schema 仍然有效、仍帮 AI Overviews 和答案引擎解析内容，所以标记留着——只是别再指望 FAQ 出 SERP 摘要了。
- 该写静态 FAQ 还是买 AI support agent？: 都要。结构清晰的静态 FAQ 是任何 AI agent 读取的知识库。如果加厂商 agent，当转人工常见时，按解决计费（如 Intercom Fin 每次解决 $0.99，截至 2026 年 6 月解决率约 50-65%）通常比按会话计费便宜。
- AI 能写完整个帮助中心吗？: 能起草，但每条都要人工核对产品准确性和语气再发布。把 Prompt 跑在 1M token 模型上，让整份工单语料一次进得去。
- 多久刷一次？: 功能改动影响的立即刷新，外加每 6 个月对 Top 20 流量文章全面审计。
相关阅读
- App 引导文案 Prompt
- Release notes Prompt
- 用户画像 Prompt
- 流失分析 Prompt
- 用 AI 从真实工单构建帮助中心 FAQ：聚类、起草、质量复核
- Product / App / Startup Prompt 总目录
标签: #Prompt #产品创业 #Onboarding