Santa Method 是一套多智能体对抗式验证框架，用一句话概括其原则：列个清单，检查两遍；若不合格，就改到合格为止。
用途
该框架解决的核心问题是：单个智能体评审自己的输出时，会共享产生该输出的同一套偏见、知识盲区和系统性错误。引入两个没有共享上下文的独立审查者，可以打破这种失效模式。
它的定位是“生成后验证层”，而非生成策略。也就是说，它不改变正常的生成工作流，只在输出交付前追加独立复核环节。
适用与不适用的场景
应当启用该技能的情况包括：输出将被发布、部署或由最终用户消费；必须执行合规、监管或品牌约束；代码在无人工审查的情况下直接上线生产环境；内容准确性重要（技术文档、教育材料、面向客户的文案）；大规模批量生成，抽查难以发现系统性模式；幻觉风险较高（声明、统计数据、API 引用、法律用语）。
不应使用的情况包括：内部草稿、探索性研究，以及具有确定性验证手段的任务——这类任务应使用构建、测试、lint 流水线处理。
架构与阶段
整个框架分为四个阶段。
第一阶段：列清单（生成）。执行主任务，正常产出交付物，不改变原有生成流程。
第二阶段：检查两遍（独立双重评审）。并行启动两个审查智能体，关键不变量包括：上下文隔离，任一审查者都看不到另一方的评估；评分标准相同，两者收到同一套评估标准；输入相同，两者都收到原始任务规格与生成输出；结构化输出，各自返回类型化裁决而非散文式描述。审查者提示词明确要求逐条对照评分标准给出 PASS（完全满足、无问题）或 FAIL（发现具体问题，需引用确切问题点），并以结构化 JSON 返回裁决、逐项检查、阻断性问题（critical_issues）与建议（suggestions）。提示词中特别强调“要严格，你的职责是找问题，而不是批准”。
关于评分标准设计，文中指出评分标准是最重要的输入，含糊的标准只会产生含糊的评审。每条标准都必须有客观的通过/失败条件。基础标准包括：事实准确性（所有声明可对照源材料或常识验证；失败信号为编造统计、错误版本号、不存在的 API）；无幻觉（不虚构实体、引语、URL 或参考；失败信号为指向不存在页面的链接、无来源的引语）；完整性（规格中每项要求都被覆盖；失败信号为缺失章节、跳过的边界情况）；合规性（通过所有项目特定约束；失败信号为使用禁词、语气违规、监管不合规）；内部一致性（输出内无矛盾）；技术正确性（代码可编译运行、算法合理；失败信号为语法错误、逻辑 bug、错误的复杂度声明）。文档还提供了针对内容/营销、代码、合规敏感场景的领域特定标准扩展，例如品牌语调一致性、SEO 要求、竞品商标误用、CTA 是否存在且链接正确；类型安全、错误处理覆盖、安全（代码中无密钥、输入校验、防注入）、新路径的测试覆盖；无结果保证或未经证实的声明、必需的免责声明、仅使用获批术语、符合司法辖区的表述。
第三阶段：合格还是不合格（裁决门）。两名审查者必须都通过，没有部分得分。只有当 review_b 与 review_c 的裁决都为 PASS 时才返回 NICE（可以发布）；否则合并两名审查者的标签并去重，返回 NAUGHTY 以及问题清单与建议。文中解释了“为何必须两者都通过”：如果只有一名审查者抓到问题，那这个问题就是真实存在的；另一名审查者的盲区，恰恰正是 Santa Method 想要消除的失效模式。
第四阶段：改到合格为止（收敛循环）。设定最大迭代次数 MAX_ITERATIONS = 3。循环中若裁决为 NICE，则记录结果并交付输出；否则由修复智能体执行修复，指令明确为“只修复被标记的问题，不要重构，也不要添加未被要求的改动”，只修复阻断性问题（建议为可选）。随后在修复后的输出上重新运行两名审查者，且每轮使用全新的智能体，不带上一轮记忆——因为先前的上下文会造成锚定偏见。若迭代次数耗尽，则记录为 escalated 并升级给人工。
实现模式
模式 A：Claude Code 子智能体（推荐）。子智能体提供真正的上下文隔离，每个审查者都是独立进程、无共享状态；两个智能体并行运行以提升速度。
模式 B：顺序内联（回退方案）。在没有子智能体时，通过显式上下文重置模拟隔离：生成输出；新建上下文“你是审查者 1，仅按此评分标准评估，找出问题”；逐字记录发现；完全清除上下文；新建上下文“你是审查者 2，仅按此评分标准评估，找出问题”；对比两份评审，修复，重复。文档指出子智能体模式严格更优，因为内联模拟存在审查者之间上下文串扰的风险。
模式 C：批量抽样。对 100 件以上的大型批次，对每一项都执行完整 Santa 成本过高，因此采用分层抽样：对随机样本（批次的 10-15%，最少 5 项）运行 Santa；按类型归类失败（幻觉、合规、完整性等）；若出现系统性模式，则对整个批次应用针对性修复；重新抽样并重新验证修复后的批次；持续直到干净样本通过。文档给出了对应的函数示意，其中 sample_rate 默认 0.15，若发现不合格则对匹配模式的所有条目批量修复并递归重新抽样，样本干净后交付整批。
失败模式与缓解
文档列出若干失败模式：无限循环（修复后审查者仍不断发现新问题）——用最大迭代上限 3 并升级处理；橡皮图章（两名审查者一律通过）——通过对抗性提示“你的职责是找问题，而不是批准”缓解；主观漂移（审查者标记的是风格偏好而非错误）——用仅含客观通过/失败条件的严格评分标准约束；修复回归（修问题 A 引入问题 B）——每轮使用全新审查者以捕捉回归；审查者一致偏见（两名审查者漏掉同一处问题）——通过独立性缓解但无法彻底消除，对关键输出可增加第三名审查者或人工抽查；成本爆炸——采用批量抽样模式并为每次验证周期设定预算上限。
与其他技能的集成
Verification Loop 用于确定性检查（构建、lint、测试），Santa 用于语义检查（准确性、幻觉）；先运行 verification-loop，再运行 Santa。Eval Harness 可接收 Santa Method 的结果作为评估指标，通过跟踪多次 Santa 运行的 pass@k 衡量生成器质量随时间的变化。Continuous Learning v2 将 Santa 的发现转化为直觉：同一标准反复失败会形成避开该模式的学习行为。Strategic Compact 场景下应在压缩前运行 Santa，避免在验证中途丢失评审上下文。
指标与成本
建议跟踪的指标包括：首次通过率（第一轮即通过 Santa 的输出占比，目标 >70%）、收敛平均迭代次数（达到 NICE 的平均轮数，目标 <1.5）、问题分类分布（幻觉、完整性、合规等失败类型的占比）、审查者一致性（两名审查者都标记的问题占比，一致性低意味着评分标准需要收紧）、逃逸率（发布后才发现、本应由 Santa 捕获的问题，目标为 0）。
成本方面，每个验证周期的 token 成本约为仅生成成本的 2-3 倍。文档给出的成本公式为：Santa 的成本 = 生成 token + 2 ×（每轮评审 token）×（平均轮数）；而不做 Santa 的成本 = 声誉损害 + 纠正成本 + 信任侵蚀。对批量操作，抽样模式可将成本降低至完整验证的约 15-20%，同时仍能捕获超过 90% 的系统性问题。
限制
该框架依赖评分标准的质量，含糊标准会削弱评审有效性；审查者之间的共同盲区只能缓解、不能消除；每轮验证会带来额外 token 成本；并且它不适用于存在确定性验证手段的任务。