耗时3个月，爆肝250小时！开发者用AI圆了8年「执念」：终于做出了一套“好用”的SQLite开发工具

【CSDN 编者按】当 AI 编程从“噱头”走向“实用”，越来越多开发者开始探索它在真实项目中的边界——是万能助手，还是潜在陷阱？本文作者以 syntaqlite 的开发历程为切口，跳出“AI 神化”与“AI 无用”的二元对立，用 250 小时的亲身经历、从 Vibe Coding 到彻底重构的试错代价，拆解了 AI 在编程中的真实价值与隐藏痛点。

原文链接：
https://lalitm.com/post/building-syntaqlite-ai/

作者 | Lalit Maganti 翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

过去 8 年里，我一直有个执念：为 SQLite 做一套真正“好用”的开发者工具（devtools）。

说实话，SQLite 在行业中的地位举足轻重，可这么久以来，居然没人投入精力去打造一套真正优秀的开发者体验，这一点始终让我百思不得其解。

直到几周前，我终于发布了 syntaqlite（在 GitHub 上开源）——这个项目花了我大约 3 个月、累计约 250 小时（主要是晚上、周末和假期）完成。

我非常确定一件事：如果没有 AI 编程 Agent，这个项目根本不会出现。

当然，现在网上普遍充斥着两种声音：

● 一种说 AI 一键生成项目，效率爆炸；

● 另一种说 AI 全是“垃圾代码”。

但这篇文章，我不会站队，只想做一件更有价值的事：系统性拆解我用 AI 构建 syntaqlite 的全过程，聊聊它具体帮了我什么，又在哪里拖了后腿。

这个坑，我为什么想填 8 年了？

我在做 Perfetto 项目时，维护了一套基于 SQLite 的查询语言：PerfettoSQL。它本质上是 SQLite 的一个扩展版本，用来分析性能 trace，在 Google 内部大约有 10 万行代码，很多团队在用。

于是，问题来了：一旦你有一门“被广泛使用”的语言，用户自然就会期待配套的格式化工具、代码检查工具、编辑器插件等生态。

我一开始以为可以直接复用开源 SQLite 工具，但现实是：找到的工具要么可靠性不足、速度太慢，要么灵活性不够，无法适配 PerfettoSQL——简单来说：没有一个能用的。

显然，从零自研是个可行的方向，可这件事始终排不上“最高优先级”。期间，我们一直勉强凑合使用现有工具，心里却始终盼着更好的方案。

另一条路，就是利用业余时间自己做。我十几岁时开发过不少开源项目，可上大学后没了动力，这份热情也就淡了。做开源项目维护者根本不是“把代码扔出去听天由命”那么简单，还要处理 Bug、排查崩溃、编写文档、搭建社区，更重要的是，要为项目找准方向。

不过，我对开源的执念从未消失——那种能自由做想做的事、同时帮到别人的感觉，一直激励着我。这个 SQLite 开发工具项目，也始终在我心里占着一席之地，是“我迟早要做的事”。

而我迟迟没动手，还有一个关键原因：这个项目又难又枯燥。

为什么这件事“又难又枯燥”？

既然要投入私人时间做，我就不想只做一个适配 Perfetto 的工具，而是想打造一款所有 SQLite 用户都能用的通用工具：也就是说，必须实现和 SQLite 完全一致的 SQL 语法解析。

所有面向语言的开发工具，核心都是解析器（Parser）。它负责把源码转换成抽象语法树，这是后续所有功能的基础数据结构。如果解析器不够精准，格式化、代码检查等功能必然会继承这些误差。

我之前找到的大部分工具，问题就出在这里 —— 它们的解析器只是近似模拟 SQLite 语法，而非精准还原。

可问题在于，和很多编程语言不同，SQLite 既没有正式的解析规范文档，也没有暴露稳定的解析器 API，更离谱的是，它的底层实现甚至根本不生成抽象语法树。在我看来，唯一可行的办法，就是从 SQLite 源码里精准提取相关模块，自己把解析器“抠”出来。

这就必须深入 SQLite 源码的细枝末节——而这个代码库的理解难度堪称“地狱级”。整个项目用 C 语言编写，代码风格极度紧凑，光是理解虚拟表 API 和实现，我就花了好几天。想要吃透整个解析器栈，几乎是一件不可能的事情。

除此之外，SQLite 有超过 400 条语法规则，覆盖了语言的全部用法。我需要为每一条语法规则定义：这段语法该映射到语法树的哪个节点。这项工作也极其重复，每条规则既和相邻规则相似，又存在本质差异。

而且不只是写规则，还要设计并编写测试用例保证正确性，出问题就调试，后续用户提交 Bug 还要排查修复……这么多年，我的这个想法一直卡在这一步。

作为副业项目，难度太高，又十分枯燥无聊，投入数月时间还可能做不成，风险实在太大。

转折点：AI 出现了！

我从 2025 年初就开始使用 AI 编程助手了，先是 Aider、Roo Code，后来又改用 Claude Code。它们确实好用，但我从不敢把正经项目完全交给它们，只当是“辅助”。

