Prompt 寫法實戰：同一個需求，好的和壞的 Prompt 差在哪？

很多人覺得 AI 不好用，問題往往不在 AI，而在我們怎麼交代事情。

網路上流傳很多「萬用咒語」，例如「你是一位頂尖專家」「請一步一步思考」。這些不是完全沒用，但都不是重點。

我的看法是：寫 Prompt 跟交代一位很聰明、但完全不了解你公司的新同事做事，是同一件事。你交代得越清楚，他做得越好。

這篇用三組實際例子，看看同一個需求，好的和壞的 Prompt 差在哪裡。

例子一：寫商品文案

❌ 壞的寫法

幫我寫一段手搖飲的行銷文案

AI 會寫出一段四平八穩、放在哪家店都可以用的文案。問題不是 AI 寫得差，而是它什麼都不知道：哪家店？什麼飲料？給誰看？放在哪裡？

✅ 好的寫法

幫我寫 LINE 官方帳號的推播文案，宣傳本週新品「桂花烏龍鮮奶」。

背景：
- 我們是台中的手搖飲店，客群以附近大學生為主
- 新品特色：桂花香氣明顯、甜度可調、用的是台灣在地烏龍茶
- 本週活動：新品第二杯半價，只到週日

要求：
- 150 字以內，語氣輕鬆、像朋友推薦
- 開頭第一句就要讓人想點開
- 結尾要有明確的行動呼籲
- 請給我三個不同風格的版本

差別在於：平台、目的、受眾、產品特色、活動內容、字數、語氣、要幾個版本，全部交代清楚了。

例子二：整理會議紀錄

❌ 壞的寫法

幫我整理這份會議紀錄
（貼上逐字稿）

「整理」可以是摘要、可以是條列、可以是改寫，AI 只能用猜的。

✅ 好的寫法

以下是今天產品會議的逐字稿，請整理成會後要寄給全體與會者的紀錄。

格式：
1. 會議結論（3～5 點）
2. 待辦事項表格：事項｜負責人｜期限
3. 尚未決定、下次要討論的問題

注意：
- 逐字稿裡沒有明確提到的負責人或期限，請填「待確認」，不要自己推測
- 閒聊和離題內容不用放

<逐字稿>
（貼上逐字稿）
</逐字稿>

這裡有兩個重點：一是說清楚這份東西要給誰、拿來做什麼；二是用 <逐字稿> 這樣的標籤把資料和指令隔開，AI 比較不會把資料內容誤當成指令。

例子三：請 AI 修 Bug

❌ 壞的寫法

登入功能壞了，幫我修

✅ 好的寫法

登入功能有 bug，請幫我找出原因並修正。

現象：輸入正確帳密後會被導回登入頁，沒有任何錯誤訊息。
重現步驟：清除 Cookie → 開啟 /login → 輸入測試帳號 → 按登入
預期結果：導向 /dashboard
相關檔案：應該在 app/Http/Controllers/AuthController.php 或 session 設定
環境：Laravel，本機正常，只有正式機會發生

請先說明你判斷的可能原因，等我確認後再修改程式碼。

這就是工程師熟悉的 bug report 格式：現象、重現步驟、預期結果、環境。最後那句「先說明原因，確認後再改」也很重要，可以避免 AI 一路改錯方向。這一點在〈Claude Code 省 Token 技巧〉裡也提過。

好 Prompt 的四大要素

把上面三個例子歸納起來，好的 Prompt 一定要把這四件事定義清楚：

要素	要回答的問題	例子
角色	AI 要用什麼身分、什麼標準來做事？	「你是負責這個 Laravel 專案的資深後端工程師」
任務	具體要做什麼？做完的樣子是什麼？	「寫三個版本的推播文案」
情境與限制	背景、路徑、規格、現況是什麼？有什麼規則要遵守？	檔案位置、客群、字數、語氣、不要推測
輸出格式	結果要長什麼樣子？	條列、表格、JSON、某種程式碼結構

其中最常被寫得太簡略的，是情境與限制。我的經驗是：你對要做的事情理解得越細，路徑、規格、會遇到的狀況交代得越清楚，AI 的結果就越精準。AI 不缺能力，缺的是只有你知道的那些細節。

如果手邊有好的樣本，例如一篇你很滿意的舊文案、一段寫得很好的程式碼，也可以一起附上當範例，效果通常會再好一截。

寫之前可以快速檢查一遍：一位第一天上班的新同事，看了這段話能不能把事情做好？

進階：定義你的風格，讓 AI 寫得像你

這是我覺得最值得投資的一件事。

如果你會反覆請 AI 寫同一類東西，例如程式碼、文章、客服回覆，與其每次都重新交代，不如先把你的風格和做法寫成一份規範，讓 AI 每次都照著做。

以寫程式為例，我會把這些寫進專案的規範檔：

# 程式風格與做法

## 架構
- Controller 只負責接收請求和回應，商業邏輯一律放在 app/Services/
- 資料庫查詢集中在 Repository，Controller 不直接寫查詢
- 新增 API 時，同時建立 FormRequest 做輸入驗證

