Building a Modern AI Image Generation SaaS with Easy-Vibe: From PRD to Launch

• 教程
• 文档

本篇文章以 Easy-Vibe 课程 Stage 2 的综合实战项目《Modern AI Image Generation SaaS》为骨架，完整讲解如何基于一份真实 PRD，从需求分析、三端脚手架搭建、模块化迭代，到端到端联调与上线的全过程。读完本文，你将掌握"读懂 PRD → 拆分模块 → AI 辅助生成前后端 → 逐模块验证 → 交付可演示产品"的完整实战方法论，并能直接复用到你自己的 SaaS 项目上。

项目定位：Stage 2 的综合实战环节

在 Easy-Vibe 的 Stage 2 学习地图 中，前面的章节分别教会了你前端设计、组件库、数据库、API 设计、支付接入、Git 协作与部署等"零件"；而这个项目（位于 docs/en/stage-2/assignments/modern-landing-page/index.md）则是把零件组装成"能运行、能演示、能上线"的完整产品，属于官方标注的Extension 扩展项目，与copywriting-platform-supabase（Project 1）和exam-management-express（Project 2）并列，适合学完两个主项目后，想按自己的方向扩充作品集的学习者。

从 Stage 2 索引 的说明看，这个项目被官方描述为 "Build a Midjourney-inspired AI image SaaS with generation workspace, gallery, payments, and admin dashboard"，即模仿 Midjourney 风格的 AI 图像生成 SaaS。

该项目要求你从零构建一个包含三个子系统的现代 AI 图像生成 SaaS 平台：

后端需要支撑的能力包括：用户认证、图像生成任务、OSS 对象存储、积分与套餐支付、图像社交互动（分享/点赞/评论/转发）、运营数据监控。

前置要求

开始这个项目前，官方要求你已熟悉以下内容（对应链接已转换为仓库根目录相对路径）：

• 前端页面设计与组件库：UI 设计、现代组件库
• 后端 API 设计与开发：API 代码（AI 辅助接口开发）
• 数据库基础与 Supabase：从数据库到 Supabase
• 支付集成：Stripe 支付系统
• Git 工作流与部署：Git 与 GitHub、Web 应用部署（Zeabur）

学习目标

完成本项目后，你将具备以下能力：

1. 阅读并理解一份真实 PRD，从中提取开发任务清单
2. 基于 PRD 拆分模块，并制定分步实施计划
3. 使用 AI 辅助搭建前端脚手架与后端 API
4. 逐个模块进行验证与迭代
5. 完成端到端集成，把项目从"本地能跑"推进到"可交付"

官方给出的整体节奏是四步流水线：需求（读 PRD，提取页面/模块/数据模型/范围）→ 脚手架（用 AI 生成 www / app / admin 三个前端骨架）→ 迭代（逐个模块接入 API、认证、支付、监控）→ 上线（端到端测试、部署、准备演示）。

Part 1：需求分析

1.1 阅读 PRD

项目的第一步是打开 PRD 需求文档（原文档中的 PRD 链接指向 GitHub 上的PRD.md文件，当前仓库的该目录下只保留了index.md任务说明，PRD 内容需按原文档指引获取），并回答四个关键问题：

• 系统有几个入口？每个入口覆盖哪些页面？
• 每个页面的核心功能是什么？
• 后端包含哪些模块和数据库表？
• MVP 范围是什么？第一版做什么、不做什么？

::: warning 官方警告 如果上述问题没有清晰的答案，就不要开始写代码。需求不明确是返工最常见的根源。 :::

这一步的核心价值在于：先确认"做什么"，再讨论"怎么做"。对图像生成 SaaS 而言，MVP 通常需要明确的是：生成任务是否排队、积分如何扣减、生成结果存放哪里（OSS）、免费用户是否有生成次数限制——这些边界都必须在动手前界定清楚。

1.2 确认系统架构

基于 PRD 画出整体架构图，官方给出的参考如下（建议用自己的话重画一遍，以确认理解完整）：

结合仓库中的配套章节，这套架构在落地时可以进一步映射到具体技术选型（以下均为 Stage 2 课程 中已讲解的技术）：

• Auth：使用 Supabase Auth，配合行级安全策略（RLS）做权限隔离，参见 从数据库到 Supabase；
• Database：Supabase（PostgreSQL），存储用户、生成任务、订单、积分、社交互动等结构化数据；
• OSS Storage：图像等非结构化文件交给对象存储统一管理，用 URL 而非二进制直接入库；
• Payments & Plans：Stripe Checkout + Webhook，定价由后端决定，参见 Stripe 支付系统；
• Observability：管理后台提供 SaaS 指标看板与 API/DB/生成供应商监控。

Part 2：项目脚手架

