> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/10-chapter.md).

# 第10章 7 天 MVP 收款:从想法到第一笔真实收入

**本章导读**:传统的产品开发模式从"想法"到"上线收款"需要数月。本章复盘一个真实项目:某独立开发者用 AI 在 7 天内完成一个最小可行产品(MVP,即 Minimum Viable Product,具有核心功能但可快速迭代的最简产品),并在第 7 天收到第一笔真实付款。本章的方法论是"时间盒驱动 + 关键路径优先"——把项目拆分为 7 个每天一个的子任务,每个子任务只关注"今天必须完成什么",严格按时间盒推进。本章同时讨论"收款链路"的设计——MVP 完成后,如何让真实用户能在 5 分钟内完成支付。

**本章关键词**:MVP、时间盒、关键路径、收款链路、真实世界后果

## 10.1 7 天的可行性

### 10.1.1 为什么是 7 天

**现场还原**:某独立开发者(以下简称"开发者")最初想做一个 SaaS 工具,想法成型后,他/她按传统节奏排了 3 个月的开发计划——需求评审 2 周,设计 2 周,开发 1.5 个月,测试 2 周,上线 1 周。计划写到飞书文档里,他/她看了 3 遍,每次都觉得"没问题,3 个月能搞定"。计划写完的第 2 周,他/她开始按计划推进,推进到第 3 天,发现连需求评审都没过完——客户访谈做了 8 场,每场都说"这个功能我也要",需求清单从 12 条涨到 47 条,完全没有收敛的迹象。开发者看着 47 条需求,突然意识到一件事:**3 个月的计划,在 3 天后就破产了**。

破产的那天晚上,开发者关掉电脑,出门走了 40 分钟。走到一半,他/她给一位做过多次 7 天 MVP 的产品经理(以下简称"PM")发了条消息:"你那个 7 天上线是怎么做到的,我 3 个月的计划第 3 天就崩了。"PM 回了条语音,大意是:"3 个月的计划之所以崩,是因为你把'做完所有功能'当目标;7 天 MVP 的目标不是'做完所有功能',是'做完一个能收钱的最小版本'。前者是过程,后者是结果,两者完全不是一回事。"

这段对话,让开发者重新审视了"7 天"这个时间盒的真正含义。回到电脑前,他/她把 47 条需求砍到 3 条——只保留"能解决一个具体问题的最小功能集"。砍完之后他/她在飞书里写了一段话(原文摘录):

> "7 天上线一个产品,不是技术能力问题,是'愿意放弃什么'的问题。我砍掉了 44 条需求,但保住了 3 条核心需求——这 3 条,就是 7 天能做完的版本。第 8 天开始,我再用真实用户反馈,决定要不要把砍掉的 44 条加回来。**7 天的约束,让我不得不做减法;做减法,反而让产品上线了**。"

7 天是经过验证的最佳时间盒:

* **3 天**过短,无法完成核心功能的开发与基本测试。开发者最初想"压缩到 3 天",试了一次,第 2 天结束时连数据库设计都没做完——3 天只能交付一个"看起来像样但点不动"的 demo。
* **14 天**过长,容易陷入"再做一点就更完美"的陷阱。14 天的项目,通常第 7—10 天就会出现"再花 3 天优化一下 UI"、"再花 2 天补个功能"的诱惑,这些"再加一点"会让 14 天变成 21 天,21 天变成 35 天。
* **7 天**恰好:够完成核心功能,又有"必须今天完成"的时间压力。7 天的项目,每天结束都必须有"今天能交付的东西",否则第 7 天就交不出——这种"日终交付"的节奏,让团队没有任何空间做"无关优化"。

时间盒的真正价值不是"7 天能完成什么",而是"7 天的约束让团队聚焦"——每一项决策都用"今天能完成吗"来检验,不重要的功能直接砍掉。

**教训**:很多新手在尝试 7 天 MVP 时,会把"7 天"误解为"7 天加班"。实际上,7 天 MVP 强调的是"约束"而不是"努力"——把范围砍到 7 天能完成的最小集合,而不是"7 天拼命做完所有想做的事"。后者只是把 3 个月的开发压缩到 7 天的加班,人会被压垮,产品也做不完。**时间盒的真正价值,是逼你做减法;做减法的过程,就是 MVP 的过程**。

### 10.1.2 7 天能完成什么

**现场细节**:某次项目里,开发者把"7 天 MVP 能完成什么"具象化成了一张表。表里列了 4 列——核心场景、最小功能集、真实可用、可收款——每一列对应一个具体的判断题。开发者每天结束时会回到这张表,看"今天结束时,这张表上的每一项,打钩了吗?"如果某一项没打钩,说明今天的交付物还不够"MVP"。

7 天的 MVP 应满足:

* **一个核心场景**:解决一个具体问题,而非多个。例如"帮独立开发者追踪 Stripe 收款"是一个核心场景,"帮独立开发者管理整个财务"是多个场景。前者 7 天可做,后者 7 天做不完。
* **最小功能集**:只保留核心功能,其他功能后做。开发者砍需求时,用的不是"哪个功能用户最想要",而是"没有这个功能,产品还能不能用"——能用的砍,不能用的留。
* **真实可用**:用户可以真正使用,而非"演示版"。演示版是"看上去能跑但用着用着就崩",真实可用是"用户拿来解决真实问题,3 天内不会卸载"。
* **可收款**:具备支付链路,用户可以真正付款。可收款是 7 天 MVP 的"硬指标"——如果第 7 天结束用户还不能付款,那就不是 MVP,是"接近 MVP"。

