Santa Method
多智能体对抗性验证框架。列清单，查两遍。如果是顽皮的，修正它直到变乖。
核心洞察：单个智能体审核自己生成的输出时，会共享导致该输出的相同偏见、知识盲区和系统性错误。两个没有共享上下文的独立审核者可以打破这种失效模式。
何时激活
遇到以下情况时调用此技能：
- 输出将发布、部署或交付给最终用户
- 必须遵守合规、监管或品牌约束
- 代码在没有人工审核的情况下部署到生产环境
- 内容准确性至关重要（技术文档、教育材料、面向客户的文案）
- 大规模批量生成，抽样检查会遗漏系统性模式
- 幻觉风险较高（声明、统计数据、API 参考、法律语言）
不要用于内部草稿、探索性研究或具有确定性验证的任务（这些应使用构建/测试/检查管道）。
架构
┌─────────────┐
│ 生成器 │ 阶段 1：列清单
│ (智能体 A) │ 产生交付物
└──────┬───────┘
│ 输出
▼
┌──────────────────────────────┐
│ 双重独立审核 │ 阶段 2：查两遍
│ │
│ ┌───────────┐ ┌───────────┐ │ 两个智能体，相同的评价标准，
│ │ 审核者 B │ │ 审核者 C │ │ 无共享上下文
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
└────────┼──────────────┼────────┘
│ │
▼ ▼
┌──────────────────────────────┐
│ 判决门 │ 阶段 3：顽皮或乖巧
│ │
│ B 通过 且 C 通过 → 乖巧 │ 两者必须通过。
│ 否则 → 顽皮 │ 无例外。
└──────┬──────────────┬─────────┘
│ │
乖巧 顽皮
│ │
▼ ▼
[ 交付 ] ┌─────────────┐
│ 修复循环 │ 阶段 4：修正直到变乖
│ │
│ 迭代次数++ │ 收集所有问题。
│ 如果迭代次数 > 最大值：│ 修复所有问题。
│ 上报 │ 重新运行两个审核者。
│ 否则： │ 循环直到收敛。
│ 转到阶段 2 │
└──────────────┘
阶段详情
阶段 1：列清单（生成）
执行主要任务。无需改变正常的生成工作流程。Santa Method 是生成后的验证层，而非生成策略。
# 生成器正常运行
output = generate(task_spec)
阶段 2：查两遍（独立双重审核）
并行生成两个审核智能体。关键不变条件：
- 上下文隔离 — 任一审核者看不到另一方的评估
- 相同的评价标准 — 两者都收到相同的评估标准
- 相同的输入 — 两者都收到原始规格说明和生成的输出
- 结构化输出 — 每个都返回类型化的判决，而非散文
REVIEWER_PROMPT = """
你是一名独立质量审核员。你未见过对此输出的任何其他审核。
## 任务规格说明
{task_spec}
## 待审核的输出
{output}
## 评估标准
{rubric}
## 指示
对照每个评价标准评估输出。对于每个标准：
- 通过：标准完全满足，没有问题
- 失败：发现具体问题（引用确切问题）
以结构化 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 要求（关键词密度、元标签、结构）
- 无竞争对手商标误用
- 行动号召并存且链接正确
代码：
- 类型安全性（无
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 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。仅对照此标准进行评估。发现问题。”
- 比较两个审核结果，修复，重复
子代理模式严格优于串行内联 — 串行模拟存在审核者之间的上下文泄漏风险。
模式 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. 合规性）
- 审核者一致性：两个审核者都标记的问题百分比（一致性低意味着评价标准需要收紧）
- 逃逸率：交付后发现的、Santa 本应捕获的问题（目标：0）
成本分析
Santa Method 每个验证周期的代币成本约为仅生成成本的 2-3 倍。对于大多数高风险输出来说，这很划算：
Santa 成本 = (生成代币) + 2×(每轮审核代币) × (平均轮数)
不使用 Santa 的成本 = (声誉损害) + (修正工作量) + (信任侵蚀)
对于批量操作，采样模式将成本降低到约全面验证的 15-20%，同时捕获 >90% 的系统性问题。