## 寫法
- 變數與函式命名用 camelCase，資料表欄位用 snake_case
- 函式盡量控制在 30 行以內，超過就拆
- 錯誤一律丟出自訂 Exception，由統一的 Handler 處理
- 不使用魔術數字，狀態值一律定義成常數或 Enum

## 效能
- 列表查詢一律分頁，並檢查是否有 N+1 問題
- 會重複讀取的設定值要加快取

## 範例
（貼一段你認為寫得最標準的程式碼）

在 Claude Code 這類工具裡，這份規範可以直接寫進 CLAUDE.md，每次都會自動載入，做法可以參考〈Claude Code 省 Token 技巧〉。

這樣做的效果很明顯：AI 接下來寫出來的程式碼，很多時候看起來就像你自己寫的，因為命名、結構、錯誤處理的習慣都一樣。對團隊來說也是好事，大家用同一份規範，AI 產出的程式碼風格就會一致，審查起來輕鬆很多。

同樣的道理也適用在其他地方：客服回覆的語氣、文章的寫作風格、報表的格式，都可以先寫成規範。

輸出格式要「非常嚴格」時怎麼辦？

一般用途，在 Prompt 裡寫清楚格式、附上範例就夠了。但如果你是把 AI 串進系統，程式要直接解析 AI 的輸出，例如一定要是某個固定結構的 JSON，少一個欄位程式就會壞掉，光靠 Prompt 就不夠保險了。

依嚴格程度，可以這樣處理：

做法	說明	適合
Prompt＋範例	在 Prompt 寫清楚格式並附上範例	給人看的內容，格式稍有出入沒關係
API 的結構化輸出	主流 AI 平台的 API 都能指定 JSON Schema，由系統在產生內容時直接限制格式，保證輸出符合結構	程式要解析的 JSON 資料
程式驗證＋重試	收到結果後用程式檢查格式，不符合就自動重新請求	搭配上面任一種，多一層保險

所以只要是程式要直接解析的資料，建議直接使用 API 的結構化輸出，再加上一層程式驗證，就能穩定拿到正確格式的結果。

常見迷思

迷思	我的看法
寫一句「你是一位專家」就夠了	角色很重要，但只寫「你是專家」太空泛。好的角色設定要帶出立場和標準，例如「你是負責這個專案的資深後端工程師，重視可讀性和安全性」，再搭配具體的情境資訊
全大寫、「一定要」「絕對不能」比較有效	對現在的模型反而可能矯枉過正，讓它在不相關的地方也過度執行這條規則。正常語氣說明原因，效果通常更好
Prompt 越長越好	重要的是資訊完整，不是字數多。不相關的內容反而會稀釋重點
只寫「不要做什麼」就好	告訴它「該怎麼做」比只列禁止事項更有效。例如與其說「不要寫太長」，不如說「150 字以內」
有萬用模板可以套	模板可以當檢查清單，但每個任務需要的背景都不一樣，最後還是要自己補內容

五個實用技巧

說明「為什麼」：例如「這份摘要是給沒參加會議的主管看的」，AI 會自己判斷什麼該保留，比你列一堆規則更有效。
用標籤隔開資料：像 <資料>、<逐字稿> 這樣把要處理的內容包起來，指令和資料就不會混在一起。
給它問問題的機會：在結尾加一句「如果資訊不足，請先問我」，可以避免它硬著頭皮亂猜。
大任務先要計畫：先請它列出步驟或大綱，確認方向後再執行。
結果不好就改 Prompt，不要只按重新產生：想想是哪個資訊沒給清楚，補上之後再試。

在系統裡，Prompt 就是程式碼

如果你是透過 API 把 AI 串進系統，Prompt 的地位就不一樣了，它應該被當成程式碼管理：

放進版本控制：每次修改都要能追蹤、能回復
準備測試案例：準備一批固定的輸入，每次改 Prompt 都跑一次，比較結果有沒有變好
分清楚系統指令和使用者輸入：固定的規則放在系統提示詞，使用者輸入的內容要和指令隔開，降低被惡意輸入操控的風險
換模型時重新測試：同一段 Prompt 在不同模型上的表現可能差很多

這和〈RAG 入門〉提到的「測試題庫」是同一個概念：沒有測試，優化就只是憑感覺。

我的看法：技巧會過時，溝通能力不會

早期的模型比較笨，所以大家發明了各種「咒語」來繞過它的弱點。但隨著模型越來越聰明，很多技巧已經不需要了，有些甚至會造成反效果。

真正不會過時的，是把需求想清楚、說清楚的能力。你會發現，寫好 Prompt 需要的技能，跟寫好一份需求文件、交代好一件工作，幾乎一模一樣。

換句話說，AI 時代最值錢的能力之一，其實是溝通。

速查：好 Prompt 檢查清單

送出之前，花十秒檢查：

☐ 我有定義 AI 的角色嗎？
☐ 任務和完成的樣子清楚嗎？
☐ 情境與限制（路徑、規格、狀況、規則）都交代了嗎？
☐ 有說明輸出格式和長度嗎？
☐ 會反覆用到的風格，寫成規範了嗎？
☐ 要處理的資料有用標籤隔開嗎？
☐ 資訊不足時，我有讓它先問我嗎？

參考資料