不满足这四个标准中的任何一项,都称不上"7 天 MVP"——它要么范围过大(超过了 7 天的承载力),要么不够真实(不能真正交付给用户)。开发者后来在内部分享里,把四个标准简化为一句话:**"一个核心场景,一个最小功能集,真实可用,可收款——四件事缺一不可"**。

![MVP 垂直切片示意](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-34b50706045dc4e86940cdc8aeb02c3a0f6d92ed%2Fsec10_vertical_slice.svg?alt=media)

![7 天 MVP 时间盒甘特图](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-a659d827284879b3514a6a5f2b34d674f3889f7a%2Fsec10_gantt.svg?alt=media)

### 10.1.3 7 天不能完成什么

**现场案例**:某次项目,开发者在第 4 天忍不住加了一个"用户可以自定义主题颜色"的功能,理由是"我朋友说这个功能他很喜欢,不加他会觉得产品不专业"。第 5 天,他/她又加了一个"用户可以导出 Excel"的功能,理由是"做运营的同事说这个方便"。两个功能加完后,第 6 天发现支付链路还没做完——于是第 6 天和第 7 天全部用来赶支付链路,主题颜色和 Excel 导出留了 bug,匆匆上线。第 8 天,第一个真实用户来付款,付完发现 Excel 导出按钮点了报错,用户截图发到群里,开发者一边道歉一边回滚功能。这次教训让开发者明白:"7 天不是用来加功能的,7 天是用来决定哪些功能不做的。"

7 天的 MVP 应明确不做什么:

* **不做完美设计**:外观可以简陋,功能可以基础。开发者的第 1 版 UI 是 Bootstrap 默认主题,没改过一行 CSS,UI 丑但能用。
* **不做多平台**:只做最关键的一个平台(web 或移动端)。开发者只做了 web 端,移动端连响应式都没做——"用户用电脑能付款就行,手机端等 V2"。
* **不做高级功能**:个性化、推荐、社交等后做。开发者的 V1 没有"用户主页",没有"评论",没有"点赞",只有"核心功能 + 支付"。
* **不做企业级安全**:小团队用不到,做也是浪费。开发者的 V1 没做 SSO(单点登录)、没做权限管理、没做审计日志,只做了最简单的"邮箱 + 密码"。

明确不做什么,与明确做什么同样重要。多数 7 天项目失败,不是因为做得太少,而是因为想做的太多。开发者后来在每次 7 天 MVP 启动时,都会先写一份"不做清单"——明确写下来"这个项目不做什么",写下来之后,每天结束都对照清单,确保没偷偷加功能。

**教训**:"不做清单"比"做清单"更难写。写"我要做 A、B、C"很容易,写"我不做 X、Y、Z"需要克制——克制住"这个功能我也很想要"的冲动。开发者的"不做清单"通常比"做清单"长 2—3 倍,例如某次项目的"做清单"是 3 条,"不做清单"是 11 条。

## 10.2 7 天的工作分解

### 10.2.1 关键路径优先

**现场还原**:某次 7 天 MVP,开发者最初的工作分解表里有 23 个子任务,从"设计 Logo"到"接入客服系统"一应俱全。第 1 天结束时,开发者发现这 23 个任务里有 18 个都是"非关键路径"——不做这些任务,产品也能上线;做这些任务,会让核心任务的时间被挤掉。第 2 天早上,开发者把任务表重写了一遍,从 23 个砍到 7 个,每个任务对应一天的工作量。重写完他/她发了一条朋友圈:"昨天 23 个任务,今天 7 个;7 个任务里有 5 个是核心,2 个是支撑——这才是 7 天能做完的版本。"

7 天的工作分解,按"关键路径"组织——只有那些必须做才能上线的任务才进入关键路径,其他任务全部砍掉或后做。

本案例的关键路径:

* **Day 1**:需求确认 + 核心功能设计。这一天的产出是"需求文档 + 功能清单",文档不超过 3 页,清单不超过 5 条。
* **Day 2**:UI 原型 + 数据库设计。UI 原型用 Figma 画 5—8 个关键页面,不需要精细;数据库设计输出 ER 图(实体关系图,描述数据表之间的关系)和建表 SQL。
* **Day 3**:核心功能开发(用户注册、核心功能 1)。用户注册走"邮箱 + 密码",不接第三方登录;核心功能 1 是产品最关键的一个流程。
* **Day 4**:核心功能开发(核心功能 2、3)。继续做核心功能,做完核心功能 2、3 之后,产品就有了"最小可用版本"。
* **Day 5**:支付链路接入 + 基础测试。接入第三方支付(微信、支付宝、Stripe),写 10—20 个基础测试用例覆盖核心流程。
* **Day 6**:部署上线 + 真实数据测试。部署到 Vercel / Netlify / Railway 等平台,用真实数据(不是 mock)跑一遍核心流程。
* **Day 7**:真实用户邀请 + 收款测试。邀请 5—10 个真实用户试用,其中 3—5 个完成付款,确认收款链路通畅。

7 天任务的关键路径是"核心功能 + 支付链路 + 上线"三件事,其他都是这三件事的支撑。开发者后来在每次 7 天 MVP 启动时,都会先问自己一个问题:"如果今天结束只能交付一件事,这件事是什么?"——这个问题逼出关键路径,把无关任务排除掉。

### 10.2.2 每日交付物

