教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载本篇指南是 Easy-Vibe 课程 Stage 2 的综合实战项目基于一份真实 PRD从需求分析、AI 辅助脚手架搭建到 Supabase 鉴权与数据库、AI 文案生成接口、Stripe 支付闭环与后台管理台完整构建一个可运行、可部署的 AI 营销文案 SaaS 产品。读完本文你将掌握读 PRD → 拆任务 → AI 生成三端页面 → 接入 Supabase/Stripe → 端到端联调 → 部署演示的全流程打法并理解支付链路中Webhook 才是支付成功的唯一真相等关键原理。项目总览三个子系统、一套后端本项目的产品形态是面向独立开发者、小团队和内容运营者的 AI 营销文案 SaaS。它不是单次调用模型的 Demo而是一套带登录、生成、历史、套餐、后台管理的完整产品由三个子系统构成子系统职责官网前台Public Website产品介绍、定价、FAQ、注册转化用户工作台User Workspace录入产品信息、生成文案、查看历史、升级套餐后台管理台Admin Dashboard用户管理、生成记录、支付数据、运营总览后端以 Supabase 承担数据库与鉴权Stripe 承担支付处理AI 模型负责营销文案生成。对应 PRD 中的系统总览架构PRD完整需求文档见 docs/zh-cn/stage-2/assignments/copywriting-platform-supabase/PRD.md中给出的技术选型建议为前端Next.js App Router、用户鉴权Supabase Auth、数据库Supabase Postgres、支付StripeAI 能力通过统一后端适配层对接第三方大模型 API。开始之前建议先掌握以下前置知识对应 Easy-Vibe Stage 2 先修章节前端页面设计与组件库UI Design、Modern Component Libraries后端 API 设计与开发API Code数据库基础与 SupabaseDatabase to Supabase支付接入Stripe Payment SystemGit 工作流与部署Git GitHub、Web App Deployment完成本项目后你将能够读懂真实 PRD 并提取开发任务清单用 AI 增量生成前端页面与后端 API用 Supabase 实现用户鉴权与数据库操作集成 Stripe 付费订阅搭建后台管理台并完成端到端集成。Part 1需求分析——先读透 PRD 再动手1.1 带着关键问题读 PRD打开 PRD 文档回答以下问题系统有几个入口每个入口覆盖哪些页面每个页面的核心功能是什么后端包含哪些模块和数据表套餐定价、支付流程、免费额度如何设计MVP 范围是什么第一版做什么、不做什么⚠️ 如果上述问题没有明确答案不要开始写代码。需求不清是返工最常见的原因。PRD 对上述问题给出了明确答案这里先梳理骨架3 套入口、10 个大页面官网前台 1 个官网首页www:/用户工作台 5 个登录页app:/login、注册页app:/register、生成工作台app:/generate、历史记录页app:/history、套餐页app:/billing后台管理台 4 个后台首页admin:/、用户管理admin:/users、生成记录admin:/generations、支付与订阅admin:/billing。3 类角色游客浏览官网、注册登录、注册用户生成文案、查看历史、管理套餐、管理员查看用户、生成数据、支付和运营数据。MVP 第一版必须包含官网首页、注册/登录、文案生成工作台、历史记录页、套餐页、支付/订阅能力、后台查看用户/生成记录/支付数据第一版不做团队协作、多语言翻译链路、复杂工作流编排、模板市场。1.2 确认系统架构基于 PRD 画出整体架构明确各模块的依赖关系PRD 同时定义了关键用户链路访客 → 官网 → 注册登录 → 工作台 → 提交生成任务 → 查看结果 → 保存历史 → 升级套餐 → Stripe 支付 → 套餐状态更新 → 后台运营查看以及关键状态流游客 → 注册用户免费用户 → 付费用户生成中 → 生成成功/失败订单处理中 → 支付成功/失败。这些状态流将在后续数据表设计和页面状态设计中反复用到。Part 2项目脚手架——用 AI 生成三端页面骨架2.1 生成前端页面使用 AI 生成所有页面的基本结构和 mock 数据。提示词参考来自原任务文档Based on the current PRD, help me generate a frontend scaffold for an AI marketing copywriting SaaS. Requirements: 1. Three entry points: www, app, admin 2. www: homepage, pricing, FAQ 3. app: login, register, generation workspace, history, plans page 4. admin: dashboard homepage, user management, generation records, payment orders 5. Only generate page structure with mock data, no real API integration 6. Style should look like a modern SaaS, not a classroom demo对照 PRD 的页面拆解脚手架阶段要确保每个页面承担明确职责首页负责转化、工作台负责结构化输入与输出管理、历史页负责内容复用、套餐页负责商业化、后台负责运营视角而不是一个输入框 一个结果框的单页工具。PRD 也建议借鉴真实营销 SaaS 的做法如 Jasper 强调营销团队场景与 CTA 转化、Copy.ai 把不同输出场景拆成清晰工作流让页面从视觉和结构上更像一个真实产品。2.2 精修核心页面脚手架就绪后聚焦打磨文案生成工作台Dashboard页面Continue refining the /dashboard page. This is an AI marketing copywriting workspace. Left side form fields: - Product name - One-line description - Target audience - 3 selling points - Distribution channels (website, WeChat Moments, Xiaohongshu, Douyin, email) Right side result area: - Main headline - Subheadline - CTA - 3 versions of short copy - Long-form copy Use mock data for interactions first. Requirements: - Loading state after clicking Generate Copy - Empty state for result area - Responsive layout, works on both wide and narrow screens这里的表单字段与 PRD 中的generation_records数据表结构一一对应产品信息、受众、渠道、语气结果区则对应文案生成的各类产出。加载态、空态、响应式这三点是 PRD 非功能要求的直接落地PRD 明确要求生成过程要有清晰加载和失败反馈首页和工作台都需要移动端可用。2.3 验证页面结构逐项检查三个入口路由相互独立www / app / admin页面数量与 PRD 一致3 套入口、10 个大页面Dashboard 表单区与结果区布局合理Mock 数据能展示基本 UI 状态卡住了怎么办脚手架阶段遇到问题可回看这些章节UI Design、Multi-Product UI Design、LLM Skills Interface Beautification、Design Prototype to Project Code、Modern Component Libraries。Part 3后端集成——Supabase、生成 API 与 Stripe3.1 接入 Supabase 登录Treat me as a beginner and guide me step by step through Supabase login integration. Help me complete: 1. Connect the project to Supabase 2. Implement registration, login, and logout 3. Redirect to /dashboard after successful login 4. Redirect unauthenticated users to /login when accessing /dashboard, /billing, /admin 5. Create a profiles table 6. Automatically create a record in profiles table after user registration 7. profiles table includes email, role, and plan fields Requirements: - Explain which files are being modified at each step - Dont hardcode API keys - Clearly mark any steps that require manual actions in the Supabase dashboard - Explain how to verify registration and login after completionSupabase 是什么从数据库到一站式 BaaS在 Database to Supabase 章节中Easy-Vibe 将 Supabase 定位为新一代 BaaSBackend as a Service以 PostgreSQL 为核心数据库在其上集成 Auth、Storage、Realtime、Edge Functions、Vector 等完整后端能力让开发者通过 SDK/API 直接调用而无需从零搭建和运维基础设施。本项目会用到的核心模块包括Table Editor可视化数据表编辑器无需写 SQL 即可像操作 Excel 一样查看和修改数据。注意public默认业务容器业务表都存这里与auth鉴权专用容器其users表自动存储所有注册用户信息不建议手动修改两个 Schema 的区别。SQL EditorSQL 语句执行器可以让大模型直接生成适配 Supabase 的 SQL粘贴到右侧输入区点击 RUN 即可建表或改表。Authentication开箱即用的注册、登录、密码重置、邮件验证支持邮箱密码与第三方 OAuth 登录所有用户数据自动同步到auth.users表。若不想每次注册都要邮件确认可在 Authentication → Sign In / Providers 中关闭 Confirm email 强制要求。Project Settings获取 Supabase URLhttps://xxx.supabase.co所有数据操作 RESTful 端点入口与 API Keys——anon 公钥受 RLS 严格限制、只能访问用户被授权的数据service_role密钥可绕过 RLS是必须放在服务端的高权限密钥泄露后需立即轮换。连接配置与环境变量Supabase 官方客户端通过 URL 与 anon key 初始化。Easy-Vibe 的 Supabase 演示项目展示了标准的客户端工厂写法见 database-supabase 章节import { createClient, type SupabaseClient } from supabase/supabase-js; // Optional client factory for demos: returns null when env is not set. export function maybeCreateBrowserClient(): SupabaseClient | null { const url process.env.NEXT_PUBLIC_SUPABASE_URL; const anon process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY; if (!url || !anon) return null; return createClient(url, anon); }在项目根目录创建.env文件并填入凭证NEXT_PUBLIC_SUPABASE_URLhttps://your-project.supabase.co NEXT_PUBLIC_SUPABASE_ANON_KEYyour-anon-key注册、登录与 profiles 表Supabase Auth 原生方法即可完成注册无需自己实现复杂的登录校验逻辑参考章节中的注册示例const { error: err } await supabaseClient.auth.signUp({ email, password, options: { data: { full_name: fullName || null, birthday: birthday || null, avatar_url: avatarUrl || null } } });登录成功后 Supabase 会自动创建会话并在后续所有数据库请求中自动携带鉴权信息。按任务要求还需要创建profiles表包含email、role、plan字段对应 PRD 中的数据表定义profiles ( id uuid primary key, email text, role text, plan text, created_at timestamptz )用户注册后自动在profiles表创建一条记录通常用数据库触发器或 Edge Function 监听auth.users的新行来实现。RLS用户只能看到自己的数据PRD 非功能要求用户历史记录只能自己可见这依赖 Supabase 的Row Level SecurityRLS。RLS 允许对数据表定义细粒度策略精确控制哪些用户能访问/修改哪些行。Supabase 提供auth.uid()函数直接返回当前登录用户的 UUID可写出user_id与当前用户 ID 一致才可见的策略create policy Users can view own generations on public.generation_records for select using (auth.uid() user_id);启用 RLS 后所有数据操作SELECT/INSERT/UPDATE/DELETE都会触发策略校验未通过任何策略的请求会被数据库直接拒绝。生产环境必须启用 RLS 并配置合理策略开发阶段可在init.sql中临时禁用但务必清楚这与生产要求相反。验证方式注册新账号 → 邮件确认或已关闭强制确认→ 登录 → 跳转/dashboard在 Supabase Authentication 中能看到新用户在 Table Editor 中能看到对应的profiles记录未登录访问/dashboard、/billing、/admin应被重定向到/login。3.2 接入生成 API 与数据库Treat me as a beginner and help me implement the core feature: generating marketing copy and saving it. Target behavior: 1. User fills out the form on /dashboard and clicks Generate Copy 2. Backend receives: product name, description, target audience, selling points, distribution channels 3. Backend calls the model to generate results 4. Page displays the generated results 5. Both input and output are saved to the database 6. User can view history on next visit Help me complete: - Create generation API /api/generate - Create generations table - Design input and output fields - Dashboard page reads current users history User experience: - Button loading state - Error message on generation failure - Empty state when no history exists After completion, explain: - Frontend page file locations - Backend API file locations - Where database write logic lives - How to test the complete generation pipelinePRD 为生成与历史模块定义了数据表与接口草案generation_records ( id uuid primary key, user_id uuid, input_payload jsonb, output_payload jsonb, channel text, tone text, status text, created_at timestamptz )其中input_payload/output_payload用jsonb存储结构化的输入产品名、一句话描述、目标受众、卖点、渠道与输出主标题、副标题、CTA、3 个短文案、长文案充分体现 JSON 类型对结构可变字段的灵活性——这也是 database-supabase 章节 中强调的对于嵌套结构、层次关系或字段可变的数据JSON 比关系表更直观灵活。接口草案中与本模块相关的部分方法路径说明POST/api/generations创建文案生成任务GET/api/generations/:id获取生成结果GET/api/history获取历史记录DELETE/api/history/:id删除历史记录实现要点后端统一通过大模型适配层调用第三方模型 API不要把模型 Key 暴露在前端生成的输入与输出同时落库Dashboard 读取当前用户的历史记录时依赖 RLS 保证只能看到自己的数据。完成后自查按钮加载态、生成失败的错误提示、无历史时的空态以及前端页面文件、后端 API 文件、数据库写入逻辑的位置。3.3 接入 Stripe 支付Treat me as a beginner and help me add the simplest viable Stripe payment to the project. No complex system needed — just get the basic payment flow working. Help me complete: 1. /billing page shows free and pro plans 2. User clicks upgrade → redirects to Stripe Checkout 3. After successful payment, returns to the site 4. Payment result saved to subscriptions table 5. Sync update to profile.plan field 6. Free users limited to 3 generations per day, pro users unlimited Implementation principles: - Get the main flow working first, dont worry about complex edge cases - Clearly document what needs to be configured in Stripe dashboard - Explain how to test the complete payment flow after completion先记住三条原则Stripe Payment System 章节开篇强调三条核心边界价格必须由后端决定——永远不要信任前端传来的金额真正授予权限的是 Webhook而不是success页面自己的数据库必须存储支付状态——不能只依赖 Stripe Dashboard。只要这三条边界正确将来从 Stripe 切换到 PayPal、支付宝、微信支付本质只是API 变了架构没变。最小可行支付链路Step 1在 Stripe Dashboard 创建 Product 与 PriceStripe 模型里Product表示你卖什么如Pro MembershipPrice表示卖多少钱、按什么周期收如$9.9/月、$99/年。后端创建 Checkout Session 时传的不是原始金额而是已有的price_id——Stripe 据此生成实际支付页、金额、币种与计费周期。最小配置建议在Test mode下操作不要一上来就在生产环境Product:Pro PlanPrice 1:pro_monthly记下其price_idPrice 2:pro_yearly记下其price_idStep 2准备环境变量至少需要以下环境变量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只能放在后端。前端只负责发起购买真正的密钥与定价逻辑应留在服务端。Step 3-4后端创建 Checkout Session前端跳转支付页后端收到请求后校验 plan 并映射到price_id用服务端密钥创建 Checkout Session 并返回session.url前端拿到链接后跳转到 Stripe 支付页。前端只发送plan / userId / email绝不发送最终扣款金额防止价格被篡改。Step 5Webhook 更新数据库最关键一步用户支付完成跳转回success页面并不意味着支付成功——success页面只是浏览器重定向成功任何人都可以直接访问该 URLWebhook 才是 Stripe 服务器发来的、带签名验证的官方通知。必须验证签名用STRIPE_WEBHOOK_SECRET验证通过后才更新数据库在billing_records表写入支付记录PRD 定义id, user_id, plan_code, billing_cycle, amount_cents, status, created_at同步更新profiles.plan字段按套餐执行额度控制免费用户每天限 3 次生成Pro 用户不限。对应需要监听的订阅事件事件含义通常处理checkout.session.completed首次订阅激活成功创建本地订阅记录invoice.paid自动续费成功延长到期时间invoice.payment_failed自动扣款失败标记风险状态并通知用户customer.subscription.deleted订阅取消撤销权限或标记过期常见坑位自查来自 Stripe 章节把success页面当支付成功应以 Webhook 为准让前端传金额存在价格篡改风险Webhook 路由被express.json()预处理签名验证需要原始请求体未做幂等处理Webhook 可能重试每次重试都加会员/加次数会出问题。本地测试使用 Stripe CLIstripe login、stripe listen把线上事件转发到本地 Webhook 地址验证checkout.session.completed是否成功到达并更新数据库。3.4 搭建后台管理台Treat me as a beginner and help me build a clean, functional admin dashboard. Admin-only access. Help me complete: 1. Only users with role admin can access /admin 2. Dashboard has 3 tabs: User List, Generation Records, Subscription Status 3. User List shows: email, plan, creation date 4. Generation Records shows: user, product name, channel, creation date 5. Subscription Status shows: user, plan, payment status Requirements: - Clean, clear interface - Use existing component librarys table, tab, and badge components - Explain how to set an account as admin after completion后台的核心是权限控制与数据聚合。权限上只有profiles.role admin的用户才能访问/admin可在数据库中将某个用户的role字段改为admin来完成设定。PRD 还定义了后台运营需要的指标视图新增注册用户数、日活跃生成用户数、文案生成总次数、生成成功率/失败率、套餐转化率、付费收入与退款率、高峰时段生成请求量并建议做基础监控模型调用成功率、接口平均耗时、支付回调成功率、数据库连接与慢查询、关键任务错误日志。这些指标对应 PRD 的接口草案GET /api/admin/overview后台总览、GET /api/admin/users用户列表、GET /api/admin/generations生成记录列表。卡住了怎么办后端开发阶段可回看Database to Supabase、API Code with LLM Assistance、Stripe Payment Integration。Part 4集成与上线4.1 端到端测试至少验证以下场景注册 → 登录 → 生成文案 → 查看历史 → 升级套餐管理员登录 → 查看用户数据 → 查看生成记录 → 查看支付状态部署前检查提示词Treat me as a beginner and help me check if the project is ready for deployment. Check focus: - Are environment variables complete? - Is the login callback URL correct? - Is the Stripe payment callback URL correct? - Are there missing loading, empty, or error states on any pages? - Does the README include setup and deployment instructions? Help me: 1. List items to fix, prioritized 2. Mark which ones must be fixed first 3. Explain deployment steps after fixes重点核对环境变量是否齐全NEXT_PUBLIC_SUPABASE_URL、NEXT_PUBLIC_SUPABASE_ANON_KEY、STRIPE_SECRET_KEY、STRIPE_WEBHOOK_SECRET、各price_id、SUPABASE_SERVICE_ROLE_KEY等Supabase 登录回调 URL格式通常为https://project-id.supabase.co/auth/v1/callback与 Stripe 支付回调 URL 是否正确各页面是否存在缺失的加载/空/错误状态。建议按照必须优先修复项 → 可后置优化项排序处理。4.2 部署将项目部署到公网环境。部署方法与注意事项参见 Git GitHub Workflow 与 Web App DeploymentEasy-Vibe 演示的 Zeabur 部署流程从 GitHub 或本地代码部署到公网让更多用户访问。部署后别忘了在生产环境重新配置 Webhook 端点与回调域名。交付物完成项目后提交可访问的在线演示链接源码仓库链接含 READMEPRD 文档核心页面截图首页、Dashboard、Billing、Admin60 秒演示视频覆盖注册 → 生成 → 支付 → 后台README 至少应包含项目概述、核心页面描述、技术栈、本地启动步骤、环境变量清单。评分标准维度基础要求进阶要求产品完整度首页、登录、Dashboard、Billing、Admin 均可访问首页文案与视觉风格像真实 SaaS业务闭环注册 → 登录 → 生成 → 查看历史端到端可用Free/Pro 权限差异清晰可见数据正确性生成结果与支付状态已保存到数据库有清晰的错误提示、空态与加载态鉴权与安全未登录用户无法访问受保护页面普通用户无法访问 Admin有基本的输入校验与服务端鉴权工程交付项目本地可运行、可公网部署README 清晰、演示视频结构完整 如果任务体量太大记住这条原则先让它跑起来再让它变好看Get it working first, then make it pretty。提交前最终检查清单首页、登录、Dashboard、Billing、Admin 页面完整用户可注册、登录、退出生成结果确实保存到数据库支付主流程可用管理员可查看用户、生成记录与支付状态项目已部署到公网参考资料UI DesignMulti-Product UI DesignLLM Skills Interface BeautificationDesign Prototype to Project CodeModern Component LibrariesDatabase to SupabaseAPI Code with LLM AssistanceGit GitHub WorkflowWeb App DeploymentStripe Payment Integration赞分享教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载相关推荐从 PRD 到上线基于 Supabase 与 Stripe 构建 AI 营销文案 SaaSeasy-vibe Stage 2 Project 1 全栈实战指南从 PRD 到上线基于 Supabase 与 Stripe 构建 AI 营销文案 SaaSeasy vibe Stage 2 Project 1 全栈实战指教程文档人工智能Vibe CodingTolaria 次级笔记窗口架构用完整 App 实例与 URL 参数检测取代独立 NoteWindow 壳层Tolaria 次级笔记窗口架构用完整 App 实例与 URL 参数检测取代独立 NoteWindow 壳层 本篇技术指南基于 Tolaria 的 ADR 0教程文档easy-vibe 实战项目用 Supabase Stripe 从 0 到 1 交付一个 AI 营销文案 SaaS 平台easy vibe 实战项目用 Supabase Stripe 从 0 到 1 交付一个 AI 营销文案 SaaS 平台 本篇技术指南是 Datawhal教程文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考