企业官网建设流程全解析

这个围绕 DeepSeek、Cursor、Devbox、Sealos 展开的零代码实战项目，第一篇文章没有急着生成登录页，而是先把数据库设计定下来：数据库实例跑在 Sealos 上，可视化建模用 DBeaver，建表 SQL 交给 DeepSeek 草拟，再由 Cursor 沉淀归档。这篇内容适合两类人：一类是刚接触 AI 辅助开发的零代码新手，想搞清楚数据库设计到底要干哪些事；另一类是把这套工具链用于实际项目开发、想少走弯路的人。看完你会发现，零代码项目省掉的是手写代码的时间，省不掉的是设计时的判断。

1. 为什么零代码项目要把数据库设计放在第一步

很多人拿到“用 AI 开发项目”的需求后，第一反应是打开 Cursor 或者找 DeepSeek 直接说“帮我做一个二手交易平台”。这个思路不能说错，但缺了一个关键前置条件：AI 生成的页面和接口，必须建立在“表结构已经确定”的基础上。如果连用户表、商品表、订单表都没想清楚，AI 生成的列表页和详情页就是空中楼阁，后面改起来会非常痛苦。

1.1 这个系列整体要完成的事

把标题里的工具串起来，其实就是一条完整的零代码开发链路：DeepSeek 负责对话式需求分析和 SQL 生成，Cursor 负责编辑与文档沉淀，Devbox 提供统一的云端开发环境，Sealos 是部署底座，数据库和应用都跑在上面，DBeaver 则作为数据库可视化客户端，连接、查表、画 ER 图。

这篇是系列的第 1 期，只解决“项目设计阶段的数据库设计”这一件事。也就是说，我们先不聊前端页面，也不聊后端接口，而是把整个项目的数据地基打牢。你在这篇文章里会拿到三样东西：一份完整的表结构设计方案、一套可以直接执行的建表 DDL、一个已经创建在 Sealos 上的空数据库实例，以及 DBeaver 里的可视化校验结果。

1.2 数据库先行的三个理由

第一个理由是：表结构就是产品需求的结构化表达。零代码不是没有代码，而是把代码生成交给 AI。但 AI 不能替你决定“用户有哪些字段、订单和商品是什么关系”，这些业务判断必须由人来完成。把数据库设计放在最前面，本质上是逼着我们把需求想清楚。

第二个理由是：数据库是后续所有生成内容的契约。AI 在生成登录页时，它需要知道用户表里是 phone 还是 email；生成商品卡片时，它需要知道价格字段是 decimal 还是 text；生成订单列表时，它需要知道状态字段的取值范围。表结构一旦定下来，后面 Cursor 生成的前端页面、DeepSeek 补的接口逻辑，都会围绕这套契约展开。

第三个理由是：数据库设计的返工成本最高，也最容易被新手忽略。改一个按钮样式几分钟就好，但改一张已经写入数据的表，可能要写数据迁移脚本、处理历史数据、更新所有关联接口。相比之下，花半天时间先把表设计好，是整个项目里性价比最高的投入。

1.3 零代码的边界在哪里

需要先说明一点：所谓的零代码，不等于全程不碰代码。在这个流程里，我们依然会执行 SQL、填写连接参数、确认字段类型，只是这些环节被工具大幅简化了。比如 Sealos 把数据库安装和运维变成了浏览器里的点击操作，DBeaver 把命令行 psql 的操作变成了图形界面，DeepSeek 把写 DDL 变成了自然语言对话。

所以更准确地说，这套流程是“低代码量的 AI 辅助开发”。对零基础用户友好，但前提是愿意理解一些数据库基础概念，比如主键、索引、外键、字段类型。这些概念在下文都会用大白话解释清楚。

2. 五个工具在数据库设计这关的分工

这个系列的工具组合不是随便拼的，每个工具都有明确的定位。在数据库设计这个阶段，有的工具要深度参与，有的可以先放在一边，但整体图景得先看清楚，否则后面衔接时会很混乱。

2.1 一张表看清五个工具的角色

2.2 为什么数据库实例放在 Sealos 而不是本地

不少人的第一反应是“直接在本地装个 MySQL 不就行了”。对于纯学习目的，本地安装没问题，但放到真实项目链路里，Sealos 有几个明显优势。

