企业官网建设流程全解析

VOZEB PRO 是一款覆盖创作简报、视觉方向、物料规划到一致性生成与自动视觉复盘的 AI 创作工作台。它的 PostgreSQL 数据库结构由 59 张vozeb_pro_*表组成，配合一套清晰的 Repository 边界设计，让账号、AI 生成任务、商业订单和社区作品各归其位。本文带你快速看懂这套数据库设计的核心思路，无需深厚 SQL 基础也能理解。

先看全局：59 张表都在为 AI 创作服务

在 VOZEB PRO 中，你在 Agent 对话里输入一句话，背后就是一次数据库协作：会话写入creative_conversations，生成任务落库generation_tasks，产出的图片登记到creative_assets，计费流水写入point_records。一次完整的 AI 生图，大约会牵动十几张表。

好消息是：你几乎不需要直接面对这 59 张表。项目把所有建表语句集中在一个文件里——schema.ts，商业功能相关表在 schema-commercial-features.ts，官方文档也整理了完整的表清单：backend-database.mdx。

59 张表怎么分？按 6 大业务域拆解

面对 59 张表，最简单的记忆方式是按"业务域"分组，而不是逐表背诵。

身份与账号域：登录、会话与安全

这个域的特点是约束非常严格：users表上有 CHECK 约束保证管理员权限必须是数组、MFA 启用时密文不能缺失、协议同意五个留痕字段必须同时存在。这是"用数据库约束代替应用层校验"的典型做法。

AI 生成与任务域：工作台的核心引擎

• generation_tasks：文本、图片、视频、音频、Agent 与短剧合成的统一异步任务表，保存执行阶段、租约和恢复信息
• creative_conversations/creative_messages/creative_assets：Agent 会话、消息和稳定资产
• creative_run_events/vozeb_workflow_runs：SSE 事件流与工作流运行快照
• generation_logs/generation_log_assets：生成日志与结果资源
• canvas_projects/drama_projects：画布与短剧项目聚合快照

generation_tasks是全套表中最"重"的一张：除了基础状态，还带execution_phase阶段列、worker_id + lease_until租约字段，以及一个只覆盖"可自动推进"任务的部分索引——这样多实例部署时，Worker 才能安全地领取和恢复任务。

商业与支付域：订单、积分、优惠券和邀请

• billing_products/billing_orders/payment_transactions：商品、订单与支付流水
• billing_refund_jobs/billing_reconciliation_runs/billing_reconciliation_rows：退款补偿任务与账单对账
• point_records/daily_plan_point_wallets/quota_usage：积分流水、每日钱包与配额
• cdk_codes/coupon_templates/user_coupons/promotion_campaigns：CDK、优惠券与促销活动
• referral_programs/referral_rewards：邀请计划与奖励结算

订单表把日常价、活动优惠、券优惠和实付金额作为权威价格快照一次性落库，支付、退款和对账都只读这份快照——这是避免"改价纠纷"的常见设计。

作品与社区域：发布、审核与互动

published_works保存作品稳定身份，published_work_versions是不可变发布版本（含审核状态），published_work_cases统一承载举报与下架申诉，user_follows、user_blocks、user_notifications则维护关注、拉黑和互动通知。所有关系表都用复合主键保证"重复操作幂等"，点赞重复请求不会产生脏数据。

平台配置与可观测域

• app_settings：单例全局设置表，用 CHECK 约束锁死id = 'default'
• system_model_channels/object_storage_settings：模型渠道与外部存储配置（密钥只存密文）
• audit_logs：登录与后台操作审计
• prompts/announcements：提示词库与站内公告
• schema_migrations：记录已应用的结构版本

一个隐藏细节：表名统一加 vozeb_pro_ 前缀

代码里写的是users，数据库里的真实表名是vozeb_pro_users。映射逻辑集中在 postgres.ts 中：业务层继续使用简短的逻辑表名，执行层统一加前缀。这样做的好处是——即使同一个 PostgreSQL 实例里还跑着别的应用，VOZEB PRO 的数据也一眼可辨，索引和命名约束同样带前缀，不会撞名。

Repository 边界设计：业务代码不直接写 SQL

这是整套设计里最值得新手学习的一点。repositories.ts 中的createPostgresRepositories()把每张表包装成面向业务的 Repository 门面：

settings / users / sessions / points / cdk / announcements / prompts / generationLogs / billing / promotions / coupons / referrals / auditLogs / workPublications / workGovernance / workCommunity

它带来三条清晰的规矩：

1. 按实体查询，不整表加载：在线功能必须按用户、状态、时间窗或分页在数据库侧完成，禁止先读全表再在应用层筛选。
2. 事务内完成原子操作：积分消费、失败退款与管理员调整，在同一事务里完成用户行锁定、每日钱包结算和幂等流水写入。
3. 密钥只存密文：渠道 API Key、支付密钥、MFA Secret 在库中只有密文，管理接口不回传明文。

对新手来说，记住"Repository 是表与业务之间的守门人"就抓住了这套设计的精髓。

本地上手：从安装页初始化开始

想动手体验数据库结构？官方文档给出了最短路径：local-development.mdx。核心步骤只有三步：

1. 准备 PostgreSQL 16，创建vozeb_pro库和账号；
2. 在web/.env.local中配置DATABASE_URL与 32 字节加密密钥；
3. 启动 Web 后访问/install，在页面里初始化 schema 并创建首个管理员。

状态检查是只读的，表结构只由安装页的初始化操作显式创建。生产环境则建议用pg_dump做整库备份，配合后台"数据备份"页做业务数据导出，两者边界在后台页面上有明确提示。

总结：59 张表背后的三个设计原则

• 按业务域分表，而非按功能堆字段：生成、商业、社区各有独立表族，扩展时互不干扰；
• 约束下沉到数据库：CHECK、部分唯一索引、外键级联把一致性规则写进 Schema，应用代码更简单；
• Repository 收敛访问边界：参数化 SQL、定向查询和事务更新都封装在 Repository 内，业务层永远只面对稳定的接口。

理解了这三点，再去看 backend-database.mdx 中逐表的详细说明，59 张表就不再是一堆名词，而是一张清晰可导航的 AI 创作平台数据地图。