如何使用 LLM 驅動的範本來建立自己的 Node.js API

長久以來，開始新的 Node.js 專案的一個常見方式是使用樣板模板。這些模板幫助開發者重複使用熟悉的程式碼結構，並實現標準功能，例如訪問雲端文件存儲。隨著大型語言模型（LLM）的最新發展，專案樣板看起來比以往任何時候都更有用。

在這個進展的基礎上，我擴展了我現有的 Node.js API 樣板，新增了一個工具 LLM Codegen。這個獨立功能使樣板能夠根據文字描述自動生成模組程式碼。生成的模組包含完整的端到端測試、數據庫遷移、種子數據和必要的業務邏輯。

歷史

我最初為 Node.js API 樣板創建了一個 GitHub 倉庫，以整合我多年來開發的最佳實踐。大部分實現基於在 AWS 上運行的實際 Node.js API 的程式碼。

我對垂直切片架構和乾淨程式碼原則充滿熱情，以保持程式碼庫的可維護性和整潔性。隨著 LLM 的最新進展，特別是它對大型上下文的支持和生成高質量程式碼的能力，我決定嘗試根據我的樣板生成乾淨的 TypeScript 程式碼。這個樣板遵循我認為高品質的特定結構和模式。關鍵問題是生成的程式碼是否會遵循相同的模式和結構。根據我的發現，答案是肯定的。

總結一下，以下是 Node.js API 樣板的主要特點：

基於 DDD 和 MVC 原則的垂直切片架構

使用 ZOD 進行服務輸入驗證

通過依賴注入（InversifyJS）解耦應用組件

使用 Supertest 進行集成和端到端測試

使用 Dockercompose 的多服務設置

在過去的一個月裡，我花了週末時間來正式化這個解決方案並實現必要的程式碼生成邏輯。接下來，我將分享具體細節。

實現概述

讓我們來探索實現的具體細節。所有的程式碼生成邏輯都組織在專案根目錄下的 llm-codegen 資料夾中，確保易於導航。Node.js 樣板程式碼不依賴於 llm-codegen，因此可以作為常規模板使用，而無需修改。

它涵蓋了以下用例：

根據輸入描述生成乾淨、結構良好的新模組程式碼。生成的模組成為 Node.js REST API 應用的一部分。

創建數據庫遷移並擴展種子腳本，為新模組提供基本數據。

生成和修復新程式碼的端到端測試，確保所有測試通過。

第一階段生成的程式碼乾淨，符合垂直切片架構原則。它僅包含 CRUD 操作所需的業務邏輯。與其他程式碼生成方法相比，它生成的程式碼乾淨、可維護且可編譯，並且有有效的端到端測試。

第二個用例涉及生成具有適當架構的數據庫遷移，並用必要數據更新種子腳本。這項任務特別適合 LLM，因為它處理得非常好。

最後一個用例是生成端到端測試，這有助於確認生成的程式碼是否正常工作。在運行端到端測試時，使用 SQLite3 數據庫進行遷移和種子數據。

主要支持的 LLM 客戶端是 OpenAI 和 Claude。

如何使用

要開始，請導航到根資料夾 llm-codegen，並通過運行以下命令安裝所有依賴項：

npm i

llm-codegen 不依賴於 Docker 或任何其他重型第三方依賴，使得設置和執行變得簡單明瞭。在運行工具之前，請確保在 .env 文件中設置至少一個 *_API_KEY 環境變量，並為您選擇的 LLM 提供者提供適當的 API 密鑰。所有支持的環境變量都列在 .env.sample 文件中（OPENAI_API_KEY、CLAUDE_API_KEY 等）。您可以使用 OpenAI、Anthropic Claude 或 OpenRouter LLaMA。截至 12 月中旬，OpenRouter LLaMA 意外地可以免費使用。您可以在這裡註冊並獲得免費使用的令牌。然而，這個免費的 LLaMA 模型的輸出質量可能需要改進，因為大多數生成的程式碼無法通過編譯階段。

要啟動 llm-codegen，運行以下命令：

npm run start

接下來，您將被要求輸入模組描述和名稱。在模組描述中，您可以指定所有必要的要求，例如實體屬性和所需操作。核心剩餘工作由微代理執行：開發者、故障排除者和測試修復者。

以下是成功生成程式碼的範例：

以下是另一個示例，演示如何修復編譯錯誤：

以下是生成的訂單模組程式碼示例：

一個關鍵細節是，您可以逐步生成程式碼，從一個模組開始，然後添加其他模組，直到所有所需的 API 完成。這種方法使您能夠在幾次命令運行中生成所有所需模組的程式碼。

運作方式

如前所述，所有工作由這些微代理執行：開發者、故障排除者和測試修復者，由協調者控制。它們按列出的順序運行，開發者生成大部分程式碼庫。在每次程式碼生成步驟後，根據其角色檢查缺少的文件（例如，路由、控制器、服務）。如果缺少任何文件，則會進行新的程式碼生成嘗試，包括有關缺少文件的提示和每個角色的示例。一旦開發者完成工作，TypeScript 編譯就會開始。如果發現任何錯誤，故障排除者將接手，將錯誤傳遞給提示並等待修正的程式碼。最後，當編譯成功時，將運行端到端測試。每當測試失敗時，測試修復者會根據具體提示進行干預，確保所有測試通過，程式碼保持乾淨。

所有微代理都源自 BaseAgent 類，並積極重用其基本方法實現。以下是開發者的實現供參考：

每個代理都利用其特定的提示。請查看這個 GitHub 連結，了解開發者使用的提示。

經過大量的研究和測試，我完善了所有微代理的提示，生成乾淨、結構良好的程式碼，問題非常少。

在開發和測試過程中，使用了各種模組描述，從簡單到非常詳細。以下是幾個範例：

負責圖書館書籍管理的模組必須處理 CRUD 操作的端點。

負責訂單管理的模組。它必須提供處理客戶訂單的 CRUD 操作。用戶可以創建新訂單、閱讀訂單詳情、更新訂單狀態或信息，並刪除已取消或完成的訂單。訂單必須具有以下屬性：名稱、狀態、下單來源、描述、圖片網址。

資產管理系統，擁有一個“資產”模組，提供公司資產的 CRUD 操作。用戶可以將新資產添加到庫存中，閱讀資產詳情，更新維護計劃或資產位置等信息，並刪除處理或出售的資產記錄。

使用 gpt-4o-mini 和 claude-3-5-sonnet-20241022 測試顯示輸出程式碼質量相當，儘管 Sonnet 更貴。Claude Haiku（claude-3–5-haiku-20241022）雖然便宜且與 gpt-4o-mini 價格相似，但經常生成無法編譯的程式碼。總體而言，使用 gpt-4o-mini 時，單次程式碼生成會話平均消耗約 11k 輸入標記和 15k 輸出標記。根據每百萬個輸入標記 15 美分和每百萬個輸出標記 60 美分的標記定價（截至 2024 年 12 月），這相當於每次會話約 2 美分的成本。

以下是 Anthropic 使用日誌，顯示標記消耗：

根據我在過去幾週的實驗，我得出結論，儘管生成的測試可能仍然存在一些問題，但 95% 的時間生成的程式碼是可編譯和可運行的。

我希望您在這裡找到一些靈感，並且這能成為您下一個 Node.js API 或升級當前專案的起點。如果您有改進建議，隨時通過提交 PR 來貢獻程式碼或提示更新。

如果您喜歡這篇文章，請隨意點贊或在評論中分享您的想法，無論是想法還是問題。感謝您的閱讀，祝您實驗愉快！