一个非程序员的AI产品开发全流程，从想法到上线——附完整提示词模板【一万六千字，建议直接听语音】

去年10月的一个晚上，我坐到电脑前，想做一个出海工具站。

打开 Cursor，盯着空白页面，手放在键盘上，脑子里有产品，手指头却没有方向。

要做什么功能？先写前端还是先搭后端？用户是谁？怎么赚钱？

每个问题都能想到一点，每个问题又都想不清楚。发了一个小时呆，关了电脑，第二天又重复。

我做了8年新媒体，带过团队，开过工厂。不是没执行力的人。但"做产品"这件事，愣是把我卡在了"第一步"。

大多数人做产品的样子

你猜我后来怎么干的？

直接写代码。

想到一个功能，就开一个文件，写到哪算哪。今天加个登录，明天加个支付，后天发现架构不对，重构。再后天发现需求都想歪了。

pngtrid.com 的第一版就是这样干的。做了一个月，上线了，然后发现——用户要的根本不是我做的那个东西。

代码全废。

OpenClaw 中文桌面版也踩过同样的坑。早期没有文档，全凭感觉写。写到一半发现前后端接口对不上，数据结构改了三遍，光返工就浪费了一周。

我不是个例。你身边想做产品的非程序员，十个有八个是这个模式：脑子里有个模糊的想法，打开 AI 工具，开干。没有文档，没有流程，没有验证，写到哪里算哪里。

程序员不会这样。他们有需求文档、有技术评审、有代码审查。每一环都有人盯着，有人扛雷。

非程序员呢？什么都没有。一个人就是整个团队，也是整个流程。缺了哪一环，只有上线后用真实用户来告诉你。

GitClear 2025 年的一份报告显示：AI 生成代码的重复率，比两年前高了 10 倍。意思是——大家都在用 AI 写代码，但大多数人写的方向是错的。代码写了一堆，产品没跑出来。

产品开发最贵的不是写代码的时间，是方向错的时间。

写废的代码一文不值。验证方向花的那两三天，才是整个产品最值钱的投入。

产品开发到底是什么

很多人一听到"做产品"，脑子里立刻跳出来的是"写代码""学编程""搞设计"。

不是的。

产品开发是一套有章法的流程。从"有个想法"到"东西上线"到"有人用"到"能赚钱"——这是一条完整的链条。

你不需要会写代码。你不需要会画 UI。你甚至不需要懂技术。

你需要的是一套流程。把每个环节做对，让对的人（或者对 的 AI）在对的时间做对的事。

以前这套流程需要产品经理写文档、设计师画原型、程序员写代码、测试找 bug。一个最小的团队也得三四个人。

现在不一样了。一个人 + AI，就能把整条链子走完。

但前提是——你得知道链子长什么样。

我后来在实践中摸索出一套方法论，自己给它起了个名字：Spec-Driven Development。

翻译成人话就是：先写文档，再让 AI 围绕文档干活。

调研报告、商业需求文档、产品需求文档、技术设计文档、UI 设计规范——每一步都有明确的产出物。下一步的 AI，以上一步的文档为输入。

不是让 AI 瞎猜你要什么。是你用文档告诉 AI 你要什么。

这个思路，是整篇文章的核心。后面每个阶段，我都会给你可以复制粘贴的提示词。

这套方法有没有效

先说别人的数据。

GitHub 2025 年开发者调查：95% 的开发者在编码中使用 AI，其中 75% 的代码由 AI 生成。Anthropic 内部透露，Claude Code 编写的代码占其自身代码库的 90%。

AI 写代码这件事，已经不是"能不能"的问题，而是"怎么让它写对"的问题。

再说我的。

PNG 部落 AI 生图网站，按这套流程从调研到上线，用了不到三周。上线第一个月，没有投一分钱流量，变现 5K+。不是什么大数字，但验证了模式跑得通。

OpenClaw 中文桌面版，从零到可用，只用了两周。因为前期文档写清楚了，AI 写代码的效率极高。

反过来，没有流程的"vibe coding"，我试过。打开 Cursor，跟 AI 聊着写，想到哪写到哪。结果就是——写了两周，推翻重来。

没有文档的 AI 编程，就像没有图纸的装修。师傅手艺再好，装出来大概率不是你要的。

下面，我把我实际在用的流程，一个阶段一个阶段拆给你看。

每个阶段有：做什么、AI 怎么辅助、可以直接用的提示词、交付物、以及一个"门控"（不通过不往下走）。

阶段一：市场调研（1-3天）

做什么

这个阶段回答一个问题：这个方向值得做吗？

很多人跳过这一步。觉得自己的点子天下第一，直接开干。

我以前也这样。后来浪费了大量时间后，学到了一个教训：点子不值钱，值钱的是"有人愿意为解决某个问题买单"。

调研不是为了写报告，是为了在你投入时间之前，确认三件事：

第一，这个痛点是真实存在的，不是你脑补的。

第二，有人正在为解决这个问题花钱或花时间。

第三，现有的解决方案有明显的缺陷，你有差异化空间。

我常用的方法是"四路搜索法"——

• • 求助类："XX 怎么做""XX 工具推荐" → 找正在找解决方案的人
• • 吐槽类："XX 太难用了""XX 又崩了" → 找对现有方案不满的人
• • 替代类："有没有比 XX 更好的" → 找在对比选择的人
• • 交易类："XX 多少钱""求购 XX" → 找已经准备付费的人

四路搜完，不只看标题。评论区才是宝藏。用户在评论区说的话，比任何分析报告都真实。

AI 怎么辅助

调研阶段，AI 是你的研究助手。

你可以让 AI 帮你搜竞品、整理用户痛点、分析差评、归类反馈。不是让它替你判断方向，而是让它帮你处理大量信息，你来做决策。

用 OpenClaw 或者 Claude Code，可以直接丢给 AI 一堆竞品的用户评价链接，让它帮你归类痛点。

提示词模板