但到 2025 年底，我明显感觉大模型的质量明显有了质的飞跃，再加上我在 Perfetto 项目里不断被解析器问题卡住，我开始意识到：也许，是时候真正动手了。

圣诞节期间，我终于有空静下心思考，决定对 AI 做一次极限压力测试：我只开通 Claude Code 的 Max 套餐（每月 200 英镑），仅凭它能不能完成整个项目的开发？

整个1 月，我基本扮演半技术管理者的角色，把几乎所有设计和实现工作都交给 Claude。最终功能层面还算可观：通过一堆 Python 脚本从 SQLite 源码中提取出 C 语言解析器，基于此实现了格式化工具，同时支持原生 SQLite 和 PerfettoSQL 扩展，还做了一个网页演示版。

可1 月底我仔细 review 代码库时，问题暴露无遗：代码完全是一团乱麻。

● 我看不懂 Python 源码提取流程的大部分逻辑，函数散乱在各个文件中毫无结构，个别文件甚至膨胀到几千行；

● 整个代码库极其脆弱，只解决了眼前问题，根本无法支撑我的长远规划，更别说集成到 Perfetto 工具链中了。

唯一的价值大概是，这套方案验证了可行性，还生成了 500 多个测试用例，其中大部分后续都能复用。

我当即决定全部推翻重来，同时把核心代码库改用 Rust 重构。我发现，用 C 语言很难实现校验器、语言服务器等上层组件。而改用 Rust 还有一个好处：提取逻辑和运行时逻辑能用同一种语言实现，不用再拆分 C 和 Python。

更重要的是，我彻底转变了自己在项目中的角色：所有决策由我主导，把 AI 当作强化版代码补全工具，建立更严格的工作流程：提前敲定设计方案，逐行仔细审查每一处改动，发现问题立刻修复，同时搭建代码检查、校验、复杂测试等，自动校验 AI 输出的代码。

这一次，2 月核心功能逐步成型，3 月又完成上游用例校验、编辑器插件、打包、文档等收尾工作，最终我在 3 月中旬发布了 0.1 版本。

不过在我看来，这并不是故事的重点。我真正想聊的是：没有 AI，这件事根本不可能完成，以及使用 AI 过程中我付出的代价。

AI 到底帮了我什么？

我可以直白地说：AI 就是 syntaqlite这个项目能存在并完整落地的核心原因。

（1）帮我“动起来”（解决拖延）

过去我会卡在：“我要弄懂 SQLite 解析原理”；现在变成：“让 AI 先给个方案，我再改”。从抽象问题 → 具体问题，这极大降低了我的启动成本。

（2）写“标准代码”比我更快

对于逻辑明确的常规代码，AI 写得比我还好。只要我把问题拆解成“实现一个具备某功能、带指定参数的函数”或“编写一个符合某接口的类”，AI 就能比我更快完成，而且代码风格更统一、文档也更完整。

（3）重构能力极强

对我来说，AI 的最大价值之一：大规模重构。不过前提是，你必须持续重构，否则代码很快就会失控。这也是我第一个月用 AI 开发得到的教训：重构不到位，代码库变得难以理解，最终只能全部推翻。

（4）充当“私人导师”

例如，我之前做过解释器和解析器，但从未听说过 Wadler-Lindig 优雅打印算法。开发格式化工具时，AI 用我能理解的方式，给了我具体可落地的教学，还推荐了相关论文深入学习。

这一点还延伸到我完全陌生的领域。我精通 C++ 和 Android 性能优化，但几乎没接触过 Rust 工具链和编辑器扩展 API。有了 AI 就不成问题：底层原理相通，术语相近，AI 能完美填补知识缺口。开发 VS Code 插件时，原本我需要花一两天学习 API 才能上手，借助 AI 一小时就做出了可运行的插件。

（5）让项目“更完整”

除了让项目落地，AI 还让它以更完整的形态上线。所有开源项目都有一堆重要但非核心的功能：理论上知道怎么做，却因核心工作更紧急而一再延后。对 syntaqlite 来说，这份清单很长：编辑器插件、Python 绑定、WASM 演示版、文档站、多生态打包等。

AI 让这些功能的开发成本变得极低，放弃它们反而成了不划算的选择。同时，AI 也让我腾出精力关注用户体验：不用把所有时间花在实现上，我可以思考用户初次使用的感受。

AI 的代价（很多人不说的部分）

（1）上瘾机制（像老虎机）

使用 AI 编程工具，和玩老虎机一样，有种令人不安的相似感：发送提示词，等待结果，要么得到优质代码，要么一无所获。我经常熬夜，总想“再跑一次提示词”，即便知道大概率没用，还是忍不住尝试。

沉没成本谬误也会作祟：就算任务明显不适合 AI，也会安慰自己“换种表述说不定就行”。

（2）疲劳死循环

疲劳也会形成恶性循环：精力充沛时，我能写出精准、范围清晰的提示词，效率极高；疲惫时，提示词变得模糊，输出质量下降，反复尝试只会更累。

