AWS 教的提示工程基本功：一個好提示的四個元素

第一次點開 AWS 的《Essentials of Prompt Engineering》時，我以為提示工程不過就是「把問題問清楚」。修完前半段才發現，AWS 把它整理成一套有結構的方法：一個提示該有哪些元素、模型端有哪些參數可以調，還有一串照著做就有感的好習慣。

這篇先整理課程的基本功部分；進階技巧與提示的誤用風險，我會在下一篇接著寫。

一個失敗的提示長什麼樣

課程開場用了一個場景：你在虛構的金融科技公司 AnyCompany 上班，要用生成式 AI 產出市場分析報告。新手最直覺的寫法大概是這樣：

Generate a market analysis report for a new product category.

模型真的會生出一份報告，只是內容是「智慧家庭保全系統」的市場分析。你明明在金融業，報告格式也跟團隊慣用的完全不同。模型沒有錯，錯的是提示沒有給它足夠的資訊。整段課程就是從這個失敗的提示出發，一步一步把它修好。

完整提示的四個元素

AWS 把一個提示拆成四個元素，寫提示時可以拿來當檢查清單：

• 指示（Instructions）：要模型做什麼任務、怎麼做。
• 脈絡（Context）：引導模型的外部資訊，例如你的產業、用途、對象。
• 輸入資料（Input data）：你要模型處理的內容本身。
• 輸出指示（Output indicator）：你要的輸出型態或格式。

不是每個提示都得四個元素到齊，但缺得越多，模型自由發揮的空間就越大。開頭那個失敗的提示只有指示，缺了脈絡、輸入資料與輸出指示，得到一份文不對題的報告，一點也不冤。

負向提示：說清楚不要什麼

有時候從反面引導反而更省力。負向提示（negative prompting）是告訴模型不要產生哪些內容、不要出現哪些行為：排除特定主題、避免偏頗用語，或不要用某種格式。與其事後挑掉不想要的東西，不如在提示裡先講明白。

推論參數：模型端的旋鈕

除了提示本身，多數模型還提供推論參數（inference parameters）可以調。課程把常見的分成兩大類：控制隨機性與多樣性的，以及控制長度的。

參數與提示是相乘的關係：提示決定方向，參數決定風格。課程回頭修改開場那個市場分析提示時，就刻意把 temperature 與 top p 調高，讓報告多一點你自己想不到的觀點。

好提示的習慣清單

課程整理了一串實作守則，我覺得這部分最實用，值得抄在手邊：

• 明確簡潔：用自然流暢的句子，避免堆疊零碎的關鍵字。
• 需要就給脈絡：請模型分析一家公司之前，先講這家公司是做什麼的。
• 指定回應型態：要摘要、要表格、要幾句話，直接說。
• 把要的輸出放在提示結尾：讓模型聚焦在該交出的東西上。
• 用疑問句開頭：誰、什麼、哪裡、為什麼、如何。
• 給範例回應：把期望的輸出格式當成範例放進提示裡。
• 拆解複雜任務：拆成子任務分次處理，或請模型一步一步思考。
• 多實驗：提示工程是反覆試錯的過程，記下有效與無效的寫法。
• 用提示範本：把常用結構做成範本，整個團隊可以重複使用。

修完這個部分我最大的收穫是：提示不是咒語，而是規格。規格寫得越清楚，模型交出來的東西就越接近你要的。