Santa Method 是一个多智能体对抗式验证框架，核心思路是：单个智能体审查自己的输出会共享产生该输出的偏见、知识盲区和系统性错误，因此改用两个无共享上下文的独立审查者来打破这一失效模式。
用途：适用于输出将被发布、部署或由最终用户消费的场景，包括合规/监管/品牌约束、无人工审查直接上生产的代码、内容准确性要求高的技术文档与客户文案、大规模批量生成、以及幻觉风险较高的声明、统计、API 引用和法律语言。不适用于内部草稿、探索性研究或可用构建/测试/lint 等确定性验证的任务。
主要能力与流程：分为四个阶段。阶段一生成（Make a List），按正常流程产出交付物，Santa Method 是生成后的验证层而非生成策略。阶段二双重独立审查（Check It Twice），并行启动两个审查智能体，关键不变量为上下文隔离、相同评分标准、相同输入（原始规格与生成输出）、结构化输出（返回类型化判定而非散文）。阶段三判定门（Naughty or Nice），两个审查者必须同时 PASS 才判定为 NICE 并发布，否则为 NAUGHTY，合并去重双方标记的问题。阶段四修复循环（Fix Until Nice），修复所有关键问题后由全新智能体重新运行两名审查者，最多迭代 3 次，超出则升级给人工。
评分标准设计：每条标准需有客观的通过/失败条件，涵盖事实准确性、无幻觉、完整性、合规性、内部一致性、技术正确性，并可按内容营销、代码、合规敏感领域扩展。
实现模式：推荐使用 Claude Code 子智能体实现真正的上下文隔离；子智能体不可用时可用顺序内联方式模拟隔离；大批量（100+ 项）可用分层抽样模式降低成本。
限制与失败模式：存在无限循环、橡皮图章、主观漂移、修复回归、审查者一致偏见、成本膨胀等风险，分别通过迭代上限、对抗性提示、严格评分标准、每轮全新审查者、抽样与预算上限缓解。审查者一致偏见只能缓解不能消除，关键输出建议增加第三名审查者或人工抽查。成本约为单独生成的 2-3 倍 token。具体安装命令与代码实现细节暂未提供。