AI 讀文檔其實讀的是「摘要」

你有沒有遇到過這種情況：把一份幾千字的文檔丟給 AI，讓它幫你回答問題，結果 AI 給的答案明顯漏掉了文檔裏的關鍵細節？

你可能以為是 AI「沒認真讀」。但真實原因可能更簡單：它根本沒讀完。

大語言模型有一個叫做「上下文窗口」的硬約束——就像一個人的短期工作記憶，能同時處理的信息量是有上限的。當你提交的內容超過這個上限，要麼系統直接截斷，要麼 AI 自動啓動「壓縮」，把長文檔縮減成它能處理的體積。

問題在於：壓縮不等於摘要。壓縮有四種完全不同的策略，用錯了，要麼答案有偏差，要麼關鍵信息直接消失。

這篇文章來拆解 GitHub 上的 context-compression Skill（來自 h4vzz/awesome-ai-agent-skills 倉庫，截至 2026 年 5 月），看 AI 系統是如何被「教會」壓縮信息的，以及這套設計背後有哪些值得記住的反直覺原則。

先搞清楚一件事：為什麼需要壓縮？

這個問題聽起來很基礎，但答案會影響你對整套設計的理解。

當一個 AI agent 要回答問題時，它通常要先「加載上下文」——可能是一篇文檔、一段對話歷史、一堆檢索結果。這些內容全部塞進模型的 context window，然後模型才能生成回覆。

context window 的大小用「token」衡量。不同模型的上限不一樣——4K、32K、128K 不等（截至 2026 年 5 月，主流商用模型大多在 32K～200K 範圍）。但即使是 128K token 的窗口，一本書、一批業務日誌、一段完整的客服對話歷史，照樣能輕鬆撐爆。

而且，就算沒有超出限制，塞太多無關內容也會降低答案質量——模型需要在一堆信息噪聲裏找到真正有用的部分，注意力被稀釋了。

所以壓縮不只是「裝不下了才壓」的應急手段，更是「讓模型更聚焦」的主動策略。

Skill 裏的第一步描述得很準確：

“

「先量一下 token budget——總窗口減去系統提示詞、指令、以及模型生成所需的輸出空間，剩下的才是真正可用於上下文的配額。如果原始內容已經裝得下，就不需要壓縮。」

這裏有一個很容易忽略的細節：token 預算不是總窗口，是總窗口減掉一堆預留之後的餘量。很多人沒意識到，系統提示詞本身就要佔走一大塊，如果你在 Skill 裏寫了幾百行的 prompt，留給用戶內容的空間其實比想象的少很多。

四種壓縮策略，差異比你以為的大得多

Skill 裏列了四種策略，這是整篇文章最核心的部分。它們不是同一件事的四種說法，而是適用場景完全不同、失敗模式完全不同的四條路。

策略一：提取式摘要（Extractive Summarization）

字面意思——從原文中挑出最重要的句子，原封不動保留，其餘的扔掉。

優點是精確：沒有改寫，沒有重新表述，保留了原文的措辭。對於法律條款、醫療數據、代碼片段這些「一字之差謬以千里」的內容來說，這是最安全的選擇。

缺點也明顯：如果重要信息分散在整段話裏，單獨提取幾句話可能會失去上下文，讓讀者（或模型）無法理解。

工具側的實現：TextRank、LexRank，或者直接用 LLM 做句子相關性打分再挑選。

策略二：生成式摘要（Abstractive Summarization）

這個大多數人更熟悉——讓 AI 用自己的話把長文本重新寫一遍，更短、更連貫。

優點是可讀性強，壓縮率也更高，而且能把分散的信息整合在一起。

但這裏有一個反直覺的設計決策：

“

生成式摘要絕對不能用於代碼。

Skill 裏寫得很清楚：對代碼內容，生成式壓縮「可能引入細微錯誤（subtle errors）」。這話說輕了——實際上，一段 100 行的 Python 函數，經過生成式摘要之後，可能函數名對、邏輯對、註釋也對，但某個邊界條件悄悄改了，或者一個變量名被「規範化」了，這種錯誤在上下文裏極難被發現，但運行起來就會出 bug。

所以對於技術內容，寧可用提取式，哪怕壓縮率低一些。

策略三：關鍵點提取（Key-Point Extraction）

把文本壓縮成結構化的要點列表：命名實體、數字、關鍵事實、結論。

