在B端業務場景中，AI大模型的應用已經逐漸普及，但如何高效地利用這些模型來滿足複雜的企業級需求，仍然是一個需要不斷探索的課題。本文通過作者在實際工作中的實踐經驗，深入探討了如何撰寫高品質的提示詞，以提升AI模型在B端業務中的應用效果。
語言的邊界與模型的理解
語言本身具有慣性和連鎖反應，總有理解發生歧義的空間。無法保證模型能立刻理解我們想要表達的意思，並精確執行不出錯。這不像程式設計中的正則表達式，修改完立即生效，而是需要不斷調整和優化。
專業需求的瓶頸
在處理企業級的專業需求時，尤其是對結果精確度、輸出專業度要求高的任務，單純依靠提示詞+通用模型的效果會逐漸走到極限。突破這一瓶頸，往往需要引入模型微調、專業知識庫或其他輔助技術，才能達到更高的專業水準，提示詞也不是萬能的。
提示詞診斷能力的成長
隨著經驗積累，我發現自己已經能夠憑直覺發現提示詞中的問題所在。下一階段的成長目標是：記錄每次發現問題時的修改過程，分析為何特定的修改能讓模型按要求輸出，從而總結出一套系統化的識別和修改方法。
結構化輸出的穩定性
當模型輸出結果不穩定時，可以嘗試用JSON格式或Markdown格式來構建提示詞中的表格結構，引導模型按照特定結構生成和填寫內容。
注意事項：輸出Markdown格式在前端渲染時，可能會出現顯示異常。建議在提示詞中特別說明，要求模型確保輸出結果可以在前端正常顯示。
“言出法隨”的精確表達
提示詞基本可以做到在模型能力範圍內”言出法隨”，關鍵在於清晰表達我們的需求。
例子：我曾在提示詞中以Markdown形式提供表格，要求模型將輸出內容填入。但在實際使用中發現，表格的前端渲染總是失敗，儘管Markdown格式本身沒有錯誤。後來我在提示詞中明確要求模型在輸出表格時檢查格式和前端渲染相容性，解決了這個問題。
消除歧義，提高精確度
在模型能力範圍內，如果輸出不符合預期，通常是因為提示詞表述不夠清晰或存在理解歧義。
例子1：
– 初始提示詞：審核【送出日期】和【落款日期】是否和【data】（可變參數）一致
– 問題：模型只判斷兩個日期是否相互一致，而非與參數一致
– 改進提示詞：
– 審核【送出日期】是否和【data】（可變參數）一致
– 審核【落款日期】是否和【data】（可變參數）一致
– 結果：模型能夠正確判斷兩個日期是否分別與參數一致
例子2：
– 初始提示詞：審核2.2是否包含”……【data】……”
– 問題：即使文件2.2內容與要求不符，模型也會編造符合要求的內容
– 改進提示詞：審核文件全文是否包含【直接寫提醒文案內容，不帶2.2前綴序號】，如果有，提取原文填到表格中；如果沒有，表中直接填【無】
– 結果：模型能夠正確審核文件中是否包含特定文案及日期
簡潔與結構化的平衡
提示詞應在表達清需求的前提下盡可能簡潔和結構化：
簡潔：過長的提示詞可能導致模型難以判斷任務重點，注意力分散，同時也會佔用寶貴的上下文
結構化：便於自己修改和記錄，也有助於模型理解需求
提示詞的隨意性越高（想到什麼說什麼），模型輸出的不穩定性就越強。對於創意性任務，這可能不是問題；但對於要求穩定性和一致性的任務（如審核類或格式規範嚴格的任務），結構化的提示詞至關重要。
重複任務的提示詞優化
如果一項任務需要重複執行三次以上，最好設計一個能夠產生穩定輸出的提示詞範本。可以提高工作效率和結果一致性。
QWEN 2.5 72B
優勢：
– 對提示詞服從度高，能嚴格按要求執行任務
– 輸出穩定性和一致性強
– 適合處理對輸出內容和格式要求嚴格的任務
局限：
– 處理複雜多步驟任務時，輸出深度和專業度不足
– 語義理解能力有限，難以識別複雜文本關係（如”合併”、”拆分”）
– 無法有效識別長文本中的錯別字和政治敏感內容
DEEPSEEK R1
優勢：
– 在創意型任務中表現出色
– 語義理解和情景分析能力強
局限：
– 處理長文本和複雜任務時，不能嚴格遵循提示詞
– 傾向於在理解提示詞基礎上，用自己的思路尋找捷徑
– 常常找到自由發揮的空間，可能偏離原始要求
希望這些實踐經驗能對你有所啟發！
本文由 @Mrs.Data 原創發佈於人人都是產品經理。未經作者許可，禁止轉載
題圖來自Unsplash，基於CC0協定
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊存儲空間服務