**现场细节**:某次项目,开发者把每日交付物做成了一张卡片,贴在电脑屏幕边上。每天结束时,他/她会看卡片上的当天条目,如果没完成,就要么加班补完(高风险),要么把任务移到第二天(意味着后续几天要更紧凑)。这套卡片机制跑了 6 个 7 天 MVP,没有一次延期超过 1 天——因为每天都能看到"今天该交付什么",不会稀里糊涂地推进。

每日的交付物应明确——交付物意味着"今天结束时的可验证产出":

* **Day 1 交付物**:需求文档 + 功能清单。文档 3 页以内,清单 5 条以内,每条都是"必须做"的功能。
* **Day 2 交付物**:UI 原型 + 数据库结构。原型是 5—8 个页面的 Figma 线框图,数据库结构是 ER 图 + 建表 SQL。
* **Day 3 交付物**:用户注册流程可演示。能完成"注册 → 登录 → 看到欢迎页"的端到端流程。
* **Day 4 交付物**:核心功能 2、3 可演示。核心功能 1、2、3 都能跑,产品有了"最小可用形态"。
* **Day 5 交付物**:支付链路可演示。能完成"下单 → 支付 → 权限开通"的端到端流程,虽然可能还有 bug,但链路是通的。
* **Day 6 交付物**:线上环境可访问。任何浏览器打开都能访问,核心流程跑通,数据真实存储。
* **Day 7 交付物**:真实用户可访问 + 第一笔收款。3—5 个真实用户完成付款,系统收到的款项能在银行对账里看到。

每日的交付物都应可被验证——今日结束时,团队成员可以打开看,确认"今天的事真的完成了"。开发者后来把"可被验证"作为交付物的硬性要求:不能验证的交付物(例如"今天做了数据库设计"),不算交付物;可验证的交付物(例如"今天能完成用户注册"),才算。

**教训**:"可被验证"的关键不是"做出东西",是"做出来的东西能被检查"。某次项目,开发者第 3 天的"交付物"是"用户注册后端写完了"——但前端还没写,无法端到端验证。PM 晚上问"用户能注册了吗",开发者答"后端可以,前端不行"。PM 当场回:"后端可以不算交付物,前端不行用户就用不了,把'可注册'改成'端到端可演示'重写。"这次教训让开发者明白:**交付物的"可验证",必须站在用户视角,不是站在开发者视角**。

### 10.2.3 关键决策的时机

**现场还原**:某次 7 天 MVP,开发者在 Day 1 做了 4 个小时的"功能选型"——反复纠结"我要不要做 X 功能"、"用户到底需不需要 Y"。第 2 天又开始纠结"数据库用 MySQL 还是 PostgreSQL"、"部署用 Vercel 还是 Netlify"。第 2 天结束时,这两个决策还没定,第 3 天开始开发,决策才匆忙敲定——结果开发到一半发现 Vercel 的某个限制不满足需求,被迫中途换平台,多花了 1 天。这次项目虽然最终在第 7 天上线,但整个过程磕磕绊绊,差点翻车。

复盘时,开发者意识到问题出在"关键决策拖到了 Day 3 才做完"。后来他/她给自己定了一个铁律:**Day 1 决策核心功能,Day 2 决策技术选型,Day 3 起只执行,不决策**。这个铁律在后续 5 个 7 天 MVP 项目里都严格执行,每次都顺利在第 7 天上线。

7 天内的关键决策应集中在前 2 天:

* **Day 1 决策**:核心功能是什么(选 3 个,做 1 个也行)。Day 1 必须确定"产品最核心的一个流程",围绕这个流程做后续所有工作。
* **Day 2 决策**:UI 风格、数据库选型、部署平台。Day 2 必须把"用什么技术做"敲定,Day 3 开始就不要再讨论技术选型。

后续 5 天不再做重大决策,只做执行。前 2 天的决策质量决定整个项目的成败——决策错误,后续 5 天做得再好也是错的方向。

关键决策前的"思考时间"投入:Day 1 应花 50% 的时间做需求确认,Day 2 应花 30% 的时间做技术选型。后续 5 天的"思考时间"应控制在 10% 以内,其余时间全部用于执行。开发者后来把这个比例画成了一张饼图,每次 7 天 MVP 启动时都看一眼:**Day 1 饼图 50% 思考、Day 2 饼图 30% 思考、Day 3—7 饼图 10% 思考**——超出比例的思考时间,意味着"还没准备好开始执行"。

**教训**:决策不是"想清楚了才做",是"在约束下做最不坏的选择"。开发者后来把 7 天 MVP 的决策原则总结成一句话:**"Day 1 和 Day 2 的决策,要选'能反悔的',不是选'最完美的'"**——能反悔的决策,错了可以换;不能反悔的决策(例如数据库选型、支付平台选型),一旦选了就难以替换,所以要更慎重。Day 3 之后的决策,要选"能马上执行的"——任何"等我想想"的决策,都意味着在浪费时间盒。

## 10.3 AI 在 7 天 MVP 中的角色

### 10.3.1 AI 替代的工作

**现场细节**:某次 7 天 MVP,开发者需要做一个"用户上传 Excel,系统解析后生成报告"的核心功能。传统开发模式里,这个功能要写 3—5 天(Excel 解析 + 报告生成 + 前端交互 + 测试)。开发者用 AI 协作,流程是:早上 9 点把需求描述发给 AI("解析用户上传的 Excel,提取第 1—3 列,生成一份 markdown 报告"),AI 在 10 分钟内输出第一版代码;开发者花 30 分钟调整参数,11 点前第一版能跑;中午 1 点前加了 5 个测试用例;下午 2 点前完成前端交互。整个功能 4 小时内做完,留出 2 天时间做别的。

