第 2 章 · Prompt 工程：把需求講清楚的技術

同樣一個模型，有人問得到垃圾、有人問得到黃金，差別往往不在模型，而在怎麼問。這一章教你「把需求講清楚」的系統化方法——這就是 Prompt 工程（Prompt Engineering）。

先接回上一章：我們說過，LLM 的本質是「看著前面的文字，猜下一個字」。這句話其實藏著 Prompt 工程的全部祕密——你打的每一個字，都是在幫模型「佈置接下來要接龍的舞台」。你給的開頭越清楚、越像「一個好答案該有的前文」，它接出來的下一段就越接近你要的。所以 Prompt 工程不是什麼玄學咒語，它是在做一件很具體的事：把舞台佈置好，讓「正確答案」變成機率最高、最順理成章的下一段文字。

💡 一句話定義：Prompt 工程 = 用文字，穩定地讓模型做出你要的事。重點在「穩定」——偶爾問對不算本事，每次都問對才是。

💡 名詞速記：Prompt（提示詞） 就是你丟給模型的那段輸入文字——你的問題、你的指令、你貼的資料，全部加起來就是一個 prompt。它是你跟模型之間唯一的介面：模型看不到你的表情、猜不到你的言外之意，它能依據的只有你打進去的那些字。所以「把 prompt 寫好」約等於「把需求交代清楚」。

先懂：一則對話其實有三種角色

你在 ChatGPT 打字時看起來只有「你說、它回」，但底層其實有三種角色的訊息：

角色	是誰	作用
System（系統）	開發者設定	定義 AI 的「人設與規則」：你是誰、要怎麼回、不能做什麼
User（使用者）	你	這一輪的實際問題或指令
Assistant（助理）	AI	模型的回覆（也會被記進對話歷史）

為什麼要分角色？用一個好懂的類比：這就像劇組發給演員的三種紙。System 是「角色設定卡」——寫死你演的是誰、有什麼原則，開演前就貼好、整場都生效；User 是「這一場的台詞提示」——導演臨場喊的、要你當下反應的那句話；Assistant 則是「演員實際講出來的台詞」，而且會被記進劇本，成為下一場的前情提要。三種紙攤在模型眼前拼成一份完整劇本，模型再根據整份劇本，接出「下一句最該說的話」。

System prompt 是最有 power 的一層。同一句「幫我看這段程式」，如果 system 是「你是嚴格的資安審查員」，跟「你是親切的教學助教」，得到的回答天差地遠——前者可能劈頭就列出五個資安漏洞，後者則會先稱讚你寫得不錯、再溫柔地提點。指令內容一模一樣，只因為「角色設定卡」不同，產出就分岔了。

它為什麼這麼有效？回到第 1 章的機率本質：當開頭寫著「你是嚴格的資安審查員」，模型在接下來每一個字的機率表上，都會把「挑毛病、講漏洞、語氣嚴謹」這類詞的機率往上調——因為在它讀過的海量文字裡，「資安審查員」後面接的，本來就多半是這種內容。你不是在對它「下命令」，你是在替它挑一個更對的接龍起點。

💡 你自己用網頁版時通常只能改 user 訊息；但只要你在做應用、串 API，system prompt 就是你最重要的設計工具。

⚠️ 別把「安全規則」全押在 system prompt 上。system 的指令會影響模型的傾向，但不是鐵牢——使用者有可能用話術把它繞過去（這叫「提示注入 / 越獄」，第 10 章會專門講）。心態上請把 system prompt 當成「強烈的引導」，而不是「絕對做不到的禁令」。

🔧 動手試試：拿同一句 user 訊息（例如「幫我看這段自我介紹寫得好不好：……」），分別搭配兩個 system 設定——「你是毒舌但專業的面試官」跟「你是溫暖的職涯教練」——各問一次（網頁版可以把設定寫在訊息最前面代替）。同樣的內容，兩邊的重點、語氣、甚至結論都會不一樣。你會親眼看到「角色設定」的威力。

講清楚的四個基本功

這四招是全章的核心。共通的底層邏輯只有一句：你給的資訊越完整、越像「一個好答案的前文」，模型接出好答案的機率就越高。記住這句，下面四招其實是同一個道理的四種用法。

1. 明確，不要讓它猜

