最近總有人問(wèn)我網(wǎng)上流傳的“ChatGPT 開(kāi)啟無(wú)限 token”到底是什么意思是不是存在什么隱藏設(shè)置能解鎖一個(gè)永遠(yuǎn)不封頂?shù)膶?duì)話窗口。說(shuō)實(shí)話我每次看到這類說(shuō)法都想先潑一盆冷水大語(yǔ)言模型從底層架構(gòu)上就不存在“無(wú)限 token”這回事但確實(shí)可以通過(guò)一系列方法和工具讓你在有限窗口里處理近似無(wú)限的內(nèi)容同時(shí)把五花八門的 token 報(bào)錯(cuò)一個(gè)個(gè)消滅掉。這篇文章就是干這個(gè)的。不管你是日常聊天用戶、拿它寫文檔做翻譯的普通上班族還是自己寫代碼調(diào) API 的開(kāi)發(fā)者都能往下看。我會(huì)把 token 的本質(zhì)、普通人的長(zhǎng)對(duì)話技巧、開(kāi)發(fā)者的工程化方案以及我踩過(guò)的各種 token 報(bào)錯(cuò)一次性講清楚。1. 先把“無(wú)限 token”這句話拆開(kāi)看1.1 token 是什么為什么網(wǎng)上都在談很多人把 token 直接理解成“字?jǐn)?shù)”其實(shí)不太準(zhǔn)確。token令牌/詞元是模型處理文本時(shí)的最小單位你可以把它想象成把一段話切成的積木塊。英文里一個(gè)常見(jiàn)單詞通常對(duì)應(yīng)一個(gè) token比如 hello 就是一個(gè) token但 unbelievable 這種長(zhǎng)單詞可能被切成 un、believ、able 三個(gè) token。中文的切法也不太一樣一個(gè)漢字大約對(duì)應(yīng) 1 到 2 個(gè) token具體取決于分詞器怎么切。所以網(wǎng)上說(shuō)的“token 用量”并不是單純的字符數(shù)。粗略估算1000 個(gè) token 大概能覆蓋 750 個(gè)英文單詞或者 400 到 600 個(gè)漢字。注意這只是經(jīng)驗(yàn)值實(shí)際會(huì)因?yàn)榭崭?、?biāo)點(diǎn)、語(yǔ)言混雜而上下浮動(dòng)。這里有兩個(gè)和 token 強(qiáng)相關(guān)的使用場(chǎng)景計(jì)費(fèi)和上下文窗口。所有走 API 的調(diào)用都會(huì)按照輸入 token 加輸出 token 來(lái)計(jì)費(fèi)網(wǎng)頁(yè)版付費(fèi)訂閱雖然看起來(lái)是包月但單次對(duì)話能容納的信息量仍然受 token 上限約束。也就是說(shuō)token 這個(gè)概念對(duì)免費(fèi)用戶、訂閱用戶、開(kāi)發(fā)者都躲不開(kāi)。1.2 上下文窗口所有“上限”的根源模型一次能處理的 token 總數(shù)是有上限的這個(gè)上限叫上下文窗口context window。上下文窗口就像模型的短期工作記憶里面既要裝你輸入的內(nèi)容也要裝模型自己生成的回復(fù)。一旦接近甚至超過(guò)窗口極限模型要么直接報(bào)錯(cuò)要么開(kāi)始“遺忘”最早的內(nèi)容。不同模型的窗口大小差別很大。幾年前的模型可能只有 2K、4K token現(xiàn)在的旗艦?zāi)Ｐ鸵呀?jīng)能做到 128K、200K甚至 1M token 的超大窗口。但無(wú)論多大它終歸是一個(gè)有窮數(shù)。這里有個(gè)很多人都不知道的機(jī)制ChatGPT 并不是真的“記住”了你們的聊天它每次回答時(shí)其實(shí)都會(huì)把整個(gè)對(duì)話歷史重新當(dāng)作輸入讀一遍。所以窗口越大單次計(jì)算成本越高處理超長(zhǎng)文本時(shí)模型的理解精度還會(huì)下降這就是業(yè)內(nèi)常說(shuō)的“大海撈針”問(wèn)題——文本越長(zhǎng)真正重要的信息越容易被淹沒(méi)。1.3 為什么“無(wú)限 token”是個(gè)偽需求但可以實(shí)現(xiàn)把上下文窗口想象成辦公桌桌面面積再大也是有限的。你不可能把所有文件無(wú)限堆在桌面上但你可以做到頻繁用到的文件放在手邊不常用的歸檔進(jìn)柜子需要時(shí)再找出來(lái)。所謂“無(wú)限 token”本質(zhì)上是這套整理術(shù)的自動(dòng)化和工程化。很多人追求“無(wú)限 token”真實(shí)需求其實(shí)是三個(gè)第一不想在長(zhǎng)對(duì)話中丟失前面的重要信息第二希望一次性處理超大文檔第三希望不要隔三差五就撞上 token 相關(guān)的報(bào)錯(cuò)。這三個(gè)需求都不需要真正無(wú)限的窗口只需要對(duì)上下文做主動(dòng)管理。接下來(lái)我分別從普通用戶和開(kāi)發(fā)者兩個(gè)角度講具體怎么做。2. 普通用戶的“無(wú)限 token”不寫代碼的上下文管理2.1 識(shí)別對(duì)話已經(jīng)逼近上限的幾個(gè)信號(hào)網(wǎng)頁(yè)版不會(huì)直接告訴你“當(dāng)前已用 86000 token”但你有幾個(gè)很明顯的信號(hào)可以判斷對(duì)話已經(jīng)塞滿了。信號(hào)一ChatGPT 開(kāi)始忘記開(kāi)頭聊過(guò)的事情比如你第一輪就說(shuō)了“項(xiàng)目截止日期是周五”到后面它問(wèn)你“截止日期是哪天”。信號(hào)二你上傳的長(zhǎng)文檔后續(xù)提問(wèn)時(shí)它回答得像完全沒(méi)讀過(guò)一樣這多半是因?yàn)槲臋n內(nèi)容已經(jīng)被擠出了窗口。信號(hào)三它的回復(fù)語(yǔ)句開(kāi)始莫名其妙地重復(fù)、混亂或者提示當(dāng)前對(duì)話串無(wú)法繼續(xù)。遇到這些信號(hào)正確做法不是繼續(xù)硬聊而是開(kāi)一個(gè)新對(duì)話。開(kāi)新對(duì)話之前先用下面這招把重要信息帶過(guò)去。2.2 主動(dòng)總結(jié)法讓 AI 幫你壓縮聊天歷史當(dāng)你覺(jué)得當(dāng)前對(duì)話已經(jīng)很長(zhǎng)別直接繼續(xù)。先輸入一句請(qǐng)把我們剛才討論的所有要點(diǎn)整理成一份 200 字左右的摘要必須包含已確定的結(jié)論、待辦事項(xiàng)、未解決問(wèn)題和關(guān)鍵背景信息。等它輸出摘要后把這份摘要復(fù)制下來(lái)開(kāi)一個(gè)新對(duì)話把摘要作為第一條消息貼進(jìn)去然后繼續(xù)提問(wèn)。這相當(dāng)于手動(dòng)把歷史壓縮成一份“項(xiàng)目簡(jiǎn)報(bào)”新對(duì)話的可用上下文立刻滿血。我個(gè)人的習(xí)慣是讓 ChatGPT 用固定格式輸出摘要比如“背景 / 結(jié)論 / 待辦 / 未決問(wèn)題 / 關(guān)鍵術(shù)語(yǔ)”這樣后續(xù)粘貼時(shí)一目了然新對(duì)話里也能快速接上。這個(gè)方法看起來(lái)簡(jiǎn)單但真的救過(guò)我很多次長(zhǎng)文檔協(xié)作場(chǎng)景比硬撐一個(gè)超長(zhǎng)對(duì)話穩(wěn)定太多了。提示摘要也是要消耗 token 的但這份消耗幾乎一定比繼續(xù)堆一個(gè)將爆未爆的長(zhǎng)對(duì)話便宜得多。2.3 大文件分段喂別一次性堆進(jìn)去很多人上傳一個(gè)幾百頁(yè)的 PDF直接說(shuō)“總結(jié)一下”期待模型像人一樣通讀全文。但網(wǎng)頁(yè)版的上下文窗口就那么大連文件帶回復(fù)幾分鐘就會(huì)被擠爆后續(xù)提問(wèn)質(zhì)量斷崖式下跌。正確做法是分而治之先從文檔里拆出目錄或章節(jié)結(jié)構(gòu)按章節(jié)逐個(gè)喂給模型每一章都讓它輸出帶要點(diǎn)的局部總結(jié)最后把若干份章節(jié)總結(jié)合并再做一次全局總結(jié)。這個(gè)“先局部后整體”的順序很重要。你甚至可以先把文檔用本地工具粗略切分成多個(gè)小文件再分批上傳和提問(wèn)。別嫌麻煩這個(gè)習(xí)慣能讓你省下大量因?yàn)椤澳Ｐ蜎](méi)讀過(guò)文檔”而產(chǎn)生的返工時(shí)間。我自己處理技術(shù)方案類文檔時(shí)還會(huì)讓模型針對(duì)每個(gè)章節(jié)輸出 3 到 5 個(gè)關(guān)鍵問(wèn)題這樣最后合并總結(jié)時(shí)能額外得到一份“閱讀提綱”。2.4 利用記憶功能與自定義指令固定重要信息如果你有一些需要長(zhǎng)期穩(wěn)定生效的規(guī)則比如“你是我寫英文郵件的助手語(yǔ)氣正式避免縮寫”不需要每次新對(duì)話里重復(fù)一遍。把這些放進(jìn) ChatGPT 的自定義指令或者記憶功能里模型會(huì)在后續(xù)所有對(duì)話中自動(dòng)繼承。這相當(dāng)于把你的“使用說(shuō)明書(shū)”常駐在上下文中非常省 token。不過(guò)要注意別把記憶開(kāi)得過(guò)雜。記憶功能如果塞滿了各類無(wú)關(guān)瑣事它反而會(huì)占用上下文空間甚至讓回答“串味”。我的經(jīng)驗(yàn)是只保留 3 到 5 條穩(wěn)定且高頻的規(guī)則其余臨時(shí)的東西每次對(duì)話里現(xiàn)寫。這樣既省 token又不容易污染模型對(duì)當(dāng)前任務(wù)的理解。3. 開(kāi)發(fā)者的“無(wú)限 token”工程化方案怎么做3.1 問(wèn)題直接拼歷史文檔行不通如果你在調(diào)用 API你其實(shí)是控制上下文的那個(gè)人這也意味著寫代碼的人必須自己解決“上下文超限”。我見(jiàn)過(guò)太多新手犯同一個(gè)錯(cuò)誤把數(shù)據(jù)庫(kù)里的全部聊天記錄一股腦拼成 messages 數(shù)組傳給接口沒(méi)攢幾輪就撞上 400 錯(cuò)誤或者上下文超限提示。網(wǎng)頁(yè)版還有一定的智能裁剪機(jī)制但 API 接口是“你給什么它處理什么”沒(méi)有內(nèi)置人性化的自動(dòng)遺忘邏輯。所以開(kāi)發(fā)者版“無(wú)限 token”的核心就一句話在有限窗口里動(dòng)態(tài)決定每一輪請(qǐng)求到底該帶哪些內(nèi)容。下面三種方案是按成本從低到高排列的你可以按場(chǎng)景去選。3.2 開(kāi)發(fā)者的第一種方案滑動(dòng)窗口截?cái)嘧詈?jiǎn)單粗暴的方案是只保留最近 N 條消息超過(guò) N 條就把最老的彈出去。這在實(shí)現(xiàn)上就是一個(gè)固定長(zhǎng)度的隊(duì)列MAX_MESSAGES 20 messages.append({role: user, content: new_text}) if len(messages) MAX_MESSAGES: messages messages[-MAX_MESSAGES:]適合閑聊機(jī)器人、客服機(jī)器人這類不需要“記住很久以前細(xì)節(jié)”的場(chǎng)景。缺點(diǎn)也很明顯粗暴早期的重要信息可能會(huì)丟。如果你的應(yīng)用要求用戶在第一輪說(shuō)了“我不吃花生”20 輪后點(diǎn)餐時(shí)它已經(jīng)把這條忘了那就是事故。所以這種方式更適合臨時(shí)性、短交互的應(yīng)用。3.3 開(kāi)發(fā)者的第二種方案歷史摘要壓縮我更推薦的一種方案是“摘要壓縮”適合長(zhǎng)對(duì)話管理。思路是當(dāng) messages 的總 token 數(shù)接近窗口上限時(shí)先調(diào)用一次相對(duì)便宜的模型把舊消息壓縮成一段摘要然后把摘要作為一個(gè) system 角色消息塞回上下文里最近的幾條原文繼續(xù)保留。這里給出一個(gè)可跑的示例邏輯import tiktoken enc tiktoken.get_encoding(cl100k_base) def count_tokens(text: str) - int: return len(enc.encode(text)) def total_messages_tokens(messages) - int: return sum(count_tokens(m[content]) for m in messages) def compress_history(messages, recent_count10): if total_messages_tokens(messages) 60000: return messages history_to_compress messages[:-recent_count] recent_messages messages[-recent_count:] history_text \n.join( f{m[role]}: {m[content]} for m in history_to_compress ) summary_response client.chat.completions.create( modelgpt-4o-mini, # 換成你賬號(hào)實(shí)際可用的模型 messages[ {role: system, content: 你負(fù)責(zé)把對(duì)話歷史壓縮為簡(jiǎn)潔摘要保留事實(shí)、用戶偏好、約定、待辦事項(xiàng)。}, {role: user, content: f請(qǐng)壓縮下面的歷史對(duì)話\n{history_text}}, ], ) summary summary_response.choices[0].message.content messages recent_messages messages.insert(0, {role: system, content: f對(duì)話歷史摘要{summary}}) return messages注意觸發(fā)條件里的60000這個(gè)數(shù)字要結(jié)合你實(shí)際用的模型窗口大小來(lái)定比如模型窗口是 128K且你還要給輸出留空間那觸發(fā)閾值就應(yīng)該設(shè)置成比如 100K而不是 60K。我在實(shí)際項(xiàng)目里跑過(guò)幾百輪的長(zhǎng)對(duì)話用這個(gè)策略后幾乎再?zèng)]出現(xiàn)過(guò)上下文爆掉的情況代價(jià)僅僅是每次壓縮時(shí)多調(diào)用一次模型成本很低。3.4 開(kāi)發(fā)者的第三種方案向量檢索增強(qiáng)RAG如果你要處理的是大型知識(shí)庫(kù)、PDF 文檔集這類靜態(tài)內(nèi)容摘要壓縮不夠用滑動(dòng)窗口更不夠用。這時(shí)候最合適的思路是 RAG檢索增強(qiáng)生成把文檔先切塊把每塊變成向量存起來(lái)用戶提問(wèn)時(shí)先檢索出最相關(guān)的幾段再塞進(jìn)上下文讓模型回答。相當(dāng)于給模型裝了一個(gè)“外部硬盤”每次只讀取需要的那幾頁(yè)。流程拆開(kāi)大致是四步切塊、向量化、召回、再生成。切塊可以按段落或固定長(zhǎng)度切中間留一點(diǎn)重疊向量化選用 embedding 接口把文本轉(zhuǎn)成一串浮點(diǎn)數(shù)召回階段把用戶問(wèn)題也轉(zhuǎn)成向量計(jì)算余弦相似度取 top-k 最相關(guān)片段最后把片段拼進(jìn) prompt讓模型基于這些片段回答。一個(gè)最小可參考的檢索邏輯長(zhǎng)這樣import numpy as np from openai import OpenAI client OpenAI() def get_embedding(text: str): # 換成你賬號(hào)實(shí)際可用的 embedding 模型名 resp client.embeddings.create( modeltext-embedding-3-small, inputtext ) return resp.data[0].embedding def cosine_sim(a, b): a np.array(a) b np.array(b) return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))) # 文檔切塊后把每塊向量存進(jìn) chunks 列表提問(wèn)時(shí) question_vec get_embedding(用戶的問(wèn)題) chunks.sort(keylambda item: cosine_sim(question_vec, item[vec]), reverseTrue) top_chunks [item[text] for item in chunks[:3]] prompt 請(qǐng)基于下列資料回答問(wèn)題\n \n---\n.join(top_chunks)實(shí)際生產(chǎn)項(xiàng)目里不需要自己寫向量的存儲(chǔ)和排序可以直接用向量數(shù)據(jù)庫(kù)或者帶向量搜索的組件但核心邏輯就是這樣。這個(gè)方案最適合的場(chǎng)景是“文檔很多、問(wèn)題很雜、每次只需要一小部分信息”。3.5 三種方案的取舍與成本方案適合場(chǎng)景優(yōu)點(diǎn)主要成本滑動(dòng)窗口截?cái)喽虒?duì)話、閑聊機(jī)器人實(shí)現(xiàn)最簡(jiǎn)單無(wú)額外調(diào)用會(huì)丟失舊信息歷史摘要壓縮長(zhǎng)會(huì)話、項(xiàng)目管理保留全局信息穩(wěn)定每次壓縮需多調(diào)一次模型向量檢索增強(qiáng)知識(shí)庫(kù)問(wèn)答、超大文檔上下文消耗極小可擴(kuò)展需要切塊和向量化架構(gòu)稍復(fù)雜我建議不要一上來(lái)就上 RAG。很多人對(duì)話類應(yīng)用只要做摘要壓縮就夠了RAG 除了檢索召回還要維護(hù)文檔更新工程量翻倍。先把摘要壓縮用熟等確實(shí)碰到“從數(shù)千份文檔里找答案”的需求再上 RAG 不遲。4. 實(shí)操現(xiàn)場(chǎng)token 相關(guān)報(bào)錯(cuò)的排查手冊(cè)4.1 登錄和 Token 交換類錯(cuò)誤這一類報(bào)錯(cuò)里的 token 和模型計(jì)費(fèi)的 token 不是一回事這里說(shuō)的是登錄態(tài)的訪問(wèn)令牌。典型的報(bào)錯(cuò)長(zhǎng)這樣sign-in could not be completed token exchange failed或者 token exchange failed: token endpoint returned status 403 forbidden。我遇到過(guò)的情況大致有四種一是本地保存的登錄態(tài)過(guò)期了但客戶端還在用舊令牌去請(qǐng)求二是多設(shè)備同時(shí)登錄服務(wù)端吊銷了其中一個(gè)會(huì)話三是賬號(hào)信息比如國(guó)家或地區(qū)字段和當(dāng)前網(wǎng)絡(luò)環(huán)境不一致服務(wù)端安全策略拒絕令牌交換四是服務(wù)端臨時(shí)故障或限流。優(yōu)先操作順序如下先退出當(dāng)前賬號(hào)清理瀏覽器或客戶端里對(duì)應(yīng)站點(diǎn)的緩存和站點(diǎn)數(shù)據(jù)再重新走一遍登錄流程如果提示 403 country就檢查賬號(hào)資料里的國(guó)家或地區(qū)是否正確填寫并確保填寫的信息和實(shí)際使用環(huán)境一致多設(shè)備同時(shí)用的話把其他設(shè)備的會(huì)話全部退出再在主力設(shè)備重新登錄。大多數(shù)時(shí)候這一套就能解決如果還不行等一小時(shí)再試一次有時(shí)候它就是服務(wù)端限流。提示遇到 token exchange failed 時(shí)最快能救回來(lái)的是“徹底注銷再登錄”而不是反復(fù)點(diǎn)重試。重試只會(huì)讓舊令牌繼續(xù)堆積問(wèn)題。4.2 刷新 Token 失敗的幾種情況刷新失敗最常見(jiàn)的報(bào)錯(cuò)是your access token could not be refreshed. please log out and sign in again以及 failed to refresh token: 400 bad request: invalid refresh_token: empty string。前者一般是 refresh token 或 access token 生命周期到了但客戶端沒(méi)能續(xù)上后者通常是客戶端在持久化 refresh token 時(shí)寫入失敗導(dǎo)致提交了一個(gè)空字符串。如果你是自己寫的客戶端別嘗試去“強(qiáng)行續(xù)簽”。正確做法是捕獲刷新失敗的異常后主動(dòng)提示用戶重新登錄重新獲取新的令牌。如果你只是普通用戶看到這類報(bào)錯(cuò)就按照客戶端的提示退出再登錄。另外如果本地系統(tǒng)時(shí)間和真實(shí)時(shí)間差太多也會(huì)導(dǎo)致令牌校驗(yàn)失敗順手把系統(tǒng)時(shí)間同步打開(kāi)。括號(hào)里多說(shuō)一句網(wǎng)上熱議的 JWT 實(shí)現(xiàn) token 續(xù)簽和 OpenAI 令牌交換是同一類問(wèn)題access token 壽命短refresh token 壽命長(zhǎng)但也會(huì)失效。工程上的標(biāo)準(zhǔn)做法就是失敗后重新走授權(quán)而不是變魔術(shù)。4.3 模型或配置文件相關(guān)的 Token 提示現(xiàn)在桌面客戶端和命令行工具越來(lái)越普及很多報(bào)錯(cuò)其實(shí)來(lái)自本地配置。比如 chatgpt 無(wú)法加載 config.toml或者 codex auth token is unavailable以及 the gpt-5.6-sol model is not supported when using codex with a chatgpt account。這些報(bào)錯(cuò)對(duì)應(yīng)的問(wèn)題通常是三個(gè)第一配置文件路徑不對(duì)工具找不到 config.toml第二config.toml 里寫的模型名在當(dāng)前賬號(hào)或工具版本里不存在比如賬號(hào)沒(méi)有該模型權(quán)限但配置里硬寫了第三登錄令牌沒(méi)有正確保存工具啟動(dòng)時(shí)讀不到。處理方式很簡(jiǎn)單先確認(rèn)工具版本是最新的用內(nèi)置的檢查命令或設(shè)置頁(yè)查看安裝路徑然后打開(kāi) config.toml把 model 字段改成你賬號(hào)實(shí)際能訪問(wèn)的模型名如果提示 auth token unavailable就重新執(zhí)行工具的官方登錄流程再確認(rèn) token 文件沒(méi)有被殺毒軟件攔截、目錄權(quán)限是否正確。這類問(wèn)題九成是升級(jí)工具后舊配置沒(méi)同步導(dǎo)致的。4.4 常見(jiàn)報(bào)錯(cuò)速查表報(bào)錯(cuò)關(guān)鍵詞可能原因優(yōu)先操作sign-in could not be completed / token exchange failed登錄態(tài)過(guò)期、會(huì)話沖突或網(wǎng)絡(luò)出口變化退出賬號(hào)清理緩存重新登錄token endpoint returned status 403 forbidden: country賬號(hào)區(qū)域信息與使用環(huán)境不一致檢查賬號(hào)國(guó)家地區(qū)資料確保一致后重新登錄your access token could not be refreshed令牌過(guò)期且無(wú)法刷新立即注銷再登錄invalid refresh_token: empty string本地沒(méi)有寫入 refresh token檢查本地令牌存儲(chǔ)重走授權(quán)流程codex auth token is unavailable登錄令牌未保存或路徑不對(duì)執(zhí)行官方登錄命令檢查 token 文件路徑the gpt-5.6-sol model is not supported配置文件里的模型名無(wú)權(quán)限或不存在改 config.toml 中的 model 字段payment was not approved支付方式被拒絕核對(duì)卡信息、賬單地址或換支付方式chatgpt failed to start / unable to locate codex cli binary本地安裝不完整重新安裝客戶端檢查 PATH 環(huán)境變量這張表我建議收藏。多數(shù) token 報(bào)錯(cuò)并不是“模型壞了”而是登錄態(tài)、配置和版本之間的連鎖反應(yīng)。5. 算一筆 token 明白賬用量估算與控制5.1 在哪看真實(shí)的 token 用量API 用戶可以在官方用量面板里看到每天的實(shí)際 token 消耗包括按模型拆分的歷史趨勢(shì)這是最準(zhǔn)確的數(shù)據(jù)。如果你是網(wǎng)頁(yè)版普通用戶界面上一般不會(huì)直接顯示單輪 token 數(shù)字需要靠估算來(lái)判斷自己的用量水平。我平時(shí)會(huì)做一件很笨但有效的事在本地用一個(gè)文本統(tǒng)計(jì)小工具把每次主要任務(wù)輸入和輸出的字?jǐn)?shù)記錄下來(lái)再按照前面 1 token 約等于 0.5 到 0.75 個(gè)漢字的比例換算心里基本有數(shù)。5.2 常見(jiàn)任務(wù)的 token 估算不同任務(wù)之間的 token 消耗差距非常大我直接給幾個(gè)身邊朋友問(wèn)過(guò)很多次的估算寫一篇 2000 字的中文文章假設(shè)你給了一段 500 字的要求輸出 2000 字綜合換算后大約消耗 3000 到 4000 token。翻譯一份普通文件100 個(gè)漢字的翻譯輸入輸出合計(jì)大概 300 到 500 token一整份上萬(wàn)字的合同可能是幾萬(wàn) token。把游戲 Mod 網(wǎng)站或游戲內(nèi)文本漢化如果你有 10 萬(wàn)字的文本需要翻譯輸出本身就有 15 萬(wàn) token 上下加上術(shù)語(yǔ)表、對(duì)話上下文反復(fù)喂給模型實(shí)際消耗很容易到 30 萬(wàn)到 40 萬(wàn) token。這種規(guī)模的任務(wù)單純靠聊天窗口對(duì)話效率很低我最建議的做法是先整理術(shù)語(yǔ)表再分批投喂必要時(shí)用 RAG 把術(shù)語(yǔ)和上下文做成可檢索的片段。讓 AI 生成一份 PPT 框架輸入你的主題和需求加輸出大綱可能只需要 2000 到 5000 token但如果你要求它逐頁(yè)生成完整演講稿消耗會(huì)成倍上升。5.3 控制消耗的幾個(gè)習(xí)慣最后說(shuō)幾個(gè)控制 token 消耗的習(xí)慣。第一不要在對(duì)話里反復(fù)粘貼同一份大文檔需要長(zhǎng)期參考的固定信息應(yīng)放進(jìn)自定義指令或記憶里第二能用便宜模型做總結(jié)、分類、改寫就不要全用旗艦?zāi)Ｐ陀绕涫桥咳蝿?wù)成本能差很多倍第三長(zhǎng)文檔粘貼前先本地壓縮掉多余空行和無(wú)關(guān)信息第四連續(xù)多輪對(duì)話時(shí)盡量保持提示詞前綴穩(wěn)定這樣能利用到官方接口的 prompt 緩存機(jī)制命中緩存的那部分是打折收費(fèi)的。這些都做下來(lái)一個(gè)月省下的額度相當(dāng)可觀。我見(jiàn)過(guò)有人一個(gè)月消耗幾百萬(wàn) token也有人用同樣功能一個(gè)月只花零頭差別不在能力而在習(xí)慣。我個(gè)人在實(shí)際操作中最深刻的體會(huì)是不要總想著去搞“無(wú)限 token”那是和物理規(guī)律對(duì)抗。把 token 理解成工作記憶加錢的合體然后老老實(shí)實(shí)去學(xué)會(huì)整理上下文——用不用得上這都會(huì)是你以后離不開(kāi)的技能。從這周開(kāi)始試著給每一次長(zhǎng)篇對(duì)話做一次摘要存檔你慢慢就會(huì)明白夠用的、能被管理的 token比虛標(biāo)的“無(wú)限”實(shí)在得多。