「這個專案不會成功。太難了，也太無聊。」這個想法在作者腦裡盤旋了整整八年。

直到 AI coding agents 出現。

一個拖了八年的念頭

作者在 Google 的 Perfetto 團隊工作，團隊內部有約十萬行 PerfettoSQL 代碼——這是基於 SQLite 的查詢語言。當你有一個被廣泛使用的語言，使用者自然會期待：格式化工具、linting 工具、編輯器擴充功能。

作者找遍了開源社群的 SQLite 工具，但每次都失望而歸。這些工具要不不可靠，要不速度不夠快，要不靈活性不足。顯然有機會從頭建構一個，但這永遠不是「最優先的事」。

開源的自由感——在自己想做的東西上工作，同時幫助別人——從未消失。SQLite devtools 專案在作者心裡一直是「某天我會做的東西」。但還有另一個理由讓他不斷推遲：這件事既困難又無聊。

為什麼這件事既困難又無聊

任何語言導向的 devtools，核心都是 parser（解析器）。這是負責將原始碼轉換為「parse tree（解析樹）」的組件，所有其他功能都建構在這個核心數據結構之上。如果你的 parser 不夠精確，formatter 和 linter 一定會繼承這些不精確性——許多現有工具都受此困擾。

SQLite 跟許多其他語言不同，它沒有描述如何解析的正式規格書。它也沒有暴露穩定的 API 供外部使用。甚至在實作中，它根本不建構 parse tree！唯一合理的方法是仔細提取 SQLite 原始碼中的相關部分，改造成 parser。

這意味著要深入了解 SQLite 的原始碼——這是一個極難理解的代碼庫。整個專案用 C 語言撰寫，風格極度密集；SQLite 有超過 400 條規則涵蓋其完整語言表面，作者必須在每個「語法規則」中指定該語法部分如何映射到 parse tree 中的相應節點。這是極度重複的工作。

好幾年來，念頭都在這裡死亡。對於 side project 來說太難、太無聊無法維持動力、風險太高投入數月到一個可能失敗的東西上。

AI 讓事情發生

作者從 2025 年初開始使用 coding agents。到了 2025 年底，模型在品質上似乎有了顯著進步。同時，作者在 Perfetto 工作中遇到無數問題，如果有可靠的 parser 這些問題都能輕易解決。

作者決定壓力測試 AI：能用 Max 方案（每月 £200）的 Claude Code，vibe-code 整個東西嗎？

在一月份，作者反覆迭代，扮演半技術經理的角色，幾乎把所有設計和實作都委派給 Claude。功能性上，作者到達了合理的狀態：一個從 SQLite 原始碼提取的 C 語言 parser、建構在它上面的 formatter、支援 SQLite 語言和 PerfettoSQL 擴充功能，全部暴露在 web playground 中。

但在一月底詳細檢視代碼庫時，缺點很明顯：代碼庫是一團意大利麵。作者不理解大部分 Python 原始碼提取流程，函數散落在隨機檔案中。這極度脆弱；它解決了眼前問題，但絕對無法應對作者的更大願景。

救贖之處是它證明了方法可行，並產生了超過 500 個測試。

作者決定丟棄一切從零開始，切換到 Rust。更重要的是，他完全改變了角色。他掌握了所有決策權，並將它作為「加了類固醇的自動完成」：先有主見的設計、徹底審查每個變更、發現問題立即修復、投資腳手架來自動檢查 AI 輸出。

核心功能在二月份完成，三月中達成 0.1 版本發布。

AI 讓這個專案存在

克服惰性

AI 讓作者能將所有懷疑、不確定、不願意開始，全部放到一旁，因為它給了作者非常具體的問題可以處理。不再是「我需要理解 SQLite 的解析如何運作」，而是「我需要讓 AI 建議一個方法給我，這樣我可以拆解它並建構更好的東西」。

