【CSDN 編者按】當 AI 編程從“噱頭”走向“實用”，越來越多開發(fā)者開始探索它在真實項目中的邊界——是萬能助手，還是潛在陷阱？本文作者以 syntaqlite 的開發(fā)歷程為切口，跳出“AI 神化”與“AI 無用”的二元對立，用 250 小時的親身經(jīng)歷、從 Vibe Coding 到徹底重構(gòu)的試錯代價，拆解了 AI 在編程中的真實價值與隱藏痛點。

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

作者 | Lalit Maganti 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

過去 8 年里，我一直有個執(zhí)念：為 SQLite 做一套真正“好用”的開發(fā)者工具（devtools）。

說實話，SQLite 在行業(yè)中的地位舉足輕重，可這么久以來，居然沒人投入精力去打造一套真正優(yōu)秀的開發(fā)者體驗，這一點始終讓我百思不得其解。

直到幾周前，我終于發(fā)布了 syntaqlite（在 GitHub 上開源）——這個項目花了我大約 3 個月、累計約 250 小時（主要是晚上、周末和假期）完成。

我非常確定一件事：如果沒有 AI 編程 Agent，這個項目根本不會出現(xiàn)。

當然，現(xiàn)在網(wǎng)上普遍充斥著兩種聲音：

● 一種說 AI 一鍵生成項目，效率爆炸；

● 另一種說 AI 全是“垃圾代碼”。

但這篇文章，我不會站隊，只想做一件更有價值的事：系統(tǒng)性拆解我用 AI 構(gòu)建 syntaqlite 的全過程，聊聊它具體幫了我什么，又在哪里拖了后腿。

這個坑，我為什么想填 8 年了？

我在做 Perfetto 項目時，維護了一套基于 SQLite 的查詢語言：PerfettoSQL。它本質(zhì)上是 SQLite 的一個擴展版本，用來分析性能 trace，在 Google 內(nèi)部大約有 10 萬行代碼，很多團隊在用。

于是，問題來了：一旦你有一門“被廣泛使用”的語言，用戶自然就會期待配套的格式化工具、代碼檢查工具、編輯器插件等生態(tài)。

我一開始以為可以直接復用開源 SQLite 工具，但現(xiàn)實是：找到的工具要么可靠性不足、速度太慢，要么靈活性不夠，無法適配 PerfettoSQL——簡單來說：沒有一個能用的。

顯然，從零自研是個可行的方向，可這件事始終排不上“最高優(yōu)先級”。期間，我們一直勉強湊合使用現(xiàn)有工具，心里卻始終盼著更好的方案。

另一條路，就是利用業(yè)余時間自己做。我十幾歲時開發(fā)過不少開源項目，可上大學后沒了動力，這份熱情也就淡了。做開源項目維護者根本不是“把代碼扔出去聽天由命”那么簡單，還要處理 Bug、排查崩潰、編寫文檔、搭建社區(qū)，更重要的是，要為項目找準方向。

不過，我對開源的執(zhí)念從未消失——那種能自由做想做的事、同時幫到別人的感覺，一直激勵著我。這個 SQLite 開發(fā)工具項目，也始終在我心里占著一席之地，是“我遲早要做的事”。

而我遲遲沒動手，還有一個關(guān)鍵原因：這個項目又難又枯燥。

為什么這件事“又難又枯燥”？

既然要投入私人時間做，我就不想只做一個適配 Perfetto 的工具，而是想打造一款所有 SQLite 用戶都能用的通用工具：也就是說，必須實現(xiàn)和 SQLite 完全一致的 SQL 語法解析。

所有面向語言的開發(fā)工具，核心都是解析器（Parser）。它負責把源碼轉(zhuǎn)換成抽象語法樹，這是后續(xù)所有功能的基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)。如果解析器不夠精準，格式化、代碼檢查等功能必然會繼承這些誤差。

我之前找到的大部分工具，問題就出在這里 —— 它們的解析器只是近似模擬 SQLite 語法，而非精準還原。

可問題在于，和很多編程語言不同，SQLite 既沒有正式的解析規(guī)范文檔，也沒有暴露穩(wěn)定的解析器 API，更離譜的是，它的底層實現(xiàn)甚至根本不生成抽象語法樹。在我看來，唯一可行的辦法，就是從 SQLite 源碼里精準提取相關(guān)模塊，自己把解析器“摳”出來。

