来源：Claude Code Skills

用 Claude Code 从零构建 SaaS 产品

概述

从零开始构建一个 SaaS（Software as a Service）产品，是许多开发者和创业者面临的挑战。你可能有一个绝妙的想法，但从想法到可运行的产品之间，存在着巨大的鸿沟——需求不清晰、架构决策困难、代码质量难以保证、上线前的焦虑......

这篇指南将展示如何利用 Claude Code 的技能体系，把一个模糊的产品想法，一步步变成一个可部署的 SaaS 产品。我们不是在讨论如何写几行代码，而是覆盖从构思到上线的完整生命周期。

适合人群：

• 独立开发者 / 小团队，希望快速验证产品想法
• 有一定编程基础，但缺乏系统化工程经验的开发者
• 希望用 AI 辅助开发来提升效率的技术创业者

你将用到的核心技能：

• 头脑风暴（Brainstorming）
• 编写实施计划（Implementation Plan）
• 测试驱动开发（TDD）
• Git Worktrees 并行开发
• 完成前验证（Pre-completion Verification）
• 代码评审（Code Review）

阶段1：构思与规划

用「头脑风暴」技能把想法具体化

大多数项目失败不是因为技术问题，而是因为一开始就没想清楚要做什么。头脑风暴技能的核心价值在于：它强迫你在写任何代码之前，先把想法结构化。

实际操作方式：

向 Claude Code 描述你的产品想法，哪怕只是一句话。例如：「我想做一个帮助自由职业者管理发票的工具。」Claude 会引导你思考以下维度：

1. 目标用户是谁？ 不是「所有自由职业者」，而是具体到「月收入 5000-50000 元、同时服务 3-10 个客户的自由设计师」
2. 核心痛点是什么？ 不是「管理发票」，而是「每月花 3 小时手动整理发票，经常漏掉未付款的客户」
3. MVP 边界在哪里？ 头脑风暴最重要的产出之一是明确「第一版只做什么，不做什么」

头脑风暴不是天马行空的发散，而是有纪律的收敛。每一轮发散之后，都要做一次优先级排序，砍掉不属于 MVP 的功能。

用「编写实施计划」技能把需求变成路线图

头脑风暴产出的是「做什么」，实施计划解决的是「怎么做、按什么顺序做」。

编写实施计划技能会帮你产出一份结构化的开发路线图，包含：

• 技术栈选型：根据产品特点推荐合适的框架和工具
• 数据模型设计：核心实体及其关系
• 功能拆分：把大功能拆成可独立开发、独立测试的垂直切片（Vertical Slice）
• 开发顺序：按依赖关系排列，确保每完成一个切片，产品就多一个可体验的功能
• 里程碑定义：每个里程碑对应一个可演示的产品状态

关键原则：垂直切片，而非水平分层。 不要先写完所有 API，再写所有前端。而是：「用户注册 → 创建第一张发票 → 发送发票给客户」，每个切片都是 API + 前端 + 交互同时完成，用户可以立即体验。

阶段2：项目搭建

从第一天就建立 TDD 纪律

项目搭建不是「创建文件夹、安装依赖」这么简单。这个阶段最重要的决定是：从第一行代码开始就实践测试驱动开发（TDD）。

为什么要在项目最早期就引入 TDD？因为这时候代码量最少、架构最灵活，是建立良好习惯成本最低的时刻。如果你打算「以后再补测试」，那个「以后」永远不会到来。

具体步骤：

1. 初始化项目骨架：让 Claude Code 根据实施计划创建项目结构，包括测试框架配置
2. 编写第一个测试：在写任何业务代码之前，先写一个最简单的测试——比如「用户可以注册」
3. 红-绿-重构循环：
   • 红：测试失败（因为还没写实现）
   • 绿：写最少的代码让测试通过
   • 重构：在测试保护下优化代码结构

这个阶段看起来慢，但它为后续所有开发奠定了质量基础。每一个功能都有测试保护，你才敢放心地迭代和重构。

配置开发环境

• 设置 Git 仓库，配置 .gitignore
• 配置 CI/CD 流水线（即使最简单的——跑测试）
• 设置环境变量管理（开发 / 测试 / 生产）
• 配置 linter 和格式化工具

