長文檔怎麼問 AI：資料放前面、問題放最後、先引用再回答（官方長文本提示詞技巧）

適用於誰

• 搜「長文本提示詞」「長文本處理時提示詞需注意什麼」的人；
• 經常讓 AI 讀論文、財報、合同、會議記錄，結果要麼泛泛而談、要麼張冠李戴的人。

本文根據 Anthropic、Google、OpenAI 的官方提示詞文檔整理，資料核對於 2026-10-11。文中的寫法在聊天介面和 API 裏都適用。

結論先說

1. 長資料放在提示詞的最前面，問題和要求放在最後。Anthropic 和 Google 的文檔給出了同樣的建議。
2. 多份文檔各自用標籤包起來，並寫上來源，後面才能要求模型說明每句話出自哪裏。
3. 先讓模型摘錄相關原文，再基於摘錄作答。這一步能讓它聚焦在相關內容上，也方便你核對。
4. 明確允許它說「資料裏沒有」，否則它傾向於補全一個看似合理的答案。
5. 資料超過上下文窗口時，換方法而不是硬塞：分塊處理、讓工具做檢索，或者只提供相關章節。

為什麼順序很重要

Anthropic 文檔針對大文檔或大量數據（官方給的量級是 2 萬 token 以上）的第一條建議就是：把長文檔和輸入放在提示詞靠上的位置，在問題、指令和示例之前。文檔裏註明，在測試中把問題放在末尾最多可以把回答質素提高 30%，在多文檔的複雜輸入上尤其明顯。

Google 對 Gemini 3 的建議幾乎一樣：提供大量上下文（文檔、代碼）時，先給出全部上下文，把具體的指令或問題放在提示詞的最後；並且在大段資料之後，用一句過渡語把資料和問題銜接起來，例如「基於以上資訊……」。

OpenAI 的說法角度不同但方向一致：在它推薦的開發者消息結構裏，上下文（Context）這一段通常放在靠後的位置，並用 XML 標籤標明一段參考內容的起止。

換成聊天介面裏的操作就是：先上載或粘貼資料，最後再寫問題；不要先寫一長串要求，再在末尾貼上幾萬字的原文。

步驟

1. 給每份資料貼上標籤

Anthropic 推薦的多文檔結構是：每份文檔用 <document> 標籤包住，裏面再用子標籤分別放來源和正文。

xml
<documents>
  <document index="1">
    <source>2025年度報告.pdf</source>
    <document_content>
    ［粘貼年報正文］
    </document_content>
  </document>
  <document index="2">
    <source>競品分析_Q2.xlsx</source>
    <document_content>
    ［粘貼競品分析內容］
    </document_content>
  </document>
</documents>

基於以上兩份資料，分析我們的戰略優勢，並給出第三季度的重點方向。

直接上載文件時不需要手動包標籤，但在問題裏仍然要用文件名指代，比如「《2025 年度報告》第三章和《競品分析》的結論有沒有矛盾」。

2. 先摘錄，再回答

Anthropic 的建議：處理長文檔任務時，先讓模型把與任務相關的部分逐字摘錄出來，再執行任務。這樣它會聚焦在相關內容上，忽略文檔的其餘部分。官方在「減少幻覺」一文裏把這一步的適用場景寫得更具體：對於超過 2 萬 token 的長文檔，先提取原文引用再執行任務。

模板：

第一步：從上面的資料中，逐字摘錄與「［你的問題］」直接相關的原文，
       放在 <quotes> 標籤裏並編號。找不到相關原文就寫「未找到相關原文」。
第二步：只根據這些摘錄回答問題，在每個結論後面標註所依據的摘錄編號。

好處有兩個：一是回答有據可查，你只需要核對摘錄；二是當它寫出「未找到相關原文」時，你就知道資料裏確實沒有，而不是得到一段編出來的內容。

3. 把問題問具體

