MVP 阶段
很多创始人把 MVP 阶段当成一个施工阶段，但 MVP 阶段本质上仍然是一场收集证据的演练。不同之处在于，你现在收集的是关于方案的证据，而不是关于问题空间的证据；具体来说，就是：一个真实、可识别的人群，是否觉得它有价值到愿意去用它、回头再用它、为它付费，并且/或者把它告诉别人。
MVP 阶段的目标
作为一家 AI 原生创业公司的创始人，你的目标是 把一个验证过的问题转化为一个真实可用的产品，让真实用户真的会去用。这不是那个包含路线图上每一项功能的完整版，而是你点子最小、最聚焦的一次迭代——把一个真实方案摆到真实用户面前，并产生真实的产品-市场契合证据。
与此同时，你现在怎么造，决定了以后什么是可能的。这意味着 MVP 阶段还有第二个、同样重要的目标：在快速推进的同时，不要积累那种会复利滚雪球的技术债——一旦真实用户成规模地涌入，这种债会反过来缠住你。
最后，从第一天起就 投资于持久的上下文，才能让 AI 始终是力量倍增器，而不是熵增之源。在 AI 原生创业公司里，你的代码库是你一轮又一轮地与 AI 协作的对象，这让"可读性"成为根基。那些跳过规格说明、架构决策和上下文文件（比如 CLAUDE.md）的创始人，会撞上一堵可预见的墙：每个新会话都要重新解释一遍代码库，而 AI 生成的改动会逐渐偏离最初的愿景。
MVP 阶段的退出标准
MVP 阶段的退出条件，是产品-市场契合的真实证据：有证据表明，一个具体、可识别的用户群体，已经觉得这个产品有价值到愿意回头再用（留存）、为它付费（收入），或把它告诉别人（推荐）。
MVP 阶段的挑战
在 MVP 阶段，创始人的最高准则是速度与判断力。这里的挑战集中在：你能不能把对的东西、以对的方式、足够快地造出来，同时不去走那些日后要让你付出代价的捷径。
智能体技术债
挑战： 因为 AI 实质上移除了过去控制"什么能进生产环境"的每一个天然瓶颈，速度是有保证的。但当速度成为创始人在 MVP 构建中唯一纳入考量的变量时，他们就有积累难以偿还的技术债的风险。
在 MVP 阶段，有些技术债是合理的——前提是你明白它必须在规模化之前被管理掉。它是逐渐累积的，可以随时间或在一次专门的冲刺里清掉。但 AI 技术债会复利滚雪球。
如果没有把规格和架构约束写在 AI 读得到的地方，每个会话都会从零重新推导那些基础性的决策，而这些决策会逐渐漂移。你最后得到的，是一个背后没有连贯心智模型的代码库——不是因为某一块单独看有多糟，而是因为这些块从一开始就没被设计成能彼此契合。这是一个真实的问题，而且它往往会很晚才浮现。
误信虚假的产品-市场契合
挑战： AI 工具能造出亮眼的早期数字，但这并不保证市场需要你的产品。
早期势头，是创始人能有的心理冲击力最强的体验之一。在数周或数月的验证工作和审慎、自律的构建之后，交付一个产品，感觉就像在确认"你一直都是对的"。
智能体编程工具能帮你比以往任何时候都更快地抵达这一刻，但早期牵引力并不等于产品-市场契合。发布时的能量来自一些转瞬即逝的力量，比如你创始人的朋友、你投资人旗下其他被投公司里的潜在买家，或者一条带来流量峰值的 Hacker News 头条。不幸的是，这些都不能可靠地预测：当最初的助推消退后，第六周、第十二周会发生什么。
零摩擦的范围蔓延
挑战： 当构建感觉毫不费力、几乎免费时，总有"再加一个很酷的功能"或"再处理一个边缘情况"。这种范围蔓延，可能弊大于利。
范围蔓延一向是创业风险。如今的不同之处在于，过去对抗它的传统约束力量——工程时间的真实成本——已经不再以同样的方式存在了，因为加一个功能现在只要一个下午，而不是一个冲刺。
这里的挑战在于，每一项单独的新增都说得通。产品当然应该处理那个边缘情况；用户当然会想要那个工作流。当下这些感觉不像范围蔓延，因为用智能体编程造每一个都只花一丁点力气；但随着你的产品蔓延出它原本的边界，你就有失去方向和势头的风险。
解药，是一份在动手构建之前就写好的范围定义：描述产品做什么、刻意不做什么，以及哪些来自真实用户的具体证据才足以支撑新增某个东西。这把决策点从"我们该不该做这个？"挪到了"已经有相当数量的用户告诉我们，没有这个他们就无法从产品里获得价值？"
因经验不足而不安全
挑战： 创始人用 AI 工具仓促把应用推向市场，却没有先理解基本的安全原则，结果让用户暴露在本可避免的风险之下。
残酷的事实是：智能体编程工具生成的是能跑的代码，不是天生安全的代码。能用的代码很容易，因为功能要么能用、要么不能用。安全漏洞在被利用之前是隐形的，这意味着没有天然的反馈回路来提醒一个初次创业的创始人哪里出了问题。然而，把一个上线的 MVP 交付给真实用户，意味着真实的数据、真实的暴露面，以及一旦出事就会有真实的后果。
轻视安全，对 AI 原生项目来说并不新鲜。各个时代的自筹资金创业公司，常常把安全考量拖到构建的很晚，有时一直拖到接近生产发布。在任何用户接触你的应用或方案之前做一次安全审查，是把一个最小可行产品放进世界里的、最低限度的负责任门槛。
Claude 如何帮助 MVP 阶段的创始人
在动手构建之前定义你的架构
在 Claude Code 写下一行生产代码之前，用 Claude 来定义并记录那些将统御本阶段一切构建的架构决策：要遵循的模式、要避免的依赖、正在做出的取舍以及为什么。这份产出会成为一份聚焦的架构上下文文档，确立 Claude Code 在其中作业的护栏。
没有这份上下文，每个会话都从零开始，Claude Code 被迫去推断它自己的结构假设。让 Claude Code 在没有护栏的情况下构建，会产出一个能用、但结构上不连贯的代码库；而在不连贯的代码库上迭代和规模化，最终是对时间和 token 的浪费。迟早会到一个点，代码不可避免地崩塌，逼你从零重建。
练习： 打开 Claude Code 之前，先打开 Claude，描述你在造什么：它解决的核心问题、它服务的用户，以及你对未来六个月现实可期的规模。让它帮你定义应当统御你 MVP 构建的架构原则、在你的约束下要避免的依赖，以及你在本阶段有意识接受的取舍。
接下来，把这份产出保存为 CLAUDE.md markdown 文件。这就是你的架构上下文文档：你这次构建的第一件产物，也是之后每个会话都依赖的那一件。CLAUDE.md 文件作为给 Claude Code 的项目级指令，提供项目特定的上下文与指示，当 Agent SDK 在某个目录中运行时会自动读取。功能上，它们就是你项目的持久"记忆"。
定义并执行你的 MVP 范围
无摩擦的范围蔓延，是 AI 时代 MVP 标志性的失败模式之一。正如你定义并记录了产品的应用架构，你也需要在造出第一个功能之前定义你 MVP 的范围。
Claude 能帮你写一份范围文档，描述你的 MVP 产品做什么、刻意不做什么，以及功能变更标准：在此刻，哪些来自真实用户的具体证据才足以支撑新增某个东西。
当新功能点子冒出来时——它们一定会——你用 Claude 来施压检验：这究竟是来自用户的真实信号，还是被打扮成产品思考的创始人热情。
用 Claude Code 构建你的 MVP
一旦架构和范围都定义好了，Claude Code 就成为主要的 MVP 构建工具。用它去生成、测试、调试和迭代你的代码库，但把每个会话都当作对你已经做好的产品决策的执行，而不是当成临时塞进一些新决策的机会。
每个 Claude Code 会话开始时，先 (1) 重温你的范围文档，(2) 把你的 CLAUDE.md 架构上下文文档提供给模型。每个会话结束时，用本次会话浮现出的任何决策去更新它。目标是一个你能解释其结构的代码库，而不仅仅是一个能跑的代码库。
- 练习： 为你的 Claude Code 工作建一个简单的会话模板，包含架构上下文文档、本次会话的具体任务，以及要遵守的任何约束或模式。每个会话结束时，往上下文文档里加一条简短的日志：本次造了什么、做了哪些决策、本次会话引入了哪些假设。每个会话花五分钟做文档，是对"复利滚成无法管理的代码库"那种架构漂移的廉价保险。
在任何用户接触它之前做安全审查
作为 AI 原生创业公司的创始人，你的责任是：知道你的代码库里有什么、理解任何潜在的暴露途径，并且不要把明显的漏洞交付给那些把数据托付给你的真实用户。
Claude 能对 AI 生成的代码做一次有用的首轮安全审查，并帮助识别常见漏洞。把它建进交付前的回路，是个好习惯。但它不能替代安全工具，在更高风险的场景下，也不能替代人工评审者——把它当成替代品的创始人，就是最后出现在数据泄露故事里的那些人。
Claude Code Security 走得更远：它扫描代码库找安全漏洞，并给出有针对性的补丁建议供人工评审，浮现传统方法可能漏掉的问题。
注： 在本电子书出版时，Claude Code Security 是有限的 beta 版本，所以在把它建进你的工作流之前，请先确认当前的可用情况。
- 练习： 在部署给任何真实用户之前，带着一份具体的工作简报让 Claude 过一遍你的核心应用代码：审查认证与会话处理、API 响应中的数据暴露、输入校验与注入风险，以及含已知漏洞的依赖。认真对待每一处发现，评估它是否需要修复；任何涉及认证、密钥或数据处理的，都要有人工评审。
在发布之前建好你的度量框架
那些把早期牵引力误判成产品-市场契合的创始人，通常也正是那些发布之后才开始追踪数据的人——而且他们选的指标是用来评估"哪些奏效"，而不是用来浮现"哪些没奏效"。解药，是在第一个用户出现之前就建好你的度量框架。
用 Claude 来定义：对你这个具体产品而言哪些指标重要、基准值是多少，以及数据里什么样的模式才算真正的产品-市场契合、什么只是讨好你的噪声。具体来说：在发布你的 MVP 之前，设好你的留存基准、激活标准，以及第 7 天和第 30 天的目标。
接下来，定义对你这个具体产品而言，假阳性长什么样：比如，注册了却不激活、有收入却没留存，或者有最初的热情却没有重复使用。当数据到来时，让 Claude 对你自己的牵引力做反方论证：一个怀疑论者会怎么评价这些数字？
管理探索与用户反馈的事务性工作
一旦真实用户进入产品，运营层会迅速膨胀。Claude Cowork 处理那些重要但繁琐的工作，比如建立和维护用户联系人名单、跑触达序列、给反馈会话排期、给缺陷报告分流、追踪迭代周期。在创意阶段管理探索事务的那些 MCP 集成，在这里同样适用。
在收集回路里保留一个人，用于对用户反馈做细腻的探究。比如一个用户说"这很好，但我希望我还能……"，这需要解读：这是核心需求还是锦上添花？是这个客户特有的，还是某个细分群体的代表？缺的那个功能是真问题，还是上手引导里某个更上游的环节才是？没有工具能回答这些问题。
- 练习： 配置 Claude Cowork 来跑你 MVP 阶段的反馈回路：给你的早期用户名单起草触达、给反馈会话排期、为缺陷报告和功能请求设计结构化的收集流程，并写一份每周综述。综述你自己先看；之后，你可以让 Claude 分析这些信息，把你可能忽略的重要点抓出来。
朝证据迭代，而不是朝"做完"迭代
MVP 阶段在你拥有产品-市场契合的真实证据时结束，无论产品感觉多"完成"。宣布你已经达成产品-市场契合、可以从 MVP 阶段进入发布阶段，归根结底是一次结合创始人直觉与所收集证据的判断。不过，有一些有用的试金石：
- Sean Ellis 测试： 问你的活跃用户："如果你再也不能用这个产品了，你会怎么想？"如果超过 40% 的人会"非常失望"，这是一个有意义的 PMF 指标。
- 费力测试： 在产品-市场契合之前，留存需要持续干预，包括频繁触达、激励、个人跟进，以及创始人为维持用户活跃而付出的英雄式精力。在产品-市场契合之后，产品开始自己做这件事。当事情开始变成"被拉动"而不是"被推动"，这种转变是"某种真实的东西已经改变"最清晰的信号之一。
归根结底，没有任何单一数据点能确认产品-市场契合，因为它是一个必须跨多个迭代周期都成立的模式，然后你才能确凿地这么说。
当证据要求转向时，就转向
万一，哪怕投入了所有这些工作，你就是似乎抵达不了产品-市场契合呢？你的结果没有印证你出发时的方向，这不是失败，这是系统在正常工作：MVP 阶段的设计目的，正是在你对错误答案过度投入之前，把这个信息浮现出来。
当数据不支持你当前的产品时，用 Claude 来梳理那些数据在告诉你什么。
- 探索其他客户细分。 也许那些没转化的用户，从一开始就不是对的目标。对的受众往往已经在你的数据里，只是被低估了。
- 调整你产品的价值主张。 也许你的受众是对的，但你的 MVP 就是没能引起用户共鸣。对上手引导、信息传达或核心功能侧重做一次调整，有可能在不改变你已造之物的前提下解决这个问题。
对"脱节可能深到需要一次更根本的改变"这种可能性保持开放。
练习： 如果你已经做完三个或更多迭代周期，却没有朝产品-市场契合基准有意义地移动，在决定下一步怎么做之前，用 Claude 跑一次诊断。把你的留存数据、用户反馈和最初的问题假设喂给它，问它三个问题：
- 这些数据里有没有某个细分群体的反应与其余不同？
- "设计出的价值"和"被体验到的价值"之间的差距，是一个定位问题还是一个产品问题？
- 要让当前产品找到真正的 PMF，什么必须为真；鉴于你看到的情况，那个情景现实吗？
让答案来决定你是调整、转向，还是回到创意阶段。