模糊的指令 → 模糊的結果。把「角色、任務、格式、限制」都講明。

為什麼「講明」這麼關鍵？因為模型碰到沒交代清楚的地方，不會停下來問你，它會自己按「最常見的情況」猜一個填進去——而它猜的，往往不是你心裡想的那個。你說「寫短一點」，它腦中的「短」可能是 300 字，你要的是 30 字；你沒講受眾，它就預設一個「一般大眾」，於是寫出四平八穩、誰看了都無感的東西。把限制講明，等於把它的機率表往你要的方向收窄，不留給它「猜錯」的空間。

❌ 幫我寫一下這個產品的文案。

✅ 你是資深電商文案。幫「無線降噪耳機」寫一段商品文案。
   受眾：通勤上班族。語氣：專業但親切。長度：50 字內。
   重點帶到「降噪」與「續航」，不要用誇張的驚嘆號。

有個好記的檢查清單，寫完 prompt 前對照一遍——這四個「W」有沒有交代：角色（Who，它扮演誰）、任務（What，具體做什麼）、格式（how，長怎樣）、限制（限制條件，不能怎樣）。上面那個 ✅ 範例剛好四項都齊：角色是「資深電商文案」、任務是「寫耳機商品文案」、格式是「50 字內一段」、限制是「別用誇張驚嘆號、要帶到兩個賣點」。

再看一組更生活化的對照，感受一下「補上細節」的差別：

❌ 幫我回一封拒絕的 email。

✅ 幫我寫一封婉拒廠商合作的 email。
   對方：一家送過我們試用品的小廠商，態度很客氣。
   語氣：感謝對方、明確拒絕、但留一線以後合作的可能。
   長度：三到四句，不要長篇大論。開頭直接稱「您好」即可。

左邊那封，模型只能靠猜——猜語氣、猜長度、猜要不要留餘地，結果多半是一封公式化的罐頭信；右邊補上「對方是誰、要什麼語氣、多長」之後，它幾乎不可能寫歪。

🔧 動手試試：挑一件你這週真的要請 AI 做的事（回信、寫貼文、整理筆記都行），先故意用一句模糊指令問一次，再照「角色／任務／格式／限制」四個 W 補完整、問第二次。把兩次結果並排看——你會很直接地感覺到「模糊 → 模糊、明確 → 精準」不是口號。

2. 給範例（Few-shot）比講規則更有效

與其用一堆文字描述你要的格式，不如直接示範一兩個。這叫 few-shot（少樣本）；完全不給範例則叫 zero-shot（零樣本）。

把使用者的句子分類成「正面/負面/中立」。

範例：
輸入：這家店服務超好！ → 正面
輸入：等了一小時還沒上菜 → 負面

輸入：價格中規中矩 →

模型看到範例，會照著你的格式與判準輸出，比你寫三段規則還準。

為什麼範例這麼有效？ 這其實直接呼應第 1 章的接龍本質。當你貼上「輸入：這家店服務超好！ → 正面」這樣的前文，你等於在模型面前擺出一個超級明確的接龍模式：看到「輸入：某句話 → 」，它機率最高的下一段就是「一個分類標籤」。範例把「我要的輸出到底長什麼樣」用做給它看的方式講清楚了——而「示範一次」永遠比「用文字描述一次」精準，因為文字描述本身還要它去解讀，範例則是直接把答案的模子擺在那裡。這也呼應第 1 章那個關鍵事實：模型的強項是模仿它看過的模式，few-shot 就是在餵它一個現成、乾淨的模式去模仿。

一個很有畫面的對照——同樣要它「把地址拆成欄位」：

❌（純規則，模型容易各拆各的）
把地址拆成縣市、區、路名。

✅（給一個範例，格式立刻被釘死）
把地址拆成 縣市 / 區 / 路名，照範例格式：
台北市大安區信義路 → 縣市：台北市｜區：大安區｜路名：信義路
台中市西屯區台灣大道 →

左邊沒給範例，模型可能回一段散文、可能用你沒預期的標點；右邊給了一個範例，它幾乎一定照著「縣市：X｜區：Y｜路名：Z」這個模子填。你想要什麼格式，就先自己示範一次——這是最省力、最可靠的一招。

