用 Muse 生成报告或 PDF，怎样给资料并逐条核对出处

01｜先确认你的账号能交付什么

Meta 在 How We Designed Muse 中写明，Muse 可以生成 documents、PDFs、web pages 等内容，并把聊天之外的丰富输出称为 Artifacts。官方安全说明还说，用户可以检查、编辑和下载放入 Muse VM 或由 Muse 生成的文件。

这篇教程依据 2026 年 10 月 1 日可查的官方资料整理，没有把本站操作写成亲测。开始前请打开自己账号的创建区或 Artifacts 库，确认当前能生成的文档类型、下载方式和可见权限。如果界面只给文档，没有 PDF，就先完成可核对的文档，再用你已有的文档工具转换。不要根据别人视频里的按钮猜自己的账号也有。

Meta 在 2025 年介绍 Meta AI 桌面端时，提到只在部分国家测试富文档编辑器、PDF 导出和文档导入。这能证明 Meta 做过相关功能，也提醒我们入口会随产品、地区和账号变化。看到附件或导入入口才使用；没有入口时，把必要文字、数据和公开链接放进任务，不要声称 Muse 已读取一个它没收到的文件。

02｜先写清交付标准，再把资料给进去

先决定报告交给谁、解决什么问题、要多长、哪天交，以及哪些结论必须有出处。交付包包括报告正文与来源登记，待确认事项和修改记录另附在后面。需要 PDF 时，再把排版后的 PDF 放进交付包。

资料多时不要一次塞进去等它自己判断。先做输入清单，每份材料给一个短编号。网页可以写 S01、S02，会议记录写 M01，表格写 D01。后面核对段落和数字时，用这些编号比反复写长文件名更清楚。

• 每份材料的标题、原始链接或文件名、作者或机构、发布日期与访问日期。
• 这份材料能支持什么，不能支持什么，以及它是一手资料、当事方说法还是个人经验。
• 表格的时间范围、时区、币种、单位、是否含税，以及空白值和重复行怎样处理。
• 不能进入报告的隐私、账号凭据、客户资料和仍受保密要求约束的内容。

03｜把这份任务指令复制给 Muse

把方括号换成自己的项目。资料还没齐时，让 Muse 先停在清单和提纲，不要补写看起来合理的内容。

请根据我提供的资料，为【读者】准备一份关于【主题】的可交付报告。报告用于【用途】，篇幅约【长度】，截止时间为【日期和时区】。先复述你实际收到的资料编号和可访问范围。缺失、打不开或内容冲突的材料单独列出，等我确认后再写正文。

先给提纲和来源计划。每个小节写明要回答的问题，以及准备使用的资料编号。正文里的关键事实、数字、日期、比较和结论都要带来源编号。无法从资料确认的内容写待确认，不要根据常识补齐，也不要编造链接、页码、引语或数字。

初稿完成后另附核对表。每行包含段落编号、关键主张、来源编号、原文位置、发布日期或数据期间、核对状态。数字还要写单位、币种、时间范围、计算式和四舍五入方式。先交核对稿，不发送、不发布，也不替我上传到外部系统。

我确认内容后，再整理最终文档。如果我的账号可以生成 PDF，请同时给 PDF 和可编辑版本；如果当前界面不能直接生成 PDF，请明确告诉我可用的文件类型，我会在自己的文档工具中转换。最终包还要包含来源登记、待确认事项和修改记录。

04｜第一轮只看提纲和证据位置

Muse 给出提纲后，先找没有来源计划的小节。背景介绍、市场判断和总结最容易写得顺，却没有材料托住。没有出处的小节可以删掉、缩成问题，或者等资料补齐再写。

再看一个来源有没有被用得太宽。产品公告可以证明官方发布了某项能力，却不能证明每个账号已经开放，也不能证明实际结果稳定。社区帖子和视频可以告诉你大家在问什么，不能拿来证明普遍能力。

05｜第二轮逐段查出处

给正文段落编号，例如 P01、P02。核对表里每一条主张都要回到原网页、原记录或原数据行。能打开链接还不够，原文必须真的支持这句话的范围、时间和主语。原文只说正在测试，报告就不能写成已经全面开放。

一段里混了事实和解释时，把它们拆开。事实保留来源编号，解释写清依据，仍缺证据的推断放入待确认事项。直接引用只留必要的短句，并核对说话人、日期和上下文。

• 链接能打开，页面标题、作者或机构与登记表一致。
• 原文位置能找到，可以是章节名、页码、时间码或表格行号。
• 报告没有把计划推出写成已经可用，也没有把个人演示写成官方承诺。
• 同一主张遇到来源冲突时并列写出，保留待确认状态。

06｜数字要单独重算一次

数字很容易在摘要里失去口径。报告写增长 18%，要知道起点和终点、采用哪个时间区间、算的是金额还是订单量。百分比、平均数和汇率换算都保留算式，抽两个结果用计算器或原表重算。

两个表里的数字接近也不能直接合并。先核对币种、税费、退款、去重方式和更新时间。没有统一口径时，让报告同时展示两组数字和差异原因，不替读者选一个更好看的值。

07｜修改分三轮，避免越改越乱

第一轮只修事实。处理错误出处、口径冲突、缺失资料和过大的结论。第二轮再修结构，把重复段落合并，让每一节回答一个问题。第三轮才修标题、语气和版式。

每轮结束后让 Muse 列出改了哪一段、为什么改、用了哪个来源。涉及数字、日期或结论的修改要重新进入核对表。不要只接受一句已经修好，也不要让后来增加的漂亮句子绕过来源检查。

08｜最后检查文档和 PDF 本身

内容通过以后再看文件。打开最终文档和 PDF，逐页检查标题层级、目录、页码、表格宽度、图片说明、脚注、超链接和分页。中文字体缺字、表格被截断、链接只在编辑稿有效，都会让一份内容正确的报告无法交付。

PDF 转换以后随机复制一段文字，确认没有变成无法搜索的整页图片。再点开两三个链接，从目录跳到一个章节，并比较 PDF 与核对稿的版本号和更新时间。如果转换过程改了页码，来源登记里的页码也要一起更新。

09｜这些卡点要交给人处理

Meta 的安全说明明确承认 Muse 仍会犯错，外部文件和网页也可能带来攻击。出现这些情况时，停止自动继续，保留当前版本、来源登记和问题列表，让资料所有者或相应专业人员决定下一步。

• 付费墙、登录页或权限问题导致原文打不开。
• 两个权威来源对同一数字、日期或定义给出不同说法。
• 报告包含法律、医疗、财务结论，或者会影响合同、付款和对外承诺。
• 资料里出现提示词注入、陌生下载链接或要求把私密数据发到外部地址的内容。
• 最终文件的格式、字体或链接在你的账号和设备上无法稳定打开。

10｜交付前照着这张清单走一遍

最后让一位没参与写作的人抽查三条主张和两个数字。他能从报告找到原始材料，也能说清哪些地方还没确认，这份报告才适合交出去。

• 正文标题、读者、日期范围、版本号和负责人都写清楚。
• 每个关键段落能回到来源，所有数字有单位、期间和计算方式。
• 待确认内容没有混进确定结论，社区经验没有写成通用事实。
• 文档与 PDF 内容一致，目录、页码、图片、表格和链接可用。
• 来源登记、待确认事项、修改记录和可编辑版本已经放进交付包。
• 文件名包含项目、日期和版本，旧稿不会和最终稿混在一起。