第一，Sealos 在浏览器里点几下就能创建一个独立数据库实例，不需要本地安装、配置环境变量、处理各种依赖。零代码项目面向的是不想折腾环境的人，这一点价值很大。第二，Sealos 给的是固定公网连接地址，后续应用部署在同一个云环境里，通过内网或公网访问都很方便，不用像本地数据库那样做内网穿透。第三，数据库生命周期可以按需管理，测试完直接删掉实例，不会污染本机，也不会出现“在我机器上是好的”这种环境问题。

2.3 为什么可视化客户端选 DBeaver

市面上数据库客户端不少，Navicat 也很好用，但它是付费软件。DataGrip 也要授权。而 DBeaver Community 版完全免费、跨平台、支持几乎所有主流数据库，而且自带 ER 图功能。对零代码项目来说，能用免费工具解决的需求，没必要掏钱。

实际操作中你会发现，DBeaver 的“元数据查看”“SQL 终端”“ER 图”三个功能，刚好覆盖数据库设计的三个关键动作：看表结构是否正确、执行建表脚本、验证表关系是否合理。这个组合对新手很友好。

3. 从需求到表结构：把二手交易平台拆成一张张关系表

工具选好了，接下来进入核心环节：把业务需求翻译成表结构。为了讲得具体，我拿一个内部叫“模拟项目X”的二手闲置交易平台作为例子。这是一个典型的极简电商场景，表不多，但覆盖了零代码项目里 90% 的设计要点。

3.1 从使用场景里梳理实体与关系

在做任何设计之前，先把用户故事列出来。这个平台的典型使用流程大致有九条：用户注册登录；用户发布闲置商品；商品属于某个分类；用户浏览和搜索商品；买家下单购买；买家填写收货地址；订单状态流转；买家确认收货后评价；管理员处理违规内容。

从这些场景里能提炼出九张核心表：用户表、商品分类表、商品表、商品图片表、订单表、订单项表、收货地址表、收藏表、评价表。额外加一张管理员操作日志表用于后台审计。

实体关系用文字描述是这样的：

• 用户和商品：一对多，一个用户能发布多个商品。
• 分类和商品：一对多，一个分类下挂着多个商品。
• 用户和商品：多对多，通过“收藏表”记录，一个用户收藏多个商品，一个商品被多个用户收藏。
• 用户和订单：一对多，一个用户产生多个订单。
• 订单和商品：多对多，通过“订单项表”拆开，一个订单包含多个商品，一个商品出现在多个订单里。
• 用户和地址：一对多，一个用户有多个收货地址。
• 订单和地址：在订单表里冗余保存一份地址快照，避免地址修改后历史订单看不到当时信息。

这个关系梳理过程非常关键，它决定后面建表的骨架。如果关系没理清，AI 生成再多 SQL 也是白搭。

3.2 核心表字段设计原则

表结构不能拍脑袋，每一张表的字段都要能回答“这个字段存什么、为什么需要它、谁会用它查询”。以最核心的三张表为例。

用户表设计的重点在登录标识和软删除：

商品表是信息量最大的一张表，设计时要注意“商品状态”和“价格精度”：

订单表则是整个设计里最需要谨慎的地方，它关联买卖双方、商品和地址快照：

订单项表要特别注意“商品快照”字段，因为商品可能下架、改价，历史订单必须保留当时的信息，所以不能直接关联实时商品表来展示。

评价表、地址表、收藏表的逻辑比较简单，核心就是“哪张表关联哪张表、哪些字段要加唯一约束”。收藏表里对 (user_id, product_id) 建唯一索引，防止同一用户重复收藏。

3.3 字段类型、主键、索引与约束的取舍

很多新手喜欢把字段全部设为 VARCHAR，觉得什么都能存，这其实是最危险的做法。字段类型是给数据设的“边界”，边界越清晰，后面出 bug 的概率越低。

主键我统一选择 BIGINT 自增，而不是 UUID。原因是自增主键占空间小、写入顺序好、对索引友好；业务唯一标识则单独用业务字段加唯一索引，比如 order_no、phone。如果你有非常强的分布式场景再考虑 UUID，对零代码小项目来说不必。

金额字段用 DECIMAL 而不是 FLOAT 或 DOUBLE。二进制浮点数存金额会产生精度误差，比如 0.1 + 0.2 在浮点里不是一个精确值。如果涉及支付对账，更稳妥的做法是直接用 BIGINT 存“分”，展示时再除以 100。我在模拟项目X里为了可读性先用 DECIMAL(10,2)，但如果你做的是涉及真实支付的系统，我强烈建议改成“分”。

