[AI] Prompt 的眉角：讓你的 LLM 不再雞同鴨講

前言

自從大型語言模型（LLM）普及之後，大家是不是都開始想辦法把 AI 整合到自己的工作流程裡？從寫程式、除錯、文件整理到發想，LLM 真的超好用。但是，有沒有遇過你給它一個指令，它卻回覆得牛頭不對馬嘴，讓你覺得它根本聽不懂你在說什麼？

這種「雞同鴨講」的狀況，其實大部分時候不是模型不夠聰明，而是我們給的「說明書」不夠清楚。這個說明書，就是我們常說的 Prompt。

Prompt 不只是單純輸入問題，它是一種跟 LLM 溝通的藝術，也是一種工程。寫得好的 Prompt，能讓 LLM 成為你的神隊友；寫得不好，就變成一個只能給你模糊答案的黑箱。今天想跟大家分享一些我在實務上常用、而且很有效的 Prompt 技巧，希望能幫大家跟 LLM 合作得更順暢。

怎麼跟 LLM 溝通最有效？從角色設定開始

想像一下，你要跟一個同事請教問題，你會直接丟一句「請解釋區塊鏈」嗎？通常不會對不對？你會先設定情境：「嘿，我是新來的，對區塊鏈有點好奇，可以請你用資深工程師的角度，跟我這個新手解釋一下嗎？」

對 LLM 也是一樣！給 LLM 一個明確的「角色（Role）」，它會更好地理解你的意圖，並以該角色應有的知識、語氣和思考模式來回應。這能讓輸出更聚焦，更符合你期待的情境。

實例對照：

沒有角色設定的 Prompt：

1	請解釋什麼是區塊鏈。

LLM 可能會回覆一段很泛、很教科書式的定義，適合給大眾看的那種。

有角色設定的 Prompt：

你是一個資深的軟體工程師，請用淺顯易懂的方式，向一位剛入門的同事解釋什麼是區塊鏈，並舉例說明它在實務上的應用。請確保解釋內容不超過 300 個中文字，並避免過於學術的詞彙。

這樣 LLM 就知道它要扮演「資深工程師」，溝通對象是「入門同事」，而且要「淺顯易懂」並「控制字數」。回覆的內容和語氣會完全不同，更貼近你的實際需求。

不再模稜兩可：清晰的指令與限制

LLM 雖然很厲害，但它也很擅長「腦補」或「猜測」。當你的指令不夠清晰時，它就可能會猜錯你的意圖，然後給你一些你根本不想要的內容。明確的指令和限制，可以大大減少這種「猜錯」的機率，節省你來回溝通和修改的時間。

實例對照：

模糊的 Prompt：

1	幫我寫一個 Python 函式。

它可能會問：「你要寫什麼函式？」「參數是什麼？」「回傳值是什麼？」或者直接給你一個 Hello World 的函式。這時候你還是得再解釋一遍。

清晰的 Prompt：

請用 Python 寫一個函式，接收兩個數字作為參數，並回傳它們的總和。請注意函式命名要符合 PEP8 規範，並包含 Docstring。輸出結果只包含程式碼，不要有任何解釋。

這樣模型就知道：

語言： Python
目標： 計算總和
輸入： 兩個數字
輸出： 總和
程式碼規範： PEP8、Docstring
格式限制： 只輸出程式碼

它給你的程式碼會更精準，甚至可以直接拿來用：

def add_two_numbers(num1: int, num2: int) -> int:
    """
    Calculates the sum of two numbers.

    Args:
        num1 (int): The first number.
        num2 (int): The second number.

    Returns:
        int: The sum of num1 and num2.
    """
    return num1 + num2

你甚至可以加入「負面指令」（Negative Constraints），例如「請不要包含任何解釋，直接輸出程式碼就好」，這在希望 LLM 精確地只給你某種特定輸出時特別有用。

多給幾個「範例」，模型會學得更快 (Few-shot Prompting)

有時候，用文字描述再多，都不如直接給幾個「輸入-輸出」的範例，讓 LLM 自己去歸納規則來得快。這就是所謂的 Few-shot Prompting。特別適用於有特定格式、風格，或是需要複雜轉換的任務。

實例對照：