这种情况下，AI 开发甚至比我手动写更慢，但我们却很难跳出这个循环。

（3）对代码“失去掌控”

我很多次丢失对代码库的细节掌控，不是不理解整体架构和模块关系，而是记不清日常细节：代码分布、函数调用关系、无数小决策累积成的运行逻辑。一旦出现这种情况，突发问题会让我完全摸不着头脑，debug 困难、问题定位困难，这种感觉非常糟糕。

（4）沟通能力退化

当你不理解代码时，你会说“改那个处理 Bar 的东西”，而不是“改 FooClass”。

AI 还要自行推断 Bar 对应 FooClass，有时还会理解错误。这像极了工程师吐槽的那种不懂代码、提出不切实际需求的管理者——而我自己，却慢慢变成了那个管理者。

（5）设计能力被侵蚀

AI 会让你觉得“反正可以以后再改”，结果架构越来越乱、决策不断拖延。另外，测试用例也带来了虚假的安全感：500 多个测试用例看起来很稳妥，AI 生成测试也很轻松，但人类和 AI 都无法预见未来所有边界场景。很多时候：设计错了，测试也没用。

（6）AI 不理解“时间”

AI 完全没有时间流逝的概念，这一点让我感触极深。它只能看到代码库某一时刻的状态，却无法像人类一样感知时间维度。我能说出使用一个 API 的感受、它数月甚至数年的演进历程、当初为何做某个决策又为何推翻。

这种感知缺失，要么导致重复踩坑、重新交学费，要么落入之前避开的新陷阱，长期来看反而拖慢进度。

什么时候该用 AI？什么时候不该？

总结下来，AI 发挥作用和拖后腿的规律其实非常清晰。

面对我已深度理解的领域，AI 表现极佳。我能瞬间审查输出结果，提前发现错误，以单人无法企及的速度推进。解析器规则生成就是典型案例：我清楚每条规则该输出什么，一两分钟就能完成审查，快速迭代。

面对能描述清楚但不了解的知识，AI 有用但需要谨慎把控。学习优雅打印算法就是如此：我能明确需求，判断输出方向是否正确，从 AI 的讲解中学习，但必须全程参与，不能直接照搬结果。

面对连自己想要什么都不清楚的领域，AI 要么没用，要么就是灾难。项目架构就是最典型的例子：早期我跟着 AI 走了无数弯路，一些当时看似高效的设计，经不住推敲。现在回想，完全脱离 AI 自己思考，或许速度会更快。

而且光有专业知识还不够。即便我深度理解问题，只要任务没有客观可校验的答案，AI 就会表现拉胯。代码实现至少有局部标准答案：编译通过、测试用例跑通、输出符合预期。但设计没有，面向对象编程问世几十年，业内依旧争论不休。

以 syntaqlite 为例，最明显的就是公共 API 设计。三月初我花了整整几天只做 API 重构，手动修复那些资深工程师本能避开、AI 却搞得一团糟的问题。“API 是否好用”、“能否帮用户解决问题”等，这些问题没有测试用例或客观指标衡量，AI 编程助手在这方面表现极差。

这让我想起物理学里的相对论：局部小范围内，物理规律遵循简单的牛顿力学，可放大到全局，时空曲率无法通过局部现象预测。代码也是同理：函数或类层面通常有明确的最优解，AI 在这里表现出色；但架构是所有局部模块交互的结果，把局部正确的组件拼接起来，未必能得到良好的全局表现。

我认为，高效使用 AI 的核心能力，就是时刻清楚自己处于上述哪个维度。

最终结论

一个想法在心里藏了八年，仅用三个月就做成了可用的 SQLite 开发工具，这无疑是巨大的成功。我很清楚，没有 AI，这一切都不可能实现。

但这个过程并非外界宣传的那样一帆风顺、线性成功。我浪费了整整一个月在Vibe Coding 上，陷入了自己都不懂的代码库陷阱，最终付出了全部重构的代价。

我的核心收获很简单：AI 是实现层面的超强放大器，却不能替代设计。它能精准回答具体技术问题，却没有历史感知、没有审美，也不懂人类使用 API 的真实感受。

如果把软件的“灵魂”交给 AI，那只会比以往更快碰壁。

【活动分享】"48 小时，与 50+ 位大厂技术决策者，共探 AI 落地真路径。"

由 CSDN&奇点智能研究院联合举办的「全球机器学习技术大会」正式升级为「奇点智能技术大会」。

2026 奇点智能技术大会将于 4 月 17-18 日在上海环球港凯悦酒店正式召开，大会聚焦大模型技术演进、智能体系统工程、OpenClaw 生态实践及 AI 行业落地等十二大专题板块，特邀来自BAT、京东、微软、小红书、美团等头部企业的 50+ 位技术决策者分享实战案例。旨在帮助技术管理者与一线 AI 落地人员规避选型风险、降低试错成本、获取可复用的工程方法论，真正实现 AI 技术的规模化落地与商业价值转化。

这不仅是一场技术的盛宴，更是决策者把握 2026 AI 拐点的战略机会。