💡 範例不用多，一到三個通常就夠。重點不是「量」，是品質與代表性：範例要涵蓋你真正在意的情況（例如分類任務裡，正面、負面、中立各給一個），別全給同一類，否則模型會以為「反正都選那一類就對了」。

🔧 動手試試：想一個你常做的小分類或小抽取（把 email 分成「要回／不用回」、把待辦標上「今天／本週／有空再說」都行）。先不給範例問一次，再給兩三個範例問一次。你會發現給了範例之後，它的輸出格式突然變得又穩又整齊——這就是 few-shot 的魔力。

3. 要它「想一想」再答（Chain-of-Thought）

遇到需要推理的題目，加一句「請一步一步思考」（Chain-of-Thought，思維鏈），準確度常常明顯提升——因為你逼它把推理過程展開，而不是急著猜一個答案。

一支筆 12 元，一本筆記本是筆的 3 倍價，買 2 支筆 + 1 本筆記本共多少？
請一步一步計算，最後再給答案。

為什麼「講出過程」就會變準？ 這要接回第 1 章最反直覺的一點：模型是一個字一個字往下接的，它沒有一個「先在心裡默默算好、再講出來」的階段——它想的深度，差不多就等於它寫出來的長度。如果你逼它直接跳到答案，它等於要在「一步」之內猜出最終數字，很容易猜歪；但你叫它一步一步寫，它就會先接出「一支筆 12 元」→「兩支筆 24 元」→「筆記本 36 元」→「合計 60 元」，每一步都成為下一步的前文、把下一步的機率往正確方向推。等於你給了它一張草稿紙，讓它把心算改成筆算。這也是為什麼同一題「直接問」常錯、「叫它列式」就對——不是它突然變聰明，是你給了它「展開來想」的空間。

一個對照就很清楚：

❌ 這句話有沒有邏輯矛盾？「所有鳥都會飛，企鵝是鳥，所以企鵝會飛。」直接回有或沒有。

✅ 這句話的推理有沒有問題？請先列出前提、再逐步檢查每一步，最後才下結論。

左邊逼它一口氣下判斷，它可能被「三段論長得很像對的」給騙過去；右邊讓它攤開來檢查，它才會發現「所有鳥都會飛」這個前提本身就是錯的（企鵝、鴕鳥都不會飛）。把「快速下結論」換成「攤開來想」，是對付推理題最便宜有效的一招。

💡 對「會先想再答」的推理模型（第 1 章）來說，這件事它會自動做；但對一般模型，這句話仍然很有用。

💡 小提醒：CoT 換來的是「更準」，代價是「更長、更慢、更花 token」（它要多寫一大段推理）。所以簡單題不必硬要它列式——問「今天星期幾」不需要三步推理。這跟第 1 章「別用大砲打小鳥」是同一個原則。

🔧 動手試試：找一道需要幾步計算或推理的題目（雞兔同籠、折扣後價格、行程時間換算都行）。先叫它「直接給答案」，再叫它「一步一步算、最後才給答案」。對答案時你會發現：攤開來想的那次，不只比較常對，連錯在哪你都一眼看得出來。

4. 指定輸出格式

要它給你能直接用的東西：「用表格」「用 JSON」「只回答一個詞，不要解釋」。越明確，越好接進後續流程。

從這段自我介紹抽出資訊，只輸出 JSON，不要多餘文字：
{ "姓名": "", "年齡": 0, "專長": [] }

為什麼要斤斤計較格式？因為模型有個「熱心過頭」的天性——你只要一個答案，它偏要先寒暄兩句「好的！這是我幫你整理的結果：」，再附一段「希望對你有幫助喔！」。你自己讀還好，但如果這段輸出要餵給下一支程式，那些多餘的客套話會讓程式解析爆掉。明確指定「只輸出 JSON、不要任何多餘文字」，就是在掐掉它那些好心的贅字，讓輸出乾淨到可以直接被機器接手。

一組對照最能說明差別：

❌ 把這三個人的資料整理一下。
   → 模型可能回：「好的！我幫您整理如下：小明今年 25 歲，擅長……」（一段散文，程式沒法用）

✅ 把這三個人的資料整理成 Markdown 表格，欄位為 姓名 / 年齡 / 專長，除了表格不要任何其他文字。
   → 模型回一個乾淨的表格，複製貼上就能用。

