選項

santa-method

affaan-m/ECC affaan-m/ECC

採用兩名獨立的審核人員來驗證輸出品質,須兩者均通過後方可出貨。

...展開全部
0
更新時間 2026-10-01

聖誕老人法

多代理對抗性驗證框架。列出清單,仔細核對兩遍。若行為不當,就不斷修正直到合宜為止。

核心洞見:單一代理在審查自身產出時,會帶有與產生該產出時相同的偏見、知識缺口及系統性錯誤。兩名沒有共同背景的獨立審查者,則能打破這種失敗模式。

何時啟用

在以下情況下啟用此技能:

  • 輸出結果即將發佈、部署或由終端使用者使用時
  • 必須遵守合規、法規或品牌限制
  • 程式碼在未經人工審查的情況下直接部署至生產環境
  • 內容準確性至關重要(技術文件、教育資料、面向客戶的文案)
  • 大規模批次生成,且抽查無法察覺系統性模式時
  • 產生「幻覺」的風險較高(陳述、統計數據、API 參考資料、法律用語)

請勿用於內部草稿、探索性研究或可進行確定性驗證的任務(此類情況請使用建置/測試/程式碼檢查管道)。

架構

┌─────────────┐
│  GENERATOR   │  Phase 1: Make a List
│  (Agent A)   │  Produce the deliverable
└──────┬───────┘
       │ output
       ▼
┌──────────────────────────────┐
│     DUAL INDEPENDENT REVIEW   │  Phase 2: Check It Twice
│                                │
│  ┌───────────┐ ┌───────────┐  │  Two agents, same rubric,
│  │ Reviewer B │ │ Reviewer C │  │  no shared context
│  └─────┬─────┘ └─────┬─────┘  │
│        │              │        │
└────────┼──────────────┼────────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│        VERDICT GATE           │  Phase 3: Naughty or Nice
│                                │
│  B passes AND C passes → NICE  │  Both must pass.
│  Otherwise → NAUGHTY           │  No exceptions.
└──────┬──────────────┬─────────┘
       │              │
    NICE           NAUGHTY
       │              │
       ▼              ▼
   [ SHIP ]    ┌─────────────┐
               │  FIX CYCLE   │  Phase 4: Fix Until Nice
               │              │
               │ iteration++  │  Collect all flags.
               │ if i > MAX:  │  Fix all issues.
               │   escalate   │  Re-run both reviewers.
               │ else:        │  Loop until convergence.
               │   goto Ph.2  │
               └──────────────┘

階段詳情

第 1 階段:建立清單(生成)

執行主要任務。無需變更您平常的生成工作流程。「聖誕老人法」是一層生成後的驗證機制,而非生成策略。

# The generator runs as normal
output = generate(task_spec)

第二階段:雙重檢查(獨立雙重審查)

並行啟動兩個審查代理。關鍵不變條件:

  1. 上下文隔離 — 兩位審查員均無法查看對方的評估結果
  2. 相同的評分標準 — 兩者皆收到相同的評分準則
  3. 相同輸入 — 兩者均收到原始規格說明以及生成的輸出結果
  4. 結構化輸出 — 每位審查員均回傳類型化的評斷結果,而非散文式描述
REVIEWER_PROMPT = """
You are an independent quality reviewer. You have NOT seen any other review of this output.

## Task Specification
{task_spec}

## Output Under Review
{output}

## Evaluation Rubric
{rubric}

## Instructions
Evaluate the output against EACH rubric criterion. For each:
- PASS: criterion fully met, no issues
- FAIL: specific issue found (cite the exact problem)

Return your assessment as structured JSON:
{
  "verdict": "PASS" | "FAIL",
  "checks": [
    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
  ],
  "critical_issues": ["..."],   // blockers that must be fixed
  "suggestions": ["..."]         // non-blocking improvements
}

Be rigorous. Your job is to find problems, not to approve.
"""
# Spawn reviewers in parallel (Claude Code subagents)
review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")

# Both run concurrently — neither sees the other

評分標準設計

評分標準是最重要的輸入要素。模糊的評分標準會產生模糊的評審結果。每項評分標準都必須具備客觀的「合格/不合格」判定條件。