你是一位经验丰富的产品市场研究员。请帮我完成以下调研任务：

## 产品方向
[填入你的产品方向，例如：面向海外中小商家的AI客服工具]

## 四路搜索要求

请分别从以下四个维度搜索并整理信息：

### 1. 求助类搜索
搜索关键词示例："how to [解决XX问题]""best tool for [XX场景]"
目标：找到正在主动寻找解决方案的用户，记录他们的原话描述

### 2. 吐槽类搜索
搜索关键词示例："[竞品名称] sucks""[竞品名称] alternatives""frustrated with [XX问题]"
目标：找到对现有方案不满的用户，记录他们的核心不满点

### 3. 替代类搜索
搜索关键词示例："[竞品名称] vs""alternative to [竞品名称]""switch from [竞品名称]"
目标：找到正在对比不同方案的用户，记录他们的选择标准

### 4. 交易类搜索
搜索关键词示例："[XX工具] pricing""buy [XX产品]""[XX工具] review"
目标：找到已经或准备付费的用户，记录他们的付费意愿和价格敏感度

## 输出格式

请按以下结构输出调研报告：

### 一、用户痛点清单
| 痛点 | 出现频率 | 痛点强度(1-5) | 来源(求助/吐槽/替代/交易) | 用户原话摘录 |

### 二、竞品分析
| 竞品 | 核心功能 | 定价 | 用户好评TOP3 | 用户差评TOP3 | 你的差异化机会 |

### 三、目标用户画像
- 谁最需要解决这个问题？
- 他们愿意花多少钱？
- 他们在哪里出没（Reddit/ProductHunt/某个论坛）？

### 四、初步结论
- ✅ 值得做 / ⚠️ 需要调整 / ❌ 不建议做
- 理由（3句话以内）
- 建议切入的具体角度

交付物

调研报告.md——一份结构化的市场调研文档，包含痛点清单、竞品分析、用户画像、初步结论。

门控

• • ✅ 有明确的、高频的用户痛点（不是小众需求）
• • ✅ 用户已经在为解决这个问题付费或投入时间
• • ✅ 现有竞品有可差异化的缺陷

三个条件全过，进入下一阶段。任何一个不过，回去重新想方向。

阶段二：BRD 商业需求文档（0.5-1天）

做什么

调研通过了。现在回答第二个问题：为什么做？做成什么样能赚钱？

BRD 是商业需求文档（Business Requirements Document）的缩写。听起来很正式，其实就是把"为什么要做这个产品"讲清楚。

包含六个部分：

1. 1. 市场分析——调研结论的提炼，市场多大、增速多快
2. 2. 目标用户——精确到"谁、在什么场景、遇到什么问题"
3. 3. 商业模式——怎么赚钱。免费增值？订阅制？按量付费？
4. 4. 资源计划——你需要什么。时间、钱、工具、AI 账号
5. 5. 风险评估——可能挂在哪里。技术风险、市场风险、法律风险
6. 6. 成功指标（KPI）——怎么判断"做成了"。日活？付费转化率？月收入？

这个文档是给"你自己"看的。帮你理清思路，避免做到一半发现商业逻辑不成立。

AI 怎么辅助

把调研报告丢给 AI，让它帮你生成 BRD 初稿。你负责审核和调整，AI 负责把结构搭好、把信息填进去。

提示词模板

你是一位商业分析师和产品经理。基于以下调研报告，帮我生成一份BRD（商业需求文档）。

## 调研报告
[粘贴阶段一输出的调研报告]

## BRD 要求

请按以下结构生成：

### 1. 市场分析
- 市场规模估算（TAM/SAM/SOM）
- 市场增速和趋势
- 市场机会窗口（为什么是现在做）

### 2. 目标用户
- 核心用户画像（年龄、职业、技术水平、使用场景）
- 用户痛点优先级排序
- 早期种子用户的获取渠道

### 3. 商业模式
- 收费模式（推荐2-3种并对比优缺点）
- 定价策略（建议具体价格区间和理由）
- MVP阶段的商业验证路径

### 4. 资源计划
- 时间规划（按周拆分，总共不超过8周）
- 资金预算（域名、服务器、AI API调用费、其他）
- 工具清单（开发工具、部署工具、运营工具）

### 5. 风险评估
| 风险类型 | 具体风险 | 概率(高/中/低) | 影响(高/中/低) | 应对预案 |

### 6. 成功指标
- 上线第1个月的目标
- 上线第3个月的目标
- 关键北极星指标（唯一最重要的指标）

请用数据和逻辑说话，不要空话。每个部分控制在200字以内。

BRD 片段示例

以"出海 AI 写作助手"为例，商业模式部分可能是这样的：

商业模式建议：Freemium + Pro 订阅 免费版：每月 5000 token 额度，3 种写作模板。目的不是赚钱，是获客和验证需求。 Pro 版（$9.9/月）：无限 token，全部模板，API 调用，优先队列。参考 Grammarly 的定价阶梯——它免费用户转付费的转化率约 3%，这是一个健康的基准。

为什么不按量付费？因为写作场景的用量不稳定，用户讨厌"不知道这个月要花多少"的不确定性。订阅制让用户有预期，也给你可预测的收入。 竞品定价参考：Jasper 49/月起，Copy.ai 49/月，Writesonic 19/月。我们的优势不是更便宜，而是"面向中文出海卖家"这个垂直场景做深。定价卡在 MVP 阶段验证路径：先不上付费，用 waitlist 验证需求。如果 waitlist 注册数在 2 周内超过 500，说明需求成立，再推付费版。

交付物

BRD.md

门控

• • ✅ 商业逻辑成立（有人愿意付费）
• • ✅ ROI 合理（投入的时间和金钱能回本）
• • ✅ 核心风险有应对预案

阶段三：PRD 产品需求文档（1-2天）

做什么

这是整个流程中最关键的文档。

回答的问题是：做成什么样？

PRD（Product Requirements Document）包含：

