把别人的 PPT 变成可反复追问的文字稿

竞品的投资者演示、客户给的三年历史汇报、行业协会的年度报告——这类材料的共同点是信息都在图里。你把 PDF 拖进对话框问一句，它答得还行；但你要问第二个、第三个问题时，每次都在重新解析同一份文件。

更麻烦的是，PDF 直接喂有两个硬限制：

• 单次请求最多 100 页（多份文档合计）
• 如果你想把这份材料放进资料库供以后检索，图文混合的 PDF 会让检索质量变差

换个顺序：先转成文字，再问问题

官方 Cookbook 给的做法是叙述法——让模型扮演演讲者，从第一页讲到最后一页，把每一页详细口述一遍。你得到的是一份文字稿。

（原文的例子是财报分析，我们跑了一遍，换成了咨询场景。）

之后所有的追问都基于这份文字稿，不再碰原 PDF。

这么做有三个好处：

1. 快。文字稿几千字，比反复解析几十页 PDF 便宜得多
2. 可检索。纯文本能进任何检索流程，图文混合的 PDF 不行
3. 可核对。它把每个数字都写出来了，你能直接看出哪里读错了——而不是在一个你看不见的中间层里出错

提示词里最关键的一句

原文的提示词里有一句设计得非常聪明：

你的部分观众有视力障碍，所以你不口述的数字，他们就不会知道。

这句话的作用是逼出完整性。不加这句，模型会挑重点讲，把它认为次要的数字略过——而那些数字往往正是你要找的。

第二句同样重要：

不确定含义的缩写不要提。

这是防编造。财报和行业报告里满是缩写，模型不认识时倾向于猜一个合理的解释，而那正是错误结论的源头。

你是这份演示的主讲人，现在要把它完整讲一遍。

整份文档已经提供给你。请从第一页讲到最后一页，
像现场演讲那样叙述。

两条硬要求：
1. 不要提任何你不确定含义的缩写或术语。
2. 不要漏掉任何细节——你的部分听众有视力障碍，
   你不念出来的数字，他们就不会知道。

按这个结构输出：

<narration>
  <page id="1">
  [第 1 页的叙述]
  </page>

  <page id="2">
  [第 2 页的叙述]
  </page>

  ……以此类推，直到最后一页
</narration>

每一页都要写到极其详细，把你看到的每个视觉元素和每个数字都描述出来。
一次性输出完整结果。

用 XML 标签包起来是为了好切分。拿到结果后按 <page id="N"> 分段，你就有了一份带页码的文字稿——之后引用某个数字时，能直接回到原文第几页去核。

拿到文字稿之后

后续问答把文字稿贴进去就行，不用再带 PDF：

以下是一份演示材料的完整文字稿：

<transcript>
[粘贴上一步的叙述结果]
</transcript>

基于这份材料回答：
<question>
[你的问题]
</question>

如果材料里没有足够信息回答，直接说没有，不要推算。

四个检查点

1. 算术不要信。 官方文档明确提到，同一个涉及计算的问题重复问几次，偶尔会得到错误答案——它读数没错，是算错了。凡是需要加减乘除的结论，自己按一遍，或者让它把算式写出来你核。

2. 复杂图表先让它数点。 图表密集的页面，在正式提问前加一句「先描述你在这一页看到的每一个数据点」。这和让它先列步骤再回答是同一个道理——先把观察摊开，判断的质量会明显提高。

3. 靠颜色区分的图要单独处理。 多组柱状图、堆叠面积图这类靠颜色传递分组信息的，模型容易串。做法是先问「这张图里有哪几种颜色，各代表什么」，确认对了再往下问。

4. 抽查三个数字。 文字稿生成后，随便挑三个数回原 PDF 对一遍。这一步花两分钟，但它是你敢把这份分析交出去的唯一理由。

适用边界

这个方法适合图表密集、需要反复追问的材料：投资者演示、年度报告、行业白皮书、客户给的历史汇报。

不适合两类：

• 纯文字的长文档。那种直接喂 PDF 或复制文本更快，叙述法是多余的一步
• 只问一个问题。转文字稿本身要花一次调用，问一次就走的话不划算

页数上限也要注意：单次请求所有文档合计不超过 100 页。超了就分批叙述，最后把几段文字稿拼起来。

一个额外用法

这份文字稿本身就是可交付物。

客户给你一份 80 页的历史汇报让你「先熟悉一下」，你可以把叙述结果整理成一份带页码的摘要归档。下次项目组里任何人要找某个数字，搜这份文字稿就行，不用再翻原件。