評分標準 通過條件 未達標訊號
事實準確性 所有論點均可透過原始資料或常識加以驗證 虛構的統計數據、錯誤的版本號、不存在的 API
無虛構內容 無捏造的實體、引言、網址或參考資料 連結至不存在的頁面、標註出處但無來源的引言
完整性 規格中的每項要求均已處理 缺失章節、遺漏邊界案例、覆蓋範圍不完整
合規性 通過所有專案特定的限制條件 使用禁用詞彙、語氣不當、違反法規
內部一致性 輸出內容無矛盾 A 節所述為 X,B 節所述卻非 X
技術正確性 程式碼可編譯/執行,演算法無誤 語法錯誤、邏輯錯誤、複雜度聲稱不正確

領域特定評分標準擴充

內容/行銷:

  • 遵循品牌語調
  • 符合 SEO 要求(關鍵字密度、元標籤、網站結構)
  • 未濫用競爭對手的商標
  • 已設置行動呼籲(CTA)且連結正確

程式碼:

  • 類型安全(無 any 記憶體洩漏、正確的 null 處理)
  • 錯誤處理覆蓋率
  • 安全性(程式碼中無機密資訊、輸入驗證、防範注入攻擊)
  • 新路徑的測試覆蓋率

合規敏感性(受監管、法律、財務):

  • 不作結果保證或未經證實的聲明
  • 已包含必要的免責聲明
  • 僅使用經核准的術語
  • 採用符合管轄區規範的措辭

第三階段:合規與否(裁決關卡)

def santa_verdict(review_b, review_c):
    """Both reviewers must pass. No partial credit."""
    if review_b.verdict == "PASS" and review_c.verdict == "PASS":
        return "NICE"  # Ship it

    # Merge flags from both reviewers, deduplicate
    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

為何兩者都必須通過:若僅有一位審查員發現問題,該問題即屬真實。另一位審查員的盲點,正是「聖誕老人法」旨在消除的失效模式。

第四階段:修正直至合格(收斂迴圈)

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)

    # Fix all critical issues (suggestions are optional)
    output = fix_agent.execute(
        output=output,
        issues=issues,
        instruction="Fix ONLY the flagged issues. Do not refactor or add unrequested changes."
    )

    # Re-run BOTH reviewers on fixed output (fresh agents, no memory of previous round)
    review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
    review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))

# Exhausted iterations — escalate
log_santa_result(output, MAX_ITERATIONS, "escalated")
escalate_to_human(output, issues)

關鍵:每輪審查均須使用全新的代理。審查員絕不能帶有前幾輪的記憶,因為先前的背景會產生錨定偏誤。

實作模式

模式 A:Claude 程式碼子代理(推薦)

子代理能提供真正的上下文隔離。每位審查員皆為獨立的程序,且不共享狀態。

# In a Claude Code session, use the Agent tool to spawn reviewers
# Both agents run in parallel for speed
# Pseudocode for Agent tool invocation
reviewer_b = Agent(
    description="Santa Review B",
    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
)
reviewer_c = Agent(
    description="Santa Review C",
    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
)

模式 B:順序內嵌(備用方案)

當無法使用子代理時,可透過明確重設上下文來模擬隔離:

  1. 產生輸出
  2. 新上下文:「您是審查員 1。請僅依據此評分標準進行評估。找出問題。」
  3. 逐字記錄發現結果
  4. 完全清除上下文
  5. 新情境:「你是評審員 2。請僅依據此評分標準進行評估。找出問題。」
  6. 比較兩份評審結果、修正問題,並重複此流程

子代理模式具有絕對優勢——內嵌式模擬會導致審閱者之間出現情境滲透的風險。

模式 C:批次抽樣

對於大型批次(100 項以上),對每項都執行完整的「聖誕老人」演算會造成過高的成本。請使用分層抽樣:

  1. 對隨機樣本(批次總量的 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)  # Fix all items matching pattern
            return santa_batch(items, rubric)   # Re-sample

    return items  # Clean sample → ship batch

失效模式與緩解措施

失效模式 症狀 緩解措施
無限迴圈 審查人員在修復後仍不斷發現新問題 設定最大迭代次數上限(3)。向上報告。
走過場 兩位審查員全數通過 對立式提示:「你的工作是找出問題,而不是批准。」
主觀偏移 審查員標記的是風格偏好,而非錯誤 僅採用嚴格的評分標準,且僅以客觀的「通過/未通過」為準
修正回歸問題 解決問題 A 卻引發了問題 B 每輪由新審查員發現退步現象
審查員一致性偏誤 兩位審查員都漏檢了相同的問題 可透過獨立性加以緩解,但無法完全消除。對於關鍵輸出,應增加第三位審查員或由人工進行抽查。
成本激增 針對大型產出進行過多迭代 採用批次抽樣模式。每輪驗證週期設有預算上限。

