你每天都在使用提示詞。

只是你不知道自己在做的事情有什麼名稱而已。

每次你在 ChatGPT 輸入「修正這個錯誤」或在 Cursor 輸入「重構這個函式」——這就是一種提示技巧。你其實一直都在做，只是沒人告訴你，這件事有十種不同的做法，而且其中大多數都比你現在正在做的更好。

我為了我的深度學習考試，必須把這些全都學起來。兩份各 50 頁的 PDF，裡面全是學術範例，像是 「推薦科幻小說」 和 「把 0°C 轉成華氏溫度」。技術上沒錯，實際上毫無用處。沒有人會打開 ChatGPT 來做攝氏轉換。

所以，這裡是我希望那些 PDF 應該要有的版本——把我課綱裡的每一種技巧都用開發者真正會用到的例子講清楚。

目錄

• 1. Zero-Shot Prompting
• 2. Few-Shot Prompting
• 3. Chain-of-Thought Prompting
• 4. Tree-of-Thought Prompting
• 5. Role-Playing Prompts
• 6. Generated Knowledge Prompting
• 7. Maieutic Prompting
• 8. Least-to-Most Prompting
• 9. Format-Specific Prompting
• 10. Multi-Turn Prompting
• 速查表
• 🧪 真正的技巧：把它們組合起來

1. Zero-Shot Prompting

它是什麼： 你直接問 AI 問題。沒有範例、沒有上下文、沒有手把手教學。就只是問題本身。

教科書範例：

「你可以推薦科幻小說嗎？」

開發者範例：

「React 裡的 useEffect 清理函式是做什麼的？」

或者：

「請用 3 句話解釋 git rebase 和 git merge 的差異。」

你其實早就在用了。每次你完全沒提供上下文就把錯誤訊息貼進 ChatGPT 然後祈禱——那就是 zero-shot prompting。對於模型看過無數次的問題，它非常有效。但只要你的問題稍微小眾一點，它就會開始失效。

什麼時候用： 快速查詢、語法問題、「X 是做什麼的」這類問題。任何 AI 預訓練知識已經足夠處理的事情。

什麼時候失效： 只要你的問題涉及你的程式碼庫、你的架構，或任何模型沒被訓練過的內容，就會開始失效。這時候就需要下一種方法。

2. Few-Shot Prompting

它是什麼： 你先給 AI 2～5 個你要的範例，讓它自己推測規則，然後把這個規則套用到新的輸入上。

教科書範例：

將攝氏轉換成華氏：
0°C → 32°F
25°C → 77°F
100°C → ？

開發者範例：

假設你在幫團隊寫 commit message，並且想維持一致風格：

這是我目前的 commit message：

feat: add user authentication with JWT
fix: resolve null pointer in payment service
refactor: extract validation logic into middleware

現在請為這個需求寫一則 commit message：我在 API endpoints 加入了 rate limiting。

輸出：

feat: add rate limiting to API endpoints

模型會自動抓出你的前綴慣例（feat:、fix:、refactor:）、句首大小寫風格、細節程度——而你不用多做任何解釋。

另一個真實用途： 你正在把舊版 API 回應格式轉成新版。先給 3 組舊格式 → 新格式的範例，再貼上第 4 組舊回應，讓模型幫你轉換。這樣你就不用特地寫一支一次性的腳本。

什麼時候用： 一致格式、風格模仿、重複性轉換。任何你在想「我還要再做這個同樣的事情 40 次」的時候。

3. Chain-of-Thought Prompting

它是什麼： 你要求 AI 有條理地解題——一步一步來——而不是直接跳到結論。

教科書範例：

23 × 47 等於多少？請展示你的計算過程。

開發者範例：

這個函式本來應該在折扣後回傳總金額，但某些輸入下卻回傳 NaN。請一步一步帶我看發生了什麼：

function getTotal(price, discount) {
  const total = price - (price * discount / 100);
  return total.toFixed(2);
}

如果沒有「一步一步」，AI 很可能只會說「這個函式看起來沒問題。」加上這句之後，AI 就會追蹤 edge case：「如果 discount 傳進來的是像 '10%' 這樣的字串，乘法運算就會產生 NaN，接著這個 NaN 會一路傳遞到最終計算……」

要求一步一步拆解，不一定會揭露模型真正的內部推理過程——但它確實會讓回答更容易檢查：有哪些假設、中間檢查了什麼、考慮了哪些 edge case，最後才下結論。這種結構，才讓錯誤更容易被抓出來。

我就是這樣抓到某個專案 service worker 裡 clients.matchAll() 的 race condition。Copilot 第一個答案很有自信，結果完全錯了。我要求它一步一步走過事件生命週期——不是「修這個」，而是「追蹤這兩個事件之間發生了什麼」——這才真的把 timing bug 找出來。

