2026年3月5日·9 min 閱讀

Claude Prompt 工程實戰技巧：讓 AI 輸出更精準

ClaudePrompt EngineeringAI技術筆記

為什麼 Prompt 很重要

同樣的 AI 模型，不同的 prompt 可以產生天差地別的結果。Prompt Engineering 不是在「哄」AI，而是在用它能理解的方式，精確地傳達你的需求。

這篇文章整理了我們在實際專案中使用 Claude 時，累積的一些實用技巧。

基礎技巧

明確指定輸出格式

如果你需要特定格式的輸出，直接告訴 Claude：

分析以下租屋資料，找出異常值。

請以 JSON 格式回傳，結構如下：
{
  "total_records": 數字,
  "anomalies": [
    {
      "record_id": "ID",
      "field": "有問題的欄位",
      "value": "異常值",
      "reason": "為什麼異常"
    }
  ],
  "summary": "一句話總結"
}

使用分隔符號區分內容

當 prompt 中混合了指令和資料時，用清楚的分隔符號避免混淆：

請將以下文章翻譯成英文，保持技術用語不變。

---文章開始---
Next.js 的 App Router 是新一代的路由系統，
支援 React Server Components...
---文章結束---

翻譯時注意：
1. 「元件」翻譯為 "component"
2. 保留所有程式碼片段不翻譯

指定角色與背景

給 Claude 一個具體的角色，能讓回答更有針對性：

你是一位有 10 年經驗的資料庫管理員，
專精 PostgreSQL 效能調校。

我有一張 wait_times 資料表，目前有 500 萬筆紀錄，
以下是目前的查詢和執行計畫。
請分析瓶頸並給出優化建議。

進階技巧

思維鏈（Chain of Thought）

對於需要推理的複雜問題，要求 Claude 展示思考過程：

以下是一段爬蟲程式碼，它偶爾會漏抓資料。
請一步一步分析可能的原因：

1. 先理解程式碼的執行流程
2. 找出每個可能失敗的環節
3. 分析每個環節失敗的條件
4. 給出最可能的原因和修復方案

{程式碼}

加上「一步一步」的引導，Claude 會更系統性地分析問題，而不是直接跳到結論。

Extended Thinking

Claude 支援 Extended Thinking（延伸思考）功能，讓模型在回答前先進行更深入的內部推理：

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6-20250320",
    max_tokens=8000,
    thinking={
        "type": "enabled",
        "budget_tokens": 5000
    },
    messages=[{
        "role": "user",
        "content": "分析這段程式碼的時間複雜度，考慮所有邊界情況..."
    }]
)

Extended Thinking 適合用在需要深度推理的場景，例如複雜的演算法分析或架構設計決策。

Few-shot 範例

提供幾個範例，讓 Claude 理解你要的模式：

請將以下的原始地址標準化。參考這些範例：

輸入：「台北市信義區信義路五段7號89樓」
輸出：「台北市信義區信義路五段7號」

輸入：「新北市板橋區文化路一段 266 號 3F-2」
輸出：「新北市板橋區文化路一段266號」

輸入：「桃園市中壢區中大路300號（中央大學內）」
輸出：「桃園市中壢區中大路300號」

現在處理以下地址：
1. 「高雄市左營區博愛二路 366 號 12樓之3」
2. 「台中市西屯區臺灣大道四段 1727 號（東海大學旁）」
3. 「台南市東區大學路１號 成功大學」

Few-shot 範例比長篇的規則說明更有效，因為模式比規則更容易學習。

限制與約束

明確告訴 Claude 什麼「不要做」，有時比告訴它「要做什麼」更重要：

幫我重構以下程式碼。

約束條件：
- 不要改變任何函式的公開介面（參數和回傳值）
- 不要新增任何第三方套件
- 不要修改測試檔案
- 保持現有的錯誤處理邏輯

特定場景的 Prompt 模板

程式碼審查

請審查以下程式碼，重點關注：

1. **正確性**：邏輯是否有 bug
2. **安全性**：是否有 XSS、SQL Injection 等漏洞
3. **效能**：是否有明顯的效能問題
4. **可維護性**：命名、結構是否清晰

對每個發現的問題：
- 說明問題是什麼
- 解釋為什麼是問題
- 提供修改建議（附程式碼）

如果沒有問題，直接說「看起來沒問題」，不需要硬找問題。

{程式碼}

最後一句很重要——避免 Claude 為了「表現有用」而硬挑毛病。

SQL 查詢生成

資料表結構：

rides (id, name, park_id, category)
wait_times (id, ride_id, wait_minutes, status, recorded_at)
parks (id, name, timezone)

需求：
找出過去 7 天內，每個設施在「每個小時」的平均等待時間，
只包含狀態為 'operating' 的紀錄。
結果按設施名稱排序，再按小時排序。

請使用 PostgreSQL 語法，並加上註解說明每一段的用途。

資料分析

以下是過去 30 天的網站流量數據（CSV 格式）。

請分析：
1. 整體趨勢（是否成長、衰退或持平）
2. 週間 vs 週末的差異
3. 是否有異常的高峰或低谷
4. 如果有異常，推測可能的原因

請用非技術人員也能理解的方式說明。
數據中如果有任何不合理的值，請標記出來。

{CSV 資料}

常見錯誤

過度詳細的指令

# 太囉唆
請用 Python 語言，使用 def 關鍵字定義一個函式，
函式名稱為 calculate_average，接收一個參數 numbers，
這個參數是一個 list 型態，裡面包含浮點數...

# 簡潔有效
寫一個 Python 函式 calculate_average(numbers)，
計算數字列表的平均值。處理空列表的情況。

多重目標的長 prompt

一個 prompt 做一件事。如果你需要 Claude 做五件不同的事，分成五次對話會比塞在同一個 prompt 裡效果好得多。

忘記處理邊界情況

# 容易忽略的
幫我寫一個解析日期的函式

# 更完整的
幫我寫一個解析日期的函式，支援以下格式：
- "2026-03-20"
- "2026/03/20"
- "20260320"

如果輸入格式不符，回傳 None 而不是拋出錯誤。

迭代改進

Prompt Engineering 很少一次就完美。實用的迭代流程：

先寫一個簡單的 prompt，看 Claude 的回應
找出不符合預期的地方，思考是指令不清楚還是缺少脈絡
針對性地修改 prompt，而不是推倒重寫
保留有效的 prompt 模板，建立自己的 prompt 庫

在我們的專案中，常用的 prompt 會存在專案的 prompts/ 目錄中，方便團隊成員共用和迭代。

結語

好的 Prompt Engineering 核心就三個字：說清楚。清楚地說明你要什麼、不要什麼、輸入是什麼、輸出要什麼格式。

把 Claude 當成一個能力很強但不了解你脈絡的同事——你不會只說「幫我處理一下那個東西」，你會說「幫我把這份 CSV 的地址欄位標準化，規則是 XYZ」。同樣的溝通原則，套用在 AI 上也一樣有效。