1. 1. 产品概述——一句话说明产品是什么、给谁用、解决什么问题
2. 2. 用户故事——"作为 XX 用户，我希望 XX，以便 XX"
3. 3. 功能规格——每个功能包含：交互流程 + 异常场景 + 验收标准
4. 4. 非功能需求——性能、安全、可访问性
5. 5. 数据模型——核心数据长什么样

大部分人写的 PRD，只写了"正常流程"——用户打开页面、输入内容、点击按钮、得到结果。但真正让产品区别开的，是你对异常场景的覆盖。

用户网络断了怎么办？输入为空怎么办？AI 接口超时怎么办？用户重复提交怎么办？

这些异常场景，人容易漏。AI 补全特别有价值——你让 AI 想异常场景，它能列出一大串你没想过的情况。

这个 PRD，是后面所有 AI 工作的唯一事实来源（Single Source of Truth）。写代码的 AI 看它，做测试的 AI 看它，做设计的 AI 也看它。

一份好的 PRD，能让任何 AI 工具独立完成自己的部分，而且产出的结果之间不会打架。

AI 怎么辅助

让 AI 帮你生成 PRD 初稿，尤其是功能规格中的异常场景部分。人类的产品经理容易漏掉的边界情况，AI 会系统地列出来。

然后用你的产品直觉去筛选——哪些异常场景在 MVP 阶段需要处理，哪些可以暂时忽略。

提示词看起来很长，但你只需要填两个地方：产品方向和BRD内容。其他部分AI会自动生成。

提示词模板

你是一位资深产品经理。基于以下BRD，帮我生成一份详细的PRD。

## BRD内容
[粘贴BRD.md的内容]

## PRD 要求

### 1. 产品概述（100字以内）
- 一句话定位
- 核心价值主张
- 与竞品的核心差异

### 2. 用户故事
按照优先级（P0/P1/P2）排列，格式：
"作为[用户角色]，我希望[完成什么操作]，以便[达成什么目的]"
每个用户故事附带：验收标准

### 3. 功能规格（这是重点部分）
对每个P0/P1功能，详细说明：

#### 功能名称：[XX]
- **描述**：这个功能做什么（2-3句）
- **交互流程**：用户操作的每一步（编号列表）
- **正常场景**：一切顺利时的完整流程
- **异常场景**（请尽量穷举）：
  - 用户侧异常：输入为空、格式错误、重复提交、网络中断、浏览器兼容性问题...
  - 系统侧异常：AI接口超时、服务不可用、数据保存失败、并发冲突...
  - 第三方异常：API限额、第三方服务变更、鉴权失败...
- **验收标准**：可测试的checklist（ Given...When...Then...格式）
- **边界条件**：最大输入长度、频率限制、并发限制

### 4. 非功能需求
- 性能要求：页面加载时间、API响应时间
- 安全要求：数据加密、用户隐私
- 兼容性：支持哪些浏览器/设备

### 5. 数据模型
用表格列出核心数据实体及其字段：
| 实体 | 字段 | 类型 | 必填 | 说明 |

请特别注意异常场景的完整性。先列出你认为所有可能的异常情况，然后我告诉你哪些在MVP阶段需要处理。

PRD 功能规格片段示例

以"AI 写写助手"中的"生成文案"功能为例：

功能名称：AI 文案生成 描述：用户输入产品信息和写作需求，系统调用 AI 生成多版本营销文案。 交互流程：

1. 1. 用户选择文案类型（产品描述 / 广告语 / 邮件 / 社媒帖）
2. 2. 用户填写产品信息（名称、卖点、目标人群）
3. 3. 用户选择语言和语气风格
4. 4. 点击"生成"，系统调用 AI
5. 5. 展示生成结果，支持复制、收藏、重新生成
6. 6. 生成记录存入用户历史

异常场景：

• • 用户未填写产品名称就点击生成 → 按钮置灰，提示"请至少填写产品名称"
• • AI 接口响应超时（>30秒） → 显示"生成中，请稍候"，超过 60 秒提示"服务繁忙，请重试"
• • AI 返回内容为空 → 自动重试一次，仍为空则提示"暂时无法生成，请稍后再试"
• • 用户生成频率超过限制 → 提示"已达到本次免费额度，升级 Pro 可继续使用"
• • 用户在等待生成时切换页面 → 后台继续生成，回来后展示结果
• • 用户修改已收藏的文案 → 弹窗确认"修改将取消收藏，确定？"

验收标准：

• • Given 用户已填写产品名称和至少一个卖点，When 点击生成，Then 3秒内显示loading状态
• • Given AI 成功返回文案，When 结果渲染完成，Then 展示 3 个版本供选择
• • Given 用户点击复制，When 复制成功，Then 显示"已复制"提示，2秒后消失

交付物

PRD.md

门控

• • ✅ 功能描述清晰无歧义，任何人读完都能理解要做什么
• • ✅ 核心功能的异常场景全覆盖
• • ✅ 验收标准可测试（不是"体验良好"这种模糊描述）

阶段四：技术设计（0.5-1天）

做什么

PRD 定了"做什么"。技术设计回答"怎么实现"。

这个阶段产出的文档是给 AI 写代码用的。包含：

1. 1. 技术选型——前端用什么框架、后端用什么语言、数据库用什么、部署在哪里
2. 2. 架构设计——整体架构图、模块划分、数据流向
3. 3. 数据库设计——表结构、字段定义、索引设计
4. 4. API 设计——每个接口的路径、方法、参数、返回值
5. 5. 项目结构——文件夹怎么组织、代码怎么分层

如果你不是程序员，这个阶段 AI 的价值最大。因为你不需要懂技术细节，只需要告诉 AI 你的需求（PRD），让它帮你推荐最合适的技术方案。

它会给你对比：Next.js vs Remix vs Vite，PostgreSQL vs Supabase vs PlanetScale，Vercel vs Railway vs AWS。每个选项的优缺点一目了然，你做选择题就行。

