资料来源：火山引擎-开发者社区

本文作者：茉卷，TRAE 开发者用户

背景

之前我们分享过 基于 Seedream 4.0 模型的多图融合应用开发实战 一文，基于该项目的代码，本文继续展示项目集成数据库和订阅功能的实际开发过程和经验要点总结。过程包含：

使用 TRAE SOLO 模式设计 MVP 开发计划

使用 Supabase 实现用户注册登录功能

使用 Stripe （沙盒）实现订阅系统

在 TRAE 中，Supabase 和 Stripe 都可以轻松集成**（需到对应的网站注册）** 。

项目提示词 + 系统设计

我们先构建一个项目提示词，让 TRAE 先给出第一个设计。

请先阅读文档，该文档详细介绍了 DEMO 项目的概况。基于此 DEMO，您需要构建一个符合国际最佳实践的多图融合与自动审核的创意图像生成网站。

具体要求如下：

1. 技术架构：

2. 采用 Supabase 实现后台数据库系统

3. 设计完整的用户邮箱认证登录系统

4. 开发配套的后台管理系统

5. 支付系统：

6. 集成 Stripe 沙盒环境

7. 展示可订阅的服务套餐

8. 实现沙盒环境订阅功能

9. 确保设计可无缝切换至正式支付环境

10. 订阅方案：

11. 免费用户：每日 5 次图像融合生成机会

12. Pro 订阅用户：每日 10 次图像融合生成机会

13. UI 设计标准：

14. 遵循交互设计最佳实践

15. 界面简洁美观

16. 达到国际一流水平

17. 确保良好的用户体验

请确保所有功能模块的设计与实现均符合行业最高标准。

1.SOLO 初步生成技术文档

设计方案看上去不错，但是能不能用于生产，还有待检查。

2.关键参数处理机制确认

这里我们可以让 AI 检查该方案，找出安全隐患。

方案确实存在安全风险，这里需要研究 AI 的改进方案。

3.架构方案重构与优化

挑战： 新架构虽然在安全性和完整性方面有显著提升，但复杂度也相应增加，偏离了最小可行产品（MVP）的初衷。

上下滑动查看完整内容

基于生产环境的最佳实践，重新设计并优化整个系统部署方案。方案需采用生产版本标准，包含以下核心要素：

1. 系统架构设计

• 采用高可用分布式架构

• 实现服务无状态化

• 设计完善的容灾机制

2. 部署策略

• 实施蓝绿部署或滚动更新

• 配置自动化 CI/CD 流水线

• 建立多环境隔离机制（开发/测试/预发/生产）

3. 安全规范

• 实施最小权限原则

• 配置完善的监控告警系统

• 实现数据加密传输与存储

4. 性能优化

• 进行容量规划与压力测试

• 配置自动扩缩容策略

• 优化资源利用率

5. 运维保障

• 建立完善的日志收集系统

• 设计标准化运维流程

• 制定详细的应急预案

• 请确保方案符合行业标准的生产环境要求，并提供详细的实施步骤和技术选型建议。

新的架构

4.再次评估新方案

经过详细评估，新架构方案在当前资源条件下的符合度较低，需要进一步调整以适应实际开发能力。

5.MVP 开发计划制定

让 TRAE 制定 5 人团队 产出 MVP 软件计划。

上下滑动查看完整内容

制定一个基于 5 人团队每周标准工作 40 小时的软件生产版本实现计划，目标是交付一个最小可行产品(MVP)。计划需包含以下详细内容：

1. 版本目标与功能范围

• 明确定义 MVP 的核心功能需求和技术指标

• 划定版本边界和优先级排序的功能清单

• 确定交付标准和验收条件

2. 每周任务分配与里程碑

• 将开发周期划分为每周一个迭代周期

• 为每个迭代设定可交付的阶段性成果

• 制定详细的周任务分解表（含开发/测试/文档任务）

3. 人员分工与职责划分

• 明确 5 名成员的角色（如开发/测试/文档）

• 分配具体模块的开发负责人

• 制定交叉评审和协同工作机制

4. 代码提交与版本控制流程

• 建立 Git 分支管理策略（feature/bugfix/release 分支）

• 制定每日代码提交规范和代码审查流程

• 设置版本 tag 标记规则

5. 质量保证与测试安排

• 制定单元测试覆盖率要求（建议≥80%）

• 安排每周集成测试和冒烟测试时间点

• 规划用户验收测试(UAT)方案

6. 风险预估与应对方案

• 识别技术/进度/人员方面的主要风险

• 为每个风险制定缓解措施和应急方案

• 建立风险监控和上报机制

• 计划需确保：

• 每人每周工作量控制在 40 小时以内

• 开发/测试/文档任务均衡分配

• 关键路径任务优先保障资源

• 预留 10-15%缓冲时间应对突发情况

开发目标： 交付最小可行产品（MVP）。

上下滑动查看完整内容

AI 多图融合创作平台 - MVP 开发实施计划 ## 1. 版本目标与功能范围 ### 1.1 MVP 核心功能需求 核心价值主张： 为用户提供基于 AI 的多图融合创作服务，支持图片上传、智能融合和结果下载。

