独立产品数据模型小型 SaaS 也需要清楚的边界小型 SaaS 容易被误解成“不需要设计”。一个人开发、用户不多、功能很轻好像直接建几张表就能跑。可独立产品一旦开始收费、协作、同步和导出数据模型的边界就会变得很重要。早期偷懒后期会变成迁移成本。我不主张一开始就上复杂架构但我会认真区分账户、工作区、项目、资源、权限和订阅。边界清楚小产品才有生长空间边界混乱再极简的功能也会慢慢打结。一、先确定产品的核心对象假设做一个 AI 创意笔记工具核心对象可能是用户、工作区、项目、素材、生成记录、导出记录。不要把所有东西都塞进notes表。表少不等于简单语义清楚才是简单。erDiagram USER ||--o{ WORKSPACE : owns WORKSPACE ||--o{ PROJECT : contains PROJECT ||--o{ MATERIAL : stores PROJECT ||--o{ AI_RUN : generates PROJECT ||--o{ EXPORT_JOB : exports这张关系图不复杂但已经表达了关键边界用户可以拥有工作区工作区包含项目项目里有素材和 AI 调用记录。以后要做团队协作、项目迁移或用量统计都有位置可放。二、订阅和用量不要混进业务表收费产品一定会遇到额度、套餐、试用、续费和退款。如果把这些字段散落在用户表里后面会很难处理。订阅和用量应该是独立模块。CREATE TABLE subscriptions ( id TEXT PRIMARY KEY, workspace_id TEXT NOT NULL, plan TEXT NOT NULL, status TEXT NOT NULL, current_period_end TIMESTAMP NOT NULL ); CREATE TABLE usage_events ( id TEXT PRIMARY KEY, workspace_id TEXT NOT NULL, event_type TEXT NOT NULL, amount INTEGER NOT NULL, created_at TIMESTAMP NOT NULL );用事件记录用量比只保存一个余额字段更容易审计。用户问“为什么额度没了”你能查到每次 AI 调用、导出和生成。独立产品不一定要做重型账务系统但基本可解释性要有。三、AI 调用记录要能复盘AI 产品的数据模型里生成记录非常重要。至少要记录模板版本、模型版本、输入摘要、输出、用户是否采纳、错误信息和耗时。它既是质量分析依据也是成本控制依据。type AiRun { id: string; projectId: string; templateId: string; templateVersion: number; model: string; inputHash: string; outputPreview: string; accepted: boolean | null; latencyMs: number; tokenUsage: { input: number; output: number; }; };注意这里用inputHash和outputPreview而不是默认保存全部输入输出。创意素材可能敏感是否完整保存应由产品策略决定。能复盘和尊重隐私需要一起设计。四、删除和导出要从第一天考虑独立产品很容易忽略数据删除。用户删除项目时是软删、硬删还是进入回收站AI 调用记录是否一起删除导出文件是否保留这些问题越晚处理越麻烦。我的做法是给核心对象统一deleted_at并建立后台清理任务。导出则使用异步 job记录状态和下载有效期。data_lifecycle: soft_delete_days: 30 export_url_ttl_hours: 24 ai_run_retention_days: 90 hard_delete_scope: - materials - generated_outputs - exported_files小产品也要给用户安全感。能导出、能删除、能解释数据去向会让用户更放心地把真实工作放进来。五、总结独立产品的数据模型不必复杂但必须边界清楚。账户、工作区、项目、素材、AI 调用、订阅用量和数据生命周期都应该有自己的位置。小型 SaaS 的优雅不是表少而是每个表都知道自己为什么存在。这样的结构不会妨碍快速上线反而能让后续迭代更安静。