你在寫prompt時候，是不是總覺得大模型它不聽話。要么答非所問、要么一堆廢話。扒開思考過程仔細閱讀時而覺得它聰明絕頂，時而又覺得它愚蠢至極。明明已經對了怎么又推理到錯的地方去了，明明在提示詞中提醒過了不要這么思考它怎么就瞎想了。這也許就是每一個Prompt Engineer的困擾。怎么能讓模型按照要求去思考。長提示詞到底應該怎么寫，有沒有方法可以一次命中，找到那個終極的提示詞。 答案是否定的，一篇成功的長提示詞總是要經歷初始版本、調優、測試、再調優。不過這個過程中有規律可循，有方法可套。 以下就是被提示詞反復捶打，經歷無數痛苦經歷后總結的一套提示詞寫作方案，保你可以得到滿意的長提示詞，讓模型聽話。

1. Prompt格式

md或者json，推薦md格式。不僅僅是因為md格式比較好看，主要是為你md格式結構清晰，撰寫方便，而且拓展性很好。總結下來md是比較好的選擇。json格式雖然結構清晰，但是擴展性太差，寫的太長了容易把自己搞暈，慎重選擇。

2. Prompt模塊

不同模塊承擔不同的作用，復雜程度不同需要的模塊也不同。
角色&任務
角色輔助，講清楚任務。 此部份在prompt最前面，是最高指令，告訴模型它是誰，要干嘛。
角色：模型本身是具備各領域知識能力的，解決當前具體問題需要調用模型哪方面的能力，是通過角色定位完成的。 你是一名牙科醫生，你是一名數據分析師、你是一名川菜廚師等讓模型從一個雜學家變成專業領域的科學家。
任務：一句話講清楚模型要干嘛，數據分析師可以寫sql查詢數據、可以使用python分析數據、可以數據可視化，也可以寫分析報告。角色和任務約束模型調用某方面能力完成一個具體的事情。
核心原則
核心原則可以一開始就輸出，也可以在調優過程中生成。 可以理解為模型執行任務時要遵守的最高原則，綱領性質的要求。所以核心準則不能多，3條以內，超過3條很容易就失效了。比如在生成sql的prompt中，為了保證生成的sql可以查詢出數據，就得有以下核心原則：

比如在做分詞提取時，我們的分詞傾向性也可以寫在核心原則內：

一開始實現某個任務時，核心原則可能還沒有，在優化過程中有些問題在提示詞主體中總是解決不了，可以考慮在核心原則中優化。對于模型來源核心原則會被考慮的權重是比較高的，僅次于角色和任務。

3. 上下文處理

當前Context Engineering概念比Prompt Engineering更加流行，一句話概括就是讓上下文以恰當的格式出現在恰當的位置，知識庫可以包括：多論對話的長短記憶、知識庫rag結果、提示詞、工作流上游輸出等。能讓上下文發揮最大作用，就必須把上下文講清楚，放對位置。
上下文模塊組織原則：

• 上下文內容比較長，最好放到最后，以免打斷提示詞
• 上下文結構講清楚，合適和組織形式影響token數量也會影響性能
• 上下文在任務中承擔的作用和價值

舉例：在生成sql環節，上下文輸入較多，具體組織形式如下：

上下文輸入：一般放在提示詞結尾處：

4. CoT(Chain of Thoughts)

CoT本來是提示詞的一種框架，是針對邏輯比較強的任務場景提出的。就是要提醒或者約束模型按照要求思考，以提升準確率
在復雜場景下，CoT，也可以理解為執行流程或者說思考過程，可以作為整個prompt一部份，模型在充分理解任務和上下文之后，再按照CoT步驟執行拆解任務，往往可以讓模型按照要求執行，聽話程度高出很多。我們的經驗是可以提升準確了20個percent。
示例如下：維度解析

要求和限制
看是什么級別，可以寫在CoT模塊內，也可以單獨一個模塊，因地制宜即可。要求和限制一般是任務中需要特殊強調、特殊處理的邏輯，建議二者分開寫。舉例：

特殊邏輯表達
在寫prompt中有些邏輯用文字特別難以準確表達，有時候準確表達出來需要上百字，對于模型準確理解就更難了。 這個時候可以考慮使用偽代碼來表達，模型理解起來既快又準。比如，收入月報每月定稿時間13日，如何根據當前時間取出月表的最新時間，并考核時間的格式。

5. 輸出規范

模型太愛表達了，它往往不會只輸出你想要的內容，總是輸出很多自己的思考過程或者考慮的因素，以表達自己的聰明。又或者是不按照要求的格式輸出，對輸出的規范要求必不可少，一些平臺可以實現結構化輸出，不過結構化輸出的基礎是要模型能輸出結構清晰的結構。
輸出規范一般包含兩部分內容：
1 期望輸出的內容和結構
2 禁止輸出的內容和結構