主題: 學習筆記
Standard Prompt：從一句清楚的請求開始
Practical Prompt Engineering 短篇筆記：用電子報訂閱表單的提示改寫，說明 Standard Prompt、必要背景、釐清問題與回答的檢查方式。
Frontend Masters《Practical Prompt Engineering》把 Standard Prompt 定義為直接向 AI 提出問題或指令。例如「請解釋這個函式」就是一個起點，不需要先安排多輪流程或提供示範答案。課程說明
延續 Prompt Engineering 的入門筆記，這篇用一個自編的表單情境，練習把需求說清楚。
把主題詞補成能執行的請求
React 表單 email 交代了主題，卻沒有說明要教學、除錯，還是實作功能。若目標是加入訂閱表單，可以寫成：
請在現有 React + TypeScript 專案加入電子報訂閱表單。
只有 email 欄位，必填；格式錯誤時顯示提示，訂閱成功後顯示確認訊息。
沿用既有表單元件、驗證方式與 API，不新增套件。
先閱讀相關檔案，再實作，最後列出修改內容與檢查結果。
若找不到訂閱 API 的契約，請先確認路徑與成功／失敗回應格式。這個版本補上三類資訊：
| 資訊 | 範例中的內容 |
|---|---|
| 任務與行為 | 新增訂閱表單、驗證 email、成功後顯示訊息 |
| 必要背景與限制 | 現有技術、元件與 API；不新增套件 |
| 完成後要交代什麼 | 修改內容與實際檢查結果 |
課程建議像向人求助一樣，用完整問題交代需求。實際寫法可以是段落、條列或短句；重點是讀者能辨認任務與條件。Anthropic 的提示建議也強調明確的輸出要求與限制，並建議在順序重要時使用條列步驟。
缺少關鍵資訊時，先釐清再實作
範例最後一句，針對的是會影響實作的缺口：如果專案裡找不到訂閱 API，就先確認契約，避免自行編造端點。若已有明確定義，便可沿用，不必為了「先問問題」再問一次。
這是一項協作規則，能讓缺少資訊時的處理方式更清楚；模型是否遵守，仍要檢查。單純加上「不懂就問」，不能保證它會察覺所有歧義，或讓每次回答逐字相同。
用完成條件檢查回答
拿到結果後，可以對照三個具體案例：空白 email 是否被擋下、格式錯誤是否顯示提示，以及有效輸入是否依 API 契約送出並在成功後顯示訊息。模型列出的檢查結果，也要有對應證據。
同一句提示仍可能得到不同回答。Google 的生成參數文件說明採樣的影響，也保留 temperature 0 下可能出現變動的限制；相關概念可接著看 Temperature 與 Top P。
比較提示版本時，保存模型、完整上下文與設定，用相同案例核對是否符合需求。這比只看某次回答是否流暢，更能指出下一版要補哪個條件。
參考資料與範圍
- Sabrina Goldfarb，課程投影片第 8 頁與 Standard Prompt 課程頁面。
- Anthropic，Prompting best practices：清楚的指令、背景與輸出要求。
- Google，Content generation parameters：生成變動與重現性的限制。
資料於 2026-10-15 查閱。訂閱表單提示與檢查案例為自編示例，尚未執行模型或表單測試，不能據此宣稱改寫後的效果。