AI Skills
santa-method

santa-method

熱門

多智能體對抗驗證與收斂迴圈。兩個獨立審查智能體必須同時通過，輸出才能出貨。

23萬星標
3.5萬分支
更新於 2026/7/19
獲取技能源代碼

相關技能

fine-tuning-expert1.1萬adhd2573migrate-ai-sdk-v6-to-v72.6萬
SKILL.md
readonlyread-only
name
santa-method
description

多智能體對抗驗證與收斂迴圈。兩個獨立審查智能體必須同時通過，輸出才能出貨。

Santa Method

多智能體對抗驗證框架。列清單，檢查兩次。如果不乖，修正到乖為止。

核心洞察：單一智能體審查自己的輸出，會共享產生該輸出時的相同偏誤、知識缺口和系統性錯誤。兩個沒有共享上下文的獨立審查者可以打破這種失敗模式。

何時啟用

在以下情況呼叫此技能：

  • 輸出將被發布、部署或供終端使用者使用
  • 必須遵守合規、法規或品牌限制
  • 程式碼在沒有人工審查的情況下部署到生產環境
  • 內容準確性很重要（技術文件、教育材料、客戶面向文案）
  • 大規模批次生成，抽樣檢查無法發現系統性模式
  • 幻覺風險較高（主張、統計數據、API 參考、法律用語）

請勿用於內部草稿、探索性研究或具有確定性驗證的任務（這些應使用建置/測試/lint 管線）。

架構

┌─────────────┐
│  生成器      │  階段 1：列清單
│  (智能體 A)  │  產出交付物
└──────┬───────┘
       │ 輸出
       ▼
┌──────────────────────────────┐
│     雙重獨立審查              │  階段 2：檢查兩次
│                                │
│  ┌───────────┐ ┌───────────┐  │  兩個智能體，相同評分標準，
│  │ 審查者 B  │ │ 審查者 C  │  │  無共享上下文
│  └─────┬─────┘ └─────┬─────┘  │
│        │              │        │
└────────┼──────────────┼────────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│        判決閘門               │  階段 3：乖或不乖
│                                │
│  B 通過 且 C 通過 → 乖        │  兩者都必須通過。
│  否則 → 不乖                  │  沒有例外。
└──────┬──────────────┬─────────┘
       │              │
    乖              不乖
       │              │
       ▼              ▼
   [ 出貨 ]    ┌─────────────┐
               │  修正迴圈    │  階段 4：修正到乖
               │              │
               │ iteration++  │  收集所有標記。
               │ if i > MAX:  │  修正所有問題。
               │   升級       │  重新執行兩個審查者。
               │ else:        │  迴圈直到收斂。
               │   goto 階段2 │
               └──────────────┘

階段細節

階段 1：列清單（生成）

執行主要任務。不改變你正常的生成工作流程。Santa Method 是生成後的驗證層，不是生成策略。

# 生成器正常執行
output = generate(task_spec)

階段 2：檢查兩次（獨立雙重審查）

並行生成兩個審查智能體。關鍵不變量：

  1. 上下文隔離 — 兩個審查者互看不到對方的評估
  2. 相同評分標準 — 兩者收到相同的評估標準
  3. 相同輸入 — 兩者都收到原始規格和生成的輸出
  4. 結構化輸出 — 每個回傳類型化的判決，而非散文
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="Santa 審查者 B")
review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa 審查者 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

為什麼兩者都必須通過：如果只有一個審查者發現問題，那個問題是真實存在的。另一個審查者的盲點正是 Santa Method 存在要消除的失敗模式。

階段 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 審查 B",
    prompt=f"審查此輸出的品質...\n\n評分標準：\n{rubric}\n\n輸出：\n{output}"
)
reviewer_c = Agent(
    description="Santa 審查 C",
    prompt=f"審查此輸出的品質...\n\n評分標準：\n{rubric}\n\n輸出：\n{output}"
)

模式 B：順序內聯（備用）

當子智能體不可用時，透過明確的上下文重置來模擬隔離：

  1. 生成輸出
  2. 新上下文：「你是審查者 1。僅根據此評分標準進行評估。找出問題。」
  3. 逐字記錄發現
  4. 完全清除上下文
  5. 新上下文：「你是審查者 2。僅根據此評分標準進行評估。找出問題。」
  6. 比較兩個審查，修正，重複

子智能體模式嚴格優越 — 內聯模擬有上下文在審查者之間洩漏的風險。

模式 C：批次抽樣

對於大型批次（100 項以上），對每個項目執行完整 Santa 成本過高。使用分層抽樣：

  1. 對隨機樣本執行 Santa（批次的 10-15%，至少 5 項）
  2. 按類型分類失敗（幻覺、合規、完整性等）
  3. 如果出現系統性模式，對整個批次應用目標修正
  4. 重新抽樣並重新驗證修正後的批次
  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 每輪使用全新審查者來捕捉回歸
審查者同意偏誤 兩個審查者都錯過同一件事 透過獨立性緩解，但無法消除。對於關鍵輸出，加入第三個審查者或人工抽檢。
成本爆炸 大型輸出上迭代次數過多 批次抽樣模式。每個驗證週期的預算上限。

與其他技能的整合

技能 關係
Verification Loop 用於確定性檢查（建置、lint、測試）。Santa 用於語義檢查（準確性、幻覺）。先執行 verification-loop，再執行 Santa。
Eval Harness Santa Method 結果回饋到評估指標。追蹤 Santa 執行的 pass@k 以衡量生成器隨時間的品質。
Continuous Learning v2 Santa 的發現變成直覺。同一標準上的重複失敗 → 學習行為以避免該模式。
Strategic Compact 在壓縮前執行 Santa。不要在驗證中途失去審查上下文。

指標

追蹤這些指標以衡量 Santa Method 的有效性：

  • 首次通過率：第一輪通過 Santa 的輸出百分比（目標：>70%）
  • 平均收斂迭代次數：達到 NICE 的平均輪數（目標：<1.5）
  • 問題分類：失敗類型的分布（幻覺 vs. 完整性 vs. 合規）
  • 審查者一致性：兩個審查者都標記的問題 vs. 只有一個標記的問題的百分比（一致性低 = 評分標準需要收緊）
  • 逃脫率：出貨後發現但 Santa 應該捕捉到的問題（目標：0）

成本分析

每個驗證週期中，Santa Method 的成本大約是單獨生成的 token 成本的 2-3 倍。對於大多數高風險輸出，這很划算：

Santa 成本 = (生成 token) + 2×(每輪審查 token) × (平均輪數)
不使用 Santa 的成本 = (聲譽損害) + (修正努力) + (信任侵蝕)

對於批次操作，抽樣模式將成本降低到完整驗證的約 15-20%，同時捕捉超過 90% 的系統性問題。