沒有範例的 Prompt：

1 2	請將以下句子轉換為被動語態：主動：The developer wrote the code.

模型可能能正確轉換，但也可能在遇到更複雜的句子時出錯，或者回覆的格式不一定是你想要的。

有範例的 Prompt：

請將以下句子轉換為被動語態。以下是幾個範例，請依循此模式轉換：

主動：The dog chased the ball.
被動：The ball was chased by the dog.

主動：The boy ate the apple.
被動：The apple was eaten by the boy.

主動：The developer wrote the code.
被動：

給了兩個範例之後，模型會學得更快，而且輸出格式會更穩定。它會知道你要的結果是什麼樣子，而不是只知道要做什麼。

讓 LLM 自己「思考」：Chain of Thought (CoT) 的威力

當你給 LLM 一個複雜的問題，如果它直接給答案，你很難判斷這個答案是不是正確的，或者它是怎麼推導出來的。Chain of Thought (CoT) 是一種很強大的技巧，它不是直接要求答案，而是請 LLM 先解釋它的「思考過程」。這能大幅提升模型解決複雜問題的準確性，同時也讓你更容易檢查它的邏輯。

實例對照：

沒有 CoT 的 Prompt：

1	有三個人 A、B、C。A 比 B 重，C 比 A 輕。誰最重？

LLM 有時可能會因為沒有足夠的思考空間而直接給出錯誤答案，或是選擇一個「聽起來合理」但實際上不對的選項。

有 CoT 的 Prompt：

1	有三個人 A、B、C。A 比 B 重，C 比 A 輕。請先分析他們之間的重量關係，然後找出誰最重。請列出你的思考步驟。

LLM 的回覆可能會像這樣：

好的，我來分析一下三個人 A、B、C 之間的重量關係：

1. 第一條線索：「A 比 B 重」。這可以表示為：A > B。
2. 第二條線索：「C 比 A 輕」。這表示 A 的重量大於 C。這可以表示為：A > C。
3. 綜合分析：
   - 我們知道 A 比 B 重。
   - 我們也知道 A 比 C 重。
   - 從這兩條資訊中，我們可以確定 A 同時比 B 和 C 都重。

結論：因此，A 是最重的人。

你看，有了思考步驟，不僅答案更可信，我們也能理解模型是怎麼推導出來的。如果它某一步想錯了，你也可以更容易地糾正它。這在處理程式邏輯、數學問題或複雜的專案規劃時特別有用。

結構化輸出：讓你的程式更容易處理 LLM 的回覆

如果你是把 LLM 當成後端服務來呼叫，讓你的程式去解析它的回覆，那麼要求結構化輸出就超級重要了。讓 LLM 回傳 JSON、XML 或是 Markdown 表格，會比純文字好處理一百倍！這樣能大幅簡化後續的程式碼處理邏輯，讓 LLM 更像是 API 的一部分。

實例對照：

純文字輸出的 Prompt：

1	請幫我分析這篇文章，並列出三個主要論點。

模型可能會回覆一長段文字，裡面用無序列表或段落來表達論點。你的程式要解析這些內容，可能需要寫很多正則表達式或複雜的字串處理邏輯，而且還很容易出錯。

JSON 格式輸出的 Prompt：

1
2
3

請分析以下文章內容，並以 JSON 格式回傳三個主要論點。JSON 結構應包含一個名為 "main_points" 的陣列，每個元素包含 "title" 和 "summary" 兩個鍵值。文章內容如下：

[文章內容]

LLM 就會回傳一個你的程式可以直接解析的 JSON 物件：

{
  "main_points": [
    {
      "title": "文章核心理念",
      "summary": "文章主要探討了 AI 在軟體開發中的應用趨勢，強調了自動化測試的重要性。"
    },
    {
      "title": "RAG 技術的實用性",
      "summary": "文中詳細介紹了 RAG (Retrieval-Augmented Generation) 如何結合現有知識庫，提升 LLM 回覆的準確性與可靠度。"
    },
    {
      "title": "工程師應對挑戰",
      "summary": "最後，文章呼籲工程師應積極學習新的 AI 工具，以適應未來開發流程的變化，並提升個人競爭力。"
    }
  ]
}