教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载本篇文章以 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-supabaseProject 1和exam-management-expressProject 2并列适合学完两个主项目后想按自己的方向扩充作品集的学习者。从 Stage 2 索引 的说明看这个项目被官方描述为 Build a Midjourney-inspired AI image SaaS with generation workspace, gallery, payments, and admin dashboard即模仿 Midjourney 风格的 AI 图像生成 SaaS。该项目要求你从零构建一个包含三个子系统的现代 AI 图像生成 SaaS 平台子系统职责Public Website公开官网产品介绍、定价、FAQ、注册转化User Workspace用户工作台Prompt 输入、图像生成、作品画廊、积分、套餐、社区互动Admin Dashboard管理后台用户管理、任务管理、支付管理、内容审核、SaaS 指标、系统监控后端需要支撑的能力包括用户认证、图像生成任务、OSS 对象存储、积分与套餐支付、图像社交互动分享/点赞/评论/转发、运营数据监控。前置要求开始这个项目前官方要求你已熟悉以下内容对应链接已转换为仓库根目录相对路径前端页面设计与组件库UI 设计、现代组件库后端 API 设计与开发API 代码AI 辅助接口开发数据库基础与 Supabase从数据库到 Supabase支付集成Stripe 支付系统Git 工作流与部署Git 与 GitHub、Web 应用部署Zeabur学习目标完成本项目后你将具备以下能力阅读并理解一份真实 PRD从中提取开发任务清单基于 PRD 拆分模块并制定分步实施计划使用 AI 辅助搭建前端脚手架与后端 API逐个模块进行验证与迭代完成端到端集成把项目从本地能跑推进到可交付官方给出的整体节奏是四步流水线需求读 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做权限隔离参见 从数据库到 SupabaseDatabaseSupabasePostgreSQL存储用户、生成任务、订单、积分、社交互动等结构化数据OSS Storage图像等非结构化文件交给对象存储统一管理用 URL 而非二进制直接入库Payments PlansStripe 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 逐模块推进在脚手架之上按以下顺序逐个模块添加功能认证Authentication注册、登录、角色区分数据库Database建表、读写 API核心业务Core Business图像生成任务、结果存储OSS 存储OSS Storage图片上传与访问支付Payments套餐、积分、Stripe 集成社交互动Social Interaction分享、点赞、评论管理后台Admin Dashboard用户管理、任务管理、内容审核数据监控Data MonitoringSaaS 指标看板、系统监控每个模块完成后使用官方自检表验证检查项验证方法页面一致性页面数量、入口、功能是否与 PRD 匹配API 正确性请求参数、响应结构、状态处理是否合理认证隔离普通用户与管理员是否被正确隔离数据一致性数据库、OSS、支付、积分数据是否对齐演示就绪度能否向他人完整演示一条业务流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.4Public 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 支付系统 一章必须记住三条原则价格必须由后端决定——绝不相信前端传来的金额真正授权的是 Webhook不是success页面自己的数据库必须存储支付状态——不能只依赖 Stripe 后台。课程给出的最小可用支付链路是用大白话翻译就是用户点击按钮 → 前端向后端要支付链接 → 后端用 Stripe 密钥创建支付会话 → 用户去 Stripe 页面付款 → Stripe 通过 Webhook 通知支付真的成功了 → 后端再更新数据库。前端只管展示按钮、发起购买、跳转页面后端负责定价、创建会话、接收 Webhook、更新数据库。只要真实收钱就绝不要把最终定价权和付款后激活逻辑放到前端。集成时需要的环境变量至少包括这些变量同样适用于本项目STRIPE_SECRET_KEYSTRIPE_WEBHOOK_SECRETSTRIPE_PRICE_PRO_MONTHLY/STRIPE_PRICE_PRO_YEARLYAPP_URLSUPABASE_URLSUPABASE_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 工作流 把你的仓库推送上线并准备演示。交付物清单完成项目后需要提交以下内容可访问的线上演示链接源码仓库链接含 READMEPRD 文档核心页面截图首页、生成工作台、画廊、套餐页、管理后台60 秒演示视频覆盖 注册 → 生成 → 查看 → 管理后台README 至少应包含项目概述、核心页面说明、技术栈、本地启动步骤、环境变量列表。评分标准官方给出了五维评分标准可以作为你自查与打磨的清单维度基础要求进阶要求PRD 对齐页面、功能、数据结构基本匹配 PRD能清晰解释每个设计决策对应的 PRD 条款产品闭环注册 → 买积分 → 生成图片 → 查看历史 → 分享作品端到端跑通支付状态、积分余额、生成次数数据一致后台能力用户、任务、支付、内容管理可查看SaaS 指标看板和系统监控页功能完整工程完整性前端、后端、数据库、OSS、支付链路打通具备错误处理、空状态、加载状态交付质量可部署、可运行README 清晰、演示视频结构良好进阶要求尤其值得留意支付状态、积分余额、生成次数数据一致——这正是前文 Webhook 原则自己的数据库必须存储支付状态的直接体现而具备错误处理、空状态、加载状态则呼应脚手架阶段就要求的 mock 数据 UI 状态。参考资料UI 设计多产品 UI 设计LLM 与技能界面美化设计原型到项目代码现代组件库从数据库到 SupabaseLLM 辅助的 API 代码编写Git 与 GitHub 工作流Web 应用部署Stripe 支付集成赞分享教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载相关推荐Building a Go Traffic Data Analysis Platform with Easy-Vibe: From PRD to a Working Data PipelineBuilding a Go Traffic Data Analysis Platform with Easy Vibe: From PRD to a Worki教程文档如何扩展commonmark-java自定义节点类型与解析器开发如何扩展commonmark java自定义节点类型与解析器开发 commonmark java是Java语言中处理CommonMark Markdown 的教程文档Build a Travel Planning Agent Platform with easy-vibe: From PRD to a Structured Itinerary AI ProductBuild a Travel Planning Agent Platform with easy vibe: From PRD to a Structured教程文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考