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