前言
在完成了基础认知与工具掌握后，我们进入最终挑战：构建一个具备真正商业价值的复杂应用。这次我们要打造的不是一个玩具项目，而是一个集成了前沿 AI 技术、完整支付体系及用户管理系统的图像生成平台。
该项目将综合运用全栈技能：从 v0.dev 的界面设计，到 Supabase 的后端支持；从 Replicate 的模型调用，到 Stripe 的支付流程；再到 Vercel 的生产环境部署。完成它，意味着你具备了将创意转化为现实产品的能力。
一、项目架构设计与技术选型
规划阶段完成后，正式进入技术实现环节。我们将借助 AI 编码助手，将传统开发中耗时且依赖经验的架构设计，转化为高效的人机协作过程。
1. 利用 AI 助手生成技术架构
接下来的代码生成将以核心生产力工具 Cursor 为依托。它能理解并索引整个项目的代码库，实现上下文感知极强的代码生成、重构及高层级架构规划。
我们将通过 Cursor 打开 TRAE SOLO 生成的代码项目，以结构化的方式向 AI 编码助手传递规划好的产品需求。
提示词模板
Cursor 的 AI 编码助手会基于现代全栈应用的最佳实践，迅速生成一份专业的架构建议和接口定义。
提示词中的 use Context7 表示启用 Context7（基于 MCP 的实时文档检索），从官方源拉取与当前技术栈及具体版本相匹配的最新文档与代码示例，并注入 AI 的上下文中，减少过时 API 或虚构接口带来的错误，提升生成结果的准确性与可用性。
@Web 命令用于指示 Cursor 启用网络搜索功能，获取与需求相关的最新信息并融入上下文，让生成的回答或代码更准确，更具时效性。
2. 技术栈选型
结合 AI 编码助手的建议与已有的技术基础，我们最终确定了项目的完整技术栈。除了读者熟悉的核心组件外，还包含几个关键的新工具或框架，具体如表所示。
| 技术 | 项目中的角色 | 说明 |
|---|---|---|
| Replicate | AI 模型的 API 服务 | 提供对 Nano Banana 等数千种开源 AI 模型的便捷、统一的 API 调用服务 |
| Next.js | React 框架 | 基于 React 的开源框架，支持服务端渲染（SSR）和静态网站生成（SSG），提升应用性能与 SEO 表现 |
| TypeScript | 编程语言 | JavaScript 的超集，提供静态类型检查，增强代码的健壮性与可维护性 |
| Tailwind CSS | CSS 框架 | 以工具类为主的 CSS 框架，使用大量现成的样式类在 HTML 中直接组合，即可快速构建响应式、美观的界面 |
| Supabase | 后端即服务平台 | 提供 PostgreSQL 数据库、用户认证、文件存储和边缘函数，作为应用的核心数据层 |
| Stripe | 支付处理平台 | 处理积分购买、订阅等商业支付流程，提供安全的支付基础设施 |
| Vercel | 部署与托管平台 | 与 Next.js 深度集成，提供全球边缘网络、自动化 CI/CD 和 HTTPS 证书管理 |
该技术栈的每个组成部分都经过精心挑选，旨在最大化独立开发者的生产力，使其能将精力完全聚焦于产品逻辑和用户体验的构建。
3. Replicate API 设计
接下来，我们借助 Cursor 规划应用与 Replicate 服务的通信接口。在 Next.js 框架中，API 路由（API Route）是服务端接口的具体实现形式，因此下文提及的'接口'本质上是 Next.js 的 API 路由，括号内为接口的访问路径（即前端调用该接口时需请求的 URL 地址，含请求方法）。根据 AI 编码助手的建议，我们设计了两个核心的 Next.js API 路由：任务启动接口（请求方法为 POST，访问路径为 /api/generate-image）和 Webhook 回调接口（请求方法为 POST，访问路径为 /api/webhook/replicate）。
3.1 任务启动接口
该接口作为前端请求的入口点，负责接收用户的文本描述（Prompt）、待处理的图片文件等输入参数。服务端会严格验证用户的身份信息和积分余额，确保用户有权限且有足够的积分余额来执行此次操作。验证通过后，接口将调用 Replicate API 启动一个异步的图像生成任务。
为明确前后端数据的交互格式，该接口的请求体与响应体定义如下：
响应体（Response Body）：同样是一个 JSON 对象，格式如下：
{"taskId":"uuid","predictionId":"string","status":"processing"}
其中，taskId 是 Supabase 数据库中创建的任务记录 ID，predictionId 是 Replicate 返回的预测任务唯一标识符，前端可以使用这两个 ID 追踪任务的执行状态。
请求体（Request Body）：设计为一个包含多个字段的 JSON 对象，格式如下：
{"taskType":"text_to_image"|"image_edit"|"image_fusion","prompt":"string","inputImages":["string",...],"modelConfig":{...}}
其中，taskType 字段用于区分不同的生成模式，prompt 用于存储用户的文本描述，inputImages 为图片 URL 数组，modelConfig 存储模型的具体配置参数。
3.2 Webhook 回调接口
这是一个完全被动的服务端接口，仅负责接收来自 Replicate 服务器的 HTTP POST 通知。当图像生成任务完成时（无论成功还是失败），Replicate 都会主动向预先配置好的 Webhook 地址发送一个包含任务结果的请求。
接口处理逻辑遵循严格的安全和业务流程：先验证接收到的请求是否真正来自 Replicate（通常通过签名进行验证），然后根据请求中携带的 predictionId 在数据库中匹配对应的任务记录并更新其状态；如果任务执行成功，接口还需要完成一系列后续操作——从 Replicate 临时存储服务器下载生成的图片，将其永久保存到我们自己的 Supabase Storage 中，同时扣除用户相应的积分。
该接口的前后端数据的交互格式定义如下：
- 响应体（Response Body）：接口处理完成后，返回简单的
200 OKHTTP 状态码，告知 Replicate 服务器已成功接收并处理了这次通知。
请求体（Request Body）：格式由 Replicate 官方定义，包含的核心字段如下：
{"id":"replicate_prediction_id","status":"succeeded"|"failed","output":["url",...],"error":"string","metrics":{...}}
其中，id 是预测任务 ID，status 表示任务执行结果，output 是生成的图片 URL 数组，error 记录失败原因，metrics 提供性能指标。
这种分离'任务发起'和'结果处理'的异步设计，是构建 AI 计算、视频转码、批量邮件发送等所有长耗时任务的行业标准模式。