2.1 用 AI 生成前端页面

使用 AI 生成所有页面的基础结构与 mock 数据。此阶段的目标是建立信息架构与路由，不做真实 API 集成。官方给出的提示词参考：

Based on the current PRD, help me generate a frontend scaffold for a modern AI image generation SaaS. Requirements: 1. Three entry points: www, app, admin 2. www: homepage, pricing, FAQ 3. app: login, register, generation workspace, gallery, plans, credits, community, artwork detail, profile 4. admin: dashboard homepage, user management, task management, content management, plan management, payment orders, operations config, SaaS metrics, system monitoring 5. Only generate page structure with mock data, no real API integration 6. Style reference: Midjourney — clean, modern, product-like

这里有两个值得注意的实战要点：

• 三入口路由独立：/（官网）、/app（用户工作台）、/admin（管理后台）应为三个互不干扰的应用入口。这与 多产品 UI 设计 中"一套设计体系服务多个产品端"的思路一致——官网重在转化、工作台重在效率、后台重在信息密度。
• 视觉风格参考 Midjourney：干净、现代、有产品感。要实现这种专业质感，直接手写样式容易"差一口气"，这正是 现代组件库 的用武之地——组件库把按钮、表单、弹窗、表格等基础件打磨好，你只需像搭乐高一样组合，把精力留给业务逻辑，同时天然获得一致性与响应式适配。

2.2 验证页面结构

脚手架生成后，逐项检查：

• 三个入口路由相互独立（/、/app、/admin）
• 页面数量与 PRD 一致
• 每个页面可访问、可跳转
• Mock 数据能展示基本 UI 状态（列表、空状态、表单等）

验证"页面数量与 PRD 一致"是防止 AI 自由发挥、页面越生越多的关键检查项。若发现 AI 生成的内容偏离 PRD，不要整页推翻，只需针对具体模块要求修正。

Part 3：迭代式开发

3.1 逐模块推进

在脚手架之上，按以下顺序逐个模块添加功能：

1. 认证（Authentication）：注册、登录、角色区分
2. 数据库（Database）：建表、读写 API
3. 核心业务（Core Business）：图像生成任务、结果存储
4. OSS 存储（OSS Storage）：图片上传与访问
5. 支付（Payments）：套餐、积分、Stripe 集成
6. 社交互动（Social Interaction）：分享、点赞、评论
7. 管理后台（Admin Dashboard）：用户管理、任务管理、内容审核
8. 数据监控（Data Monitoring）：SaaS 指标看板、系统监控

每个模块完成后，使用官方自检表验证：

3.2 三种角色并行

迭代期间，你需要同时扮演三个角色：

• 产品经理（Product Manager）：确认每个模块的功能与 PRD 一致
• 技术负责人（Tech Lead）：确认实现方案合理
• QA 工程师（QA Engineer）：确认功能真实可用

这种"一人三角"的切换是 vibe coding 时代个人开发者最核心的工程素养：AI 负责执行，你负责决策与验收。

3.3 模块落地要点（结合课程源码）

认证与数据库：Supabase Auth + RLS

认证、用户与任务数据建议直接使用 Supabase。在 从数据库到 Supabase 一章中，Supabase 被定位为 "Postgres-centric, one-stop backend platform"，在 PostgreSQL 之上集成了 Auth、Storage、Realtime、Edge Functions、Vector 等能力。普通用户与管理员隔离的实现依赖数据库层的行级安全策略（RLS）——这正好呼应自检表里的"认证隔离"检查项：权限边界最好收敛在数据库层，而不是散落在前端条件渲染里。

图像结果存储：OSS 对象存储

生成出的图片属于"尺寸不定、数量庞大"的非结构化文件，不应直接塞进业务数据库，而应交给对象存储服务。课程给出了两种取用方式（参见 database-supabase 章节 5.4）：

• Public URL（永久公开链接）：适合官网 Logo、作品画廊这类确定要公开且长期访问的资源；缺点是在生产环境有被"盗链"消耗带宽的风险。
• Signed URL（临时签名链接）：推荐优先使用。链接带安全标记和过期时间，过期即失效，还能防带宽滥用——课程原文特别举例"text-to-image applications generating time-limited image viewing links for users"，即文生图应用给用户生成限时图片查看链接，与本项目的场景完全吻合。

存储权限同样用 RLS 策略控制。课程示例（可参考 database-supabase 章节 5.4.1）展示了如何只允许登录用户把图片上传到以自己user_id命名的目录、且仅限图片类型：

CREATE POLICY "Allow authenticated uploads to avatars bucket" ON storage.objects FOR INSERT TO authenticated WITH CHECK ( bucket_id = 'avatars' AND auth.uid() = (storage.foldername(name))[1]::uuid AND (storage.extension(name) IN ('png', 'jpg', 'jpeg')) ); CREATE POLICY "Allow public read access to avatars" ON storage.objects FOR SELECT USING ( bucket_id = 'avatars' );