阶段3：核心开发

TDD 驱动每一个功能

进入核心开发阶段后，TDD 不再是「可选项」，而是你的主要开发节奏：

1. 从用户故事出发：「作为自由职业者，我想创建一张发票，以便发送给客户」
2. 编写验收测试：这个用户故事完成后，什么行为应该成立？
3. 拆分为单元测试：验收测试太大了，拆成小的单元测试逐个实现
4. 红-绿-重构：每个单元测试都走完整循环

让 Claude Code 帮你写测试时，要明确告诉它：「先写测试，确认测试失败，再写实现。」不要让它一次性生成测试和实现代码，那不是 TDD，那是「后补测试」。

用 Git Worktrees 实现并行开发

当你的 SaaS 产品有多个相对独立的功能模块时，Git Worktrees 技能可以大幅提升效率。

什么是 Git Worktrees？ 简单说，它允许你在同一个仓库中同时检出多个分支到不同的目录，每个目录都是独立的工作区。

实际应用场景：

假设你的发票管理工具需要同时开发三个功能：

• 发票创建与编辑
• 客户管理
• 支付状态追踪

传统方式是串行开发，一个一个来。使用 Git Worktrees，你可以：

1. 为每个功能创建独立的 worktree
2. 让 Claude Code 在不同 worktree 中并行开发不同功能
3. 每个功能独立测试、独立提交
4. 开发完成后合并回主分支

这不仅提升了速度，更重要的是每个功能的开发上下文是隔离的，不会互相干扰。这就是「并行代理调度（Parallel Agent Dispatch）」的实际应用——将大任务分解为可并行的子任务。

阶段4：质量保障

用「完成前验证」技能做最终检查

每个功能开发完成后，不要急着合并。完成前验证（Pre-completion Verification）技能会引导你做一次系统化的检查：

1. 功能完整性：需求中的每个点都实现了吗？有没有遗漏边界情况？
2. 测试覆盖：所有关键路径都有测试吗？测试真的在验证正确的行为吗？
3. 错误处理：网络超时、数据库连接失败、用户输入异常......这些情况都处理了吗？
4. 安全性：SQL 注入、XSS、CSRF、权限校验——基本的安全检查通过了吗？
5. 性能：有没有 N+1 查询？有没有不必要的大数据量加载？

很多开发者在「代码能跑」之后就认为功能完成了。完成前验证的价值在于，它帮你发现「能跑」和「能上线」之间的差距。

用「代码评审」技能做深度审查

自己写的代码自己很难发现问题，这是认知偏见。即使是 AI 生成的代码，也需要被严格评审。

代码评审技能提供两个视角：

• 请求代码评审（Request Review）：让 Claude 以严格审查者的身份检查你的代码，找出潜在问题
• 接收代码评审（Receive Review）：收到评审意见后，系统化地处理每一条反馈

重点关注：

• 架构决策是否合理
• 是否有过度设计或设计不足
• 代码是否易于理解和维护
• 是否符合团队约定的编码规范

阶段5：部署上线

最终验证与部署

部署不是「把代码推上去」这么简单。在上线之前，你需要：

1. 端到端测试：在类生产环境中跑一遍完整的用户流程
2. 环境配置检查：生产环境的环境变量、数据库连接、第三方服务 API Key 都配置正确了吗？
3. 回滚方案：如果上线后出问题，你能在 5 分钟内回滚吗？
4. 监控与告警：错误追踪（如 Sentry）、性能监控、关键业务指标告警
5. 数据备份：数据库备份策略是否就位？

完成前验证技能在这个阶段再次发挥作用——这次是从部署视角做最终检查。

为什么这套组合有效

这套技能组合的核心逻辑是分层保障：

每一层都在为下一层建立信心。头脑风暴确保你不会花三个月做一个没人要的东西；TDD 确保你不会在重构时引入 bug；完成前验证确保你不会带着明显的问题上线。

