我們使用編碼代理為RonDB新增RonSQL支援

在Hopsworks，我們最近利用新一代AI程式設計工具，成功為RonDB新增了複雜的SQL查詢支援。這個名為RonSQL的功能，包括CTE（公用表表示式）和推送連線聚合，已經在RonDB 26.04.1中以Beta形式釋出。

幾年前，我們曾嘗試使用ChatGPT進行編碼，但那次嘗試被證明是一個昂貴的錯誤——生成的程式碼花費了幾個月的時間重寫。因此，今年年初我再次嘗試AI程式設計時，抱持著相當多的懷疑態度。

最初的轉機來自一個意想不到的地方：我們的營銷經理在大約兩小時內構建了一個簡單的RonDB客戶端。這引起了我的興趣，我接手程式碼後，又在幾個小時內對其進行了顯著擴充套件。受到鼓舞，我嘗試了更接近真實工程的任務：擴充套件REST API伺服器，使其不僅能處理批次鍵讀取，還能處理批次鍵插入、寫入和刪除。原始程式碼編寫耗費了大量精力，而擴充套件只用了兩天。顯然，Claude和Codex在擴充套件現有程式碼方面表現出色。

有了這些成功實驗後，我意識到這些新工具可能對開發RonDB真正的新功能極為有用。客戶長期以來一直渴望在即時AI推理中實現更復雜的查詢。支援這一點需要CTE和並行連線聚合——這個功能在RonDB的待辦清單上已經躺了十多年。它是一項非常複雜的開發工作；用傳統編碼，我估計至少需要兩年時間。

實際上，這相當於在鍵值儲存中新增複雜SQL子集的支援。RonDB與Redis和DynamoDB屬於同一類別，這些儲存傳統上用於這種即時、低延遲的服務，但完全不支援複雜SQL查詢。將CTE和並行連線聚合引入這個領域，使得這項工作既非比尋常又值得。

我決定看看AI程式設計是否能讓它變得可行。本文分享了我在過去五個月中的經驗。

開發模式從一開始就清晰：有效的開發模式依然適用。從高層次計劃開始，轉向詳細實現計劃，然後逐步實現。我們多次經歷了這個迴圈。每個計劃至少包含10到20個階段，有時更多。

在Claude和Codex之間，我的結論是它們的優勢互補。Claude更擅長跟蹤計劃和剩餘工作。Codex通常更擅長解決難題，但它在維護計劃方面較為馬虎，可能會忘記下一步該做什麼。因此，大部分時間我讓Claude負責計劃維護和較簡單的任務，而將難題交給Codex。

AI程式設計的一個直接好處是能夠生成大量的單元測試——即使是通常難以測試的分散式場景。RonSQL查詢執行跨越RonDB的四個層：LDM（本地資料管理器）、TC（事務協調器）、NDB API和RonSQL。通常，你需要針對RonSQL編寫測試程式，因為手動針對LDM、TC和NDB API層編寫和維護程式非常困難。AI程式設計改變了這一點：變得可以先開發和測試LDM層，然後再接觸TC層，最後是NDB API層。這大大加快了在所有四個層上快速實現工作版本的速度。

AI程式設計在模型訓練中見過的順序程式碼上效果很好。但RonDB使用非同步程式設計模型，有時模型需要明確的指導才能理解實際工作方式。對我來說顯而易見的事情，模型可能完全看不見——但透過提示通常很容易教會它。反過來也經常發生：模型生成新程式碼的速度遠超人類思考。

如何驗證生成的程式碼是否正確？我遵循以下模式：

第一階段：按計劃構建。遵循高層次計劃，然後是實施計劃，最後逐步實施。在這個階段，你是架構師：告訴模型做什麼，大部分情況下你作為操作者接受它的建議。我發現至關重要的一點是，不讓模型在未明確說明更改內容和方式的情況下修改任何程式碼。Claude預設就是這樣；而Codex需要嚴格約束，以防止它擅自生成程式碼而不檢查正確性。檢視每個差異能讓你至少對新程式碼的作用有一個概念——這也是生成大量測試的階段。關鍵的是，每一步都包括編寫至少一個測試用例，並在進入下一步之前驗證該步驟已成功執行。步驟只有在有透過測試證明時才視為“完成”。這保持了實現的基礎，防止小錯誤在計劃的多個階段中累積。

第二階段：審查。步驟完成後，審查所有新程式碼。我主要關注影響實際執行的程式碼，只瀏覽測試用例和計劃。我使用模型生成文件——包括圖片和信令圖——以更好地理解新程式碼。這個階段確保模型遵循RonDB的記憶體模型，並正確處理節點故障和其他查詢執行中的故障。模型也傾向於生成大量重複程式碼，因此刪除重複程式碼路徑是必不可少的步驟——有些刪除掉了數千行需要維護的生產程式碼。

第三階段：用測試壓力測試功能。我們編寫了CTE測試用例，不考慮它們是否被支援。當一個功能不被支援時，我們要麼修復它，要麼將其標記為不支援。剩下的是儘可能減少查詢延遲，並繼續審查生成的程式碼。

最後一點觀察：當模型思考時，有足夠的時間做其他事情。大部分時間我同時執行兩到四個專案。因此，在RonSQL之外，還出現了RonDB直譯器的JIT編譯器、在RonDB中使用纖程以及死鎖檢測的原型。目前只有死鎖檢測在原始碼樹中，且預設停用。這三個都還在進行中。

回顧過去，一個在待辦清單上超過十年的功能——我原本預估需要兩年時間——在五個月內達到了Beta。工作並沒有消失，而是改變了形態。我的角色從編寫程式碼轉變為架構設計、指導模型、審查結果，以及最重要的測試。這，遠超原始程式碼生成，是新一代AI程式設計在我們構建RonDB中贏得一席之地的原因。