通用助手 编辑复核
常见问题回答草稿与事实边界
根据官方资料生成客服或帮助中心的 FAQ 草稿，明确适用范围、例外和需要人工升级的情况。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名帮助中心内容编辑。请只基于给定资料生成可读的 FAQ，不要把推测、旧版本信息或个案经验写成普遍规则。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 按用户问题、简短回答、详细说明、适用条件组织 FAQ
2. 每个回答关联资料来源和更新时间
3. 列出无法确认或需要客服升级的问题
4. 检查是否存在绝对化承诺、隐私风险和版本冲突
输入变量：
- 官方资料（{{source_docs}}）：提供允许引用的文档、公告或产品页摘录。
- 读者（{{audience}}）：说明 FAQ 面向用户、客户还是内部客服。
- 问题清单（{{questions}}）：提供真实问题或搜索查询。
- 升级规则（{{support_policy}}）：说明哪些问题必须转人工处理。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先用真实客服问题建立 FAQ，再按重复率和未解决率更新。
- 每次产品政策变更都要复核相关回答和更新时间。
WHEN IT FITS
适用判断
适合这些情况
- 有具体的问题需要写出准确回答。
- 回答涉及产品行为，你能提供实际规则。
- 需要明确哪些情况回答不了，要转人工。
换个做法更好
- 你要规划的是整个 FAQ 的结构：用《FAQ 问题簇与答案草稿》。
- 问题涉及个别用户的具体情况：通用回答不适用。
- 你没有产品的实际规则：回答会是猜的。
FAILURE MODES
常见翻车与修正
- 回答里描述了产品实际没有的功能或流程。
把产品的实际规则和界面路径粘进输入，要求所有描述以此为准，不确定的标注「需产品确认」。
- 回答绕了半天没给出明确答复。
要求第一句直接回答是或否、能或不能，解释放在后面。
- 涉及退款、隐私、合规的问题也给了确定答复。
这类问题有法律后果。要求标注为需人工或法务确认，回答里只给流程指引不做承诺。
ACCEPTANCE
怎么判断输出合格
- 第一句就是明确答复，不绕弯。
- 所有产品描述来自实际规则，没有虚构功能。
- 涉及法律后果的问题标了需人工确认。
- 说明了回答的适用条件和例外情况。
SAFETY BOUNDARY
使用边界
- 客服工单里的用户身份信息和订单详情不要直接作为素材，先替换成示例值。
- 模型会把「大概是这样」写成确定的答复，涉及退款规则、时效承诺和资质的回答必须由业务方核准后才能上线。