[ai/05] Prompt Engineering：讓 AI 聽話的實用技巧

cover

先講結論

Prompt Engineering 沒有什麼神秘的——就是四件事：

給角色（System Prompt）：告訴 AI 它是誰，回答風格怎樣
給範例（Few-shot）：CP 值最高的技巧，給 2-3 個範例勝過寫 500 字描述
要求分步驟（Chain-of-Thought）：複雜問題不要讓 AI 直接跳到答案
指定輸出格式：你要 JSON 就說 JSON，不然 AI 給你寫散文

這四個搞定，你的 AI 使用體驗會直接升一個檔次。剩下那些什麼 temperature 調參、negative prompting，等你把基本功練好再說。

我是怎麼踩坑的

老實說，我剛開始用 AI 寫程式的時候，prompt 大概是這樣：

幫我寫一個 API

然後 AI 給我一個用 Python Flask 寫的、沒有 error handling 的、變數名叫 x 的東西。我心裡想：AI 也不過如此嘛。~~結果是我自己不會問問題。~~

後來我學會了同一個需求要這樣說：

用 Express.js + TypeScript 寫一個 GET /api/users/:id 的 endpoint，
從 PostgreSQL 查詢使用者資料，回傳 JSON，包含 error handling。

差別有多大？前者像是跟計程車司機說「載我去那邊」，後者像是說「到信義區松仁路 100 號」。你不把地址說清楚，能怪司機開錯路嗎？

技巧一：System Prompt 設定角色

System Prompt 就是 AI 的「人設」。你不設定，它就用預設的——什麼都很客氣、什麼都講一堆廢話、動不動就「這是一個很好的問題」。

我目前最常用的 System Prompt 長這樣：

你是一位有 10 年經驗的 Senior Backend Engineer，專精 Node.js 和 PostgreSQL。
回答風格：
- 直接給解法，不要廢話
- 程式碼要包含 error handling 和 TypeScript 型別
- 如果有多種做法，列出 pros/cons 讓我選
- 如果我的做法有安全風險，主動提醒

設了這個之後，AI 回答的品質跟沒設完全是兩個世界。為什麼？因為角色設定會影響它選擇哪些知識來回應。你跟它說你是 junior，它給你的答案會比較保守；你跟它說你是 senior，它就敢給你更進階的方案。

一個小技巧：把你團隊的 coding style 也塞進去，像是「用 Result pattern 不用 try-catch」「error message 用英文」，這樣生出來的 code 不用二次修改。

技巧二：Few-shot——給範例就對了

如果只能記住一個技巧，記這個。

與其花 200 字描述你要什麼輸出格式，不如直接給 2 個範例。AI 看到範例會自己抓出 pattern。

請幫我把 API 文件轉成 TypeScript interface。

範例：
輸入：GET /users - 回傳 {id: number, name: string, email: string}
輸出：
interface User {
  id: number;
  name: string;
  email: string;
}

請轉換：
GET /orders - 回傳 {id: number, items: [{productId: number, quantity: number}], total: number, status: "pending" | "completed"}

我有一次不給範例，請 AI 把 log 轉成 JSON。它回我一個 key 全部大寫、timestamp 格式亂來的 JSON。給了一個範例之後，它就完全照著範例的命名風格和格式走。

重點：AI 不只學內容，也學格式。 你的範例用 camelCase，它的輸出就是 camelCase；你的範例用 snake_case，它就跟著 snake_case。

技巧三：Chain-of-Thought——讓 AI 慢慢想

遇到比較複雜的問題（debug、架構設計、效能分析），不要讓 AI 直接噴答案。要求它分步驟思考，正確率會高很多。

請分析這個演算法的時間複雜度。
步驟：
1. 先辨識每個迴圈和遞迴的結構
2. 分別標出每一層的複雜度
3. 推導整體複雜度
4. 最終答案（Big-O）

[貼上程式碼]

跟直接問「這個時間複雜度是什麼」比起來，要求分步思考在巢狀迴圈和遞迴的場景下，正確率明顯比較高。我之前遇過一個三層巢狀的遞迴函數，直接問 AI 它說 O(n^2)，用 CoT 問它一步步拆完之後改口說 O(n^3)——後者才是對的。

什麼時候用 CoT？我的經驗法則是：如果你自己也需要想超過 30 秒的問題，就該用 CoT。

技巧四：指定輸出格式

這在寫自動化腳本的時候特別重要。你要 AI 吐 JSON，就明確告訴它 JSON schema 長怎樣：

請分析以下程式碼的問題，用這個 JSON 格式回答：
{
  "issues": [
    {
      "severity": "high | medium | low",
      "line": "行號",
      "description": "問題描述",
      "suggestion": "修改建議"
    }
  ],
  "overallScore": "1-10"
}

不指定格式會怎樣？AI 有時候給你 Markdown、有時候給你純文字、有時候還加一段「希望這對你有幫助！」的客套話，你的 JSON.parse() 直接炸掉。~~問我怎麼知道的？別問。~~

常見錯誤（我全踩過）

太模糊——「幫我改善這段程式碼」。改善什麼？效能？可讀性？安全性？你不說清楚，AI 就隨便改一改交差。

塞太多指令——一個 prompt 塞 15 條要求，AI 很可能忽略其中一半。不如拆成多輪對話：第一輪寫基本功能、第二輪加 error handling、第三輪補 test。

不給 context——AI 不知道你用什麼框架、什麼版本、團隊的 coding convention。你覺得「這不是顯而易見嗎」的事情，AI 真的完全不知道。

不迭代——很少有一次就完美的 prompt。第一次拿到結果後追問「error handling 不夠完整，請補上 network timeout 的情況」，這才是正常流程。Prompt Engineering 是對話，不是一次性指令。

Terry Yao's Blog

分類

目錄