讀完這篇文章，你將清楚了解什麼是 AI 上下文視窗、它如何默默決定 AI 對你業務的實用程度，以及為什麼規格表上數字最大的模型，未必是最能替你節省時間的選擇。沒有術語，沒有行銷語言——只談香港老闆真正需要知道的部分。
上下文視窗（Context Window）在 2026 年成為熱門商業話題，原因很直接：數字爆炸了。Google Gemini 標榜 100 萬 token、GPT-5 可處理 40 萬、Claude 提供 20 萬。這些看似只是規格，但實際上決定了 AI 能否一次記住你與客戶的整段對話、你剛貼上的完整價目表，以及上個季度的交接記錄。如果你曾經把長文件貼進 ChatGPT，然後看著它「忘記」一半內容，其實你早已遇過上下文視窗——只是不知道它的名字。
這篇文章會從頭解釋這個概念、展示它在香港中小企日常運作中如何發揮作用，並幫助你分辨：什麼是真正的能力，什麼只是規格表上的數字遊戲。
什麼是 AI 上下文視窗？
上下文視窗是 AI 模型在一次對話中，可以閱讀、記住和回應的最大文字量，以 token 為單位計算。你輸入的問題、系統指令、你貼上的檔案、對話歷史、以及 AI 自己的回答都會一併計算在內。一旦超出這個上限，模型就會開始遺忘最早的部分。
可以把它理解為 AI 的短期記憶。一位人類助手能記得兩小時會議的大致輪廓，但沒有筆記就會忘記具體數字。AI 沒有筆記，只有上下文視窗。一個 20 萬 token 的視窗，大約等於 20 萬個中文字，相當於一份約 200 頁的商業文件。超過的部分，一旦滑出視窗邊緣就消失了。
計算單位是 token，不是字。 AI 模型不是以字數計算，而是以 token 為單位。一個中文字大致等於 1 個 token，一個英文字大約等於 0.75 個 token。所以 20 萬 token 的視窗，大約可以放下 20 萬個中文字或 15 萬個英文字。實際數字取決於你的中英文比例。
上下文視窗實際是如何運作的？
在模型內部，視窗裡的每一個 token 都要與其他 token 建立關聯。視窗愈大，模型要進行的比較就愈多。根據 IBM 的技術文獻，這種計算量大致以平方增長——視窗加倍，運算成本不只是加倍，而是接近四倍。
這也解釋了為什麼超大視窗在 2023 年技術上難以實現、2024 年昂貴無比，到 2026 年才變得可以負擔。推動這項突破的不是建更多 GPU 機房，而是底層工程的改進。
實際後果是什麼？ 一個 100 萬 token 視窗的模型，不只是「比 20 萬 token 的模型更大」而已。它每次請求更慢、每次查詢更貴，而且最關鍵的是——它在視窗中段的準確度往往下降。模型對視窗的開頭和結尾表現良好，但在中間位置，資訊最容易被忽略。
上下文視窗的大小，對中小企為何重要？
視窗大小決定你可以一次性交給 AI 處理多少工作。小視窗迫使你把文件切成小塊；大視窗則允許你貼上整份合約、完整員工手冊或完整的客戶對話記錄，然後就整體內容提出問題。
以下是三個具體的香港中小企場景：
--- 客服交接。 一位餐廳老闆想讓 AI 先讀完 30 頁的訂座政策與過去 200 則客戶訊息，才回應新查詢。這大約是 4 萬 token——對現代模型完全沒問題，但 2023 年時代的 4,000 token 視窗會立即當機。
--- 租約與合約審核。 一間地產代理要求 AI 將 60 頁的租約與 40 頁的業主範本逐條比對，找出差異。總計約 12 萬 token。在 20 萬 token 下運作順暢；在 10 萬 token 下就無法完成。
--- 全年帳目檢視。 一間小型零售店上載 12 個月的交易描述，約 30 萬 token 的文字量，要求 AI 找出異常。只有 40 萬 token 以上的模型能一次看完全部。
如果你日常處理的文件都不長，視窗大小其實影響有限。但如果你經常處理長合約、厚手冊或完整對話記錄，它就決定了什麼是可能的、什麼是不可能的。
上下文視窗是不是愈大愈好？
不是。愈大的視窗成本愈高、速度愈慢，而且在視窗中段的準確度往往下降——研究員稱這個現象為「上下文腐化」（context rot）。2026 年多項基準測試顯示，標榜 20 萬 token 的模型，往往在 13 萬 token 左右就開始表現不穩。而且這種退化是突然發生，不是漸進的。
這一點很重要，因為 AI 收費通常是按 token 計算。一次用掉 50 萬 token 上下文的查詢，成本大約是用 4,000 token 查詢的 125 倍。對一間每日運行 100 次查詢的香港中小企而言，這是每日幾元與幾百元的差別。
實用原則是這樣的： 選用能舒適容納你任務的最小視窗。對 95% 的中小企應用場景，20 萬 token 已經綽綽有餘。100 萬 token 的模型主要用於法律文件審閱、程式碼分析、長篇研究——不是用來回覆客戶電郵的。
當你超出上下文視窗，會發生什麼事？
當你超出上下文視窗，模型要麼直接報錯，要麼在你不知情的情況下靜靜刪掉最早的對話內容。兩種行為都不是使用者預期的。AI 不會提醒你它正在遺忘——它只是根據不完整的資訊，給出一個較差的回答。
在商業運作中，這通常表現為兩種情況：
--- AI 突然「忘記」你 40 則訊息前貼上的價目表。 那份價目表已經滑出視窗，AI 現在只能憑空編造價格。
--- AI 給出的答案，與你在對話開始時設定的規則互相矛盾。 那些規則同樣已經滑出視窗，AI 現在是在沒有規則的情況下運作。
實際的解決方法：對於絕對不能遺忘的內容（價目、政策、審批規則、品牌指引），要麼把它貼在最新提示的結尾（視窗尾端最容易被記住），要麼使用設有獨立知識庫的 AI 方案，讓這些資訊不用擠進上下文視窗。
AI 員工如何以不同方式處理長內容？
一個設計良好的 AI 員工，不會單靠把所有資訊塞進上下文視窗。它會結合一個合理大小的上下文視窗，加上一個外部知識庫——有時稱為檢索增強生成（RAG）——讓 AI 每次只取出最相關的資訊片段，而不是把整個圖書館都搬進來。
這個差別很重要，因為它區分了「消費級聊天機械人」與「企業級 AI 員工」。
--- 消費級聊天機械人 每次都要求你重新貼上所有內容。對話一長，它就會遺忘。
--- 為企業設計的 AI 員工 會把你的政策、價目表、產品目錄、歷史對話儲存在可搜尋的知識庫中。上下文視窗只需要保存與當前問題相關的內容，即使累積了數千次客戶對話，AI 仍然能保持準確。
對香港中小企來說，這個架構選擇，比上下文視窗的原始數字更重要。一個 20 萬 token、有良好知識庫的 AI 員工，表現會勝過一個 100 萬 token、每次都要靠貼文字的聊天機械人。
關於上下文視窗的常見誤解
大多數中小企老闆是從行銷標題認識上下文視窗的，因此累積了幾個固執的誤解。釐清這些誤解，可以避免花冤枉錢，也避免買錯工具。
--- 「愈大愈好」： 不對。愈大愈貴，而且中段往往愈不準確。視窗要配合任務。
--- 「上下文視窗就是 AI 的長期記憶」： 不對。它只是單次對話的短期工作記憶。長期記憶要靠獨立的知識庫或微調。
--- 「對話記錄放在視窗裡就安全了」： 不對。一旦超出視窗，最早的部分會被靜靜刪除。重要資料要另外儲存。
--- 「視窗裡每個 token 的權重都一樣」： 不對。模型對開頭與結尾的注意力，明顯高於中段。重要指令應該放在這兩個位置。
香港中小企實際上需要多大的上下文視窗？
大多數香港中小企需要 3.2 萬至 12.8 萬 token 的上下文視窗——足以處理一次完整的客戶對話加上詳細的業務政策。超過 20 萬 token，對多數應用場景已經過剩，而且每次查詢開始要花真金白銀。
以下是按業務類型劃分的粗略建議：
--- 餐飲業： 3.2 萬 token 已足夠。完整餐牌加上三個月訂座記錄綽綽有餘。
--- 零售店： 6.4 萬 token。產品目錄（最多 500 款）加上當期推廣與客戶常見問題。
--- 地產代理： 12.8 萬至 20 萬 token。完整租約、業主範本、相關案例資料都能放得下。
--- 專業服務（法律、會計、顧問）： 20 萬 token 或以上。文件密集型工作最能受益於大視窗。
如果你不肯定自己屬於哪一類，最安全的選擇是配備知識庫的現代 AI 員工。重擔由知識庫承擔，上下文視窗只需要放當前問題與最相關的文件。
結論：上下文視窗是天花板，不是賣點
上下文視窗是 AI 一次能看見的「天花板」。它不是魔法，不是免費的，也不等同於智能。規格表上數字最大的 AI，未必是最能替你節省時間的 AI——特別是當你其實不需要傳送這麼長的上下文，卻還是按 token 付費的時候。
對香港中小企而言，重點從來不是最大的視窗，而是正確的架構：一個實用大小的上下文視窗，搭配一個可搜尋的知識庫，並由同時理解技術與你業務的人來設置。這就是「AI 在關鍵時刻忘記事情」與「AI 成為你團隊可靠一員」之間的差別。
UD 陪伴香港企業走過 28 年，我們懂 AI 的冷，更懂你的難——懂 AI，更懂你。
準備好打造一個真正記得你業務的 AI 員工？
了解了上下文視窗是什麼、以及架構為何比規格更重要，下一步就是為你的業務找出最合適的方案。UD 的 AI Employee Hub 幫你挑選、訓練、部署 AI 員工，把合適的上下文視窗與你真實業務內容的知識庫結合起來。UD 團隊手把手教你評估、選型，到部署上線，全程陪你走每一步。