什麼時候用： Debug、code review、任何「推理過程」比答案本身更重要的問題。如果你曾經被 AI 給過一個很有自信但完全錯誤的答案——這很可能就是少了這個技巧。

4. Tree-of-Thought Prompting

它是什麼： AI 不只走一條推理路徑，而是同時探索多條路徑。Chain-of-thought 是直線；tree-of-thought 是決策樹。

教科書範例：

分開列出氣候變遷的環境影響與社會影響。

開發者範例：

我需要在我的 app 裡加入即時通知。請探索三種不同做法——WebSockets、Server-Sent Events 和 polling——並針對每一種說明在複雜度、擴充性與瀏覽器支援上的取捨。最後請推薦哪一種最適合一個使用 Node 後端的小團隊。

這樣就不是讓 AI 隨便挑一個然後硬辯護它（zero-shot 常常會這樣），而是把比較過程明確化，而不是讓 AI 直接跳到某個推薦結論。

另一個真實用途： 架構決策。「我們需要儲存使用者 session。請比較 Redis、資料庫 session 和 JWT token。每一種都列出優點、缺點與失效模式，然後推薦一個適合兩人團隊做 MVP 的方案。」

什麼時候用： 任何有多種合理選項、你需要 AI 幫你比較而不只是選一個的情境。技術棧選擇、架構決策、當你不確定是哪個子系統有問題時的除錯。

5. Role-Playing Prompts

它是什麼： 你告訴 AI 扮演某個特定專家。這不是噱頭——它真的會改變回答的深度與角度。

教科書範例：

「假設你是一位資深創投，請評估這個新創公司的簡報。」

開發者範例：

你是一位正在進行 code review 的資深後端工程師。請審查這段 Express.js 路由處理器，並標出任何安全漏洞、效能問題或架構疑慮。請具體一點——指出行號並解釋為什麼這是個問題。

沒有角色設定時，AI 給你的通常只是禮貌又泛泛的評論。有角色設定時，它就會開始像那種真的會抓問題的資深工程師——「第 14 行：你把使用者輸入直接插入 SQL 查詢。這是教科書等級的 SQL injection 漏洞。」

我在求職季也反過來這樣用過：「你是一位產品型公司裡很嚴格的技術面試官。請針對這個專案追問我，直到你找到我理解上的漏洞。」 這很不舒服，但它也是你在真正面試前，最接近免費的模擬練習。

其他真的有幫助的角色：

• 「你是一位技術招募主管。這份履歷有哪些不足？」
• 「你是一位 QA 工程師。請找出這個函式的 edge cases。」
• 「你是一位 DevOps 工程師。這份 Dockerfile 有什麼問題？」

什麼時候用： Code review、履歷回饋、面試準備、從你團隊裡沒有的角度取得第二意見。角色設定能把 AI 的注意力縮小到那個特定專家會在意的事情。

6. Generated Knowledge Prompting

它是什麼： 在請 AI 做正式任務之前，先叫它列出它對主題所知道的一切。先研究，再寫作。

教科書範例：

「請寫一篇關於森林砍伐的文章。先列出重點事實。」

開發者範例：

我需要為我們的驗證流程寫文件。在你開始寫之前：

1. 列出從使用者點擊「登入」到他們進入儀表板為止，所發生的每一個步驟——包含 token 產生、cookie 處理與 redirect 邏輯。
2. 然後根據這份清單撰寫開發文件。

這裡的關鍵是第 1 步。透過強迫 AI 先生成知識基礎，你會得到一個更有事實依據的底層，再讓寫作建立在這個基礎上。若沒有這一步，AI 常常會寫出很泛的文件，卻漏掉你實際的流程。

什麼時候用： 撰寫文件、README、技術部落格文章（很諷刺，對吧？），或任何比創意更重視事實準確性的任務。先「列出你知道的內容」這一步，等於是一種自我查核。

7. Maieutic Prompting

它是什麼： 這個名稱來自蘇格拉底式方法——你先問一個問題，接著再要求 AI 更深入解釋它自己的答案，再更深入一次。透過遞迴式提問，直到你真的理解。

教科書範例：

「請解釋天空為什麼是藍色的。然後再解釋為什麼藍光比較容易散射。」

開發者範例：

為什麼我的 React component 明明用了 useMemo，卻還是會在每次 state 變更時重新 render？

現在請進一步解釋為什麼 dependency array 對 useMemo 特別重要。

現在請解釋什麼是 JavaScript 物件脈絡下的「引用相等性」（referential equality），以及它為什麼會破壞 memoization。

每一次追問都會逼 AI 往更深一層走。到了第三個問題，你已經不是只知道「它在重新 render」，而是理解 JavaScript 的物件比較模型，如何從根本上和 React 的 reconciliation 演算法互動。

