企业官网建设流程全解析

• 教程
• 文档

本篇指南是 Easy-Vibe 课程 Stage 2 的综合实战项目：基于一份真实 PRD，从需求分析、AI 辅助脚手架搭建，到 Supabase 鉴权与数据库、AI 文案生成接口、Stripe 支付闭环与后台管理台，完整构建一个可运行、可部署的 AI 营销文案 SaaS 产品。读完本文，你将掌握"读 PRD → 拆任务 → AI 生成三端页面 → 接入 Supabase/Stripe → 端到端联调 → 部署演示"的全流程打法，并理解支付链路中"Webhook 才是支付成功的唯一真相"等关键原理。

项目总览：三个子系统、一套后端

本项目的产品形态是面向独立开发者、小团队和内容运营者的 AI 营销文案 SaaS。它不是单次调用模型的 Demo，而是一套带登录、生成、历史、套餐、后台管理的完整产品，由三个子系统构成：

后端以 Supabase 承担数据库与鉴权，Stripe 承担支付处理，AI 模型负责营销文案生成。对应 PRD 中的系统总览架构：

PRD（完整需求文档见 docs/zh-cn/stage-2/assignments/copywriting-platform-supabase/PRD.md）中给出的技术选型建议为：前端Next.js App Router、用户鉴权Supabase Auth、数据库Supabase Postgres、支付Stripe，AI 能力通过统一后端适配层对接第三方大模型 API。

开始之前，建议先掌握以下前置知识（对应 Easy-Vibe Stage 2 先修章节）：

• 前端页面设计与组件库：UI Design、Modern Component Libraries
• 后端 API 设计与开发：API Code
• 数据库基础与 Supabase：Database to Supabase
• 支付接入：Stripe Payment System
• Git 工作流与部署：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 与 Stripe

3.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 - Don't hardcode API keys - Clearly mark any steps that require manual actions in the Supabase dashboard - Explain how to verify registration and login after completion

Supabase 是什么：从数据库到一站式 BaaS

在 Database to Supabase 章节中，Easy-Vibe 将 Supabase 定位为新一代 BaaS（Backend as a Service）：以 PostgreSQL 为核心数据库，在其上集成 Auth、Storage、Realtime、Edge Functions、Vector 等完整后端能力，让开发者通过 SDK/API 直接调用，而无需从零搭建和运维基础设施。

本项目会用到的核心模块包括：

• Table Editor：可视化数据表编辑器，无需写 SQL 即可像操作 Excel 一样查看和修改数据。注意public（默认业务容器，业务表都存这里）与auth（鉴权专用容器，其users表自动存储所有注册用户信息，不建议手动修改）两个 Schema 的区别。
• SQL Editor：SQL 语句执行器，可以让大模型直接生成适配 Supabase 的 SQL，粘贴到右侧输入区点击 RUN 即可建表或改表。
• Authentication：开箱即用的注册、登录、密码重置、邮件验证，支持邮箱密码与第三方 OAuth 登录，所有用户数据自动同步到auth.users表。若不想每次注册都要邮件确认，可在 Authentication → Sign In / Providers 中关闭 Confirm email 强制要求。
• Project Settings：获取 Supabase URL（https://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_URL=https://your-project.supabase.co NEXT_PUBLIC_SUPABASE_ANON_KEY=your-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 会自动创建会话，并在后续所有数据库请求中自动携带鉴权信息。按任务要求，还需要：

1. 创建profiles表（包含email、role、plan字段），对应 PRD 中的数据表定义：

   profiles ( id uuid primary key, email text, role text, plan text, created_at timestamptz )

2. 用户注册后自动在profiles表创建一条记录（通常用数据库触发器或 Edge Function 监听auth.users的新行来实现）。

RLS：用户只能看到自己的数据

PRD 非功能要求"用户历史记录只能自己可见"，这依赖 Supabase 的Row Level Security（RLS）。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 user's 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 pipeline

PRD 为生成与历史模块定义了数据表与接口草案：

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 比关系表更直观灵活。

接口草案中与本模块相关的部分：

实现要点：后端统一通过"大模型适配层"调用第三方模型 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, don't 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 章节开篇强调三条核心边界：

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

只要这三条边界正确，将来从 Stripe 切换到 PayPal、支付宝、微信支付，本质只是"API 变了，架构没变"。

最小可行支付链路

Step 1：在 Stripe Dashboard 创建 Product 与 Price

Stripe 模型里，Product表示"你卖什么"（如Pro Membership），Price表示"卖多少钱、按什么周期收"（如$9.9/月、$99/年）。后端创建 Checkout Session 时传的不是原始金额，而是已有的price_id——Stripe 据此生成实际支付页、金额、币种与计费周期。

最小配置建议（在Test mode下操作，不要一上来就在生产环境）：

• Product:Pro Plan
• Price 1:pro_monthly（记下其price_id）
• Price 2:pro_yearly（记下其price_id）

Step 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 5：Webhook 更新数据库（最关键一步）

用户支付完成跳转回success页面，并不意味着支付成功——success页面只是"浏览器重定向成功"，任何人都可以直接访问该 URL；Webhook 才是 Stripe 服务器发来的、带签名验证的官方通知。必须验证签名（用STRIPE_WEBHOOK_SECRET），验证通过后才更新数据库：

• 在billing_records表写入支付记录（PRD 定义：id, user_id, plan_code, billing_cycle, amount_cents, status, created_at）；
• 同步更新profiles.plan字段；
• 按套餐执行额度控制：免费用户每天限 3 次生成，Pro 用户不限。

对应需要监听的订阅事件：

常见坑位自查（来自 Stripe 章节）：把success页面当支付成功（应以 Webhook 为准）；让前端传金额（存在价格篡改风险）；Webhook 路由被express.json()预处理（签名验证需要原始请求体）；未做幂等处理（Webhook 可能重试，每次重试都加会员/加次数会出问题）。

本地测试：使用 Stripe CLI（stripe 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 library's 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 Deployment（Easy-Vibe 演示的 Zeabur 部署流程：从 GitHub 或本地代码部署到公网，让更多用户访问）。部署后别忘了在生产环境重新配置 Webhook 端点与回调域名。

交付物

完成项目后提交：

• 可访问的在线演示链接
• 源码仓库链接（含 README）
• PRD 文档
• 核心页面截图（首页、Dashboard、Billing、Admin）
• 60 秒演示视频（覆盖注册 → 生成 → 支付 → 后台）

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

评分标准

💡 如果任务体量太大，记住这条原则：先让它跑起来，再让它变好看（Get it working first, then make it pretty）。

提交前最终检查清单

• 首页、登录、Dashboard、Billing、Admin 页面完整
• 用户可注册、登录、退出
• 生成结果确实保存到数据库
• 支付主流程可用
• 管理员可查看用户、生成记录与支付状态
• 项目已部署到公网

参考资料

• UI Design
• Multi-Product UI Design
• LLM & Skills Interface Beautification
• Design Prototype to Project Code
• Modern Component Libraries
• Database to Supabase
• API Code with LLM Assistance
• Git & GitHub Workflow
• Web App Deployment
• Stripe Payment Integration

• 教程
• 文档