昨天我們探討了 Google 提出的 T-C-R-E-I 五步驟，為「寫出好提示詞」打下穩固基礎。今天，我們將深入三個能顯著提升模型表現的進階技巧：Chain of Thought（思考鏈）、 Few-Shot Prompting（少樣本提示） 與 Self-Consistency（自我一致性）。

(一) Chain of Thought（COT）— 教模型「把推理說出來」

COT 的核心精神在於，要求模型逐步展示其思考過程，而非直接給出結論。這好比在撰寫程式前先規劃偽代碼（Pseudo Code），透過將思路逐一展開，確保每一步都符合預期方向。

簡單來說，COT 是將一個複雜任務拆解成一系列邏輯清晰、可供檢驗的小步驟。模型在每一步都更容易對齊我們的需求，最終將這些步驟組合，形成一個更加可靠的解答。

COT 的三大特性：

1. 拆解複雜性：將大問題分解為小步驟，有效降低單一步驟出錯的機率，如同先寫偽代碼再開發的嚴謹流程。
2. 過程可驗證：讓模型產出「可驗證的中間結論」，方便我們或自動化腳本介入檢查，確保推理路徑的正確性。
3. 促進深度思考：引導模型進行更系統化的「慢思考」，在內部進行更嚴謹的資訊檢索與條件約束，從而減少僅憑直覺或模式匹配而產生的錯誤。

COT範例

假設一段 Java 程式碼在執行後拋出錯誤 Exception in thread "main" java.lang.ArithmeticException: / by zero。

原始程式碼：

public int divide(int a, int b) {
    return a / b;
}

使用 Chain of Thought 提示詞：

請用 Chain of Thought 方式逐步分析以下 Java 程式碼的錯誤：

1.確認錯誤來源：指出具體的 Exception 類型與訊息。
2.分析可能原因：根據錯誤訊息推斷導致問題的根本原因。
3.提出驗證假設：描述如何驗證你的推斷是否正確。

提出修改建議：基於以上分析，說明應如何修正程式碼。
最後，請提供一個修正後且完整的 Java 方法。

模型可能的推理輸出：

1. 錯誤來源：錯誤類型為 ArithmeticException，錯誤訊息明確指出 / by zero（除以零）。
2. 可能原因：divide 方法在執行時，其參數 b 的值被傳入為 0。
3. 驗證假設：如果呼叫 divide(10, 2)，程式應能正常回傳 5。這證明只有在 b 為 0 的情況下才會觸發此錯誤。
4. 修改建議：在執行除法運算前，應加入一個條件判斷。若 b 為 0，則拋出一個更具描述性的 IllegalArgumentException，告知呼叫者傳入了無效的參數。

修正後的完整程式碼：

public int divide(int a, int b) {
    if (b == 0) {
        throw new IllegalArgumentException("Denominator cannot be zero.");
    }
    return a / b;
}

以下是用Claude 範例

沒用COT範例

(二) Few Shot Prompting — 給範例，讓 AI 學 pattern

在提示工程中，「Few-Shot」意指在提示詞裡提供幾個完整的範例（Shots），讓模型從中學習並模仿我們期望的格式或邏輯。

這個技巧就像給 AI 做「考前模擬題」。我們不僅僅是下達任務指令，更是給予它具體的參考答案。模型會分析這些範例，從中歸納出應遵循的模式，進而大幅提升輸出的準確性與一致性。這在需要統一團隊程式碼風格或固定產出格式時，扮演著至關重要的角色。

你是一個熟悉 OpenAPI 3.0 與 Java Spring Boot 的工程師。
請將以下 Swagger YAML 中的 schema 轉換為 Java DTO。
輸出格式必須是乾淨的 Java class，使用 Lombok @Data 或 @Builder。

以下是範例：

例子1：
YAML:
components:
  schemas:
    UserResponse:
      type: object
      properties:
        id:
          type: string
        name:
          type: string
        age:
          type: integer

轉換結果:
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class UserResponse {
    private String id;
    private String name;
    private Integer age;
}

---

例子2：
YAML:
components:
  schemas:
    ConsentAcceptanceRequest:
      type: object
      properties:
        consentTimestamp:
          type: string
          format: date-time
        accepted:
          type: boolean

轉換結果:
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ConsentAcceptanceRequest {
    private Instant consentTimestamp;
    private Boolean accepted;
}

---

請依照相同格式轉換以下 YAML：

components:
  schemas:
    ProductInfo:
      type: object
      properties:
        productId:
          type: string
        productName:
          type: string
        price:
          type: number
          format: double
        available:
          type: boolean

模型輸出

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ProductInfo {
    private String productId;
    private String productName;
    private Double price;
    private Boolean available;
}

以下是用Claude 範例，有用Few Shot的DTO Model

沒用Few Shot範例的DTO，你會看到QuestionnaireSubmission DTO寫法上就不同。一般我們再讓AI統一團隊程式生成時，這個Prompt技巧佔非常關鍵的環節點。

(三) Self-Consistency Prompting — 讓模型「交叉驗證自己」

大型語言模型（LLM）的生成過程帶有一定的隨機性（Stochasticity），這意味著即使是同一個問題，每次的回答也可能不盡相同。Self-Consistency 的核心概念，正是利用這一點來提升結果的可靠性。

具體作法是：讓模型針對同一個問題，進行多次獨立的 Chain of Thought 推理，從而得到多組不同的思考路徑與答案。最後，我們採用「多數決」原則，選出在這些結果中最常出現（最一致）的那個答案作為最終輸出。

其概念相當直觀：如果模型透過不同角度的思考，卻多次得出相同的結論，那麼這個結論的可信度就更高。

例如一個火車以每小時 60 公里行駛，另一列以 40 公里迎面而來，兩車相距 200 公里，多久會相遇？

• 第 1 次：算出 2 小時
• 第 2 次：不小心只用 60 算，得到 3.33 小時（錯誤）
• 第 3 次：再次算到 2 小時
• 第 4 次：又是 2 小時

最後用投票或統計，得出最常見的答案「2 小時」。此方法通常除了用在推理邏輯相關問題外，我也很常使用GPT上，因為能力強的使用次數比較少，所以會常使用這個技巧用在能力比較不強的LLM Model上，意外好用。