一个人、250小时、外加AI：SQLite终于等来像样的开发工具了
SQLite这么重要，为什么工具却一直这么“将就”
科技行业里有一种很典型的现象：最重要的东西，往往最不显眼。SQLite 就是这样一种存在。它不太上头条，不像大模型、芯片、自动驾驶那样自带流量，但它几乎藏在每一部手机、每一个浏览器、无数桌面软件和边缘设备里。它是很多应用默认的本地数据库，是“能跑就行”时代最稳的一块砖。
问题是，这块砖太稳了，稳到大家默认它会一直在那里，却很少有人愿意认真打磨围绕它的开发体验。写 SQLite 查询的人，并不比写 PostgreSQL 或 TypeScript 的人少，但他们拿到的格式化、Lint、编辑器补全、语法检查这些工具，长期处在“能凑合用”的水平。Lalit Maganti 在新文章里提到，他为这件事惦记了八年，真正动手则是最近三个月，最终做出了一个叫 syntaqlite 的项目。它瞄准的不是炫技，而是一个很朴素的目标：让 SQLite 开发者也有像样的工具链。
这件事乍看很“小”。无非是一个开源开发者工具发布而已。但如果你了解一点行业背景，就会发现它触到一个真实痛点：SQLite 的影响力远大于它的工具生态。很多成熟语言都有一整套“语法树—格式化—静态检查—语言服务”的基础设施，开发者已经习以为常；SQLite 这里却像停留在“手工时代”。不是没人想做，而是这事又难又烦，难到大厂内部都常常选择继续忍。
真正的难点，不是写个格式化器，而是得先和SQLite“同一种脑回路”
很多读者可能会觉得，做开发工具不就是写个 parser、再做点格式化和提示吗？听上去像个常规工程。问题在于，SQLite 并不是那种“规范写得很清楚、语法树接口也很稳定”的现代语言生态。恰恰相反，它没有一份完整、正式、对外友好的解析规范，内部实现也并没有直接吐出一个开发工具最想要的那种 parse tree（语法树）。
这意味着，如果你想做真正可靠的 SQLite 工具，而不是一个“差不多能解析大部分 SQL”的玩具，你就不能偷懒。你得尽量精确地跟 SQLite 本体保持一致。因为只要解析稍微歪一点，后面的格式化、Lint、错误提示都会跟着歪。开发者对这类工具最不能容忍的，恰恰就是“看着智能，关键时候误判”。
Lalit 的路径很硬核：不是另起炉灶发明一套“类 SQLite 语法”，而是尽量从 SQLite 源码里抽取真正相关的解析逻辑，再改造成自己需要的架构。这听着就知道不轻松。SQLite 的代码库以 C 语言写成，风格高度紧凑，老派、密实，而且规则很多。文章里提到，SQLite 语法有 400 多条规则。你不仅要理解它们，还得为每条规则定义“它在语法树里应该长什么样”。这是一种非常典型的工程折磨：技术门槛高，重复劳动又巨大。
这也是为什么这个念头能在作者脑中搁八年。不是因为它不重要，而是因为它太像一个“会吞掉你所有周末”的项目了。它不像做一个新 App 那样容易看见即时反馈，也不像做个炫酷 AI Demo 那样容易收获掌声。它更像修城市下水道：谁都知道重要，但真去干的人总是不多。
AI没有“凭空造神”，它真正改变的是项目能不能启动
这篇文章最有价值的地方，不在于作者又一次高呼“AI 改变一切”，而在于他讲得很诚实：AI 既是项目能诞生的关键推手，也差点把项目带沟里。
Lalit 说，他在 2025 年开始持续使用 Aider、Roo Code、Claude Code 等编码代理。真正让他下决心开干的，不是 AI 已经完美，而是它终于好到足以帮他跨过最痛苦的起步阶段。对很多工程师来说，最难的不是敲代码，而是面对一个巨大、模糊、风险高的新项目时那种心理惯性：不知道从哪开始，也不确定自己选的路对不对。AI 在这里的价值，有点像一个可以立刻产出原型、让你“边看边骂边改”的实习生。
他最开始甚至尝试过一种今天很流行的路线：把设计和实现大量交给 AI，自己做“半技术经理”。结果一个月后，他得到了一堆功能上可用、结构上却像意大利面的代码。解析器有了，格式化器有了，Web playground 也有了，但代码库脆弱、难懂、难扩展，根本撑不起更大的愿景。这一段特别像今天很多团队的缩影：AI 能在很短时间内把“有”和“没有”的差距抹平，却不保证你得到的是一栋可持续维护的房子。
于是他做了一个很不 AI 爆款叙事、但很工程真实的决定：全部推倒重来。换到 Rust，重新设计架构，把 AI 从“代替你做决定的人”降级成“超强自动补全”。这次他自己掌握全部关键决策，提前定义设计方向，逐个审查改动，还加上 lint、验证脚手架、非平凡测试等约束，专门用来防止 AI 一本正经地胡来。结果反而是项目在 2 月进入正轨，3 月完成 0.1 版本发布。
这让我想到一个越来越清晰的判断：AI 对软件工程最大的作用，不是让不会写代码的人一夜做出伟大系统，而是让本来就懂问题、懂品味、懂取舍的人，把长期被拖延的高摩擦工程真正做出来。它不是方向盘，更像涡轮增压器。方向错了，车会更快撞墙；方向对了，它确实能让你早点到。
最惊喜的地方，反而不是写代码，而是“陪你学会”
如果只把 AI 当代码生成器，反倒低估了它。Lalit 在文中提到，AI 在研究和学习上的回报率最高。比如他做格式化器时，AI 给他引到了 Wadler-Lindig pretty printing 这类编译器和排版理论里的经典方法，还能把抽象论文讲到可执行的程度。这个细节很有意思，因为它展示了 AI 目前一个非常适合工程师的角色：不是替代专业知识，而是把知识入口大幅压低。
你以前当然也能查资料、读论文、翻 API 文档，但成本很高，尤其跨领域时更明显。作者本来擅长 C++ 和 Android 性能，对 Rust 工具链、编辑器扩展 API 并不熟，AI 却让他在很短时间内做出了能用的 VS Code 扩展。这里的关键不是“AI 比人聪明”，而是它能把原本需要一两天的熟悉期，压缩成一小时的互动式带路。
这种带路能力，正逐渐改变个人开发者的项目边界。以前一个人做开源，核心功能能做完就不错了，外围那些绑定、文档站、打包、多生态发布、在线 playground，常常永远停留在 TODO 列表里。现在这些“最后一公里”被 AI 显著降本，项目完成度也因此被抬高。syntaqlite 不只是一个 parser，它还带着编辑器扩展、Python 绑定、WASM playground、文档和多生态包装一起出现。这件事非常现实：一个工具是否被真正采用，往往不是因为核心技术多高深，而是你有没有把最后那些麻烦事也做好。
但这里也埋着一个值得警惕的问题。如果 AI 让“做完”变容易，会不会也让代码库里充满更多维护负担？开源世界的难题从来不只是发布，而是长期维护。今天 AI 可以帮你一周铺出一大片功能面，明天谁来为这些边角功能修 bug、升级依赖、回应用户？这也是我看这篇文章时最强烈的复杂心情：兴奋是真的，担心也是真的。
这件事为什么发生在今天，而不是三年前
把时间拉远一点看，syntaqlite 的出现，几乎是两个趋势交叉后的产物。一个趋势是 SQLite 的地位越来越基础化。边缘计算、移动端、本地优先应用、嵌入式设备都在继续推高 SQLite 的存在感。另一个趋势则是 AI 编码工具终于进入“可以参与严肃工程，但必须被严密驯化”的阶段。
三年前，很多人对 AI 编码的理解还停留在“帮我写个函数”“帮我搭个脚手架”。今天更现实的用法已经变成：先让它把大量显然正确、但人类懒得手写的部分铺开，再由人类高密度评审、重构、压实架构。换句话说，AI 开始能接住那些过去“并非技术上不可能，只是人力上不值得”的项目。数据库工具、编译器外围、测试基础设施、跨平台适配，这些长期被低估的“脏活累活”，反而可能是 AI 时代最先开花的地方。
如果把它和近几年一些 AI 编码争论放在一起看，这篇文章也提供了一个相对靠谱的中间答案。一边是“AI 一句话生成整个应用”的营销神话，另一边是“AI 代码全是垃圾”的全面否定。现实显然更接近中间地带：对于高复杂度系统，AI 不是单兵作战选手，而是放大资深工程师生产力的协作者。它在标准化、重复性、模板化任务上大杀四方；在真正体现项目价值的非标准核心地带，仍然需要人类亲自下场。
这也是为什么我对 syntaqlite 这类项目比对某些“十分钟做出 SaaS”的视频更感兴趣。前者碰到的是工程硬骨头，能说明 AI 的真实边界；后者很多时候只是把 demo 和产品、把生成和维护混为一谈。一个工具能不能走远，最终要看它是否能经受版本迭代、用户反馈、异常输入、跨平台兼容这些无聊但残酷的现实。
从这个角度说，syntaqlite 的 0.1 版本不是故事结束，反而只是开始。它真正的考验还在后面：社区会不会用？能不能稳定跟上 SQLite 语法演进？Perfetto 之外的开发者愿不愿意迁移？这些问题没有一个能靠模型参数直接回答。
可即便如此，我还是愿意给这件事一个偏乐观的评价。因为它证明了一种很具体、也很有希望的可能性：那些过去“每个人都想要、但没人有精力做”的底层工具，终于开始有人做了，而且有机会做得更完整、更体面。这对软件行业来说，是一件比表面上看起来更重要的小事。