與其他技能的整合

技能 關聯性
驗證迴圈 用於確定性檢查(建置、語法檢查、測試)。Santa 用於語義檢查(準確性、幻覺)。先執行驗證迴圈,再執行 Santa。
評估框架 Santa 方法的結果會饋入評估指標。透過追蹤 Santa 執行過程中的 pass@k 數值,以衡量生成器隨時間推移的品質。
持續學習 v2 Santa 的發現會轉化為「直覺」。若在同一項標準上反覆失敗 → 系統將學習如何避免該模式。
策略性壓縮 在進行壓縮前先執行 Santa。避免在驗證過程中遺失審查脈絡。

指標

追蹤以下指標以衡量 Santa 方法的有效性:

  • 首輪通過率:第一輪通過聖誕老人測試的輸出比例(目標:>70%)
  • 收斂所需平均迭代次數:達到 NICE 標準所需的平均輪次(目標:<1.5)
  • 問題分類:失敗類型的分布(幻覺 vs. 完整性 vs. 合規性)
  • 審查員一致性:兩位審查員均標記的問題佔總數的百分比,相對於僅由其中一位標記的問題(一致性低 = 評分標準需收緊)
  • 漏檢率:聖誕老人本應偵測到、卻在發布後才發現的問題比例(目標:0)

成本分析

Santa Method 每輪驗證週期的成本約為單純生成代幣成本的 2 至 3 倍。對於大多數高風險輸出而言,這是一筆划算的投資:

Cost of Santa = (generation tokens) + 2×(review tokens per round) × (avg rounds)
Cost of NOT Santa = (reputation damage) + (correction effort) + (trust erosion)

對於批次操作,其抽樣模式可將成本降低至完整驗證成本的約 15-20%,同時能偵測出超過 90% 的系統性問題。

在 GitHub 上查看
---
name: santa-method
description: Uses two independent review agents to verify output quality, requiring both to pass before shipping.
---

# Santa Method

Multi-agent adversarial verification framework. Make a list, check it twice. If it's naughty, fix it until it's nice.

The core insight: a single agent reviewing its own output shares the same biases, knowledge gaps, and systematic errors that produced the output. Two independent reviewers with no shared context break this failure mode.

## When to Activate

Invoke this skill when:
- Output will be published, deployed, or consumed by end users
- Compliance, regulatory, or brand constraints must be enforced
- Code ships to production without human review
- Content accuracy matters (technical docs, educational material, customer-facing copy)
- Batch generation at scale where spot-checking misses systemic patterns
- Hallucination risk is elevated (claims, statistics, API references, legal language)

Do NOT use for internal drafts, exploratory research, or tasks with deterministic verification (use build/test/lint pipelines for those).

## Architecture

```
┌─────────────┐
│  GENERATOR   │  Phase 1: Make a List
│  (Agent A)   │  Produce the deliverable
└──────┬───────┘
       │ output
       ▼
┌──────────────────────────────┐
│     DUAL INDEPENDENT REVIEW   │  Phase 2: Check It Twice
│                                │
│  ┌───────────┐ ┌───────────┐  │  Two agents, same rubric,
│  │ Reviewer B │ │ Reviewer C │  │  no shared context
│  └─────┬─────┘ └─────┬─────┘  │
│        │              │        │
└────────┼──────────────┼────────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│        VERDICT GATE           │  Phase 3: Naughty or Nice
│                                │
│  B passes AND C passes → NICE  │  Both must pass.
│  Otherwise → NAUGHTY           │  No exceptions.
└──────┬──────────────┬─────────┘
       │              │
    NICE           NAUGHTY
       │              │
       ▼              ▼
   [ SHIP ]    ┌─────────────┐
               │  FIX CYCLE   │  Phase 4: Fix Until Nice
               │              │
               │ iteration++  │  Collect all flags.
               │ if i > MAX:  │  Fix all issues.
               │   escalate   │  Re-run both reviewers.
               │ else:        │  Loop until convergence.
               │   goto Ph.2  │
               └──────────────┘
```