作者在有具體原型可以玩、有代碼可以看時，工作效率高得多，而不是在腦海裡無限思考設計，而 AI 讓他能以以前夢想不到的速度到達那個點。一旦跨出第一步，之後的每一步都容易太多了。

更快產生代碼

假設代碼很明顯，AI 在撰寫代碼上比作者更擅長。如果作者能將問題分解到「寫一個有這個行為的函數」或「寫一個符合這個介面的類別」，AI 會比作者更快建構它，風格可能對未來讀者更直觀。

這種標準化是雙面刃。大部分代碼，標準正是你想要的：可預測、可讀、不驚人。但每個專案都有邊緣部分，價值來自做一些非明顯的事。對 syntaqlite 來說，那是提取流程和 parser 架構。AI 的正規化本能對那些部分有害，這些是作者必須深度設計並經常親自撰寫的。

讓 AI 在明顯代碼上快速的同樣能力，也讓它在重構上表現出色。如果你用 AI 以工業規模產生代碼，你必須不斷持續重構。如果不做，事情立刻失控。這是 vibe-coding 一個月的教訓：作者沒有足夠重構，代碼庫變成他無法推理的東西，必須丟棄一切。

教學助理

研究有最高的價值交付時間比。

作者之前處理過解譯器和 parser，但從沒聽過 Wadler-Lindig pretty printing。當需要建構 formatter 時，AI 給了作者一個具體可操作課程，並指向論文。AI 壓縮了可能要一到兩天的閱讀到專注對話中，在那裡作者可以問「但為什麼這有效？」直到他真正理解。

這延伸到他從未處理過的領域。作者有深厚的 C++ 和 Android 效能專業，但幾乎沒碰過 Rust 工具或編輯器擴充 API。用 AI，這不是問題：基礎相同，術語相似，AI 橋接差距。VS Code 擴充功能作者可能要一到兩天學習 API 才能開始。用 AI，一小時內就有運作的擴充功能。

單獨會建的更多

除了讓專案存在之外，AI 也是它發布得如此完整的原因。每個開源專案都有一長串重要但非關鍵的功能：理論上你知道如何做但一直延後因為核心工作更緊急的東西。對 syntaqlite 來說，清單很長：編輯器擴充、Python binding、WASM playground、docs 站。AI 讓這些夠便宜，跳過它們感覺像是錯誤取捨。

沒有 AI，作者會建構更小的東西，可能沒有編輯器擴充或 docs 站。AI 不只是讓同一個專案更快。它改變了專案是什麼。

AI 的代價

成癮

使用 AI coding 工具和玩老虎機之間有個令人不安的平行。你送出 prompt，等待，然後得到好東西或無用東西。作者發現自己深夜想來「再一個 prompt」，持續嘗試 AI 只看會發生什麼，即使他知道可能不會有用。沈沒成本謬誤也發作：即使對它明顯不擅長的任務，作者持續做。

疲勞回饋循環讓情況更糟。當作者有精力，他能寫精確、範圍明確的 prompt 並真正有生產力。但當他疲勞，prompt 變得模糊，輸出變差，他會再試，過程中變得更疲勞。在這些情況，AI 可能比親自實作更慢，但跳出循環太困難。

失去連結

專案中幾次，作者失去了代碼庫的心理模型。不是整體架構或如何組合。而是日常細節：什麼在哪裡、哪些函數呼叫哪些、累積成運作系統的小決定。當那發生，令人驚訝的問題會出現，作者會發現自己完全無法理解出錯的地方。

更深層的問題是失去連結造成溝通中斷。當你沒有心理線索理解發生什麼，不可能跟 agent 有意義溝通。每次交換變得更長更囉嗦。不是「改 FooClass 做 X」，你會說「改做 Bar 的東西做 X」。然後 agent 必須找出 Bar 是什麼、如何映射到 FooClass，有時它會弄錯。

緩慢腐蝕