這就必須深入 SQLite 源碼的細枝末節(jié)——而這個代碼庫的理解難度堪稱“地獄級”。整個項目用 C 語言編寫，代碼風格極度緊湊，光是理解虛擬表 API 和實現(xiàn)，我就花了好幾天。想要吃透整個解析器棧，幾乎是一件不可能的事情。

除此之外，SQLite 有超過 400 條語法規(guī)則，覆蓋了語言的全部用法。我需要為每一條語法規(guī)則定義：這段語法該映射到語法樹的哪個節(jié)點。這項工作也極其重復，每條規(guī)則既和相鄰規(guī)則相似，又存在本質(zhì)差異。

而且不只是寫規(guī)則，還要設(shè)計并編寫測試用例保證正確性，出問題就調(diào)試，后續(xù)用戶提交 Bug 還要排查修復……這么多年，我的這個想法一直卡在這一步。

作為副業(yè)項目，難度太高，又十分枯燥無聊，投入數(shù)月時間還可能做不成，風險實在太大。

轉(zhuǎn)折點：AI 出現(xiàn)了！

我從 2025 年初就開始使用 AI 編程助手了，先是 Aider、Roo Code，后來又改用 Claude Code。它們確實好用，但我從不敢把正經(jīng)項目完全交給它們，只當是“輔助”。

但到 2025 年底，我明顯感覺大模型的質(zhì)量明顯有了質(zhì)的飛躍，再加上我在 Perfetto 項目里不斷被解析器問題卡住，我開始意識到：也許，是時候真正動手了。

圣誕節(jié)期間，我終于有空靜下心思考，決定對 AI 做一次極限壓力測試：我只開通 Claude Code 的 Max 套餐（每月 200 英鎊），僅憑它能不能完成整個項目的開發(fā)？

整個1 月，我基本扮演半技術(shù)管理者的角色，把幾乎所有設(shè)計和實現(xiàn)工作都交給 Claude。最終功能層面還算可觀：通過一堆 Python 腳本從 SQLite 源碼中提取出 C 語言解析器，基于此實現(xiàn)了格式化工具，同時支持原生 SQLite 和 PerfettoSQL 擴展，還做了一個網(wǎng)頁演示版。

可1 月底我仔細 review 代碼庫時，問題暴露無遺：代碼完全是一團亂麻。

● 我看不懂 Python 源碼提取流程的大部分邏輯，函數(shù)散亂在各個文件中毫無結(jié)構(gòu)，個別文件甚至膨脹到幾千行；

● 整個代碼庫極其脆弱，只解決了眼前問題，根本無法支撐我的長遠規(guī)劃，更別說集成到 Perfetto 工具鏈中了。

唯一的價值大概是，這套方案驗證了可行性，還生成了 500 多個測試用例，其中大部分后續(xù)都能復用。

我當即決定全部推翻重來，同時把核心代碼庫改用 Rust 重構(gòu)。我發(fā)現(xiàn)，用 C 語言很難實現(xiàn)校驗器、語言服務(wù)器等上層組件。而改用 Rust 還有一個好處：提取邏輯和運行時邏輯能用同一種語言實現(xiàn)，不用再拆分 C 和 Python。

更重要的是，我徹底轉(zhuǎn)變了自己在項目中的角色：所有決策由我主導，把 AI 當作強化版代碼補全工具，建立更嚴格的工作流程：提前敲定設(shè)計方案，逐行仔細審查每一處改動，發(fā)現(xiàn)問題立刻修復，同時搭建代碼檢查、校驗、復雜測試等，自動校驗 AI 輸出的代碼。

這一次，2 月核心功能逐步成型，3 月又完成上游用例校驗、編輯器插件、打包、文檔等收尾工作，最終我在 3 月中旬發(fā)布了 0.1 版本。

不過在我看來，這并不是故事的重點。我真正想聊的是：沒有 AI，這件事根本不可能完成，以及使用 AI 過程中我付出的代價。

AI 到底幫了我什么？

我可以直白地說：AI 就是 syntaqlite這個項目能存在并完整落地的核心原因。

（1）幫我“動起來”（解決拖延）

過去我會卡在：“我要弄懂 SQLite 解析原理”；現(xiàn)在變成：“讓 AI 先給個方案，我再改”。從抽象問題 → 具體問題，這極大降低了我的啟動成本。

（2）寫“標準代碼”比我更快