AI 怎么辅助

技术设计几乎可以全部交给 AI。把 PRD 丢给它，让它输出完整的技术方案。

但有一个坑：AI 倾向于推荐它"最擅长"的技术，而不是"最适合你的"技术。所以你要在提示词里强调——我是非程序员，优先推荐上手成本低、社区资源多的方案。

提示词模板

你是一位全栈技术架构师。基于以下PRD，帮我设计完整的技术方案。

## PRD内容
[粘贴PRD.md的内容]

## 技术设计要求

### 1. 技术选型对比
请对以下每个维度给出2-3个选项的对比：

**前端框架**
| 方案 | 优势 | 劣势 | 上手难度 | 适合非程序员程度 | AI编程支持度 |

**后端/服务端**
| 方案 | 优势 | 劣势 | 上手难度 | 适合非程序员程度 | AI编程支持度 |

**数据库**
| 方案 | 优势 | 劣势 | 免费额度 | 上手难度 |

**部署平台**
| 方案 | 优势 | 劣势 | 免费额度 | 部署难度 |

**选型原则**：
- 我是非程序员，优先推荐学习曲线平缓的方案
- 优先选择AI编程工具支持好的方案（Cursor、Claude Code兼容性好）
- 优先选择免费额度够MVP使用的方案
- 避免过度工程化，MVP阶段能用就行

### 2. 架构设计
- 整体架构图（用文字描述组件和连接关系）
- 前端→后端→数据库的数据流向
- 第三方服务集成点（支付、AI API、邮件等）

### 3. 数据库Schema
列出所有核心表的结构：
| 表名 | 字段 | 类型 | 约束 | 说明 |
包含索引设计和关联关系。

### 4. API设计
| 方法 | 路径 | 描述 | 请求参数 | 返回值 | 错误码 |
按照RESTful规范设计。

### 5. 项目目录结构

project/ ├── src/ │ ├── components/ # ... │ ├── pages/ # ... │ └── ... ├── prisma/ # 数据库schema ├── public/ # 静态资源 └── ...

### 6. 关键技术决策
列出每个选型的最终推荐和理由（每项2句话）。

### 7. 风险预案
| 技术风险 | 发生概率 | 影响 | 应对方案 |

技术选型对比表示例

为什么推荐 Next.js？因为它前后端一体，非程序员只需要学一套东西。而且 Cursor 和 Claude Code 对 Next.js 的代码生成质量最高，你让 AI 写的代码大概率能直接跑。 为什么推荐 Supabase？因为它免费额度足够 MVP 使用，自带用户认证和数据库，不用自己搭后端。很多 AI 编程教程也基于 Supabase，遇到问题容易搜到解决方案。 为什么不推荐自建后端？MVP 阶段最大的敌人是时间。自建后端意味着你要处理服务器、数据库、缓存、负载均衡……每一项都是学习成本。Next.js API Routes + Supabase，能覆盖 80% 的 MVP 需求。

交付物

spec.md——完整的技术设计文档

门控

• • ✅ 技术方案可行（AI 评估无重大隐患）
• • ✅ 关键技术风险有预案
• • ✅ 免费额度足够 MVP 阶段使用

阶段五：UI/UX 设计（1-3天）

做什么

前面四个阶段都是在"想"。这个阶段开始"看见"你的产品。

分四步走：

1. 1. 信息架构——产品有哪些页面，页面之间怎么跳转。用纸笔画就行，不需要工具
2. 2. 交互原型——每个页面的布局和交互逻辑。这里可以开始用工具了
3. 3. 视觉设计——配色、字体、间距、圆角。让产品"好看"
4. 4. 设计规范——把视觉决策固定下来，后面 AI 写前端代码时直接参考

很多非程序员在这步卡住——"我不会设计啊"。

放心，AI 时代，你不需要会设计。

AI 怎么辅助

这是 AI 设计工具大显身手的环节。

v0.dev（Vercel 出品）可以直接用自然语言生成 UI 页面。你告诉它"我要一个 AI 写作工具的首页，暗色主题，左侧是输入区，右侧是生成结果展示"，它会直接生成可预览的页面代码。

把前几个阶段的文档作为上下文丢给 v0.dev，它生成的设计会更贴合你的产品需求。

如果你用 Claude Code 或 Cursor，也可以直接让 AI 生成 Tailwind CSS 代码。把技术设计文档里定义的设计规范（配色、字体、间距）写进一个 design-tokens.ts 文件，后续所有页面都参考它。

提示词模板

你是一位UI/UX设计师和前端工程师。基于以下PRD和技术设计，帮我设计产品界面。

## PRD核心内容
[粘贴PRD中P0功能的描述]

## 技术设计中的设计规范
[粘贴技术设计中的UI相关约束]

## 设计要求

### 1. 信息架构
列出所有页面及其层级关系：

首页 ├── 注册/登录 ├── 仪表盘 │ ├── 功能A页面 │ ├── 功能B页面 │ └── 设置页面 └── 定价页面

### 2. 页面设计（对每个核心页面）

**页面名称：[XX]**
- 布局描述：上中下/左右分栏/其他
- 核心组件：每个组件的位置和功能
- 交互说明：用户在这个页面上能做什么
- 移动端适配：小屏幕上的布局变化

### 3. 设计规范

**配色方案**
| 用途 | 颜色值 | 说明 |
|------|--------|------|
| 主色 | #XX | 用于按钮、链接等主要交互元素 |
| 背景色 | #XX | 页面背景 |
| 文字主色 | #XX | 标题和正文 |
| 文字辅色 | #XX | 说明文字 |
| 成功色 | #XX | 成功提示 |
| 错误色 | #XX | 错误提示 |

**字体**
- 标题字体：
- 正文字体：
- 代码字体：

**间距系统**
- 基础间距单位：4px
- 组件间距：16px
- 区块间距：32px
- 页面边距：max(16px, 5vw)