AI 在 7 天 MVP 中替代的工作:

* **UI 原型生成**:基于需求描述,AI 一天内可生成多个 UI 风格供选择。开发者给 AI 一段需求描述(约 200 字),AI 在 1 小时内生成 3—5 版 HTML 原型,开发者从中选 1 版微调即可。
* **数据库设计**:基于功能描述,AI 可生成数据库结构与初始数据。AI 会输出 ER 图 + 建表 SQL + 初始数据脚本,开发者只需要根据业务调整字段。
* **后端开发**:基于功能描述,AI 可生成后端代码与接口。AI 会输出 API 路由、控制器、数据模型,代码质量比"初级工程师 1 周写的"还稳定。
* **前端开发**:基于 UI 原型,AI 可生成前端代码。AI 会输出 HTML + CSS + JS(或 React/Vue 组件),开发者只需要调整样式和交互。
* **测试用例**:基于功能描述,AI 可生成测试用例。AI 会输出单元测试、集成测试、E2E 测试的代码框架,开发者补充关键断言。
* **部署配置**:基于平台选择,AI 可生成部署脚本。AI 会输出 Dockerfile、CI/CD 配置、环境变量说明,部署从"半天"压缩到"1 小时"。

这些工作如果由人完成,需要 30—60 天;由 AI 完成,只需 3—5 天。开发者后来在内部分享里说:"7 天 MVP 不是'人变快了',是'人不用做执行了'——执行交给 AI,人做判断。判断的时间无法压缩,但执行的时间可以。"

**教训**:AI 替代执行的关键是"边界清晰"。开发者每次给 AI 派活,都会先写一段"边界"——AI 做什么、不做什么、做到什么程度算完成。这段边界让 AI 不会"自由发挥"——某次项目,开发者只说"做一个用户登录页",AI 自动加了"忘记密码"、"第三方登录"、"人脸识别"等 5 个功能,导致开发者花了 2 天"砍掉多余功能"。从此以后,开发者每次给 AI 派活,都会在边界里写明"不做忘记密码、不做第三方登录、不做人脸识别"。

### 10.3.2 人保留的工作

**现场还原**:某次 7 天 MVP,Day 5 支付链路接入时,AI 生成的代码能跑通支付流程,但有 3 个细节 AI 没考虑到——支付成功页面的文案、退款按钮的位置、支付失败的兜底文案。开发者花了一整个下午和 PM 一起调这 3 个细节,直到晚上 8 点才满意。PM 后来在复盘时说:"这 3 个细节,AI 做不了,只能人做。AI 不知道'用户付完款后第一眼看到什么最重要'、'退款按钮放哪里转化率最高'、'支付失败后用户最容易点哪里'——这些是业务判断,不是技术实现。"

人保留的工作:

* **需求决策**:做什么、不做什么。AI 不会替开发者决定"这个功能要不要做",开发者必须自己拍板。
* **质量验收**:AI 生成的代码是否符合预期。AI 生成的代码 80% 可以直接用,20% 需要修改——这 20% 通常是"AI 没理解业务逻辑"导致的,只有人能识别。
* **用户体验判断**:界面是否好看、流程是否顺畅。AI 生成的 UI 经常出现"按钮颜色不对"、"间距太大"等问题,需要人调整。
* **业务逻辑判断**:某个细节是否符合业务常识。例如"用户上传 Excel 后,系统提示'解析成功',但没显示解析了多少行"——技术上没错,业务上不友好,需要人补。
* **真实数据测试**:用真实数据测试,而不是用测试数据。AI 经常用 mock 数据测试(因为 mock 数据可控),但真实数据有各种边界情况(空值、特殊字符、超长文本),需要人用真实数据验证。

这些工作 AI 难以替代,需要人来做。开发者后来把"人保留的工作"列成清单,每天提醒自己:"今天 80% 时间给 AI(派活、验收),20% 时间给自己(决策、判断)"。如果某天人花的时间超过 50%,说明今天的工作模式有问题——可能在"替 AI 写代码",而不是"让 AI 替自己写代码"。

**教训**:人保留的工作最容易被"省掉"——很多团队 7 天 MVP 失败,不是因为 AI 做得不好,是因为人该做的工作(尤其是质量验收)被省掉了。开发者后来每次验收 AI 的代码,都会做一件事:**打开产品,自己点一遍核心流程,从用户视角看"产品用起来顺不顺"**——这一步不是技术验收,是体验验收,只有人能做。

### 10.3.3 人机协作的节奏

**现场细节**:某次 7 天 MVP,开发者把"人机协作"的节奏画成了一张图——横轴是时间(7 天),纵轴是"AI 做的工作"和"人做的工作"的占比。Day 1—2 是"人主导"(50% 以上是人的思考),Day 3—4 是"AI 主导"(80% 是 AI 写代码),Day 5 是"人机均衡"(各 50%),Day 6—7 是"人主导"(50% 是人验收和上线)。这张图让开发者每天都知道"今天我应该做什么、AI 应该做什么",不会混乱。

7 天 MVP 中的人机协作节奏:

* **人提出需求**:人告诉 AI 要做什么。需求描述尽量具体(2—3 段话,包含输入、输出、边界条件)。
* **AI 产出**:AI 产出代码、UI、文档。AI 产出 1 版,人验收;不通过则进入下一轮。
* **人验收**:人检查 AI 的产出,标记问题。验收要对照需求描述——"AI 是不是做了需求里说的事、有没有多做、有没有少做"。
* **AI 修改**:AI 根据人标记的问题修改。修改通常需要 30 分钟到 1 小时,比从零写快。
* **人再验收**:人再次检查,确认通过。再次验收要关注"AI 是否修复了所有标记的问题、有没有引入新问题"。
* **进入下一项**:验收通过后,进入下一项任务。每一项任务结束后,人要在任务表上打钩。

