2.4 验证器设计：为什么验证是瓶颈 — Loop Engineering 的核心组件

本节导读：深入理解验证器（Verifier）在循环中的核心地位，掌握从弱验证到强验证的设计方法，学会构建可靠的验证系统来保证循环产出质量。

学习目标

• 理解"验证器是瓶颈"这一核心洞察的技术根源
• 掌握四个等级验证器的设计与实现
• 学会为不同类型任务选择和组合验证策略
• 理解验证器的成本与收益权衡

核心概念

为什么验证器是瓶颈？

AI Builder Club 的核心观点："In any loop, the verifier is the bottleneck, not the model."（在任何一个循环中，验证器是瓶颈，不是模型。）

这个洞察背后的技术逻辑：

1. 模型已经够好了：到 2026 年中，主流 LLM 已经能可靠地编写、分析和修改代码。瓶颈不再是"AI 能不能做"，而是"你怎么知道 AI 做得对不对"。

2. 自评的系统性偏差：让编写代码的同一个模型评判自己的输出，会产生系统性乐观偏差。研究表明，AI 对自己产出的评分远高于独立评估者的评分。

3. 验证决定了循环的可靠性：一个差验证器 + 好模型 = 循环要么永远不停（验证太松），要么过早停止（验证太严）。一个好验证器 + 中等模型 = 循环虽然慢但能可靠收敛。

4. 验证的成本远低于执行的成本：花 10% 的精力设计验证器，可以避免 50% 的无效执行。验证器设计是最值得投入的工程环节。

验证器的四个等级

Level 1：模型自评
让完成工作的模型自己评判。简单但不可靠——模型"对自己太宽容"。

Level 2：确定性工具检查（推荐起点）
测试套件、lint、类型检查器、编译器。确定性的——结果只有通过或失败。这是大多数循环的基线。

Level 3：独立子代理评审
启动一个独立的 Agent，用不同的系统指令评审。Claude Code 的 /goal 底层机制就是如此。

Level 4：多重验证组合
Level 2 + Level 3 + Level 1 的加权组合。最可靠，成本也最高。

环境准备 / 前置知识

• 已完成 2.1-2.3 节学习
• 有编写测试用例的经验
• 了解基本的 CI/CD 流程

分步实战

步骤 1：构建多级验证器

"""
multi_level_verifier.py - 多级验证器实现
展示从 Level 1 到 Level 4 的验证器设计
"""
from dataclasses import dataclass
from typing import List, Optional
from enum import Enum

class Verdict(Enum):
    PASS = "pass"
    FAIL = "fail"
    UNDETERMINED = "undetermined"

@dataclass
class VerifyResult:
    level: int
    verdict: Verdict
    score: float  # 0.0 ~ 1.0
    details: str
    evidence: List[str]

class VerifierChain:
    """多重验证器链：按级别执行，综合判断"""

    def __init__(self):
        self.verifiers = []

    def add(self, level: int, verifier_func, weight: float = 1.0):
        self.verifiers.append({
            "level": level,
            "func": verifier_func,
            "weight": weight
        })
        return self  # 支持链式调用

    def verify(self, context) -> VerifyResult:
        results = []
        for v in sorted(self.verifiers, key=lambda x: x["level"]):
            result = v["func"](context)
            results.append(result)

        # 加权综合评分
        weighted_score = sum(
            r.score * v["weight"]
            for r, v in zip(results, self.verifiers)
        )
        total_weight = sum(v["weight"] for v in self.verifiers)
        final_score = weighted_score / total_weight

        # 判断规则：所有 Level 2+ 验证器必须通过
        mandatory_pass = all(
            r.verdict == Verdict.PASS
            for r, v in zip(results, self.verifiers)
            if v["level"] >= 2
        )

        if mandatory_pass and final_score >= 0.8:
            verdict = Verdict.PASS
        elif final_score >= 0.5:
            verdict = Verdict.UNDETERMINED
        else:
            verdict = Verdict.FAIL

        return VerifyResult(
            level=max(v["level"] for v in self.verifiers),
            verdict=verdict,
            score=final_score,
            details=f"综合评分: {final_score:.1%}",
            evidence=[r.details for r in results]
        )


# ===== Level 1: 模型自评 =====
def llm_self_review(context):
    """Level 1: 让模型评审自己的工作（最弱但有基本价值）"""
    # 实际中调用 LLM API
    # 示例：让模型检查自己写的代码是否有明显问题
    code = context.get("code", "")
    issues = []

    if "TODO" in code:
        issues.append("发现 TODO 注释，可能未完成")
    if "pass" in code and "except" in code:
        issues.append("发现裸 except 子句")

    score = 0.7 if len(issues) <= 1 else 0.4
    return VerifyResult(
        level=1,
        verdict=Verdict.PASS if score > 0.5 else Verdict.FAIL,
        score=score,
        details=f"自评发现 {len(issues)} 个潜在问题",
        evidence=issues
    )


# ===== Level 2: 确定性工具检查 =====
def test_runner(context):
    """Level 2: 运行测试套件（确定性，推荐起点）"""
    import subprocess
    result = subprocess.run(
        ["npm", "test", "--", "--json"],
        capture_output=True, text=True
    )
    passed = result.returncode == 0
    return VerifyResult(
        level=2,
        verdict=Verdict.PASS if passed else Verdict.FAIL,
        score=1.0 if passed else 0.0,
        details=f"测试{'全部通过' if passed else '存在失败'}",
        evidence=[]
    )

