santa-method

Santa Method

多智能体对抗性验证框架。列清单，检查两遍。如果表现不好，就修正直到表现良好。

核心洞察：单个智能体审查自己的输出时，会共享产生该输出的相同偏见、知识空白和系统性错误。两个没有共享上下文的独立审查者可以打破这种失败模式。

何时激活

在以下情况下调用此技能：

输出将被发布、部署或供最终用户使用
必须遵守合规、监管或品牌约束
代码在没有人工审查的情况下发布到生产环境
内容准确性很重要（技术文档、教育材料、面向客户的文案）
大规模批量生成，抽检无法发现系统性模式
幻觉风险较高（声明、统计数据、API 引用、法律语言）

不要用于内部草稿、探索性研究或具有确定性验证的任务（这些任务应使用构建/测试/检查管道）。

架构

┌─────────────┐
│  生成器      │  阶段 1：列清单
│  (智能体 A)  │  生成交付物
└──────┬───────┘
       │ 输出
       ▼
┌──────────────────────────────┐
│     双重独立审查              │  阶段 2：检查两遍
│                                │
│  ┌───────────┐ ┌───────────┐  │  两个智能体，相同标准，
│  │ 审查者 B  │ │ 审查者 C  │  │  无共享上下文
│  └─────┬─────┘ └─────┬─────┘  │
│        │              │        │
└────────┼──────────────┼────────┘
         │              │
         ▼              ▼
┌──────────────────────────────┐
│       裁决门                  │  阶段 3：表现好或不好
│                                │
│  B 通过 且 C 通过 → 表现好     │  两者都必须通过。
│  否则 → 表现不好               │  没有例外。
└──────┬──────────────┬─────────┘
       │              │
    表现好          表现不好
       │              │
       ▼              ▼
   [ 发布 ]    ┌─────────────┐
               │  修正循环    │  阶段 4：修正直到表现好
               │              │
               │ 迭代次数++   │  收集所有标记。
               │ 如果 i > 最大:│  修正所有问题。
               │   升级       │  重新运行两个审查者。
               │ 否则:        │  循环直到收敛。
               │   转到阶段 2 │
               └──────────────┘

阶段详情

阶段 1：列清单（生成）

执行主要任务。无需更改正常的生成工作流程。Santa Method 是生成后的验证层，而非生成策略。

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

阶段 2：检查两遍（独立双重审查）

并行生成两个审查智能体。关键不变条件：

上下文隔离 — 两个审查者互不见对方的评估
相同标准 — 两者收到相同的评估标准
相同输入 — 两者收到原始规格和生成的输出
结构化输出 — 每个返回类型化的裁决，而非散文

审查者提示 = """
你是一个独立的质量审查者。你没有看到过此输出的任何其他审查。

## 任务规格
{task_spec}

## 待审查输出
{output}

## 评估标准
{rubric}

## 说明
根据每个标准评估输出。对于每个标准：
- 通过：标准完全满足，无问题
- 失败：发现具体问题（引用确切问题）

以结构化 JSON 返回你的评估：
{
  "verdict": "PASS" | "FAIL",
  "checks": [
    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
  ],
  "critical_issues": ["..."],   // 必须修复的阻塞问题
  "suggestions": ["..."]         // 非阻塞性改进建议
}

请严格。你的工作是发现问题，而不是批准。
"""

# 并行生成审查者（Claude Code 子智能体）
review_b = Agent(prompt=审查者提示.format(...), description="Santa 审查者 B")
review_c = Agent(prompt=审查者提示.format(...), description="Santa 审查者 C")

# 两者并发运行 — 互不见对方

标准设计

标准是最重要的输入。模糊的标准产生模糊的审查。每个标准必须有客观的通过/失败条件。

标准	通过条件	失败信号
事实准确性	所有声明可依据来源材料或常识验证	编造的统计数据、错误的版本号、不存在的 API
无幻觉	没有虚构的实体、引用、URL 或参考文献	链接到不存在的页面、无来源的引用
完整性	规格中的每个要求都得到处理	缺失部分、跳过边缘情况、覆盖不完整
合规性	通过所有项目特定约束	使用禁用术语、语气违规、监管不合规
内部一致性	输出内无矛盾	A 部分说 X，B 部分说非 X
技术正确性	代码编译/运行，算法合理	语法错误、逻辑错误、错误的复杂度声明

领域特定标准扩展

内容/营销：

