帮助中心 FAQ Prompt：产品支持模板

帮助中心 FAQ Prompt——挖出用户真问的问题、搭懂导流的答案、把帮助中心结构成能降低工单又不伤信任的形态。

发布于: 2026/05/19 作者: AI Productivity Guide Team 🌐 查看英文版本

FAQ 失败是因为它照团队心智模型写，而不是照用户原话写。搜索、工单、应用内提问、社区帖里才是真问题；团队凭空写的不是。下面 15 个 Prompt 覆盖从真实数据挖问题、懂导流的答案（链到该去的地方、但不挡掉真正需要人工的场景）、答案骨架模式、可扩展不变垃圾抽屉的帮助中心结构。

适合哪些场景

写或重构 help center 的产品 / CX 团队、每周回答同样 12 个问题的创始人、想降工单量的 support lead、做应用内 help 文案的内容设计师。

什么时候不建议这样写 Prompt

法律披露、合规页等需要律师签字的不要用——FAQ 是用户面文案，不是政策。每周工单少于 50 也别用——逐条人工读。

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 更糟。
多语直译，不做文化适配。

优化技巧

问题 backlog 来自工单 + 搜索，不来自团队脑暴。
每个答案都先放 1 句 quick answer 用于搜索 snippet。
每页保留”还需要帮助”入口——硬导流反噬。
功能改动后立即更新对应 FAQ；过期比没写更伤。
追踪哪些文章降工单、哪些反而增工单，重写后者。
用真实用户原词；用户说 “login” 不要写 “sign-in”。
建一小组 procedural / explanatory / branching 模板，不要每条都重写。

FAQ

help center 应该多少篇？: 质胜量。50 篇好文章打败 200 篇平庸的。狠砍。
FAQ 要替代人工 support 吗？: 不。它该导走 60-70% 重复型；剩下 30-40% 路由到人工才是设计目标。
怎么知道 FAQ 在起作用？: 看 FAQ 上线前后某 topic 的工单量。下降 20%+ 且 CSAT 不掉，就有效。
AI 能写完整个帮助中心吗？: 能起草，但每条都要人工核对产品准确性和语气再发布。
多久刷一次？: 功能改动影响的立即刷新，外加每 6 个月对 Top 20 流量文章全面审计。