支付：后端定价 + Webhook 确认

支付模块是本项目中最容易做错、也最需要"架构正确"的一环。结合 Stripe 支付系统 一章，必须记住三条原则：

1. 价格必须由后端决定——绝不相信前端传来的金额；
2. 真正授权的是 Webhook，不是success页面；
3. 自己的数据库必须存储支付状态——不能只依赖 Stripe 后台。

课程给出的最小可用支付链路是：

用大白话翻译就是：用户点击按钮 → 前端向后端要支付链接 → 后端用 Stripe 密钥创建支付会话 → 用户去 Stripe 页面付款 → Stripe 通过 Webhook 通知"支付真的成功了" → 后端再更新数据库。前端只管展示按钮、发起购买、跳转页面；后端负责定价、创建会话、接收 Webhook、更新数据库。只要真实收钱，就绝不要把"最终定价权"和"付款后激活逻辑"放到前端。

集成时需要的环境变量至少包括（这些变量同样适用于本项目）：

• STRIPE_SECRET_KEY
• STRIPE_WEBHOOK_SECRET
• STRIPE_PRICE_PRO_MONTHLY/STRIPE_PRICE_PRO_YEARLY
• APP_URL
• SUPABASE_URL
• SUPABASE_SERVICE_ROLE_KEY

⚠️ 其中STRIPE_SECRET_KEY和SUPABASE_SERVICE_ROLE_KEY只能放在后端。

Stripe 的 Dashboard 配置顺序也值得注意：先在测试模式下创建一个Pro Plan产品，再挂上月付、年付两个价格；后端创建 Checkout Session 时不传裸金额，而是传已有的price_id。Dashboard 上真正要抄下来的不是产品名，而是price_id。

社交互动与数据监控

分享、点赞、评论、转发都落到数据库的社交互动表；管理后台的 SaaS 指标看板与系统监控则把用户数、任务数、生成成功率、支付转化等数据聚合展示，形成运营闭环。

Part 4：集成与上线

4.1 端到端测试

此阶段重点不是加新页面，而是跑通完整业务流。至少要验证：

• 注册 → 购买积分 → 生成图片 → 查看历史 → 分享互动
• 管理员登录 → 查看用户数据 → 查看任务统计 → 查看系统监控

如果出现 AI 生成内容偏离 PRD 的情况，不要整页丢弃，只需针对具体模块让 AI 修正。

4.2 部署

把项目部署到公开环境，确保：

• 环境变量全部配置完整
• 登录回调 URL 正确
• 支付回调 URL 正确
• 页面没有缺失的加载态、空状态或错误提示

部署方式可参考 Web 应用部署（Zeabur 等 PaaS 平台）：相比自己买服务器、配环境、传文件、维护进程，PaaS 平台帮你自动完成购买服务器、配置运行时、拉取代码、启动服务、监控存活等繁琐步骤。课程对比了四类平台：腾讯云 CloudBase（国内访问快、微信生态强）、Vercel（前端框架支持好）、Netlify（功能全面、表单与认证支持）、Zeabur（服务组合灵活，适合包含 Dify、n8n 等工具的复杂项目，约 $5/月免费额度）。对于本项目这种"前端 + 后端 + 数据库 + Webhook"的组合型应用，可以优先考虑支持多服务编排的平台。

部署完成后，结合 Git 与 GitHub 工作流 把你的仓库推送上线，并准备演示。

交付物清单

完成项目后，需要提交以下内容：

• 可访问的线上演示链接
• 源码仓库链接（含 README）
• PRD 文档
• 核心页面截图（首页、生成工作台、画廊、套餐页、管理后台）
• 60 秒演示视频（覆盖 注册 → 生成 → 查看 → 管理后台）

README 至少应包含：项目概述、核心页面说明、技术栈、本地启动步骤、环境变量列表。

评分标准

官方给出了五维评分标准，可以作为你自查与打磨的清单：

进阶要求尤其值得留意："支付状态、积分余额、生成次数数据一致"——这正是前文 Webhook 原则（自己的数据库必须存储支付状态）的直接体现；而"具备错误处理、空状态、加载状态"则呼应脚手架阶段就要求的 mock 数据 UI 状态。

参考资料

• UI 设计
• 多产品 UI 设计
• LLM 与技能界面美化
• 设计原型到项目代码
• 现代组件库
• 从数据库到 Supabase
• LLM 辅助的 API 代码编写
• Git 与 GitHub 工作流
• Web 应用部署
• Stripe 支付集成

• 教程
• 文档