1. 為什么需要一份人機(jī)交互協(xié)議大多數(shù)人跟大模型打交道的方式其實(shí)停留在許愿階段。想到什么說什么問完一句等結(jié)果結(jié)果不滿意就換個(gè)說法再問一遍。這種方式在偶爾用用的場景下沒什么問題但一旦你每天要處理幾十個(gè)任務(wù)、要在多個(gè)模型之間切換、要把輸出結(jié)果直接對接給下游流程靠隨口問就會(huì)暴露出三個(gè)致命問題結(jié)果不穩(wěn)定、經(jīng)驗(yàn)無法沉淀、協(xié)作無法傳遞。我最初也是這么用的。直到有一次我需要連續(xù)三天用大模型處理一批結(jié)構(gòu)化的文本數(shù)據(jù)第一天調(diào)好的提示詞第二天換個(gè)對話窗口重新說一遍輸出格式就變了第三天想把這套方法交給同事對方聽完我的口頭描述復(fù)現(xiàn)出來的效果跟我差了十萬八千里。那次之后我才意識(shí)到問題不在于模型不夠聰明而在于我從來沒有把怎么跟它說話這件事當(dāng)成一件需要設(shè)計(jì)的事情來對待。所謂人機(jī)交互協(xié)議說白了就是一套你自己定義的、跟大模型協(xié)作時(shí)的固定規(guī)則集合。它規(guī)定了你怎么描述任務(wù)、怎么提供上下文、怎么約束輸出格式、怎么處理異常結(jié)果、怎么在多輪對話中保持一致性。它不需要多復(fù)雜但必須足夠明確明確到你可以把它寫下來交給另一個(gè)人對方照著做能復(fù)現(xiàn)出接近的結(jié)果。這份協(xié)議解決的核心問題是把跟大模型對話從一門手感活變成一套可重復(fù)、可迭代、可傳授的工程方法。它適合所有已經(jīng)把大模型納入日常工作流的人——不管你是寫代碼的、做內(nèi)容的、搞數(shù)據(jù)分析的還是單純想讓自己問問題的效率高一點(diǎn)。如果你只是偶爾問問天氣或者讓它幫你寫個(gè)請假條那確實(shí)用不上但如果你每天跟它打交道超過十次這套東西值得你花時(shí)間建立起來。我把它命名為V2.00是因?yàn)榈谝话媸俏易约涸谟玫牟莞褰?jīng)過大概兩個(gè)月的反復(fù)調(diào)整才定型。下面我把這套協(xié)議的完整結(jié)構(gòu)拆開講包括每個(gè)部分為什么這么設(shè)計(jì)、實(shí)際用起來效果如何、以及我在打磨過程中踩過的那些坑。2. 協(xié)議的第一層任務(wù)描述的結(jié)構(gòu)化模板2.1 為什么說清楚比說得多更重要很多人有一個(gè)誤區(qū)覺得給大模型的提示詞越長越好信息越多越好。實(shí)際測試下來真正影響輸出質(zhì)量的是信息的結(jié)構(gòu)而不是信息的數(shù)量。一段三百字但邏輯混亂的描述效果遠(yuǎn)不如一段一百字但層次分明的指令。我試過一個(gè)很典型的對比。同樣是讓模型幫我整理一份會(huì)議紀(jì)要第一種寫法是把會(huì)議背景、參會(huì)人、討論內(nèi)容、我的期望全部混在一段話里扔過去第二種寫法是分成背景任務(wù)輸出要求三個(gè)明確的段落。結(jié)果第二種寫法的輸出質(zhì)量明顯更穩(wěn)定格式幾乎不需要二次調(diào)整。原因很簡單模型在處理結(jié)構(gòu)化輸入時(shí)能更準(zhǔn)確地識(shí)別出哪些是約束條件、哪些是背景信息、哪些是它需要執(zhí)行的動(dòng)作。所以協(xié)議的第一條規(guī)則就是任何一次任務(wù)請求必須包含三個(gè)基本要素——背景Context、任務(wù)Task、約束Constraint。我把它簡稱為CTC結(jié)構(gòu)。2.2 CTC結(jié)構(gòu)的具體寫法背景部分要回答的是這件事的來龍去脈是什么。不需要長篇大論但必須讓模型知道它面對的是什么場景。比如你要它幫你寫一封郵件背景里至少要說明收件人是誰、你和對方是什么關(guān)系、這封郵件的目的是什么。任務(wù)部分要回答的是你具體要它做什么。這里最容易犯的錯(cuò)誤是任務(wù)描述太模糊。比如幫我優(yōu)化一下這段文字優(yōu)化什么是讓語言更簡潔還是讓語氣更正式還是修正語法錯(cuò)誤不同的優(yōu)化目標(biāo)對應(yīng)完全不同的處理方式。我的做法是任務(wù)描述里必須包含一個(gè)明確的動(dòng)詞比如改寫提取分類翻譯生成。約束部分要回答的是輸出應(yīng)該長什么樣。這包括格式要求JSON、Markdown表格、純文本、長度要求不超過多少字、至少包含幾個(gè)要點(diǎn)、風(fēng)格要求正式、口語、技術(shù)文檔風(fēng)格、以及禁止事項(xiàng)不要使用某些詞匯、不要添加解釋性文字。我實(shí)際用下來CTC結(jié)構(gòu)能把一次對話的有效率從大概六成提升到八成以上。所謂有效率就是第一次輸出就能直接用的比例。剩下的兩成需要微調(diào)但至少方向不會(huì)跑偏。2.3 一個(gè)完整的CTC示例拿一個(gè)實(shí)際場景來說。我需要模型幫我從一堆用戶反饋里提取出功能需求并且按優(yōu)先級(jí)分類。用CTC結(jié)構(gòu)寫出來大概是這樣背景我有一批來自產(chǎn)品試用用戶的文字反饋大約50條內(nèi)容涉及功能建議、bug報(bào)告和使用體驗(yàn)。這些反饋的語言風(fēng)格不統(tǒng)一有的很簡短有的寫了一大段。任務(wù)請從每條反饋中提取出核心訴求判斷它屬于功能新增功能優(yōu)化缺陷修復(fù)體驗(yàn)改進(jìn)中的哪一類并給出一個(gè)1到5的優(yōu)先級(jí)評分。約束輸出為Markdown表格包含四列——原始反饋摘要、訴求提取、分類、優(yōu)先級(jí)。優(yōu)先級(jí)評分標(biāo)準(zhǔn)是影響核心流程的為5影響次要功能的為3純體驗(yàn)建議的為1。不要添加額外的解釋文字。這個(gè)結(jié)構(gòu)寫出來不到兩百字但模型拿到之后基本不需要追問就能給出可用的結(jié)果。對比一下那種幫我看看這些反饋里有什么需求的寫法差距非常明顯。2.4 模板的靈活變體CTC結(jié)構(gòu)不是死板的。有些場景下背景可以省略比如你只是讓它做一個(gè)純粹的數(shù)學(xué)計(jì)算有些場景下約束可以放寬比如你在做頭腦風(fēng)暴不希望被格式限制。但有一條原則我始終堅(jiān)持任務(wù)和約束不能同時(shí)模糊。如果任務(wù)描述本身就不夠具體那約束就必須寫得很細(xì)如果約束很寬松那任務(wù)描述就必須精確到?jīng)]有歧義。這個(gè)原則幫我省了很多來回修改的時(shí)間。很多時(shí)候輸出不理想不是因?yàn)槟Ｐ湍芰Σ粔蚨且驗(yàn)槲以谌蝿?wù)和約束這兩端同時(shí)留了太多模糊空間模型只能靠猜猜錯(cuò)是必然的。3. 上下文管理的策略與邊界3.1 多輪對話中的信息衰減問題大模型的對話上下文是有窗口限制的這一點(diǎn)大家都知道。但實(shí)際使用中更隱蔽的問題是即使沒有超出窗口限制隨著對話輪次增加模型對早期信息的注意力也會(huì)衰減。我做過一個(gè)簡單的測試在一段對話的第3輪給出一個(gè)關(guān)鍵約束到第15輪再問一個(gè)相關(guān)問題時(shí)模型有相當(dāng)概率會(huì)忽略那個(gè)約束。這不是模型的bug而是注意力機(jī)制的特性決定的。長對話中越靠近當(dāng)前輪次的信息權(quán)重越高越早的信息越容易被稀釋。所以協(xié)議的第二層規(guī)則是關(guān)于上下文管理的關(guān)鍵約束必須重復(fù)重要背景必須前置。我的做法是在任何超過5輪的對話中如果某個(gè)約束對后續(xù)所有輸出都適用我會(huì)每隔幾輪就重新聲明一次。比如記住所有輸出都用JSON格式這句話我不會(huì)只說一次而是在每次提出新任務(wù)時(shí)都帶上。聽起來有點(diǎn)啰嗦但實(shí)測下來能顯著降低格式跑偏的概率。3.2 什么時(shí)候該開新對話很多人習(xí)慣在一個(gè)對話窗口里處理所有事情覺得這樣模型能記住之前的上下文。但實(shí)際上不相關(guān)的任務(wù)混在同一個(gè)對話里反而會(huì)互相干擾。我總結(jié)了一個(gè)簡單的判斷標(biāo)準(zhǔn)如果新任務(wù)和之前的任務(wù)在領(lǐng)域、格式要求、角色設(shè)定上沒有任何關(guān)聯(lián)就開新對話。比如你先讓模型幫你改了一段代碼然后接著讓它幫你寫一份市場分析報(bào)告。這兩個(gè)任務(wù)之間沒有任何共享的上下文放在同一個(gè)對話里模型可能會(huì)把代碼討論中的某些術(shù)語或風(fēng)格帶到報(bào)告里產(chǎn)生莫名其妙的輸出。分開處理各自干凈。反過來如果是一系列相關(guān)的任務(wù)比如先讓模型分析數(shù)據(jù)再基于分析結(jié)果寫結(jié)論再根據(jù)結(jié)論生成建議這種就應(yīng)該放在同一個(gè)對話里因?yàn)楹竺娴娜蝿?wù)依賴前面的輸出。3.3 上下文壓縮的實(shí)操方法當(dāng)一個(gè)對話確實(shí)需要很長又不想開新窗口的時(shí)候我會(huì)做一次上下文壓縮。具體操作是讓模型自己總結(jié)當(dāng)前對話中已經(jīng)確認(rèn)的關(guān)鍵信息然后我把這個(gè)總結(jié)復(fù)制出來開一個(gè)新對話把總結(jié)作為背景重新貼進(jìn)去。這個(gè)方法的妙處在于它把可能已經(jīng)衰減的早期信息以濃縮的形式重新放到了上下文的最近位置。我通常會(huì)在對話進(jìn)行到20輪左右的時(shí)候做一次壓縮壓縮后的新對話能恢復(fù)到接近初始狀態(tài)的理解準(zhǔn)確度。壓縮的提示詞我一般這么寫請把以上對話中已經(jīng)確認(rèn)的關(guān)鍵信息整理成一段背景說明包括任務(wù)目標(biāo)、已確定的約束條件、已經(jīng)完成的部分、尚未解決的問題。不要添加任何新的分析或建議只做信息匯總。拿到匯總之后新對話的第一條消息就是這段背景加上下一個(gè)具體任務(wù)。實(shí)測下來這種做法的信息保真度比直接繼續(xù)長對話要高不少。3.4 上下文里不該放什么有一條經(jīng)驗(yàn)是我踩了坑才總結(jié)出來的不要在上下文里放你自己的思考過程。什么意思呢就是不要跟模型說我覺得可能是因?yàn)椤也麓蟾攀恰也淮_定是不是……。這些表達(dá)會(huì)污染模型的判斷它可能會(huì)把你的猜測當(dāng)成事實(shí)來對待。正確的做法是只提供事實(shí)和明確的需求。如果你確實(shí)需要模型幫你分析原因那就把現(xiàn)象描述清楚讓它自己去推理而不是你先給一個(gè)可能錯(cuò)誤的假設(shè)把它帶偏。我舉個(gè)例子。有一次我處理一個(gè)數(shù)據(jù)異常的問題我跟模型說我覺得可能是編碼格式的問題你幫我看看怎么解決。結(jié)果它順著我的思路給了一堆編碼相關(guān)的方案但實(shí)際問題出在數(shù)據(jù)源本身的字段缺失上。后來我改成這批數(shù)據(jù)出現(xiàn)了以下異?，F(xiàn)象[具體描述]請分析可能的原因它給出的排查方向就全面得多。4. 輸出格式的約束與后處理4.1 為什么必須約束輸出格式如果你只是把大模型的輸出讀一讀然后自己消化格式其實(shí)無所謂。但如果你要把輸出直接對接給下游流程——比如粘貼到表格里、導(dǎo)入到代碼中、傳給另一個(gè)模型——那格式就是生命線。我最初做數(shù)據(jù)提取的時(shí)候沒有約束格式模型每次輸出的結(jié)構(gòu)都不一樣。有時(shí)候用列表有時(shí)候用段落有時(shí)候加了一堆解釋性文字。每次都要手動(dòng)整理效率極低。后來我強(qiáng)制要求所有提取類任務(wù)必須輸出JSON情況才徹底改觀。約束格式的核心技巧是給出一個(gè)具體的示例。光說輸出JSON不夠因?yàn)镴SON的結(jié)構(gòu)可以千變?nèi)f化。你要給出一個(gè)字段名和嵌套關(guān)系的樣例模型才能準(zhǔn)確理解你要的是什么。4.2 常用格式的約束模板我整理了幾種最常用的輸出格式及其對應(yīng)的約束寫法可以直接拿來用格式類型適用場景約束寫法要點(diǎn)JSON結(jié)構(gòu)化數(shù)據(jù)提取、API對接給出完整字段示例標(biāo)明必填和可選字段Markdown表格對比分析、清單整理指定列名和列順序說明每列的內(nèi)容要求有序列表步驟說明、優(yōu)先級(jí)排序說明排序依據(jù)限制條目數(shù)量純文本段落文案撰寫、內(nèi)容生成指定字?jǐn)?shù)范圍、語氣風(fēng)格、禁止事項(xiàng)代碼塊代碼生成、配置編寫指定語言類型、是否包含注釋、命名規(guī)范拿JSON舉例我通常會(huì)這樣寫約束輸出為JSON格式結(jié)構(gòu)如下{items: [{id: 數(shù)字, title: 字符串, category: 字符串, priority: 數(shù)字}]}。不要輸出任何JSON之外的文字不要使用Markdown代碼塊包裹。最后那句不要使用Markdown代碼塊包裹很關(guān)鍵。很多模型默認(rèn)會(huì)把JSON放在代碼塊里輸出如果你要直接解析這個(gè)輸出代碼塊的反引號(hào)就會(huì)造成問題。明確禁止之后輸出就是干凈的純JSON文本。4.3 輸出后處理的自動(dòng)化思路即使約束寫得再好模型的輸出偶爾還是會(huì)有小瑕疵。比如JSON里多了一個(gè)尾逗號(hào)或者表格里某一行多了一列。這些瑕疵如果靠人工檢查量大之后根本看不過來。我的做法是寫一個(gè)簡單的后處理腳本對輸出做自動(dòng)校驗(yàn)和修復(fù)。以JSON為例我會(huì)用Python寫一個(gè)校驗(yàn)函數(shù)嘗試解析輸出如果失敗就做幾件事去掉首尾的非JSON字符、修復(fù)常見的尾逗號(hào)問題、檢查字段是否完整。大部分小瑕疵都能被自動(dòng)修復(fù)只有少數(shù)需要人工介入。import json import re def clean_and_parse(text): # 去掉可能的代碼塊標(biāo)記 text re.sub(r^(?:json)?\s*, , text.strip()) text re.sub(r\s*$, , text) # 嘗試直接解析 try: return json.loads(text) except json.JSONDecodeError: # 修復(fù)尾逗號(hào) text re.sub(r,\s*([}\]]), r\1, text) try: return json.loads(text) except json.JSONDecodeError: return None這個(gè)腳本不長但幫我省了大量的手動(dòng)修正時(shí)間。核心思路就是能自動(dòng)修的就自動(dòng)修修不了的再人工看。后處理腳本不需要多完美能覆蓋八成以上的常見問題就值回票價(jià)了。4.4 格式約束的邊界有一點(diǎn)需要注意格式約束不能過度。如果你把輸出格式限制得太死模型可能會(huì)為了滿足格式要求而犧牲內(nèi)容的準(zhǔn)確性。比如你要求每個(gè)字段不超過10個(gè)字模型可能會(huì)把一些需要詳細(xì)說明的內(nèi)容強(qiáng)行壓縮導(dǎo)致信息丟失。我的經(jīng)驗(yàn)是格式約束應(yīng)該約束結(jié)構(gòu)而不是約束內(nèi)容。你可以規(guī)定輸出三個(gè)要點(diǎn)但不要規(guī)定每個(gè)要點(diǎn)不超過20字。結(jié)構(gòu)性的約束幫助模型組織輸出內(nèi)容性的約束則可能造成信息損失。5. 異常處理與迭代機(jī)制5.1 輸出不符合預(yù)期時(shí)的排查順序模型輸出不理想的時(shí)候很多人的第一反應(yīng)是換個(gè)說法再問一遍。但盲目重試的效率很低因?yàn)槟悴恢绬栴}出在哪里換的說法可能只是碰巧對了下次遇到類似情況還是不會(huì)處理。我總結(jié)了一個(gè)排查順序每次輸出不理想的時(shí)候按這個(gè)順序檢查任務(wù)描述是否明確模型是否清楚地知道你要它做什么動(dòng)詞是否具體約束是否完整輸出格式、長度、風(fēng)格是否都說清楚了上下文是否有干擾之前的對話內(nèi)容是否可能影響當(dāng)前任務(wù)的判斷信息是否充足模型是否擁有完成任務(wù)所需的所有信息任務(wù)是否超出能力邊界這個(gè)任務(wù)是否本身就不適合當(dāng)前模型處理按這個(gè)順序排查大部分問題都能定位到具體原因。我實(shí)際用下來排在第一和第二位的問題占了七成以上——也就是說大部分時(shí)候不是模型不行而是我沒說清楚。5.2 迭代式追問的技巧當(dāng)?shù)谝淮屋敵龇较虼笾抡_但細(xì)節(jié)需要調(diào)整時(shí)不要重新問一遍而是基于現(xiàn)有輸出做迭代。迭代式追問的關(guān)鍵是具體指出哪里不對、希望改成什么樣。比如模型給你寫了一段產(chǎn)品介紹你覺得語氣太正式了。不要重新說幫我寫一段產(chǎn)品介紹語氣輕松一點(diǎn)而是說把上面這段介紹的語氣改得更口語化保留所有產(chǎn)品特性描述但把書面語替換成日常表達(dá)。后者的好處是模型不需要重新理解整個(gè)任務(wù)只需要在現(xiàn)有輸出的基礎(chǔ)上做定向修改。這樣既保留了已經(jīng)正確的部分又精確地解決了問題。我通常會(huì)在迭代兩到三次之后得到滿意的結(jié)果比重新問一遍快得多。5.3 建立自己的提示詞庫協(xié)議的最后一條規(guī)則是關(guān)于經(jīng)驗(yàn)沉淀的把好用的提示詞存下來。我見過太多人每次用大模型都是從零開始寫提示詞之前調(diào)好的版本用完就忘了下次遇到類似任務(wù)又得重新調(diào)。我的做法是建一個(gè)簡單的文本文件按任務(wù)類型分類存放提示詞模板。每次調(diào)出一個(gè)好用的版本就把它存進(jìn)去標(biāo)注適用場景和注意事項(xiàng)。時(shí)間長了這個(gè)庫就成了我最高效的生產(chǎn)力工具。遇到新任務(wù)先翻翻庫里有沒有類似的模板有的話改一改就能用沒有的話從頭寫寫完再存進(jìn)去。這個(gè)庫不需要多復(fù)雜一個(gè)Markdown文件就夠了。關(guān)鍵是要堅(jiān)持記錄并且在每次使用后根據(jù)實(shí)際效果做微調(diào)。我現(xiàn)在的庫里大概有四十多個(gè)模板覆蓋了數(shù)據(jù)提取、文案撰寫、代碼生成、信息整理等常見場景。大部分日常任務(wù)都能在五分鐘內(nèi)找到可用的起點(diǎn)。5.4 什么時(shí)候該放棄當(dāng)前方案有一種情況需要特別說明當(dāng)你按照排查順序檢查了一遍發(fā)現(xiàn)任務(wù)描述沒問題、約束也完整、上下文也干凈但模型就是做不好這時(shí)候可能意味著這個(gè)任務(wù)本身不適合用大模型來做。我遇到過幾次這種情況。有一次我需要模型對一批數(shù)據(jù)做精確的數(shù)值計(jì)算涉及多步公式推導(dǎo)。不管我怎么優(yōu)化提示詞結(jié)果總是有細(xì)微的數(shù)值偏差。后來我意識(shí)到這種需要精確計(jì)算的任務(wù)用代碼來做遠(yuǎn)比用模型來做靠譜。模型擅長的是理解和生成不是精確計(jì)算。識(shí)別任務(wù)邊界很重要。大模型適合處理模糊的、需要理解的任務(wù)比如文本分類、內(nèi)容生成、信息提取不適合處理精確的、需要嚴(yán)格計(jì)算的任務(wù)比如數(shù)值運(yùn)算、邏輯驗(yàn)證、大規(guī)模數(shù)據(jù)處理。把合適的任務(wù)交給合適的工具比硬要用一個(gè)工具解決所有問題要高效得多。6. 協(xié)議落地后的實(shí)際變化6.1 效率提升的具體數(shù)據(jù)這套協(xié)議我從草稿到定型大概用了兩個(gè)月定型之后又用了三個(gè)月。最直觀的變化是任務(wù)完成時(shí)間。以我日常處理最多的數(shù)據(jù)提取任務(wù)為例之前處理一批50條的數(shù)據(jù)從寫提示詞到整理輸出大概需要40分鐘現(xiàn)在用固定的CTC模板加上JSON格式約束同樣的工作量大概15分鐘就能完成而且輸出可以直接導(dǎo)入下游流程不需要手動(dòng)整理。另一個(gè)變化是結(jié)果的一致性。之前同一個(gè)任務(wù)每次做的結(jié)果格式都不一樣現(xiàn)在因?yàn)榧s束固定了不同時(shí)間、不同對話窗口做出來的結(jié)果結(jié)構(gòu)完全一致。這對于需要批量處理的任務(wù)來說非常重要。6.2 協(xié)作場景下的價(jià)值這套協(xié)議最大的價(jià)值其實(shí)體現(xiàn)在協(xié)作上。之前我把任務(wù)交給同事需要花大量時(shí)間解釋你要怎么問它輸出大概長什么樣遇到問題怎么調(diào)整?，F(xiàn)在我把協(xié)議文檔和提示詞庫一起給對方對方照著做就能復(fù)現(xiàn)出接近的結(jié)果。我印象很深的一次是我需要臨時(shí)把一個(gè)數(shù)據(jù)整理任務(wù)交給同事處理。我把對應(yīng)的提示詞模板和輸出格式要求發(fā)過去對方之前完全沒有用過這套方法但照著模板操作第一次輸出就基本可用。這在以前是不可想象的以前至少要來回溝通三四輪才能對齊預(yù)期。6.3 持續(xù)迭代的方向協(xié)議本身也在不斷迭代。我目前在做的一個(gè)改進(jìn)方向是把常用的提示詞模板做成參數(shù)化的形式。比如數(shù)據(jù)提取的模板把數(shù)據(jù)來源提取字段輸出格式做成可替換的變量用的時(shí)候只需要填幾個(gè)空就能生成完整的提示詞。這樣進(jìn)一步降低了使用門檻也減少了每次重新組織語言的時(shí)間。另一個(gè)方向是建立輸出質(zhì)量的自動(dòng)評估機(jī)制。目前判斷輸出好不好還是靠人工看量大之后容易疲勞。我在嘗試寫一些簡單的規(guī)則來對輸出做初步篩選比如檢查JSON是否合法、檢查必填字段是否缺失、檢查輸出長度是否在合理范圍內(nèi)。這些規(guī)則能過濾掉明顯不合格的輸出減少人工檢查的工作量。這套協(xié)議沒有什么高深的技術(shù)核心就是把跟大模型協(xié)作時(shí)的那些隱性經(jīng)驗(yàn)顯性化、結(jié)構(gòu)化、可復(fù)用化。它不需要你懂模型內(nèi)部的原理只需要你愿意花一點(diǎn)時(shí)間把自己平時(shí)問問題的習(xí)慣整理成一套固定的規(guī)則。一旦建立起來你會(huì)發(fā)現(xiàn)跟大模型協(xié)作的效率和質(zhì)量都會(huì)有明顯的提升。