背景介紹
技術演進背景
隨着 DeepSeek 等開源 AI 工具的崛起，智能編程助手正在重塑軟件開發流程。對於開發者而言，AI 輔助編碼已為生產力工具。雖然目前 AI 尚無法直接根據需求文檔和指定技術棧生成完整生產級項目，但在特定場景下已展現出驚人潛力：基於詳細邏輯描述生成代碼片段準確率可達 80%以上。目前AI 在項目的工程化能力方面仍顯不足，而 Sponge 框架則在工程化能力表現出色，兩者恰好形成互補。
Sponge 是一個強大的 Go 語言開發框架，目前提供40多個代碼生成命令，其獨特的逆向工程能力支持通過解析 SQL/Protobuf/JSON 生成模塊化代碼，模塊化代碼可靈活組合出 Web、gRPC、HTTP+gRPC、gRPC 網關等多種服務架構。開發者只需在生成的項目代碼中填充業務邏輯，即可快速構建生產級後端服務。sponge生成代碼框架圖如下圖所示：
Sponge Github： https://github.com/go-dev-frame/sponge
黃金組合
當 Sponge 的工程化能力遇上 DeepSeek 的智能生成，形成了一套完整的高效開發解決方案：
- Sponge：負責基礎設施代碼生成（服務框架、CRUD API 接口、缺少業務邏輯實現的自定義 API 接口等）。
- DeepSeek：專注業務邏輯實現（表 DDL 設計、自定義 API 接口定義、業務邏輯實現代碼）。
值得一提的是，Sponge 已集成了 DeepSeek 的 API，只需簡單執行命令即可自動搜索項目代碼中待補全業務邏輯的方法函數，讓 DeepSeek 生成業務邏輯實現代碼。
項目實戰示例 —— 從零開始構建家電零售管理平台
下面以構建一個線下家電實體店的產品管理平台為例，説明如何利用 Sponge 與 DeepSeek 協同開發後端服務。本示例後端技術棧選擇 Web 服務 (Gin + Gorm + Protobuf)。
提示： 這裏把 API 接口的請求和返回數據結構定義在 Protobuf 文件中，充分利用 Protobuf 的優勢——解析Protobuf來生成框架所需的代碼和API接口文檔。
1. 生成功能需求文檔
首先，通過 DeepSeek R1 生成詳細的功能需求文檔。輸入以下提示：
“現在需要實現線下家電實體店鋪的產品管理平台的後台服務，請列出詳細的功能需求。”
DeepSeek R1 會生成一個較為全面的需求文檔，開發者可以根據實際需要刪減不必要的功能，保留真正需要的功能模塊，或額外添加補充功能模塊。點擊查看家電零售管理平台功能需求文檔。
2. 生成 MySQL 表結構 DDL
接下來，根據功能需求文檔生成所有 MySQL 表結構的 DDL。輸入以下提示：
“根據功能需求文檔，生成後台服務所需的所有 MySQL 表結構的 DDL，要求生成的 SQL 可直接導入 MySQL 創建表，表的每列均需附帶中文註釋。”
DeepSeek R1 會根據需求文檔生成對應的 Mysql 表結構 DDL，開發者需要校驗判斷是否完全滿足要求，如果不滿足可以人工調整。點擊查看家電零售管理平台表結構DDL。
把 Mysql 表結構 DDL 導入 MySQL 後，即可為後續代碼生成提供數據結構支持。Sponge 可以根據這些表結構生成各種模塊代碼，如 CRUD API 代碼 和 CRUD Protobuf 定義等。
3. API 接口定義
3.1 生成 CRUD API Protobuf
在 Sponge 的生成代碼頁面中，依次選擇：【Public】→【生成 Protobuf CRUD 代碼】，填寫參數後點擊【下載代碼】按鈕生成代碼，如下圖所示：
提示： 如果生成的 proto 文件較多，建議將它們合併到一個文件中，因為 DeepSeek R1 上傳文件數量有限制。
3.2 生成自定義 API Protobuf
標準的 CRUD API 並不能涵蓋所有業務需求，因此需要根據 CRUD API Protobuf 文件和功能需求文檔生成自定義 API 的 Protobuf 定義。
在 DeepSeek R1 中上傳 CRUD API 的 proto 文件和家電零售管理平台功能需求文檔，並輸入如下提示：
已確定所有 MySQL 表的標準 CRUD API 的 Protobuf 定義，這些 API 僅涵蓋家電零售管理平台後台服務的一部分功能，為了涵蓋所有的功能，請依據CRUD API 的 Protobuf 定義和家電零售管理平台的功能需求文檔，進行補充自定義API Protobuf，要求如下：
1. 每個 rpc 方法必須包含 option (google.api.http)。
2. rpc 方法及其 message 字段需附帶中文註釋，rpc 方法需詳細描述邏輯實現過程（作為 AI 生成業務邏輯代碼的依據）。
3. 補充的 API 需要標識其所屬的 Protobuf service。注： 若生成結果中 Protobuf 描述裏的 rpc 方法註釋不夠詳細(例如邏輯實現過程、指定技術棧)，可以適當人工補充完善。
生成的自定義 API Protobuf 與 CRUD API Protobuf 共同構成了服務完整功能的API接口定義，為後續 Sponge 提供生成代碼依據。
4. 創建服務代碼
以 Web 服務為例（技術棧：Gin + Gorm + Protobuf）進行後續代碼生成和集成。
4.1 生成服務基礎代碼
在 Sponge 代碼生成的頁面中，選擇：【Protobuf】→【創建 Web 服務】，填寫參數後點擊【下載代碼】按鈕生成代碼。如下圖所示：
生成的代碼包中包含服務的基本框架，解壓後進入代碼目錄。
4.2 生成 CRUD API 代碼
同樣在 Sponge 代碼生成的頁面中，選擇：【Public】→【生成 Handler CRUD 代碼】，填寫參數後點擊【下載代碼】按鈕生成代碼，如下圖所示：
解壓文件，將生成的 api 和 internal 目錄移動至服務代碼目錄中。
使用 VS Code 或 Goland 打開項目代碼，並將在前面由 DeepSeek R1 生成的自定義 API 的 Protobuf 文件人工合併到 api/store/v1 目錄下對應的 proto 文件中。
接着，在項目根目錄下執行以下命令生成代碼：
make proto
注： 每當修改 proto 文件後，都需重新執行 make proto 命令，可通過指定 proto 文件名生成代碼。
5. 業務邏輯代碼補全
Sponge 集成了 DeepSeek API，可自動定位到需要補充業務邏輯的方法函數，讓 AI 助手生成業務邏輯實現代碼，執行如下命令：
sponge assistant generate --type=deepseek --model=deepseek-reasoner --api-key=xxxx --dir=.生成的業務邏輯代碼會以 .assistant 為後綴保存在相應目錄下，開發者只需將其複製到對應方法函數中即可。這裏不採用自動填充的方式，是因為 DeepSeek R1 輸出可能包含 markdown 等非純 Go 代碼，故需人工校驗複製。
6. 測試和驗證 API 功能
至此，通過 Sponge 與 DeepSeek 的協同工作，絕大部分代碼均已自動生成。如果AI助手根據詳細的提示生成業務邏輯實現代碼也無法滿足要求，則需要人工編寫代碼。完整的web服務代碼雞蛋模型如下：
接着開發者調試與驗證 API 功能，啓動服務：
make run使用瀏覽器訪問 Swagger 界面進行 API 調試：http://localhost:8080/apis/swagger/index.html
這是Sponge與DeepSeek協同生成的後端服務示例代碼。
總結
本文通過一個家電零售管理平台的案例，演示瞭如何利用 Sponge 與 DeepSeek R1 協同開發後端服務的全過程：
- 需求分析：利用 DeepSeek R1 生成詳細功能需求文檔。
- 數據庫設計：依據需求生成 MySQL 表結構 DDL，並導入數據庫。
- 接口定義：先生成標準 CRUD API 的 Protobuf，再由 DeepSeek R1 生成自定義 API 的 Protobuf的定義信息。
- 服務代碼生成：利用 Sponge 分別生成基礎服務代碼、CRUD API 代碼、自定義 API 的 Protobuf代碼(只缺業務邏輯實現)。
- 業務邏輯代碼補全：通過 Sponge 內置 AI 工具自動生成業務邏輯代碼，並由開發者進行整合與校驗。
- 調試驗證：啓動服務，藉助 Swagger 等工具調試並驗證 API 接口。
這種基於 Sponge 與 DeepSeek R1 協同開發可以快速構建出一個功能完善、邏輯清晰的後端服務項目，實現了“寫較少代碼完成大部分工作”的目標，讓個人開發者也能輕鬆承擔團隊級別的任務。同時也正在重新定義軟件開發的效率邊界：
- 開發角色轉變：工程師更側重架構設計和質量把控。
- 敏捷度提升：原型開發週期從周級縮短至天級。
- 知識沉澱：AI 生成的標準化代碼更易維護和迭代。
