聖誕老人驗證法（Santa Method）
多智能體對抗性驗證框架。列清單，檢查兩次。若為調皮，修正直到乖巧。
核心洞察：單一智能體審查自己的輸出，會共享產生該輸出時所帶有的相同偏差、知識盲點和系統性錯誤。兩個沒有共享上下文的獨立審查者，可以打破這種失敗模式。
何時啟用
符合以下情況時，請調用此技能：
- 輸出將被發佈、部署或供終端使用者使用
- 必須遵守合規、法規或品牌限制
- 程式碼未經人工審查就直接發佈到生產環境
- 內容準確性至關重要（技術文件、教育材料、面對客戶的文案）
- 需要大規模批次生成，而抽樣檢查無法發現系統性模式
- 幻覺風險較高（涉及聲明、統計數據、API 參考、法律用語）
請勿用於內部草稿、探索性研究，或是具有確定性驗證的任務（這類情況請使用建置/測試/lint 管線）。
架構
┌─────────────┐
│ 產生器 │ 階段 1：列清單
│ (智能體 A) │ 產出可交付成果
└──────┬───────┘
│ 輸出
▼
┌──────────────────────────────┐
│ 雙重獨立審查 │ 階段 2：檢查兩次
│ │
│ ┌───────────┐ ┌───────────┐ │ 兩個智能體，相同評估標準，
│ │ 審查者 B │ │ 審查者 C │ │ 無共享上下文
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
└────────┼──────────────┼────────┘
│ │
▼ ▼
┌──────────────────────────────┐
│ 判決閘門 │ 階段 3：調皮或乖巧
│ │
│ B 通過 且 C 通過 → 乖巧 │ 兩者都必須通過。
│ 否則 → 調皮 │ 沒有例外。
└──────┬──────────────┬─────────┘
│ │
乖巧 調皮
│ │
▼ ▼
[發佈] ┌─────────────┐
│ 修正循環 │ 階段 4：修正直到乖巧
│ │
│ 迭代次數++ │ 收集所有標記。
│ 若 i > 最大值:│ 修正所有問題。
│ 升級 │ 重新執行兩個審查者。
│ 否則: │ 循環直到收斂。
│ 返回階段 2 │
└──────────────┘
階段細節
階段 1：列清單（產生）
執行主要任務。不需改變你正常的產生工作流程。聖誕老人驗證法是一個產生後驗證層，而非產生策略。
# 產生器照常執行
output = generate(task_spec)
階段 2：檢查兩次（獨立雙重審查）
平行啟動兩個審查智能體。關鍵不變量：
- 上下文隔離 — 兩個審查者都看不到對方的評估結果
- 相同的評估標準 — 兩者收到相同的評估準則
- 相同的輸入 — 兩者都收到原始規格 AND 產生的輸出
- 結構化輸出 — 每個審查者回傳結構化判決，而非散文
REVIEWER_PROMPT = """
你是一個獨立的品質審查者。你沒有看過任何其他對此輸出的審查。
## 任務規格
{task_spec}
## 待審查輸出
{output}
## 評估標準
{rubric}
## 指示
根據每個評估標準來評估輸出。針對每一項：
- PASS：該標準完全符合，沒有問題
- FAIL：發現具體問題（引用確切的問題點）
以結構化 JSON 回傳你的評估結果：
{
"verdict": "PASS" | "FAIL",
"checks": [
{"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
],
"critical_issues": ["..."], // 必須修正的阻礙問題
"suggestions": ["..."] // 非阻礙性的改善建議
}
請保持嚴謹。你的工作是找出問題，而不是核准。
"""
# 平行啟動審查者（Claude Code 子智能體）
review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="聖誕老人審查者 B")
review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="聖誕老人審查者 C")
# 兩者同時執行 — 彼此看不到對方
評估標準設計
評估標準是最重要的輸入。模糊的標準會產生模糊的審查結果。每個標準都必須有客觀的通過/失敗條件。
| 標準 | 通過條件 | 失敗信號 |
|---|---|---|
| 事實準確性 | 所有聲明皆可根據原始資料或常識驗證 | 虛構的統計數據、錯誤的版本號碼、不存在的 API |
| 無幻覺 | 沒有捏造的實體、引用、URL 或參考文獻 | 連結到不存在的頁面、沒有來源的引用 |
| 完整性 | 規格中的每個需求都已處理 | 缺少章節、跳過邊界案例、覆蓋範圍不完整 |
| 合規性 | 通過所有專案特定的限制條件 | 使用了禁止用語、語氣違規、法規不合規 |
| 內部一致性 | 輸出中沒有矛盾 | A 節說 X，B 節說非 X |
| 技術正確性 | 程式碼可編譯/執行，演算法正確 | 語法錯誤、邏輯錯誤、錯誤的複雜度聲明 |
特定領域的評估標準擴展
內容/行銷：
- 品牌語氣遵循度
- 符合 SEO 要求（關鍵字密度、Meta 標籤、結構）
- 未不當使用競爭對手商標
- 行動呼籲（CTA）存在且連結正確
程式碼：
- 型別安全（無
any洩漏、正確的 null 處理） - 錯誤處理覆蓋率
- 安全性（無機密資訊寫在程式碼中、輸入驗證、注入防護）
- 新增路徑的測試覆蓋率
合規敏感（法規、法律、金融）：
- 無結果保證或未經證實的主張
- 必要的免責聲明已包含
- 僅使用核准的術語
- 符合管轄區適用的語言
階段 3：調皮或乖巧（判決閘門）
def santa_verdict(review_b, review_c):
"""兩個審查者都必須通過。沒有部分給分。"""
if review_b.verdict == "PASS" and review_c.verdict == "PASS":
return "NICE" # 發佈
# 合併兩個審查者的標記，去除重複
all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)
return "NAUGHTY", all_issues, all_suggestions
為何兩者都必須通過：如果只有一個審查者發現問題，那麼這個問題是真實存在的。另一個審查者的盲點正是聖誕老人驗證法想要消除的失敗模式。
階段 4：修正直到乖巧（收斂循環）
MAX_ITERATIONS = 3
for iteration in range(MAX_ITERATIONS):
verdict, issues, suggestions = santa_verdict(review_b, review_c)
if verdict == "NICE":
log_santa_result(output, iteration, "passed")
return ship(output)
# 修正所有關鍵問題（建議可選）
output = fix_agent.execute(
output=output,
issues=issues,
instruction="只修正被標記的問題。不要重構或新增未要求的變更。"
)
# 對修正後的輸出重新執行兩個審查者（全新的智能體，無上一輪的記憶）
review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
# 迭代次數耗盡 — 升級
log_santa_result(output, MAX_ITERATIONS, "escalated")
escalate_to_human(output, issues)
關鍵：每一輪審查都使用全新的智能體。審查者不得攜帶之前輪次的記憶，因為先前的上下文會造成定錨偏誤。
實作模式
模式 A：Claude Code 子智能體（推薦）
子智能體提供了真正的上下文隔離。每個審查者都是一個獨立的程序，沒有共享狀態。
# 在 Claude Code 會話中，使用 Agent 工具來啟動審查者
# 兩個審查者同時執行以提高速度
# Agent 工具呼叫的虛擬碼
reviewer_b = Agent(
description="Santa Review B",
prompt=f"審查此輸出的品質...\n\n評估標準:\n{rubric}\n\n輸出:\n{output}"
)
reviewer_c = Agent(
description="Santa Review C",
prompt=f"審查此輸出的品質...\n\n評估標準:\n{rubric}\n\n輸出:\n{output}"
)
模式 B：順序內聯（備用）
當無法使用子智能體時，透過明確的上下文重置來模擬隔離：
- 產生輸出
- 新上下文：「你是審查者 1。僅根據此評估標準進行評估。找出問題。」
- 記錄發現
- 完全清除上下文
- 新上下文：「你是審查者 2。僅根據此評估標準進行評估。找出問題。」
- 比較兩個審查結果，修正，重複
子智能體模式嚴格優於內聯模式 — 內聯模擬有審查者之間上下文洩漏的風險。
模式 C：批次取樣
對於大量批次（100 項以上），對每一項都執行完整的聖誕老人驗證法成本過高。請使用分層取樣：
- 對隨機樣本（批次量的 10-15%，至少 5 項）執行聖誕老人驗證法
- 按類型分類失敗（幻覺、合規、完整性等）
- 如果發現系統性模式，對整個批次進行目標性修正
- 重新取樣並重新驗證修正後的批次
- 持續直到清潔樣本通過為止
import random
def santa_batch(items, rubric, sample_rate=0.15):
sample = random.sample(items, max(5, int(len(items) * sample_rate)))
for item in sample:
result = santa_full(item, rubric)
if result.verdict == "NAUGHTY":
pattern = classify_failure(result.issues)
items = batch_fix(items, pattern) # 修正所有符合該模式的項目
return santa_batch(items, rubric) # 重新取樣
return items # 清潔樣本 → 發佈整個批次
失敗模式與緩解措施
| 失敗模式 | 症狀 | 緩解措施 |
|---|---|---|
| 無限循環 | 審查者在修正後仍不斷發現新問題 | 最大迭代次數上限（3次）。升級。 |
| 橡皮圖章 | 兩位審查者都通過所有項目 | 對抗式提示：「你的工作是找出問題，而不是核准。」 |
| 主觀漂移 | 審查者標記風格偏好，而非錯誤 | 嚴謹的評估標準，僅包含客觀的通過/失敗條件 |
| 修正回歸 | 修正問題 A 卻引入了問題 B | 每一輪使用全新的審查者以捕捉回歸 |
| 審查者一致性偏誤 | 兩位審查者都錯過了同一事物 | 可透過獨立性緩解，但無法完全消除。對於關鍵輸出，可新增第三位審查者或進行人工抽檢。 |
| 成本爆炸 | 在大輸出上耗費太多迭代次數 | 批次取樣模式。每個驗證週期設定預算上限。 |
與其他技能的整合
| 技能 | 關係 |
|---|---|
| 驗證循環 | 用於確定性檢查（建置、lint、測試）。聖誕老人驗證法用於語意檢查（準確性、幻覺）。先執行驗證循環，再執行聖誕老人驗證法。 |
| 評估工具 | 聖誕老人驗證法的結果可回饋到評估指標。追蹤聖誕老人驗證法執行中的 pass@k，以衡量生成器隨時間的品質。 |
| 持續學習 v2 | 聖誕老人驗證法的發現會轉化為本能。對同一標準反覆失敗 → 學習到的行為以避免該模式。 |
| 策略壓縮 | 在壓縮之前執行聖誕老人驗證法。不要在驗證中期遺失審查上下文。 |
指標
追蹤這些指標以衡量聖誕老人驗證法的有效性：
- 首次通過率：在第一輪就通過聖誕老人驗證法的輸出百分比（目標：>70%）
- 收斂的平均迭代次數：達到乖巧狀態所需的平均輪數（目標：<1.5）
- 問題分類：失敗類型的分布（幻覺 vs. 完整性 vs. 合規性）
- 審查者一致性：兩位審查者都標記的問題 vs. 只有一位標記的問題的百分比（一致性低表示評估標準需要收緊）
- 逃逸率：發佈後才發現的、聖誕老人驗證法本應能捕捉到的問題（目標：0）
成本分析
聖誕老人驗證法每個驗證週期的成本約為單獨生成的 2-3 倍。對於大多數高風險輸出而言，這是一筆划算的交易：
聖誕老人驗證法的成本 = (生成 token) + 2×(每輪審查 token) × (平均輪數)
不使用聖誕老人驗證法的成本 = (聲譽損害) + (修正努力) + (信任侵蝕)
對於批次操作，取樣模式可將成本降低至完整驗證的約 15-20%，同時能捕捉超過 90% 的系統性問題。