AI Native 创业（五）：MVP 阶段，产品边界比写代码更重要
AI-native MVP 的第一份产物不该是代码，而应该是范围、架构、指标和上下文约束。
Jonathan
创始人
MVP 仍然是证据收集
这是 AI Native 创业系列的 MVP 阶段篇。这里讨论的不是“如何更快写出 MVP”，而是当 AI 已经让写代码变快之后，创业者如何守住产品边界、架构上下文和 PMF 证据。
The Founder’s Playbook 第四章讲 MVP Stage。原文有一个很重要的定位：MVP 阶段不是单纯的 construction phase，它仍然是 evidence-gathering exercise。
Idea 阶段收集的是问题证据。MVP 阶段收集的是解决方案证据。
你要证明的不是“产品能跑”，而是一个具体人群是否觉得它足够有价值，愿意回来、付费、推荐，或者把它放进自己的工作流。
这句话在 AI 时代尤其重要。因为 AI 会让“能跑”变得太容易。
一个能跑的产品，不等于一个有人持续使用的产品。一个看起来完整的界面，不等于 product-market fit。
Agentic technical debt
原文提到一个很好的概念：agentic technical debt。
传统技术债通常来自取舍：为了速度先写一个不完美实现，之后再还。MVP 阶段一定会有技术债，这很正常。
但 AI 带来的技术债有一点不同：它常常来自上下文缺失。
如果你没有写清楚架构原则、依赖选择、目录约定、命名方式、状态管理、测试策略、边界条件，每一次 AI coding session 都会重新推断这些东西。单看某一段代码可能没问题，但多次 session 叠加后，项目会慢慢失去一致的心智模型。
最后你得到的是一个能跑但难以解释的代码库。
这比单个坏实现更危险。因为它不是某个 bug，而是结构性漂移。
所以 AI-native MVP 的第一份产物不应该是代码，而应该是 Architecture Context Document。
如果你使用 Claude Code，可以是 CLAUDE.md；如果使用别的工具，也应该有等价文件。它要告诉 AI：
- 这个产品解决什么问题。
- 当前 MVP 明确做什么、不做什么。
- 技术栈和架构原则是什么。
- 哪些依赖要避免。
- 哪些 tradeoff 是有意接受的。
- 每次 session 结束后需要更新什么决策。
这不是仪式感。这是防止 AI 生成的代码在多轮迭代里散掉。
Zero-friction scope creep
MVP 阶段第二个大坑，是无摩擦的范围蔓延。
过去，新增功能要消耗工程时间，所以团队会被迫取舍。现在，很多功能一个下午就能做出来。于是每个新增点看起来都合理：
- 这个 edge case 用户可能会需要。
- 这个 workflow 做了体验会更完整。
- 这个 integration 做了销售会更好讲。
- 这个 dashboard 做了投资人会更喜欢。
问题是，每一个新增功能都合理，不代表它们加在一起仍然是一个好 MVP。
MVP 的目标不是完整，而是产生证据。你应该先定义：
- 产品必须完成的核心交互是什么？
- 哪些功能明确不做？
- 什么样的用户证据才允许新增功能？
原文的建议非常对：把问题从“要不要做这个功能”改成“是否有足够多真实用户证明，没有这个功能他们无法获得核心价值”。
这个转变能救很多 AI-era MVP。
先建指标，再上线
原文还提醒：不要发布后才开始选指标。
很多创始人在产品上线后，容易挑选那些看起来不错的数据解释进展。注册数涨了、访问量涨了、转发多了，就觉得方向对了。
更好的做法是，在第一个用户来之前，就定义 measurement framework。
你至少要提前定义：
- activation：用户完成什么动作才算真正激活？
- retention：第 7 天、第 30 天回来意味着什么？
- revenue：什么样的付费才说明产品价值，而不是关系或定制服务价值？
- referral：用户是否愿意主动推荐给同类人？
- false positive：哪些漂亮数字不能证明 PMF？
AI 可以帮你设计指标，但创始人要决定哪些指标真的代表价值。
MVP 阶段如何整理现有数据
MVP 阶段的数据整理，应该围绕 PMF 证据展开。
你要把四类数据放在一起看。
第一，产品行为数据。用户是否完成核心动作？在哪一步退出？是否回来？是否形成重复使用？
第二，用户反馈。用户说喜欢什么、卡在哪里、为什么没有继续用、有没有主动提出把它接进实际工作流。
第三，bug 和支持请求。哪些问题只是小瑕疵，哪些问题阻断了核心价值？
第四，销售和付费信号。愿意付费的人是谁？他们买的是产品本身，还是你作为创始人的手把手服务？
这些数据不应该被整理成“本周增长不错”。它们应该进入 PMF Evidence Board。
这个 board 要同时显示支持和反对：
支持 PMF 的证据 | 反对 PMF 的证据 | 需要验证的问题 | 下一次迭代如果你连续三轮迭代后，核心指标没有改善，就应该让 AI 帮你做一次 diagnostic：
- 是否有某个细分用户表现明显不同？
- 问题是定位错了，还是产品体验错了？
- 当前产品要找到 PMF，需要哪些假设成立？
- 这些假设在现有数据里现实吗？
这比继续加功能更有价值。
安全不能等到以后
原文在 MVP 阶段也讲了安全，这是很多 AI-native 创始人容易低估的部分。
AI 生成代码通常会优先让功能跑起来。功能是否可用，有即时反馈；安全问题是否存在，往往没有即时反馈，直到出事。
只要你把产品给真实用户用，就会涉及真实数据、真实身份和真实责任。至少在任何真实用户接触产品之前，要做一次基础安全 review：
- 认证和 session 是否安全？
- API 是否暴露不该暴露的数据？
- 输入是否有注入风险？
- secret 是否被泄露？
- 依赖是否有已知漏洞？
AI 可以做第一轮检查，但不能成为唯一防线。高风险部分必须有更可靠的工具或人工复查。
这一章应该沉淀什么
MVP 阶段至少要沉淀四个 artifact。
第一个是 MVP Scope Contract：明确做什么、不做什么、什么证据允许扩 scope。
第二个是 Architecture Context Document：给 AI coding session 的持久上下文。
第三个是 Session Log：每次 AI 写代码后记录做了什么、做了哪些决策、引入了哪些假设。
第四个是 PMF Evidence Board：用来判断是否继续、调整还是 pivot。
如果只有代码，没有这些 artifact，你不是在构建 AI-native MVP，而是在堆一个越来越难解释的 demo。
小结
MVP 阶段的关键不是让 AI 更快写代码，而是让 AI 在清楚边界里写代码。
速度已经不稀缺了。稀缺的是产品判断、范围纪律、架构上下文和真实证据。
本文是 Anthropic The Founder’s Playbook: Building an AI-Native Startup 的中文拆解系列第五篇。