这不是瀑布式的线性流程，而是每个功能切片都走一遍的循环。一个典型的功能开发周期是：需求确认 → 写测试 → 写实现 → 验证 → 评审 → 合并。这个循环越快、越流畅，你的产品就迭代得越快。

常见误区

误区1：「先把功能做出来，测试以后再补」

这是最常见也是最致命的错误。「以后」从来不会到来。当你的代码库膨胀到一定规模后再补测试，成本是初期的 10 倍以上。而且没有测试保护的代码，你根本不敢重构，最终只能在烂代码上不断堆砌新功能。

误区2：「AI 生成的代码不需要评审」

恰恰相反。AI 生成的代码更需要评审，因为它可能看起来完美但实际上存在微妙的逻辑错误。AI 擅长生成「看起来对」的代码，但「看起来对」和「真的对」之间有很大差距。

误区3：「先做完整架构，再填充功能」

这是过度设计的典型表现。你不需要在第一天就设计出能支撑百万用户的架构。先用最简单的方式让一个功能跑起来，然后在真实使用数据的指导下逐步演进。

误区4：「一个人不需要代码评审」

独立开发者更需要代码评审，因为没有队友帮你把关。让 AI 做你的评审者，它不会碍于情面给你留面子——它会直接告诉你哪里有问题。

误区5：「跳过规划直接写代码更快」

短期看是更快，长期看是灾难。花一天做规划，可以省下一个月的返工。尤其是当你用 Claude Code 做规划时，成本几乎为零——你只需要花时间思考和确认，Claude 会帮你结构化。

下一步行动： 选择你最想构建的 SaaS 产品想法，从头脑风暴技能开始，按照这个指南一步步推进。你会发现，有了系统化的技能组合加持，从零到一的过程比你想象的要顺畅得多。

Source: Claude Code Skills

Build a SaaS Product from Scratch with Claude Code

Overview

Building a SaaS product is one of the most ambitious things you can do as a developer or founder. The journey from a blank terminal to a production-ready application involves hundreds of decisions, thousands of lines of code, and countless opportunities for things to go sideways. Claude Code, equipped with the right skills, transforms this process from a chaotic scramble into a structured, repeatable methodology.

This guide is for developers, technical founders, and indie hackers who want to build a real SaaS product --- not a toy demo --- using Claude Code as their AI-powered development partner. Whether you are a solo founder bootstrapping on weekends or a small team moving fast, this guide will show you which skills to activate, in what order, and why each one matters at each stage of the build.

By the end, you will have a clear playbook that takes you from "I have an idea" to "users are paying for this" with confidence, code quality, and speed.

Phase 1: Ideation & Planning

Every successful SaaS product starts with clarity. Before you write a single line of code, you need to know what you are building, for whom, and why it matters. This is where two foundational skills come into play.

Skill: Brainstorming

The Brainstorming skill turns Claude Code into a structured ideation partner. Instead of scribbling on a whiteboard alone, you engage in a guided exploration of your problem space. The skill prompts you to articulate the core problem, identify your target users, map out competitors, and pressure-test your assumptions.

Start by describing your idea in plain language. Claude will help you decompose it: What is the core value proposition? Who are the first ten users? What existing solutions do they use, and where do those solutions fail? The Brainstorming skill does not just generate ideas --- it forces you to confront the hard questions early, before you have invested weeks of development time.

A typical brainstorming session might produce a prioritized feature list, a rough user journey, and a set of hypotheses about what will make your product sticky. Capture all of this output. It becomes the foundation for everything that follows.

Skill: Implementation Plan

Once you have clarity on what to build, the Implementation Plan skill translates your vision into an actionable development roadmap. This skill generates a phased plan with concrete milestones, technology choices, database schema outlines, API endpoint definitions, and a recommended order of execution.

The key insight here is vertical slicing. The Implementation Plan skill does not produce a plan where you build the entire backend first, then the entire frontend. Instead, it slices the product into thin, end-to-end features that each deliver user value. Your first milestone might be "a user can sign up, see a dashboard, and create one resource." That single slice touches authentication, database, API, and UI --- and it gives you something you can demo and test immediately.

Review the plan carefully. Challenge the assumptions. Ask Claude to justify technology choices or suggest alternatives. Once you are satisfied, you have a living document that will guide the rest of the build.

