验证器经济学：为什么评判比生成更有价值

TL;DR

在 AI 时代，验证比生成更容易规模化。程序员的竞争力正在从”写出好代码”转向”定义什么叫好代码”。

2021年 OpenAI 的验证器研究揭示了一个反直觉的真相：让模型生成多个答案然后用验证器筛选，比直接训练模型生成正确答案更有效——准确率从 50% 提升到 70%，且扩展性更好。Harness 工程将这个发现系统化：当 Agent 可以生成百万行代码时，限制因素不再是”谁能写得更快”，而是”谁能判断哪些是对的”。

📋 本文结构

1. 一个数学发现引发的革命 —— GSM8K 实验的惊人结果
2. P vs NP 的工程直觉 —— 验证为什么比求解更容易
3. Harness 工程中的验证器实践 —— OpenAI 与 Carlini 的双重验证
4. 验证器设计原则 —— 为 Agent 设计而非为自己设计
5. 从生成到筛选的范式转移 —— 新的工程工作流
6. 程序员职业能力的重新定义 —— 评判力 > 实现力
7. 今日毒舌 —— 关于验证的残酷真相
8. 结语 —— 验证器经济学的终极含义

一个数学发现引发的革命

2021年，OpenAI 研究员 Karl Cobbe 等人发表了一篇看似平淡的论文：《Training Verifiers to Solve Math Word Problems》。

但他们的发现一点都不平淡。

在 GSM8K（8500 道小学数学应用题）上的对比实验：

这 20 个百分点的差距，不只是技术优化。它触及了一个更深层的问题：

在 AI 时代，什么能力最稀缺？

P vs NP 的工程直觉

计算复杂性理论中有一个著名的未解决问题：P vs NP。

• P：可以在多项式时间内求解的问题
• NP：可以在多项式时间内验证解的问题

核心问题：求解和验证是否一样难？

一个直观的例子

解一个复杂的数独谜题可能需要数小时。但验证一个完成的数独是否正确？只需要几分钟，检查每行、每列、每宫格即可。

Cobbe 等人的发现，把这个直觉实证化了：

在语言模型的场景下，训练一个验证器来评判答案，比训练模型直接生成正确答案更有效率、更容易规模化。

这不是巧合。这是某种深层规律的体现。

Harness 工程中的验证器实践

OpenAI 和 Anthropic 的两个独立实验，完美印证了验证器经济学。

实验一：OpenAI 的 Harness 工程

背景：5 个月，100 万行代码，0 手写。

关键洞察：

“瓶颈很快从代码生成转移到了人类 QA 容量。”

问题诊断：随着代码吞吐量增加，人类来不及审查所有代码。

解决方案：让更多系统组件对 Agent 可读：

应用 UI    ──Chrome DevTools Protocol──→ Agent 可浏览
日志       ───────LogQL 查询───────→ Agent 可分析
指标       ───────PromQL 查询──────→ Agent 可验证

每个 git worktree 有独立的可启动实例，Agent 可以：

• 自主复现 Bug
• 验证修复
• 推理 UI 行为

结果：验证不再是人类的专属职责，而成为 Agent 工作流的一部分。

实验二：Carlini 的 C 编译器项目

背景：16 个并行 Claude Agent，从零写 Rust C 编译器，目标：编译 Linux 内核。

结果：

• 2000 次 Claude Code 会话
• $20,000 API 成本
• 10 万行代码
• 成功编译 Linux 6.9（x86/ARM/RISC-V）

但 Carlini 反复强调的关键点：

“我大部分精力都花在了为 Claude 设计周围的环境——测试、环境、反馈机制。”

“测试验证器必须近乎完美，否则 Claude 会解决错误的问题。”

典型问题与解决方案：

验证器设计原则

基于这些经验，我们可以总结 Harness 工程中验证器的设计原则：

原则 1：为 Agent 设计，而非为自己设计

Carlini 的关键洞察：

“我必须不断提醒自己，我是在为 Claude 写测试，而不是为自己。”