**圆角**
- 按钮圆角：8px
- 卡片圆角：12px
- 弹窗圆角：16px

### 4. Tailwind CSS 配置
生成一份 tailwind.config.ts 配置文件，把以上设计规范全部定义进去。

### 5. 核心页面代码
为2-3个最重要的页面生成完整的 Tailwind CSS + React/Next.js 代码。
代码要求：
- 使用设计规范中定义的 token
- 响应式设计（移动端优先）
- 语义化 HTML
- 可访问性（aria标签、键盘导航）

踩坑提醒

我早期做 UI 设计犯过一个错：在 v0.dev 上生成了页面，看起来很漂亮，直接丢到项目里。结果发现——AI 生成的设计和 PRD 里定义的功能对不上。按钮的位置和交互流程不一致。

后来学乖了：先画信息架构，再让 AI 生成页面。 先确定"每个页面有什么、放哪里"，再让 AI 决定"长什么样"。

顺序不能反。先确定骨架，再长肉。

交付物

• • design-system.md——设计规范文档
• • UI 页面文件（由 AI 生成的前端代码）

门控

• • ✅ 核心用户流程（从注册到完成第一次使用）在页面上走得通
• • ✅ 所有页面的风格统一（配色、字体、间距一致）
• • ✅ 移动端可用（不要求完美，但核心功能能用）

到这里，前五个阶段完成了。

你没有写一行代码，但你手里有五份文档：调研报告、BRD、PRD、技术设计、设计规范。

这五份文档，就是你在下一个阶段让 AI 写代码时的"施工图"。

有图施工和没图施工，差别有多大？你装修过房子就知道了。

五份文档，从"为什么做"到"做成什么样"到"怎么实现"到"长什么样"，全部写清楚。

有图施工和没图施工，差别有多大？你装修过房子就知道了。

但文档写好了，东西还没做出来。别急——接下来，才是你等了整篇文章的那个环节。

阶段6：开发实现（1-4周）

把大象拆成骨头

技术设计文档的本质是一份"施工图纸"。

但图纸不会自动变成房子。你需要把图纸拆成一张张施工单——每个任务只做一件事，做完能验证，验证完能提交。

一个任务，一个commit。 这句话是我踩了无数次坑之后才真正理解的。

我早期做PNG部落的时候，一口气写了两千行代码，中间没提交过一次。结果程序跑不起来，想回退都不知道回退到哪个版本。那两天的代码，全部重写。

从那以后，我给自己立了一条铁律：

任务拆到不能再拆为止。拆完，你能用一句话描述这个任务在干什么。

一个真实的任务拆解示例

假设你在做一个AI写作助手，你的技术设计里有3个模块。拆完之后，任务列表大概长这样：

用户模块
├── task-001: 搭建项目骨架（Next.js + TypeScript + Tailwind）
├── task-002: 创建Supabase项目，初始化数据库表结构
├── task-003: 实现邮箱注册/登录接口
├── task-004: 实现JWT鉴权中间件
└── task-005: 编写用户CRUD接口 + 单元测试

内容模块
├── task-006: 接入OpenAI API，封装调用函数
├── task-007: 实现文章生成的prompt模板系统
├── task-008: 实现流式输出（SSE）接口
└── task-009: 内容生成接口 + 错误处理

前端模块
├── task-010: 搭建首页布局（Header + Sidebar + Main）
├── task-011: 实现登录/注册页面
├── task-012: 实现写作工作台页面（输入框 + 生成按钮 + 结果展示）
└── task-013: 实现文章列表页面 + 分页

注意看，每个task都是独立的。task-003做完，用户就能注册；task-008做完，就能看到AI流式输出文字的效果。

不依赖其他任务的任务先做。 你不用等后端全部完成才开始前端，前端可以用mock数据先跑起来。

CLAUDE.md：让AI理解你项目的"灵魂文件"

这一步很多人跳过了，但它可能是整个开发阶段最重要的一件事。

当你用Claude Code或Cursor写代码的时候，AI需要理解你的项目——用了什么技术栈、代码风格是什么、哪些事绝对不能做。

这个信息写在哪里？写在一个叫CLAUDE.md的文件里。放在项目根目录，AI每次打开项目都会自动读取。

我给你看一个完整的示例，你可以直接复用：

# 项目信息
项目名称：AI写作助手
技术栈：Next.js 14 (App Router) + TypeScript + Tailwind CSS + Supabase
数据库：Supabase (PostgreSQL)
API：OpenAI GPT-4o-mini
包管理：pnpm

# 常用命令
- pnpm dev        # 启动开发服务器
- pnpm build      # 构建生产版本
- pnpm test       # 运行测试
- pnpm lint       # 代码检查

# 编码规范
- 所有函数必须有TypeScript类型标注
- 组件文件使用 PascalCase 命名
- API路由统一放在 /app/api/ 目录下
- 数据库操作统一通过 Supabase Client
- 错误处理统一用 try-catch，禁止空catch

# 红线（绝对不能违反）
- 禁止使用 any 类型，用 unknown 替代
- 禁止在前端暴露 Supabase service_role key
- 禁止在客户端直接调用 OpenAI API（必须走服务端）
- 禁止提交 .env 文件到 Git

这个文件就是你和AI之间的契约。有了它，AI写出来的代码风格一致，不会犯低级错误。

没有CLAUDE.md，等于让一个新员工第一天就写代码——他不了解项目，产出质量全靠运气。

逐任务执行的工作流

现在，进入最爽的部分。你不用自己写代码了。

工作流是这样的：

第一步：告诉AI你要做哪个任务。

读一下技术设计文档的 task-006 部分，帮我接入OpenAI API。
按照CLAUDE.md的规范来写代码。

第二步：AI读spec，写代码。

它会读取你之前写好的技术设计文档，找到task-006对应的需求，然后生成代码。

第三步：跑测试，看结果。

跑一下测试，看看有没有通过。

第四步：你审查代码。