作者發現 AI 讓他拖延關鍵設計決策。因為重構便宜，他總能說「我晚點處理這個」。因為 AI 可以跟產生代碼一樣的工業規模重構，延遲的感覺成本很低。但它並不低：延遲決策腐蝕清晰思考的能力，因為代碼庫中間保持混亂。

測試創造類似錯誤安慰。有 500+ 測試感覺安心，AI 讓產生更多很簡單。但人類或 AI 都不夠創造以預見未來會遇到的所有邊緣情況；在 vibe-coding 階段有幾次作者想出測試案例，然後意識到某組件的設計完全錯誤需要徹底重作。

沒有時間感

AI 對時間流逝理解多麼少。它看到代碼庫在某個狀態，但不以人類方式感受時間。作者可以告訴你使用 API 的感覺、它幾個月或幾年如何演進、為什麼某些決策後來被反轉。

從這種缺乏理解自然產生的問題是你要麼重犯過去的錯誤並重新學教訓，要麼掉入第一次成功避免的新陷阱，長期來說拖慢你。

相對性

AI 何時有幫助何時有害的模式相當一致。

當作者處理他已經深度理解的東西，AI 極佳。他能瞬間審查輸出，在落地前抓錯誤，以他無法單獨達到的速度前進。Parser 規則產生是最清楚例子：作者精確知道每條規則應該產出什麼，所以他能在幾分鐘內審查 AI 輸出並快速迭代。

當作者處理他能描述但還不知道的東西，AI 不錯但需要更多照顧。學習 Wadler-Lindig 做 formatter 是這樣：他能清楚表達想要的，評估輸出是否朝對的方向，從 AI 解釋中學習。但他必須保持參與，不能只接受給他的。

當作者處理他甚至不知道想要什麼的東西，AI 介於無害和有害之間。專案架構是最清楚案例：早期幾週作者跟 AI 走死胡同，探索感覺當下有生產力但在仔細檢視下崩潰的設計。後見之明，作者好奇不帶 AI 在 loop 純粹思考可能更快。

但專業不夠。即使作者深度理解問題，如果任務沒有客觀可檢查答案，AI 仍然掙扎。實作有正確答案，至少在局部層級：代碼編譯、測試通過、輸出符合要求。設計沒有。OOP 幾十年後我們還在爭論。

具體來說，作者發現設計 syntaqlite 公開 API 是這最痛的地方。三月初作者花了幾天只做 API 重構，手動修正任何有經驗工程師會直覺避免但 AI 完全搞砸的東西。沒有測試或客觀指標衡量「這 API 好用嗎」和「這 API 會幫助使用者解決他們的問題嗎」，這正是 coding agents 表現如此差的原因。

這帶作者回當時迷戀物理的日子，特別是相對論。物理定律在任何小局部區域看起來簡單牛頓，但拉遠時空彎曲無法從局部圖片預測。代碼一樣：在函數或類別層級，通常有清楚正確答案，AI 在那裡極佳。但架構是那些局部組件互動時發生的事，你不能縫合局部正確組件得到好全域行為。

總結

在腦裡帶一個專案八年是很長的時間。只花三個月工作看到這些 SQLite 工具真正存在運作是巨大勝利，作者完全知道沒有 AI 它們不會在這裡。

但過程不是人們通常貼的乾淨線性成功故事。作者浪費整個月在 vibe-coding。他掉進管理他不真正理解的代碼庫的陷阱，他用完全重寫付出代價。

作者的領悟很簡單：AI 是實作的驚人力倍器，但設計的危險替代品。它極擅長給你特定技術問題的正確答案，但它沒有歷史感、品味、或人類實際使用 API 的感覺。如果你依靠它處理軟體的「靈魂」，你只會比以前更快撞牆。

作者想從其他人看到更多正是他試圖在此做的事：用這些工具建構真實軟體的誠實詳細帳戶；不是週末玩具或一次性腳本，而是那種必須在與使用者、bug 報告、和你自己改變的心智的接觸中存活的軟體。