外键的问题要专门说。数据库设计课会教你建物理外键，但实战项目里物理外键有时候反而碍事。它会在删除和修改时产生强约束，导致业务操作被数据库卡住，尤其在迭代快的项目里。我的实践是：小项目如果团队经验不足，可以用物理外键先保证一致性；但像模拟项目X这种灵活迭代的场景，我更推荐用逻辑外键加索引，由应用层保证关联完整性。

时间字段统一用 TIMESTAMPTZ，存储 UTC 时间，展示时按本地时区转换。千万别用字符串存时间，否则排序、比较、计算时间差都会变得无比痛苦。

4. Sealos 上创建数据库实例：浏览器里点出云数据库

设计稿写完了，下一步是让数据库真实存在。这一节是用 Sealos 创建 PostgreSQL 实例的完整过程。可以说，这是我用过的最顺滑的数据库创建方式之一，不需要命令行，不需要安装包，全程浏览器操作。

4.1 创建实例的具体操作步骤

第一步，打开 Sealos 平台并登录。如果还没有账号，先完成注册和基本的实名认证，这一步是为了使用平台资源。

第二步，进入“数据库”模块。不同版本的 Sealos 界面入口名称可能略有差异，但核心都是找“数据库”或“数据服务”相关的菜单项。

第三步，选择数据库引擎。我这次选的是 PostgreSQL，原因很简单：PostgreSQL 对复杂查询和 JSON 数据处理更友好，而且后续配合 AI 生成 SQL 时语法规范更严格。如果你更熟悉 MySQL 8.0，选 MySQL 也没问题，流程完全一样。

第四步，填写实例配置。需要配置实例名称、数据库名称、用户名、密码，然后选择 CPU、内存和存储容量。测试环境选最小规格就够了，比如 1 核 1G、10G 存储，等真正上线再扩容。不要把生产环境的规格直接拉满，纯粹是浪费钱。

第五步，设置网络访问策略。这一步容易被忽略。如果需要在本地用 DBeaver 连接，就要开启公网访问，或者是配置白名单把你的出口 IP 加进去。如果只允许后续应用从同一个 Sealos 环境内访问，就可以不开公网。

第六步，确认创建，等待实例状态变为 Running。创建时间一般在一两分钟内。创建完成后，控制台会给出连接信息，包括主机地址、端口、数据库名称、用户名。把这些信息复制保存好，接下来的 DBeaver 连接要用。

4.2 连接信息与 DATABASE_URL 的作用

Sealos 提供的连接信息通常长这样：

• 主机：pg-abc1234.api.sealos.io
• 端口：5432（PostgreSQL 默认）
• 数据库名：db_demo
• 用户名：demo_user
• 密码：你自己设置的密码

把这些信息拼成 DATABASE_URL 就是：

postgres://demo_user:密码@pg-abc1234.api.sealos.io:5432/db_demo

这个 URL 后面会直接用到应用配置里，无论是 Cursor 生成的代码还是以后部署的服务，都需要它来连接数据库。所以在设计阶段就把它整理到项目的 README 里，能省很多事。

有一点要特别提醒：Sealos 给的地址如果分内网和公网，一定要看清楚自己当前在哪一端。DBeaver 跑在本地电脑上，必须用公网地址；如果后续服务部署在和数据库同一套 Sealos 环境里，才适合用内网地址。我见过不少人拿内网地址在本地连接，结果一直超时，白白排查半小时。

4.3 测试环境下的成本与生命周期管理

Sealos 按资源实际使用计费，测试实例挂着不关也会持续产生费用。虽然最小规格的成本很低，但养成用完就关闭或删除实例的习惯仍然很重要。模拟项目X在测试阶段，我习惯在一天开发结束后把数据库实例暂停，第二天再启动。

另外，创建出来的只是一个空数据库实例，表结构还没有。空实例可以先用 DBeaver 连接测试，确认网络和权限没问题后，再把第三章设计的建表 SQL 执行进去。这样“网络通不通”和“SQL 对不对”两个问题就能分开排查，不会混在一起抓瞎。

5. DBeaver 连接与 ER 图核验：让表结构可见可查

数据库实例已经跑在 Sealos 上了，接下来要请出 DBeaver。这个工具相当于是数据库的“可视化驾驶舱”，既能执行 SQL，也能把表结构画成一张张关系图，方便逐张核对设计。

5.1 安装和环境准备

DBeaver 分社区版和企业版，免费功能完全够我们用。到官网下载对应操作系统的安装包，装好后打开，首页是一个数据库连接管理界面。第一次使用不需要配置什么，跟着下一步走即可。

