Day 3 比較了 GPT、Gemini、Claude 之後,得到一個結論:選哪個模型的影響,往往比不上「怎麼問」的影響大。 同一個模型,換一種問法,輸出品質可能差很多。這也是為什麼在動手寫「情境生成」「角色扮演」這些核心功能之前,Day 4 要先停下來,把 Prompt Engineering 的基礎打好。
Prompt Engineering(提示工程),簡單說就是:設計輸入給 LLM 的文字指令,讓它更準確地生成你要的結果。 LLM 本質上是「根據上下文生成內容」,所以輸入的內容越清楚、結構越完整,輸出的品質跟穩定性就越高。
雖然沒有標準公式,但一個好的 Prompt,通常會包含以下幾個要素:
用專題會用到的「英文修正」功能來對照,一個沒有結構的 Prompt 跟一個有結構的 Prompt,差異會很明顯:
❌ 沒有結構的 Prompt:
幫我看看這句英文有沒有問題:I want a coffee with not too much sweet.
這種寫法 AI 通常只會給一個籠統的修正,格式每次可能不一樣,很難串接到系統裡自動處理。
✅ 有結構的 Prompt:
你是一位英文口語教練。請針對使用者提供的句子,依照以下格式回覆:
- 原句
- 文法修正
- 更自然的母語者說法
- 一句話說明為什麼這樣更自然
使用者句子:「I want a coffee with not too much sweet.」
角色設定(英文口語教練)、任務(修正句子)、輸出格式(四個固定欄位)都寫清楚了,AI 給出的結果會更穩定,也更方便之後串接到程式裡解析成結構化資料。
對於「學習報告生成」這種格式要求嚴謹的功能,Few-shot 通常效果更穩定——先給一份範例報告,AI 比較不會漏掉欄位或格式跑掉。
請 AI 先「一步一步想」再給答案,而不是直接跳到結論。例如:
請先分析這句話的文法結構,找出可能的問題,再給出修正建議。
這對「英文錯誤分析」這種需要邏輯判斷的任務特別有幫助,能減少 AI 亂猜答案的情況。
如果之後要把 AI 的回應串接到程式(例如 FastAPI 後端要解析資料),最好直接要求 AI 輸出固定格式,例如:
請用以下 JSON 格式回覆,不要加入其他文字說明:
{ "original": "原句", "corrected": "文法修正", "natural": "更自然的說法", "explanation": "簡短說明" }
這個技巧在後面 Day 8-14 實作角色扮演與修正功能時會不斷用到,也是 Day 17-18 串接 FastAPI 時,讓後端能穩定解析 AI 回應的關鍵。
避免 AI 回答出跳脫情境的內容,例如:
你只能以咖啡廳店員的身份對話,不要跳出這個角色,也不要主動提及你是 AI。
這對「角色扮演」功能很重要,能避免 AI 中途「出戲」,破壞使用者的沉浸感。
Day 4 不用把每個功能的 Prompt 寫到完美,但可以先為四個核心功能,各自列出「這個 Prompt 至少要包含哪些要素」:
| 功能 | 角色設定 | 關鍵輸出格式要求 |
|---|---|---|
| 情境生成 | 情境設計師 | 背景、角色、目的、建議表達方式,分項條列 |
| 角色扮演 | 情境中的特定角色 | 純對話文字,維持角色一致性,不主動出戲 |
| 英文修正 | 英文口語教練 | 原句/修正/自然說法/說明,固定欄位或 JSON |
| 學習報告 | 學習分析助理 | 單字、文法、片語、建議複習內容,結構化整理 |
這張表會是 Day 5 實際動手寫 Prompt 時的骨架,先把「該包含什麼」想清楚,寫的時候就不會漏東漏西。
Day 4 學到的核心觀念是:Prompt 不是隨便打字問問題,而是一種「設計」——把角色、任務、脈絡、格式、限制講清楚,AI 給出的結果才會穩定、可預期,也才能真正串接進系統裡自動化處理,而不是每次都要人工檢查格式對不對。
明天(Day 5)要正式動手:針對「情境生成」功能,把今天整理的 Prompt 骨架寫成第一版可以實際執行的 Prompt,讓 AI 根據使用者輸入的情境,生成完整的英文對話場景。
本文為「30 天 AI 情境英文口語教練」自主學習專題系列文章 — Day 4