說個(gè)可能不少人都有過的體驗(yàn)同一個(gè) AI 工具上一輪還在寫代碼下一輪突然讓它幫忙潤色一段市場文案結(jié)果它一邊寫著文案一邊忍不住給你補(bǔ)了一行 if 判斷或者明明已經(jīng)切換了話題它還在執(zhí)著地引用上一個(gè)項(xiàng)目里的舊事。問題通常不出在模型能力上而是出在“上下文”沒有被好好管理。我最近一直在折騰的context-mode上下文模式就是專門解決這個(gè)事的它不是某個(gè)神秘插件而是一套根據(jù)任務(wù)自動切換記憶范圍、提示詞和參考資源的機(jī)制。這篇文章我會把它的設(shè)計(jì)思路、配置方法、踩坑記錄一次講透適合那些重度使用 AI 寫代碼、寫文檔、做分析的人也適合想自己動手給已有工具加上下文管理能力的人。1. 項(xiàng)目概述與核心需求解析1.1 context-mode 到底是什么context-mode 拆開看就是“上下文”加“模式”。在實(shí)際使用中它既可以指某個(gè)產(chǎn)品或工具里已經(jīng)內(nèi)置好的上下文模式開關(guān)也可以指我們自己設(shè)計(jì)的一套上下文組織方案。無論哪種核心邏輯都一樣給 AI 指定當(dāng)前應(yīng)該以哪種“記憶和注意力”的方式工作。我自己的定義更樸素這是一個(gè)“決定把哪些信息擺到桌面上、哪些信息收進(jìn)抽屜里”的開關(guān)。比如在編程場景里A 模式只讓 AI 關(guān)注當(dāng)前模塊的代碼和需求B 模式讓 AI 掌握整個(gè)倉庫的結(jié)構(gòu)再做判斷。兩個(gè)模式用的是同一個(gè)模型但表現(xiàn)出來的專業(yè)度和穩(wěn)定性完全不同。這里想強(qiáng)調(diào)一個(gè)容易被忽略的點(diǎn)context-mode 不只是“記憶多和少的區(qū)別”。它還包括系統(tǒng)提示詞、引用文件、知識庫檢索范圍、歷史對話保留策略等一整套配置。很多人以為上下文就是聊天記錄其實(shí)聊天記錄只是最表層的一層。真正的上下文管理是把模型能看到的全部信息按任務(wù)意圖重新編排。1.2 為什么需要給 AI 劃分上下文模式先說個(gè)最直觀的問題上下文污染。我自己做過一個(gè)實(shí)驗(yàn)在同一個(gè)會話里先讓它幫我梳理后端接口文檔再讓它給前端寫頁面。結(jié)果它在寫前端代碼時(shí)反復(fù)引用后端 API 里的字段名來解釋頁面上并不存在的報(bào)錯(cuò)。原因很好理解——AI 不知道你已經(jīng)切換任務(wù)了它只看到這個(gè)會話里所有歷史信息都是“線索”。另一個(gè)問題是 token 資源浪費(fèi)。上下文窗口再大也有上限而且越長的上下文意味著更長的推理時(shí)間和更高的調(diào)用成本。如果每次對話都把所有資料、所有歷史記錄全塞進(jìn)去不僅慢而且貴更重要的是效果未必好。業(yè)界常說“l(fā)ost in the middle”意思是模型對長上下文中部位置的信息記憶最模糊。你辛辛苦苦塞進(jìn)去的資料它可能壓根沒“看進(jìn)去”。所以我做 context-mode 的核心目標(biāo)有三個(gè)一是隔離任務(wù)避免不同任務(wù)之間的信息串?dāng)_二是控制成本按需攜帶上下文而不是多多益善三是在有限上下文里提高信號密度讓 AI 更容易抓到真正重要的信息。1.3 哪些人最適合用這套方案先說第一類每天和 AI 編程助手打交道的人。一個(gè) workspace 下可能同時(shí)維護(hù)著好幾個(gè)項(xiàng)目如果項(xiàng)目背景、技術(shù)棧、目錄結(jié)構(gòu)都能根據(jù)當(dāng)前任務(wù)切換著來效果會立竿見影。第二類是內(nèi)容創(chuàng)作者。寫長文的時(shí)候既要參考大量資料又要保持統(tǒng)一的寫作風(fēng)格還要隨時(shí)照顧到已經(jīng)寫好的章節(jié)不同階段需要的上下文完全不是一回事。前期調(diào)研、大綱擬定、正文寫作、校對潤色拆成四個(gè)模式之后AI 的輸出質(zhì)量會有肉眼可見的提升。第三類是數(shù)據(jù)分析師或知識庫使用者。讓 AI 處理數(shù)據(jù)時(shí)最怕它憑空猜測字段含義。如果有一個(gè)模式能按需掛載數(shù)據(jù)字典、表結(jié)構(gòu)、業(yè)務(wù)口徑它給出的答案就會準(zhǔn)確得多。我自己做知識庫問答工具的時(shí)候也把 context-mode 當(dāng)作默認(rèn)功能來設(shè)計(jì)效果比單純堆 prompt 穩(wěn)定太多了。2. 整體設(shè)計(jì)與方案選型2.1 為什么“一個(gè)上下文打天下”行不通我早期也走過彎路覺得只要把上下文塞滿模型就一定更聰明。事實(shí)證明上下文不是越多越好。它就像一個(gè)堆滿文件的辦公桌你讓同事模型幫你找東西桌上全是亂七八糟的紙張它反而不知道該先看哪一張。上下文過載會引發(fā)三個(gè)典型副作用。第一是注意力稀釋模型對每個(gè)信息的重視程度都下降了因?yàn)樾畔⒅g互相競爭。第二是沖突概率上升舊的上下文和新指令如果存在隱含矛盾模型會傾向于折中或者采用舊邏輯導(dǎo)致新任務(wù)的執(zhí)行走樣。第三是性能劣化每次請求傳幾十萬字進(jìn)去響應(yīng)時(shí)間肉眼可見變長再加上費(fèi)用問題長期用下來很難受。所以正確的思路是分層把上下文分成“什么情況下都必須存在的基線信息”和“只有特定任務(wù)下才需要裝載的臨時(shí)信息”。context-mode 就是這兩種信息之間的調(diào)度開關(guān)。開關(guān)撥到哪一檔決定模型當(dāng)前主要依據(jù)什么來思考。2.2 三種主流的 context-mode 實(shí)現(xiàn)思路我整理過自己在不同工具和項(xiàng)目中見過的實(shí)現(xiàn)方式大致可以歸成三類。第一類是按“記憶范圍”分檔。典型的分法有嚴(yán)格模式、平衡模式、長會話模式。嚴(yán)格模式只保留最近幾輪對話或只關(guān)注當(dāng)前輸入平衡模式保留最近幾十輪對話長會話模式則盡可能多地保留歷史。這類實(shí)現(xiàn)的優(yōu)點(diǎn)是簡單直接適合純對話場景缺點(diǎn)是沒有對信息內(nèi)容做區(qū)分只能控制“多少”不能控制“什么”。第二類是按“任務(wù)角色”分檔。比如編程模式、寫作模式、閱讀模式、分析模式。每個(gè)模式對應(yīng)一套系統(tǒng)提示詞一套參考文件清單一類特定的行為約束。這是我最常用也最推薦的方式因?yàn)樗娴陌选安煌蝿?wù)需要不同信息”這個(gè)需求落到了實(shí)處。第三類是按“上下文來源”分檔。比如只使用對話歷史、只使用用戶主動掛載的文件、自動從知識庫檢索相關(guān)內(nèi)容。這個(gè)方式適合信息量巨大、無法靠手工指定文件的項(xiàng)目本質(zhì)上是把上下文管理交給了檢索系統(tǒng)。三類思路并不是互斥關(guān)系。成熟一點(diǎn)的設(shè)計(jì)通常是以“任務(wù)角色”為主框架嵌套“記憶范圍”和“信息來源”作為子參數(shù)。我自己搭的方案就是這樣的選一個(gè)主模式確定“我是誰”再配合輪數(shù)和引用范圍控制“我記得多少”。2.3 從代碼層面看 context-mode 的調(diào)度機(jī)制如果要在自己的工具里實(shí)現(xiàn) context-mode本質(zhì)上是做一件事在每次發(fā)起請求之前根據(jù)當(dāng)前模式重新組裝 messages。這并不復(fù)雜但有一個(gè)關(guān)鍵點(diǎn)需要注意——組裝順序直接影響最終效果。我通常用這種結(jié)構(gòu)來組織固定層系統(tǒng)提示詞描述全局角色和底線規(guī)則不隨模式變化。模式層當(dāng)前模式的專屬指令包括任務(wù)目標(biāo)、輸出格式、注意事項(xiàng)。資料層當(dāng)前模式需要參考的文檔內(nèi)容或知識庫檢索結(jié)果。對話層按模式設(shè)定過濾后的歷史消息。這里面的“過濾”比很多人想象中更重要。切換模式的時(shí)候如果只是把系統(tǒng)提示詞換掉但是歷史消息一條不少地全部保留那舊任務(wù)的信息仍然會干擾新任務(wù)。所以一個(gè)合格的 context-mode 實(shí)現(xiàn)在切換模式時(shí)還應(yīng)該把上一輪對話歷史一并清理或降權(quán)。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 上下文分層的黃金結(jié)構(gòu)長什么樣我打磨了很久之后把上下文拆成了三個(gè)明確的層級用久了你會發(fā)現(xiàn)這套結(jié)構(gòu)既好用又好調(diào)。第一層是穩(wěn)定身份層占比建議控制在 10% 到 15%。這一層回答“你是什么角色、你的底層原則是什么”。比如“你是一個(gè)嚴(yán)謹(jǐn)?shù)能浖こ處熕谢卮鸨仨毣谧C據(jù)”這類話放在這一層。這一層的作用是給整個(gè)會話定調(diào)也是切換模式時(shí)唯一保留不變的部分。第二層是場景任務(wù)層占比建議在 30% 到 40%。這一層回答“這次會話我們具體要干什么”。包括項(xiàng)目背景、當(dāng)前目標(biāo)、輸入輸出格式、約束條件。模式切換時(shí)這一層必須整體替換因?yàn)檫@是區(qū)分 mode 的核心。第三層是即時(shí)信息層占比大概 50%。包括當(dāng)前的用戶輸入、最近的對話記錄、臨時(shí)掛載的參考內(nèi)容。這一層的特點(diǎn)是變動最頻繁在切換模式時(shí)通常需要重置或大幅壓縮。我為什么反復(fù)強(qiáng)調(diào)這個(gè)比例因?yàn)楸壤Ш馐呛芏?context-mode 配置效果不佳的根源。穩(wěn)定身份層太短模型容易跟著用戶話題到處跑場景任務(wù)層太長模型會陷入對背景的復(fù)述而忽略實(shí)際要解決的問題即時(shí)信息層過多又會讓模型被瑣碎信息牽著走。3.2 必須配置的三個(gè)關(guān)鍵參數(shù)在我自己的實(shí)踐里有三個(gè)參數(shù)是最先要確定的它們基本決定了整個(gè)模式的行為邊界。第一個(gè)參數(shù)是context_scope也就是對話保留范圍。這個(gè)參數(shù)可以取值 like “僅當(dāng)前”、“最近 20 輪”、“全部歷史”。我一般默認(rèn)設(shè)成“最近 20 輪”因?yàn)槌^這個(gè)范圍的對話信息密度已經(jīng)很低了留著只會增加干擾。只有在需要連續(xù)推理長任務(wù)的場景里才會調(diào)到“全部歷史”。第二個(gè)參數(shù)是reference_files也就是參考文件清單。這個(gè)參數(shù)是個(gè)列表告訴模型當(dāng)前模式下應(yīng)該讀取哪些外部文檔。很多人把這個(gè)參數(shù)當(dāng)成一個(gè)可以無限加的倉庫這是個(gè)誤區(qū)。參考文件的價(jià)值在于“精準(zhǔn)”不在于“全面”。一個(gè) 3000 行的文檔全塞進(jìn)去不如你提前提煉出核心規(guī)則后再塞進(jìn)去。第三個(gè)參數(shù)是inject_mode代表內(nèi)容注入方式。它可以注入到系統(tǒng)提示詞里也可以作為上下文前綴還可以在每次對話時(shí)動態(tài)追加。這三者的區(qū)別在于優(yōu)先級和生效范圍。注入系統(tǒng)提示詞的內(nèi)容約束力最強(qiáng)適合放規(guī)則作為上下文前綴的內(nèi)容容易被后續(xù)指令覆蓋適合放背景說明。我用一個(gè)表格來總結(jié)這三個(gè)參數(shù)的區(qū)別方便對照參數(shù)作用建議默認(rèn)值典型誤用context_scope控制歷史對話保留量最近 20 輪盲目設(shè)置全部歷史reference_files控制外部文檔引用任務(wù)相關(guān) 3-5 個(gè)文件塞入整個(gè)項(xiàng)目完整代碼inject_mode控制內(nèi)容注入位置與優(yōu)先級system全部內(nèi)容都堆在對話層3.3 一套可以直接抄的 prompt 組織模板設(shè)計(jì) context-mode 的時(shí)候最忌諱的是想到哪寫到哪沒有固定格式。我自己固定使用下面這個(gè)模板實(shí)測下來穩(wěn)定性很高。[系統(tǒng)層] 你是[角色名稱]你的核心原則是[原則 1][原則 2]。 [模式層] 當(dāng)前模式寫入或粘貼具體模式名 任務(wù)目標(biāo)一句話說清本次會話要解決什么 背景信息簡要交代項(xiàng)目或任務(wù)所處環(huán)境 輸出要求寫明格式、長度、風(fēng)格等 禁忌事項(xiàng)列出模型不應(yīng)該做的事 [即時(shí)層] 當(dāng)前用戶需求這里的核心技巧是“模式層”的寫法。模式層不需要寫太長但要寫得非常具體。比如“任務(wù)目標(biāo)”不要寫“幫我寫代碼”而要寫“為登錄模塊新增基于 token 的會話保持邏輯只改 service 層和 controller 層不修改數(shù)據(jù)庫結(jié)構(gòu)”。信息越具體模型的注意力越集中。切換模式的時(shí)候我會保留系統(tǒng)層不變整體替換模式層同時(shí)清空或壓縮即時(shí)層的舊內(nèi)容。這一步我之前經(jīng)常漏掉后來發(fā)現(xiàn)只要舊內(nèi)容還在模型就很容易被拽回上一個(gè)模式的世界觀里。3.4 實(shí)操中最容易犯的三個(gè)禁忌第一不要把歷史記憶范圍設(shè)成“全部歷史”。我踩過這個(gè)坑在分析一個(gè)項(xiàng)目的時(shí)候圖省事直接把幾十輪討論全喂進(jìn)去。結(jié)果是模型在一開始還能保持模式狀態(tài)聊到后面就開始把早期的臨時(shí)方案當(dāng)成最終結(jié)論越答越偏。第二不要在切換模式之后立刻問復(fù)雜問題。切換之后模型需要時(shí)間適應(yīng)新的體系最好先讓它復(fù)述一遍模式目標(biāo)比如問一句“請確認(rèn)你現(xiàn)在的工作模式以及本次要完成的任務(wù)”確認(rèn)正常后再進(jìn)入正式問題。這一步看似多余但能攔截掉至少一半的串味。第三不要頻繁切換模式而不清理上下文。每次切換都會有信息殘留殘留多了模式邊界就模糊了。我的做法是每次切換模式前先手動清理一輪敏感歷史或者簡單粗暴地新開一個(gè)會話再把必要的背景信息復(fù)制進(jìn)去效果往往比在同一個(gè)會話里反復(fù)切換更好。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 場景復(fù)現(xiàn)從零搭一個(gè)三檔 context-mode下面我用一個(gè)具體的例子來演示完整落地方案。假設(shè)我正在給個(gè)人知識庫問答工具里加上下文管理能力目標(biāo)是要支持三種模式閱讀模式、寫作模式、編程模式。第一步準(zhǔn)備配置文件。每個(gè)模式對應(yīng)一個(gè) YAML 文件里面定義了該模式下的全部上下文參數(shù)。以閱讀模式為例mode: reading context_scope: 30 reference_files: - docs/guide.md - docs/faq.md inject_mode: system system_prompt: | 你是文檔解讀助手。 你的任務(wù)是基于指定參考資料回答用戶問題不編造不在資料中的信息。 如果資料中沒有答案請明確說“資料中未找到”。 回答時(shí)引用資料中的原文作為依據(jù)。 task_prompt: | 當(dāng)前任務(wù)是快速理解用戶提供的文檔并給出準(zhǔn)確的摘要或答疑。 輸出要求先給結(jié)論再給依據(jù)。 禁止事項(xiàng)不要輸出與參考資料無關(guān)的通用知識。寫作模式的配置思路類似但是參考文件會換成長文大綱和風(fēng)格指南系統(tǒng)提示詞也會變成“你是一個(gè)資深撰稿人嚴(yán)格遵循既定風(fēng)格”這類表述。第二步實(shí)現(xiàn)組裝邏輯。不管用什么語言核心流程都是一樣的讀配置 → 取系統(tǒng)層 → 掛載場景層 → 過濾歷史 → 組合發(fā)送。我用 Python 簡單演示一下def build_prompt(mode, user_input, history): cfg load_config(mode) messages [] # 1. 系統(tǒng)層角色與原則 messages.append({role: system, content: cfg.system_prompt}) # 2. 模式層任務(wù)描述 messages.append({role: system, content: cfg.task_prompt}) # 3. 資料層按需掛載參考文件 for doc in cfg.reference_files: content load_file(doc) messages.append({role: user, content: f[參考資料:{doc}]\n{content}}) messages.append({role: assistant, content: 收到我已閱讀參考資料。}) # 4. 對話層按模式過濾歷史 if cfg.context_scope ! all: history history[-cfg.context_scope:] messages.extend(history) messages.append({role: user, content: user_input}) return messages第三步設(shè)置默認(rèn)模式和回退規(guī)則。比如用戶不指定模式時(shí)默認(rèn)走“閱讀模式”模式文件加載失敗時(shí)回退到全局基礎(chǔ)配置。這一步看起來很基礎(chǔ)但能避免很多因?yàn)榕渲萌笔?dǎo)致請求失敗的情況。4.2 已有工具不做代碼改造也能實(shí)現(xiàn)輕量版如果你用的工具沒有開放編程接口也不用灰心。context-mode 的思想完全可以直接通過“提示詞模板包”來實(shí)現(xiàn)。操作方法是維護(hù)一份主模板和幾份子模板每次切換模式時(shí)手工把對應(yīng)內(nèi)容粘進(jìn)去。我的輕量版做法是給每個(gè)模式起一個(gè)簡短的名字然后把這個(gè)名字寫在每輪提問的開頭。比如寫作模式就在每輪消息前加“寫作模式”編程模式就加“編程模式”。這不是什么高深技巧但對很多模型來說就是一個(gè)強(qiáng)信號能讓它更清楚地知道你還在同一個(gè)任務(wù)框架里。更正式一點(diǎn)的做法是做一個(gè)“模式切換語句”模板請切換到{寫作模式}。 當(dāng)前任務(wù){(diào)長文第三章節(jié)初稿}。 參考背景{完整大綱 前三章內(nèi)容摘要}。 歷史對話從上一問題開始保留之前內(nèi)容無需參考。這段話本身就是 context-mode 的最小實(shí)現(xiàn)。它同時(shí)做了三件事聲明新身份、裝載新背景、劃清新舊信息邊界。在我沒有能力修改工具內(nèi)部邏輯的早期階段就靠這種方式勉強(qiáng)撐過了好幾個(gè)項(xiàng)目。4.3 怎么驗(yàn)證你的 context-mode 真的有效配置做完之后要有一套驗(yàn)證方法來判斷自己折騰出來的東西有沒有用。這里分享我常用的三個(gè)測試。第一個(gè)是“串味測試”。準(zhǔn)備一個(gè)和當(dāng)前模式無關(guān)的干擾性問題比如在編程模式里問模型“這篇文章的開頭要怎么寫”。如果它一本正經(jīng)地開始分析代碼結(jié)構(gòu)說明模式約束沒生效如果它說“當(dāng)前模式是編程模式這個(gè)問題超出了我的任務(wù)范圍”那說明模式信息被正確接收了。第二個(gè)是“token 用量對比”。啟用 context-mode 前后對同一個(gè)問題進(jìn)行若干輪對話統(tǒng)計(jì)平均 token 消耗。正常情況下帶模式的配置在任務(wù)單一且參考文件精簡時(shí)用量會明顯低于不帶模式的“全量塞入”方式。第三個(gè)是“切入測試”。切換新模式后第一輪提問的質(zhì)量是否立刻在線。這個(gè)測試最直觀你新建一個(gè)會話不做任何熱身直接問一個(gè)中等復(fù)雜度的任務(wù)如果模型能直接聚焦在問題上且答案結(jié)構(gòu)合理說明模式層寫得到位。我自己常用的調(diào)優(yōu)順序是先調(diào)參考文件再調(diào)保留輪數(shù)最后調(diào)提示詞措辭。不要一上來就改措辭因?yàn)榇朕o問題往往不是優(yōu)先級最高的問題。5. 常見問題與排查技巧實(shí)錄5.1 模式切換之后模型還在回答舊任務(wù)這應(yīng)該是 context-mode 最常見的失敗了。我第一次遇到的時(shí)候特別困惑明明系統(tǒng)提示詞都換了為什么模型還在回答上一個(gè)模式的問題。后來把請求日志打出來一看發(fā)現(xiàn)歷史消息里有大量舊任務(wù)的長對話全部原封不動傳給了模型。解決方案有兩個(gè)一是在切換模式時(shí)把舊的歷史消息清空或截?cái)嘀槐Ａ糇罱鼉蓷l作為銜接緩沖二是在切換后追加一條強(qiáng)制指令例如“忽略以上所有內(nèi)容只依據(jù)當(dāng)前模式和當(dāng)前問題作答”。這個(gè)方法非常有效但要注意不要每輪都加只在切換后的第一輪加一次就夠了。另外還要檢查一下有些工具只在界面層改了顯示名稱實(shí)際請求體里沒有做任何變更。這種情況不算真正實(shí)現(xiàn)了 context-mode只是給用戶一個(gè)心理安慰。所以排查的第一步永遠(yuǎn)是看實(shí)際發(fā)出去的請求到底長什么樣。5.2 token 用量不降反升還有一個(gè)常見的困惑用了 context-mode 之后怎么每次請求的 token 反而變多了排查之后發(fā)現(xiàn)問題幾乎都出在參考文件上。配置里掛了一堆 reference_files而且很多文件又長又雜光這些資料加起來就比原來的歷史消息都多。正確做法是先對參考文件做預(yù)處理。大文件先切片切片后再精煉成摘要每個(gè)文件只保留和當(dāng)前模式任務(wù)最相關(guān)的部分。我現(xiàn)在的習(xí)慣是參考文件總量盡量控制在 3000 token 以內(nèi)超過的部分要么做摘要要么拆成更細(xì)的子模式。另外一個(gè)隱蔽問題是注入時(shí)機(jī)。有些實(shí)現(xiàn)會把參考資料在每一輪對話都重新注入導(dǎo)致對話輪數(shù)越多token 膨脹越厲害。解決方法是只在模式切換時(shí)注入一次參考資料后續(xù)輪次直接依賴模型自身的記憶即可。5.3 新模式生效了但回答質(zhì)量反而變差這種情況也很讓人頭疼。模式切換明明成功了模型也在按新模式執(zhí)行但答案質(zhì)量和之前相比反而退步了。我遇到過的最典型原因是場景層寫得過于單薄。比如只寫了“當(dāng)前模式是編程模式”但沒交代清楚到底要寫什么服務(wù)、什么接口、沿用哪種風(fēng)格。模型是聽懂了你在編程但不知道你要編什么程序。解決辦法是在模式層補(bǔ)充足夠的“任務(wù)背景和約束邊界”。我給寫作模式加了很多次才慢慢找到合適的粒度既不能寫太長導(dǎo)致模型反復(fù)復(fù)述背景又不能太短導(dǎo)致模型自由發(fā)揮。最佳粒度是“能把任務(wù)描述到讓一個(gè)人接手就能干活”的程度。還有一類原因是系統(tǒng)層和模式層之間出現(xiàn)了矛盾。比如系統(tǒng)層寫著“你是通用助手回答任何問題”模式層卻寫著“只回答編程問題”。模型會在這兩個(gè)指令之間搖擺最常見的表現(xiàn)是“先回答一部分再附加一段通用建議”。檢查這類問題最有效的方法是分別打印系統(tǒng)層、模式層、即時(shí)層的內(nèi)容逐條對照看有沒有沖突。5.4 長時(shí)間使用后模式效果逐漸“漂移”這是長期使用中幾乎必然遇到的問題。剛開始的幾輪模型還很聽話嚴(yán)格按照模式約束來。聊到四五十輪之后它就開始自由發(fā)揮甚至?xí)炱鹱钤鐜纵喴呀?jīng)廢棄的思路。我把這個(gè)現(xiàn)象叫“模式漂移”。漂移的根源在于隨著對話變長早期模式的約束信號被大量無關(guān)消息稀釋了。就算保留輪數(shù)設(shè)得合理模型對“當(dāng)前是什么模式”這個(gè)判斷的置信度也會隨著上下文變長而下降。我的應(yīng)對措施有三層第一把重要的模式約束從“即時(shí)層”挪到“系統(tǒng)層”讓它始終約束模型行為第二設(shè)置會話斷點(diǎn)比如每 30 輪對話之后強(qiáng)制換一個(gè)新會話把關(guān)鍵結(jié)論和背景信息手動帶過去第三在關(guān)鍵節(jié)點(diǎn)主動讓模型復(fù)述模式目標(biāo)和已完成結(jié)論把模型重新拉回主線。這三個(gè)方法配合下來模式漂移基本可以被控制在可接受的范圍內(nèi)。當(dāng)然也需要你有意識地少在同一個(gè)會話里頻繁橫跳能新開會話解決的問題就不要依賴上下文繼承。最后再分享一個(gè)小技巧我在每個(gè)模式的配置里都會內(nèi)置一條“校準(zhǔn)指令”——要求模型在每次回答前先在心里復(fù)述當(dāng)前模式的唯一任務(wù)然后用一句話引出答案。這個(gè)規(guī)則聽起來有點(diǎn)笨但它對抑制模式漂移特別管用。我有兩個(gè)項(xiàng)目已經(jīng)穩(wěn)定跑了小半年基本沒有再出現(xiàn)需要反復(fù)糾正模型狀態(tài)的情況。