Prompt Engineering 進階技巧：Chain of Thought 完整教學與實戰應用
如果你有在用 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 使用效率提升好幾個層次。重要的是持續練習，找到最適合你工作場景的用法。
