我几乎没看代码就重写了 PostHog 的 SQL 解析器，快了 70 倍
文章摘要
这篇文章讲述了作者如何借助 AI，在”几乎不看代码”的情况下重写了 PostHog 的 SQL 解析器，并实现了巨大的性能提升。
PostHog 最初使用 ANTLR（一个解析器生成器）在 C++ 中实现 SQL 解析器。ANTLR 虽然功能强大，但它通过图遍历解释器来运行，需要解释一个 ATN（增强转移网络，augmented transition network）。这一抽象层加上对任意动态前瞻（dynamic lookahead）的支持，使其比手写解析器要慢得多。
作者的新方案是借助 Claude 从零重写解析器，最终产出了”1.6 万行手写的解析器代码、5 千行工具代码”以及额外的测试覆盖。新实现是一个用 Rust 编写的”手写的、以预测式为主的递归下降解析器，核心采用 Pratt 表达式解析”。
整个过程中最关键的，是几项工程方法而非”让 AI 自己发挥”：
- 以 Oracle 为基准的测试驱动开发：作者把原来的 C++ 解析器当作”标准答案”（ground truth），让新解析器在真实查询上的行为与之完全一致。
- 基于属性的测试（Property-Based Testing, PBT）：使用 Hypothesis，团队根据 ANTLR 的语法文件代码生成了一个 SQL 生成器，从而产出多样化的测试用例；还通过 token 交换、括号变体等手段制造更多排列组合。
- 提示词工程：每次修复前，都让 Claude 加载语法文件和参考用的 C++ 源码，避免它做出”脆弱的修复”导致脆弱的方案。
- 持续模糊测试（Fuzzing）：后台智能体并行地持续运行 PBT、分析生产查询日志、探索边缘情况，与开发同步进行。
在性能结果上，针对生产查询，新解析器实现了 454 倍 的速度提升；标题中提到的 70 倍，是笔记本电脑基准测试的数据。
HN 评论精华
cespare（高赞） 挑战了”手写解析器很难”这一前提：”手写解析器比人们想象的要容易写好、也更容易维护得多。”他认为真正的价值在于可测试性和正交的复杂度，这恰恰让解析器成为 AI 辅助的理想对象——尽管作者最初对工期的预估有些夸大。
keeda 提出了一个有趣的框架：未来将是”凭感觉编码”（vibe-coding），工程师的重心从阅读生成的代码，转移到”精心打造全面而严密的验证机制”上。这代表着一种从”代码审查”到”严谨测试设计”的转变。
jakewins 点出了核心模式：”如果你有一个 Oracle，而你的问题在很大程度上只是一个纯函数，那么 AI 很擅长生成出既能正确工作又跑得快的东西。”
也有批判的视角。ncruces 从哲学层面质疑这套方法论：”这门源语言到底有什么问题，以至于用……随机代码生成器和模糊测试，反而比造一个足够聪明的编译器更好？”sscaryterry 批评了营销话术：”每次有人说什么东西快了 X 倍……都是纯粹的标题党”，尽管他也承认这项工作本身很扎实。duendefm 则表达了更宽泛的担忧：AI 让人能走捷径，长此以往可能拖慢这个行业的知识积累与进步。