如果你有在用 ChatGPT、Claude 或其他大型語言模型，你一定遇過這種情況：明明問題不難，但模型的回答就是不對，或者邏輯跳來跳去讓人看不懂。這時候，Chain of Thought（CoT）就是你的救星。

我自己從 2024 年開始大量使用 CoT 技巧，到現在已經變成我寫 prompt 的標準配備了。今天就來跟大家分享我這兩年累積下來的心得，從基礎到進階一次講完。

什麼是 Chain of Thought

Chain of Thought，中文常翻成「思維鏈」，簡單來說就是讓模型把思考過程一步一步寫出來，而不是直接跳到答案。這個概念最早是 Google 在 2022 年的論文裡提出的，結果一發表就炸了鍋，因為效果提升太明顯了。

為什麼它有用？因為 LLM 本質上是在做 token prediction，當你強迫它把中間推理步驟展開，等於是給它更多「思考空間」。就像你考數學的時候，老師要你寫計算過程一樣，寫出來反而比較不會算錯。

舉個最簡單的例子，你問模型：「小明有 15 顆蘋果，給了小華 7 顆，又從市場買了 12 顆，請問他現在有幾顆？」直接問，模型偶爾會算錯。但如果你加一句「請一步一步思考」，正確率就會大幅提升。

Zero-shot 與 Few-shot CoT

CoT 主要分兩種用法，搞懂差別很重要：

Zero-shot CoT

這是最懶人的方法，你只要在 prompt 最後加上「Let's think step by step」或「請一步一步思考」就好。不需要給範例，模型自己就會展開推理過程。

你是一位資深數據分析師。
請分析以下銷售數據的趨勢，並給出建議。
請一步一步思考，先列出觀察到的模式，再進行分析。

Zero-shot CoT 的好處是簡單快速，適合日常使用。但缺點是你沒辦法控制模型的推理方向，有時候它會往奇怪的方向跑。

Few-shot CoT

如果你需要更精確的結果，Few-shot CoT 就是給模型幾個帶有推理過程的範例，讓它學會你想要的思考方式。

問題：一個工廠每天生產 200 個零件，不良率 3%，請問一週生產多少良品？

思考過程：
1. 每天生產 200 個零件
2. 不良率 3%，代表良品率是 97%
3. 每天良品數 = 200 × 0.97 = 194 個
4. 一週 = 7 天
5. 一週良品數 = 194 × 7 = 1,358 個

答案：1,358 個良品

---
現在請用同樣的方式回答以下問題：
[你的實際問題]

我個人的經驗是，Few-shot CoT 在專業領域的效果遠好於 Zero-shot。特別是當你在處理像是RAG Chunking 策略相關的技術問題時，給模型看過正確的推理範例，它的輸出品質會好很多。

進階技巧：Tree of Thoughts

如果 CoT 是一條直線的思考，那 Tree of Thoughts（ToT）就是把思考展開成一棵樹，讓模型同時探索多條推理路徑，再從中選出最好的。

這個方法特別適合那種沒有標準答案的開放式問題，例如架構設計、策略規劃等。實作上，你可以用這樣的 prompt 結構：

針對以下問題，請產生 3 個不同的解決方案。
對每個方案：
1. 描述具體做法
2. 列出優點和缺點
3. 評估可行性（1-10 分）

最後，綜合比較三個方案，選出最佳方案並說明原因。

問題：如何設計一個能處理每秒 10,000 請求的 RAG 系統？

我在設計 AI 應用架構的時候很常用 ToT，特別是在評估要用LangChain 還是 LlamaIndex 這類框架選擇的時候，讓模型幫我從不同角度分析，省了很多自己來回思考的時間。

Self-Consistency 提升準確率

Self-Consistency 是另一個我超推的技巧。原理很簡單：同一個問題讓模型回答多次，然後取最常出現的答案。

聽起來很笨對吧？但效果出奇地好。因為 LLM 每次生成的推理路徑可能不同，有些路徑會導向錯誤答案。但如果你跑個 5 次，正確答案通常會是出現最多次的那個。

