耗時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 拐點的戰略機會。