OpenClaw Vibe Coding小技巧:数据库设计规范,让AI不再凭空猜表

📌 让AI写前端代码前你知道要先搭骨架，可到了数据库设计阶段，你是不是又让AI”自由发挥”了？表结构混乱、字段冗余、关系不明——问题不在AI，在你跳过了数据库设计的规范流程。本文教你如何让AI陪你”专业地”设计数据库。

🎯 前置原则：别让AI”凭空猜表”

很多人在做全栈项目时，上来就让AI直接设计数据库。结果呢？不是漏了关键字段，就是表间关系一团乱麻。

正确姿势：先磨前端，再设计数据库。

如果你的项目涉及前端、后端和数据库，建议先打磨前端主要流程——明确用户操作、页面需要展示什么数据、业务对象都有哪些——再进行数据库设计。先搞清楚业务”长什么样”，再让AI帮你设计数据”怎么存”。

第一步：从业务流程中提取核心对象

数据库源于业务。不要问AI”我们数据库该有哪些表”，而是先梳理业务对象。不同项目类型的核心对象各不相同：

• 电商项目：用户、商品、订单、支付记录、收货地址
• 内容平台：用户、文章、评论、点赞、收藏
• 后台系统：用户、角色、权限、操作日志
• 预约系统：用户、服务项目、预约记录、时间段、门店

💡 技巧：如果前端已开发完成，让AI根据页面反推数据——注册登录页对应用户表，订单列表页对应订单表。如果前端还没做，从立项文档或功能说明推导，但要多跟AI讨论，确保不遗漏任何业务对象。

第二步：确认对象间的关系——数据库最容易翻车的一步

找到了对象，只是完成了第一步。表间关系没厘清，后续全是坑。

明确每一对对象之间的关系：

• 用户与订单：一对多，订单表存 user_id
• 文章与评论：一对多，评论表存 article_id 和 user_id
• 用户与角色：多对多，建用户角色关联表
• 订单与商品：多对多，建订单商品关联表

⚠️ 关键点：每设计一张表，都要让AI解释它的业务含义、表间关系类型、为什么这样设计。如果AI说不清楚，说明它也在”猜”——需要你纠正。

第三步：选择合适的数据库——别什么都Redis

数据库选型不是越炫越好，而是合适最重要：

• MySQL / PostgreSQL：常见业务项目首选（后台系统、SaaS工具、电商系统），关系型数据库扛大旗
• SQLite：本地小工具、轻量存储，免安装真香
• Redis：缓存、登录验证、限流——不是主数据库。没明确的高并发/缓存需求，别强行上

💡 技巧：让AI说明主数据库选型的原因。如果它推荐了Redis，也要解释必要性。如果解释不清，说明它在”跟风”而非”分析”。

第四步：设计表结构与字段规范

这是AI最容易放飞自我的环节。需要一套硬规范锁定。

遵循三大范式校验

• 第一范式：字段原子化，一个字段只存单一含义。例如手机号、地址分开存储，而不是一个字段存”手机号+地址”
• 第二范式：字段围绕表的主对象。例如订单表只存订单信息，用户信息通过 user_id 关联，而不是把用户地址和手机号直接存订单表
• 第三范式：字段间无冗余依赖。例如城市名称从城市表关联，不在用户表重复存储

⚠️ 血的教训：如果要做反范式设计（为性能做冗余），必须让AI说明原因。无理由的字段冗余就是在”埋雷”——你以为在优化，其实在制造数据不一致。

字段命名与核心规范

-- ✅ 正确示范
CREATE TABLE orders (
    id            BIGSERIAL   PRIMARY KEY,
    user_id       BIGINT      NOT NULL,
    order_no      VARCHAR(32) NOT NULL UNIQUE,
    total_fee     INTEGER     NOT NULL DEFAULT 0,
    status        VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_time  TIMESTAMP   NOT NULL DEFAULT NOW(),
    updated_time  TIMESTAMP   NOT NULL DEFAULT NOW(),
    deleted_time  TIMESTAMP
);

字段规范要点：

• 命名：英文下划线（user_name、created_time），不要拼音、不要驼峰
• 核心字段：id（主键）、created_time、updated_time——系统自动维护
• 敏感数据：密码存哈希值（password_hash），绝不存明文
• 软删除：不可物理删除的数据加 is_delete 字段
• 金额：用整数（以分为单位），或数据库精确数字类型（如 DECIMAL）
• 状态字段：明确枚举值，别让AI自己写”待处理””处理中””已完成”这样的模糊字符串

