八年来，SQLite 开发者工具的质量问题始终困扰着 Lalit Maganti。作为 Google Perfetto 团队的高级工程师，他在日常工作中频繁接触 PerfettoSQL—— 一个基于 SQLite 的查询语言，内部有约十万行代码被各团队广泛使用。然而，他发现市面上根本没有可靠、快速且足够灵活的 SQLite 开发工具。这种挫败感持续了八年，始终没有行动的机会，直到 AI 编码工具的出现彻底改变了游戏规则。

愿景的萌芽与阻碍

Maganti 在 Perfetto 的工作使他深刻理解 SQLite 生态的缺陷。用户对格式化器、linter、编辑器扩展的期望与现有工具的质量之间存在巨大鸿沟。他曾尝试从开源社区寻找解决方案，但发现现有工具要么不够可靠，要么速度无法接受，要么缺乏对 PerfettoSQL 这类扩展的支持。问题的核心在于构建高质量语言工具需要精确解析 SQL，而 SQLite 与其他编程语言不同，它没有正式的语法规范，也不暴露稳定的解析器 API。事实上，SQLite 的实现本身甚至不构建解析树。这意味着唯一合理的路径是从 SQLite 源代码中提取相关部分并加以适配。

这个方案的难度是全方位的。首先，SQLite 源代码以其极高的密度著称，Maganti 花费数天仅为了理解虚拟表 API 和实现细节。其次，SQLite 有超过四百条语法规则需要逐条处理，每条规则都必须精确指定语法节点到解析树的映射方式。这种工作既困难又繁琐，是典型的 “做起来无聊、做错了更糟” 的任务。多年以来，这个项目始终停留在 “总有一天要做” 的状态，直到 AI 编程助手让他看到了真正动手的可能。

三次迭代：从失控到掌控

Maganti 的 AI 开发经历了一个关键的演变过程。第一阶段是 2025 年底至 2026 年一月的 “氛围编程” 阶段。他使用 Claude Code 的 Max 套餐（每月 200 英镑），几乎将所有设计和实现工作都委托给 AI。在这个月里，他得到了一个用 C 实现的解析器（从 SQLite 源码提取）、一个格式化器、SQLite 和 PerfettoSQL 的支持，以及一个 Web 演示界面。然而，当他在月底仔细审视代码时，现状令人沮丧：代码完全是意大利面条式结构，Python 源码提取管道有大量无法理解的部分，函数分散在随机文件中，某些文件膨胀到几千行。这是一个脆弱的系统，短期内解决了问题，但根本无法承载更大的愿景，也不可能集成到 Perfetto 工具链中。

这次失败促成了关键的转折。他决定丢弃一切，从头开始，同时将大部分代码库切换到 Rust。他意识到 C 难以构建高级组件如验证器和语言服务器实现，而 Rust 可以用同一门语言处理提取和运行时。此外，他完全改变了自己在项目中的角色：从 “甩手掌柜” 变成所有决策的第一责任人，将 AI 更多地用作 “增强版自动补全”，而非独立的开发者。他推行了一套严格的流程：先做有观点的设计、彻底审查每一处改动、发现问题时立即修复、并投入精力构建脚手架工具如 linting、验证和非平凡的测试来自动检查 AI 输出。

这种工作方式在二月份开始见效，核心功能逐渐成形。三月则是最后的冲刺：上游测试验证、编辑器扩展、包装和文档工作，最终在三月中期发布了 0.1 版本。

AI 赋能的具体维度

Maganti 明确指出，没有 AI，这个项目根本不会存在。他将 AI 的帮助归纳为几个关键维度。

克服启动惯性是他提到的首要收益。作为软件工程师，他最大的弱点之一是面对大型新项目时的拖延倾向。AI 让他能够将 “我需要理解 SQLite 如何解析” 这类模糊问题转化为 “让 AI 提出一个方法，我可以推翻并构建更好的方案” 这样的具体任务。他更适合有具体原型可以摆弄、有代码可以查看的状态，而不是在脑海中无休止地思考设计。AI 让他以前所未有的速度到达可以工作的代码阶段，一旦迈出第一步，后续每一步都变得更容易。

代码生成速度是另一个显著优势。AI 在编写 “显而易见” 的代码方面表现得比他更好。如果能把问题分解为 “编写一个具有此行为的函数” 或 “编写一个匹配此接口的类”，AI 会更快地完成，而且代码风格对未来读者可能更直观。AI 会记录他通常会跳过的文档，保持代码布局与项目其他部分一致，并遵循所使用语言的 “标准方言”。不过这种标准化是一把双刃剑：对于绝大多数代码来说，标准正是所需要的 —— 可预测、可读、不出意料。但每个项目都有其边缘部分，即价值来自做非显而易见事情的那些部分。对 syntaqlite 来说，这是提取管道和解析器架构。AI 标准化本能在那儿是有害的，这些部分必须由他深度设计，往往不得不自己动手写。

