開始閱讀
AI 原理入門系列｜第 4 篇，共 10 篇。資料核對：2026-10-09。文中的情境與練習為教學示例。
請 AI 閱讀一份很長的企劃書時，可能會遇到輸入過長，或回答忽略前面的條件。要理解這些現象，先認識 token：模型處理文字時使用的切分單位。它與我們平常計算的中文字數或英文單字數並不相同。
文字先被切分，再轉成編號
Tokenizer 會依自己的規則與詞彙表，把文字轉為 token 序列，再對應到編號。Token 可能是完整詞、詞的一部分、符號或其他片段。不同 tokenizer 對同一段文字可能有不同切法。Hugging Face 的分詞文件介紹了 BPE、WordPiece 與 Unigram 等方法。
因此，「一個中文字等於一個 token」不能當成通則。混合英文、網址、表格或特殊符號後，用字數粗估也可能偏差更大。需要精確估算時，應使用目標模型對應的計數工具。
圖解：文字進入模型的路徑
切成數字不等於已經理解
編號的作用是讓系統能處理文字，不代表編號本身具有自然語意。後續模型會把這些編號轉成向量表示，結合前後文進行運算。Tokenization 是入口，不是整個語言理解過程。
以教學類比來說，把一本書編上頁碼，方便找位置，但頁碼不會替你解釋內容。這個類比只能說明「編碼與意義不同」，不能代表模型真的像人一樣翻書。
上下文是這次任務可用的資訊範圍
對話內容、指令、工具回傳與輸出，可能共同占用模型的上下文額度，實際計算方式依服務而異。可以放進很多內容，也不保證每個細節都被正確使用。工作流程仍要把任務、限制與必要資料整理清楚。
例如將三十頁活動企劃直接貼入，再要求「幫我改善」，模型需要自行猜測重點。若先指定「只檢查預算與執行時程是否矛盾，列出所在段落」，就縮小了需要完成的工作。
長文件可以怎麼整理
本站建議先分成四塊：任務說明、不可變動的事實、要分析的內容，以及輸出格式。對跨章節問題，保留章名與段落編號；若分批摘要，另外維護日期、數字、專有名稱與未解問題清單，避免摘要後遺失細節。
不要只追求把字數壓到最少。刪掉限制條件，可能讓答案更快產生，卻更難使用。應刪除重複與無關內容，保留會改變判斷的資訊。
練習：比較兩種文件提問
拿同一份公開課程簡章，先問「整理重點」，再問「列出對象、日期、費用與報名方式；找不到請標未提供，並附段落位置」。比較哪些資訊被保留、哪些需要回查。這個練習檢查的是資訊組織效果，不是測量模型容量。
圖解：Token 不等於字數
費用怎麼估？先分清輸入與輸出
以下是純教學假設，不是任何供應商的實際報價：每百萬輸入 token 收 1 個計價單位，每百萬輸出 token 收 4 個計價單位。一次送入 12,000 token，生成 2,000 token，則估算為 12,000 ÷ 1,000,000 × 1 + 2,000 ÷ 1,000,000 × 4 = 0.02 個計價單位。
實際服務可能另有快取、工具、圖片、音訊或其他計費項目。應以使用紀錄與當時方案核對。若整段對話歷史反覆送入，總用量也可能增加；不要只計算最新那一句問題的字數。
把長企劃書改成可檢查的輸入
可以建立「事實表」保存活動日期、預算上限、受眾與不可變動的承諾，再將文件分成招募、執行、預算三段。每段先要求找出明確事實與缺漏，最後才跨段比對。這樣保留了查核線索，也避免摘要把重要限制刪掉。
但分段會切斷關聯。例如報名上限在第一章，餐點數量在第三章，單獨讀每一段都可能看不出矛盾。最後整合時，要特別指定需要跨段核對的欄位，並回到原文確認。
練習：記錄兩種輸入方式的 token 用量、遺漏欄位、人工修正時間。較短的提示只有在結果仍完整時，才可能是較好的安排。
一份長企劃如何安排上下文？
假設你要請 AI 根據品牌資料、歷年活動與新的預算限制提出方案。不要把所有檔案無差別貼入，再期待模型自己找出主次。先把任務寫在前面，接著放這次確定有效的限制，最後提供有來源與日期的參考。過期價格、已取消的合作或不同產品的資料，應明確分開，不要讓模型猜哪一版才算數。
可以整理成四層：任務目標、必須遵守的條件、需要引用的事實，以及僅供靈感的案例。每層都要說明用途。例如去年的宣傳標語只是風格參考，不是今年活動的承諾；去年受眾回饋可以幫助提問，不代表今年的每個人都會有相同需求。上下文整理的價值，在於讓資訊的角色更清楚，而不只是把字數壓短。
為什麼「放得進去」不等於「全部用得好」？
上下文視窗描述可處理內容的容量，不是逐字理解與記憶的保證。資料很多、結構混亂或資訊彼此矛盾時，模型仍可能漏掉重點。若一項條件會直接影響成果，例如活動只接受成年參與者，就應在任務規格與最後驗收都出現，不能只藏在某份長文件的中段。
摘要也有代價。把訪談濃縮成三句話，可能丟失受訪者猶豫的原因；把課程條款改成簡短清單，可能漏掉例外。需要精準引用的地方，應保留原始段落與定位資訊，而非只傳遞上一個模型的摘要。摘要適合導航，原文負責核對，兩者一起使用比一層層壓縮更可靠。
如何估算一次工作的費用？
把工作拆成輸入、輸出與重試，而不是只看最後交付多少字。一份兩千字文章，可能先讀很多資料、產生大綱、改寫段落，再做一次查核，因此總用量會高於最後正文。不同模型也可能對快取、圖片或額外推理用量採不同計價方式，應以實際 API 回傳用量與當時價目表核算。
實作時可以為每項任務設上限：最多讀多少來源、允許幾次重寫、什麼情況改成草稿。記錄文章識別碼、模型、用量與結果狀態，有助於找出哪個步驟最耗費成本。不要為了省少量 token 而刪掉關鍵條件；真正值得減少的是重複資料、無目的的重試，以及沒有明確驗收標準的來回修改。
若任務需要分多輪完成，每輪都要確認哪些限制仍然有效。把重要規格保存在可查閱的任務文件，比依賴對話永遠記住所有細節更容易維護。重開工作時先讀規格與最新資料，再繼續修改，可以減少新舊條件混用造成的返工。