這是壓縮率最高的策略，通常能達到 90%+。一篇 800 token 的文檔，變成 150 token 的要點清單，仍然保留了模型需要的所有關鍵信息——人名、日期、金額、結論。

適用於：信息密集型文檔（財報摘要、會議紀要、數據報告），查詢目的明確（用戶想問「這家公司什麼時候上市的」，不是「幫我感受這篇文章的語氣」）。

不適用於：需要理解敍事邏輯、論證過程、語境推斷的場景。關鍵點提取會扔掉「為什麼」，只保留「是什麼」。

策略四：選擇性剪枝（Selective Pruning）

這是四種策略裏最「保守」的，也是最容易被低估的：不改寫，不提取，只是把明顯多餘的部分刪掉——樣板開頭、重複的解釋、純修辭性的語句、空行和格式符。

Skill 裏給出的使用場景是：「內容只超出預算 10%~15%」的時候。

這是一個值得記住的原則：輕度超支不要動刀，剪枝就夠了。 很多開發者一遇到內容超出就上生成式摘要，但壓縮是有代價的——每多一步處理，就多一份信息丟失的風險。能剪枝解決的，不要摘要。

最核心的設計決策：信息密度評分

四種策略背後，還有一個更基礎的步驟：怎麼判斷哪些內容「值得保留」？

Skill 的第二步叫做「信息密度評分（Score Information Density）」——給每一段、每一句打分，看它在每個 token 裏攜帶了多少與當前任務相關的信息。

這個設計讓我覺得有意思的地方在於：它是 task-aware 的，而不是通用摘要。

一篇關於電商用戶行為的文檔，如果你的任務是「計算用戶 LTV」，那麼第三段裏關於「用戶註冊來源分佈」的詳細分析，信息密度就是低的——雖然它本身很有價值，但對你的任務幫助不大。

傳統摘要工具不管這個，它只看「這段話本身重不重要」。這個 Skill 的設計是：先錨定任務，再評分。 同一份文檔，面對不同的查詢，應該保留不同的內容。

實現上，Skill 給出了兩條路：啓發式方法（關鍵詞與 query 的重疊度），或者輕量分類器。對於工程實踐來說，啓發式方法通常已經夠用——把 query 的關鍵詞列出來，然後統計每個段落包含多少這些詞，打個加權分，就能快速篩出高密度段落。

處理多個來源時的 Token 預算分配

現在 RAG（檢索增強生成）是非常常見的架構——在回答一個問題之前，系統先從知識庫裏檢索出 5～10 個相關段落，然後把這些段落一起塞進 context 裏讓模型綜合回答。

這裏有一個很實際的工程問題：如果 context 預算是 4000 token，10 個檢索結果每個平均 600 token，總共 6000 token，超出了怎麼辦？

最簡單的做法是均勻截斷——每個段落只保留前 400 token。但 Skill 裏推薦的做法是動態預算分配：

“

「對相關性更高的檢索段落分配更多 token，對相關性更低的段落進行更激進的壓縮。」

道理很簡單：5 個檢索結果裏，前 2 個相關性遠高於後 3 個，均勻截斷等於把最重要的部分也砍掉了一半。按相關性分配 token 預算，才是合理的優化。

這個設計決策在 Skill 裏叫做「Token Budget Management」，是四種壓縮技術的橫向管理層。

五個真實會踩的 Edge Cases

說完設計原則，來說 Skill 裏記錄的 Edge Cases——這些才是真正體現「工程洞察」的部分。

1. 內容本來就裝得下——別壓縮

聽起來廢話，但 Skill 專門寫出來了，因為這是真實會發生的誤操作：有人寫了一個流程，不管內容多長，先壓縮再提交。結果對於本來就很短的內容，壓縮反而引入了信息損失。

規則很簡單：先量 token，超了再壓，沒超就別動。

2. 高技術內容（表格、JSON、代碼塊）不適合生成式壓縮

前面提到代碼不能用生成式，這裏擴展到了結構化數據。一個 JSON 對象或一個數據表，經過生成式摘要，結構會被打亂，字段可能被「概括掉」。

正確做法：對結構化內容，用選擇性剪枝（刪掉不相關的字段）或提取式（保留相關行），而不是重新描述它。

3. 多語言內容要分開壓縮

如果原始文檔裏同時有中文、英文、日文，用一個統一的摘要模型處理，不同語言的質量可能差距很大——某些語言在訓練數據裏的比例低，壓縮質量也更差。Skill 的建議是：按語言分段，各自獨立壓縮，或者專門用多語言摘要模型。

