ECC 的 Santa Loop 对抗性双审收敛循环：双模型独立审查与 NICE 门控的代码发布实战指南

ECC 的 Santa Loop 对抗性双审收敛循环双模型独立审查与 NICE 门控的代码发布实战指南【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC/santa-loop是 ECCAgent Harness Performance Optimization System提供的一个 review 类型命令它基于santa-method技能实现对抗性双审收敛循环在代码推送push之前由两个互不共享上下文的独立模型评审者Claude Opus 外部模型分别对改动进行审查只有两者都返回 PASS映射为 NICE才允许发布。本文以 docs/ja-JP/commands/santa-loop.md与 commands/santa-loop.md 英文原版内容一致为核心骨架结合 skills/santa-method/SKILL.md 的方法论细节与 agents/code-reviewer.md 的评审代理实现完整讲解命令的用法、7 步工作流、评判规则Rubric、双评审者架构、最大 3 轮的修复收敛机制以及 NICE/NAUGHTY 裁决与最终报告格式帮助你为未经人工复核就要出荷的代码变更建立一道可落地的对抗性质量闸门。一、为什么需要双审Santa Method 的核心洞察santa-loop命令的元描述为Adversarial dual-review convergence loop — two independent model reviewers must both approve before code ships对抗性双审收敛循环——两个独立模型评审者均需批准后方可发布代码在 docs/COMMAND-REGISTRY.json 中被登记为type: review类型的命令并在 COMMANDS-QUICK-REF.md 中作为快速引用入口列出。其底层方法论来自santa-method技能该技能在 skills/santa-method/SKILL.md 中开宗明义地指出核心洞察单一 Agent 审查自己的输出时会共享产生该输出时的同一种偏差bias、知识空白knowledge gap与系统性错误。而两个不共享上下文的独立评审者可以打破这种失效模式。santa-method 的架构可以概括为四个阶段详见 skills/santa-method/SKILL.md 的 Architecture 一节Make a List生成生成者Generator正常产出交付物Santa Method 是生成后的验证层而非生成策略本身Check It Twice双独立审查并行拉起两个评审 Agent使用相同 rubric、相同输入但彼此看不到对方的评审结论Naughty or Nice裁决门只有两个评审者都 PASS 才判定 NICE否则为 NAUGHTYno exceptions无例外Fix Until Nice收敛循环汇总双方标记的问题、修复、再以全新评审者重跑直到收敛或触发最大迭代上限。santa-loop命令正是把这个方法论落地为一条可直接调用的/santa-loop命令并把双评审者具体化为Claude Opus始终运行 外部模型Codex / Gemini CLI的组合。二、命令用法/santa-loop [file-or-glob | description]santa-loop的调用方式为/santa-loop [file-or-glob | description]其中可选参数$ARGUMENTS可以是文件路径、glob 通配模式或者一段自然语言描述不传参数时命令会自动回退到未提交的改动作为审查范围。该命令同时被注册进agent.yaml在 agent.yaml 中列为可用命令之一并且santa-method技能本身也在 agent.yaml 中被声明为随附技能package.jsonpackage.json则将该技能目录列入安装清单说明它随 ECC 安装包一起分发。三、Step 1确定审查范围Identify What to Review命令首先根据$ARGUMENTS判定本次审查的范围scope如果参数指定了路径、文件或描述则直接以该参数作为范围否则回退到当前工作区未提交的改动git diff --name-only HEAD随后读取所有变更文件的内容构建完整的评审上下文review context。也就是说评审者拿到的不只是一份 diff 摘要而是变更文件的完整内容以便能结合上下文判断问题。四、Step 2构建评判规则RubricRubric评判规则是整个流程中最关键的输入。命令要求针对被审查的文件类型构建合适的 rubric且每个标准都必须有客观的 PASS/FAIL 判定条件。最低限度必须包含以下六个维度标准合格条件正确性Correctness逻辑正确、无 bug、处理了边界情况安全性Security无密钥泄露、注入、XSS 或 OWASP Top 10 问题错误处理Error handling错误被显式处理无静默吞掉完整性Completeness所有需求都被覆盖无遗漏场景内部一致性Internal consistency文件之间或段落之间无自相矛盾无回归No regressions改动不破坏既有行为在此基础上还应根据文件类型追加领域专属标准例如TypeScript类型安全type safety无any泄漏、空值处理正确Rust内存安全memory safetySQL迁移安全migration safety。santa-method技能在 skills/santa-method/SKILL.md 的 Rubric Design 一节给出了更细的对照包括事实准确性所有论断可核验、无幻觉不得编造实体、引用、URL、完整性、合规性、内部一致性、技术正确性以及按内容/营销、代码、合规敏感领域的扩展建议。技能原文强调Vague rubrics produce vague reviews——含糊的 rubric 只能得到含糊的评审。关于什么不该标记仓库里的评审代理实现提供了更强的证据agents/code-reviewer.md 明确要求评审者遵循置信度过滤Confidence-Based Filtering只有 80% 确信的问题才上报并且列出了一系列常见误报模式False Positives应当跳过例如调用方或框架已处理的错误路径上的 consider adding error handling、对测试夹具中的硬编码值标记 Hardcoded value、对非加密场景的Math.random()做security theater式标记等。同时code-reviewer要求 HIGH/CRITICAL 级别的问题必须给出精确行号、具体失败场景输入、状态、后果以及为什么现有防护未能拦截——这正是客观 PASS/FAIL 条件在实现层的落地方式。五、Step 3双独立审查Dual Independent Review流程要求使用 Agent 工具并行启动两个评审者两个评审者在同一条消息中发起以获得并发执行并且必须等两者都完成后才进入裁决门。每个评审者都针对 rubric 的每一条标准给出 PASS 或 FAIL然后返回结构化 JSON 判定{ verdict: PASS | FAIL, checks: [ {criterion: ..., result: PASS|FAIL, detail: ...} ], critical_issues: [...], suggestions: [...] }santa-method技能将这种结构化输出而非散文列为评审阶段的关键不变量之一并要求评审者提示词中显式写入You are an independent quality reviewer. You have NOT seen any other review of this output.你是一名独立的质量评审者你没有看过任何其他评审。5.1 评审者 AClaude Agent始终运行评审者 A 是常驻评审者无论工具环境如何都必须运行。它使用subagent_type: code-reviewer、model: opus的 Agent其提示词必须包含完整的 rubric被审查的所有文件内容独立评审者身份声明You are an independent quality reviewer. You have NOT seen any other review. Your job is to find problems, not to approve.你的工作是发现问题而不是批准要求返回上述结构化 JSON 判定。这里与仓库中的 agents/code-reviewer.md 形成呼应该 Agent 本身被设计为专家级代码评审专员其默认模型为 sonnet但santa-loop要求以opus运行以使用可用模型中最强的一档该 Agent 的 Review Process 第一步就是Gather context——运行git diff --staged和git diff若无 diff 则用git log --oneline -5查看最近提交与 santa-loop 的读取全部变更文件构建完整上下文要求一致。5.2 评审者 B外部模型无外部 CLI 时才回退 Claude评审者 B 的目标是模型多样性model diversity。命令首先检测本机可用的 CLIcommand -v codex /dev/null 21 echo codex || true command -v gemini /dev/null 21 echo gemini || true然后将与评审者 A 完全一致的 rubric 与指令写入唯一的临时文件PROMPT_FILE$(mktemp /tmp/santa-reviewer-b-XXXXXX.txt) cat $PROMPT_FILE EOF ... full rubric file contents reviewer instructions ... EOF随后按优先级使用第一个可用的 CLICodex CLI若已安装——注意这里使用了--sandbox read-only以保证审查过程中不会改动仓库codex exec --sandbox read-only -m gpt-5.4 -C $(pwd) - $PROMPT_FILE rm -f $PROMPT_FILEGemini CLI若已安装且无 codexgemini -p $(cat $PROMPT_FILE) -m gemini-2.5-pro rm -f $PROMPT_FILEClaude Agent 回退仅当codex和gemini都未安装时启动第二个 Claude Agentsubagent_type: code-reviewer、model: opus并记录一条警告两个评审者共享同一模型家族真正的模型多样性未达成但上下文隔离仍然生效。无论走哪条路径评审者 B 都必须返回与评审者 A 相同的结构化 JSON 判定。santa-method技能还补充了另一种无 subagent 场景下的降级实现Pattern B: Sequential Inline显式重置上下文、先让 Reviewer 1 记录结论、完全清空上下文后再让 Reviewer 2 评审。技能明确指出 subagent 模式严格优于 inline 模拟因为 inline 存在评审者之间上下文渗漏context bleed的风险santa-loop命令通过两个评审者并行、互不可见规避了这一风险。六、Step 4裁决门Verdict Gate裁决逻辑非常简单且严格两个评审者都 PASS → NICE直接进入 Step 6推送任一评审者 FAIL → NAUGHTY合并两个评审者的全部 critical issues、去重deduplicate后进入 Step 5。santa-method技能给出了对应的裁决函数语义并解释了为什么必须两者都通过如果只有一个评审者发现了某个问题这个问题就是真实存在的。另一个评审者的盲区blind spot恰恰是 Santa Method 要消除的失效模式。因此不存在部分通过no partial credit的概念。七、Step 5修复循环NAUGHTY 路径一旦裁决为 NAUGHTY进入收敛修复循环展示来自两个评审者的全部 critical issues只修复被标记的问题——严禁顺手重构no drive-by refactors避免引入非必要的改动面将所有修复合并为单个提交提交信息遵循约定格式fix: address santa-loop review findings (round N)以全新的评审者对上一轮结论没有任何记忆重新执行 Step 3重复直到两者都返回 PASS。循环存在硬性上限最大 3 次迭代。若 3 轮后仍为 NAUGHTY则停止并展示剩余问题SANTA LOOP ESCALATION (exceeded 3 iterations) 3ラウンド後の残存問題 - [両方のレビュアーからの未解決のクリティカルな問題をすべてリスト] 続行する前に手動レビューが必要です。并且不得推送Do NOT push需要人工介入审查。santa-method技能将每轮使用全新评审者列为关键点评审者不能携带上一轮的记忆因为先前结论会形成锚定偏差anchoring bias——评审者可能会倾向性地认可上一轮修复后的代码。此外技能强调修复指令必须限定为Fix ONLY the flagged issues. Do not refactor or add unrequested changes.与命令的只改被标记的问题完全一致。八、Step 6 与 Step 7推送与最终报告NICE 路径当两个评审者都返回 PASS 时执行推送git push -u origin HEAD推送后或升级后输出最终报告SANTA VERDICT: [NICE / NAUGHTY (escalated)] Reviewer A (Claude Opus): [PASS/FAIL] Reviewer B ([model used]): [PASS/FAIL] Agreement: Both flagged: [両方が検出した問題] Reviewer A only: [Aのみが検出した問題] Reviewer B only: [Bのみが検出した問題] Iterations: [N]/3 Result: [PUSHED / ESCALATED TO USER]这份报告的价值在于评审者一致性Agreement可视化如果某个问题被两个评审者同时标记说明它是高置信度的真实问题如果只有单侧标记则可能反映模型多样性带来的互补发现详见下文度量一节。九、注意事项与最佳实践原文档的 Notes 一节沉淀了该流程的若干关键约束值得逐条展开评审者 AClaude Opus始终运行无论目标机器上是否安装了 codex / gemini都至少保证有一名强评审者在场评审者 B 的目标是模型多样性GPT-5.4 或 Gemini 2.5 Pro 能提供真正的独立性——不同的训练数据、不同的偏差、不同的盲区。纯 Claude 回退虽然通过上下文隔离仍保留了价值但会失去模型多样性使用可用的最强模型评审者 A 用 Opus评审者 B 用 GPT-5.4 或 Gemini 2.5 Pro外部评审者以--sandbox read-only运行Codex防止审查过程中评审者意外改动仓库repo mutation每轮使用全新评审者防止先前发现导致锚定偏差Rubric 是最重要的输入若评审者出现橡皮图章式放行rubber-stamp或对主观风格问题滥标flag subjective style issues应收紧 rubricNAUGHTY 轮也会提交因为每轮修复都会产生一个fix:提交即使循环中途被中断修复成果也不会丢失推送只发生在 NICE 之后循环过程中绝不推送。santa-method技能在失败模式表中给出了对应的缓解清单可作为排障手册无限循环评审者不断发现新问题→ 以 3 轮上限截断并升级橡皮图章 → 对抗性提示词 Your job is to find problems, not approve.主观漂移 → 只保留客观 PASS/FAIL 的紧凑 rubric修复引入回归 → 每轮全新评审者捕获双评审者同盲 → 独立性只能缓解无法消除关键输出可增加第三评审者或人工抽检成本爆炸 → 批次采样与预算上限。十、度量与成本如何判断 Santa Loop 是否有效skills/santa-method/SKILL.md 建议持续跟踪以下指标来衡量双审机制的效果首轮通过率First-pass rate第 1 轮即通过的比例目标 70%收敛平均迭代次数Mean iterations to convergence达到 NICE 的平均轮数目标 1.5问题分类学Issue taxonomy失败类型的分布幻觉 vs. 完整性 vs. 合规性评审者一致性Reviewer agreement双方共同标记 vs. 单侧标记的比例——一致性过低往往意味着 rubric 需要收紧逃逸率Escape rate发布后被 Santa 本应捕获的问题比例目标 0。成本模型上Santa Method 每次验证周期约为生成成本的 2~3 倍 token 开销Cost of Santa (generation tokens) 2×(review tokens per round) × (avg rounds) Cost of NOT Santa (reputation damage) (correction effort) (trust erosion)对于大批量场景技能提供了**分层抽样Pattern C: Batch Sampling**降本方案随机抽取 10~15%至少 5 项跑完整双审按失败类型归类若出现系统性模式则对整批执行定向修复后重新抽样验证可将成本降至全量验证的约 15~20%同时捕获超过 90% 的系统性问题。十一、在 ECC 工作流中的定位与衔接santa-loop属于 ECC 命令体系中的review 类型命令见 docs/COMMAND-REGISTRY.json与同为评审类的code-review、review-pr等命令并存但侧重点不同它是面向出荷前最后一道对抗性闸门的收敛循环而非一次性评审。它依赖 agents/code-reviewer.md 作为评审者 A 的 Agent 实现并在 agent.yaml 中与santa-method技能一起随 ECC 分发package.json。skills/santa-method/SKILL.md还给出了与其他技能的衔接建议先跑 Verification Loop 的确定性检查构建、lint、测试再跑 Santa 做语义检查准确性、幻觉Santa 的发现可以反哺 Continuous Learning v2 沉淀为 instincts在 Strategic Compact 之前先完成 Santa避免验证中途丢失评审上下文。综上/santa-loop提供了一条开箱即用的代码发布前双模型独立把关路径以客观 rubric 为准绳、以双评审者并行独立评审为机制、以 3 轮修复收敛为兜底、以 NICE 门控推送为铁律。对于需要无人值守发布、或对代码质量与安全有硬性要求的团队这是一套可以直接在 ECC 环境中落地执行的对抗性质量保障方案。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考