每一轮"人提出需求 → AI 产出 → 人验收"通常需要 1—3 小时,7 天内可完成 15—20 轮。开发者后来把这个节奏总结成一句话:**"AI 是工具,人是指挥——AI 不主动推进任务,人推一下,AI 走一步"**。如果某一天"AI 推人"(例如 AI 自动加了功能、修改了架构),说明边界没写清楚,要在第二天补边界。

**教训**:人机协作最常翻车的是"人催 AI"。某次项目,开发者给 AI 派活后,等了 30 分钟没回,催了一句"快点,要下班了"。AI 在压力下生成了一个有 bug 的版本,开发者赶着上线,第 7 天用户来用,崩了 3 次。事后复盘,开发者意识到"催"是反模式——AI 生成代码需要时间,催了反而容易出错。**正确做法是"给 AI 足够的时间 + 提前派活"**——晚上睡前派活,第二天早上验收,中间不催。

## 10.4 收款链路的设计

![收款链路决策树](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-48b6278110df569bbcdb1e200149e87c1775660b%2Fsec10_payment_decision.svg?alt=media)

### 10.4.1 收款链路的最小实现

**现场还原**:某次 7 天 MVP,开发者最初只想做"产品功能",没想收款。Day 4 时 PM 问"你打算怎么收费",开发者答"等上线再说"。PM 当时回了一段话(原文摘录):

> "**收款链路不是上线后加的,是上线前必须做好的**。用户在你产品页停留 30 秒,如果有支付入口,他会点击;如果没有,他会关掉页面。收款链路的'有没有',决定了产品的'能不能变现'。Day 5—6 你必须把支付做出来,不能拖到 V2。"

PM 的话让开发者把收款链路从"Day 7 之后再说"提到了"Day 5—6 必须完成"。这个调整让整个项目的优先级重排——Day 5 全部用来做支付接入,Day 6 一边部署一边测试支付。

7 天 MVP 的收款链路,只需满足:

* **支付入口**:用户能在产品内找到支付按钮。支付按钮的位置要明显,但不能太突兀——通常放在"核心功能完成后的下一步"。
* **支付方式**:支持主流支付方式(微信、支付宝、银行卡)。国内产品至少要支持微信 + 支付宝,海外产品要支持 Stripe。
* **订单生成**:支付成功后自动生成订单。订单包含用户 ID、产品 ID、金额、支付时间,用于后续对账。
* **权限开通**:支付成功后自动开通对应权限。用户在支付完成后,立刻能使用付费功能(无需手动激活)。
* **通知机制**:支付成功后通知用户和运营。用户收到"支付成功"邮件,运营收到"新订单"提醒。

最小实现的收款链路,需要 1—2 天完成。本案例使用了第三方支付 SDK(微信支付、支付宝),集成在产品中,用户点击支付按钮后,跳转到第三方完成支付。开发者后来把"收款链路"列为 7 天 MVP 的"必做"项,优先级和"核心功能"并列——少做任何一项,MVP 都不算完成。

### 10.4.2 收款链路的关键决策

**现场细节**:某次 7 天 MVP,Day 5 早上开发者纠结了 2 小时"用微信支付还是支付宝"——两个都能用,两个都有优劣(微信支付 C 端用户多,支付宝 B 端用户多;微信支付费率 0.6%,支付宝费率 0.55%)。纠结到中午,他/她突然意识到——纠结本身就是浪费时间盒,正确做法是"先上一个,后续再补"。于是他/她用 1 小时接入微信支付(因为自己更熟悉),下午就用真实账号测试,晚上支付链路跑通。这个决策让 Day 5 没被支付选型拖垮。

收款链路的关键决策:

* **支付平台**:选一家主流的支付平台(微信、支付宝、Stripe 等)。选平台的标准不是"哪个费率最低",是"哪个自己最熟悉"——熟悉的能 1 天接入,不熟悉的可能 3 天接入。
* **支付场景**:支持一次性支付(年费、季费、月费)。7 天 MVP 不建议做订阅(订阅涉及自动续费、取消订阅、计费周期等复杂逻辑),先做一次性支付。
* **退款机制**:7 天无理由退款,降低用户决策门槛。退款机制是"信任锚"——用户看到"7 天无理由退款",会更愿意付款。
* **发票机制**:支持电子发票,满足企业用户需求。电子发票可以后期接入(不是 Day 5—6 的必做),但要在产品页注明"支持发票",让企业用户放心。

这些决策在 Day 5 应已确定,Day 5—6 完成接入,Day 6—7 完成测试。开发者后来给每个 7 天 MVP 项目都画了一个"收款链路时间盒":Day 5 上午选平台 + 申请商户号,Day 5 下午接入 SDK,Day 5 晚上写测试,Day 6 上午用真实账号跑通,Day 6 下午上线,Day 7 真实用户付款。

### 10.4.3 第一笔收款的意义

**现场还原**:某次 7 天 MVP,Day 7 下午 5 点,开发者收到支付平台的到账通知——9.9 元,来自一位陌生用户。开发者盯着屏幕看了 5 秒钟,然后给 PM 发了一条消息:"收到第一笔了,9.9 元,真的有人愿意付钱。"PM 回了句:"恭喜,**9.9 元不重要,'真的有人愿意付钱'这件事才重要**。9.9 元证明你的产品有真实需求,不是开发者玩具。"