你不用看懂每一行。重点关注三件事：

• • 这段代码做的是不是我要的？
• • 有没有明显的错误？
• • 有没有违反CLAUDE.md里的红线？

第五步：提交。

代码没问题，提交一下。commit message写清楚做了什么。

一个task一个commit。commit message写成 "feat: 接入OpenAI API封装调用函数" 这样的格式，清晰明了。

Git规范

分支策略很简单，个人开发者不需要搞复杂的Git Flow：

main（主线，始终保持可部署状态）
 └── dev（开发分支，所有task在这里做）
      └── feature/xxx（可选，如果某个task比较复杂）

commit message格式：

feat: 实现邮箱注册功能
fix: 修复登录token过期问题
test: 添加用户模块单元测试
refactor: 重构API错误处理逻辑

交付物： 一个干净的Git仓库，commit历史清晰，每个commit对应一个完成的任务。

阶段7：测试（贯穿开发，上线前集中1-3天）

代码写了，能跑吗？

我刚学编程的时候，觉得测试是个多余的事。代码能跑就行了嘛，测什么测？

后来我在PNG部落上线第三天，发现用户上传图片后页面白屏。查了半天，是因为一个空值没处理。

一个空值。用户量不大还好，用户量大的话，一晚上能丢掉几百个用户。

测试不是保险，是底线。

测试金字塔

测试分三层，像金字塔一样：

        /  E2E  \        10% — 模拟真实用户操作
       / 集成测试  \      20% — 测试模块之间的协作
      /  单元测试    \    70% — 测试单个函数的行为

单元测试： 测试一个函数。输入A，输出是不是B？是→通过。不是→挂了。

集成测试： 测试两个模块能不能正常配合。用户注册接口 + 数据库写入，组合起来能不能跑通？

E2E测试： 模拟一个真实用户打开浏览器、输入信息、点击按钮、看到结果。这一层最贵，所以只做关键路径。

AI写测试：一个提示词搞定

你不用自己手写测试用例。把你之前写的PRD丢给AI，让它根据验收标准自动生成：

读一下PRD文档，找到"用户注册"功能的验收标准。
根据这些标准，生成完整的测试用例。

要求：
1. 覆盖正常流程和所有边界情况
2. 使用 Vitest 框架
3. 测试文件放在 __tests__/ 目录下
4. 每个测试用例用 describe + it 结构
5. 先写测试代码，不写实现代码（TDD的Red阶段）

AI会生成类似这样的测试：

describe('用户注册', () => {
  it('应该用有效邮箱和密码成功注册', async () => {
    const result = await registerUser('test@example.com', 'ValidPass123!')
    expect(result.user).toBeDefined()
    expect(result.user.email).toBe('test@example.com')
  })

  it('应该拒绝重复的邮箱', async () => {
    await registerUser('test@example.com', 'ValidPass123!')
    await expect(
      registerUser('test@example.com', 'ValidPass123!')
    ).rejects.toThrow('邮箱已注册')
  })

  it('应该拒绝少于8位的密码', async () => {
    await expect(
      registerUser('test@example.com', '123')
    ).rejects.toThrow('密码长度至少8位')
  })
})

AI版TDD

TDD（测试驱动开发）的流程是：

1. 1. Red： 先写测试，运行，全部失败（因为还没写实现）
2. 2. Green： 写最少的代码让测试通过
3. 3. Refactor： 重构代码，消除重复，优化结构

有了AI，这个过程变得异常丝滑。你说"先帮我写测试"，AI写完，跑一下，全红。再说"帮我把这些测试都通过"，AI写实现代码，再跑，全绿。

交付物： 一份测试报告。多少个用例，通过了几个，失败率多少，一目了然。

上线前检查清单

发布之前，过一遍这10个问题。每个打勾了再上线：

• • [ ] 所有核心功能的单元测试通过
• • [ ] 用户注册→登录→使用主功能的完整流程跑通
• • [ ] 所有API接口有错误处理，不会返回500裸错误
• • [ ] 敏感信息（API Key、数据库密码）不在代码里
• • [ ] 移动端响应式布局正常
• • [ ] 首屏加载时间 < 3秒
• • [ ] HTTPS已配置
• • [ ] 数据库已备份
• • [ ] 监控已接入，能收到异常报警
• • [ ] 域名解析正确，能正常访问

阶段8：部署上线（0.5-1天）

让全世界看到你的产品

代码写完了，测试通过了，但产品还只活在你的电脑上。

部署就是把代码放到服务器上，让任何人都能通过网址访问。

这个环节，AI能帮你解决90%的问题。

部署的六个步骤

① 环境准备： 买服务器、注册域名、配置DNS。服务器推荐用Vercel（Next.js项目直接连GitHub，推送代码自动部署，免费额度够用）或者Railway（支持多种语言）。

② 部署配置： 让AI帮你生成配置文件。

帮我生成一份部署配置。
项目是 Next.js + Supabase。
部署平台用 Vercel。
需要包含环境变量说明。

AI会帮你生成vercel.json，列出需要配置的环境变量（API_KEY、DATABASE_URL等），你只需要在Vercel后台填上对应的值。

③ 数据库初始化： 在Supabase控制台跑你的migration脚本，建表、建索引。

④ 上线： 推送代码到GitHub，Vercel自动检测到更新，开始构建部署。两分钟。

⑤ 冒烟测试： 上线后立刻打开网站，走一遍核心流程。能注册吗？能登录吗？核心功能正常吗？三分钟搞定。

⑥ 监控接入： 上线不等于结束。你需要知道产品出了问题能第一时间发现。

监控工具推荐：

三样都接上，半小时搞定。

部署提示词模板

帮我完成项目的部署配置。

## 项目信息
- 技术栈：[Next.js 14 + TypeScript + Tailwind CSS]
- 数据库：[Supabase，项目ID: xxx]
- 部署平台：[Vercel / Railway]