小訣竅：直接把「模子」給它。與其形容「我要一個有姓名年齡的 JSON」，不如像上面範例那樣，直接把 { "姓名": "", "年齡": 0, "專長": [] } 這個空殼貼給它，叫它「照這個結構填」——這其實就是第 2 招 few-shot 的變形：用「示範一個空模子」代替「用文字描述格式」。

結構化輸出是「AI 接進程式」的關鍵，第 4 章會深入（那裡會談到怎麼用工具/schema 強制它一定吐出合法格式，而不只是「拜託」它）。

🔧 動手試試：挑一段雜亂的文字（一則活動公告、一段商品描述都行），先只說「幫我整理」問一次，再明確要求「整理成表格／JSON，欄位是 X、Y、Z，除此之外不要任何文字」問一次。第二次的輸出會乾淨到你可以直接貼進 Excel 或程式裡——這就是「指定格式」的實際價值。

拆解：複雜任務要「分步」

不要用一個超長 prompt 要求模型「一次做完十件事」。把大任務拆成幾個小步驟，一步一個 prompt，準確度和可控性都會大增。

為什麼拆開就會變好？ 兩個很實際的原因。第一，回到接龍本質：模型在寫每一個字時，注意力是分散在整份 prompt 上的——你塞的要求越多，每個要求分到的「注意力」就越薄，於是它顧此失彼、漏東漏西。第二，一個超長 prompt 一次做完十件事，等於把十個環節綁成一坨，中間哪一步錯了你根本不知道，也沒法單獨重修；拆成一步一個 prompt，就像把一鍋亂燉拆成一道道菜——哪道鹹了，單獨那道重做就好，不必整鍋倒掉。

例如「幫我把這篇會議記錄整理成待辦清單」可以拆成：

先請它摘要會議重點；
再從摘要抽出所有決議與行動項；
最後把行動項排成待辦表格（負責人、期限）。

這樣拆有個隱藏好處：每一步的產出你都能先檢查、修正，再餵給下一步。第 1 步摘要漏了一段，你當場補上，第 2、3 步就不會跟著錯下去——這比「一個 prompt 全做完、錯了整包重來」可控太多了。

再舉一個更貼近日常的例子——「幫我把這份英文產品說明改寫成給長輩看的中文短文」，硬要一步做完，模型常常翻譯腔很重又抓不到重點。拆成三步就順很多：(1) 先忠實翻成中文；(2) 再挑出長輩最在意的三個重點（怎麼用、安不安全、多少錢）；(3) 最後用長輩能懂的白話改寫成一小段。一步一個目標，每步都好檢查、好調整。

這個「拆步驟」的想法，放大到程式層級，就是第 5 章的 AI Workflow——把這些「一步一個 prompt」用程式固定地串起來、自動跑，就成了一條穩定的生產線。

🔧 動手試試：找一件你平常會「一句話丟給 AI」的複雜任務（把一篇文章改寫成三則貼文、把一堆雜記整理成計畫），這次刻意拆成 2～3 步，一步問一次、每步都先看過再往下。跟你「一次丟完」的老做法比比看——你會發現拆開之後，不只結果更好，連「它哪裡做歪了」都變得一眼就抓得到。

常見反模式（新手最容易踩的雷）

反模式	為什麼不好	怎麼修
一次塞十個要求	模型會顧此失彼、漏做	拆步驟，或明列編號需求
指令自相矛盾	「要詳細」又「要簡短」 → 它亂猜	檢查指令有沒有打架
重點埋在最後一行	長 prompt 中間的指令容易被忽略	重要指令放開頭或結尾、加強調
用「不要 X」下指令	模型有時反而更容易做出 X	改成正面說「請做 Y」
假設它記得	它沒有跨對話記憶	需要的背景每次都要給（第 3 章）

這幾個雷背後其實是同一批第 1 章的原理在作祟，點破了就很好記：