## Phase Details

### Phase 1: Make a List (Generate)

Execute the primary task. No changes to your normal generation workflow. Santa Method is a post-generation verification layer, not a generation strategy.

```python
# The generator runs as normal
output = generate(task_spec)
```

### Phase 2: Check It Twice (Independent Dual Review)

Spawn two review agents in parallel. Critical invariants:

1. **Context isolation** — neither reviewer sees the other's assessment
2. **Identical rubric** — both receive the same evaluation criteria
3. **Same inputs** — both receive the original spec AND the generated output
4. **Structured output** — each returns a typed verdict, not prose

```python
REVIEWER_PROMPT = """
You are an independent quality reviewer. You have NOT seen any other review of this output.

## Task Specification
{task_spec}

## Output Under Review
{output}

## Evaluation Rubric
{rubric}

## Instructions
Evaluate the output against EACH rubric criterion. For each:
- PASS: criterion fully met, no issues
- FAIL: specific issue found (cite the exact problem)

Return your assessment as structured JSON:
{
  "verdict": "PASS" | "FAIL",
  "checks": [
    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
  ],
  "critical_issues": ["..."],   // blockers that must be fixed
  "suggestions": ["..."]         // non-blocking improvements
}

Be rigorous. Your job is to find problems, not to approve.
"""
```

```python
# Spawn reviewers in parallel (Claude Code subagents)
review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")

# Both run concurrently — neither sees the other
```

### Rubric Design

The rubric is the most important input. Vague rubrics produce vague reviews. Every criterion must have an objective pass/fail condition.

| Criterion | Pass Condition | Failure Signal |
|-----------|---------------|----------------|
| Factual accuracy | All claims verifiable against source material or common knowledge | Invented statistics, wrong version numbers, nonexistent APIs |
| Hallucination-free | No fabricated entities, quotes, URLs, or references | Links to pages that don't exist, attributed quotes with no source |
| Completeness | Every requirement in the spec is addressed | Missing sections, skipped edge cases, incomplete coverage |
| Compliance | Passes all project-specific constraints | Banned terms used, tone violations, regulatory non-compliance |
| Internal consistency | No contradictions within the output | Section A says X, section B says not-X |
| Technical correctness | Code compiles/runs, algorithms are sound | Syntax errors, logic bugs, wrong complexity claims |

#### Domain-Specific Rubric Extensions

**Content/Marketing:**
- Brand voice adherence
- SEO requirements met (keyword density, meta tags, structure)
- No competitor trademark misuse
- CTA present and correctly linked

**Code:**
- Type safety (no `any` leaks, proper null handling)
- Error handling coverage
- Security (no secrets in code, input validation, injection prevention)
- Test coverage for new paths

**Compliance-Sensitive (regulated, legal, financial):**
- No outcome guarantees or unsubstantiated claims
- Required disclaimers present
- Approved terminology only
- Jurisdiction-appropriate language

### Phase 3: Naughty or Nice (Verdict Gate)

```python
def santa_verdict(review_b, review_c):
    """Both reviewers must pass. No partial credit."""
    if review_b.verdict == "PASS" and review_c.verdict == "PASS":
        return "NICE"  # Ship it

    # Merge flags from both reviewers, deduplicate
    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
```

Why both must pass: if only one reviewer catches an issue, that issue is real. The other reviewer's blind spot is exactly the failure mode Santa Method exists to eliminate.

### Phase 4: Fix Until Nice (Convergence Loop)

```python
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)

    # Fix all critical issues (suggestions are optional)
    output = fix_agent.execute(
        output=output,
        issues=issues,
        instruction="Fix ONLY the flagged issues. Do not refactor or add unrequested changes."
    )

    # Re-run BOTH reviewers on fixed output (fresh agents, no memory of previous round)
    review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
    review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))

# Exhausted iterations — escalate
log_santa_result(output, MAX_ITERATIONS, "escalated")
escalate_to_human(output, issues)
```

Critical: each review round uses **fresh agents**. Reviewers must not carry memory from previous rounds, as prior context creates anchoring bias.

## Implementation Patterns

### Pattern A: Claude Code Subagents (Recommended)

Subagents provide true context isolation. Each reviewer is a separate process with no shared state.

```bash
# In a Claude Code session, use the Agent tool to spawn reviewers
# Both agents run in parallel for speed
```

