用Claude 4小时搭完整SaaS：我的精确流程

三个月前，我花了三周做一套SaaS后台。上周，我用3小时42分钟搭了一个更复杂的——Claude当副驾驶。

差别不在"用没用AI"，而是一套可复现的工作流。它消除了大多数开发者跟AI协作时的卡点。

以下是完整步骤，含真实提示词。

问题：多数人用AI的方式错了

我看到的典型失误：

• 把整个代码库贴进Claude，指望它自己搞定
• 提示词模糊，比如"给我做个后台"
• 拆解问题前就扔给AI
• 不懂就复制粘贴AI输出
• 没让AI干它真正擅长的事

核心认知：AI是个不睡觉、不喊累、读过所有Stack Overflow的初级开发。但跟任何初级开发一样，它需要清晰的指令。

我的4小时框架

每个项目拆成4个阶段，各约1小时：

阶段一：蓝图（60分钟）
阶段二：脚手架（60分钟）
阶段三：核心逻辑（60分钟）
阶段四：打磨上线（60分钟）

逐阶段拆解。

阶段一：蓝图（60分钟）

写代码前，我先花一小时跟Claude做规划。这是最重要的阶段，也是多数人跳过的。

步骤1：定义问题

我用结构化提示词开场：

"我在做SaaS产品。需求如下：
产品：订阅数据分析后台
用户：想追踪MRR、流失率、LTV的SaaS创始人
数据源：Stripe API
技术栈：Next.js 14（App Router）、TypeScript、Prisma、PostgreSQL、TailwindCSS
时间线：今天需要可运行的原型

给我：
1. 完整数据库schema，含所有关系
2. API路由结构（REST端点）
3. 组件层级（需要哪些页面/组件）
4. 构建顺序（依赖图）
5. 可能踩的坑"

为什么有效：Claude生成具体计划。不再是"边做边看"，你有了路线图。

步骤2：生成数据库Schema

然后深入每个部分：

"基于你生成的schema，写：
1. 完整Prisma schema，含所有模型、关系、索引
2. 种子数据（每模型至少20条，要真实）
3. 如需迁移，给SQL

格式：单个`schema.prisma`文件，可直接复制。"

步骤3：API契约

"每个API路由给我：
1. 端点路径和HTTP方法
2. 请求体/参数类型（TypeScript接口）
3. 响应类型（TypeScript接口）
4. 认证要求
5. 功能简述

格式：TypeScript文件，所有类型导出。"

阶段一产出：完整规格——数据库schema、API类型、组件清单、构建顺序。手动做要2-3天。

阶段二：脚手架（60分钟）

让AI生成所有无聊的部分。

生成项目结构

"搭建Next.js 14项目：
• App Router（不用Pages Router）
• TypeScript严格模式
• TailwindCSS，自定义色值：[你的调色板]
• Prisma配置好PostgreSQL
• 认证用NextAuth.js（Google OAuth）
• 按阶段一的组件层级创建所有文件夹和空文件

给我可运行的命令和配置文件。"

生成类型定义

"基于阶段一的API契约，创建：
1. 所有TypeScript接口（请求/响应）
2. 共享的schema验证（Zod）
3. 前端用的类型工具函数

文件：`types/index.ts`"

生成API路由骨架

"为阶段一的每个端点创建：
1. 路由文件，含基础错误处理
2. 占位实现（返回mock数据）
3. 认证中间件

确保所有路由能通过基础测试（返回200）。"

阶段二产出：完整项目结构，所有文件就位，类型安全，路由可响应。还没业务逻辑，但骨架全了。

阶段三：核心逻辑（60分钟）

现在做真正重要的部分。一次一个功能，深度优先而非广度优先。

策略：端到端单功能

不要同时做所有API。选一个用户流程，打通到底。

示例：MRR计算流程