重构能力同样关键。AI 生成代码的速度使得大规模重构成为可能，也成为必须。如果不持续进行重构，代码会立即失控。这是氛围编程阶段的核心教训：重构不够，代码库变得无法理解，最终只能全部推倒重来。在重写过程中，重构成为了工作流程的核心。每当生成一大批代码后，他会退后一步问 “这丑陋吗？” 有时 AI 可以清理，有时存在大规模抽象是 AI 无法看到的，他会给出方向让 AI 执行。

研究效率是他认为价值与时间投入比最高的使用方式。他曾需要构建格式化器，但此前从未听说过 Wadler-Lindig 漂亮打印算法。AI 给了他一个可以从他理解的角度出发的具体且可操作的课程，并指向了可以深入学习的论文。他可以压缩可能是一两天的阅读为一个集中的对话，持续问 “为什么这有效” 直到真正理解。这延伸到他从未接触过的整个领域。他有深厚的 C++ 和 Android 性能专业知识，但几乎没碰过 Rust 工具链或编辑器扩展 API。有了 AI，这不是问题：基础原理相同，术语相似，AI 架起了桥梁。VS Code 扩展本来会花费他一两天的 API 学习时间，而有了 AI，一个可工作的扩展在一小时内就完成了。

长尾功能的完成度同样令人印象深刻。AI 让他完成了原本会无限期推迟的长尾功能：编辑器扩展、Python 绑定、WASM 演示场、文档网站、多个生态系统的打包。这些功能重要但不关键，是理论上知道如何做但因为核心工作更紧迫而被不断推迟的事项。AI 使这些变得足够便宜，以至于跳过它们反而成了错误的权衡。AI 还释放了 mental energy 用于用户体验。他可以思考用户第一次体验应该是什么感觉：什么样的错误信息能真正帮助他们修复 SQL、格式化器输出默认应该是什么样子、CLI 标志是否直观。这些是将人们尝试一次的工具与持续使用的工具区分开来的东西。

AI 的隐性成本

然而，AI 的帮助并非没有代价。Maganti 详细描述了几个关键问题。

成瘾性是一个令人不安的并行。AI 编程工具与玩老虎机之间存在令人不舒服的相似之处。发送提示、等待、要么得到很棒的东西要么得到没用的东西。他发现自己深夜仍想 “再做一次提示”，不断尝试 AI 只是看看会发生什么，即使明知它可能不会起作用。沉没成本谬误也在起作用：即使任务明显不适合 AI，他仍然继续，告诉自己 “也许这次换个说法会有用”。疲劳反馈循环使情况恶化。当他有精力时，他可以写出精确的、范围恰当的提示，并真正产生效率。但当疲倦时，提示变得模糊，输出变得更糟，他会再次尝试，在这个过程中更加疲倦。在这些情况下，AI 可能比他自己实现东西更慢，但很难摆脱这个循环。

失去代码库的触感是另一个严重问题。在项目的几个时刻，他失去了对代码库的日常细节的掌控。不是整体架构或事物如何配合，而是哪一天住了哪里、哪些函数调用了哪些、累积成工作系统的小决策。当这种情况发生时，令人惊讶的问题会出现，他对到底哪里出了问题完全摸不着头脑。更深层次的问题是失去触感造成的沟通崩溃。当你没有正在发生的事情的思维线索时，与 Agent 进行有意义的交流变得不可能。每次交流变得更长更冗长。不是 “改变 FooClass 做 X”，而是 “改变做 Bar 的事情做 X”。然后 Agent 必须弄清楚 Bar 是什么，它如何映射到 FooClass，有时还会搞砸。这正是工程师们一直对不理解代码的经理的抱怨：要求奇异或不可能的事情。区别在于现在你成了那个经理。

设计决策的拖延也是一个渐进发现的问题。他发现 AI 使他拖延关键的设计决策。因为重构很便宜，他总是可以说 “以后再处理”。因为 AI 可以以与生成代码相同的工业规模进行重构，推迟的成本感觉很低。但事实并非如此：推迟决策腐蚀了他清晰思考的能力，因为代码库在此期间一直处于混乱状态。氛围编程月份是这方面最极端的版本。是的，他理解问题，但如果更早地遵守做出艰难设计调用的纪律，他本可以更快地收敛到正确的架构。