## 需要生成的配置
1. vercel.json（或对应平台的部署配置文件）
2. .env.example（列出所有需要配置的环境变量及说明）
3. 数据库初始化脚本（Supabase migration SQL）
4. 部署步骤清单（按顺序）

## 要求
- 每个配置文件加上注释说明
- 环境变量用占位符，我在部署时替换
- 包含回滚步骤（部署出问题怎么办）

交付物： 一个能被全世界访问的产品，加上一套监控报警系统。

阶段9：运营增长（持续）

产品上线了，然后呢？

这是我最想聊的阶段。因为我自己在这个阶段踩了最多的坑。

PNG部落上线第一个月，我什么运营都没做，就等着用户来。结果呢？每天5个访问，其中3个是我自己。

后来我花了两个月研究运营，才慢慢把流量做起来。

产品上线不是终点，是起点。

上线后的三个阶段

种子期（0-30天）： 目标不是增长，是验证。找10-20个真实用户，看他们用不用你的产品。怎么找？去相关的社区发帖、去评论区找有痛点的人、直接私信。

这个阶段最重要的指标不是用户量，是留存率——用了一次之后，还会回来用吗？

验证期（30-90天）： 用户反馈收集了一堆，开始迭代。把高频需求做进去，把没人用的功能砍掉。同时开始尝试获客渠道，看哪种方式成本最低、效果最好。

增长期（90天+）： 找到了有效的获客渠道，开始加大投入。同时关注商业化——能不能让一部分用户付费？

获客渠道，从便宜到贵

按成本从低到高排列：

① SEO + 内容营销： 写和你产品相关的教程、攻略。这是最便宜的方式，但见效慢，通常需要3-6个月。一旦做起来，流量是持续的、免费的。

② 社区运营： 在Reddit、V2EX、掘金、Product Hunt等社区发帖。不是为了打广告，是为了分享你解决问题的过程。好内容自带流量。

③ Product Hunt发布： 如果你做的是面向全球用户的产品，PH发布日能带来几千到上万的初始访问。

④ 社交媒体： Twitter/X、YouTube、小红书。持续输出有价值的内容，建立个人品牌，自然引流到产品。

⑤ 付费投放： Google Ads、Meta Ads。效果快但烧钱，建议在前四个渠道跑通之后再考虑。

数据指标体系

别被复杂的分析工具吓到。你只需要关注四个层级的指标：

• • 获客层： 每天有多少新用户？从哪个渠道来的？
• • 留存层： 第二天回来多少人？第七天呢？第三十天呢？
• • 变现层： 付费转化率多少？ARPU（每用户平均收入）多少？
• • 推荐层： 用户会推荐给别人吗？NPS（净推荐值）多少？

四层指标，抓最上面两个就够了。 获客和留存，决定了产品能不能活下去。

我的教训

说个真实教训。我做PNG部落的时候，上线第一个月，我什么运营都没做，就等着用户来。

结果呢？每天5个访问，其中3个是我自己。

后来我花了两个月研究运营，才慢慢把流量做起来。这个公众号的数据也是一样——前4篇文章不到100阅读，后来调整了选题方法才起来。

教训就一个：产品上线不是终点，是起点。你不主动找用户，用户不会自己找上门。

阶段10：商业化（持续）

别等到产品做完了才想怎么赚钱

这是我和很多独立开发者交流时，发现最普遍的错误——先做产品，做完再想怎么收费。

结果往往是：做出来的功能别人不需要，愿意付费的功能你做了免费版。

商业化不是最后才想的事，在BRD阶段就已经规划好了。

商业模式怎么选

我的建议：如果你不确定选哪种，先做Freemium。 免费层让用户体验到价值，付费层提供真正能省时间/省钱的升级。

定价策略：四层定价法

免费层  → 让用户体验核心功能，产生依赖
低价层  → $5-9/月，消除付费门槛，"一杯咖啡的价格"
中价层  → $19-29/月，主力付费档，大部分收入来自这里
高价层  → $49-99/月，面向团队/重度用户，提供专属服务

大部分SaaS产品80%的收入来自中价层。 所以把中价层的价值做到极致，比给高价层堆功能更重要。

出海支付工具

如果你面向海外用户收费，这三个工具选一个：

• • LemonSqueezy（最推荐）：一家公司搞定支付、税务、订阅管理。不需要自己注册海外公司，它帮你处理全球各地的消费税。独立开发者的首选。
• • Stripe：最强大的支付平台，功能全，但需要你自己处理税务合规。
• • Paddle：和LemonSqueezy类似，但定价略高，适合已经有稳定收入的团队。

AI还能帮你做定价分析：

我有一个AI写作助手产品，目标用户是独立内容创作者。
帮我分析一下竞品的定价策略，并给出定价建议。
考虑以下因素：用户付费意愿、市场平均水平、我的成本结构。

极限测试：这套流程的边界在哪

什么时候不该用这套流程？

先说清楚：不是所有事都需要走10个阶段。

改个bug？直接改。

做个个人用的自动化小脚本？打开AI，说需求，跑通就行。

帮朋友做一个活动报名页面？一天就上线，不需要BRD也不需要PRD。

这套流程是为"你要做一个产品"设计的。 什么叫产品？有用户、有持续性、有可能商业化的东西。

常见误用

我在带深海圈学员的时候，见过三种最常见的误用：

第一，流程太重。 有学员花一周写了一份20页的PRD，然后发现做出来的东西没人用。问题不在PRD本身，在于他把PRD当成了目的。文档是工具，不是产出。

第二，一次性写完所有文档。 BRD写完写PRD，PRD写完写技术设计，一口气五份文档全写了。然后发现BRD里的市场判断是错的，后面四份全废。

正确的做法是：写完一份，验证一份，确认没问题再写下一份。

第三，文档和代码脱节。 PRD写了A功能，代码实现的是B功能。最后验收的时候，谁也不知道产品到底该长什么样。

个人开发者的简化版

