# 提示詞寫得再清楚，Claude 還是把資料和指令混在一起，憑什麼怪模型笨？官方拆台：不是模型讀不懂，是你沒給它劃清界線 官方來源：Anthropic A… · @swordBluesy · TwKit

@swordBluesy

# 提示詞寫得再清楚，Claude 還是把資料和指令混在一起，憑什麼怪模型笨？官方拆台：不是模型讀不懂，是你沒給它劃清界線 官方來源：Anthropic Academy《Building with the Claude API》第 9 課。課頁未標注發布日期，故此處不寫日期。原文標題直譯：《用 XML 標籤結構化》。先把反常識結論放前面：提示詞寫得長、寫得細，不代表模型讀得清——指令和資料糊成一鍋粥的時候，模型不是答錯，是根本不知道你哪句是命令、哪段是材料；標籤不是排版體面，是給模型劃的三八線，線劃清了，它才知道該看哪、該幹嘛。 說清詞： - XML 標籤（XML tags）：成對出現的尖括號標記，像 <sales_records> 這樣把一段內容框起來，告訴模型這段是一個整體。 - 定界符（delimiter）：幫模型分清「這段是什麼」的邊界記號，標籤就是最常用的定界符。 - 插值（interpolating）：把外部資料、變量塞進提示詞裡，資料越多，越需要邊界。 - 內容邊界（content boundaries）：指令、資料、不同種類內容之間的分隔線，邊界不清，模型就只能猜。 - 描述性標籤名：名字本身就說明內容是什麼的標籤，如 <sales_records>、<athlete_information>，讀到名字就知道這段是什麼。 - 混合內容：同一提示詞裡既有代碼、又有文檔、還有資料的情況，最容易混成一鍋粥。 - 複雜提示詞：插了多個變量、含多種內容的提示詞，結構價值隨複雜度一起漲。 一個真實的例子：課內講的就是最常見的翻車現場——要模型分析 20 頁銷售記錄、出一頁決策報告，提示詞裡先寫任務、再把 20 頁記錄往裡一插、後面再列五條分析步驟，指令和資料全糊在一起，模型讀下來根本分不清哪句是讓它幹活、哪段是給它分析。套上 <sales_records> 一框，邊界立刻出來：框裡是資料、框外是指令，模型先看見結構、再讀內容。另一例更直觀：讓模型拿著文檔給代碼除錯，代碼和文檔混在一起叫「不太好」，幾乎分不清哪段是代碼、哪段是文檔；改成 <my_code> 和 <docs> 兩組標籤，就叫「好多了」——同一段話，界線一劃，效果兩樣。眼熟的進化路線也正是這條：從第 1 課的單次請求，到第 2 課的帶歷史多輪對話，到第 3 課的定角色系統提示詞，到第 4 課的調溫度，到第 5 課的流式輸出，到第 6 課的結構化數據，到第 7 課的提示詞評估，到第 8 課的代碼評分，再到本課的 XML 標籤——前面是把調用調通、把輸出調順、把評估搭起來，這課是給提示詞本身動結構：資料歸資料、指令歸指令，模型先看懂結構，再談答得好不好。 反方適用條件清單——以下情況，不必先花大力氣加標籤，先說清楚，免得把本課讀成教條： - 提示詞只有一句話、沒有外部資料要插：邊界本來就清楚，加標籤屬於多此一舉，課內自己也說簡單提示詞上看不到明顯提升。 - 內容單一、不需要模型區分「這段是資料、那段是指令」：沒東西可混，就沒界線可劃。 - 除此之外，只要提示詞裡插了大量資料、或混了代碼文檔數據好幾種內容——標籤就是必選項，沒有第二種做法。 一句定性金句：標籤不是裝飾，是界線；界線劃清了，模型才知道哪句是命令、哪段是資料。 ### 一、翻車清單 - 指令和資料糊成一鍋粥：20 頁銷售記錄直接插進提示詞，模型分不清哪句是任務、哪段是材料，答案從第一步就歪了。 - 代碼和文檔不分家：除錯時把代碼和說明混在一起，模型拿著文檔當代碼改、拿著代碼當文檔讀，越改越亂。 - 標籤名起得含糊：<data> 這種名字說了等於沒說，模型讀到名字還是不知道這段到底是什麼，框了等於沒框。 - 大量插值不用標籤：變量一多、內容一雜，邊界全靠模型猜，猜錯一次答案就歪一次。 - 拿簡單提示詞驗標籤效果：短內容上提升本來就不明顯，沒看到飛躍就斷定標籤沒用，複雜提示詞上來的時候又沒養成習慣。 ### 二、替代方案＋理由 課內給的替代方案不是什麼新架構，就是三句話：第一，大量資料用描述性標籤框起來，像 <sales_records> 這樣，資料進框、指令留框外；第二，混合內容按種類分標籤，代碼歸 <my_code>、文檔歸 <docs>，不許混在同一個段落裡；第三，標籤名起具體，寧可長一點也不要含糊，<sales_records> 不要寫成 <data>。理由有三：第一，邊界一清，模型不用猜哪段是指令、哪段是資料，誤讀直接少一半；第二，標籤名本身就是信息，<athlete_information> 一眼就知道這組是運動員資料，不用另寫一段說明去解釋；第三，複雜度越高收益越大，提示詞越長、變量越多，標籤省下的誤讀成本越高，簡單提示詞上省不下多少，複雜提示詞上全是利潤。先把「資料進標籤、種類分標籤、名字寫具體」這條規矩寫穩，後面所有「模型讀不懂提示詞」的問題都是在它上面加東西。 ### 三、目標形態 一個結構一目了然的提示詞：指令是一段、資料各有各的標籤框，模型讀下來先看見結構、再讀內容；20 頁銷售記錄也好、代碼加文檔也好，邊界清清楚楚，答案不再因為「讀錯段」而歪掉；新同事接手一看標籤名，就知道每段是什麼，不用再猜。 ### 四、遷移步驟 1. 先數提示詞裡有幾種內容：指令、資料、代碼、文檔、變量，種類超過一種就準備加標籤。 2. 大量資料先框起來：銷售記錄這類成段資料，用 <sales_records> 這種描述性標籤包住，別裸插。 3. 混合內容按種類分標籤：代碼歸 <my_code>、文檔歸 <docs>，不要混在同一個段落裡。 4. 標籤名寫具體：<sales_records> 不要寫成 <data>，<athlete_information> 不要寫成 <info>，名字本身就要說明內容。 5. 多變量提示詞逐個檢查邊界：每個插進來的變量都有標籤框著，沒有裸奔的變量。 6. 拿課內那兩道題驗一遍：銷售記錄決策報告、代碼加文檔除錯——邊界清了、答案沒歪，標籤就算接通了。 7. 簡單提示詞別指望奇蹟：短內容上提升本來就不明顯，別因為沒看到飛躍就把標籤扔了，複雜提示詞上見真章。 ### 五、團隊共建分工 - 一個人定標籤命名規範：什麼內容用什麼標籤名，寫死在文檔裡，不許各人各起一套。 - 一個人審提示詞結構：新提示詞上線前檢查邊界——資料框住了嗎、種類分開了嗎、名字具體嗎。 - 一個人管複雜提示詞的標籤模板：銷售記錄、代碼文檔這類常見結構做成模板，新人直接套。 ### 六、官方工具包 - <sales_records> 標籤：大量銷售資料的框法，資料進框、指令留框外。 - <my_code>／<docs> 標籤：代碼與文檔分家的框法，除錯時各歸各。 - <athlete_information> 標籤：運動員資料這類成組信息的框法，身高體重目標限制放一組一起算。 - 描述性標籤名規則：名字越具體、越有描述性，模型越明白每段的用途。 - 四種最適用場景：塞大量上下文或資料、混合不同種類內容、邊界要格外講清、插值多個變量的複雜提示詞。 - 課頁四張示意圖：無標籤提示詞、加標籤的銷售記錄提示詞、代碼與文檔對照、運動員備餐結構示例，照著圖走一遍，寫法就立住了。 結尾收束：原則比架構重要——提示詞不是寫給人看的散文，是寫給模型讀的結構圖；你不劃界線，模型就只能猜，猜錯一次，答案就歪一次。可重複的動作規則只有一條，每次提示詞裡要插資料前問自己一句：這段東西框起來了嗎、名字寫具體了嗎——兩句答清楚了再發，答不清楚就先別發。把這句話寫成習慣、寫成模板，「模型讀不懂提示詞」就從玄學變成了手藝。 S1哥觀點：別再罵模型「連這麼清楚的話都讀不懂」了——你那提示詞，指令和 20 頁資料糊成一鍋粥，換個人來讀也得先問一句「你到底要我幹嘛」。標籤這東西，說白了就是給模型劃的三八線：線劃清了，它才知道哪邊是命令、哪邊是材料。更值得問的是：你現在最長的那條提示詞，資料是裸插的還是框起來的？裸插的就先別罵模型，先把 <sales_records> 這種框套上，跑一遍再罵也不遲。你提示詞裡的資料是裸插還是框起來的？評論區說說。 收藏用清單（照著做）： 1. 提示詞裡有幾種內容先數清楚，超過一種就加標籤。 2. 大量資料用描述性標籤框住，<sales_records> 不要寫成 <data>。 3. 代碼歸 <my_code>、文檔歸 <docs>，混合內容不許混在一段裡。 4. 多變量逐個檢查邊界，簡單提示詞別指望奇蹟、複雜提示詞上見真章。 轉給還在把資料裸插進提示詞的朋友，這篇他今天就能用上。 #Claude中文教程

曝光 39 · 评论 3 · 点赞 0 · 书签 0