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