如果你是一个人做，时间有限，这里有一个简化版：

• • BRD： 三段话。第一段说市场机会，第二段说目标用户，第三段说怎么赚钱。
• • PRD： 只聚焦MVP功能，不超过3个核心功能。每个功能一段话描述 + 一段验收标准。
• • 技术设计： 1小时。选技术栈 + 画模块关系图 + 列任务清单。

30分钟到1小时，完成所有前置文档。 然后直接开始写代码。

FAQ

"我不是程序员，能学会吗？"

能。我现在也不是程序员，是AI编程实践者。这套流程的核心理念是：你负责思考和决策，AI负责执行。你需要学的是"怎么跟AI沟通"，不是"怎么写代码"。

"AI写出来的代码能直接用吗？"

大部分情况下，能用。但不完美。你需要审查、测试、调整。AI写代码就像实习生干活——方向对了，细节需要你把关。

"文档写错了怎么办？"

改。文档是活的，不是死的。发现BRD的市场判断有误，更新BRD。发现PRD的功能优先级不对，调整PRD。文档的价值不在于"写对"，在于"让你有东西可以改"。

"一个人做产品，哪个阶段最耗时？"

开发阶段（阶段6）。通常占总时间的40-60%。但如果你用了AI辅助编码，这个时间能缩短到原来的1/3到1/2。

"做完MVP后发现方向错了怎么办？"

恭喜你，你只花了2-4周就验证了一个不成立的方向。如果没走这个流程，你可能花了3个月才发现。快速失败是独立开发者最重要的能力。

"怎么判断产品该不该继续做？"

三个信号。第一，有用户自发使用（不是你求来的）。第二，有用户愿意付费。第三，有用户主动推荐给别人。如果上线30天三个信号一个都没有，认真考虑要不要转向。

实操框架：从今天开始

三步，今天就能启动

① 确定一个产品想法。 不用完美，不用纠结。你最近遇到什么问题？有没有一个工具你觉得"这也太难用了"？那就是你的起点。

② 让AI帮你做调研。 打开Claude Code或者任何AI对话工具，输入这句话：

帮我做一个 [你的产品想法] 的市场调研。
分析：目标用户是谁、现有竞品有哪些、市场空间多大、机会在哪里。

③ 确认MVP功能。 调研做完了，砍功能。只留3个核心功能，其他全部扔进"未来可能做"的列表。

不要等完美再开始。先走通一遍流程，哪怕做出来的东西很粗糙。

粗糙的第一个版本，比永远停留在脑子里的完美想法，值一百倍。

最小行动

如果上面的三步你还是觉得多，那就只做一件事：

现在打开AI，说："我想做一个XX工具，帮我分析一下市场。"

这一句话，就是你的第一步。剩下的，走一步看一步。

对比：有流程 vs 没流程

数字会说话

我把自己做PNG部落的经历拆成了两组数据，你看看区别：

没流程（早期尝试）：

• • 没有调研，觉得AI生图是风口就直接做
• • 没有PRD，想到什么功能就加什么
• • 代码写了删、删了写，版本管理一塌糊涂
• • 结果：3个月做了个半成品，上线后没人用
• • 浪费时间：约200小时

有流程（后来的产品）：

• • 先做市场调研，2小时确认方向
• • BRD + PRD加起来4小时
• • 技术设计2小时，任务拆解1小时
• • AI辅助开发，2周完成MVP
• • 结果：上线第一周就有自然用户
• • 总投入时间：约80小时

同样的想法，有流程和没流程，差了2.5倍的时间。

有AI vs 没AI

再说一个对比。我在2024年初和2025年底分别做过两个类似复杂度的项目：

AI不是替代你思考，是替代你执行。 思考的事你来，执行的事交给它。

思维迁移：这套流程不只做产品

这篇文章讲的是做产品，但我想让你看到一个更底层的东西。

核心不是"做产品"，是"把复杂问题拆成可执行的步骤"。

这个能力可以迁移到任何事情上。

写公众号文章？选题→骨架→正文→优化→发布。我每篇文章都走这个流程。

做一门课程？确定主题→列出大纲→逐节录制→剪辑→上线。也是一样的。

做社群运营？明确定位→制定规则→策划活动→数据复盘→迭代优化。

任何你看着觉得"好复杂我做不到"的事情，拆成10个小步骤之后，每个步骤都不难。

难的是拆的那一步。而这，恰恰是AI最能帮到你的地方——你说目标，AI帮你拆。

这就是通用的工程思维。

成长路径

入门：走一遍

照着这篇文章，做一个你的第一个产品。不用创新，不用做得多好，关键是完整走一遍10个阶段。

走完之后你会知道：每个阶段要产出什么，遇到卡点怎么绕过去，哪些地方AI能帮上忙。

这一步的目标不是"做出一个成功的产品"，是"建立对流程的体感"。

进阶：学方法论

走完第一遍之后，开始学每个阶段的"正确做法"。

PRD到底该怎么写？去读优秀产品的PRD模板。技术设计怎么画架构图？学一下基本的UML。怎么用Claude Code的Plan Mode？这是AI辅助开发的高阶玩法——让AI先规划任务列表，你确认后再逐个执行。

书单推荐

最后给你四本书，都是我自己读过的、真正改变了我做事方式的书：

《启示录》 —— 产品管理圣经。它告诉你产品经理到底在做什么，为什么"做正确的产品"比"正确地做产品"重要十倍。

《人月神话》 —— 软件工程经典。它解释了为什么"往一个延期的项目里加人只会让它更延期"，理解了这个道理，你就不会再犯"加人加速"的错误。

《疯传》 —— 为什么有些产品自带传播力，有些砸钱推广也没人用？这本书把传播的底层逻辑讲透了。

《Spec-Driven Development》 —— Addy Osmani的方法论。这是AI编程时代的工程实践指南，教你如何用规格文档驱动开发，让AI和人类在同一个上下文里协作。

每本都值得读两遍。