實作上，你可以透過 API 設定較高的 temperature（例如 0.7），然後同時發送多個請求：

# 概念示範
import asyncio

async def self_consistency(prompt, n=5):
    tasks = [call_llm(prompt, temperature=0.7) for _ in range(n)]
    responses = await asyncio.gather(*tasks)
    # 提取每個回答的最終答案
    answers = [extract_answer(r) for r in responses]
    # 回傳出現最多次的答案
    return most_common(answers)

這個方法的缺點是 API 成本會乘以 N 倍，但在高風險的場景（比如自動化決策）下，這個投資是值得的。

CoT 搭配結構化輸出

到了 2026 年，光讓模型「想清楚」還不夠，你還要讓它的輸出格式可以被程式直接使用。這就是 CoT 搭配結構化輸出的威力。

我最常用的做法是讓模型先在一個欄位裡做推理，然後在另一個欄位輸出結構化結果：

請分析這段使用者回饋，判斷情緒和主要議題。

請用以下 JSON 格式回答：
{
  "reasoning": "你的逐步分析過程",
  "sentiment": "positive | negative | neutral",
  "topics": ["議題1", "議題2"],
  "confidence": 0.0-1.0,
  "summary": "一句話摘要"
}

這個模式在開發LangChain Agent 的時候特別好用。你可以讓 Agent 在 reasoning 欄位裡做 CoT 推理，同時確保 tool calling 的參數格式是正確的。

重點提醒：reasoning 欄位放在前面很重要。因為模型是從左到右生成的，先產生推理過程，後面的判斷結果才會更準確。

2026 趨勢：Context Engineering

2026 年最熱門的趨勢就是 Context Engineering——不再只是寫好一個 prompt，而是精心設計整個上下文環境。

Context Engineering 包含幾個核心概念：

動態 System Prompt：根據使用者的意圖動態組裝 system prompt，而不是用一個固定的模板
記憶管理：設計有效的短期和長期記憶機制，讓對話更連貫
檢索增強：結合 RAG 在對話過程中即時注入相關知識
工具編排：讓模型根據 CoT 推理結果，自動選擇和呼叫合適的工具

說白了，Context Engineering 就是把 Prompt Engineering 從「寫一段文字」升級到「設計一個系統」。CoT 在這裡面扮演的角色就是推理引擎——你用 CoT 讓模型理解當前情境，然後根據推理結果去調用不同的工具或檢索不同的資料。

我的觀察是，2026 年頂尖的 AI 工程師已經不太講 Prompt Engineering 了，他們講的是 Context Engineering。但本質上，CoT 這些基本功還是核心中的核心。

實戰範例與建議

最後分享幾個我日常工作中的實戰建議：

1. 分層 CoT

遇到複雜問題，不要一個 prompt 搞定，把它拆成多層：

第一層：理解和分類問題
第二層：針對分類結果做深入分析
第三層：產生最終答案

2. 設定思考框架

與其說「請一步一步思考」，不如直接給模型一個思考框架：

請依照以下框架分析：
1. 【現狀分析】目前的情況是什麼？
2. 【問題識別】核心問題在哪裡？
3. 【方案設計】有哪些可能的解法？
4. 【風險評估】每個方案的風險是什麼？
5. 【最終建議】綜合以上，你的建議是？

3. 善用 Negative Prompting

告訴模型不要做什麼，有時候比告訴它要做什麼更有效：

在分析過程中：
- 不要跳過任何計算步驟
- 不要假設未給的條件
- 不要在沒有數據支持的情況下下結論

4. 持續迭代

沒有一個 prompt 是第一次就完美的。我的習慣是先寫一個基本版，跑幾次看結果，然後根據錯誤的 pattern 去調整。這個過程通常要 3-5 輪才會穩定。

Chain of Thought 說到底就是一種讓 AI 更可靠的方法。不管你是用來做資料分析、程式除錯、還是內容生成，掌握這些進階技巧都會讓你的 AI 使用效率提升好幾個層次。重要的是持續練習，找到最適合你工作場景的用法。

Prompt Engineering 進階技巧：Chain of Thought 完整教學與實戰應用