def type_checker(context):
    """Level 2: 类型检查"""
    import subprocess
    result = subprocess.run(
        ["npx", "tsc", "--noEmit"],
        capture_output=True, text=True
    )
    passed = result.returncode == 0
    return VerifyResult(
        level=2,
        verdict=Verdict.PASS if passed else Verdict.FAIL,
        score=1.0 if passed else 0.0,
        details=f"类型检查{'通过' if passed else '存在错误'}",
        evidence=[]
    )


# ===== Level 3: 独立子代理评审 =====
def independent_reviewer(context):
    """Level 3: 独立 Agent 评审"""
    # 实际中启动一个独立 Agent 实例
    # 使用不同的系统指令来评审
    code = context.get("code", "")
    goal = context.get("goal", "")

    # 简化版：检查代码是否确实解决了目标问题
    relevant = goal.split()[:3]  # 取目标关键词
    mentions = sum(1 for kw in relevant if kw.lower() in code.lower())

    score = min(mentions / max(len(relevant), 1), 1.0)

    return VerifyResult(
        level=3,
        verdict=Verdict.PASS if score >= 0.8 else Verdict.UNDETERMINED,
        score=score,
        details=f"独立评审: 相关度 {score:.0%}",
        evidence=[]
    )


# ===== 组合使用 =====
chain = (
    VerifierChain()
    .add(1, llm_self_review, weight=0.5)
    .add(2, test_runner, weight=2.0)
    .add(2, type_checker, weight=1.5)
    .add(3, independent_reviewer, weight=1.0)
)

result = chain.verify({"code": "...", "goal": "修复登录 Bug"})
​

步骤 2：为不同任务设计验证策略

# 任务类型 → 推荐验证策略
verification_strategies = {
    "Bug 修复": {
        "mandatory": ["测试套件", "类型检查"],
        "recommended": ["Lint 检查", "回归测试"],
        "verdict_rule": "所有 mandatory 通过 + 回归测试无新增失败"
    },
    "功能开发": {
        "mandatory": ["测试套件", "类型检查"],
        "recommended": ["代码审查", "集成测试"],
        "verdict_rule": "所有 mandatory 通过 + 覆盖率 > 阈值"
    },
    "重构": {
        "mandatory": ["全量测试", "性能基准"],
        "recommended": ["代码复杂度检查"],
        "verdict_rule": "所有测试通过 + 性能不退化 + 复杂度不增加"
    },
    "文档": {
        "mandatory": ["构建检查"],
        "recommended": ["链接检查", "拼写检查"],
        "verdict_rule": "文档构建成功 + 无断链"
    }
}
​

步骤 3：处理验证器的边缘情况

class RobustVerifier:
    """健壮的验证器：处理边缘情况"""

    def verify(self, context):
        # 1. 验证器本身出错了
        try:
            result = self.run_tests()
        except Exception as e:
            return VerifyResult(
                level=2,
                verdict=Verdict.UNDETERMINED,
                score=0.0,
                details=f"验证器异常: {e}",
                evidence=[]
            )

        # 2. 测试 hung（超时）
        if result.timed_out:
            return VerifyResult(
                level=2,
                verdict=Verdict.FAIL,
                score=0.0,
                details="测试超时，可能引入死循环",
                evidence=[]
            )

        # 3. 测试 flakes（不稳定）
        if self.is_flaky(result):
            return VerifyResult(
                level=2,
                verdict=Verdict.UNDETERMINED,
                score=0.5,
                details="测试结果不稳定，建议重试",
                evidence=[]
            )

        return result
​

常见问题 FAQ

Q1：测试覆盖率作为验证标准好不好？

A：覆盖率是辅助指标，不是验证标准本身。100% 覆盖率不意味着代码正确——测试可能覆盖了代码但没有覆盖正确的行为。正确的做法是：测试通过率作为主验证标准，覆盖率作为辅助参考。

Q2：验证器本身有 Bug 怎么办？

A：验证器需要自己的测试。测试你的验证器是否正确判断了成功和失败。关键场景：(1) 全部通过的代码是否被正确判定为 PASS；(2) 有明确失败的代码是否被判定为 FAIL；(3) 验证器超时或崩溃时是否有合理的降级处理。

Q3：主观性验证（如代码质量）怎么处理？

A：尽量转化为可量化的标准。与其验证"代码质量好"，不如验证"代码复杂度 < 10"、"函数长度 < 50 行"、"无重复代码块 > 5 行"。如果必须包含主观判断，使用 Level 3 独立子代理评审，并将其权重设为较低值。

最佳实践与避坑

• 验证器 > 模型：设计验证器比选择更好的模型更有效
• 确定性优先：能用工具检查的就不要让模型判断
• Maker-Checker 分离：编写和验证必须由不同组件负责
• 验证器要测试：验证器本身的质量决定循环的质量
• 多重验证：组合多种验证比单一验证更可靠

本节小结

本节深入分析了验证器在循环工程中的核心地位。我们学习了四个等级的验证器设计，从最简单的模型自评到最可靠的多重验证组合。关键收获：到 2026 年，模型已经足够好了——循环工程的核心挑战不是"让 AI 做事"，而是"判断 AI 做得对不对"。

下一节我们将探讨停止条件与断路器机制——循环安全运行的最后一道防线。

延伸阅读

• AI Builder Club: Loop Engineering Guide
• Anthropic: Building Effective Agents
• 相关章节：2.5 停止条件与断路器机制

关键词：Loop Engineering, 验证器设计, Verifier, Maker-Checker, 多级验证, 确定性验证, 独立评审, 循环瓶颈, 教程, 架构

难度：进阶

预计阅读：15 分钟