测试的虚假安慰也是问题之一。拥有 500 多个测试让人感到安慰，AI 生成更多测试也很容易。但人类和 AI 都不够有创意，无法预见你将来会遇到的每一个边缘情况。在氛围编程阶段有好几次，他会产生一个测试用例并意识到某个组件的设计完全错误，需要完全返工。这是缺乏信任和决定彻底重写的重要原因。

时间感的缺失是他反复思考的事情。AI 以某种状态看到代码库，但不像人类那样 “感受” 时间。他可以告诉你使用一个 API 是什么感觉、它如何在数月或数年中演变、为什么某些决定被做出后来又被推翻。缺乏这种理解的自然问题是，你要么犯下过去已经犯过的错误并必须重新学习教训，要么掉入新陷阱，而这些陷阱第一次已经成功避免，从长远来看减慢了你的速度。

实用框架：何时依赖 AI

基于这些经验，Maganti 提出了一个实用的判断框架。当他从事他已经深度理解的事情时，AI 非常出色。他可以立即审查输出，在错误发生前抓住它们，并以他独自无法企及的速度移动。解析器规则生成是最清晰的例子：他确切地知道每个规则应该产生什么，所以可以在一两分钟内审查 AI 的输出并快速迭代。

当从事可以描述但尚不知道的事情时，AI 不错但需要更多小心。学习 Wadler-Lindig 做格式化器就是这样：他可以表达他想要什么，评估输出是否朝正确的方向发展，并从 AI 的解释中学习。但他必须保持参与，不能仅仅接受它给的东西。

当从事甚至不知道自己想要什么的事情时，AI 介于无益和有害之间。项目的架构是最清楚的案例：在早期几周，他跟随 AI 走向死胡同，探索当时感觉高效但经不起审视的设计。回头来看，他想知道如果根本不让 AI 介入思考是否会更快。

然而，仅有专业知识是不够的。即使他深刻理解一个问题，如果任务没有客观可验证的答案，AI 仍然会挣扎。实现有正确答案，至少在局部层面：代码编译、测试通过、输出匹配你要求的内容。设计没有。我们仍在为几十年前首次出现的面向对象编程争论。设计公开 API 是他发现这影响最大的地方。他在三月初花了几天什么也不做，只做 API 重构，手动修复任何有经验的工程师会本能避免但 AI 做得一团糟的事情。没有测试或客观指标来衡量 “这个 API 用起来是否愉快” 和 “这个 API 是否能帮助用户解决他们的问题”，而这正是编码代理做得如此糟糕的原因。

工程实践的具体参数

从 Maganti 的经验中可以提取几个可操作的工程实践参数。首先是代码审查的粒度控制：在使用 AI 生成代码后，应立即在代码实现后进行审查，并主动思考 “我会如何 differently 做这件事”。这解决了 “失去触感” 的问题。其次是重构频率：每当生成一大批 AI 代码后，应该退后一步评估代码是否丑陋，必要时进行大规模重构而非等到后期堆积问题。

第三是决策前置原则：关键设计决策必须在实现之前做出，不能依赖 AI 的渐进式探索。Maganti 明确指出氛围编程阶段最大的教训是推迟决策导致必须彻底重写。第四是验证机制的建立：他创建了 500 多个测试来验证解析器正确性，并构建了 linting、验证等自动化脚手架来检查 AI 输出。这些测试在发现设计缺陷时发挥了关键作用。

最后一个重要参数是工作时间的管理。Maganti 在三个月内投入了约 250 小时，平均每天约 2.8 小时，这还是利用了晚上、周末和假期的时间。这意味着 AI 辅助开发并非不需要时间投入，而是将时间重新分配到更高价值的决策和审查工作中，而非低价值的代码实现。

核心教训

Maganti 的历程揭示了一个关键真相：AI 是实现层面的惊人力量倍增器，但它是设计的危险替代品。它擅长给出特定技术问题的正确答案，但没有历史、品味或人类实际感受如何使用你的 API 的感觉。如果你在软件的 “灵魂” 方面依赖它，你会更快地撞墙，比以往任何时候都更快。

这个故事也提醒我们，传统的软件工程规则在 AI 时代仍然适用：如果你没有基本的基础（清晰的架构、定义良好的边界），你将永远追逐不断出现的 bug。AI 可以加速实现，但无法替代对问题本质的深刻理解 —— 这是任何技术工具都无法跨越的鸿沟。

资料来源：Lalit Maganti 个人博客，2026 年 4 月 5 日发布的《Eight years of wanting, three months of building with AI》