有一种流行的叙事正在悄悄扎根：AI 写代码越来越强，程序员的价值正在被侵蚀。
这个叙事在每个 GPT 版本发布时都会被重新激活。GPT-5.6 刚发布，舆论场上又响起了同样的声音。但如果你真的蹲下来看一个具体的案例，会发现完全相反的故事。
PostHog 的工程师 James 用 Claude 重写了公司的 SQL 解析器。结果：16K 行解析器代码、5K 行工具代码，性能提升 70 倍（生产中实测 454 倍），所有真实查询零偏差。
但真正值得注意的不是这些数字。而是他几乎没写一行代码。
他不是通过"写代码"完成这次重写的——他是通过"搭了一个验证闭环"完成的。这恰恰是程序员核心能力正在发生的结构性转变：从手写代码，到搭建验证系统。
一、为什么 PostHog 需要重写解析器——以及为什么它以前做不到
PostHog 是一个开源产品分析平台，用户可以直接写 SQL 查询数据。但底层是 ClickHouse 数据库，PostHog 需要在中间做一层 SQL 转译（transpile），把用户写的 SQL 转成 ClickHouse 能理解的 SQL。
这需要一个 SQL 解析器。
这个解析器处理的每一个查询都是不受信任的输入。下游的访问控制、性能优化，都依赖解析器生成的 AST（抽象语法树）。如果解析器错了，整个系统的基础就错了。
PostHog 之前用的是 ANTLR 生成的解析器。ANTLR 是一个开源的解析器生成器——你定义语法规则，它自动生成解析器代码。它强大、灵活，但代价是性能。
ANTLR 把语法规则编译成 ATN（增强型非确定性自动机），运行时用一个通用的解释器遍历这个图。每一次解析都是通过抽象和间接层完成的。没有手写的 parseExpression() 方法，所有操作都是通用的图遍历。
在 AI 出现之前，手写一个解析器根本不现实。 需要几个月的时间，维护成本极高，远不值得为了性能提升去投入。
ANTLR 的通用性换来了开发效率，但牺牲了运行时性能。这是一个经典的"通用工具 vs 特化实现"的权衡。
AI 让这个权衡的天平倾斜了。
二、验证闭环：程序员的新工作方式
James 的重写过程，本质上是一个不断迭代的验证闭环：
生成测试用例 → 发现差异 → 修复解析器 → 运行回归 → 重复
这个闭环包含了三个关键层次。
2.1 第一层：Oracle 比对
James 有一个"标准答案"——现有的 C++ ANTLR 解析器。他把这个解析器当作 oracle（标准参照），新解析器的目标就是在所有真实查询上与 oracle 输出完全一致。
这听起来简单，但实现起来并不容易。两个解析器之间的差异点不会自动浮现，你得主动去找它们。
2.2 第二层：自动化差异发现
James 用了四种方法找出差异：
- 回归测试套件——已有的测试用例，初期快速验证
- 基于属性的测试（PBT）——用 Hypothesis 库自动生成 SQL 语句，寻找新解析器与 oracle 不一致的输入
- 生产日志中的匿名查询——从真实流量中抽取样本
- "深入思考边缘情况"——让 Claude 的 Agent 在后台主动生成刁钻的测试用例
其中 PBT 是最核心的武器。James 甚至写了一个工具，基于 ANTLR 的语法文件自动生成 SQL 生成器。写一个新的 SQL 解析器，要先写一个解析 .g4 语法文件的解析器——他自嘲地笑了。
这里有一个关键洞察： 他会让 PBT 在后台持续运行，不断把新的失败用例写入文件。Claude 空闲时就调取这些用例修复。他的 CPU 始终满负荷跑 PBT，Claude 的推理始终满负荷修解析器——两条生产线同时运转。
2.3 第三层：覆盖率引导的定向生成
后期，James 加入了基于代码覆盖率的测试用例生成。生成器能识别哪些语法结构尚未被覆盖，然后有针对性地生成更多这类用例。
这一步不是必需的——生产数据集上的准确率已经接近 100%。但它帮助 James 发现了一些极其微妙的边缘案例。
最终迭代闭环： 生成失败用例（PBT + 真实语料 + 回归测试 + 边缘思考）→ 精简并加入回归测试 → 思考最佳修复方案，优先通用解决方案 → 实施修复，生成一段摘要供人类审阅 → 运行回归套件 → 自动重新循环
三、"验证闭环"框架：程序员的新能力模型
从 PostHog 的案例可以抽象出一个通用框架：验证闭环（Verification Loop）。
这个框架有三个层次，从基础到进阶：
第一层：Oracle 定义
- 你必须有"正确"的标准。这个标准可以是现有系统、人工标注、理论模型
- 没有 oracle，就没有验证。没有验证，AI 输出的质量就不可控
第二层：差异发现自动化
- 不能指望人眼发现所有差异。必须用自动化手段系统性搜索
- 核心工具：基于属性的测试、模糊测试、覆盖率引导
- 投入产出比：写测试工具所花的时间，远比手动审查 AI 输出更高效
第三层：闭环自治化
- 把差异发现和修复串成一个自动循环
- 人类从"逐行审阅代码"变成"审查闭环设计"
- 人类的关键决策：测试用例是否充分？修复方案是否通用？闭环是否收敛？
James 总结得很精准："虽然我没有亲手写任何代码，但我绝不会把这叫作'凭感觉编程'。我的 PBT 配置基于语法文件生成输入，并采用覆盖率引导生成——这在解析器模糊测试领域已经接近最先进水平。"
四、这个框架的跨场景解释力
验证闭环不是解析器重写的专属方法论。它适用于几乎所有 AI 生成代码的场景。
场景一：代码重构
假设你想让 AI 把一个旧系统的 Python 代码重写为 Go。如果直接让 AI 写，你得到的是"看起来不错但不一定对"的代码。
但如果你按照验证闭环：
- Oracle 定义：旧系统的输出和行为是 oracle
- 差异发现自动化：构建 diff 测试工具，自动化对比新旧系统的输出
- 闭环自治化：让 AI 不断修复直至所有测试通过
场景二：AI 辅助单元测试
测试生成本身就是验证闭环的天然应用。AI 生成测试用例，你运行测试套件，找出未覆盖的分支，让 AI 补充。
场景三：多 Agent 协作
当多个 Agent 协同工作时，验证闭环变成了"Agent 之间的共识检验"。每个 Agent 的输出互为 oracle，差异点就是冲突所在——这正是 CoAgent 框架试图解决的问题。
同一个框架，三层结构，不同场景。验证闭环不是 PostHog 的专属发明，它正在成为 AI 时代软件工程的基础范式。
五、落到行动：程序员该怎么做
如果你是一线开发者：
- 停止把精力花在"审阅 AI 的每一行代码"上——那是低效的
- 开始构建验证工具：测试框架、diff 工具、属性测试
- 你的核心产出不再是代码，而是"这组代码是正确的"的置信度
如果你是技术管理者：
- 不要用"AI 生成的代码行数"衡量团队效率
- 建立"验证闭环成熟度"指标：你的团队在每个项目中是否系统性地构建了 oracle、差异发现和闭环
- 投资于测试基础设施，它的回报率比直接买更多 AI credits 更高
如果你是架构师：
- 在设计系统时，把"可验证性"作为第一优先级
- 如果一个模块的输出无法被自动化验证，它就不应该被 AI 生成
- 考虑"影子模式"——让 AI 生成的新实现与旧系统并行运行，比较输出差异
这一次，James 用几天时间做完了过去需要几个月的工作。他没有写代码，但他搭建了一个系统，让 AI 在正确的约束下生成代码，让自动化测试保证代码质量，让验证闭环驱动迭代收敛。
AI 并没有让程序员失业。AI 只是把程序员从"写代码"提升到了"搭闭环"——一个更高级的工作。 那些掌握了验证闭环能力的程序员，他们的价值不仅没有降低，反而因为杠杆效应被放大了。
来源：PostHog Engineering Blog - I wrote a 70x faster SQL parser while barely looking at the code