圣诞老人方法 是做什么的？
多智能体对抗验证框架。列个清单，检查两遍。如果不乖，就修到乖为止。
核心洞察：单个智能体对自己的输出进行审查时，会共享产生该输出的相同偏见、知识盲点和系统错误。两个没有共享上下文的独立审查者可以打破这种失效模式。
何时激活
在以下场景中调用此技能：
- 输出将发布、部署或提供给最终用户
- 必须执行合规、监管或品牌约束
- 代码在没有人工审查的情况下发布到生产环境
- 内容准确性至关重要（技术文档、教育材料、面向客户的文案）
- 批量大规模生成，抽检无法发现系统性模式
- 幻觉风险较高（主张、统计数据、API 引用、法律语言）
不要用于内部草稿、探索性研究或具有确定性验证的任务（这些应使用构建/测试/lint 流水线）。
架构
┌─────────────┐
│ 生成器 │ 阶段 1：列个清单
│ (智能体 A) │ 生成可交付物
└──────┬───────┘
│ 输出
▼
┌──────────────────────────────┐
│ 双独立审查 │ 阶段 2：检查两遍
│ │
│ ┌───────────┐ ┌───────────┐ │ 两个智能体，相同评估准则，
│ │ 审查者 B │ │ 审查者 C │ │ 无共享上下文
│ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │
└────────┼──────────────┼────────┘
│ │
▼ ▼
┌──────────────────────────────┐
│ 判决门 │ 阶段 3：乖还是不乖
│ │
│ B 通过且 C 通过 → 乖 │ 两者都必须通过。
│ 否则 → 不乖 │ 没有例外。
└──────┬──────────────┬─────────┘
│ │
乖 不乖
│ │
▼ ▼
[ 交付 ] ┌─────────────┐
│ 修复循环 │ 阶段 4：修到乖为止
│ │
│ iteration++ │ 收集所有标记。
│ if i > MAX: │ 修复所有问题。
│ 升级 │ 重新运行两个审查者。
│ else: │ 循环直到收敛。
│ goto 阶段2│
└──────────────┘
阶段详情
阶段 1：列个清单（生成）
执行主要任务。正常生成工作流程无需更改。圣诞老人方法是生成后的验证层，而非生成策略。
# 生成器正常运行
output = generate(task_spec)
阶段 2：检查两遍（独立双审查）
并行生成两个审查智能体。关键不变量：
- 上下文隔离 — 两个审查者互不见对方的评估
- 相同评估准则 — 两者都收到相同的评估标准
- 相同输入 — 两者都收到原始规格说明和生成的输出
- 结构化输出 — 每个都返回类型化的判决，而非散文
REVIEWER_PROMPT = """
你是一个独立的质量审查者。你没有见过任何其他关于此输出的审查。
## 任务规格说明
{task_spec}
## 待审查输出
{output}
## 评估准则
{rubric}
## 说明
针对每个评估准则评估输出。对于每个准则：
- 通过：准则完全满足，没有问题
- 失败：发现具体问题（引用确切问题）
以结构化的 JSON 返回你的评估：
{
"verdict": "通过" | "失败",
"checks": [
{"criterion": "...", "result": "通过|失败", "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 要求满足（关键词密度、元标签、结构）
- 无竞品商标滥用
- 行动号召（CTA）存在且链接正确
代码：
- 类型安全（无
any泄漏，适当的 null 处理） - 错误处理覆盖
- 安全（代码中无密钥、输入验证、注入防护）
- 新路径的测试覆盖
合规敏感型（监管、法律、金融）：
- 无结果保证或无根据声明
- 存在必要的免责声明
- 仅使用批准的术语
- 适合司法管辖区的语言
阶段 3：乖还是不乖（判决门）
def santa_verdict(review_b, review_c):
"""两个审查者都必须通过。没有部分通过。"""
if review_b.verdict == "通过" and review_c.verdict == "通过":
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 | 圣诞老人方法的发现结果成为“直觉”。相同准则反复失败 → 学习到的行为以规避该模式。 |
| 战略压缩 | 在压缩之前运行圣诞老人方法。不要在验证过程中丢失审查上下文。 |
指标
追踪以下指标以衡量圣诞老人方法的效果：
- 首次通过率：第 1 轮即通过圣诞老人方法的输出百分比（目标：>70%）
- 收敛平均轮次：达到“乖”的平均轮数（目标：<1.5）
- 问题分类：失败类型的分布（幻觉 vs. 完整性 vs. 合规性）
- 审查者一致性：两个审查者共同标记 vs. 仅一个审查者标记的问题百分比（一致性低 = 评估准则需要收紧）
- 逃逸率：交付后发现但圣诞老人方法本应捕获的问题（目标：0）
成本分析
圣诞老人方法的成本大约是每轮验证仅生成成本的 2-3 倍。对于大多数高风险输出而言，这是划算的：
圣诞老人方法成本 = (生成代币数) + 2×(每轮审查代币数) × (平均轮数)
不采用圣诞老人方法的成本 = (声誉损害) + (修正工作量) + (信任侵蚀)
对于批量操作，采样模式将成本降至全量验证的约 15-20%，同时捕获 >90% 的系统性问题。