大模型用了一年多我發(fā)現(xiàn)身邊不少朋友對 Prompt 工程的理解還停留在把話說清楚這個層面。話是沒錯但遠遠不夠。同一個模型同一件事有人寫三行字就能拿到能直接用的結果有人來回改十幾輪還是差點意思——差距往往不在文筆而在有沒有用對提示范式。Zero-shot、Few-shot、CoT 思維鏈這三個詞你可能天天在熱搜上刷到但真正能把它們用對場景、用出效果的人并不多。這篇就把這三套基礎范式拆開講透它們各自解決什么問題、底層為什么有效、什么場景該用哪個、實際寫的時候有哪些坑。不管你是剛接觸 Prompt 的新手還是已經(jīng)寫過一堆提示詞但效果時好時壞的老手都能從里面找到能直接抄作業(yè)的東西。1. 先把三個范式擺到同一張桌子上很多人學這三個概念是分開學的結果腦子里是三個孤立的定義。我更建議先把它們放在一條連續(xù)的軸上理解這樣你才知道什么時候該往哪邊挪。1.1 它們本質上是給模型多少信息的三個檔位把大模型想象成一個剛入職、能力很強但完全不了解你公司業(yè)務的同事。Zero-shot 就是你直接甩一句幫我寫個周報他憑常識給你寫Few-shot 是你先給他看兩份以前的周報當樣例他照著格式和風格寫CoT 則是你不僅給樣例還要求他先列這周做了啥再歸類再總結成三條把思考過程顯式地走一遍。所以這三者不是互斥的三選一而是可以疊加的Few-shot CoT 就是既給樣例又要求分步推理這在復雜任務里是最常見的組合。理解這一點后面所有的選型判斷都會順很多。1.2 一張表看清三者的適用邊界范式給模型的信息量典型適用場景主要成本Zero-shot只有任務指令通用任務、模型已充分訓練的能力結果不穩(wěn)定格式難控Few-shot指令 若干輸入輸出樣例格式固定、風格特定、分類任務消耗上下文長度樣例選擇敏感CoT指令 分步推理要求可疊加樣例數(shù)學、邏輯、多步推理、復雜決策輸出變長簡單任務反而變差這張表建議你存下來。實際工作中遇到一個新任務先問自己兩個問題模型對這個任務熟不熟任務需不需要多步推理兩個問題的答案基本就能定位你該從哪個檔位起步。1.3 為什么檔位這個視角比定義更有用因為真實項目里你幾乎不會只用一種。比如做一個合同信息抽取你可能會先用 Few-shot 固定輸出格式再對其中判斷條款是否對己方不利這種需要推理的子任務加 CoT。如果只記定義你會糾結這到底算 Few-shot 還是 CoT用檔位視角你只會關心這一步我需要給模型補什么信息。我見過太多人卡在概念分類上反而耽誤了真正該做的調(diào)優(yōu)。記住范式是工具不是考試題。2. Zero-shot別小看什么都不給的難度Zero-shot 看起來最簡單其實最考驗你對任務描述的精準度。因為模型沒有任何參照全靠你的指令去對齊它的理解。2.1 Zero-shot 真正難在哪難在你以為說清楚了其實沒有。比如總結一下這篇文章模型不知道你要多長、給誰看、要不要保留數(shù)據(jù)、要不要帶觀點。它只能猜而猜的結果十有八九不是你要的。我自己的經(jīng)驗是Zero-shot 的提示詞里至少要交代清楚四件事任務是什么、輸出給誰看、輸出什么格式、有什么約束。這四件事缺一件結果就會飄。舉個具體的請把下面這段產(chǎn)品介紹改寫成給非技術用戶看的版本。 要求 - 面向完全沒有技術背景的普通消費者 - 控制在 150 字以內(nèi) - 不使用任何專業(yè)術語如果必須用要加一句大白話解釋 - 語氣親切不要用感嘆號對比一下幫我改寫得更通俗一點你會發(fā)現(xiàn)前者幾乎不需要二次修改后者你得來回好幾輪。差別就在于約束是否顯式。2.2 指令的顆粒度怎么把握顆粒度太粗模型自由發(fā)揮太細又容易把模型框死反而寫出機械的答案。我的判斷標準是凡是結果對不對取決于它的必須寫死凡是風格好不好的給方向就行。比如做數(shù)據(jù)清洗輸出必須是合法 JSON這個必須寫死甚至要給字段名和類型。但如果是寫營銷文案你只需要說活潑一點、面向年輕人具體怎么活潑交給模型它往往比你規(guī)定得更自然。2.3 一個常被忽略的技巧用角色 任務 約束三段式這是 Zero-shot 里最穩(wěn)的結構我?guī)缀踉谒泻唵稳蝿绽锒加媒巧闶且晃挥惺杲?jīng)驗的財務分析師任務請分析下面這份利潤表指出三個最值得關注的問題約束每個問題用一句話說明并給出對應的數(shù)據(jù)支撐不要泛泛而談角色不是玄學它的作用是幫模型快速定位到某個知識分布和表達風格。你讓它當財務分析師它調(diào)用的就是財務領域的表達習慣和關注點比你不給角色要準得多。提示角色要具體到領域 經(jīng)驗層級你是一個助手這種等于沒寫。3. Few-shot樣例給對了效果翻倍給錯了全盤皆輸Few-shot 是我在工程里用得最多的范式因為大部分業(yè)務任務都需要固定格式和特定風格而這些靠文字描述很難說清給兩個樣例模型立刻就懂了。3.1 樣例數(shù)量不是越多越好很多人一上來就給十個樣例覺得越多越準。實測下來3 到 5 個高質量樣例通常就夠了再多邊際收益很低還白白吃掉上下文長度。更重要的是樣例的覆蓋度而不是數(shù)量。什么叫覆蓋度就是你的樣例要覆蓋任務里可能出現(xiàn)的各種情況。比如做情感分類你不能五個樣例全是正面和負面得有一個中性或者模棱兩可的否則模型遇到邊界情況就懵。3.2 樣例的順序會悄悄影響結果這一點很多人不知道。模型對樣例順序是有敏感性的尤其是分類任務。如果你把某一類的樣例都放在前面模型可能會輕微偏向這一類。我的做法是打散順序讓各類樣例交替出現(xiàn)減少位置偏差。另外最后一個樣例的影響往往最大因為它離你的真實輸入最近。所以如果你有特別想強調(diào)的格式或風格把它放在最后一個樣例里。3.3 樣例的格式必須和真實輸入完全一致這是踩過坑才知道的。有一次我做信息抽取樣例里的輸入是規(guī)整的短句結果真實數(shù)據(jù)里全是帶各種符號和換行的長文本模型直接崩了輸出格式全亂。后來我把樣例換成和真實數(shù)據(jù)同分布的長文本問題立刻解決。所以給樣例前先看一眼你的真實輸入長什么樣樣例必須長得像它。格式、長度、噪聲程度都要接近模型才能泛化過去。3.4 Few-shot 和 Zero-shot 的取舍判斷什么時候該上 Few-shot我的經(jīng)驗是三條里中一條就該上輸出格式有嚴格要求JSON、表格、特定模板任務風格很特殊文字描述說不清比如某種品牌調(diào)性Zero-shot 試了兩三次還是不穩(wěn)定反過來如果任務很通用、格式隨意、模型本來就擅長那就別浪費上下文Zero-shot 直接上。4. CoT 思維鏈讓模型想出來而不是猜出來CoT 是這三個里最容易被神化也最容易被誤用的。它的核心思想很簡單讓模型把推理過程寫出來而不是直接給答案。但什么時候用、怎么用講究很多。4.1 CoT 為什么有效把隱式計算變成顯式步驟大模型本質上是逐 token 生成的它沒有真正的思考過程。當你直接問一個多步問題它必須在一次前向計算里把答案蹦出來中間步驟全被壓縮了容易出錯。CoT 的做法是強制它把中間步驟一個個寫出來。每寫一步這一步的結果就變成了下一步的輸入條件相當于把一個大計算拆成了多個小計算。這就是為什么在數(shù)學、邏輯、多步推理任務上加了 CoT 之后準確率能明顯提升。用個類比你讓一個人心算 37 乘 24他可能算錯但你讓他拿紙筆一步步寫正確率立刻上去。CoT 就是給模型遞了張紙。4.2 最簡 CoT一句話觸發(fā)最簡單的 CoT 甚至不需要樣例只要在提示詞末尾加一句請一步一步思考并展示你的推理過程最后再給出結論。這一句話在很多任務上就能帶來明顯提升。但要注意展示推理過程和給出答案要分開要求否則模型可能把推理和答案混在一起你提取結果時很麻煩。4.3 Zero-shot CoT 和 Few-shot CoT 的區(qū)別Zero-shot CoT只加一步步思考的指令不給推理樣例。適合模型本身就會推理、只是沒被激發(fā)的情況。Few-shot CoT給幾個帶完整推理過程的樣例讓模型模仿推理的格式和深度。適合推理路徑比較特殊、或者你希望推理風格統(tǒng)一的情況。Few-shot CoT 的樣例里推理過程要寫得像人話不要跳步。我見過有人樣例里推理寫得太簡略結果模型也學著跳步最后還是錯。4.4 CoT 的適用邊界不是所有任務都該用這是最重要的一點。CoT 在需要多步推理的任務上有效但在簡單任務上反而可能變差。原因有兩個一是簡單任務本來一步就能出結果強行分步反而引入噪聲二是輸出變長模型有更多機會想多了跑偏。所以判斷標準是這個任務人需不需要打草稿需要打草稿的數(shù)學、邏輯、規(guī)劃、復雜判斷上 CoT不需要的翻譯、改寫、簡單分類別上。任務類型是否建議 CoT原因數(shù)學應用題強烈建議多步計算中間易錯邏輯推理強烈建議需要逐步排除情感分類不建議一步判斷加了反而飄文本翻譯不建議直接映射無需推理復雜決策分析建議需要權衡多個因素5. 三者組合真實項目里沒人只用一種講完三個單獨的范式該說說組合了。真實項目里尤其是稍微復雜一點的任務幾乎都是組合使用。5.1 Few-shot CoT復雜任務的標準配置這是最常用的組合。樣例里既包含輸入輸出又包含推理過程。模型既學到了格式又學到了推理路徑。寫這種樣例時有個技巧推理過程要寫得比實際需要稍微詳細一點給模型留出模仿空間。但也不能太啰嗦否則模型會學得又臭又長。我的經(jīng)驗是推理步驟控制在 3 到 6 步之間比較合適。5.2 分層使用不同子任務用不同范式一個復雜任務往往可以拆成幾個子任務每個子任務用最適合它的范式。比如做一個從用戶反饋里提取問題并判斷優(yōu)先級的任務第一步提取問題用 Few-shot 固定輸出格式第二步判斷優(yōu)先級用 CoT因為需要權衡影響范圍和緊急程度第三步生成回復建議用 Zero-shot因為格式隨意、模型擅長這樣拆開之后每一段都更可控出問題也容易定位是哪一步的鍋。5.3 組合時的上下文預算管理組合用得多上下文消耗就快。這時候要有預算意識樣例不是越多越好推理不是越細越好。我一般會先跑一版看哪部分對結果影響最大把預算往那部分傾斜其他部分能省則省。注意上下文塞太滿模型對中間部分的注意力會下降反而影響效果。寧可精簡不要堆砌。6. 那些文檔里不會寫的實操坑前面講的都是方法論這一節(jié)講點真金白銀踩出來的經(jīng)驗。6.1 樣例里的錯誤會被模型完美復制這是最坑的一點。你樣例里但凡有個錯別字、格式不一致、邏輯小錯誤模型會一絲不茍地學過去。所以樣例給出去之前一定要逐字檢查。我現(xiàn)在的習慣是樣例寫完先自己當模型跑一遍看有沒有歧義。6.2 指令和樣例沖突時模型往往聽樣例的如果你文字里說輸出用中文但樣例全是英文模型大概率跟著樣例走。所以指令和樣例必須一致不能打架。這個坑我在做多語言任務時踩過改了半天指令沒用最后發(fā)現(xiàn)是樣例語言不對。6.3 CoT 的推理過程可能看起來很對但結論錯模型寫出來的推理過程是它生成的不是它真實計算的。所以它可能寫出一段邏輯通順但結論錯誤的推理。這時候不能只看推理像不像樣必須驗證結論。我的做法是讓模型給出結論后再單獨問一遍這個結論對嗎請檢查相當于讓它自查一次。6.4 溫度參數(shù)和范式要匹配Zero-shot 想要穩(wěn)定輸出溫度調(diào)低CoT 想要多樣推理溫度可以稍高。但很多人調(diào)范式的時候忘了調(diào)溫度結果效果忽好忽壞。這兩個是要一起調(diào)的。6.5 別指望一次寫對迭代才是常態(tài)我寫過的提示詞幾乎沒有一次成型的。都是先寫一版跑一批測試數(shù)據(jù)看哪類錯得多針對性改再跑。這個過程通常要三到五輪。所以別追求一次寫出完美提示詞追求快速迭代到能用。7. 從零搭一套自己的提示詞測試流程光會寫還不夠你得能驗證寫得好不好。這一節(jié)講怎么搭一個簡單的測試流程。7.1 準備一批有代表性的測試樣本不用多20 到 50 條就夠但必須覆蓋各種情況典型的、邊界的、容易出錯的。這批樣本是你判斷提示詞好壞的唯一依據(jù)比拍腦袋感覺靠譜得多。7.2 定義清楚的評判標準什么叫好是格式對、內(nèi)容準、還是風格像不同任務標準不同。我一般會列三到五條硬標準比如輸出必須是合法 JSON關鍵字段不能漏語氣符合要求逐條打分。7.3 記錄每次改動和結果這一步很多人省了但特別重要。你改了哪句話、效果變好還是變差記下來。不然改到后面你自己都忘了哪版最好。我用一個簡單的表格記版本改動內(nèi)容通過率主要問題v1初始版本60%格式偶爾錯v2加了一個格式樣例85%邊界情況漏字段v3補了邊界樣例95%基本可用有了這個表你一眼就能看出哪次改動有效哪次是白費功夫。7.4 什么時候算夠用不要追求 100% 通過率那通常意味著你過擬合到測試集了。我的標準是核心場景全過邊界場景大部分過錯誤可接受且可兜底。剩下的交給后處理或者人工兜底比無限調(diào)提示詞劃算得多。8. 幾個真實場景的完整提示詞拆解理論講完來看幾個能直接抄的例子。8.1 場景一結構化信息抽取Few-shot你是一位專業(yè)的信息抽取助手。請從下面的文本中抽取指定字段輸出 JSON。 字段說明 - name: 人名字符串 - company: 公司名字符串沒有則填 null - role: 職位字符串沒有則填 null 示例1 輸入張三在字節(jié)跳動擔任產(chǎn)品經(jīng)理。 輸出{name: 張三, company: 字節(jié)跳動, role: 產(chǎn)品經(jīng)理} 示例2 輸入李四最近離職了暫時沒有新東家。 輸出{name: 李四, company: null, role: null} 現(xiàn)在請?zhí)幚?輸入王五加入了美團負責騎手運營。這個例子的關鍵點字段說明寫清楚、樣例覆蓋了有值和null兩種情況、格式嚴格一致。8.2 場景二多步推理判斷CoT你是一位資深運營分析師。請判斷下面這條用戶反饋的緊急程度高/中/低并說明理由。 請按以下步驟思考 1. 這條反饋涉及的問題影響多少用戶 2. 問題是否影響核心功能 3. 是否有替代方案 4. 綜合以上給出緊急程度。 反饋內(nèi)容今天下午開始所有用戶都無法登錄提示密碼錯誤但我們后臺看密碼沒問題。這個例子里步驟是顯式給出的模型會照著走。對于判斷類任務把判斷維度列出來比讓它自由發(fā)揮穩(wěn)定得多。8.3 場景三風格化改寫Zero-shot 角色你是一位有十年經(jīng)驗的科技媒體編輯擅長把技術內(nèi)容寫得讓普通人也能看懂。 請把下面這段技術說明改寫成面向普通讀者的版本 - 控制在 200 字以內(nèi) - 不使用專業(yè)術語 - 用一個生活化的類比幫助理解 - 語氣平實不夸張 技術說明本系統(tǒng)采用分布式架構通過一致性哈希算法實現(xiàn)數(shù)據(jù)分片并利用多副本機制保證高可用性。這個例子沒有樣例全靠角色和約束把方向定死。對于改寫類任務角色 約束的組合往往比給樣例更靈活。9. 關于提示詞工程會不會過時這件事最后聊個大家常問的問題?？傆腥苏f模型越來越強提示詞工程遲早沒用。我的看法是基礎范式不會過時但具體技巧會不斷更新。Zero-shot、Few-shot、CoT 這三個東西本質上是在解決如何把任務信息有效地傳達給模型這個根本問題。只要模型還是通過上下文來理解任務這個問題的解法就不會消失。變的只是形式——以前要手寫 CoT現(xiàn)在有些模型內(nèi)置了推理能力你只需要觸發(fā)它。所以與其焦慮會不會過時不如把這三個范式的底層邏輯吃透。你理解了為什么要給樣例為什么要分步無論模型怎么迭代你都能快速找到對應的用法。這才是真正值錢的東西。我自己現(xiàn)在的習慣是每換一個新模型都會拿這三個范式各跑一遍手頭的典型任務看看新模型在哪方面變強了、哪方面還需要提示詞補。這個習慣幫我省了很多瞎調(diào)的時間。