大多數使用 Claude 的實戰者都知道,Anthropic 於 2026 年 2 月推出的 Claude Sonnet 4.6 已經支援單次最高一百萬個 Token 的上下文視窗。但幾乎沒有人在認真使用它。他們依然一次貼一份 PDF,問一個問題,然後關掉視窗。一百萬 Token 的上下文不是更大的 PDF 閱讀器。它是一種完全不同的工作方式。理解這一點的實戰者,將會以另一個層級的水平運作。
本文要補上發佈公告沒有寫的部分:三個只有在一百萬 Token 規模才能跑得通的實戰工作流程,加上三個會悄悄浪費上下文的常見錯誤。每個範例都可以直接複製貼上使用。今天就挑一個試試。
一百萬 Token 上下文視窗的實際意義
一個 Token 大約是四分之三個英文單詞,或一個中文字。一百萬 Token 大致相當於七十五萬個英文字、或一百五十萬個中文字。這個量等於七本完整小說、一份包含所有附錄的年報、或者你與一個客戶整整十八個月的電郵往來。Anthropic 在 2026 年 2 月的更新說明中確認 Claude Sonnet 4.6 支援這個視窗大小,可透過 API 與 Claude 企業版方案使用。
實際的意義是,你不再需要篩選要給 Claude 什麼。你可以把與一個問題相關的全部內容一次給它,讓模型自己過濾。這是一種不同的工作方式,也是大多數實戰者尚未跟上的關鍵轉變。
工作流程一:單次分析完整報告或書籍
長文檔分析是一百萬 Token 視窗最明顯的用途,但大多數人仍然用錯方法。他們貼進一份兩百頁的報告,輸入「幫我總結」,然後得到一份失去所有有趣細節的籠統摘要。一百萬 Token 浪費在籠統摘要上實在可惜。正確做法是在文件之前,先給 Claude 一個清晰定義的視角。
試試以下提示結構:
角色:你是一位策略分析師,正在為一位考慮做出競爭性動作的香港中小企客戶審閱這份年報。
我關心的脈絡:客戶身處同一行業。他們想了解定價策略的轉變、新產品的押注,以及任何利潤壓力的訊號。
你要做的事:讀完整份報告。把對應上述三件事的原文直接引用出來。每段引文要附上頁碼、原句、以及一句競爭意義的解讀。
格式:四欄表格:訊號類型、頁碼、引文、解讀。
然後:在這行之下貼上完整 PDF 全文。在讀完所有內容之前,不要做任何總結。
這個提示之所以有效,是因為你已經告訴 Claude 要找什麼、要抽取什麼、要忽略什麼,以及答案應該長成什麼樣。一百萬 Token 視窗本身不是價值。真正的價值在於問題的設計。
工作流程二:一次將整個客戶專案脈絡載入 Claude
第二個工作流程,是真正改變資深實戰者運作方式的那一個。把一個完整的客戶資料夾、一個完整的專案歷史、一個完整的活動檔案,全部載入到同一個對話中。然後在這個已經備齊脈絡的環境裡,與 Claude 真正對話。
具體做法是,把以下材料蒐集起來:原始 brief、所有電郵往來、所有會議筆記、過往交付物、合約、品牌指南。在每個段落之間加上清晰的章節標題後串接成一份文件。先給一個設定指令,再把完整檔案貼上去。
試試這個開場提示:
接下來你會收到我過去九個月經營的一個專案的完整脈絡。內容包括原始 brief、所有電郵往來、內部筆記、目前的交付物,以及合約。讀完所有資料後,不要做總結。只回應「Ready」,再加上一行確認你了解專案類型與目前階段。我之後會問具體問題,你的答案要引用文件中的實際內容,在相關時提供原文與日期。
然後把完整檔案貼在那段話之後。從這一刻起,你問的每一個問題都建立在完整專案歷史之上。「幫我擬一封給客戶的進度確認電郵」會變成針對這位客戶、依照你既定語氣、引用最近決議的具體內容。「我們二月就上線日期談過什麼?」會給出一個真實答案,把當時的對話原文重新呈現。這就是取代每次客戶溝通前那段整段研究時間的工作流程。
工作流程三:重大策略決定前,通覽所有筆記
第三個工作流程比較個人化。大多數知識工作者都累積了數百則會議筆記、半成形的想法、客戶訪談逐字稿,以及散落在五個工具裡的 Slack 匯出檔。每當有一個策略決定要做,你通常只能憑記憶判斷,因為把所有內容拼湊起來感覺成本太高。
有了一百萬 Token 視窗,這個成本崩盤。把過去六個月在 Notion、Obsidian 或任何寫作工具的筆記匯出。串接成一份文件。配上一個鋒利的框架問題,送進 Claude。
試試這個提示:
以下是我過去六個月的筆記、會議摘要,以及客戶訪談逐字稿。我正在考慮把服務範圍延伸到為中小企提供 AI 工作流程顧問。讀完所有內容後,回答三件事。第一,客戶最常用自己的話表達的具體痛點是什麼。第二,這些筆記中有什麼證據支持往 AI 工作流程顧問方向延伸。第三,這些筆記中又有什麼證據反對這個方向。在引用筆記時,請附上具體的日期。
輸出不是摘要。它是一份你的大腦無法自行產出的綜合分析,因為你的大腦無法同時把六個月的細節全部保留在工作記憶中。這才是真正的解鎖。
三個會浪費長上下文視窗的常見錯誤
一百萬 Token 視窗不會自動改善輸出品質。三個錯誤會穩定地浪費它。避開這三點,結果會明顯跳升。
錯誤一:輸入內容沒有結構標記。如果你貼進八十萬 Token 的混合內容、完全沒有任何標題,Claude 只能自行猜測哪些段落屬於同一個單位。在每個段落之間插入清晰的章節分隔線,例如「=== 電郵串 2026 年 3 月 12 日 ===」或「=== 第一季規劃會議筆記 ===」。模型會用這些分隔線作為後續引用的錨點。
錯誤二:問題出現在文件之前。Anthropic 的官方建議是,長輸入的表現會更好,當問題或指令放在提示最末端、所有文件之後。把文件放前面,把框架問題放最後。如果你習慣寫郵件從上而下,這個順序會反直覺,但這正是模型在長上下文檢索任務中表現最好的安排。
錯誤三:明明想要分析,卻要求「總結」。一份摘要把一百萬 Token 重新壓縮回五百字,等於丟掉了你把所有內容貼進去的價值。改成請它做抽取、對比、綜合,或決策支援。請它引用原文。請它做附引用的表格。請它告訴你跨時間的變化。這些答案之所以存在,正是因為完整脈絡都在視窗裡。
立即試試:測試你的長上下文視窗的診斷提示
這裡有一個低風險的方法讓你親身體驗差別。挑一份你熟悉的單一文件,最好是三十到八十頁的報告。把它貼進 Claude Sonnet 4.6,跑一次以下提示:
我已在上方提供完整文件。不要做總結。請執行三件事。第一,找出這份文件中三個最仰賴未明說假設的主張。引用每個主張的原句,並說明它建立在什麼未明說的假設之上。第二,找出文件中兩處互相矛盾、或削弱先前論點的段落。把兩段都引用出來。第三,找出一個如果整段刪掉、整體論證也不會改變的章節。並說明為什麼。
這個提示能完成摘要永遠做不到的事。它用整個視窗找出論證的結構性弱點。對你自己寫的報告跑一次,你會看到自己的盲點。對競爭對手的白皮書跑一次,你會看到他們的。
結語
一百萬 Token 上下文視窗不是一個更大的檔案上傳器。它是一種與資訊建立關係的新方式:你把全部內容一次交給 Claude,然後在完整圖像就在眼前的情況下,展開一場真正的對話。學會把這套流程設定好的實戰者,將會在三十分鐘內產出過去要花三天的工作。一次只貼一份 PDF 的人,不會注意到天花板已經被抬高。
懂 AI,更懂你 UD 相伴,AI 不冷。如果你想把這些工作流程嵌進你自己團隊的工具裡,正是 UD 過去 28 年一直在做的事。
掌握了這些工作流程,下一步是把它們嵌進你團隊真實的工具裡,讓它們每週都能穩定運行。UD 團隊手把手帶你完成每一步,從 Claude Projects 設定、文件管道,到品質檢查。
