提示詞的四段式結構：角色、任務、限制、輸出格式
大部分「模型不聽話」其實是提示沒有結構。用固定四段式改寫，同一個需求的輸出穩定度通常立刻提升一個檔次。
讓模型只回 JSON：從提示約束到結構化輸出參數
要模型輸出 JSON，光在提示裡拜託是不夠的。這篇整理三個層次的做法，以及各自會在什麼情況下失效。
少樣本示範怎麼挑：三個會讓效果變差的常見錯誤
加了範例反而更糟，通常不是因為範例太少，而是挑錯了。這篇講清楚範例的挑選原則與排列順序的影響。
思維鏈的正確用法：什麼時候該讓模型想，什麼時候不該
思維鏈不是萬靈丹。用在不需要推理的任務上，只會增加延遲、成本與出錯機會。
系統提示與使用者提示：邊界該畫在哪裡
把該放系統提示的東西寫進使用者訊息，是最常見也最容易修的架構錯誤。
提示注入的基本防線：分隔、標記與輸出檢查
只要你的提示裡有使用者輸入或外部文件，就存在提示注入風險。這篇是可以今天就加上的三道防線。
用提示模板管理版本：把提示當程式碼看待
提示散落在各個檔案的字串裡，就沒辦法回答「上週效果比較好的是哪一版」。
建立你的第一組提示評測集：30 題就能開始
沒有評測集，改提示就只是憑感覺。這篇示範用 30 題建立可重跑的基準。
溫度、top-p 與重複懲罰：三個參數的實際影響
調參數之前，先知道每個參數實際在改什麼。多數任務其實只需要動一個。
長文摘要的兩種策略：分段彙整與滑動精煉
文件超過上下文長度時，怎麼摘才不會漏掉關鍵段落。兩種策略各有適用情境。
讓模型承認自己不知道：降低幻覺的提示設計
模型預設會傾向給出答案。要它回「不知道」，必須明確給出這條路，而且讓這條路夠好走。
把需求寫成規格：用驗收條件取代形容詞
「寫得專業一點」對模型沒有意義。把形容詞換成可檢查的條件，輸出品質才會穩定。
提示壓縮：在不掉分的前提下把 token 砍掉四成
長提示不只貴，還會讓中段指令被忽略。這篇是實測過的壓縮順序。
多語言提示：中文任務要用中文提示嗎
提示語言、輸入語言與輸出語言可以是三種不同的選擇。這篇整理各種組合的實際差異。
把一個大提示拆成多次呼叫：什麼時候值得
一次做完所有事的提示很難調。拆成多步後好維護，但延遲與成本會上升，要拆得有道理。
提示工程的除錯清單：輸出不對時依序檢查這七項
輸出怪怪的時候不要急著改提示。照順序檢查，通常前三項就能找到原因。