跳到主要內容
/
aiclaudeprompt-engineeringdeveloper-tools

Claude Prompt Engineering 實戰：讓回應品質提升 10 倍的技巧

avatar
Akira@@akiraxtwo

你一定有過這種經驗：同一個問題，問 Claude 兩次，得到完全不同品質的回答。第一次給你一堆廢話，第二次精準到讓你懷疑是不是換了模型。

差別不在模型。在你怎麼問。

Prompt engineering 不是玄學。它是一套可以學、可以複製的技術。這篇文章整理了四個在 Claude 上特別有效的核心技巧，每個都附上實際對比，讓你看到差距有多大。

Claude 和 GPT 的 prompting 差異

先講結論：大部分在 GPT 上有效的技巧，在 Claude 上也有效，但有幾個關鍵差異。

Claude 更聽指令。 如果你在 prompt 裡說「只回答是或否」，Claude 真的只會回答是或否。GPT 有時候會忍不住多解釋幾句。這意味著你在 Claude 上可以更精確地控制輸出格式。

Claude 對 XML 標籤特別敏感。 這是 Claude 最獨特的優勢——用 XML 結構化你的 prompt，Claude 的理解能力會顯著提升。GPT 也能讀 XML，但效果沒有那麼明顯。

Claude 更擅長長文脈。 200K token 的 context window 不只是數字大，Claude 在長文脈中的注意力分配比同級模型更穩定。這意味著你可以放心地給它大量參考資料，不用擔心「放太多反而搞混」。

Claude 比較不會幻覺。 當它不確定的時候，更傾向說「我不確定」而不是編一個聽起來很合理的答案。你可以利用這個特性，在 prompt 裡加上「如果不確定，請直接說不知道」來進一步降低幻覺率。

技巧一：角色設定 — 不是裝飾，是校準

爛 prompt：

幫我寫一個 landing page 的文案

好 prompt：

你是一位專注於 SaaS 產品的資深文案寫手。你的風格是簡潔、直接、
避免行銷術語。目標讀者是台灣的獨立開發者，他們對誇張的行銷文案
有天然的抵抗力。

請為一個 AI 學習平台撰寫 landing page 的 hero section 文案。

差異在哪？角色設定不是讓 AI「扮演」什麼人。它的作用是校準輸出的風格、深度和目標受眾。當你說「資深文案寫手」，Claude 會自動調整用詞的精準度；當你說「目標讀者是獨立開發者」，它會避免對開發者來說顯得廉價的行銷套路。

具體原則：

  • 角色要和任務相關（寫 code 就設定工程師，不要設定「全能助手」）
  • 加上風格約束（「簡潔」「技術導向」「不用 emoji」）
  • 明確指出目標受眾（誰會讀到這個輸出？）

技巧二：XML 標籤 — Claude 的超能力

這是在 Claude 上效果最好、也最被低估的技巧。

爛 prompt：

這是一段用戶反饋：產品很好用但是價格太貴了而且客服回覆很慢。
請分析正面和負面的部分。

好 prompt：

請分析以下用戶反饋，將正面和負面評價分開列出。

<user_feedback>
產品很好用但是價格太貴了而且客服回覆很慢。
</user_feedback>

<output_format>
- 正面：逐條列出
- 負面：逐條列出
- 建議優先處理的問題：選一個最關鍵的
</output_format>

XML 標籤做了三件事：

  1. 分隔內容和指令。Claude 不會把用戶反饋的文字和你的指令混在一起理解。
  2. 標記語義。<user_feedback> 告訴 Claude 這段文字是什麼，不只是一段文字。
  3. 定義輸出結構。<output_format> 直接告訴 Claude 你期待的回答長什麼樣。

常用的標籤模式：

  • <context> — 背景資訊
  • <instructions> — 具體任務
  • <examples> — 範例
  • <constraints> — 限制條件
  • <output_format> — 輸出格式

你不需要用正式的 XML schema。標籤名字隨便取，只要語義清楚就好。Claude 讀的是語義，不是 DTD。

技巧三：思考鏈 — 讓 AI 展示推理過程

爛 prompt：

這段 code 有 bug 嗎？
[貼上 code]

好 prompt：

請審查以下程式碼，找出潛在的 bug 或問題。