對于邏輯明確的常規(guī)代碼，AI 寫得比我還好。只要我把問題拆解成“實現(xiàn)一個具備某功能、帶指定參數(shù)的函數(shù)”或“編寫一個符合某接口的類”，AI 就能比我更快完成，而且代碼風格更統(tǒng)一、文檔也更完整。

（3）重構(gòu)能力極強

對我來說，AI 的最大價值之一：大規(guī)模重構(gòu)。不過前提是，你必須持續(xù)重構(gòu)，否則代碼很快就會失控。這也是我第一個月用 AI 開發(fā)得到的教訓：重構(gòu)不到位，代碼庫變得難以理解，最終只能全部推翻。

（4）充當“私人導師”

例如，我之前做過解釋器和解析器，但從未聽說過 Wadler-Lindig 優(yōu)雅打印算法。開發(fā)格式化工具時，AI 用我能理解的方式，給了我具體可落地的教學，還推薦了相關(guān)論文深入學習。

這一點還延伸到我完全陌生的領(lǐng)域。我精通 C++ 和 Android 性能優(yōu)化，但幾乎沒接觸過 Rust 工具鏈和編輯器擴展 API。有了 AI 就不成問題：底層原理相通，術(shù)語相近，AI 能完美填補知識缺口。開發(fā) VS Code 插件時，原本我需要花一兩天學習 API 才能上手，借助 AI 一小時就做出了可運行的插件。

（5）讓項目“更完整”

除了讓項目落地，AI 還讓它以更完整的形態(tài)上線。所有開源項目都有一堆重要但非核心的功能：理論上知道怎么做，卻因核心工作更緊急而一再延后。對 syntaqlite 來說，這份清單很長：編輯器插件、Python 綁定、WASM 演示版、文檔站、多生態(tài)打包等。

AI 讓這些功能的開發(fā)成本變得極低，放棄它們反而成了不劃算的選擇。同時，AI 也讓我騰出精力關(guān)注用戶體驗：不用把所有時間花在實現(xiàn)上，我可以思考用戶初次使用的感受。

AI 的代價（很多人不說的部分）

（1）上癮機制（像老虎機）

使用 AI 編程工具，和玩老虎機一樣，有種令人不安的相似感：發(fā)送提示詞，等待結(jié)果，要么得到優(yōu)質(zhì)代碼，要么一無所獲。我經(jīng)常熬夜，總想“再跑一次提示詞”，即便知道大概率沒用，還是忍不住嘗試。

沉沒成本謬誤也會作祟：就算任務(wù)明顯不適合 AI，也會安慰自己“換種表述說不定就行”。

（2）疲勞死循環(huán)

疲勞也會形成惡性循環(huán)：精力充沛時，我能寫出精準、范圍清晰的提示詞，效率極高；疲憊時，提示詞變得模糊，輸出質(zhì)量下降，反復嘗試只會更累。

這種情況下，AI 開發(fā)甚至比我手動寫更慢，但我們卻很難跳出這個循環(huán)。

（3）對代碼“失去掌控”

我很多次丟失對代碼庫的細節(jié)掌控，不是不理解整體架構(gòu)和模塊關(guān)系，而是記不清日常細節(jié)：代碼分布、函數(shù)調(diào)用關(guān)系、無數(shù)小決策累積成的運行邏輯。一旦出現(xiàn)這種情況，突發(fā)問題會讓我完全摸不著頭腦，debug 困難、問題定位困難，這種感覺非常糟糕。

（4）溝通能力退化

當你不理解代碼時，你會說“改那個處理 Bar 的東西”，而不是“改 FooClass”。

AI 還要自行推斷 Bar 對應(yīng) FooClass，有時還會理解錯誤。這像極了工程師吐槽的那種不懂代碼、提出不切實際需求的管理者——而我自己，卻慢慢變成了那個管理者。

（5）設(shè)計能力被侵蝕

AI 會讓你覺得“反正可以以后再改”，結(jié)果架構(gòu)越來越亂、決策不斷拖延。另外，測試用例也帶來了虛假的安全感：500 多個測試用例看起來很穩(wěn)妥，AI 生成測試也很輕松，但人類和 AI 都無法預見未來所有邊界場景。很多時候：設(shè)計錯了，測試也沒用。

（6）AI 不理解“時間”

AI 完全沒有時間流逝的概念，這一點讓我感觸極深。它只能看到代碼庫某一時刻的狀態(tài)，卻無法像人類一樣感知時間維度。我能說出使用一個 API 的感受、它數(shù)月甚至數(shù)年的演進歷程、當初為何做某個決策又為何推翻。