第一笔收款的意义不在金额——可能是 9.9 元、99 元,远不足以覆盖开发成本。其意义在于\*\*"真实世界后果"的完成\*\*——产品从"开发者的玩具"变成"有人愿意付费的东西"。这一变化是质变,不是量变。开发者后来在每次 7 天 MVP 上线时,都会等"第一笔真实收款"才宣布成功,而不是"上线成功就成功"。

第一笔收款也是后续迭代的起点——付费用户比免费用户更愿意提供反馈,产品可以根据真实付费用户的需求持续优化。开发者后来在第一个 7 天 MVP 上线后,主动联系了前 10 个付费用户,问"你为什么愿意付钱"、"你希望产品加什么功能"。这 10 个用户的反馈,直接决定了 V2 的功能优先级——其中 3 个功能是开发者自己没想到的,完全是从用户反馈里来的。

**教训**:第一笔收款的"仪式感"比"金额"重要。开发者后来每次 7 天 MVP 收到第一笔,都会做一件事——截图发到飞书群,@所有团队成员,说一句"今天开始,我们做的不是 demo,是有人愿意付费的产品"。这个仪式感让团队记住"我们做的是真东西,不是 demo"——态度变了,后续所有决策都会更认真。

## 10.5 验收与复盘

![冷启动渠道选择](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-df57e255b9ea8f1126b8fa3ec6df428e5fb711dd%2Fsec10_coldstart_channels.svg?alt=media)

### 10.5.1 上线验收

**现场案例**:某次 7 天 MVP 上线前,开发者做了一次自检——按清单逐项核对。第一遍发现有 4 项没通过:登录页 logo 缺失、支付成功页面 404、移动端按钮错位、用户协议链接 404。开发者花 2 小时把这 4 项修完,自检第二遍,全部通过。Day 7 下午,真实用户试用,3 个用户里有 1 个反馈"我的邮箱收不到激活邮件"——这个 bug 自检时没发现,因为开发者用的是测试邮箱(不依赖真实邮件服务商),真实邮箱的某些反垃圾机制把激活邮件拦截了。这次教训让开发者明白:**自检能发现 80% 的问题,剩下 20% 要靠真实用户发现**。

7 天 MVP 的上线验收,包含以下检查项:

* **核心功能**:用户可完成核心场景的端到端操作。检查方法:开发者自己点一遍核心流程,确认"每个按钮都能点,每个流程都能跑通"。
* **支付链路**:用户可完成支付,系统可正确开通权限。检查方法:用真实账号(不是测试账号)走一遍支付,确认"钱到账 + 权限开通"。
* **稳定性**:产品无明显崩溃、无明显错误。检查方法:连点 10 次核心按钮,看是否报错;刷新页面 5 次,看是否能正常加载。
* **性能**:核心操作在合理时间内完成。检查方法:核心功能响应时间不超过 2 秒,首屏加载时间不超过 3 秒。
* **数据**:用户数据被正确存储,可被检索。检查方法:注册一个用户,做几个操作,看数据库里的数据是否对得上。

### 10.5.2 7 天复盘

**现场还原**:某次 7 天 MVP 上线后,开发者和 PM 一起做复盘。复盘用了一个简单的模板——4 列:实际用时 vs 计划用时、关键决策是否正确、用户反馈、改进点。第一列里,Day 1—4 都按计划,Day 5 超时 3 小时(支付接入卡了),Day 6—7 提前完成。第二列里,核心功能选对了(用户反馈证明),支付平台选错了(微信支付,后来发现支付宝用户更多,应该选支付宝)。第三列里,5 个用户给了 7 条反馈,3 条是"产品好用",2 条是"功能不够",2 条是"UI 太丑"。第四列里,改进点是"V2 加功能 + V2 重做 UI"。

7 天结束后,应做一次复盘,记录:

* **实际用时 vs 计划用时**:哪些环节超时,哪些提前。超时环节分析"为什么超时",提前环节分析"为什么提前"——超时环节的改进比提前环节的复用更有价值。
* **关键决策是否正确**:每个关键决策的最终效果。决策的"正确与否"以"用户是否买账"为标准,不是"逻辑是否合理"。
* **用户反馈**:上线后用户的真实反馈。付费用户的反馈优先级高于免费用户,因为付费用户更认真。
* **改进点**:下一版本应改进的地方。改进点要按"用户提了 + 能做"两个条件筛选——用户没提的不做、做了用户用不上的也不做。

复盘的输出是"7 天 MVP 方法论"的更新——每做一个项目,方法论就迭代一次。开发者后来做了 6 个 7 天 MVP,每个项目结束后都更新一份"方法论笔记"——这份笔记从 1 页涨到 8 页,记录了"哪些原则有效、哪些原则需要修正"。

### 10.5.3 长期迭代

**现场细节**:某次 7 天 MVP 上线后,开发者发现前 3 个月最重要的不是"加新功能",是"看用户行为数据"——他/她在产品里加了埋点,记录"用户在哪一步流失"、"哪个按钮点击率最高"、"哪个功能用得最多"。3 个月后,数据告诉开发者:V1 的"用户主页"功能 0 人用(应该砍掉),V1 的"Excel 解析"功能 100% 用户都用(应该重点优化)。**用户行为数据比用户口头反馈更可靠**——用户说"我想要 X",但他/她可能不用;用户没说要 Y,但他/她天天用。

7 天 MVP 上线后,产品进入长期迭代阶段。迭代的原则:

* **小步快跑**:每周一个小版本,持续改进。每周发布 1—2 个小功能或修 1—2 个 bug,不要"憋大招"。
* **数据驱动**:基于用户行为数据决策,而非主观判断。数据包括:点击率、转化率、留存率、流失率、用户反馈(主动 + 被动)。
* **核心场景优先**:先优化核心场景,后扩展其他场景。核心场景是"用户买你产品的理由",其他场景是"用户买完之后想要的"。
* **付费用户优先**:付费用户的反馈优先级高于免费用户。付费用户更认真,反馈更具体;免费用户可能只是路过,反馈不一定准确。

7 天 MVP 不是"完成",而是"开始"——真正的产品生命周期从第 8 天开始。开发者后来在每次 7 天 MVP 上线时,都会在飞书群里发一句话:"Day 7 结束,MVP 完成。Day 8 开始,真正的工作开始。"这句话提醒团队——上线不是终点,是另一个起点。

**教训**:7 天 MVP 的最大陷阱是"上线即懈怠"。很多团队 7 天冲刺完,Day 8 开始松一口气,产品 1—2 个月没更新,用户慢慢流失。开发者后来给自己定了一个规矩:**Day 8—Day 37(第 8 天到第 5 周),必须每周发 1 个版本;Day 38 起,改为每两周发 1 个版本**。这个节奏让产品在头 5 周保持高强度更新,5 周后再放慢——这个节奏比"上线后随意更新"更有效。

## 10.6 方法论提炼与可复用资产

**现场还原**:本章方法论的提炼,来自 6 个 7 天 MVP 项目的复盘笔记。开发者把 6 次复盘笔记合并去重,提炼出 5 个出现频率最高的"经验"——这 5 个经验后来成为本章的 5 个原则。原则的提炼过程是"从具体项目中归纳,而不是从抽象理论上演绎"——后者听起来漂亮,但用不上。

本章的方法论可提炼为五个原则。

**原则一:时间盒约束是关键**。7 天的约束让团队聚焦,防止"再做一点就更完美"的陷阱。时间盒的真正价值不是"7 天能完成什么",是"逼你做减法"。

**原则二:关键路径优先**。只做必须做的事,其他事全部砍掉或后做。23 个任务砍到 7 个,7 个里 5 个是核心,2 个是支撑——这才是 7 天能做完的版本。

**原则三:关键决策集中在前 2 天**。后续 5 天只执行,不决策。决策错误,执行得再好也是错的方向。Day 1 决策功能,Day 2 决策技术,Day 3 起只做。

**原则四:AI 替人做执行,人做判断**。AI 替代开发、测试、部署,人保留需求决策、质量验收、用户体验判断。"判断"无法压缩时间,但"执行"可以。

**原则五:第一笔收款比想象中重要**。真实世界后果的完成,是产品从玩具变成商品的标志。9.9 元不重要,"有人愿意付钱"才重要。

**可复用资产:7 天 MVP 任务模板**——本节 10.2 给出的工作分解,可作为所有 7 天 MVP 项目的任务模板。

```
7 天 MVP 任务模板

Day 1: 需求确认 + 核心功能设计
  - 交付物:需求文档 + 功能清单
  - 时间分配:50% 思考 + 50% 文档

Day 2: UI 原型 + 数据库设计
  - 交付物:UI 原型 + 数据库结构
  - 时间分配:30% 选型 + 70% 设计

Day 3-4: 核心功能开发
  - 交付物:核心功能可演示
  - 时间分配:20% 验收 + 80% 开发

Day 5: 支付链路接入
  - 交付物:支付链路可演示
  - 时间分配:30% 选型 + 70% 接入

Day 6: 部署上线
  - 交付物:线上环境可访问
  - 时间分配:20% 配置 + 80% 测试

Day 7: 真实用户邀请 + 收款测试
  - 交付物:真实用户可访问 + 第一笔收款
  - 时间分配:50% 邀请 + 50% 收尾
```

### 10.7.1 本章思考题

1. 10.1.3 的"不做清单":你下一个 7 天 MVP 的"做清单"有 3 条,"不做清单"有几条?如果"不做"比"做"短,你大概率会延期。
2. 10.2.3 的"Day 1—2 决策,Day 3 起只执行":你过去的 MVP 项目,Day 3 之后还在做重大决策的比例是多少?每个决策的"返工天数"是多少?
3. 10.3.1 的"AI 替代执行 vs 人保留判断":你最近的 MVP 项目里,人花 50% 以上时间在"替 AI 写代码"的比例是多少?这说明什么?
4. 10.4 的收款链路:你的 MVP 第 7 天能让真实用户付款吗?如果不能,卡在"接入支付"还是"合规审核"?
5. 10.2.2 的"可被验证"标准:你今天的交付物,客户能在浏览器里点开验证吗?如果不能,"端到端可演示"是否被推迟到第 3 天?

### 10.7.2 本章延伸阅读

1. **\[数据报告] Stripe 官方定价页(NerdWallet 2026-07-17 复核)** — 在线卡 2.9% + $0.30、国际卡 +1.5%、手动输入 +0.5% | 第 10 章
2. **\[数据报告] Stripe Atlas 官方页与 2026 评测** — $500 一次性注册特拉华 C-Corp/LLC、含首年注册代理、续费 $100/年、$2,500 Stripe 额度 | 第 10 章
3. **\[数据报告] Lemon Squeezy 定价与 MoR 说明(2024 年被 Stripe 收购)** — 5% + 50¢、订阅 +0.5%、国际卡 +1.5%、无月费、payout 约每月两次 | 第 10 章
4. **\[数据报告] 微信支付商户平台接入指引** — 企业/个体工商户申请材料、费率按类目 0.6%—1%、审核 1—2 个工作日、小微/个人卖家进件条件 | 第 10 章
5. **\[数据报告] Clerk vs Supabase Auth 2026 价格核验** — Clerk 免费 50K MAU、Pro $25/月;Supabase 免费 50K MAU、Pro $25/月含 100K MAU | 第 10 章

