后端开发新革命：DeepSeek+Sponge 协作打造高效后端开发新范式

背景介绍

技术演进背景

随着 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 协同开发后端服务的全过程：

1. 需求分析：利用 DeepSeek R1 生成详细功能需求文档。

2. 数据库设计：依据需求生成 MySQL 表结构 DDL，并导入数据库。

3. 接口定义：先生成标准 CRUD API 的 Protobuf，再由 DeepSeek R1 生成自定义 API 的 Protobuf 的定义信息。

4. 服务代码生成：利用 Sponge 分别生成基础服务代码、CRUD API 代码、自定义 API 的 Protobuf 代码(只缺业务逻辑实现)。

5. 业务逻辑代码补全：通过 Sponge 内置 AI 工具自动生成业务逻辑代码，并由开发者进行整合与校验。

6. 调试验证：启动服务，借助 Swagger 等工具调试并验证 API 接口。

这种基于 Sponge 与 DeepSeek R1 协同开发可以快速构建出一个功能完善、逻辑清晰的后端服务项目，实现了“写较少代码完成大部分工作”的目标，让个人开发者也能轻松承担团队级别的任务。同时也正在重新定义软件开发的效率边界：

1. 开发角色转变：工程师更侧重架构设计和质量把控。

2. 敏捷度提升：原型开发周期从周级缩短至天级。

3. 知识沉淀：AI 生成的标准化代码更易维护和迭代。