人类可容忍的，Agent 可能无法容忍：

# ❌ 人类可读，Agent 灾难
print("""
Test Results:
=============
Module A: ............................................ PASS
Module B: ............................................ PASS
Module C: ............................................ FAIL
... (5000 lines of logs)
""")

# ✅ Agent 友好
print("SUMMARY: 2 pass, 1 fail")
print("FAIL: module_c")
print("ERROR: NullPointerException at line 42")

设计要点：

• 最多只打印几行输出
• 错误格式标准化：ERROR: 原因，方便 grep
• 预计算统计摘要，不让 Agent 重新计算
• 日志文件易于自动处理

原则 2：验证器的验证器

验证器本身也需要被验证：

代码 → [Agent 生成] → 候选方案
          ↓
    [验证器筛选] → 通过/失败
          ↓
    [元验证器] → 验证器是否有效

Carlini 的方法：

• 观察 Claude 犯的错误模式
• 设计针对性的新测试
• 持续迭代测试套件

这是一个元级别的反馈回路。

原则 3：从生成到筛选

不要试图让 Agent 一次性生成正确答案。相反：

# 旧范式：直接生成正确答案
answer = agent.generate(problem)  # 50% 成功率

# 新范式：生成多个，验证器筛选
candidates = [agent.generate(problem) for _ in range(100)]
answer = verifier.select_best(candidates)  # 70% 成功率

这正是 Cobbe 论文中的方法：生成 100 个答案，验证器选出最好的。

从生成到筛选的范式转移

这个转变影响整个工程工作流：

传统工作流

需求 → 人类设计 → 人类实现 → 人类测试 → 部署

Harness 工作流

需求 → 人类定义验证器 → Agent 生成候选 → 验证器筛选 → 人类审查 → 部署
          ↑_________________________________|
                    (反馈回路)

关键变化：

• 人类从”实现者”变成”验证器设计者”
• Agent 承担生成工作
• 验证器成为质量控制的核心

程序员职业能力的重新定义

验证器经济学对我们意味着什么？

技能重心的转移

评判能力 > 实现能力

OpenAI 的实验表明：当 Agent 可以生成 100 万行代码时，限制因素不再是”谁能写得更快”，而是”谁能判断哪些代码是对的”。

人类的角色：

• 设计验证器
• 定义”正确”的标准
• 识别输出哪里不对
• 判断方向是否正确

这不是降格，而是升级——从执行层到决策层。

今日毒舌

验证器经济学揭示了一个尴尬的真相：

大多数程序员其实不擅长评判代码——他们只擅长写代码。

想想 Code Review 的场景：多少人能一眼看出架构问题，而不是纠结于缩进和命名？多少人能在 5 分钟内判断一个设计方案的好坏，而不是看完 50 个文件后说”LGTM”？

验证器经济学残酷地指出：如果你不能清晰地定义”好”，你就无法驾驭 Agent。

而那些只会写代码、从不思考”为什么这样写”的程序员——恭喜，你们正在被自己训练出来的 Agent 取代。

不是 Agent 太聪明，是你们太懒。

结语

Cobbe 等人的论文标题很谦虚：《Training Verifiers to Solve Math Word Problems》。

但他们的发现指向了一个更大的图景：

在 AI 时代，评判能力正在取代实现能力，成为最稀缺的工程技能。

这不是人类的退却。相反，这是人类角色的升级：

• 从执行者到设计者
• 从实现细节到定义标准
• 从写代码到写验证代码的代码

Harness 工程的实践者们已经证明：当验证器被正确设计，Agent 可以成为可靠的生产力倍增器。

而人类的真正价值，在于知道什么是好的——以及如何让机器也明白这一点。

参考来源：

• Cobbe et al.: Training Verifiers to Solve Math Word Problems (arXiv:2110.14168)
• Carlini: Building a C compiler with a team of parallel Claudes (Anthropic)
• OpenAI: Harness engineering: leveraging Codex in an agent-first world
• George: Harness 工程就是控制论

← 返回 AI-Native 工程系列