第五步：先出设计文件，再建表——规范套在AI头上

这是最重要的习惯，也是最容易被跳过的：

先让AI生成数据库设计文件（schema.sql或migration文件），提交到Git，再建表。

流程应该是这样的：

1. 梳理业务对象 → 让AI输出DB设计文件
2. 确认表关系、字段、范式 → 逐条核对
3. 无异议 → 执行建表
4. 后续字段变更 → 先改设计文件，说明原因，再操作

💡 设计文件就是数据库的”唯一事实来源”。没有它，AI随时可能”忘记”之前的设计决策，自己偷偷改字段。

第六步：制定实施计划，分步验证

最后一步：像前端骨架一样，让AI先搭好数据库基础结构，再逐步加业务。

实施计划：

1. 提取业务对象（用户、商品、订单…）
2. 确认表间关系（一对多、多对多…）
3. 选择数据库服务（MySQL/PostgreSQL）
4. 设计表结构和字段规范
5. 输出设计文件并提交到Git
6. 第一阶段：让AI搭建数据库基础结构（能连接、能建表、能插入/查询测试数据）
7. 第二阶段：开发接口和数据访问层
8. 第三阶段：对接前端业务功能

⚡ OpenClaw实操：用引导文件锁定数据库设计规范

理论讲完了，你现在遇到的问题是——这些规则怎么让AI一直记住？每次写Prompt都要重复一遍数据库规范吗？

答案是：不用。在 OpenClaw 中，你的 Agent 有一套 Bootstrap Files（引导文件）——它们就是 Agent 的”长期记忆”，每次启动新会话自动加载。你只需把数据库设计规范写进去，AI 就默认遵守。

在 AGENTS.md 中定义数据库设计规则（推荐）

AGENTS.md 是 Agent 的核心操作手册。在里面加一个”数据库设计规范”章节即可：

📋 数据库设计规范

业务对象提取：电商（用户、商品、订单、支付记录）、内容（用户、文章、评论、点赞）、后台（用户、角色、权限）、预约（用户、服务项目、预约记录）

表设计规范：命名用英文下划线；核心字段 id、created_time、updated_time 自动维护；软删除加 deleted_time；金额用整数（分为单位）或 DECIMAL

范式校验：1NF字段原子化，2NF围绕表主对象，3NF无冗余依赖。反范式设计必须说明原因

流程规范：先输出设计文件 → 提交Git → 核对通过 → 建表。字段变更先改设计文件，说明原因再操作

🔑 关键点：只要写进 AGENTS.md，AI 每次设计数据库都会自动遵守这些规则，再也不用每次手动啰嗦”注意数据库规范”。

在 TOOLS.md 中记录数据库连接信息

### 数据库
主库: ~/projects/my-app/db/migrations/
连接配置: DATABASE_URL=postgresql://localhost:5432/myapp

总结一句话：

用 AGENTS.md 锁定数据库设计规则，用 TOOLS.md 记住项目配置。 一次配好，AI永远”记得”你的数据库规范。

总结：先理业务，再让AI设计表

让AI设计数据库前，先把这些事做好：

1. 理业务 — 提取核心业务对象，别让AI凭空猜
2. 定关系 — 厘清表间关系，一对一、一对多、多对多
3. 选数据库 — MySQL/PostgreSQL优先，别强行上Redis
4. 定规范 — 三大范式 + 字段命名规则，AI不乱写
5. 出文件 — 先出设计文件再建表，数据库”有迹可循”
6. 分步走 — 先搭基础结构，再逐步加功能
7. 写进引导文件 — 规则写进 AGENTS.md，AI不会忘

你的OpenClaw已经准备好了。下次让它设计数据库时，先把规范立好，你会发现AI输出的表结构质量完全不同。

💡 更专业的AI Coding工具推荐：如果你的项目数据库复杂度较高，建议搭配 Claude Code、Codex CLI、Cursor 等专业 AI Coding 工具使用。这些工具在多文件编辑、数据库迁移管理、代码与表结构同步等方面有更强能力，配合 OpenClaw 的引导文件规则，效果翻倍。

本文由 OpenClaw 研习社出品，带你用好 OpenClaw，用好 AI。

📮 关注我们，获取更多 AI 工程实践和行业洞察。