核心功能清单：

• 用户注册与登录系统

• 图片上传与预览功能

• AI 多图融合处理（基于火山引擎 SeeDream4）

• 融合结果展示与下载

• 基础用户配额管理

• 简单的用户界面和交互体验

1.2 技术指标要求

1.3 功能优先级排序 P0 - 必须实现（核心功能）：

1. 用户注册/登录

2. 图片上传功能

3. AI 图片融合处理

4. 结果展示和下载

5. P1 - 重要功能：

6. 用户配额管理

7. 基础错误处理

8. 响应式设计

9. P2 - 可选功能（MVP 后考虑）：

10. 用户历史记录

11. 高级参数配置

12. 社交分享功能

1.4 交付标准和验收条件 功能验收标准：

• 所有 P0 功能 100%完成并通过测试

• P1 功能至少 80%完成

• 单元测试覆盖率 ≥ 80%

• 集成测试通过率 ≥ 95%

• 用户验收测试通过率 ≥ 90%

• 技术验收标准：

• 代码审查通过率 100%

• 无严重安全漏洞

• 性能指标达到要求

• 部署文档完整

2. 每周任务分配与里程碑 ### 2.1 开发周期规划（8 周迭代） #### 第 1 周：项目启动与基础架构 里程碑： 完成项目初始化和基础架构搭建

• 完整的开发环境

• 基础项目结构

• CI/CD 流水线

• 数据库表结构

第 2 周：用户认证系统 里程碑： 完成用户注册、登录功能

• 用户注册/登录功能

• 用户会话管理

• 认证相关测试用例

第 3 周：图片上传功能 里程碑： 完成图片上传和预览功能

• 图片上传界面

• 文件存储功能

• 图片格式验证

• 上传进度显示

第 4 周：AI 融合核心功能 里程碑： 完成 AI 图片融合处理功能

• AI 图片融合功能

• 处理状态显示

• 错误处理机制

第 5 周：结果展示与下载 里程碑： 完成融合结果展示和下载功能

• 融合结果展示界面

• 图片下载功能

• 结果历史记录

第 6 周：用户配额管理 里程碑： 完成基础配额管理系统

• 用户配额管理系统

• 配额使用统计

• 配额不足处理

第 7 周：集成测试与优化 里程碑： 完成系统集成测试和性能优化

• 完整的端到端测试

• 性能优化报告

• 部署就绪的系统

第 8 周：用户验收测试与发布准备 里程碑： 完成 UAT 测试和生产发布准备

• MVP 产品发布版本

• 完整的用户文档

• 生产环境部署

2.2 每周工作量分配 工作量控制原则：

• 每人每周 40 小时标准工作时间

• 预留 10%缓冲时间（4 小时）

• 实际安排 36 小时具体任务

• 关键路径任务优先分配资源

3. 人员分工与职责划分 ### 3.1 团队角色定义 #### 角色 1：前端负责人（Frontend Lead） 主要职责：

• 前端架构设计和技术选型

• 核心页面和组件开发

• 前端代码审查和质量把控

• 与后端 API 接口对接

• 技能要求：

• React/TypeScript 专家级

• 3 年以上前端开发经验

• 熟悉现代前端工程化

角色 2：后端负责人（Backend Lead） 主要职责：

• 后端架构设计和数据库设计

• 核心 API 开发和第三方服务集成

• 后端代码审查和性能优化

• 生产环境部署和运维支持

• 技能要求：

• Node.js/Supabase 专家级

• 3 年以上后端开发经验

• 熟悉云服务和 API 集成

角色 3：前端开发者（Frontend Developer） 主要职责：

• UI 组件开发和页面实现

• 用户交互逻辑实现

• 前端单元测试编写

• 协助前端负责人完成开发任务

• 技能要求：

• React/JavaScript 熟练

• 1-2 年前端开发经验

• 良好的 UI/UX 理解能力

角色 4：测试负责人（QA Lead） 主要职责：

• 测试策略制定和测试计划执行

• 自动化测试框架搭建

• 集成测试和端到端测试

• 质量把控和缺陷管理

• 技能要求：

• 2 年以上测试经验

• 熟悉自动化测试工具

• 具备基础开发能力

角色 5：文档负责人（Documentation Lead） 主要职责：

• 技术文档编写和维护

• API 文档和用户手册

• 项目管理和进度跟踪

• 跨团队沟通协调

• 技能要求：

• 优秀的文档编写能力

• 项目管理经验

• 技术背景和沟通能力

3.2 模块开发负责人分配

3.3 协同工作机制 每日站会（Daily Standup）：

• 时间：每天上午 9:30，15 分钟

• 参与：全体团队成员

• 内容：昨日完成、今日计划、遇到问题

• 代码审查机制：

• 所有代码必须经过至少 1 人审查

• 核心功能代码需要 2 人审查

• 审查重点：代码质量、安全性、性能

• 技术分享会：

• 时间：每周五下午，1 小时

• 内容：技术难点分享、最佳实践讨论

• 轮流主讲，促进知识共享

4. 代码提交与版本控制流程 ### 4.1 Git 分支管理策略 分支结构：