「重點埋在最後一行」為什麼危險？ 這正是第 1 章講的「lost in the middle（中間迷路）」——模型對開頭和結尾記得牢、對正中間的東西容易忽略。所以要緊的指令，要嘛放最前面、要嘛放最後，別把它夾在長長一段的中間。
「用『不要 X』下指令」為什麼常常反效果？ 因為你一寫「不要想到粉紅色大象」，粉紅色大象就已經進到 prompt 裡、變成它接龍時會參考的內容了。你越是提到 X，X 在它「腦中」的存在感越強，反而更容易冒出來。這跟人腦是一個道理——叫你「別緊張」通常只會讓你更緊張。

一組「不要 X」→「請做 Y」的實際改寫，感受一下差別：

❌ 寫產品介紹，不要太長、不要用術語、不要太浮誇。
   → 它腦中被塞滿「長、術語、浮誇」，反而可能寫出正是這樣的東西。

✅ 寫產品介紹，控制在 60 字內，用國中生能懂的白話，語氣平實可信。
   → 每個要求都是「正面的、可執行的目標」，它照著做就對了。

⚠️ 特別提醒「不要 X」的陷阱：與其說「不要用專業術語」，不如說「用國中生能懂的白話」。正面示範永遠比負面禁止有效。

🔧 動手試試：把你手邊一個充滿「不要」的指令（「不要太正式、不要太長、不要離題」）翻譯成一串「請做什麼」（「用聊天的口吻、寫三句話、只談這個主題」），兩種各問一次。你會發現「正面版」不只更聽話，連你自己都因為被迫想清楚「那到底要什麼」而更知道自己在要什麼。

把 Prompt 當「程式」來管理

當 prompt 進到產品裡，它就不再是隨手打的字，而是產品的一部分，要像程式一樣認真對待：

版本管理：把 prompt 存進 git，改了要能追、能回退。
A/B 測試：兩版 prompt 到底哪個好？別憑感覺，用第 10 章的評估方法比。
參數化：把會變的部分（使用者名字、日期）抽成變數，別寫死。

為什麼要搞得這麼「工程」？因為在產品裡，prompt 的一個字都可能牽動成千上萬次的輸出品質。舉個實際場景：你把客服機器人的 system prompt 從「請簡短回答」改成「請詳細說明」，覺得這樣更貼心——結果上線後回覆變超長，使用者反而嫌囉唆、客訴變多。如果你有版本管理，一秒就能回退到上一版；如果你有A/B 測試（讓一半使用者用舊版、一半用新版，比數據），你根本不會靠感覺亂改，而是用真實反應決定哪版好。這正是「隨手打的字」和「產品裡的 prompt」最大的差別：後者錯了是有代價的，所以要能追、能比、能回退。

參數化再具體一點：與其每次都手動改成「你好小明，今天是 7 月 9 號……」，不如把 prompt 寫成一個帶空格的模板——「你好 {使用者名}，今天是 {日期}……」——真正執行時再把變數填進去。這樣同一份 prompt 能服務所有使用者，也不會因為手動改字而改錯。（這個「把會變的部分抽成變數」的想法，你在第 1 招「指定輸出格式」給空殼 JSON 時其實已經見過雛形了。）

💡 這裡藏了一條伏筆：Prompt 工程處理的是「這一次要說什麼」；但當對話變長、要塞的東西變多，問題就升級成「有限的視窗裡該放哪些東西」——那就是下一章的 Context 工程。

重點回顧

一則對話有 System / User / Assistant 三種角色；System prompt 是你最強的設計槓桿——它像「角色設定卡」，靠的是把模型的機率表往對的方向調，而不是下鐵令（安全別全押在它上面）。
四個基本功底層是同一件事——把「好答案的前文」佈置好：講明確（收窄它的猜測）、給範例 few-shot（做給它模仿，比講規則準）、要它一步步想 CoT（給它草稿紙，寫得越開想得越深）、指定輸出格式（掐掉贅字，好接進程式）。
複雜任務要拆步驟，不要一個 prompt 塞十件事——拆開後每步都能單獨檢查、單獨重修，錯在哪一眼就看得到。
避開反模式：矛盾指令、重點埋沒（lost in the middle）、用「不要」下令（越提 X 越容易冒出 X）、假設它有記憶。
Prompt 進了產品就是程式：要版控（能回退）、要 A/B（用數據不用感覺）、要參數化（把會變的抽成變數）。

你已經會「講清楚」了。但如果要塞的資料很多、對話很長怎麼辦？下一章談如何管理模型的「工作記憶」——Context 工程。