"实现完整的MRR计算流程：
1. 从Stripe API获取订阅数据的服务函数
2. 计算MRR、ARR、月度变化的逻辑
3. 存储计算结果的API端点
4. 显示MRR图表的前端组件（Recharts）
5. 数据获取的React Server Component

要求：
• 处理Stripe API分页
• 缓存策略（Redis或内存）
• 错误边界和加载状态
• 响应式设计"

关键：理解后再粘贴

Claude给代码时，我要求解释：

"解释这段代码的每一部分，然后再给我。"

这强制我理解，而不是盲目复制。如果不懂，就追问：

"为什么用`useEffect`而不是Server Component？"
"这个SQL查询会N+1吗？"
"如果Stripe API超时怎么办？"

测试驱动

每个功能后，让AI写测试：

"给刚才的MRR计算写单元测试：
• 正常情况
• 空数据
• Stripe API错误
• 时区边界（月末）"

阶段三产出：2-3个完整功能，端到端工作，有测试覆盖。不是半成品，是可演示的。

阶段四：打磨上线（60分钟）

最后阶段：让它能用，且看起来专业。

错误处理和边界情况

"检查整个代码库：
1. 所有API错误是否返回一致格式？
2. 前端是否处理所有错误状态？
3. 数据库操作有事务吗？
4. 敏感数据有日志泄露吗？

给需要修复的具体文件和代码。"

性能优化

"识别性能瓶颈：
1. 数据库查询有索引吗？
2. API响应能缓存吗？
3. 前端有过度渲染吗？
4. 大列表需要虚拟化吗？

优先改影响最大的。"

部署配置

"生成生产部署配置：
• Vercel（前端）
• Railway或Render（PostgreSQL）
• 环境变量清单
• GitHub Actions部署流程"

阶段四产出：可部署的应用，错误处理完善，性能可接受，有CI/CD流程。

让这套流程有效的关键原则

1. 上下文窗口管理

Claude的上下文有限。我的策略：

• 每阶段新开对话，带总结而非完整代码
• 用"基于我们讨论的schema"而非粘贴整个schema
• 文件级而非项目级请求

2. 提示词工程极简主义

复杂提示词模板是反模式。我的提示词结构：

• 角色：你在做什么（搭建SaaS后台）
• 约束：技术栈、时间、质量要求
• 输出：具体要什么（文件、格式、标准）
• 示例：如有复杂格式，给一个例子

3. 人在回路

AI写代码，我做决策：

• 架构决策（我定，AI执行）
• 代码审查（每段都读，不懂就问）
• 测试策略（我定场景，AI写用例）
• 部署判断（我选平台，AI给配置）

4. 快速失败

如果Claude给的方向不对，30秒内放弃，重述约束。不要试图"纠正"五轮对话。

真实时间分解

最近项目的实际计时：

• 阶段一（蓝图）：58分钟
• 阶段二（脚手架）：47分钟
• 阶段三（核心逻辑）：72分钟（超了，因为Stripe API文档坑）
• 阶段四（打磨）：35分钟
• 总计：3小时52分钟

对比我三个月前的项目：3周，其中一半时间在"搞清楚要做什么"。

何时这套流程不适用

诚实地说，不是所有项目都适合：

不适合：

• 全新算法（AI会幻觉复杂度）
• 严格合规场景（金融、医疗，需要审计追踪）
• 超大规模（百万用户，需要专门架构评审）

适合：

• 标准SaaS功能（CRUD、仪表板、支付）
• 内部工具
• MVP验证
• 已知模式的实现（换技术栈重写）

下一步

这套流程在进化。我最近实验的：

• 用Claude 3 Opus做阶段一（规划更强），Sonnet做阶段二三四（更快更便宜）
• 把常见模式做成可复用的提示词模板
• 用AI生成AI提示词（元优化）

核心洞察没变：AI是乘法器，不是替代品。你的工程判断越好，AI放大效果越强。

最危险的开发者，是以为"AI能搞定"就跳过思考的人。最危险的竞争对手，是用AI加速思考的人。

你是哪种？