有一个坑要先预告：DBeaver 第一次连接 PostgreSQL 时会提示下载驱动，如果网络环境不好可能下载失败。这种情况下，要么在驱动下载设置里切换镜像源，要么手动下载 PostgreSQL JDBC 驱动 jar 包放到 DBeaver 的驱动目录。这个坑我在第 7 节会详细展开。

5.2 新建连接时的关键配置

在 DBeaver 工具栏点“新建连接”，选择 PostgreSQL，然后填入 Sealos 提供的连接信息。主机、端口、数据库、用户名、密码逐一填好，先别急着保存，点一下“测试连接”。

如果测试提示缺少驱动，按提示下载即可。如果连接成功，会显示数据库版本和服务器信息。这时候再点“连接设置”里的“驱动属性”，把连接时区设为和数据库一致的时区，避免查时间时出现偏移。

如果是 MySQL 实例，几个常见的连接属性也要提前准备好：allowPublicKeyRetrieval=true，useSSL=false 或 sslMode=disable。这两个属性解决的是 MySQL 8.0 认证方式和 SSL 连接的问题，不设置可能直接报 “Public Key Retrieval is not allowed” 或 SSL 连接异常。

连接串参数没法一概而论，但思路是固定的：先在 DBeaver 里把网络配置、认证配置、时区配置这三关过掉，再谈后面的可视化。

5.3 用 ER 图和 SQL 终端反向验证设计

连接成功后，左侧导航栏会列出所有 schema 和表。刚建好的数据库还是空的，这时候有两种选择：一是直接在 SQL 终端里执行建表 DDL，二是先在 DBeaver 里手动建表再导出 SQL。我推荐前者，因为我们已经有完整的设计稿，直接用 SQL 终端批量执行最高效。

SQL 终端在 DBeaver 顶部菜单可以打开，把建表语句一条条粘进去执行。执行过程中如果报错，错误信息会直接告诉你哪一行有问题，改完重新执行即可。

表建好后，右键点击连接的“表”目录，选择生成 ER 图。DBeaver 会自动把表之间的外键关系画出来。如果你的表设计里没有物理外键，ER 图就不会显示连线，这时候要回头检查一下逻辑外键有没有对应的索引，索引是否在合理字段上。

ER 图的价值在于，它把“表结构设计稿”和“真实数据库”之间的落差直接暴露出来。比如发现某张表没有主键、某两个表之间应该有关联但没建索引、某些字段类型不对，都可以在图上一眼看出来。这一步相当于给数据库设计做了一次体检。

6. DeepSeek + Cursor 生成和审核建表 SQL 的方法

很多人以为 AI 写 SQL 就是一句话的事，其实要把 SQL 写对、写规范，提示词和审核流程比 SQL 本身更重要。这一节分享我在这套流程里沉淀下来的方法，核心是“让 AI 先给方案，再给代码，最后交叉检查”。

6.1 提示词不是聊天，而是需求文档

给 DeepSeek 的第一条提示词，我会这样写：

你是资深 DBA。我在设计一个二手闲置交易平台，核心流程包括：用户注册登录、用户发布商品、商品分类、买家下单、订单状态流转、买家填写收货地址、买家确认收货后评价、收藏商品。 请先不要直接输出全部建表 SQL，按以下顺序回答： 1. 列出你建议的实体清单以及实体之间的关系。 2. 针对每个表，列出关键字段及类型，标注主键、唯一索引、普通索引。 3. 等我确认表结构后，再一次性输出完整的 PostgreSQL 建表 DDL。 4. 要求：金额字段用 decimal，时间字段用 timestamptz，主键用自增 bigint，所有表都要有 created_at 和 updated_at，软删除字段统一命名为 is_deleted。

这个提示词有三个关键点。第一，给了角色设定，AI 回答会更专业。第二，限制了输出节奏，先出方案、确认后再出 SQL，避免大量不可读的内容。第三，写清了硬性约束，比如金额类型、时间类型、主键策略，AI 就不会自由发挥。

如果你不告诉 AI 这些约束，它很可能给你生成一个 UUID 主键、VARCHAR(255) 存所有字段、没有注释的表结构。不是它不懂，是你没把需求表达清楚。

6.2 AI 生成 SQL 后必须做的审查

AI 生成的 SQL 依然需要人工复核。我在项目里固定了一张检查表，每张表都要过一遍：

复核方法也很简单，把 AI 生成的 DDL 再贴回 DeepSeek，让它以审计视角检查一遍。你会发现 AI 自己发现的问题往往很准，比如漏了唯一索引、时间字段默认值缺失、某张表缺了软删除标志。这种“生成 + 审查”的循环，比一个人埋头检查快得多。

