聖誕老公公驗證法 是做什麼的？
多重智能體對抗式驗證框架。列出清單，檢查兩次。若表現不佳，修正到完善為止。
核心洞察：由單一智能體審查自己的產出，會共享產生該產出時的相同偏誤、知識缺口與系統性錯誤。兩個無共享上下文的獨立審查者，可以打破這種失敗模式。
何時啟動
在以下情況啟用此技能：
- 輸出將會發布、部署或提供給終端使用者
- 需強制遵守合規、法規或品牌限制
- 程式碼在無人為審查的情況下上線
- 內容準確性至關重要（技術文件、教育材料、客戶面對的文案）
- 大規模批次生成，抽樣檢查無法發現系統性模式
- 幻覺風險高（聲明、統計資料、API 參考、法律語言）
不適用於內部草稿、探索性研究，或可透過建置/測試/lint 管線進行確定性驗證的任務。
架構
┌─────────────┐
│ 生成器 │ 階段 1：列出清單
│ (智能體 A) │ 產出交付物
└──────┬───────┘
│ 輸出
▼
┌──────────────────────────────┐
│ 雙重獨立審查 │ 階段 2：檢查兩次
│ │
│ ┌───────────┐ ┌───────────┐ │ 兩個智能體，相同評分規章，
│ │ 審查者 B │ │ 審查者 C │ │ 無共享上下文
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
└────────┼──────────────┼────────┘
│ │
▼ ▼
┌──────────────────────────────┐
│ 裁決閘門 │ 階段 3：頑皮或乖巧
│ │
│ B 通過且 C 通過 → 乖巧 │ 兩者皆須通過。
│ 否則 → 頑皮 │ 不得有例外。
└──────┬──────────────┬─────────┘
│ │
乖巧 頑皮
│ │
▼ ▼
[ 發布 ] ┌─────────────┐
│ 修正循環 │ 階段 4：修正到完善
│ │
│ iteration++ │ 收集所有標記。
│ if i > MAX: │ 修正所有問題。
│ 升級 │ 重新執行兩位審查者。
│ else: │ 重複直到收斂。
│ 跳至階段 2 │
└──────────────┘
階段詳情
階段 1：列出清單（生成）
執行主要任務。不改變您正常的生成流程。聖誕老公公驗證法是後生成的驗證層，而非生成策略。
# 生成器正常執行
output = generate(task_spec)
階段 2：檢查兩次（獨立雙重審查）
同時啟動兩個審查智能體。關鍵不變量：
- 上下文隔離 — 兩位審查者互看不到對方的評估
- 相同的評分規章 — 兩者收到相同的評估標準
- 相同的輸入 — 兩者都收到原始規格與產生的輸出
- 結構化輸出 — 每個審查者返回結構化裁決，而非散文
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 段說 not-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 "乖巧" # 發布
# 合併兩位審查者的標記，去重
all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)
return "頑皮", 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 == "乖巧":
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="聖誕審查 B",
prompt=f"審查此輸出的品質...\n\n評分規章：\n{rubric}\n\n輸出：\n{output}"
)
reviewer_c = Agent(
description="聖誕審查 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 == "頑皮":
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 倍。對於大多數高風險輸出來說，這非常划算：
聖誕成本 = (生成代幣) + 2×(每輪審查代幣) × (平均輪數)
不採用聖誕的成本 = (聲譽損害) + (修正努力) + (信任侵蝕)
對於批次作業，取樣模式可將成本降至完整驗證的約 15-20%，同時能捕捉超過 90% 的系統性問題。