```python
# Pseudocode for Agent tool invocation
reviewer_b = Agent(
    description="Santa Review B",
    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
)
reviewer_c = Agent(
    description="Santa Review C",
    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
)
```

### Pattern B: Sequential Inline (Fallback)

When subagents aren't available, simulate isolation with explicit context resets:

1. Generate output
2. New context: "You are Reviewer 1. Evaluate ONLY against this rubric. Find problems."
3. Record findings verbatim
4. Clear context completely
5. New context: "You are Reviewer 2. Evaluate ONLY against this rubric. Find problems."
6. Compare both reviews, fix, repeat

The subagent pattern is strictly superior — inline simulation risks context bleed between reviewers.

### Pattern C: Batch Sampling

For large batches (100+ items), full Santa on every item is cost-prohibitive. Use stratified sampling:

1. Run Santa on a random sample (10-15% of batch, minimum 5 items)
2. Categorize failures by type (hallucination, compliance, completeness, etc.)
3. If systematic patterns emerge, apply targeted fixes to the entire batch
4. Re-sample and re-verify the fixed batch
5. Continue until a clean sample passes

```python
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)  # Fix all items matching pattern
            return santa_batch(items, rubric)   # Re-sample

    return items  # Clean sample → ship batch
```

## Failure Modes and Mitigations

| Failure Mode | Symptom | Mitigation |
|-------------|---------|------------|
| Infinite loop | Reviewers keep finding new issues after fixes | Max iteration cap (3). Escalate. |
| Rubber stamping | Both reviewers pass everything | Adversarial prompt: "Your job is to find problems, not approve." |
| Subjective drift | Reviewers flag style preferences, not errors | Tight rubric with objective pass/fail criteria only |
| Fix regression | Fixing issue A introduces issue B | Fresh reviewers each round catch regressions |
| Reviewer agreement bias | Both reviewers miss the same thing | Mitigated by independence, not eliminated. For critical output, add a third reviewer or human spot-check. |
| Cost explosion | Too many iterations on large outputs | Batch sampling pattern. Budget caps per verification cycle. |

## Integration with Other Skills

| Skill | Relationship |
|-------|-------------|
| Verification Loop | Use for deterministic checks (build, lint, test). Santa for semantic checks (accuracy, hallucinations). Run verification-loop first, Santa second. |
| Eval Harness | Santa Method results feed eval metrics. Track pass@k across Santa runs to measure generator quality over time. |
| Continuous Learning v2 | Santa findings become instincts. Repeated failures on the same criterion → learned behavior to avoid the pattern. |
| Strategic Compact | Run Santa BEFORE compacting. Don't lose review context mid-verification. |

## Metrics

Track these to measure Santa Method effectiveness:

- **First-pass rate**: % of outputs that pass Santa on round 1 (target: >70%)
- **Mean iterations to convergence**: average rounds to NICE (target: <1.5)
- **Issue taxonomy**: distribution of failure types (hallucination vs. completeness vs. compliance)
- **Reviewer agreement**: % of issues flagged by both reviewers vs. only one (low agreement = rubric needs tightening)
- **Escape rate**: issues found post-ship that Santa should have caught (target: 0)

## Cost Analysis

Santa Method costs approximately 2-3x the token cost of generation alone per verification cycle. For most high-stakes output, this is a bargain:

```
Cost of Santa = (generation tokens) + 2×(review tokens per round) × (avg rounds)
Cost of NOT Santa = (reputation damage) + (correction effort) + (trust erosion)
```

For batch operations, the sampling pattern reduces cost to ~15-20% of full verification while catching >90% of systematic issues.

所有檔案

1 個檔案

安裝 santa-method

請下載並將技能檔案解壓縮至您的 .claude/skills/ 目錄中。

下載 ZIP

複製儲存庫並將技能檔案複製到您的專案中。

git clone https://github.com/affaan-m/ECC/tree/main/skills/santa-method # Copy SKILL.md to your .claude/skills/ directory

複製 複製
快速設定: 將技能資料夾複製到 .claude/skills/ Claude 會自動偵測並使用該技能
儲存庫 affaan-m/ECC

相關技能

web-search
更新時間 2026-06-29
webapp-testing
更新時間 2026-06-29
lark-base
更新時間 2026-07-05
agentmail
更新時間 2026-06-29
OR