产品文档解释系统，客户则询问具体情境：“可以导出吗？”“取消后会怎样？”“谁能看到我的工作？”AI 能协助将批准的文档改成更清楚的 FAQ 草稿，但关键是保留条件，并承认资料没有回答的问题。
Studio Global Infobase 提供可复用来源，Skill 保存起草和检查说明。来源与工作规则分开维护，才能更清楚地审核答案。
收集当前材料与真实问题主题
使用获准处理的产品指南和政策，移除过时版本。尽可能保留负责人和生效日期，以便处理歧义。从支持与入门流程收集问题主题，不要复制不必要的个人信息。“导出格式”这个主题通常比客户整段邮件历史更有用。
一次性草稿可以直接附加文件；需要定期更新时，可按Infobase 指南创建聚焦集合。
明确什么才算答案
将以下内容作为提示词，或保存为专门的 Skill：
根据选定的已批准产品文档起草 FAQ。
受众：[客户群体]。问题主题：[列表]。
每题提供问题、简短答案、可用的来源文档及章节和重要条件。
只使用材料能支持的信息。
不要编造政策、价格、限制、安全保证或日期。
把未回答或互相冲突的问题放入独立审核清单。
公开文案与内部编辑备注必须分开。
保存规则与提供任务背景的方式见技能指南。
先检查一个小示例
下面的来源和答案是虚构的编辑示例，不是 Studio Global 的产品政策，也不是实测模型输出。
示例来源：项目负责人可以将任务列表导出为 CSV；归档任务不包含在导出中。
可接受的答案是：“项目负责人可以导出 CSV 任务列表，但不包含归档任务。”
不可接受的答案是：“所有成员都能按喜好的格式下载全部项目数据。”后者扩大权限、数据范围与格式，还删掉排除条件。句子看起来顺畅，却已经背离来源。
若客户询问能否恢复归档任务，这份来源没有给出答案。应转给产品负责人，而不是发明恢复政策。
保留内部证据表
| 字段 | 用途 |
|---|---|
| 客户问题 | 确认对应真实需求 |
| 批准答案 | 记录面向客户的措辞 |
| 支持来源 | 允许审核者复核 |
| 条件与例外 | 避免误导性简化 |
| 审核者与日期 | 明确批准责任 |
不要将内部路径或机密备注随 FAQ 一起公开。公开来源可按需链接；私人证据应保留在获授权的审核流程内。
提高清晰度，不改变政策
先给直接答案，再解释术语并缩短长句。不要为了简短删除必要条件。需要较大修改时，可在 Documents 中逐段编辑。Brand Voice 可以调整语气，但事实批准仍来自资料和负责人。
发布后继续维护
通过所选帮助中心或网站的正常流程发布批准答案。在聊天中生成 FAQ，不会自动部署到外部支持系统。保留待解决清单；政策变化，或客户持续对同一表述感到困惑时，重新审核。
先完成少量重要问题。一组准确且便于维护的答案，比大量自信猜测更有价值。