長文檔 + 模糊問題 = 泛泛的摘要。對比：

• 模糊：「總結一下這份報告。」
• 具體：「為沒讀過這份報告的銷售總監寫一頁摘要：三句話說清結論；列出 5 個支撐數據並標頁碼；列出報告自己承認的侷限。」

按 Anthropic 的通用原則，說清楚輸出的格式和約束、讀者是誰、用來做什麼。順序或完整性重要時，把要求寫成編號步驟。

4. 分階段提問

一份長文檔通常值得問不止一次。常用的順序：

1. 先要結構：「列出這份文檔的章節結構和每章的一句話概述，讀不到的部分請說明。」用來確認它真的讀到了全文；
2. 再按章節深入：「第 4 章提出了哪幾種方案？做成表格對比。」
3. 最後交叉核對：「第 2 章的預測數據和附錄 B 的原始數據是否一致？逐項列出。」

這也是 Google 文檔裏「拆分提示詞」的做法：複雜任務拆成一連串步驟，前一步的輸出作為後一步的輸入。

5. 資料太長放不下怎麼辦

OpenAI 文檔提醒，模型一次能處理的內容受上下文窗口限制，各模型的窗口大小不同，要查模型文檔確認。放不下時：

• 只給相關章節：自己先篩一遍，比把整本手冊丟進去效果好；
• 分塊處理再彙總：Google 文檔稱之為聚合（對數據的不同部分分別處理，再把結果合併）；
• 用帶檢索的工具：把資料放進知識庫或文件檢索功能裏，每次只取出相關片段交給模型，也就是檢索增強生成（RAG）。

用檢索型工具時有一個竅門，出自 LM Studio 官方文檔對文檔問答的說明：問題裏盡量帶上你預期原文中會出現的術語和說法，命中正確片段的概率更高。

可照抄的模板

<documents>
  <document index="1">
    <source>［文件名或來源］</source>
    <document_content>
    ［資料全文］
    </document_content>
  </document>
</documents>

基於以上資料完成下面的任務。

任務：［具體要做什麼，給誰看，用來幹什麼］

要求：
1. 先在 <quotes> 標籤裏逐字摘錄與任務相關的原文並編號；
2. 再給出回答，每個結論後標註摘錄編號；
3. 資料裏沒有涉及的內容，寫「資料中未提及」，不要用常識補充；
4. 輸出格式：［表格 / 要點列表 / 多少字以內］。

常見問題

Q：聊天介面上載文件和粘貼文本，哪個好？

能上載就上載，表格、圖片和版式資訊保留得更完整。但上載後要用第一問確認它讀到了什麼，掃描件和圖片型 PDF 常常只識別出一部分。

Q：對話越長，它是不是越容易忘記前面的資料？

長對話確實會讓早期內容的影響變弱，也可能觸發上下文壓縮。重要的任務，開一個新對話重新提供資料，比在一個很長的對話裏反覆追問更可靠。見站內《ChatGPT 上下文長度與字數限制》。

Q：讓它標頁碼，標出來的頁碼可信嗎？

不一定，頁碼是最容易出錯的資訊之一。要求它「逐字引用原文」比要求頁碼可靠，因為引文可以直接在原文裏搜尋驗證。

Q：這些建議對所有模型都適用嗎？

「資料在前、問題在後」和「用標籤區分內容」在三家文檔裏都有體現，可以當作通用做法。具體效果仍然建議用你自己的資料試一次再定。

參考資料

• Anthropic 文檔：Prompting best practices（Long context prompting）— https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Anthropic 文檔：Reduce hallucinations — https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations
• Google 文檔：Prompt design strategies — https://ai.google.dev/gemini-api/docs/prompting-strategies
• OpenAI 文檔：Prompt engineering — https://developers.openai.com/api/docs/guides/prompt-engineering
• LM Studio 文檔：Chat with Documents — https://lmstudio.ai/docs/app/basics/rag