三个月前，我花了三周做一套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加速思考的人。
你是哪种？
热门跟贴