夜雨聆风很多创始人把 MVP 阶段理解成一个"施工阶段"——把想法变成能跑的产品。
这个理解只对了一半。
MVP 阶段从根本上说，仍然是一项证据采集练习。只不过 Idea 阶段你采集的是关于"问题"的证据，而 MVP 阶段你采集的是关于"方案"的证据：
一组真实且可识别的人，是否觉得这个东西有足够价值，从而**使用它、回到它、为它付费、并把它告诉别人**。
MVP 的真正目标
作为 AI 原生创业公司的创始人，你的目标有三个：
1. 把已验证的问题转译成可运行产品
这不是一个把 roadmap 特性都做齐的完整版本。而是把"真实方案"摆到"真实用户"面前、生成关于 product-market fit 真实证据的、最小、最聚焦的版本。
2. 不积累会复利的技术债务
AI 基本上消除了过去控制"什么能进生产"的每一个天然瓶颈。速度被保证了。但当速度成了唯一变量时，你就会积累很难还清的技术债——而且它会复利。
每一次 Claude Code 会话都从零重新推导基础决策，这些决策就开始漂移。最终你得到一个没有任何连贯心智模型的代码库。
3. 从 Day One 就建立持久化上下文
在 AI 原生创业公司里，你的代码库是你一次又一次与 AI 协作的对象。那些跳过规约、架构决策、上下文文件的创始人，会撞上一堵可预期的墙：每个新会话都要重新解释一遍代码库。
吴恩达分享过一个非常实用的技巧：
**如果你的时间有限，就缩减项目的范围，直到项目小到你在现有时间里能完成为止。**
他举了自己的例子：
某周六下午，他想做一个"虚拟观众模拟器"——帮助练习公开演讲的工具。最初的想法很宏大：几十个虚拟观众、AI 自动反馈、3D 渲染……
但他只有几个小时。于是他做了三次缩减：
1. 从几十个观众 → 只模拟一个（之后再复制扩展）
2. 从 AI 自动反馈 → 人工手动选择反应（Wizard of Oz 原型法）
3. 从复杂图形 → 最简单的 2D 图像
结果？几小时内就做出了一个能跑的基础版本。虽然简陋，但它推动了他的项目进展，让他更深入地思考设计方案，并且能展示给朋友看，快速收集用户反馈。
这个方法的核心逻辑是：完成比完美重要一百倍。一个粗糙但存在的东西，胜过十个存在于脑子里的完美想法。
第一步：构建前先定义架构
在 Claude Code 写下一行生产代码之前，先用 Claude 定义和记录架构决策：
- 要遵循的模式
- 要避免的依赖
- 所做的权衡及其理由
把这个输出存为 CLAUDE.md 文件。这就是你项目的持久化"记忆"，后续每个 Claude Code 会话都会依赖它。
没有这层 context，每次会话都从零开始，AI 不得不自己推断结构假设。产生的代码能工作，但结构上不连贯——迭代几次后就会崩塌。
第二步：写下明确的范围定义
这是 AI 时代 MVP 最容易踩的坑——零摩擦的范围蔓延。
当加一个特性只要一个下午而不是一个 sprint 时，每一个单独的添加都"说得过去"。但随着产品膨胀超出最初的边界，你会失去方向感和势头。
解药：在开始构建之前写一份 scope 文档，明确描述：
1. 这个产品做什么
2. 刻意不做什么
3. 来自真实用户的什么具体证据才会成为加新东西的理由
这把决策点从"我们应该构建它吗？"变成"是否有关键多数的用户告诉我们：没有这个他们就无法得到价值？"
第三步：用 Claude Code 构建，但遵守纪律
架构和范围定义好之后，Claude Code 就是主要构建工具。但要遵守几个纪律：
- 每个会话开始时：先回顾 scope 文档 + CLAUDE.md
- 每个会话结束时：更新上下文文档，记录本次做了什么决定、引入了什么假设
- 把每个会话当作对已有产品决策的执行，而不是临时加新东西的机会
每会话花 5 分钟做文档化，是对抗"架构漂移"最便宜的保险。
第四步：任何用户接触前先做安全审查
残酷的事实：智能体编码工具生成的是能工作的代码，不是天然安全的代码。
功能性的问题有自然的反馈回路（能用或不能用）。安全漏洞是不可见的，直到被利用为止——这意味着没有自然的反馈回路提醒你"出问题了"。
在部署到任何真实用户之前，让 Claude 对核心应用代码做一次安全审查： - 认证与会话处理
- API 响应中的数据暴露
- 输入校验与注入风险
- 已知有漏洞的依赖
涉及认证、密钥、数据处理的部分，必须有人工评审。
第五步：发布前就建好度量框架
那些把早期 traction 误判为 product-market fit 的创始人，通常也是发布之后才开始追踪数据的人——他们挑的指标用于评估"什么正在工作"，而不是暴露"什么没在工作"。
解药：在第一个用户出现之前就建立度量框架：
- 设定留存基准和激活标准
- 定义 Day 7 / Day 30 目标
- 明确"假阳性"长什么样：没有激活的注册、没有留存的收入、没有重复使用的初始热情
- 当数据进来时，让 AI 对你自己的 traction 提出反方论证：怀疑者会怎么解读这些数字？
怎么判断 MVP 是否成功？
MVP 结束的时机不是产品"完工"的时候，而是你拥有 product-market fit 的真凭实据的时候。
几个有用的试金石：
Sean Ellis 测试
问你的活跃用户："如果你不再能用这个产品，你会作何感受？" 如果超过 40% 回答"非常失望"，这是一个有意义的 PMF 指标。
努力程度测试
PMF 之前，留存要靠持续干预——频繁外联、激励、人盯人的跟进。PMF 之后，产品开始自己做这件事。当事情从"推"变成"拉"，就是最清晰的信号之一。
数据模式测试
没有任何单一数据点能确认 PMF。它是一种必须跨多个迭代周期都成立的模式。看趋势，不看快照。
如果看不到 PMF 怎么办？
这不叫失败，这叫系统在工作——MVP 阶段就是被设计来在你把错误答案投资过深之前浮现这种信息的。
用 AI 梳理数据在告诉你什么：
1. 探索不同客户细分——也许没转化的用户从一开始就不是合适的目标
2. 调整价值主张——也许受众对了，但 MVP 没和他们产生共鸣
3. 保持开放——脱节深到可能需要更根本的改变
如果完成了 3 个以上迭代周期而朝 PMF 的实质性推进有限，停下来做一次诊断：把留存数据、用户反馈和最初的问题假设全部交给 AI，问三个问题：
- 数据里是否存在一个细分群体，响应与其他人显著不同？
- 设计价值与体验价值的差距，是定位问题还是产品问题？
- 当前产品要找到真正的 PMF，必须发生什么前提条件？
让答案决定你是调整、pivot，还是回到 Idea 阶段重新验证。
写在最后
MVP 阶段最容易犯的错误，是把"能跑"当成"有人要"。
在 AI 时代，造出一个能跑的东西从未如此简单。但也正因如此，纪律比以往任何时候都重要：
- 先写 CLAUDE.md 再写代码
- 先定义范围再加特性
- 先审查安全再给用户看
- 先建度量框架再发布
- 朝着"证据"迭代，而不是朝着"完工"迭代
记住：MVP 不是用来证明你能造什么的。它是用来证明有人需要你造的东西的。
*本文基于 Anthropic《创业者手册：构建 AI 原生创业公司》第四章及吴恩达 MVP 方法论整理*