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