Prompt 就是你打進 ChatGPT、Claude 或任何 LLM 的那段文字。定義就這麼簡單。它之所以有「prompt engineering」這個專屬詞,是因為小小的措辭差異會產生天差地遠的回答 — 大多數人因為不知道該調整什麼,白白放棄了一大塊品質。
一個 prompt 裡面到底有什麼
你在 chat 框輸入的時候,系統其實打包三件東西丟給模型:
- System prompt(產品設定的,你看不到) — 「你是 Claude,Anthropic 做的 AI 助理。回答要簡潔謹慎……」這段塑造模型的語氣和規則。
- 對話歷史 — 這個對話裡所有訊息,包含模型之前的回答。
- 你剛輸入的訊息 — 也就是你剛打的這一段。
用 API 的時候三個你都能控;用 chat 產品時你通常只看得到第三個,但前兩個仍然影響答案。
這件事很重要,因為如果你對話已經漂走了(本來在討論食譜,現在問 Python),前面的 context 還是會影響答案。想要乾淨的回答,就開一個新對話。
什麼樣的 prompt 才是好 prompt
沒有公式,但有四個槓桿持續會推動品質。
具體(specificity)。「幫我寫一封行銷信」得到的就是一封通用行銷信。「寫一封 120 字的行銷信給某個 SaaS 分析工具的現有客戶,公告 v2.0 下週二上線、唯一新功能是排程報告;語氣友善但專業、不要驚嘆號」這樣才會得到能用的東西。
**Context(背景)。**告訴模型它扮演什麼角色、聽眾是誰、前因是什麼。「你是一個資深文案,正在審我這份草稿。請毫不客氣地指出哪裡弱。」然後貼上草稿。
**格式。**直接講明輸出格式。「給我一張 markdown 表格,欄位:優點、缺點、什麼時候適用」遠比期待模型自己猜對版型來得好。
**範例。**這是最被低估的招式。給模型看一兩個你想要的輸入/輸出範例。模型對於「從幾個範例 pattern matching」非常擅長 — 比聽抽象指令好用得多。兩個精選範例,常常贏過 200 字的規則。
常見的失誤
三個浪費時間的模式。
叫模型一次做太多事。「幫我寫一份完整的 AI 寵物食物外送服務商業計畫書」得到的會是樣板答案。拆開:先市場分析、再競品列表、再單位經濟學、再 go-to-market。每一步的結果可以貼進下一個 prompt。
**沒告訴模型該拒絕什麼。**講明「如果資訊不夠,請問我釐清問題,不要猜」。否則模型會把空白處用聽起來合理的東西填滿,而不是承認自己不知道。
用模糊的語氣詞。「再專業一點」 — 什麼意思?更技術?更正式?句子更長?改成:「把口語縮寫展開、把口頭禪換成中性說法、控制在 200 字內」。
一個實用的 prompt 模板
任何非小事的請求,這個骨架都管用:
[角色或背景]
你是一個資深 PM,在審一份功能規格。
[任務]
讀下面這份規格,按嚴重程度給我列出三個 scope 上的疑慮。
[限制]
- 每個疑慮:一句說問題、一句說影響。
- 不要提解法。
- 如果規格太模糊評不了,直接講、然後問我三個釐清問題。
[格式]
用 markdown 編號列表。
[輸入]
<貼上規格>
你不需要每次都填齊每個欄位,但腦中有這個模板,你會注意到自己漏掉了哪一塊重要的。
什麼時候不需要做 prompt engineering
閒聊用的 prompt(「台北哪間義大利餐廳好吃?」)直接打就好。優化 prompt 只在這幾種場合划算:
- 你會重複跑同一類 prompt(模板、自動化、產品)
- 答案品質直接影響你的工作成果
- 你撞牆了,預設答案一直很糟
其他時候,自然地打、迭代。迭代就是 prompt engineering 的一半 — 你幾乎不會從第一個訊息就拿到最好的答案。讀完回應,說一下你想要什麼不一樣的,模型會調整。
延伸閱讀
- 什麼是 LLM
- System prompt vs user prompt:誰說了算
- 什麼是 context window
- 什麼是 prompt injection、為什麼危險
- Temperature、top-p、top-k 取樣參數解釋