6.3 Cursor 里的落地习惯

SQL 确认没问题后，打开 Cursor，把这个项目建好目录。我习惯在项目里建一个 docs 文件夹，里面放两份文件：

• schema.sql：最终确认的建表 DDL，作为代码库的一部分。
• README.md：记录 DATABASE_URL、表结构说明、每个字段的含义和业务术语约定。

后续用 Cursor 做页面开发时，我会在对话里给 AI 加上一句“请先阅读 docs/README.md 中的数据契约，再生成前端字段”，这样 AI 就不会臆造出表里不存在的字段。这一步很重要，因为很多 AI 生成的页面之所以跑不通，就是因为前端用的字段名和后端表字段对不上。

还有一个小技巧：DBeaver 可以把表结构以 Markdown 或 SQL 形式导出，我通常会把导出的内容粘贴到 Cursor 的对话里，请它根据最新的表结构生成接口文档。这样整个开发链条里，数据库始终是唯一可信的数据源。

7. 这一轮数据库设计我踩过的坑与收尾记录

到这一步，模拟项目X的数据库已经从需求变成了运行在 Sealos 上的真实实例，表结构也通过了 DBeaver 的可视化校验。但整个过程并不是一帆风顺，有几个坑我认为值得记录下来，它们很典型，几乎每个做零代码项目的人都会遇到。

7.1 坑一：先让 AI 写 SQL，没给需求结构

我第一次尝试时，直接对 DeepSeek 说“帮我写二手平台的建表语句”，结果确实很快，但它生成了二十多张表，其中一半是我根本不需要的，比如“用户积分表”“商品浏览记录表”，字段设计也很随意。后来我把需求拆成实体关系描述，再让 AI 生成，质量立刻提升了一个档次。这个经历给我的体会是：AI 的 SQL 质量，完全取决于你给它的需求结构质量。

7.2 坑二：金额用 FLOAT，时间用字符串

这是最贵的两个坑。最早的表结构草稿里，price 字段被 AI 写成了 FLOAT，时间字段写成了 VARCHAR。当时看不出问题，直到我把价格数据插入后做 SUM 统计，发现结果和手算差了几分钱，才意识到是浮点精度问题。时间字段用字符串更是灾难，你没法按时间范围正确排序。这个坑用一句话总结就是：字段类型选错，代码再对也没用。

7.3 坑三：外键全部物理化，删数据时被卡死

第一版设计里我把所有逻辑关系都建了物理外键，看起来很正规，但实际运行时特别难受。比如管理员想删除一个违规分类，数据库会因为有商品关联而拒绝删除，业务上只能做标记下架，根本不需要物理外键来阻碍。后来我把物理外键全部去掉，只保留外键字段和索引，逻辑约束交给应用层，整个操作立刻顺畅了。

7.4 坑四：Sealos 公网连接不上

用 DBeaver 连接 Sealos 上的数据库时，第一次连接一直超时。排查了一圈才发现，我填的是内网地址。换成公网地址后还有其他问题，比如没有在安全策略里加白名单。这里分享一个排查命令，在终端里执行：

telnet pg-abc1234.api.sealos.io 5432

能连通，说明网络层没问题；连不通，就先检查地址类型、实例是不是 Running、白名单是否包含当前 IP。别一上来就怀疑 DBeaver 配置，先把链路一层层拆开。

7.5 坑五：DBeaver 驱动下载失败

DBeaver 第一次连接 PostgreSQL 时，驱动下载经常因为网络原因卡住。这时不要反复点测试，去驱动设置里换个镜像源，或者手动下载 jar 包放进 DBeaver 的驱动目录，重启应用就能解决。这个问题不难处理，但卡住时很劝退新手。

7.6 这轮下来的个人体会

数据库设计是整个零代码项目里最不“零代码”的环节，但它也是唯一一个用最少时间投入，换最长期稳定收益的环节。AI 可以把 SQL 写得很快，甚至写得比我手写还规范，但它不会替我做业务判断：这个字段要不要默认值、那个关系要不要唯一约束、金额用元还是分。这些判断最终还是回到设计师身上。

我把这些经验整理成了模拟项目X的 database-design-checklist，以后每做一个新模块，先从这张检查表过一遍。下一篇系列文章，我们会进入真正的开发阶段，到时候 Devbox 和 Cursor 就开始大显身手了。数据库这个地基已经打牢，后面无论是生成页面还是部署服务，都会轻松很多。