<code>
[貼上 code]
</code>

<instructions>
請按照以下步驟分析：
1. 先理解這段 code 的意圖
2. 逐行檢查邏輯是否正確
3. 檢查 edge case（null、空陣列、超大輸入）
4. 檢查是否有安全隱患
5. 最後給出你的結論和修改建議
</instructions>

思考鏈（Chain of Thought）的原理很簡單：當你要求 AI 一步步推理，它的每一步都會成為下一步的上下文，累積出更準確的結論。

在 Claude 上，你也可以用 extended thinking 功能讓模型在回答前先進行內部推理。但即使不用這個功能，在 prompt 裡明確要求分步驟分析，效果已經非常顯著。

適合用思考鏈的場景：

  • 複雜的邏輯推理
  • Code review
  • 多步驟的決策（「應該選 A 還是 B？」）
  • 數學或量化分析

不需要用思考鏈的場景：

  • 簡單的格式轉換
  • 翻譯
  • 直接的事實查詢

技巧四：範例 — 一個好範例勝過一百字描述

爛 prompt：

幫我寫 git commit message，要簡潔有意義

好 prompt：

請根據以下 diff 撰寫 git commit message。

<examples>
輸入：新增了用戶登入的 API endpoint
輸出：feat(auth): add login endpoint with JWT token generation

輸入：修正了價格計算時小數點精度的問題
輸出：fix(billing): use Decimal for price calculation to avoid floating point errors

輸入：把 UserCard 組件從 pages/ 移到 components/
輸出：refactor(ui): move UserCard to shared components directory
</examples>

<diff>
[貼上你的 diff]
</diff>

Few-shot examples 是所有 prompting 技巧裡投資回報率最高的。你不需要解釋規則，直接給 Claude 看「好的輸出長什麼樣」，它會自動歸納出模式。

寫好範例的原則：

  • 給 2-3 個就夠。太多反而浪費 context。
  • 涵蓋不同情況。上面的例子包含 feat、fix、refactor 三種類型。
  • 範例要真實。不要給理想化的範例，給你實際會用的。

System Prompt 的最佳實踐

如果你透過 API 使用 Claude，system prompt 是你最重要的武器。它在每次對話開始前就載入，相當於 Claude 的「人格設定檔」。

好的 system prompt 結構：

<role>
你是一位台灣的資深全端工程師，專精 Next.js 和 TypeScript。
</role>

<style>
- 回答使用繁體中文，技術名詞保留英文
- 程式碼註解使用英文
- 語氣直接，不加不必要的客套話
- 如果問題不夠明確，先釐清再回答
</style>

<constraints>
- 不要使用 any type
- 優先使用 server component
- 不要推薦已經 deprecated 的 API
- 如果不確定，明確說不確定，不要猜
</constraints>

把不會變的指令放在 system prompt，把每次對話特定的內容放在 user message。這樣你不用每次都重複那些基本設定。

中文用戶的注意事項

繁簡體要明確指定。 Claude 預設會根據你的輸入語言回覆，但在繁簡體之間有時候會飄。如果你需要繁體中文，在 system prompt 或第一則訊息裡明確寫「請使用繁體中文回覆」。

中英混用要給規則。 技術文章常常需要中英混用。告訴 Claude 你的規則：「技術名詞保留英文，其餘使用繁體中文」比「用中文回答」精準得多。

中文 prompt 效果不比英文差。 早期的模型確實對英文 prompt 理解更好，但 Claude 3.5 之後這個差距已經非常小。用你最自然的語言寫 prompt，不需要刻意翻譯成英文。

一個公式

如果你只記一件事，記這個公式：

好的 prompt = 角色 + 上下文 + 具體任務 + 輸出格式 + 限制條件

不是每次都要五個元素全上。簡單的問題，一句話就夠。但當你發現 Claude 的回答不如預期，回頭檢查這五個元素，通常能找到缺了哪一塊。

Prompt engineering 不是讓你變成「AI 溝通專家」。它是讓你更精確地表達需求的練習——而這個能力，不管有沒有 AI，都值得培養。

想系統性學習 AI 工具的進階用法？我們在 AI 工具實戰教學 裡整理了從 prompting 到自動化工作流的完整課程。