什麼時候用： 學習新概念。當第一個答案看得懂，但你能感覺到底下還有些你沒完全理解的東西。這就是「可是為什麼？」技巧。

8. Least-to-Most Prompting

它是什麼： 你先要求 AI 把大問題拆成子問題，再依序解決。先分解，再執行。

教科書範例：

「請列出解 3x + 5 = 20 的子問題，然後逐一解答。」

開發者範例：

我需要在我的 Next.js app 加入 Google OAuth。請把這件事拆成我需要依序解決的每個子問題。然後請帶我一步一步完成，並附上程式碼。

輸出可能會像這樣：

1. 建立 Google Cloud Console 專案並取得憑證
2. 安裝並設定 NextAuth.js
3. 建立驗證 API route
4. 加入 Google provider 設定
5. 使用 session 檢查保護路由
6. 處理 callback 並儲存使用者資料

然後 AI 會依序解決每個問題，而每一步都建立在前一步之上。

這基本上就是我每次 hackathon 截止前能活下來的方式——把「在 24 小時內做出可運作的 demo」拆成一個真正有順序的流程，而不是盯著整個範圍然後開始恐慌。

什麼時候用： 實作你從沒做過的功能。與其問「我要怎麼加 auth」（通常只會得到很空泛的概述），不如強迫 AI 給你一個真的能照著做的順序。

9. Format-Specific Prompting

它是什麼： 你明確告訴 AI 你想要的輸出格式。條列、表格、JSON、markdown、CSV——直接指定，AI 就會照做。

教科書範例：

「請用條列式列出前 5 部電影。」

開發者範例：

比較這三個 React state management 函式庫。請用 markdown 表格輸出，欄位為：Library、Bundle Size、Learning Curve、Best For、Drawback。

或者：

請把這段錯誤日誌轉成 JSON 陣列，每個物件都要有 timestamp、level、message 和 source 欄位。

這是最被低估的技巧之一。很多開發者不指定格式，然後再花 5 分鐘重排 AI 的回答。你只要一開始就講清楚就好。

什麼時候用： 幾乎每次你需要特定輸出形狀時都該用。表格、JSON、程式碼區塊、條列、編號步驟。只要你最後還是要自己重排輸出，那就是在浪費時間。

10. Multi-Turn Prompting

它是什麼： 在對話中透過多輪訊息累積上下文。每個提示都建立在前一輪回覆之上。這就是你把 AI 從搜尋引擎變成協作者的方式。

教科書範例：

第 1 輪：「請摘要這篇文章。」
第 2 輪：「現在把它改寫成給 10 歲小孩看的版本。」
第 3 輪：「再加 3 題測驗題。」

開發者範例：

第 1 輪：「這是我的 Express app 資料夾結構。[貼上 tree 輸出]。請解釋這個架構。」

第 2 輪：「現在我想新增一個通知服務。它應該放在這個結構的哪裡，應該 import 什麼？」

第 3 輪：「請依照現有服務的模式，為這個服務寫 boilerplate。」

第 4 輪：「現在請為它寫測試，並且要符合 __tests__/user.service.test.js 的測試風格。」

到了第 4 輪，AI 已經知道你的資料夾結構、架構模式、命名慣例，以及測試風格。單次提問根本不可能產出這麼貼合的內容。

什麼時候用： 任何比較大的 coding 任務。做功能、重構、寫測試。如果你每次都在重複貼上相同上下文，你就應該改用 multi-turn。

速查表

🧪 真正的技巧：把它們組合起來

重點是這個：你不需要只選一種技巧然後一路用到底。 最好的提示詞通常會結合兩種或三種。

Chain-of-thought + role-playing： 「你是一位資深工程師。請一步一步除錯這個函式。」

Few-shot + format-specific： 「這裡有我三個 commit message 的範例。請用相同風格寫出接下來五個，並用條列式輸出。」

Generated knowledge + least-to-most： 「列出部署 Next.js app 到 AWS 所涉及的一切。然後把它拆成子問題，帶我逐一完成。」

這些技巧就像食材。真正的功夫，是知道哪些該一起搭配。

我就是從兩份充滿攝氏換算和科幻小說推薦的學術 PDF 學會了這一切。現在，你是從一些明天就會真的打開終端機來用的例子學會它。

如果這讓你省下了 50 頁教科書式排版閱讀——不客氣。

你最常用、但不在這份清單上的提示技巧是什麼？ 或者這裡面哪一個你以前不知道它有名字？

留在下面吧——我真的很好奇，大家都在做哪些教科書還沒跟上的事。👇

原文出處：https://dev.to/dj29/10-prompting-techniques-my-deep-learning-exam-taught-me-that-i-actually-use-now-43h0