🏛️ 為什麼需要設計模式？
AI 模型不是 100% 可靠的——它會幻覺、會犯錯、會變慢、會宕機。設計模式就是讓你的 AI 產品在這些不完美中仍然穩定運作。
💡 一句話理解 AI 設計模式 = 軟體工程的 Design Pattern 在 AI 應用上的延伸。 解決的核心問題：「AI 不可靠，但產品必須可靠」。
和傳統 GoF 設計模式的差別
GoF（Gang of Four）的 23 種經典設計模式解決的是物件導向的結構問題——例如 Observer 處理事件通知、Factory 處理物件建立。AI 設計模式要解決的則是另一類問題：
- 推理不確定性：同一個輸入、同一個模型，輸出可能不同。
- 成本與延遲：每次呼叫都要錢，每個 token 都有延遲。
- 失敗模式複雜：不是「成功」或「例外」兩種，還有「回答但錯了」、「回答但偏題」、「信心度低」。
- 上下文有限：Context window 是硬限制，不能無限塞資料。
所以你會看到 AI 設計模式圍繞不確定性管理、成本控制、失敗降級這三條主軸轉。下面先介紹 6 個 AI 原生的「思考模式」，再接 6 個工程面的「產品模式」。
🧠 6 個核心 AI 推理模式（Reasoning Patterns）
這 6 個模式是所有 AI 應用的底層思考架構。理解它們，你看 LangChain 或 Agent 框架 的原始碼就不會迷路。
Pattern A：RAG（檢索增強生成）
一句話：回答問題前，先去知識庫找資料，再把資料塞進 prompt。 何時用：答案需要即時性（公司文件、最新新聞）或需要引用來源時。 虛擬碼：
docs = vector_db.search(question, top_k=5)
answer = llm(f"根據以下資料回答問題：\n{docs}\n\n問題：{question}")完整實作參考 RAG 完全指南。當你發現 LLM 回答的內容「不在它的訓練資料裡」時，第一個想到的就是 RAG。
Pattern B：ReAct（Reason + Act）
一句話：讓 AI 「想一步 → 做一步 → 看結果 → 再想一步」，而不是一次給答案。 何時用：需要呼叫外部工具（搜尋、計算機、資料庫）才能回答的問題。 虛擬碼：
Thought: 我需要知道今天天氣
Action: call_weather_api("台北")
Observation: 23°C，多雲
Thought: 根據天氣，我建議...
Final Answer: ...ReAct 是大多數 Agent 系統的基礎迴圈。
Pattern C：Chain-of-Thought（CoT）
一句話：在 prompt 裡加一句「讓我們一步一步思考」，強迫 AI 寫出推理過程。 何時用：數學、邏輯、多步驟推理任務。 虛擬碼：
prompt = f"問題：{q}\n\n請一步一步推理，最後給答案。"實測：在算數和邏輯題上，CoT 能把準確率從 50% 拉到 85%+。細節可看 Prompt Engineering。
Pattern D：Self-Consistency（自我一致性）
一句話：同一個問題跑 5 次，取多數決的答案。 何時用：數學/邏輯題、答案必須精確的場景。 虛擬碼：
answers = [llm(question, temperature=0.7) for _ in range(5)]
final = most_common(answers)成本 5 倍，但錯誤率可降一半。適合關鍵決策，不適合聊天。
Pattern E：Reflection（反思）
一句話：AI 先給答案，再自我批判、修正，然後給最終版。 何時用：寫作、寫程式、需要品質控制的任務。 虛擬碼：
draft = llm(f"回答：{q}")
critique = llm(f"批評以下答案的問題：{draft}")
final = llm(f"根據批評修正：{draft}\n批評：{critique}")延遲和成本 3 倍，但品質通常顯著提升。Vibe Coding 背後很多靠的就是 Reflection。
Pattern F：Multi-Agent（多 Agent 協作）
一句話：把任務拆給多個角色不同的 AI（PM、工程師、QA），讓他們互相討論。 何時用：任務大、需要不同專業視角（如產品規劃、複雜寫作）。 虛擬碼：
pm_plan = pm_agent(task)
code = engineer_agent(pm_plan)
review = qa_agent(code)警告：這是被過度使用的模式。80% 用 Multi-Agent 的場景，用 Reflection 或 CoT 就夠了。
🎯 決策樹：怎麼挑模式？
不知道用哪個？照著問：
-
答案需不需要外部知識？
- 需要最新資料/公司文件 → RAG
- 需要呼叫工具（搜尋、計算、API） → ReAct
- 都不需要，只靠模型內知識 → 下一題
-
任務需不需要多步推理？
- 需要（數學、邏輯、複雜規劃） → CoT
- 答案必須極準確 → CoT + Self-Consistency
- 不需要 → 直接呼叫模型
-
品質要求高嗎？
- 要發布、要給客戶看 → 加 Reflection
- 內部快速迭代 → 不加
-
任務真的大到一個 AI 做不完？
- 是 → Multi-Agent（最後才考慮）
- 不確定 → 先試 Reflection
我的經驗法則：RAG + ReAct + CoT 可以解決 90% 的企業應用。Multi-Agent 留到最後再碰。
🎬 實戰場景：客服系統的漸進式升級
從一個最簡單的 FAQ bot，逐步加上模式，看每一步在解什麼問題。
V1（只有 LLM）：直接把用戶問題丟給 GPT。 問題：LLM 不知道公司的退貨政策，亂回答。
V2（+ RAG）：把公司政策向量化，回答前先檢索。 問題：用戶問「我三天前買的鞋子有瑕疵」，模型只查到「退貨政策」，沒查到「瑕疵商品處理」。
V3（+ ReAct）：讓模型決定要查哪個知識庫、要不要查訂單系統。 問題：模型偶爾回答矛盾（例如說能退又說不能退）。
V4（+ Reflection）：答案先經「審核 agent」檢查政策一致性再回覆。 問題：對高價商品退貨，錯一次就客訴。
V5（+ Human-in-the-Loop）：金額超過 NT$10,000 的退貨請求，AI 草稿 + 人工確認。
每一步都是針對觀察到的失敗模式加一個模式，不是一次堆滿。
🏗️ 6 個產品工程模式（Production Patterns）
推理模式管「AI 怎麼思考」，產品模式管「AI 怎麼上線不爆炸」。
🔄 模式 1：Human-in-the-Loop（人機協作）
讓人類在關鍵節點介入審核，而不是完全自動化。
三種介入策略
| 策略 | 做法 | 適合 |
|---|---|---|
| Always Review | 每次 AI 輸出都需人類確認 | 醫療、法律、金融 |
| Confidence Gate | 低信心時才要求人類介入 | 客服、分類 |
| Random Audit | 隨機抽查 AI 結果 | 大量自動化場景 |
Confidence Gate 實作
def ai_with_human_review(question, confidence_threshold=0.7):
"""信心度低時自動轉人工"""
# AI 回答 + 自評信心度
response = client.chat.completions.create(
model="gpt-4o",
messages=[{
"role": "user",
"content": f"""回答以下問題，並評估你的信心度。
問題：{question}
用 JSON 回答：
{{"answer": "你的回答", "confidence": 0.0到1.0, "reason": "信心度理由"}}"""
}],
response_format={"type": "json_object"}
)
result = json.loads(response.choices[0].message.content)
if result["confidence"] >= confidence_threshold:
return {"type": "auto", "answer": result["answer"]}
else:
# 信心不足 → 轉人工
return {
"type": "human_review",
"ai_draft": result["answer"],
"confidence": result["confidence"],
"reason": result["reason"]
}🛟 模式 2：Graceful Degradation（優雅降級）
AI 失敗時，不要給使用者一個錯誤頁面——要有備案。
降級瀑布
async def smart_response(question):
"""多層降級策略"""
# Level 1：AI 完整回答
try:
answer = await call_ai(question, model="gpt-4o")
return {"level": "full_ai", "answer": answer}
except Exception:
pass
# Level 2：用較便宜的模型
try:
answer = await call_ai(question, model="gpt-4o-mini")
return {"level": "fallback_model", "answer": answer}
except Exception:
pass
# Level 3：從 FAQ 資料庫直接匹配
faq_answer = search_faq_database(question)
if faq_answer:
return {"level": "faq_match", "answer": faq_answer}
# Level 4：固定回覆（最後防線）
return {
"level": "static_fallback",
"answer": "抱歉，目前系統忙碌中。請稍後再試，或聯繫客服：[email protected]"
}💸 模式 3：Model Routing（模型智慧路由）
不是所有問題都需要用最貴的模型。先用便宜的，需要時再升級。
Router 實作
class ModelRouter:
"""根據問題複雜度自動選擇模型"""
def __init__(self):
self.classifier = ChatOpenAI(model="gpt-4o-mini")
async def route(self, question):
# 用便宜模型判斷問題複雜度
classification = await self.classifier.invoke([{
"role": "user",
"content": f"""判斷以下問題的複雜度（simple/moderate/complex）：
問題：{question}
只回答一個字：simple、moderate 或 complex"""
}])
complexity = classification.content.strip().lower()
model_map = {
"simple": "gpt-4o-mini", # $0.15/M → 簡單問答
"moderate": "gpt-4o", # $2.50/M → 一般任務
"complex": "gpt-4o", # $2.50/M → 複雜推理
}
selected = model_map.get(complexity, "gpt-4o")
return selected
# 使用
router = ModelRouter()
model = await router.route("今天天氣如何？") # → gpt-4o-mini
model = await router.route("分析這份財報的風險因素") # → gpt-4o成本影響
| 流量分佈 | 月呼叫量 | 全用 GPT-4o | 用 Router | 節省 |
|---|---|---|---|---|
| 70% 簡單 + 30% 複雜 | 100K | $250 | $100 | 60% |
🗄️ 模式 4：Semantic Cache（語意快取）
相似的問題直接回傳快取結果，避免重複呼叫 API。底層依賴 Embedding 計算語意相似度。
class SemanticCache:
"""根據語意相似度快取 AI 回答"""
def __init__(self, threshold=0.92):
self.threshold = threshold
self.cache = [] # [(embedding, question, answer)]
def get(self, question):
q_embed = get_embedding(question)
for cached_embed, cached_q, cached_answer in self.cache:
similarity = cosine_similarity(q_embed, cached_embed)
if similarity >= self.threshold:
return cached_answer # 快取命中！
return None # 快取未命中
def set(self, question, answer):
q_embed = get_embedding(question)
self.cache.append((q_embed, question, answer))
# 使用
cache = SemanticCache(threshold=0.92)
def ask_ai(question):
# 先查快取
cached = cache.get(question)
if cached:
return cached # 免費！不呼叫 API
# 快取未命中 → 呼叫 API
answer = call_ai(question)
cache.set(question, answer)
return answer
# 「怎麼退貨」和「退貨流程是什麼」語意接近 → 快取命中
ask_ai("怎麼退貨？") # 呼叫 API
ask_ai("退貨流程是什麼？") # 快取命中，免費！🔍 模式 5：Guardrail Pipeline（護欄流水線）
在 AI 的輸入和輸出兩端加上安全檢查。
用戶輸入
↓
[輸入護欄] → 長度限制 / 注入偵測 / PII 去識別
↓
[AI 模型] → 生成回答
↓
[輸出護欄] → 幻覺檢測 / PII 過濾 / 毒性檢查
↓
[品質閘門] → Confidence 太低？轉人工
↓
回覆用戶📊 模式 6：A/B Testing AI
測試不同的 Prompt、模型或參數，用數據決定哪個更好。搭配 LLM 評估模式使用效果更佳。
import random
class AIExperiment:
"""AI 功能 A/B 測試"""
def __init__(self):
self.variants = {
"control": {
"model": "gpt-4o",
"prompt": "你是客服助理。用繁體中文簡潔回答。",
"metrics": {"total": 0, "positive_feedback": 0}
},
"treatment": {
"model": "gpt-4o",
"prompt": "你是熱情友善的客服。回答時先同理用戶，再解決問題。",
"metrics": {"total": 0, "positive_feedback": 0}
}
}
def get_variant(self, user_id):
"""根據 user_id 一致性分流"""
variant = "treatment" if hash(user_id) % 2 == 0 else "control"
return variant
def record_feedback(self, variant, is_positive):
self.variants[variant]["metrics"]["total"] += 1
if is_positive:
self.variants[variant]["metrics"]["positive_feedback"] += 1
def report(self):
for name, v in self.variants.items():
total = v["metrics"]["total"]
pos = v["metrics"]["positive_feedback"]
rate = pos / total * 100 if total > 0 else 0
print(f"{name}: {rate:.1f}% 正面回饋 ({pos}/{total})")📋 設計模式選用指南
| 你的問題 | 推薦模式 |
|---|---|
| AI 回答不能出錯 | Human-in-the-Loop |
| API 可能宕機 | Graceful Degradation |
| 成本太高 | Model Routing + Semantic Cache |
| 擔心安全問題 | Guardrail Pipeline |
| 不知道哪個 Prompt 好 | A/B Testing |
| 全部都要 | 組合使用 ✅ |
🚫 Anti-Patterns：這些做法看起來聰明，其實在挖坑
看過太多團隊在這些地方翻車：
Anti-pattern 1：過度串鏈（Over-chaining）
「用 5 個 LLM 呼叫解決一個問題，因為每一步都很優雅。」 問題：每個 LLM 呼叫都有機率出錯（假設 95% 正確率），5 步串起來整體正確率 = 0.95⁵ ≈ 77%。而且延遲和成本都 5 倍。 解法：能一個 prompt 解決的，絕對不要拆 3 個。只有在每一步需要不同工具/知識源時才拆。
Anti-pattern 2：過早上 Multi-Agent
「我要做個 AI 產品經理 + AI 工程師 + AI QA 互相協作。」 問題：你連單一 Agent 都還沒跑穩，三個 Agent 一起就是三倍的不可預測。 解法：先把單 Agent 做到 95% 可靠，再考慮 Multi-Agent。參考 Agent 實作教學 的漸進法。
Anti-pattern 3：Prompt Soup（Prompt 濃湯）
「把所有規則、範例、邊界條件全塞進一個 3000 字的系統 prompt。」 問題：模型會忽略中間的指令（known as “lost in the middle”），而且難以除錯——改一條規則會影響其他規則。 解法：把 prompt 拆成清晰的段落（角色、任務、範例、限制），用 結構化輸出 限制格式，限制條件多時改用 tool use / function calling。
Anti-pattern 4：沒有 Fallback 的上線
「AI 掛了就掛了，反正只是輔助功能。」 問題：使用者看到錯誤訊息會直接放棄，不會回來。 解法：至少要有一層 static fallback（「系統忙碌中，請稍後再試」比 500 Internal Server Error 好 10 倍）。
Anti-pattern 5：信任模型的自評分數
「我讓模型自己打信心分數，然後低分轉人工。」 問題：LLM 的 self-confidence 常常和實際正確率無關——它可能很自信地講錯。 解法：用外部訊號判斷信心（答案長度、是否引用了 RAG 來源、是否要求澄清），或用 LLM Evaluation 的判官模型做二次驗證。
🛠️ 實戰建議：什麼時候該加模式、什麼時候該省
從我做過的案子歸納出這張時機表：
| 產品階段 | 建議模式 | 先別碰 |
|---|---|---|
| PoC / Demo | 直接呼叫 LLM，頂多加 RAG | Reflection、Multi-Agent |
| 內部工具 | + Graceful Degradation + Semantic Cache | A/B Testing |
| 付費用戶 MVP | + Guardrail Pipeline + Human-in-the-Loop（關鍵節點） | Multi-Agent |
| 規模化營運 | + Model Routing + A/B Testing + 完整 Observability | — |
| 高合規場景 | 全開 + 人工審核 SOP | — |
一個反直覺的觀察：很多 AI 新創在 PoC 階段就堆上 Multi-Agent 和複雜 RAG，結果 demo 時一堆邊界案例炸裂。一個寫得好的 prompt + 好的 RAG 資料，往往贏過一整套 agent 架構。和 MCP 開發 一樣——好工具比多工具重要。
❓ FAQ
小專案也需要這些設計模式嗎？
內部工具或 MVP 可以先跳過，直接呼叫 API。但只要有外部用戶使用的 AI 功能，至少要有 Graceful Degradation（不能噴錯誤給用戶）和基本的輸入過濾。
Semantic Cache 的快取命中率大概多少？
取決於場景。客服場景（問題重複性高）通常有 40-60% 命中率。開放式問答（問題多元）可能只有 5-10%。閾值設太低會回傳不相關的快取，建議 0.90 以上。
Model Routing 的分類器本身也要花 Token 嗎？
是的，但分類用的 prompt 很短（< 100 tokens），用 GPT-4o-mini 一次只需 ~$0.00005。相比路由節省的成本（60%+），分類器成本可忽略不計。
推理模式（RAG/ReAct/CoT）和產品模式（Human-in-the-Loop/Guardrail）有衝突嗎？
不會衝突，而是組合使用。推理模式決定 AI「怎麼想答案」，產品模式決定「答案怎麼安全地送到用戶手上」。典型客服系統：RAG（找知識） + CoT（推理） + Reflection（自我檢查） + Guardrail（輸出過濾） + Human-in-the-Loop（低信心轉人工），五個模式同時運作。
什麼時候該用 Multi-Agent 而不是單 Agent？
三個條件都滿足才用：(1) 任務真的需要不同專業角色（不只是步驟），(2) 每個角色需要不同的工具/知識庫，(3) 你能接受延遲變 3-5 倍。否則用 Reflection 或 CoT 就能達到 80% 效果，成本和延遲只要 1/3。我看過太多團隊用 Multi-Agent 解決「拆 3 個 prompt 就搞定」的問題。
Reflection 和 Self-Consistency 選哪個？
任務類型決定。有標準答案的任務（數學、分類、事實查詢）用 Self-Consistency——跑多次取多數決。沒有標準答案的任務（寫作、程式、分析）用 Reflection——讓 AI 自我批判修正。Self-Consistency 成本線性增加但效果有上限，Reflection 成本較低但需要設計好批判 prompt。
決策樹選完模式後，下一步該做什麼？
先用最簡單的實作跑出 Demo（直接串 API，不用框架），收集 20-50 個真實 case。看 case 在哪裡失敗——是找不到資料（加 RAG）、推理錯誤（加 CoT）、還是品質不穩（加 Reflection）？根據實際失敗原因加模式，而不是一開始就照架構圖堆滿。這套方法在 Claude Code 寫 MVP 時特別好用。