Time investment: 2--4 hours for brainstorming and planning. This upfront investment will save you days or weeks of rework later.

Phase 2: Project Setup

With a plan in hand, it is time to set up your project. This is where discipline either gets established or abandoned, and the difference echoes through the entire lifecycle of your product.

Skill: TDD (Test-Driven Development)

Activate TDD from the very first commit. Not after you have built the core features. Not when you "have time to add tests." From day one.

The TDD skill enforces a red-green-refactor cycle: write a failing test that describes the behavior you want, write the minimum code to make it pass, then refactor while keeping tests green. When applied from the start of a SaaS project, TDD does several things simultaneously:

1. It forces you to think about interfaces before implementations. When you write a test for your user registration endpoint before the endpoint exists, you naturally design a clean API contract.

2. It gives you a safety net for the entire project. Every feature you add from this point forward is protected by tests. When you refactor your authentication system in month three, your tests will catch regressions instantly.

3. It produces documentation as a side effect. Your test suite becomes a living specification of what your application does.

Set up your testing infrastructure during project initialization: test runner, assertion library, database fixtures, and CI pipeline. The TDD skill will guide you through writing your first tests --- typically for your data models and core API endpoints.

Practical tip: Start with integration tests for your API endpoints and unit tests for your business logic. Do not obsess over achieving 100% coverage on day one. Focus on covering the critical paths: authentication, authorization, and your core domain operations.

Phase 3: Core Development

This is the longest phase, where you build feature after feature according to your implementation plan. Two skills work together here to keep you productive and your codebase healthy.

Skill: TDD (continued)

Every new feature begins with a test. This is non-negotiable. As you build out your SaaS --- adding payment integration, team management, notification systems, admin dashboards --- each feature starts with a failing test that describes the expected behavior.

The TDD skill adapts to the complexity of what you are building. For a simple CRUD endpoint, it might suggest a straightforward request-response test. For a payment webhook handler, it will guide you toward testing edge cases: duplicate events, out-of-order delivery, and partial failures. The skill helps you think about what can go wrong, not just what should go right.

Skill: Git Worktrees

As your feature set grows, you will often need to work on multiple things in parallel or quickly switch context. The Git Worktrees skill teaches you to use Git's worktree feature to maintain multiple working directories from a single repository. Each feature gets its own worktree, its own branch, and its own isolated development environment.

Why does this matter for SaaS development? Consider a realistic scenario: you are halfway through building the team invitation system when a user reports that password reset emails are broken. Without worktrees, you either stash your work (risky), commit half-finished code (messy), or lose your flow state entirely. With worktrees, you open a new terminal, navigate to a fresh worktree on a hotfix branch, fix the issue, push, and return to your feature work without missing a beat.

The Git Worktrees skill also pairs beautifully with TDD. Each worktree runs its own test suite independently. You can have tests running in your invitation-system worktree while you debug in your hotfix worktree.

Practical tip: Create a naming convention for your worktrees early. Something like feature/team-invitations, fix/password-reset, experiment/new-pricing-page. This keeps your workspace organized as the project grows.

Development rhythm

The rhythm during Phase 3 should feel like this:

1. Pick the next feature from your implementation plan.
2. Create a new branch (and optionally a new worktree).
3. Write failing tests for the feature.
4. Implement the feature until tests pass.
5. Refactor while tests stay green.
6. Create a pull request.
7. Repeat.

Each cycle should take hours to a couple of days, not weeks. If a feature is taking longer than two days, break it into smaller vertical slices.

Phase 4: Quality Assurance

You have built the core features. The test suite is green. But before you ship, two more skills ensure you are not sending a half-baked product into the world.

Skill: Pre-Completion Verification

The Pre-Completion Verification skill is your checklist before declaring a feature "done." It systematically walks through a verification process: Do all tests pass? Are there edge cases you haven't considered? Is error handling comprehensive? Are environment variables documented? Is the database migration reversible? Are API responses consistent with your schema?

