1. 從 1.4 萬 Token 到 200 Token一次提示詞瘦身的真實動機第一次看到自己月度 Token 賬單的時候我盯著那個數(shù)字看了很久一度以為是統(tǒng)計口徑出了問題。反復(fù)核對了幾次調(diào)用日志之后才確認問題不在統(tǒng)計而在我自己寫的系統(tǒng)提示詞上。那份提示詞從項目第一天開始就不斷往里加?xùn)|西今天補一條格式約束明天加一段角色設(shè)定后天又塞進去幾個示例對話半年下來膨脹到一萬四千多個 Token。每次請求都要把這坨東西完整發(fā)一遍哪怕用戶只是問一句幫我改個變量名。這件事的荒誕之處在于我花在優(yōu)化業(yè)務(wù)邏輯上的時間遠不如花在給提示詞打補丁上的時間多。而真正吃掉成本的恰恰是這些補丁本身。后來我把整套系統(tǒng)遷移到一個更輕的提示詞架構(gòu)上最終穩(wěn)定在兩百個 Token 左右賬單直接降了八成五。這個過程踩了不少坑也推翻了很多我原本以為理所當(dāng)然的做法值得完整記錄一遍。這篇文章面向的是已經(jīng)在用大模型做產(chǎn)品、或者正在搭建 AI 應(yīng)用的開發(fā)者。如果你手上有一份越寫越長的系統(tǒng)提示詞每次改動都提心吊膽怕影響其他功能或者你單純被 Token 成本壓得喘不過氣那接下來的內(nèi)容應(yīng)該能幫你省下不少錢和精力。我會把整個遷移思路、提示詞重構(gòu)方法、參數(shù)取舍邏輯、以及實際踩過的坑都攤開講盡量做到你照著做就能復(fù)現(xiàn)。需要先說明一點這里說的遷移不是簡單換個模型接口那么簡單而是整套提示詞設(shè)計哲學(xué)的轉(zhuǎn)變。從把所有規(guī)則都寫死在系統(tǒng)提示里轉(zhuǎn)向用最少的約束撬動模型自身的能力。這個轉(zhuǎn)變聽起來抽象但落到具體操作上非常實在每一步都有明確的判斷標準。2. 為什么系統(tǒng)提示詞會膨脹到失控2.1 提示詞膨脹的典型路徑幾乎每一個從零開始做 AI 應(yīng)用的團隊都會經(jīng)歷同樣的膨脹曲線。我把這個過程拆成四個階段你可以對照看看自己走到哪一步了。第一階段是角色設(shè)定期。剛開始你只需要模型扮演一個助手寫一句你是一個專業(yè)的編程助手就夠了。這時候提示詞可能只有幾十個 Token。第二階段是格式約束期。你發(fā)現(xiàn)模型輸出格式不穩(wěn)定有時候用 Markdown有時候用純文本于是你開始加規(guī)則必須用代碼塊包裹代碼、必須用列表組織步驟、必須標注文件路徑。規(guī)則一條條加上去提示詞漲到幾百 Token。第三階段是邊界防御期。線上出了幾次事故模型回答了不該回答的問題或者生成了有風(fēng)險的代碼于是你開始加各種不要做某事的約束。每出一次問題就加一條提示詞漲到幾千 Token。第四階段是示例堆砌期。你發(fā)現(xiàn)光靠規(guī)則描述模型還是理解不到位于是開始塞示例對話。一個示例動輒幾百 Token塞三五個就上千了。到這一步提示詞已經(jīng)徹底失控。我自己的項目就是完整走完了這四個階段。最夸張的時候系統(tǒng)提示詞里同時存在十七條不要開頭的約束還有四組完整的示例對話。每次請求光系統(tǒng)提示就消耗一萬四千 Token而用戶的實際問題往往只有幾十個 Token。這個比例嚴重失衡。2.2 膨脹背后的三個認知誤區(qū)提示詞之所以會失控根源在于三個很常見的認知誤區(qū)我自己全都踩過。第一個誤區(qū)是規(guī)則越多越安全。很多人覺得只要把所有可能出問題的情況都寫成規(guī)則模型就不會犯錯。但實際情況恰恰相反。規(guī)則越多模型在生成時需要在更多約束之間做權(quán)衡反而容易出現(xiàn)顧此失彼的情況。而且大量規(guī)則之間存在潛在沖突模型不知道該優(yōu)先遵守哪一條輸出質(zhì)量會明顯下降。第二個誤區(qū)是示例比描述有效。這個說法在少量示例時成立但示例的邊際收益遞減得非?？?。第一個示例能顯著提升理解準確度第二個示例提升有限到第三個第四個基本就是浪費 Token 了。更麻煩的是示例會錨定模型的輸出風(fēng)格如果示例本身寫得不夠好反而會把模型帶偏。第三個誤區(qū)是系統(tǒng)提示是免費的。很多人潛意識里覺得系統(tǒng)提示寫一次就固定了不像用戶輸入那樣每次都變所以不太在意它的長度。但實際上系統(tǒng)提示是每次請求都要完整傳輸?shù)乃某杀臼浅艘哉埱蟠螖?shù)的。一個一萬四千 Token 的系統(tǒng)提示如果每天有一萬次請求光系統(tǒng)提示這一項每天就要消耗一億四千萬 Token。這個數(shù)字算出來的時候我自己都嚇了一跳。2.3 成本賬到底怎么算我們來做一道具體的算術(shù)題這樣你對成本結(jié)構(gòu)會有更直觀的感受。假設(shè)你的應(yīng)用每天處理一萬次請求平均每次用戶輸入加輸出是五百 Token系統(tǒng)提示是一萬四千 Token。那么單次請求的總 Token 消耗是一萬四千五百 Token其中系統(tǒng)提示占比高達百分之九十六點五。按主流模型的定價粗略估算輸入 Token 的成本雖然比輸出低但架不住量大。一天下來系統(tǒng)提示消耗的 Token 是一億四千萬而真正有價值的用戶交互內(nèi)容只有五百萬。也就是說你花的錢里有九成以上是在重復(fù)傳輸同一份固定文本。如果把系統(tǒng)提示壓縮到兩百 Token單次請求總消耗降到七百 Token整體成本直接降到原來的百分之四點八也就是降了九成五以上。即便考慮到壓縮后可能需要更精細的調(diào)用策略實際降幅也能穩(wěn)定在八成五左右。這就是標題里那個數(shù)字的來源它不是拍腦袋寫的是實打?qū)嵥愠鰜淼?。提示在動手?yōu)化之前先把你最近一周的調(diào)用日志拉出來統(tǒng)計系統(tǒng)提示 Token 占總 Token 的比例。如果這個比例超過百分之五十那優(yōu)化空間就非常大值得投入時間重構(gòu)。3. 提示詞瘦身的核心思路從寫規(guī)則到給結(jié)構(gòu)3.1 一個關(guān)鍵判斷模型能力已經(jīng)變了很多人提示詞寫得又長又細是因為他們的大腦還停留在早期模型的水平上。早期模型理解能力弱你必須把話說得非常死它才能照做。但現(xiàn)在的模型在指令遵循、格式控制、上下文理解上都有了質(zhì)的飛躍很多以前必須寫死的規(guī)則現(xiàn)在模型自己就能處理好。我做過一個對比實驗。同一組任務(wù)一份提示詞寫滿了格式約束和邊界防御另一份只寫核心目標。結(jié)果在現(xiàn)在的模型上兩份提示詞的輸出質(zhì)量差異微乎其微但 Token 消耗差了七十倍。這個實驗讓我徹底改變了對提示詞長度的執(zhí)念。所以瘦身的第一步不是急著刪規(guī)則而是先做減法實驗把某條規(guī)則刪掉跑一批測試用例看輸出質(zhì)量有沒有下降。如果沒有下降說明這條規(guī)則是冗余的模型自己能處理。逐條驗證下來你會發(fā)現(xiàn)大部分規(guī)則其實都可以刪。3.2 結(jié)構(gòu)化的兩百 Token 長什么樣瘦身不是簡單地把長提示詞砍短而是重新設(shè)計信息結(jié)構(gòu)。我最終穩(wěn)定下來的兩百 Token 提示詞大致包含四個部分每部分都極其精簡。第一部分是身份錨點一句話說明模型扮演什么角色大概二十個 Token。第二部分是核心任務(wù)說明這次交互要達成什么目標大概五十個 Token。第三部分是輸出契約只保留最關(guān)鍵的格式要求比如代碼用代碼塊包裹大概三十個 Token。第四部分是動態(tài)注入?yún)^(qū)把原本寫死在系統(tǒng)提示里的上下文信息改成按需注入這部分根據(jù)實際情況變化平均一百個 Token。關(guān)鍵在于第四部分的設(shè)計。原本我把項目結(jié)構(gòu)、技術(shù)棧、代碼規(guī)范全都寫死在系統(tǒng)提示里但其實每次請求真正需要的上下文只是其中一小部分。改成動態(tài)注入后系統(tǒng)提示只保留最通用的框架具體上下文由調(diào)用方根據(jù)當(dāng)前任務(wù)拼裝。這樣既保證了信息完整又避免了每次傳輸無關(guān)內(nèi)容。3.3 動態(tài)注入的三種實現(xiàn)方式動態(tài)注入聽起來簡單但落地時有幾種不同的實現(xiàn)方式各有適用場景。第一種是檢索式注入。把項目相關(guān)的所有信息切片存進向量庫每次請求時根據(jù)用戶問題檢索最相關(guān)的幾個片段注入。這種方式適合知識庫類應(yīng)用信息量大且分散的場景。第二種是模板式注入。預(yù)先定義幾種任務(wù)模板每種模板對應(yīng)一套固定的上下文注入方案。比如代碼修改模板注入文件路徑和函數(shù)簽名代碼解釋模板注入完整函數(shù)體。這種方式適合任務(wù)類型明確的場景實現(xiàn)簡單且可控。第三種是分層式注入。把上下文分成必選層和可選層必選層每次都注入可選層根據(jù)任務(wù)復(fù)雜度決定是否注入。這種方式適合上下文重要性差異明顯的場景。我自己的項目用的是模板式注入因為任務(wù)類型比較固定實現(xiàn)成本最低。實測下來平均每次注入的上下文在一百 Token 左右比原來寫死的一萬四千 Token 少了兩個數(shù)量級。4. 實操一步步把提示詞從一萬四砍到兩百4.1 第一步給現(xiàn)有提示詞做體檢動手刪之前先要搞清楚現(xiàn)有提示詞里到底有什么。我的做法是把系統(tǒng)提示詞按段落拆開逐段標注它的作用、使用頻率、以及刪除后的風(fēng)險等級。具體操作是建一張表格三列分別是段落內(nèi)容摘要這條規(guī)則最近一個月觸發(fā)過幾次刪掉后可能出什么問題。觸發(fā)次數(shù)這一列很關(guān)鍵很多規(guī)則寫進去之后就再也沒起過作用屬于典型的僵尸規(guī)則。我自己的提示詞體檢結(jié)果是十七條不要約束里有十一條在過去一個月里從未觸發(fā)過四組示例對話里有兩組和實際任務(wù)場景根本不匹配還有一大段項目背景介紹其實每次請求都用不到。光這三項加起來就占了八千多 Token。注意體檢時不要憑印象判斷一定要拉真實日志統(tǒng)計。我原本以為某條格式約束很重要結(jié)果統(tǒng)計發(fā)現(xiàn)它觸發(fā)率不到百分之一刪掉之后輸出質(zhì)量沒有任何變化。4.2 第二步把規(guī)則翻譯成契約刪規(guī)則不能一刀切有些規(guī)則確實重要但可以用更省 Token 的方式表達。核心技巧是把過程性規(guī)則翻譯成結(jié)果性契約。舉個例子。原來我寫了五條規(guī)則來描述代碼輸出的格式要求必須用代碼塊、必須標注語言、必須在代碼前說明修改點、必須在代碼后說明影響范圍、必須保持縮進一致。這五條加起來一百多 Token。翻譯成契約之后只需要一句話輸出格式修改說明 代碼塊標注語言 影響范圍。同樣三十個 Token 左右但表達的是最終結(jié)果要求而不是過程步驟。模型理解結(jié)果性契約的能力比理解過程性規(guī)則更強因為它不需要在腦子里模擬執(zhí)行步驟。這個翻譯過程需要反復(fù)打磨。我的經(jīng)驗是每一條規(guī)則都問自己一句我真正想要的結(jié)果是什么然后直接把這個結(jié)果寫出來而不是寫達成結(jié)果的步驟。4.3 第三步示例對話的取舍標準示例對話是 Token 大戶但完全刪掉又可能影響輸出風(fēng)格。我的取舍標準是只保留一個最能代表核心任務(wù)的示例且這個示例必須極度精簡。精簡示例的關(guān)鍵是去掉所有非必要信息。原來我的示例對話里包含了完整的用戶提問、完整的模型思考過程、完整的輸出結(jié)果一組下來三百多 Token。精簡后只保留輸入要點 輸出骨架一組壓縮到五十 Token 以內(nèi)。另外示例的位置也很重要。放在系統(tǒng)提示末尾的示例模型參考時權(quán)重更高。所以如果只保留一個示例就把它放在最后。如果保留兩個把最重要的放最后。實測下來從四組示例精簡到一組輸出風(fēng)格的一致性沒有明顯下降但 Token 省了將近一千。這個投入產(chǎn)出比非常高。4.4 第四步建立動態(tài)注入的調(diào)用規(guī)范系統(tǒng)提示瘦身之后上下文信息改由調(diào)用方注入這就需要建立一套調(diào)用規(guī)范否則每個調(diào)用點各寫各的很快就會重新失控。我的做法是定義一個注入模板函數(shù)所有調(diào)用都必須通過這個函數(shù)生成上下文。函數(shù)內(nèi)部根據(jù)任務(wù)類型選擇注入內(nèi)容并做長度截斷保護。這樣即使某個調(diào)用點想注入大量上下文也會被函數(shù)截斷不會污染系統(tǒng)提示。模板函數(shù)的核心邏輯大概是這樣的def build_context(task_type, payload): templates { code_edit: lambda p: f文件{p[file]}\n函數(shù){p[func]}, code_explain: lambda p: f代碼\n{p[code][:800]}, general: lambda p: p.get(summary, )[:200], } builder templates.get(task_type, templates[general]) return builder(payload)這段代碼的關(guān)鍵在于每個模板都有長度上限比如代碼解釋最多注入八百字符通用任務(wù)最多兩百字符。這個上限是根據(jù)實測效果定的超過之后模型的理解準確度不再提升純屬浪費。4.5 第五步灰度驗證與回滾預(yù)案提示詞改動最怕的是線上出問題所以一定要灰度驗證。我的做法是保留新舊兩套提示詞按流量比例分流同時記錄兩套的輸出質(zhì)量和 Token 消耗?；叶绕陂g重點看三個指標任務(wù)成功率、輸出格式合規(guī)率、平均 Token 消耗。前兩個指標不能下降第三個指標要明顯下降。如果前兩個指標有下降立刻回滾分析是哪條規(guī)則刪錯了。我自己的灰度跑了一周前三天新舊各百分之五十后四天新提示詞百分之百。最終數(shù)據(jù)是任務(wù)成功率持平格式合規(guī)率略升Token 消耗降了百分之八十七。這個結(jié)果比我預(yù)期的還要好。5. 遷移過程中踩過的坑與排查實錄5.1 坑一刪規(guī)則刪過頭導(dǎo)致格式崩壞最開始我信心滿滿一口氣刪掉了所有格式約束結(jié)果模型輸出變得非常隨意有時候用 Markdown有時候用純文本代碼塊也時有時無。下游解析程序直接報錯。排查之后發(fā)現(xiàn)格式約束雖然大部分可以刪但代碼必須用代碼塊包裹這一條是下游解析的硬依賴不能刪。教訓(xùn)是刪規(guī)則之前先確認哪些規(guī)則是下游系統(tǒng)的硬依賴這些必須保留。5.2 坑二動態(tài)注入的上下文順序影響理解動態(tài)注入上線后我發(fā)現(xiàn)模型對上下文的利用效率時好時壞。后來對比日志才發(fā)現(xiàn)注入內(nèi)容的順序會影響模型理解。把最相關(guān)的信息放在最前面模型利用率明顯更高。調(diào)整之后我在注入模板里加了一條規(guī)則按相關(guān)性降序排列注入內(nèi)容。這個改動很小但效果立竿見影。5.3 坑三Token 統(tǒng)計口徑不一致導(dǎo)致誤判優(yōu)化過程中我一度以為 Token 沒降下來排查了半天才發(fā)現(xiàn)是統(tǒng)計口徑問題。有的統(tǒng)計工具把系統(tǒng)提示和用戶輸入分開算有的合并算。我一開始看的是分開算的數(shù)據(jù)誤以為系統(tǒng)提示沒降。后來統(tǒng)一了口徑把所有輸入 Token 合并統(tǒng)計才看到真實的降幅。這個坑提醒我做優(yōu)化之前一定要先確認度量標準否則容易白忙活。5.4 常見問題速查表問題現(xiàn)象可能原因排查方向解決方法輸出格式不穩(wěn)定格式契約寫得太模糊檢查輸出契約部分用結(jié)果性描述替代過程性規(guī)則上下文利用率低注入順序不合理對比不同順序的效果按相關(guān)性降序排列Token 降幅不明顯統(tǒng)計口徑不一致確認統(tǒng)計工具口徑統(tǒng)一為合并統(tǒng)計任務(wù)成功率下降刪掉了關(guān)鍵規(guī)則逐條回滾驗證保留下游硬依賴規(guī)則輸出風(fēng)格漂移示例被刪太多檢查示例保留情況保留一個核心示例放末尾5.5 獨家避坑技巧分享幾個文檔里不會寫、但實際很有用的技巧。第一個是規(guī)則觸發(fā)日志。給每條規(guī)則加一個隱式標記模型觸發(fā)這條規(guī)則時在日志里留痕。跑一周之后觸發(fā)率為零的規(guī)則直接刪。這個技巧能幫你精準識別僵尸規(guī)則。第二個是提示詞版本對照。每次改動提示詞都存一個版本記錄改動內(nèi)容和對應(yīng)的效果指標。出問題時可以快速定位是哪次改動導(dǎo)致的。我用一個簡單的表格管理成本很低但收益很大。第三個是極端用例回歸。準備一組極端用例比如超長輸入、空輸入、多語言混合輸入每次改提示詞都跑一遍。這些用例能暴露大部分邊界問題。6. 遷移后的效果與可復(fù)用的經(jīng)驗6.1 實際數(shù)據(jù)對比遷移前后的核心數(shù)據(jù)對比大致是這樣的。系統(tǒng)提示 Token 從一萬四千降到兩百降幅百分之九十八點六。單次請求總 Token 從一萬四千五百降到七百降幅百分之九十五點二。月度賬單降幅百分之八十五之所以沒有 Token 降幅那么大是因為遷移后調(diào)用頻次有所上升部分節(jié)省被新增調(diào)用抵消了。輸出質(zhì)量方面任務(wù)成功率持平格式合規(guī)率從百分之九十二提升到百分之九十六主要得益于輸出契約比原來的過程性規(guī)則更清晰。響應(yīng)延遲也有改善因為輸入 Token 少了模型處理時間相應(yīng)縮短。6.2 哪些場景適合這套方法這套方法不是萬能的它有明確的適用邊界。適合的場景是任務(wù)類型相對固定、輸出格式有明確要求、上下文信息可以結(jié)構(gòu)化拆分的應(yīng)用。比如代碼助手、客服機器人、內(nèi)容生成工具。不太適合的場景是任務(wù)高度開放、需要大量領(lǐng)域知識注入、或者對輸出風(fēng)格有極其精細要求的應(yīng)用。這類場景可能需要保留更多上下文瘦身空間有限。判斷標準很簡單如果你的系統(tǒng)提示里超過一半的內(nèi)容是通用規(guī)則而非領(lǐng)域知識那瘦身空間就很大。6.3 后續(xù)可以繼續(xù)優(yōu)化的方向提示詞瘦身只是成本優(yōu)化的第一步。后續(xù)還可以從幾個方向繼續(xù)挖潛。一是緩存策略。對于重復(fù)性高的請求把模型輸出緩存起來直接返回緩存結(jié)果連模型都不用調(diào)。這個對客服類應(yīng)用效果特別明顯。二是模型分級。簡單任務(wù)用輕量模型復(fù)雜任務(wù)用重量模型按需分配。很多請求其實用輕量模型就夠了沒必要都走重量模型。三是批處理。把多個小請求合并成一個大請求減少請求次數(shù)攤薄系統(tǒng)提示的固定開銷。這個對批量處理場景很有效。6.4 我個人的幾點體會最后分享幾點我自己的真實體會不一定對所有人適用但都是我踩過坑之后總結(jié)出來的。第一提示詞的長度和效果沒有正相關(guān)。我見過太多人把提示詞寫得像說明書結(jié)果效果還不如一句精準的指令。寫提示詞的核心是精準不是全面。第二優(yōu)化之前先量化。沒有數(shù)據(jù)支撐的優(yōu)化都是瞎猜?；ò胩鞎r間搭個統(tǒng)計比花三天時間憑感覺改提示詞有用得多。第三改動要小步快跑。一次改一條規(guī)則驗證效果后再改下一條。一次性大改雖然爽但出問題時根本不知道是哪條改錯了。第四別怕刪。大部分提示詞里的規(guī)則都是冗余的刪掉之后你會發(fā)現(xiàn)模型比你想的聰明得多。真正需要保留的規(guī)則往往是那些和下游系統(tǒng)強耦合的硬約束而不是那些我覺得模型可能做不好的軟約束。這套方法我后來又用在兩個新項目上效果同樣明顯。其中一個項目的系統(tǒng)提示從八千 Token 壓到一百五十 Token賬單降了八成。另一個項目因為領(lǐng)域知識較多只壓到八百 Token但賬單也降了六成。所以具體能壓到多少取決于你的任務(wù)類型但只要有優(yōu)化意識總能找到空間。