很多人把大模型用不好第一反應就是這模型太笨但實際排查下來十有八九是上下文工程沒做到位。所謂上下文工程就是指我們圍繞LLM輸入側做的一系列設計、組織與管理工作決定給模型看什么、不看什么、以什么順序看、以及看完一輪之后如何延續(xù)。它直接決定了模型能不能發(fā)揮出真正的潛能也是搭建一套理想AI工作環(huán)境的核心技能。這四大關鍵階段——任務目標界定、上下文材料準備、提示詞策略編排、多輪交互管理每一個都值得單獨打磨。這篇文章我就用自己實際操作中的經驗和踩坑記錄把這四個階段掰開揉碎講清楚適合所有正在用LLM做應用、寫自動化腳本、搭知識庫助手的開發(fā)者參考。1. 上下文工程到底是什么從調包到調上下文很多朋友剛接觸大模型時習慣把注意力放在選模型、調參數(shù)上認為換個更聰明的模型就萬事大吉?？烧娴搅藢嶋H項目里同一個模型別人能穩(wěn)定輸出高質量結果自己卻經常得到答非所問、胡編亂造的內容。問題往往就出在上下文的構建上。1.1 為什么說上下文是LLM的真正工作臺我們可以把LLM想象成一個能力很強但記憶極短、且特別容易受周圍環(huán)境影響的臨時工。它本身的知識儲備很廣但每次開工時眼前只有你遞給它的那張工作臺——也就是當前對話窗口里的全部內容。工作臺上放了什么、怎么擺放、有沒有干擾物直接決定了它能干出什么活兒。如果你把一堆雜亂無章的資料、一個含糊不清的目標、再加上幾條互相矛盾的指令全丟上去那它當然只能給你一份亂七八糟的結果。上下文工程要做的就是把這個工作臺收拾得井井有條讓模型一上來就知道我是誰、要做什么、有哪些可用素材、答案應該長什么樣。在很多真實項目中上下文工程帶來的收益甚至比換模型還明顯。我有一個做客服問答系統(tǒng)的項目最初用某款通用模型直接丟給用戶問題讓它回答效果一般經常答非所問或者漏掉關鍵信息。后來花了兩周時間做上下文工程把企業(yè)知識庫做了清洗和結構化、設計了帶角色和示例的提示模板、給多輪對話加了記憶摘要。同樣還是那個模型準確率直接提升了一大截用戶反饋完全像換了個產品。這件事給我的觸動很大模型能力是靜態(tài)的上下文工程是動態(tài)的后者才是我們真正能發(fā)揮主動權的地方。1.2 四個階段的整體視圖我習慣把上下文工程拆成四個階段分別對應一次完整交互從0到1、從1到N的完整鏈路。第一階段是任務目標與邊界界定。動手之前先想清楚這次調用想讓模型完成什么輸入是什么、輸出是什么有哪些限制條件這個階段的產出是一份任務說明書而不是直接寫提示詞。第二階段是上下文材料的選擇、清洗與結構化。模型不是數(shù)據(jù)庫你不能把所有資料一股腦塞進去需要篩選出真正相關的信息并按照模型容易理解的格式組織好。第三階段是提示詞策略設計與角色編排。把目標和材料翻譯成一段結構清晰、指令明確、帶示例的提示詞讓模型知道每一步該怎么走。第四階段是多輪交互中的上下文管理與迭代優(yōu)化?，F(xiàn)實中的AI工作環(huán)境很少只調一次接口往往是多輪對話、持續(xù)使用怎么維護對話歷史、怎么避免上下文污染、怎么從錯誤中反推改進都屬于這一階段。這四個階段不是一次性走完就結束的而是一個循環(huán)。每次看到Bad Case都需要回到前面某個階段重新調整。下面我按順序詳細說。2. 第一階段任務目標與上下文邊界界定很多人的提示詞寫得差根源不是文筆不好而是在寫之前根本沒想清楚任務目標。你在上下文里塞進的第一句話往往就決定了模型的整個行為方向。如果連你自己都不知道要什么模型就更不可能知道。2.1 動手前先回答四個問題我在設計任何一次LLM調用前都會強制自己回答四個問題答不清楚就絕不動筆寫提示詞。第一個問題這個任務的核心輸出是什么要求是一段文本、一個JSON、一份表格還是僅僅做一個判斷輸出形式需要一開始就鎖定否則模型很容易自由發(fā)揮。第二個問題輸入側有哪些必要信息和可選信息比如做摘要任務必要信息是原文可選信息是目標長度、風格偏好、關注角度。第三個問題成功標準是什么怎么判斷這一次輸出是好的是包含所有關鍵點還是格式完全合法還是語氣足夠專業(yè)沒有成功標準后面就沒法迭代。第四個問題有哪些絕對不能觸碰的邊界比如不能編造數(shù)據(jù)、不能輸出敏感內容、不能偏離某個固定口徑、不能使用某種語言。這些邊界要在進入正文前就寫清楚。這一步看似簡單卻能把很多后續(xù)問題消滅在萌芽狀態(tài)。我見過太多人上來就甩給模型一個幫我寫個方案然后模型寫出來一堆泛泛而談的東西又反過來罵模型不行。其實只要在提問前補上一句我是某個行業(yè)的中型團隊負責人需要一份針對新員工培訓的3周方案包含目標、日程、考核方式控制在800字以內輸出質量立刻就不一樣了。2.2 上下文窗口預算Token從哪來、到哪去很多人忽略了一個關鍵資源上下文窗口是有限的。目前主流模型的上下文窗口從幾萬到幾十萬Token不等看著很大但實際可用空間會被很多隱性內容吃掉。指令、角色設定、示例、對話歷史、檢索到的參考文檔、模型輸出本身全都要占空間。我習慣在項目初期就做一次Token預算。假設模型窗口是32K我會把規(guī)劃寫成這樣系統(tǒng)角色與全局指令1K用戶任務描述0.5K少樣本示例3個3K參考文檔檢索后20K歷史對話摘要2K預留輸出空間5K合計31.5K剛好卡在窗口之內。你會發(fā)現(xiàn)參考文檔通常是最大的消耗者所以在第二階段必須做信息篩選和壓縮。如果預算超了優(yōu)先砍參考文檔其次砍示例最后砍角色指令。因為對大多數(shù)任務來說指令可以短但材料不能亂。這個預算表我會寫進項目文檔里每次改提示詞都對照檢查一遍避免不知不覺超限。模型一旦觸發(fā)截斷往往不是丟開頭就是丟中間輸出質量會斷崖式下降這種問題極難排查。2.3 實操模板任務定義塊基于第一階段的思考我會在每次編寫提示詞時先寫一個任務定義塊放在上下文的最前面。它相當于給整個工作臺定下基調。一個典型的模板長這樣【任務目標】 針對用戶提供的產品差評內容生成一段安撫回復。 【輸入信息】 用戶差評原文。 【輸出要求】 1. 先表達歉意再給出具體解決方案 2. 不承認是產品質量問題但要體現(xiàn)負責任態(tài)度 3. 不超過120字。 【限制邊界】 不得編造訂單信息、不得承諾未經驗證的賠償、不得使用機械化的客服套話。這樣一個任務定義塊看起來很樸素但能讓模型在閱讀后續(xù)所有內容時都帶著這個目標框架。我測試下來加了這一塊的回復準確率、合規(guī)性都明顯高于直接發(fā)揮式提問。這也說明第一階段的工作不是可有可無的它是整個上下文工程的地基。3. 第二階段上下文材料的選擇、清洗與結構化目標定好之后就要往上下文里填充材料了。這一步最考驗功力因為材料的好壞直接決定模型輸出的事實基礎。很多AI應用翻車不是因為提示詞寫得差而是因為喂進去的參考資料本身就是臟的、亂的、過時的。3.1 材料選擇的相關性漏斗不要什么都往上下文里塞必須建立一個篩選漏斗。我自己的操作方法是四步過濾。第一步按任務目標圈定候選范圍。比如做法律問答就只找相關的法規(guī)條文和司法解釋而不是把整個法律庫都搬進去。第二步按時間過濾。信息類任務必須優(yōu)先選擇最新材料過期的說明文檔、舊版本政策條例很容易誤導模型。第三步按權威性過濾。同一個知識點優(yōu)先選官方文檔、一手數(shù)據(jù)其次是質量較高的二手整理論壇灌水內容直接丟掉。第四步按信息密度過濾。同樣講一個概念一篇文章可能有一半是鋪墊和廢話只提取其中真正包含事實、數(shù)據(jù)、步驟的段落就行。這個漏斗看起來簡單但大多數(shù)人會偷懶直接把幾篇長文拼接進上下文結果模型被大量無關內容干擾反而忽略了關鍵信息。我做檢索增強生成時對召回回來的文檔還會做一次重排序只取與問題得分最高的前3到5段而不是把整篇文檔都喂進去。這一步讓我項目的幻覺率下降得非常明顯。3.2 結構化組織從純文本到語義塊材料選好之后不能直接一大段懟進去要讓模型好讀。LLM對結構非常敏感語義塊清晰的上下文比一大坨連續(xù)文本更容易被精確引用。我自己常用的做法是給材料加標簽和分層。比如給模型提供產品資料時我不會寫我們的產品叫智辦系統(tǒng)是一款協(xié)同辦公軟件擁有任務管理、文檔協(xié)作、審批流程等功能而是組織成【產品基本信息】 名稱智辦系統(tǒng) 類型協(xié)同辦公軟件 目標用戶中小團隊 【核心功能】 - 任務管理支持看板、列表、日歷三種視圖 - 文檔協(xié)作多人實時編輯支持版本歷史 - 審批流程可自定義審批節(jié)點和條件 【常見用戶問題】 - 如何邀請成員進入團隊設置... - 如何導出任務點擊任務列表右上角...這樣的結構模型在回答用戶問題時能快速定位對應模塊生成的答案也更接近從文檔中找答案而不是自己憑空編。如果你在做一個知識庫問答系統(tǒng)強烈建議把所有知識文檔都統(tǒng)一成這種帶標題的語義塊格式前期多花點功夫清洗后期效果會好很多。3.3 長文本壓縮摘要、檢索和分塊的經驗現(xiàn)實中的資料往往很長一篇論文幾萬字、一本說明書幾百頁不可能全部塞進上下文。我總結出三種常用的壓縮策略。第一種是抽象摘要。把整篇長文檔先讓模型或人工生成一段摘要再放進上下文。這個方案適合背景信息類材料但摘要會丟失細節(jié)不適合需要精確引用數(shù)據(jù)的場景。第二種是檢索切片。把文檔切成小塊用向量檢索或關鍵詞檢索找出最相關的幾塊只把這幾塊喂給模型。這是RAG最常見的形式適合開放域知識問答。第三種是分層結構。先放一個全局摘要作為目錄級信息再把詳細內容放在后面讓模型按需查閱。這個方法在超長對話歷史管理里非常有用后面我會細說。切片時要注意塊的大小。我一般控制在每塊300到500字太小會中斷語義完整性太大會混入不相關內容。塊之間用空行和標題隔開最后在提示詞里明確告訴模型優(yōu)先使用【參考文檔】中的內容沒有資料時如實說明不知道。這樣模型就不會硬編了。4. 第三階段提示詞策略設計與角色/示例編排材料備好了接下來就是把目標和材料糅合成一段真正有效的提示詞。這是很多人最感興趣的部分但也是最容易被花哨技巧帶偏的部分。我始終認為提示詞的核心不是詞藻而是結構、順序和約束。4.1 指令、角色、示例的排布優(yōu)先級一份完整的提示詞通常包含角色設定、任務指令、上下文材料、示例、輸出格式這幾類組件。它們的排列順序會影響模型的理解效果。我習慣遵循一個目標先行、角色輔助、材料跟上、示例兜底的順序。先寫任務目標讓模型一進來就鎖定方向。再寫角色設定讓它調用相應的知識背景和語氣。接著給參考材料這是模型的事實依據(jù)。然后給少樣本示例讓模型模仿格式和推理風格。最后寫輸出約束和格式要求。比如錯誤示范是先給一大堆角色故事再給示例最后才輕描淡寫一句幫我總結一下。這會讓模型把更多注意力放在角色模仿而不是核心任務上。正確示范應該是你是一個數(shù)據(jù)分析助手。請根據(jù)下面的銷售數(shù)據(jù)總結本季度各區(qū)域表現(xiàn)。 【銷售數(shù)據(jù)】 ... 【輸出要求】 以要點的形式輸出每個區(qū)域包含完成率、同比增長、關鍵問題。這樣模型掃一眼就知道該干什么不需要反復猜測。很多人為了調教模型喜歡寫幾百字的角色小傳其實對大多數(shù)任務都是浪費。角色設定的作用只是錨定語氣和知識范圍三句話以內足夠了。4.2 少樣本示例的選取與數(shù)量控制少樣本示例是提示詞中威力最大的組件之一。一個精心設計的輸入輸出對往往比一百句抽象指令更能讓模型理解你想要的答案。選示例時要注意三個原則相似性原則示例要盡量貼近真實場景差異性覆蓋原則多個示例要覆蓋不同邊界情況而不是同一類重復反例原則有時需要放一個錯誤示范并標注為什么錯這能有效抑制模型的某些不良傾向。數(shù)量上我一般控制在2到5個。少于2個模型往往學不會模式多于5個Token消耗大而且示例之間可能互相干擾。有一次我做郵件分類任務最初給了8個示例模型表現(xiàn)反而不穩(wěn)定因為有些示例的分類邊界重疊了。精簡到3個典型示例后準確率還上升了一些。這件事讓我不再迷信示例越多越好。示例本身也要保持一致性。如果示例的輸出格式一會兒用列表、一會兒用段落模型就會困惑。最好把示例中的輸入部分也按真實情況脫敏處理并讓示例里的邏輯可解釋而不是讓模型單純復制表面措辭。4.3 輸出約束與格式錨點最后一個設計要點是輸出約束。你希望模型輸出什么格式就要在提示詞里用格式錨點明確卡死。比如你希望它輸出JSON就不要說請以JSON格式返回而是給出一個完整的JSON模板告訴它把字段填進去。模型對模板的遵循能力遠高于對抽象指令的遵循能力。一個實用的做法是使用XML或Markdown標簽把輸出區(qū)域框出來。比如請將結果填入下面的JSON { summary: 這里寫摘要, keywords: [關鍵詞1, 關鍵詞2], risk_level: high/mid/low }如果模型仍然不按格式輸出可以用請只輸出上述JSON結構不要包含任何解釋來收緊。還有一個技巧是讓模型先輸出一個思考草稿再給出最終結果。這種兩步法雖然增加了一些Token卻能顯著提升復雜任務的邏輯性。我在寫推理類提示詞時會在最后加上先梳理已知條件再逐步推導效果很不錯。5. 第四階段多輪交互中的上下文管理與迭代優(yōu)化前面三個階段解決的是單次調用怎么設計好。但真正搭建理想AI工作環(huán)境一定繞不開多輪交互——要么是用戶和模型連續(xù)對話要么是Agent多次調用工具。這時候上下文管理就變成動態(tài)問題了。5.1 對話歷史的取舍滑動窗口、記憶摘要多輪對話最基礎的管理手段是滑動窗口只保留最近N輪對話作為上下文。這個方案簡單粗暴但缺點是一旦關鍵信息被滑出去模型就失憶了。所以我會在此基礎上疊加一個記憶摘要層。具體做法是每一輪或每幾輪結束后讓模型把當前對話產生的關鍵信息濃縮成摘要比如用戶偏好、已經確認的事實、待辦事項等。下次對話時把摘要信息和最近幾輪窗口一起作為上下文喂進去。這樣一來模型既保留了對長期信息的記憶又不需要把全部歷史都塞進去。我做項目時通常會設定每5輪生成一次摘要并檢查摘要是否遺漏核心決策否則后續(xù)會話會出現(xiàn)前后矛盾。摘要和原始對話在上下文里的排布也有講究。摘要放在最前面因為它是對歷史的高度概括原始最近對話放在后面因為模型對緊鄰內容的注意力更強。這樣安排下來即使窗口不大也能維持較長時間的連貫性。5.2 上下文污染與遺忘機制上下文污染是我在多輪交互中踩過最多坑的地方。所謂污染就是之前某條消息里包含的無關、錯誤或沖突信息影響到了后續(xù)所有輪次的輸出。大模型不具備主動刪除記憶的能力它只會把新信息和舊信息混合當新舊信息矛盾時輸出就會崩壞。最常見的污染來源有三個一是用戶中途改了需求但舊需求相關的示例和材料還在上下文里二是前一輪模型的錯誤輸出被當作已知背景繼續(xù)參與后續(xù)生成三是無關的閑聊話題夾在關鍵指令中間分散了模型注意力。我的解決辦法是引入顯式的遺忘機制。當檢測到用戶意圖切換時主動重建上下文——清除掉舊的示例和對話記錄只保留任務目標摘要和新任務的材料。另外可以在提示詞中加一句請忽略前面對話中與本次指令沖突的內容以本次指令為準。這不能百分之百解決問題但對大多數(shù)場景很有效。還有一個土辦法如果某一輪出現(xiàn)了明顯污染不要繼續(xù)對話直接開一個新會話把必要的摘要手動粘過去往往比試圖糾正更省力。5.3 反饋閉環(huán)從Bad Case反推上下文缺陷上下文工程不可能一次到位必須建立反饋閉環(huán)。每次任務輸出質量不達標時我都會把這個Bad Case單獨拿出來反推是哪個階段出了問題而不是簡單換一個提示詞再試。我有一套固定的排查路徑先看任務目標是否明確再看參考材料是否相關、是否足夠然后檢查示例是否帶來誤導最后檢查上下文是否被歷史污染。如果模型輸出太泛泛往往是一階段目標界定不清晰如果模型編造了材料里沒有的內容往往是二階段材料篩選有遺漏如果模型格式不對往往是三階段輸出錨點不夠硬如果模型前后矛盾多是四階段對話管理出了問題。在項目里我會定期收集所有Bad Case給它們打上階段標簽統(tǒng)計哪一類問題占比最高。通常你會發(fā)現(xiàn)問題集中在一兩個階段那就集中精力優(yōu)化那一塊效率會高很多。我有一個同事一開始覺得模型不好用狂換模型后來我們幫他做了Bad Case分類發(fā)現(xiàn)八成問題出在第二階段——喂進去的參考文檔又舊又亂。把材料清洗和檢索優(yōu)化之后同一個模型的表現(xiàn)讓人刮目相看。6. 常見問題與排查技巧實錄最后整理一份我在實操中經常遇到的高頻問題速查表以及兩個典型的Debug案例希望能幫大家少走彎路。6.1 高頻問題速查表問題現(xiàn)象可能原因排查方向輸出內容太寬泛、不落地任務目標模糊缺少邊界回到第一階段補充具體輸出要求和限制引用不存在的數(shù)據(jù)或事實參考材料缺失或不完整檢查第二階段材料覆蓋率必要時加檢索回答格式總是不對輸出錨點不夠明確在提示詞中給出完整輸出模板禁止多余解釋多輪對話后開始胡言亂語上下文被污染或者歷史過長使用記憶摘要滑動窗口及時重建會話加了示例反而更差示例數(shù)量過多或互相矛盾精簡到2-3個高質量示例注意覆蓋差異同樣的提示詞時好時壞參考文檔順序不穩(wěn)定或引入無關內容固定文檔排序規(guī)則重排檢索結果清理干擾這張表我打印出來貼在工位上每次翻車就對照著查。多數(shù)情況下問題都能快速定位。6.2 兩個典型Debug案例第一個案例是一個報表生成助手。用戶要求模型根據(jù)銷售數(shù)據(jù)生成周報但輸出總是缺少環(huán)比和同比字段。我一開始以為是提示詞指令不夠清楚加了好幾遍強調還是偶爾丟字段。后來反查Bad Case發(fā)現(xiàn)參考數(shù)據(jù)里根本沒有上周和去年同期的數(shù)據(jù)模型自然沒法算。問題出在第二階段的信息準備而不是提示詞。修正方案是把歷史對照數(shù)據(jù)一起喂進去并在數(shù)據(jù)說明中標注字段含義和計算口徑。改完之后丟字段的問題徹底消失。第二個案例是一個教育問答機器人。單輪問答效果不錯但聊到第三四輪就開始亂。我檢查發(fā)現(xiàn)用戶在前幾輪問的是A知識點之后切換到B知識點時對話歷史里A的相關示例仍然占據(jù)上下文模型被舊內容干擾。解決方法是加了一個意圖檢測模塊當識別到切換話題時清空前面的參考文檔只保留一句簡單歷史摘要。同時在新指令開頭加上忽略之前話題專注于當前問題。經過這樣處理后續(xù)輪次的準確率明顯穩(wěn)定下來。這兩個案例的共同點在于都不是靠換模型或堆提示詞解決的而是回到上下文工程的具體階段找到根因。這也再次說明精通上下文工程才是解鎖LLM潛能的正確路徑。最后分享一點個人體會做上下文工程心態(tài)上要像整理房間而不是表演魔術。每一次穩(wěn)定的輸出背后都是清晰的邊界、干凈的素材、合理的結構和及時的復盤。我自己剛開始時也追求各種復雜技巧后來發(fā)現(xiàn)把基礎階段做扎實效果反而最可靠。希望大家也能從這四個階段入手一點點完善自己的AI工作環(huán)境讓模型真正成為靠得住的搭檔。