用 Claude 重写 16K 行 SQL 解析器后，PostHog 工程师说：程序员的活儿不是写代码，是搭验证回路

2026 年 7 月，PostHog 工程师 Robbie Coomber 在官方博客公开了一组数字：他们用 Claude Opus 4.7 完整重写了 PostHog 的 SQL 解析器，新版在生产查询里平均比旧版快 454 倍，笔记本基准也有 70 倍。整个项目产出 16K 行手写解析器代码、5K 行工具代码、几千行测试代码——全是 AI 生成的（PostHog Blog, 2026-05）。

让这个数字反常识的不是 454 倍。让人坐直身子的是另一句话：

我没有亲手写任何代码。但我不会把它叫"凭感觉写出来的代码"。

这是文章的核心反转：AI Coding 的瓶颈从来不在 AI 写得多快，在你拿什么告诉它写错了。PostHog 这一轮不是一次 prompt 工程胜利，是一次"验证基础设施"的胜利。他们搭的不是 prompt，是 oracle——一个能持续回答"对不对"的裁判。

下面把这个工程动作拆给你看——为什么大多数人用 AI 重写组件会翻车，为什么 PostHog 跑通了，以及这套打法能不能搬到你手上的项目。

一、你给 AI 的反馈信号，决定了它能写出多复杂的东西

先说清楚 PostHog 为什么有 SQL 解析器。

PostHog 让你直接写 SQL 查数据，但用户写的 SQL 要先转译成 ClickHouse SQL 才能执行——因为他们要在数据库层做访问控制、性能优化、schema 迁移，同时不破坏用户查询。SQL 解析器是这个转译链的第一环，操作的是不可信输入：它生成的语法树（AST）会被下游所有组件消费。

过去 PostHog 的解析器用 ANTLR 生成，C++ 实现，跑在一种"本来就快的语言"上。但 ANTLR 的工作方式是通用图遍历——每访问一个 Token 都要走一遍带栈的非确定性有限自动机，还支持任意动态前瞻。这意味着哪怕是一段简单的 SELECT a FROM b，ANTLR 也要走多遍模拟路径。

ANTLR 灵活，但灵活是要付钱的。钱就是 p95 延迟。

Coomber 想重写。问题不是"要不要让 AI 写"，是"AI 写完了，谁来验收"。

他一开始直接对 Claude 说：用 Rust 重写，不要犯错。 Claude 写了。然后不停地出错。Coomber 在文章里原话是：它做了很多让我怀疑这件事是否可能的错误，每完成一轮编码我都想停下来。他老实承认：他也不知道这件事做不做得成。

这是大多数团队用 AI 重写组件的标准剧本。AI 不是写得不对，是它"不知道自己写得不对"——而人也不知道。

二、Oracle 是地基：先找一个能持续回答"对不对"的裁判