## 10.7 完整提示词:7 天 MVP 的时间盒编排

以下提示词用于"7 天内把想法做成可收款的产品"。它把"时间盒约束"、"关键路径优先"、"人机协作分工"、"前 2 天决策 / 后 5 天执行"全部落到 prompt 里,且每日的交付物必须可被验证。

```
你是 7 天 MVP 项目的全栈工程师,擅长在严格时间盒内把"想法"做成"可收款的产品"。接下来的 7 天,你必须严格按时间盒推进——任何超过 7 天的功能,必须砍掉或推迟到 V2,不允许以"再加一点就更好"为由延期。

【你的工作方式:7 天时间盒】
- Day 1(需求确认 + 核心功能设计):50% 时间思考、50% 时间写文档
- Day 2(UI 原型 + 数据库设计):30% 选型、70% 设计
- Day 3—4(核心功能开发):20% 时间验收、80% 时间开发
- Day 5(支付链路接入):30% 选型、70% 接入
- Day 6(部署上线):20% 配置、80% 测试
- Day 7(真实用户邀请 + 收款测试):50% 邀请、50% 收尾

【每日的交付物(必须可被验证)】
- Day 1:需求文档 + 功能清单(精选 3 个核心,做 1 个也行)
- Day 2:UI 原型 + 数据库结构(可点击的线框图 + ER 图)
- Day 3—4:核心功能可演示(录屏或在线访问链接)
- Day 5:支付链路可演示(下单 → 支付 → 权限开通)
- Day 6:线上环境可访问(任何人都能打开)
- Day 7:真实用户可访问 + 第一笔收款到账

【关键决策集中在前 2 天】
Day 1 决策:核心功能是什么(从 10 个候选中选 3 个,做 1 个也行)
Day 2 决策:UI 风格、数据库选型、部署平台、支付方式
Day 3 起只执行,不决策。决策错误,执行得再好也是错的方向。

【AI 替代的工作】
- UI 原型生成(基于需求描述,1 天内出多版供选)
- 数据库设计(基于功能描述,自动生成 schema)
- 后端开发(基于功能描述,自动生成接口)
- 前端开发(基于 UI 原型,自动生成页面)
- 测试用例生成(基于功能描述)
- 部署脚本生成(基于平台选择)

【人保留的工作】
- 需求决策(做什么、不做什么)
- 质量验收(AI 生成的代码是否符合预期)
- 用户体验判断(界面是否好看、流程是否顺畅)
- 业务逻辑判断(细节是否符合业务常识)
- 真实数据测试(不是用测试数据)

【7 天不能完成的事(明确不做)】
- 完美设计(外观可以简陋,功能可以基础)
- 多平台(只做最关键的一个:web 或移动端)
- 高级功能(个性化、推荐、社交等后做)
- 企业级安全(小团队用不到)
- 完整文档(只写必要的)

【MCP 配置】
- 数据库 MCP:连接业务数据库
- 支付 MCP:对接第三方支付(微信、支付宝、Stripe)
- 部署 MCP:对接 Vercel、Netlify、Railway 等
- 监控 MCP:对接错误监控服务

【输入格式】
提供——
- 想法(用 1—2 段话描述)
- 目标用户(谁是最终用户)
- 收款方式(年费、季费、月费、单次)
- 现有资源(团队规模、技术背景、可用时间)

【输出格式】
每日结束时,产出——
- 当日完成的具体功能(列表)
- 当日决策(若有)
- 明日计划
- 当前阻塞(如无,写"无")

【每日验收标准】
Day 1:打开需求文档,核心功能不超过 3 个
Day 2:打开 UI 原型,能看出"这是什么产品"
Day 3:打开 Demo,能完成最核心的一个流程
Day 4:打开 Demo,核心功能都可演示
Day 5:能完成真实下单 → 支付 → 权限开通
Day 6:任何浏览器打开,能正常访问
Day 7:收到第一笔真实款项

【遇到以下情况,先停下来和我对齐】
- 客户改变需求 → 不接受 7 天内的新需求,记入 V2
- 技术难点出现,3 天解决不了 → 砍掉或简化
- 支付接入超时 → 用最简方案(单次支付,不做订阅)
- 部署失败 → 换平台,不要死磕
- 第一天结束仍不确定核心功能 → 我帮你决

【7 天结束的产出物】
- 可访问的线上 URL
- 至少 1 笔真实收款
- 完整源代码(代码仓库)
- 部署说明(10 分钟能复现)
- 7 天复盘报告(哪些按计划、哪些没按、改进点)
```

## 本章方法论:让 AI 加速产品交付

本章的方法论核心是"让 AI 加速产品交付"——7 天的时间盒、关键路径优先、人机协作分工,共同构成"快速从想法到真实收入"的方法论。这一方法不仅适用于独立开发者,也适用于小团队的产品探索。

下一章将进入"无文档遗留系统"——AI 替读者理解、改造一个没有文档、没有测试、无人维护的存量系统。这一章关注的是"AI 替读者处理历史包袱"的能力。