最近因為工作需要我開始認真研究怎么寫好一個 Prompt。以前我是想到什么寫什么總覺得字寫多一點、要求說得全一點總沒錯。后來發(fā)現(xiàn)不是那么回事。這段時間看了一篇講 Prompt 原則的文章把里面的東西整理成了筆記也結(jié)合自己工作中遇到的情況記錄一下我現(xiàn)在的理解。先說一下我的情況工作中主要寫 Java 后端平時會用 AI 幫忙寫代碼、排查報錯、做技術(shù)方案、寫單元測試之類的用得不少但一直憑感覺寫 Prompt沒系統(tǒng)了解過。這次認真研究的契機是有一次排查一個線上問題讓 AI 幫忙分析日志Prompt 改了半天輸出還是沒到點上?；厝サ穆飞暇驮谙氲降啄睦锍隽藛栴}。先說兩個我踩過的坑Prompt 越寫越長輸出反而越來越差有一次讓模型幫忙出一個對接第三方支付的技術(shù)方案。需求不復(fù)雜——我們的系統(tǒng)要接一個支付網(wǎng)關(guān)需要設(shè)計接口交互和回調(diào)處理。我一開始的 Prompt 寫了大概四五百字項目背景、需求說明、技術(shù)棧、注意事項全塞進去了。覺得寫得挺全的。結(jié)果模型輸出的東西很散——列了一大堆技術(shù)點什么消息隊列、分布式鎖、冪等性全扯進來了但我真正想讓它重點設(shè)計的對接流程和回調(diào)處理反而一筆帶過。我當(dāng)時第一反應(yīng)是是不是我寫得不夠清楚于是又加了一段把對接流程的要求寫得更細還加了一句請確保方案可落地。結(jié)果更散了模型好像什么技術(shù)點都說一點什么都不深最后還給我來了一段綜上所述建議采用微服務(wù)架構(gòu)實現(xiàn)解耦——說了跟沒說一樣。當(dāng)時已經(jīng)搞了快兩小時了有點煩躁。我停下來想了一下覺得可能不是內(nèi)容不夠是內(nèi)容太多了。于是試著反過來做——把項目背景刪掉只留核心任務(wù)和對接流程的要求然后把重點設(shè)計對接流程和回調(diào)處理方案其他技術(shù)點簡要提及挪到 Prompt 最前面。輸出確實好了一些至少對接流程的篇幅上來了廢話也少了一些。這個過程讓我意識到問題不在信息量不夠在于信息太多重要的東西被淹沒了。我一開始覺得寫全一點總沒錯這個想法本身就有問題。后來看那篇文章的時候里面提到信息密度這個說法跟我的感受對上了。Prompt 不是寫得越多越安全寫得越長真正重要的東西反而越容易被稀釋掉。明明寫了約束模型就是不照做另一個讓我頭疼的情況我在 Prompt 里明確寫了某個要求模型還是不照做。那次是讓模型幫忙寫一段 Java 代碼處理訂單狀態(tài)流轉(zhuǎn)。我在 Prompt 里寫了不要用 Lombok用 Java 8 語法不要用第三方庫。結(jié)果模型輸出的代碼里全是 Data、Builder 注解還用了 Java 14 的 record。我以為是表達不夠清楚又把不要用 Lombok改成嚴格不使用 Lombok不要加任何 Lombok 注解還加了請使用 Java 8 語法不要使用 record。還是照樣給我加 Data還用了一個 var——Java 10 才有的。我又加了一條注意以上約束必須遵守——然并卵該用還是用。當(dāng)時挺納悶的明明白紙黑字寫了不要用 Lombok為什么模型就是不照做我換了一個模型試結(jié)果差不多。后來看那篇文章的時候里面提到了一個叫 “Lost in the Middle” 的現(xiàn)象——模型對 Prompt 開頭和結(jié)尾的內(nèi)容記得比較清楚中間的內(nèi)容容易被忽略。我回頭看了看我那個 Prompt不要用 Lombok和用 Java 8 語法這幾個約束被我寫在了中間偏后的位置前面還有一大段需求說明和業(yè)務(wù)邏輯。我試著把約束挪到 Prompt 最末尾重新跑了一遍。這次 Lombok 注解沒了語法版本偶爾還會跑偏但比之前好不少。這個坑給我的教訓(xùn)是約束的位置可能比約束的措辭重要。我之前以為只要寫了就行沒想過放在哪里。不過說實話我也不確定這是不是完全準確的原因解釋?！癓ost in the Middle” 那個現(xiàn)象我是在講 Prompt 原則的那篇文章里看到的具體是哪篇不太記得了可能是引用了某個研究。我的理解可能不完全對但把約束放首尾這個做法確實對我有用。我的理解核心是界定邊界不是堆砌信息踩完這兩個坑之后再看那篇文章有一句話我印象很深一個好的 Prompt 基本由四要素構(gòu)成——Role角色、Task任務(wù)、Context上下文、Format格式。我現(xiàn)在寫 Prompt 的時候會先想清楚這四件事讓模型扮演誰、要它做什么、有什么背景、結(jié)果按什么格式給。四件事想清楚了Prompt 基本就成形了。不需要寫很多但每一句都要知道它在四要素里屬于哪一塊。再結(jié)合前面那個Lost in the Middle的教訓(xùn)現(xiàn)在寫 Prompt 的時候最重要的約束我會盡量放在開頭或者結(jié)尾不埋在中間。這個框架對我來說挺有用的至少寫 Prompt 的時候心里有數(shù)了不用每次都從頭想。但也不敢說這是最優(yōu)寫法——那篇文章里講的東西我還沒完全消化有些技巧沒實際試過。技巧沒有萬能的按場景組合那篇文章列了六種技巧角色扮演、思維鏈CoT、少樣本學(xué)習(xí)Few-shot、任務(wù)分解、結(jié)構(gòu)化輸出、XML 標簽。里面有一句話我印象很深技巧服務(wù)于穩(wěn)定性。我的理解是用技巧是為了讓輸出穩(wěn)定而不是時好時壞地碰運氣。所以沒有一種技巧是萬能的得看場景來選。目前我自己的做法大致是簡單任務(wù)寫個短 Prompt 就行復(fù)雜一點的推理用思維鏈讓模型把思考過程一步步寫出來對格式有嚴格要求的用 Few-shot 給幾個例子或者直接給 JSON Schema任務(wù)太長就拆成幾步一步步來Prompt Chaining。六種技巧里我實際用過的角色扮演用過一些讓模型扮演有 10 年經(jīng)驗的 Java 后端工程師來寫代碼比不給角色的時候輸出專業(yè)一點至少不會給我寫出一堆不能編譯的偽代碼。但也不是所有任務(wù)都需要——讓它格式化一段 SQL 給不給角色區(qū)別不大。CoT 用過幾次在排查問題的時候效果明顯。比如有一次線上接口超時我讓模型分析可能的原因加了請一步步分析先列出可能的性能瓶頸點再逐一排查之后輸出比直接問為什么接口慢要有邏輯。不過簡單任務(wù)用不上反而讓輸出變啰嗦。Few-shot 我用得最多。對代碼格式有要求的時候特別管用——給兩三個方法示例放進去模型就知道你想要什么風(fēng)格了。有一次讓模型按特定格式生成接口文檔我用文字描述了三遍格式它還是不對給了兩個示例就對了。那次之后我基本養(yǎng)成習(xí)慣格式要求一律用示例說話不再用文字描述了。任務(wù)分解偶爾用。需求復(fù)雜的時候我會拆成幾步來問——第一步先讓它出接口設(shè)計確認了再讓它寫實現(xiàn)代碼最后再讓它補單元測試。不是每次都需要但對于比較復(fù)雜的業(yè)務(wù)邏輯分步來比一次性寫完質(zhì)量好。結(jié)構(gòu)化輸出和 XML 標簽我沒怎么用過。結(jié)構(gòu)化輸出偶爾用讓模型輸出 JSON 格式的接口定義時會指定一下字段。XML 標簽不太熟還沒研究怎么用。最后落到一句話能用示例就別用文字能拆分就別硬塞進一個 Prompt。這是我自己用下來最大的感受。那篇文章和我的學(xué)習(xí)順序我說的那篇文章是一篇講 Prompt 工程原則的長文具體標題不太記得了是公司技術(shù)群里有人分享的。里面講了四要素、六種技巧、還有Lost in the Middle這些概念。對我?guī)椭畲蟮氖切畔⒚芏群图s束位置這兩個點正好對應(yīng)我踩的兩個坑。如果讓我重新學(xué)一遍我會先自己踩幾次坑這個好像避不開然后看四要素框架再一個一個試六種技巧。不要一上來就全部用——用了才知道哪個場景需要哪個。六種技巧里我覺得最先可以試的是 Few-shot效果最直觀格式問題一給示例就解決。其次是 CoT對排查類任務(wù)提升明顯。其他的看需求。剛學(xué) Prompt 的時候最困惑的幾個問題Prompt 到底寫多長合適我之前總覺得越長越全面越好后來發(fā)現(xiàn)不是。我的經(jīng)驗是能說清楚任務(wù)就行別為了全面硬加背景和約束。四要素想清楚每一句知道屬于哪一塊差不多就夠了。我現(xiàn)在的 Prompt 一般在一兩百字左右比以前短了不少效果反而好一些。要不要給模型一個角色看任務(wù)。需要技術(shù)深度的內(nèi)容寫代碼、做方案給個角色有點用給有 10 年經(jīng)驗的 Java 工程師角色之后輸出的代碼至少能看不會給你整一堆不存在的方法。簡單任務(wù)格式化 SQL、解釋報錯信息給不給區(qū)別不大。我試過給資深架構(gòu)師角色來格式化 SQL輸出反而變啰嗦了加了一堆不需要的架構(gòu)分析。模型不按約束來怎么辦先看約束放在 Prompt 的什么位置。如果是長 Prompt約束可能被中間淹沒了試試挪到開頭或結(jié)尾。還不行就給個示例Few-shot用示例來示范約束比用文字寫約束管用。比如不要用 Lombok這個約束與其寫三遍不要用 Lombok不如直接給一段沒有 Lombok 注解的代碼示例模型照著寫就不會加。還沒搞懂的目前我就到這個程度。那篇文章里有些東西我還沒完全消化——比如 XML 標簽怎么用、任務(wù)分解和 Prompt Chaining 的邊界在哪、結(jié)構(gòu)化輸出除了 JSON 還有什么場景。還有一點我不確定四要素框架是不是適用于所有類型的任務(wù)我感覺復(fù)雜任務(wù)可能需要更多結(jié)構(gòu)但具體怎么加我還沒想清楚。這些都是我從那篇文章里整理出來的理解工作里實際撞過的主要是前面說的這兩種情況。