4. 安全信息絕對不能被壓掉

這條 Edge Case 寫得很直接：安全警告、法律免責聲明、醫療劑量信息，無論壓縮率多高，這些內容必須原封不動保留。

實現上的建議是：在壓縮前先標記「必須保留」的關鍵詞或段落，壓縮算法跳過這些部分。這需要在 prompt 層做預處理，不能只靠後處理兜底。

5. 壓縮後要驗證信息保留率

這條很容易被忽略：Skill 裏要求在壓縮完成後，做一次「回溯檢查」——針對原始內容裏的關鍵問題，驗證壓縮後的版本還能不能正確回答。

這個檢查步驟在工程上增加了延遲，但避免了一種很隱蔽的風險：壓縮看起來成功了，內容也短了，但模型在回答問題時卻給出了錯誤答案，因為關鍵信息已經在壓縮時悄悄丟失了。

橫向對比：這個 Skill 和「直接讓 AI 總結」有什麼不同？

很多人遇到文檔太長，會直接扔給 AI 一句「幫我總結」。這和 context-compression Skill 的區別是什麼？

本質區別是目的不同：讓人讀的摘要，追求可讀性和連貫性；讓 AI 處理的壓縮上下文，追求信息保留率和 token 效率。這兩個目標在很多地方是矛盾的。

一篇「讓人讀起來很流暢」的摘要，可能把很多具體數字和原文措辭都改掉了——人讀着覺得更優雅，但 AI 在做精確問答時，需要的恰恰是那些「不那麼流暢」的原始數據。

說一個讓我有點震撼的設計細節

Skill 裏有一條 Best Practice 很簡單，但細想很有意思：

“

「壓縮完成後，要告訴模型這份上下文經過了壓縮。」

理由是：讓模型知道自己讀的是摘要而不是原文，它在回答時會「適度降低確定性」，比如加上「根據摘要，文檔似乎提到……」而不是直接斷言。

這裏有一個隱含的認知：模型的自我校準能力是可以被 prompt 提示觸發的。 告訴它「你拿到的是壓縮版」，它對自己輸出的不確定性估計會更準確。

這和「chain of thought」的邏輯有點像——提示語改變模型處理信息的方式，不只改變輸出內容，還影響輸出的置信度。

大多數人在做 RAG 或 long context 處理時，不會專門加這一句話。但如果你的應用對答案准確性要求高，這個細節值得加上。

Skill 的邊界在哪裏

讀完這個 Skill，會發現它在技術層面考慮得很細緻——但有一件事它做不到：判斷什麼信息「在語義上真的重要」。

Skill 裏的信息密度評分，是基於關鍵詞重疊和任務錨點的。這能解決 80% 的場景——你問的問題裏有「營收」，文檔裏含「營收」的段落就會得高分。

但有些重要信息不直接用你問的詞表達。一個分析用戶流失的文檔，裏面有一段關於「產品迭代節奏」的描述，和流失沒有直接詞彙關聯，但實際上是解釋流失原因的關鍵背景——信息密度評分不會給它打高分，但一個有經驗的分析師讀到這裏會停下來。

這不是 Skill 的缺陷，是所有自動化壓縮系統的共同邊界：語義理解的深度是有限的。

真正高質量的上下文管理，往往需要人工標註哪些段落是「必須保留」的（Skill 裏叫做 must-retain keywords）——而這個標註工作，本身就需要人對文檔的深度理解。

AI 接管了壓縮執行，但「決定什麼值得保留」這個判斷，最終還是人的工作。

寫在最後

這次拆解的 context-compression，是 h4vzz/awesome-ai-agent-skills 倉庫 context-engineering 分類下的一個 Skill（截至 2026 年 5 月，該倉庫共收錄 70+ 個 Skill，覆蓋 14 個分類）。

它之所以有趣，在於它揭示了一件通常被藏起來的事：AI 在處理長文檔時，並不是「逐字閲讀」，而是在做不斷的信息取捨。 取捨的策略，決定了答案的質量上限。

四條策略，適用場景各不同；五個 Edge Cases，每一個都是真實踩過的坑；一個「告訴模型你讀的是摘要」的細節，影響的是模型自我校準的準確性——這些設計背後，是大量工程實踐的沉澱。

下次你把一份長文檔丟給 AI，發現它「漏看了」重要信息，不一定是它不認真，也許是壓縮策略用錯了，或者 must-retain 沒有設好。

理解 AI 怎麼「讀」信息，是用好 AI 的前提。