This skill catches the things that slip through the cracks when you are moving fast. It is especially valuable for SaaS products because the surface area of potential issues is so large. Authentication, authorization, data validation, rate limiting, error messages, logging --- each of these is a domain where a small oversight can become a production incident.

Run Pre-Completion Verification for every major feature before merging it. The twenty minutes it takes will save you hours of firefighting after launch.

Skill: Code Review

The Code Review skill turns Claude into a rigorous reviewer of your own code. It examines your changes for security vulnerabilities, performance issues, maintainability concerns, and adherence to best practices.

For a SaaS product, the Code Review skill is particularly valuable in a few areas:

• Security: It flags common vulnerabilities like SQL injection, insecure direct object references, and missing authorization checks. These are the kinds of bugs that do not crash your app but quietly expose your users' data.
• Performance: It identifies N+1 queries, missing database indexes, and unnecessary data fetching that will become painful as your user base grows.
• Maintainability: It catches code smells, suggests better abstractions, and points out where your code has drifted from established patterns.

Even if you are a solo developer, treat every pull request as if a teammate is reviewing it. The Code Review skill provides that second pair of eyes.

Phase 5: Ship

You have built, tested, verified, and reviewed. Now it is time to put your product in front of real users.

Final Checks

Before deployment, run through a final round of Pre-Completion Verification at the project level (not just the feature level). This means:

• All tests pass in CI.
• Environment variables are configured for production.
• Database migrations have been tested against a production-like dataset.
• Error monitoring and logging are in place.
• Rate limiting and abuse prevention are configured.
• Your landing page accurately describes what the product does.

Deployment

Deploy to your chosen platform. Whether it is Vercel, Railway, Fly.io, AWS, or something else, your implementation plan from Phase 1 should have already defined the deployment strategy. Your first deploy should be anticlimactic --- that is a sign that your process worked.

Post-Launch

After launch, the same skills continue to serve you. New features follow the TDD cycle. Bug reports get investigated with Systematic Debugging (see the debugging guide). Code Review catches regressions before they reach users. The skills do not just help you build --- they help you maintain and grow.

Why This Combination Works

The five skills in this guide are not random selections. They form an interlocking system:

• Brainstorming ensures you build the right thing.
• Implementation Plan ensures you build it in the right order.
• TDD ensures every piece works correctly as you build it.
• Git Worktrees ensures you can move fast without creating chaos.
• Pre-Completion Verification + Code Review ensures nothing slips through before it reaches users.

Each skill addresses a different failure mode. Without brainstorming, you build the wrong product. Without a plan, you build features in the wrong order and waste time on rework. Without TDD, bugs accumulate silently. Without worktrees, context switching destroys your productivity. Without verification and review, you ship broken features.

Together, they create a development process that is both fast and safe. You move quickly because you have a clear plan and automated tests that catch mistakes. You move safely because every feature is verified and reviewed before it ships.

Common Pitfalls

Skipping the planning phase. The urge to "just start coding" is strong. Resist it. Two hours of structured brainstorming and planning will save you twenty hours of rework.

Adding TDD later. If you tell yourself you will add tests after the core features are built, you will not. The codebase will grow in ways that make testing difficult, and the effort required to retrofit tests will feel prohibitive. Start with TDD on day one.

Making worktrees too long-lived. A worktree that has been open for two weeks without merging is a merge conflict waiting to happen. Keep your feature branches short-lived. Merge frequently. If a feature is too large to merge in a couple of days, break it into smaller pieces.

Treating code review as optional when solo. Solo developers often skip code review because "I wrote it, so I know what it does." You do not. Future-you will not remember why you made that design decision. The Code Review skill provides objectivity and catches blind spots.

Ignoring pre-completion verification for "small" changes. Small changes cause big outages. A one-line configuration change can take down your entire application. Run verification proportional to risk, not proportional to the size of the diff.

Not iterating on the plan. Your implementation plan is a living document. As you build, you will learn things that change your priorities. Update the plan. Do not rigidly follow a plan that no longer reflects reality.

Building a SaaS product is hard work, but it does not have to be chaotic work. With the right skills activated at the right time, Claude Code becomes more than a code generator --- it becomes a development partner that keeps you disciplined, productive, and shipping.