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 使用效率提升好幾個層次。重要的是持續練習,找到最適合你工作場景的用法。
你可能也喜歡
探索其他領域的精選好文