品牌语气一致性
满足 SEO 要求（关键词密度、元标签、结构）
无竞争对手商标滥用
行动号召存在且链接正确

代码：

类型安全（无 any 泄漏，适当的空值处理）
错误处理覆盖
安全性（代码中无机密、输入验证、注入预防）
新路径的测试覆盖

合规敏感（监管、法律、金融）：

无结果保证或未经证实的声明
存在所需的免责声明
仅使用批准的术语
适合管辖区的语言

阶段 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：修正直到表现好（收敛循环）

最大迭代次数 = 3

for iteration in range(最大迭代次数):
    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=审查者提示.format(output=output, ...))
    review_c = Agent(prompt=审查者提示.format(output=output, ...))

# 迭代次数耗尽 — 升级
log_santa_result(output, 最大迭代次数, "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。仅根据此标准进行评估。发现问题。”
比较两个审查，修复，重复

子智能体模式严格优于内联模拟 — 内联模拟存在审查者之间上下文泄漏的风险。

模式 C：批量采样

对于大批量（100 项以上），对每个项目完整运行 Santa 成本过高。使用分层采样：

对随机样本运行 Santa（批量的 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	每轮使用新审查者以捕获回归
审查者一致性偏差	两个审查者都遗漏相同内容	通过独立性缓解，但未消除。对于关键输出，添加第三个审查者或人工抽检。
成本爆炸	大输出上迭代次数过多	批量采样模式。每个验证周期的预算上限。

与其他技能的集成

技能	关系
验证循环	用于确定性检查（构建、检查、测试）。Santa 用于语义检查（准确性、幻觉）。先运行验证循环，再运行 Santa。
评估框架	Santa Method 结果输入评估指标。跟踪 Santa 运行中的 pass@k 以衡量生成器质量随时间的变化。
持续学习 v2	Santa 发现成为直觉。同一标准上的重复失败 → 学习避免该模式的行为。
战略压缩	在压缩前运行 Santa。不要在验证过程中丢失审查上下文。

指标

跟踪以下指标以衡量 Santa Method 的有效性：

首次通过率：第一轮通过 Santa 的输出百分比（目标：>70%）
平均收敛迭代次数：达到“表现好”的平均轮数（目标：<1.5）
问题分类：失败类型的分布（幻觉 vs. 完整性 vs. 合规性）
审查者一致性：两个审查者都标记的问题百分比 vs. 仅一个（一致性低 = 标准需要收紧）
逃逸率：发布后发现但 Santa 本应捕获的问题（目标：0）

成本分析

每个验证周期，Santa Method 的成本大约是单独生成的 token 成本的 2-3 倍。对于大多数高风险的输出，这是划算的：

Santa 成本 = (生成 token) + 2×(每轮审查 token) × (平均轮数)
不使用 Santa 的成本 = (声誉损害) + (修正努力) + (信任侵蚀)

对于批量操作，采样模式将成本降低到完整验证的约 15-20%，同时捕获超过 90% 的系统性问题。

你可能还喜欢

ponytail-gain

85Kprompting-reasoning

Show ponytail's measured impact as a compact scoreboard: less code, less cost, more speed, from the benchmark medians. One-shot display, not a persistent mode, and not a per-repo number. Trigger: /ponytail-gain, "ponytail gain", "what does ponytail save", "show ponytail impact", "ponytail scoreboard".

dietrichgebert

获取

evaluation-methodology

38Kprompting-reasoning

PluginEval quality methodology — dimensions, rubrics, statistical methods, and scoring formulas. Use this skill when understanding how plugin quality is measured, when interpreting a low score on a specific dimension, when deciding how to improve a skill's triggering accuracy or orchestration fitness, when calibrating scoring thresholds for your marketplace, or when explaining quality badges to external partners like Neon.

wshobson

获取

cavecrew

75Kprompting-reasoning

将任务委托给穴居人风格子代理的决策指南。告诉主线程何时生成 `cavecrew-investigator`（定位代码）、`cavecrew-builder`（1-2 文件编辑）或 `cavecrew-reviewer`（差异审查），而不是内联执行或使用普通的 `Explore`。子代理输出经过穴居人压缩，因此注入回主上下文的工具结果约小 60%——在长时间会话中，主上下文能维持更久。触发词：“委托给子代理”、“使用 cavecrew”、“生成 investigator/builder/reviewer”、“节省上下文”、“压缩代理输出”。

juliusbrussee

获取

继续探索

浏览 prompting-reasoning 热门 Skills 最近更新