main (生产分支)

├── develop (开发主分支)

│ ├── feature/user-auth (功能分支)

│ ├── feature/image-upload (功能分支)

│ └── feature/ai-fusion (功能分支)

├── release/v1.0.0 (发布分支)

└── hotfix/critical-bug (热修复分支)

分支规则：

• main: 生产环境代码，只接受来自 release 和 hotfix 的合并

• develop: 开发主分支，集成所有功能分支

• feature/*: 功能开发分支，从 develop 分出，完成后合并回 develop

• release/*: 发布准备分支，从 develop 分出，测试通过后合并到 main

• hotfix/*: 紧急修复分支，从 main 分出，修复后合并到 main 和 develop

4.2 代码提交规范 提交信息格式：

():

类型定义： - feat: 新功能 - fix: Bug 修复 - docs: 文档更新 - style: 代码格式调整 - refactor: 代码重构 - test: 测试相关 - chore: 构建过程或辅助工具变动 提交示例： feat(auth): add user registration functionality - Implement user registration form - Add email validation - Integrate with Supabase Auth Closes #123 ### 4.3 代码审查流程 Pull Request 流程： 1. 创建功能分支并完成开发 2. 提交 PR 到 develop 分支 3. 自动化测试执行 4. 指定审查人员进行代码审查 5. 审查通过后合并到 develop 6. 删除功能分支 审查检查清单： - [ ] 代码符合项目编码规范 - [ ] 功能实现符合需求 - [ ] 包含必要的单元测试 - [ ] 没有明显的性能问题 - [ ] 没有安全漏洞 - [ ] 文档已更新 ### 4.4 版本标记规则 版本号格式： v.. 标记规则： - 每个 sprint 结束创建 release 标记 - 生产发布创建正式版本标记 - 热修复创建 patch 版本标记 **标记示例：**bash # Sprint 版本 git tag -a v1.0.0-sprint1 -m "Sprint 1 release" # 正式版本 git tag -a v1.0.0 -m "MVP release" # 修复版本 git tag -a v1.0.1 -m "Critical bug fix" ## 5. 质量保证与测试安排 ### 5.1 测试策略 测试金字塔： E2E Tests (10%) ────────────── Integration Tests (20%) ──────────────────────── Unit Tests (70%) ### 5.2 单元测试要求 覆盖率目标： ≥80% 测试框架： - 前端：Jest + React Testing Library - 后端：Jest + Supertest 测试重点： - 核心业务逻辑函数 - 工具函数和帮助方法 - React 组件的关键交互 - API 接口的输入输出 **测试示例：**typescript // 前端组件测试 describe('ImageUpload Component', () => { test('should upload image successfully', async () => { // 测试逻辑 });

test('should show error for invalid file type', () => {

// 测试逻辑

});

});

// 后端 API 测试

describe('Auth API', () => {

test('POST /api/auth/login should return token', async () => {

// 测试逻辑

});

});

5.3 集成测试安排 测试时间点：

• 每周三：模块集成测试

• 每周五：端到端集成测试

• Sprint 结束：完整回归测试

• 测试内容：

• API 接口集成测试

• 前后端数据流测试

• 第三方服务集成测试

• 数据库操作测试

5.4 端到端测试 测试工具： Playwright

测试场景：

• 用户注册登录流程

• 完整的图片融合流程

• 错误处理和边界条件

• 跨浏览器兼容性

• 测试执行：

• 每日自动执行冒烟测试

• 每周执行完整 E2E 测试套件

• 发布前执行全面回归测试

5.5 用户验收测试(UAT) 测试阶段： 第 8 周

测试参与者：

• 产品经理

• 设计师

• 内部用户代表

• 测试内容：

• 功能完整性验证

• 用户体验评估

• 性能表现测试

• 兼容性确认

• 验收标准：

• 所有 P0 功能正常工作

• 用户满意度 ≥ 4.0/5.0

• 关键用户路径无阻塞问题

6. 风险预估与应对方案 ### 6.1 技术风险 #### 风险 1：第三方 API 集成问题 风险描述： 火山引擎 SeeDream4 API 集成可能遇到技术难题或服务不稳定

影响程度： 高

发生概率： 中等

缓解措施：

• 提前进行 API 调研和原型验证

• 准备备用的 AI 服务方案

• 与火山引擎技术支持建立联系

• 应急方案：

• 使用模拟数据完成前端开发

• 考虑其他 AI 图像处理服务

• 延后 AI 功能，优先完成基础功能

风险 2：性能瓶颈 风险描述： 图片处理和存储可能导致性能问题

影响程度： 中等

发生概率： 中等

缓解措施：

• 早期进行性能测试

• 实施图片压缩和优化

• 使用 CDN 加速图片访问

• 应急方案：

• 限制图片大小和数量

• 实施队列处理机制

• 升级服务器配置

6.2 进度风险 #### 风险 3：开发进度延迟 风险描述： 某些功能开发复杂度超出预期，导致进度延迟

影响程度： 高

发生概率： 中等

缓解措施：

• 每周进行进度评估和调整

• 预留 15%缓冲时间

• 优先保证 P0 功能完成

• 应急方案：

• 调整功能范围，推迟 P1 功能

• 增加工作时间或人员支持

• 重新评估和调整里程碑

风险 4：测试时间不足 风险描述： 开发延期导致测试时间压缩，影响质量

影响程度： 中等

发生概率： 中等

缓解措施：

• 开发过程中同步进行测试

• 自动化测试减少手工测试时间

• 提前准备测试用例和数据

• 应急方案：

• 延长测试周期，推迟发布

• 重点测试核心功能

• 发布后持续修复问题

6.3 人员风险 #### 风险 5：关键人员离职或请假 风险描述： 核心开发人员离职或长期请假影响项目进度

影响程度： 高

发生概率： 低

缓解措施：

• 建立知识共享机制

• 交叉培训和备份人员

• 完善的文档和代码注释

• 应急方案：

• 快速招聘替代人员

• 重新分配任务和职责

• 寻求外部技术支持

风险 6：团队协作问题 风险描述： 团队成员之间沟通不畅或技术分歧

影响程度： 中等

发生概率： 低

缓解措施：

• 建立清晰的沟通机制

• 定期团队建设活动

• 技术决策透明化

• 应急方案：

• 项目经理介入协调

• 技术专家仲裁决策

• 必要时调整团队结构

6.4 风险监控机制 风险监控指标：

• 每周进度完成率

• 代码质量指标（测试覆盖率、代码审查通过率）

• 团队士气和满意度

• 技术债务积累情况

• 风险上报机制：

• 日常风险：团队内部讨论解决

• 中等风险：项目经理协调处理

• 高风险：上报管理层，制定应对策略

• 风险评估频率：

• 每日站会：快速风险识别

• 每周回顾：风险状态更新

• Sprint 结束：全面风险评估

7. 项目保障措施 ### 7.1 工作量控制 工作时间管理：

• 严格控制每人每周 40 小时工作时间

• 避免长期加班影响团队效率

• 合理安排任务优先级

• 任务分配原则：

• 根据个人能力和经验分配任务

• 确保开发/测试/文档任务均衡

• 关键路径任务优先分配资源

7.2 质量保证 代码质量：

• 强制代码审查流程

• 自动化代码质量检查

• 定期技术债务清理

• 测试质量：

• 测试用例覆盖所有核心功能

• 自动化测试减少人工错误

• 持续集成确保代码质量

7.3 沟通协调 定期会议：

• 每日站会：15 分钟，同步进度和问题

• 每周回顾：1 小时，总结和计划

• Sprint 演示：2 小时，展示成果

• 文档管理：

• 及时更新技术文档

• 维护项目知识库

• 记录重要决策和变更

7.4 应急预案 进度延迟应对：

1. 重新评估任务优先级

2. 调整功能范围

3. 增加资源投入

4. 延长项目周期

5. 质量问题应对：

6. 立即停止相关开发

7. 分析问题根本原因

8. 制定修复计划

9. 加强相关测试

10. 人员问题应对：

11. 快速重新分配任务

12. 寻找临时支援

13. 调整项目计划

14. 必要时延期交付

8. 成功标准和验收 ### 8.1 项目成功标准 功能完成度：

• P0 功能 100%完成

• P1 功能 80%以上完成

• 所有功能通过验收测试

• 质量标准：

• 单元测试覆盖率 ≥ 80%

• 集成测试通过率 ≥ 95%

• 用户验收测试通过率 ≥ 90%

• 无严重安全漏洞

• 性能标准：

• 页面加载时间 < 3 秒

• 图片上传时间 < 10 秒

• 支持 100 并发用户

• 99%可用性

8.2 最终交付物 软件产品：

• MVP 版本的完整应用

• 生产环境部署包

• 数据库初始化脚本

• 文档资料：

• 用户操作手册

• 技术文档和 API 文档

• 部署和运维指南

• 测试报告

• 项目资料：

• 项目总结报告

• 经验教训文档

• 后续迭代建议

项目预计总工时： 1600 小时（5 人 × 8 周 × 40 小时）

实际安排工时： 1440 小时（预留 10%缓冲时间）

项目周期： 8 周

团队规模： 5 人

预期交付： AI 多图融合创作平台 MVP 版本

实际开发过程与问题解决

第一版核心功能清单：

用户注册与登录系统

图片上传与预览功能

AI 多图融合处理（基于火山引擎 SeeDream4）

基础用户配额管理

简单的用户界面和交互体验

第一版只有登录和创作页面。

1.用户注册功能检查

用户注册后，数据库中就会出现用户的数据表。

注意：注册成功后，supa base 会给邮箱发送一封邮件，只有点击邮件中的链接（Confirm your mail），2.1 图中的 “Last sign in at” 值才会出现具体的登录时间（才能通过邮箱和密码登录成功）

2.登录访问权限问题

在如下图的界面中，输入注册的邮箱和密码后（登录系统），出现 406 访问拒绝

fetch.ts:15 GET https://zouvkpyjgbnwbxplvfck.supabase.co/rest/v1/users?select=*&id=eq.c6ad03a3-15be-400a-9ade-e9eshdebafd2 406 (Not Acceptable)

查看 supabase 数据库中有用户数据，但是请求数据失败。

把数据库截图交给模型，让 TRAE 理解现状，给出分析。

TRAE 找到问题原因，并修改代码。主要是因为 Supabase 客户端 的初始化里少写一些参数。

上下滑动查看完整内容

HTTP 406 错误主要由以下原因引起：

• 认证头信息缺失 ：Supabase 客户端未正确传递认证令牌

• 会话状态异常 ：用户会话过期或无效

• RLS 策略配置错误 ：Row Level Security 策略过于严格

• 权限配置问题 ：数据库角色权限设置不正确

// 创建优化的 Supabase 客户端

exportconst supabase = createClient<Database>(

SUPABASE_CONFIG.url,

SUPABASE_CONFIG.anonKey,

{

auth: {

// 自动刷新令牌 autoRefreshToken: true,

// 持久化会话 persistSession: true,

// 检测 URL 中的会话 detectSessionInUrl: true,

// 确保会话存储在 localStorage 中 storage: typeof window !== 'undefined' ? window.localStorage : undefined,

// 设置会话刷新的阈值（在过期前 60 秒刷新） refreshThreshold: 60,

// 会话刷新间隔 refreshInterval: 30 * 60 * 1000, // 30 分钟 // 流程类型 flowType: 'pkce'

},

realtime: {

params: {

eventsPerSecond: 10

}

},

// 全局配置，确保所有请求都包含正确的头信息 global: {

headers: {

'Content-Type': 'application/json',

'Accept': 'application/json',

'Prefer': 'return=representation',

// 确保 API 密钥始终存在 'apikey': SUPABASE_CONFIG.anonKey

}

},

// 数据库配置 db: {

schema: 'public'

}

}

)

...

修改代码后，登录正常。

3.用户界面优化

去掉不必要的三方登录按钮（谷歌、twiter）

点击 “选择元素”，找到需要去掉的按钮并 添加到对话，在输入框中输入提示词。

TRAE 自动修改并完成。

在融合生图页面添加用户信息显示

提示词只要求增加了用户信息。但 TRAE 竟然自主规划了下拉菜单，支持登出，明确保持风格一致，还要进行一个自动测试。

TRAE 自动修改并完成。

4.多图融合功能调试

出现多图融合错误，把问题直接交给 TRAE，让 AI 分析。

TRAE 生成了一个错误分析文档：

TRAE 分析结论主要是 API Key 配置缺失导致融合功能失败。

这个错误的主要原因是 API Key 配置问题。通过配置有效的 SeeDream API Key，可以解决大部分网络请求失败的问题。同时，建议添加更完善的错误处理和配置验证机制，以提高系统的稳定性和可维护性。

检查环境配置文件（。env），确实是由于关键参数没有配置，出错时代码：

正确配置火山引擎关键参数。

图片上传与预览功能与融合生图功能完成。

意外发现

本来预期 AI 会按照已有方案执行：即图片先上传文件服务器，再获得 URL，通过 URL 的方式调用 SeeDream4。

意外的惊喜是 TRAE 使用了 直接上传图片 Base64 数据 到服务器的方式实现 （SeeDream4 支持 文件 URL 和 Base64 数据 的方式），这样就省去了文件上传对象存储的成本，爆赞👍

TRAE 能够自主使用最优设计是因为在项目开始阶段，它分析了已有代码。

5.功能完善与优化

“下载图片” 和 “重新生成” 按钮没反应

用之前的方法，把按钮发送给 TRAE，让它分析。

下载图片按钮有反应了，但是下载失败，跨域请求问题，TRAE 修复。

图片下载、重新生成 功能修改完成。

融合生图页面 切换出去再切换回来时，总是在刷新，打断生图任务

用 TRAE 提出需要解决的问题：

TRAE 自动修改并解决。

6.用户配额显示功能

需要实现用户配额的实时显示，确保数据库中的配额信息正确同步到前端界面。确认需求，让 TRAE 解决。

数据库中确认数据无误。

7.订阅系统完善

让 TRAE 确认 订阅功能，发现部分实现缺失，关键表不存在：

✅ user_quotas 表存在

❌ user_subscriptions 表缺失

❌ subscription_plans 表缺失

数据库中并没有 user_subscriptions 和 subscription_plans 表。

提出具体改进意见，让 TRAE 完善。

TRAE 生成了详细的订阅系统完善方案。

上下滑动查看完整内容

订阅系统完善计划文档

1. 项目概述

本文档旨在为 AI 多图融合创作平台的订阅系统提供完整的完善计划，包括数据库结构设计、UI 组件开发、Stripe 支付集成和订阅管理界面的实现。通过系统性的改进，为用户提供完整的订阅服务体验。

2. 数据库结构设计

2.1 subscription_plans 表设计

表名： subscription_plans

| 字段名 | 数据类型 | 约束 | 描述 |

|--------|----------|------|------| | id | UUID | PRIMARY KEY, DEFAULT gen_random_uuid() | 计划唯一标识 |

| name | VARCHAR(100) | NOT NULL | 计划名称（如：基础版、专业版、企业版） |

| description | TEXT | | 计划详细描述 |

| price | DECIMAL(10,2) | NOT NULL | 价格（月费） |

| currency | VARCHAR(3) | DEFAULT 'USD' | 货币代码 |

| billing_period | VARCHAR(20) | DEFAULT 'monthly' | 计费周期（monthly/yearly） |

| daily_limit | INTEGER | NOT NULL | 每日图片生成限制 |

| monthly_limit | INTEGER | NOT NULL | 每月图片生成限制 |

| features | JSONB | | 功能特性列表 |

| stripe_price_id | VARCHAR(255) | | Stripe 价格 ID |

| is_active | BOOLEAN | DEFAULT true | 是否启用 |

| sort_order | INTEGER | DEFAULT 0 | 排序顺序 |

| created_at | TIMESTAMP WITH TIME ZONE | DEFAULT NOW() | 创建时间 |

| updated_at | TIMESTAMP WITH TIME ZONE | DEFAULT NOW() | 更新时间 |

2.2 user_subscriptions 表设计

表名： user_subscriptions

| 字段名 | 数据类型 | 约束 | 描述 |

|--------|----------|------|------| | id | UUID | PRIMARY KEY, DEFAULT gen_random_uuid() | 订阅记录唯一标识 |

| user_id | UUID | NOT NULL, REFERENCES users(id) | 用户 ID |

| plan_id | UUID | NOT NULL, REFERENCES subscription_plans(id) | 订阅计划 ID |

| stripe_subscription_id | VARCHAR(255) | UNIQUE | Stripe 订阅 ID |

| stripe_customer_id | VARCHAR(255) | | Stripe 客户 ID |

| status | VARCHAR(20) | NOT NULL | 订阅状态（active/canceled/past_due/unpaid） |

| current_period_start | TIMESTAMP WITH TIME ZONE | NOT NULL | 当前周期开始时间 |

| current_period_end | TIMESTAMP WITH TIME ZONE | NOT NULL | 当前周期结束时间 |

| cancel_at_period_end | BOOLEAN | DEFAULT false | 是否在周期结束时取消 |

| canceled_at | TIMESTAMP WITH TIME ZONE | | 取消时间 |

| trial_start | TIMESTAMP WITH TIME ZONE | | 试用开始时间 |

| trial_end | TIMESTAMP WITH TIME ZONE | | 试用结束时间 |

| created_at | TIMESTAMP WITH TIME ZONE | DEFAULT NOW() | 创建时间 |

| updated_at | TIMESTAMP WITH TIME ZONE | DEFAULT NOW() | 更新时间 |

2.3 数据库关系设计

erDiagram      users ||--o{ user_subscriptions : has      subscription_plans ||--o{ user_subscriptions : defines      users ||--o{ user_quotas : has            users {          uuid id PK          string email          string username          timestamp created_at      }            subscription_plans {          uuid id PK          string name          decimal price          integer daily_limit          integer monthly_limit          string stripe_price_id          boolean is_active      }            user_subscriptions {          uuid id PK          uuid user_id FK          uuid plan_id FK          string stripe_subscription_id          string status          timestamp current_period_start          timestamp current_period_end      }            user_quotas {          uuid id PK          uuid user_id FK          string plan_type          integer daily_limit          integer daily_used          integer monthly_limit          integer monthly_used      }  
3.Progress UI组件设计
3.1 Progress组件规范
组件路径： src/components/ui/progress.tsx 功能特性：
支持百分比显示（0-100%）
平滑动画过渡效果
自定义颜色主题
响应式设计
可配置尺寸（small/medium/large） Props接口：
interface ProgressProps {    value: number; // 0-100的进度值    max?: number; // 最大值，默认100    size?: 'sm' | 'md' | 'lg'; // 尺寸    variant?: 'default' | 'success' | 'warning' | 'danger'; // 颜色变体    showLabel?: boolean; // 是否显示百分比标签    animated?: boolean; // 是否启用动画    className?: string; // 自定义样式类  }  
3.2 订阅进度条实现
使用场景：
1.使用量进度条： 显示当日/当月已使用次数占限制次数的百分比
2.订阅周期进度条： 显示当前订阅周期的时间进度
3.功能解锁进度条： 显示不同订阅等级的功能解锁状态 实现示例：
// 使用量进度条  const usagePercentage = (dailyUsed / dailyLimit) * 100;  <Progress     value={usagePercentage}     variant={usagePercentage > 80 ? 'warning' : 'default'}    showLabel={true}    size="md"  />  // 订阅周期进度条  const periodProgress = calculatePeriodProgress(currentPeriodStart, currentPeriodEnd);  <Progress     value={periodProgress}     variant="success"    showLabel={false}    size="sm"  />  
3.3 响应式设计规范
断点设计：
移动端（<768px）： 进度条高度4px，标签字体12px
平板端（768px-1024px）： 进度条高度6px，标签字体14px
桌面端（>1024px）： 进度条高度8px，标签字体16px 布局适配：
移动端：垂直堆叠布局，进度条占满宽度
桌面端：水平布局，进度条与标签并排显示
4.Stripe集成技术方案
4.1 Stripe配置和初始化
环境变量配置：
# Stripe配置  STRIPE_PUBLISHABLE_KEY=pk_test_...  STRIPE_SECRET_KEY=sk_test_...  STRIPE_WEBHOOK_SECRET=whsec_...  
Stripe客户端初始化：
// src/services/stripe.ts  import Stripe from 'stripe';  exportconst stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {    apiVersion: '2023-10-16',  });  exportconst stripePromise = loadStripe(process.env.STRIPE_PUBLISHABLE_KEY!);  
4.2 订阅创建流程
API端点设计：
// POST /api/subscriptions/create  interface CreateSubscriptionRequest {    planId: string;    paymentMethodId?: string;    trialDays?: number;  }  interface CreateSubscriptionResponse {    subscriptionId: string;    clientSecret?: string;    status: 'succeeded' | 'requires_payment_method' | 'requires_confirmation';  }  
实现流程：
1.创建或获取Stripe客户
2.创建订阅
3.处理支付确认
4.更新本地数据库
5.返回订阅状态
4.3 Webhook处理
支持的事件类型：
customer.subscription.created - 订阅创建
customer.subscription.updated - 订阅更新
customer.subscription.deleted - 订阅取消
invoice.payment_succeeded - 支付成功
invoice.payment_failed - 支付失败 Webhook处理器：
// POST /api/webhooks/stripe  export async function handleStripeWebhook(event: Stripe.Event){    switch (event.type) {      case'customer.subscription.updated':        await updateSubscriptionStatus(event.data.object as Stripe.Subscription);        break;      case'invoice.payment_succeeded':        await handlePaymentSuccess(event.data.object as Stripe.Invoice);        break;      // ... 其他事件处理    }  }  
4.4 订阅状态同步
同步策略：
1.实时同步： 通过Webhook即时更新订阅状态
2.定时同步： 每日检查订阅状态，处理异常情况
3.手动同步： 提供管理员手动同步功能
5.订阅界面UI/UX设计
5.1 订阅计划展示页面
页面路径： /subscription/plans 核心模块：
暂时无法在飞书文档外展示此内容
5.2 订阅管理页面
页面路径： /subscription/manage 核心模块：
暂时无法在飞书文档外展示此内容
5.3 支付流程界面
支付确认页面：
订阅计划确认
支付方式选择
优惠码输入
总价计算显示
服务条款确认 支付处理页面：
支付进度指示器
3D Secure验证处理
支付结果反馈
错误处理和重试机制
5.4 设计规范
色彩方案：
主色调：#3B82F6（蓝色）
成功色：#10B981（绿色）
警告色：#F59E0B（橙色）
错误色：#EF4444（红色） 组件样式：
卡片：圆角8px，阴影elevation-2
按钮：圆角6px，悬停效果
进度条：圆角4px，平滑动画
表单：简洁设计，清晰的错误提示
6.实施步骤和优先级
6.1 第一阶段：数据库基础设施（优先级：高）
时间估算： 2-3天
任务清单：
1.创建 subscription_plans 表迁移文件
2.创建 user_subscriptions 表迁移文件
3.设置表关系和索引
4.配置RLS（行级安全）策略
5.插入初始订阅计划数据
6.编写数据库操作函数 验收标准：
所有表结构正确创建
RLS策略正常工作
基础CRUD操作测试通过
6.2 第二阶段：Progress UI组件开发（优先级：中）
时间估算： 1-2天
任务清单：
1.创建Progress组件基础结构
2.实现进度条动画效果
3.添加响应式设计支持
4.编写组件文档和示例
5.集成到订阅状态显示中 验收标准：
组件在不同设备上正常显示
动画效果流畅
支持所有定义的Props
6.3 第三阶段：订阅管理界面（优先级：高）
时间估算： 3-4天
任务清单：
1.创建订阅计划展示页面
2.实现订阅管理页面
3.集成Progress组件显示使用统计
4.添加计划变更功能
5.实现响应式布局 验收标准：
页面布局美观，用户体验良好
所有功能模块正常工作
移动端适配完成
6.4 第四阶段：Stripe集成（优先级：高）
时间估算： 4-5天
任务清单：
1.配置Stripe开发环境
2.实现订阅创建API
3.开发Webhook处理器
4.集成支付流程到前端
5.实现订阅状态同步
6.添加错误处理和重试机制 验收标准：
支付流程完整可用
Webhook正确处理所有事件
订阅状态实时同步
6.5 第五阶段：测试和优化（优先级：中）
时间估算： 2-3天
任务清单：
1.端到端测试
2.支付流程测试
3.性能优化
4.安全性检查
5.用户体验优化 验收标准：
所有功能测试通过
性能指标达标
安全漏洞修复完成
7.风险评估和应对策略
7.1 技术风险
风险： Stripe API集成复杂度
应对： 提前进行API测试，准备备用支付方案
风险： 数据库迁移可能影响现有功能
应对： 在测试环境充分验证，准备回滚方案
7.2 业务风险
风险： 用户接受度不高
应对： 提供免费试用期，收集用户反馈
风险： 支付安全问题
应对： 严格遵循PCI DSS标准，定期安全审计
8.成功指标
技术指标：
支付成功率 > 95%
页面加载时间 < 2秒
API响应时间 < 500ms 业务指标：
订阅转化率 > 5%
用户满意度 > 4.0/5.0
月度活跃订阅用户增长 > 10%
通过以上完善计划的系统性实施，将为AI多图融合创作平台构建一个完整、稳定、用户友好的订阅系统。





  



接着让 TRAE 生成 user\_subscriptions 和 subscription\_plans 表 。

  


数据迁移命令，修改的是云端的 Supabase，修改后需要到数据库查看，如图所示红线部分，新增的 2 个表。

  







![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/0acdf433888246628885ead15f90d91a~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=l1LW7KFcnpWOmBaZOYxOyMWzwy4%3D)





![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/6792e4a581064e1bab1d0e59b725a309~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=N9A0gI8X0krtVbuWxgK4II4KMsU%3D)



  



接着生成整个方案代码（一个大活）。

  





执行中，AI 行动栏中发现它要实现后端代码（Stripe 相关密钥不能暴露到前端），我比较倾向使用 python FastApi 接口，于是让 TRAE 修改后端方案。这个方案应该在项目开始前就确认，前期没有明确后端方案，失误了。



  






![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/04b7ad2616a3497e9c01d363a753bae6~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=mYoec%2FFUZnto6FYo%2F3h8PiBN1tk%3D)





![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/a55e87f93e3c4a559e521b658482a162~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=O33oht0XFUAjccIJiuf%2BR4BR5I8%3D)



  



运行了很久之后，基本改完，图片融合生成后，出错，让 TRAE 继续分析。

  







![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/734255dc0de4460687e4d75bce770528~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=DOkt1xpG9O%2BNALjCdSIXrSbVcW8%3D)





![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/e1b7d650576043f7bcbb4ec9d93cfde8~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=ykfxr129AvMpCxG1X8jzWppCM58%3D)



  


AI 分析 LOG 显示 代码使用了错误的表 user\_usage\_records ， 而不是 user\_quotas 表，需要人为干预。

  






![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/21d9118a0e7541059e5c845c005a7cd2~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=%2BKzNhgv2L%2BlAJhpDwt9o22OHkwQ%3D)





![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/9d19d4671ea34c9c869241914dd03ecd~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=GBcUDTzJJ73jcofgofcMAyyq6RQ%3D)



  


代码中确实访问了错误的表（红：修改前，绿：修改后）。

  




![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/53ecb25f19bc4d849cb8f355ab39a2a2~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=1iVRmWUkt6J7JsSIJ%2B%2B4523dYec%3D)

  


最后检查，订阅功能完成。

  




![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/0286460cce9240ae95d2c04f69a12c04~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=bugQ7bsoAZh9u9Dhv%2FOp0wdxVXw%3D)





![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/be3b1409a7e34eecae9decdb11b92ec4~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=4JOGsOJmOtXo3og0vPLWZBMDU5k%3D)





![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/d2a7e622f331438c93cabff1338b980a~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=o%2B9HBGGI37KtS8S03bsML%2Bhm618%3D)



  




![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/5d851f9ae7cb46859f37f8b1c741e207~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=qeOK0sgcsoNYozW98oPmh5arlgI%3D)


**SOLO 中使用 Supabase  和 Stripe  的经验要点** 


  






**1. 架构与安全** 





  



**核心原则：** 在编码开始前，必须设计清晰的前后端架构。尤其需要规划如何安全地处理 Stripe 的密钥和 Supabase 的 RLS 策略。

  


所有敏感的 API 密钥必须置于后端环境中。绝对不要将 STRIPE\_SECRET\_KEY  密钥硬编码在前端代码中。

  







**2. 确保数据库状态与代码定义一致** 





  



**主动验证：** 即使你使用 TRAE 生成了数据表定义，在运行迁移后，也务必登录 Supabase 管理后台，亲自检查数据表、列、索引以及行级安全策略是否已按预期正确生成。

  


**一致性检查：** 在完成任何数据库迁移操作后，立即进行此验证，确保代码中的 TypeScript 类型定义与数据库中的实际结构保持一致。

  







**3. 妥善处理数据迁移失败** 





  



**常见问题：** 当执行 SQL 迁移命令反复失败时，通常是代码中的类型定义与数据库现有结构（如列类型、约束冲突）不一致导致的。

  


**标准解决流程：** 

* 分析错误日志：仔细阅读错误信息，定位冲突的具体表或列。* 重置开发环境：如果问题复杂难解，最有效的方法是在 Supabase 后台删除有冲突的数据表，然后重新运行迁移命令，让 TRAE 基于当前代码定义重建表结构。* 注意：此操作会清空表内数据，仅推荐在开发初期或测试环境使用。




![picture.image](https://p3-volc-community-sign.byteimg.com/tos-cn-i-tlddhu82om/e4399c54e45a4bc693aeee3d77ff304d~tplv-tlddhu82om-image.image?=&rk3s=8031ce6d&x-expires=1760508420&x-signature=ZdY2xJgdr8%2FZKB9dfgWHjfQzssY%3D)