這種感知缺失，要么導致重復踩坑、重新交學費，要么落入之前避開的新陷阱，長期來看反而拖慢進度。

什么時候該用 AI？什么時候不該？

總結(jié)下來，AI 發(fā)揮作用和拖后腿的規(guī)律其實非常清晰。

面對我已深度理解的領(lǐng)域，AI 表現(xiàn)極佳。我能瞬間審查輸出結(jié)果，提前發(fā)現(xiàn)錯誤，以單人無法企及的速度推進。解析器規(guī)則生成就是典型案例：我清楚每條規(guī)則該輸出什么，一兩分鐘就能完成審查，快速迭代。

面對能描述清楚但不了解的知識，AI 有用但需要謹慎把控。學習優(yōu)雅打印算法就是如此：我能明確需求，判斷輸出方向是否正確，從 AI 的講解中學習，但必須全程參與，不能直接照搬結(jié)果。

面對連自己想要什么都不清楚的領(lǐng)域，AI 要么沒用，要么就是災難。項目架構(gòu)就是最典型的例子：早期我跟著 AI 走了無數(shù)彎路，一些當時看似高效的設(shè)計，經(jīng)不住推敲?，F(xiàn)在回想，完全脫離 AI 自己思考，或許速度會更快。

而且光有專業(yè)知識還不夠。即便我深度理解問題，只要任務(wù)沒有客觀可校驗的答案，AI 就會表現(xiàn)拉胯。代碼實現(xiàn)至少有局部標準答案：編譯通過、測試用例跑通、輸出符合預期。但設(shè)計沒有，面向?qū)ο缶幊虇柺缼资?，業(yè)內(nèi)依舊爭論不休。

以 syntaqlite 為例，最明顯的就是公共 API 設(shè)計。三月初我花了整整幾天只做 API 重構(gòu)，手動修復那些資深工程師本能避開、AI 卻搞得一團糟的問題。“API 是否好用”、“能否幫用戶解決問題”等，這些問題沒有測試用例或客觀指標衡量，AI 編程助手在這方面表現(xiàn)極差。

這讓我想起物理學里的相對論：局部小范圍內(nèi)，物理規(guī)律遵循簡單的牛頓力學，可放大到全局，時空曲率無法通過局部現(xiàn)象預測。代碼也是同理：函數(shù)或類層面通常有明確的最優(yōu)解，AI 在這里表現(xiàn)出色；但架構(gòu)是所有局部模塊交互的結(jié)果，把局部正確的組件拼接起來，未必能得到良好的全局表現(xiàn)。

我認為，高效使用 AI 的核心能力，就是時刻清楚自己處于上述哪個維度。

最終結(jié)論

一個想法在心里藏了八年，僅用三個月就做成了可用的 SQLite 開發(fā)工具，這無疑是巨大的成功。我很清楚，沒有 AI，這一切都不可能實現(xiàn)。

但這個過程并非外界宣傳的那樣一帆風順、線性成功。我浪費了整整一個月在Vibe Coding 上，陷入了自己都不懂的代碼庫陷阱，最終付出了全部重構(gòu)的代價。

我的核心收獲很簡單：AI 是實現(xiàn)層面的超強放大器，卻不能替代設(shè)計。它能精準回答具體技術(shù)問題，卻沒有歷史感知、沒有審美，也不懂人類使用 API 的真實感受。

如果把軟件的“靈魂”交給 AI，那只會比以往更快碰壁。

【活動分享】"48 小時，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。"由 CSDN&奇點智能研究院聯(lián)合舉辦的「全球機器學習技術(shù)大會」正式升級為「奇點智能技術(shù)大會」。2026 奇點智能技術(shù)大會將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開，大會聚焦大模型技術(shù)演進、智能體系統(tǒng)工程、OpenClaw 生態(tài)實踐及 AI 行業(yè)落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團等頭部企業(yè)的 50+ 位技術(shù)決策者分享實戰(zhàn)案例。旨在幫助技術(shù)管理者與一線 AI 落地人員規(guī)避選型風險、降低試錯成本、獲取可復用的工程方法論，真正實現(xiàn) AI 技術(shù)的規(guī)模化落地與商業(yè)價值轉(zhuǎn)化。這不僅是一場技術(shù)的盛宴，更是決策者把握 2026 AI 拐點的戰(zhàn)略機會。