第四章：最小可行产品阶段 (MVP Stage)
许多创始人将最小可行产品（MVP）阶段视为建设阶段，但 MVP 阶段本质上仍然是证据收集练习。区别在于，你现在是在收集关于解决方案而非问题空间的证据；具体而言，一个真实、可识别的人群是否认为它足够有价值去使用、回访、付费和/或推荐给他人。
MVP 阶段的目标
作为 AI 原生创业公司的创始人，你的目标是将一个已验证的问题转化为一个真实用户实际会使用的工作产品。这不是包含所有路线图功能的完整版本，而是你想法的最小、最聚焦的迭代版本——将一个真正的解决方案放在真正的用户面前，并生成真正产品-市场契合（Product-Market Fit）的证据。
与此同时，你现在如何构建决定了以后什么成为可能。这意味着 MVP 阶段还有第二个同等重要的目标：快速行动，但不积累会复利的技术债务——它会在真正的用户以有意义的数量到来时纠缠你。
最后，从第一天起就投资持久化上下文是让 AI 保持乘数效应而非成为熵增源的关键。在 AI 原生创业公司中，你的代码库是你在一次又一次会话中与 AI 协作的东西，这让可读性成为基础。跳过规格说明、架构决策和上下文文件（如 CLAUDE.md）的创始人，会撞上一个可预测的墙：每次新会话都需要重新解释代码库，AI 生成的改动也会偏离原始愿景。
MVP 阶段的退出标准
MVP 阶段的退出条件是真正产品-市场契合的证据：证明一个特定的、可识别的用户群体已经发现产品足够有价值，以至于会回访（留存）、付费（收入）或推荐给他人（推荐）。
MVP 阶段的挑战
在 MVP 阶段，创始人的首要指令是速度和判断力。这里的挑战围绕着你是否能以正确的方式、正确的速度构建正确的东西，而不会削减以后会付出代价的角落。
智能体技术债务
挑战：因为 AI 本质上移除了曾经控制什么能进入生产的每一个自然瓶颈，速度是有保证的。但当速度是创始人纳入 MVP 构建的唯一变量时，他们就有积累难以偿还的技术债务的风险。
MVP 阶段一些技术债务是适当的，理解是它必须在规模化之前被管理。它逐渐积累，可以随时间清除或在专门的冲刺中清理。AI 技术债务则是复利式的。没有规格说明和 AI 能阅读的架构约束书面记录，每次会话都会从头重新推导出基础决策，而这些决策就会漂移。你最终得到一个背后没有连贯心智模型的代码库——不是因为任何单个部分不好，而是因为这些部分从未被设计成适配在一起。这是真正的问题，而且它确实往往在很晚的时候才显现。
误信虚假的产品-市场契合
挑战：AI 工具可以产生令人印象深刻的早期数据，但这些数据并不能保证市场需要你的产品。
早期势头是创始人能拥有的最具心理影响力的体验之一。经过数周或数月的验证工作和谨慎、有纪律的构建，交付产品感觉像是在确认你一直都是对的。
智能体编程工具可以帮助你比以往任何时候都更快地达到这一刻，但早期牵引力不等于产品-市场契合。发布能量来自短暂的力——比如你创始人的朋友、你投资人其他被投公司的潜在买家，或者驱动峰值的 Hacker News 头条。不幸的是，这些都不能可靠地预测第六周或第十二周在初始提升消退后会发生什么。
零摩擦的范围蔓延
挑战：当构建感觉毫不费力且几乎免费时，总有另一个酷功能可以添加，或另一个边界情况要处理。这种范围蔓延可能弊大于利。
范围蔓延一直是创业风险。现在的不同在于，对抗它的传统强制措施——工程时间的真实成本——在添加一个功能只花一个下午而非一个冲刺时，不再以同样的方式存在。
这里的挑战在于每个单独的添加都是可辩护的。当然产品应该处理那个边界情况；当然用户会想要那个工作流。这些在那一刻感觉不像范围蔓延，因为每个用智能体编程构建都花那么少功夫，但随着你的产品超出原始边界，你就有失去方向和势头的风险。
解药是一个在构建开始前就写好的范围定义，描述产品做什么、故意不做什么，以及来自真实用户的什么具体证据会证明添加新东西是合理的。这将决策点从「我们应该构建这个吗？」转移到「一个关键质量的用户告诉我们，没有这个他们就无法从产品中获得价值。」
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 在目录中运行时会自动读取。功能上，它们是项目的持久化「记忆」。
每次 Claude Code 会话开始时，通过 (1) 回顾你的范围文档和 (2) 向模型提供你的 CLAUDE.md 架构上下文文档来开始。每次会话结束时用会话中浮现的任何决策更新它。目标是一个你能解释其结构的代码库，而不只是一个能运行的代码库。
练习：为你的 Claude Code 工作创建一个简单的会话模板，包括架构上下文文档、本次会话的具体任务，以及要遵循的任何约束或模式。在每次会话结束时，在上下文文档中添加一个简要日志条目，记录构建了什么、做出了什么决策、以及会话引入了什么假设。每次会话五分钟的文档是便宜的保险，防止架构漂移复利成不可管理的代码库。
定义并执行 MVP 范围
无摩擦的范围蔓延是 AI 时代 MVP 的决定性失败模式之一。就像你定义和记录了产品应用架构一样，你也需要在构建第一个功能之前定义 MVP 的范围。
Claude 可以帮你创建一个范围文档，描述你的 MVP 产品做什么、故意不做什么、以及功能修正标准：来自真实用户的什么具体证据会证明在此阶段添加新东西是合理的。
当新功能想法浮现时——而且它们肯定会——用 Claude 压力测试它是来自用户的真实信号，还是包装成产品思维的创始人热情。
任何用户触及之前进行安全审查
作为 AI 原生创业公司创始人，你的责任是了解你的代码库中有什么、理解任何潜在的暴露向量，并且不将明显的漏洞交付给信任你数据的真正用户。
Claude 可以对 AI 生成的代码进行有用的首次安全审查，帮助识别常见漏洞。在发布前将安全审查纳入循环是个好习惯。但它不能替代安全工具，或者在更高风险的情况下——人类审查者——把 Claude 当作替代的人最终会出现在数据泄露的报道中。
Claude Code Security 更进一步：扫描代码库中的安全漏洞并建议供人类审查的定向补丁，揭示传统方法可能遗漏的问题。
注意：在本电子书发布时，Claude Code Security 是一个有限测试版，请在将其纳入你的工作流之前检查当前可用性。
用 Claude Code 构建你的 MVP
一旦架构和范围定义完毕，Claude Code 就成为主要的 MVP 构建工具。用它来生成、测试、调试和迭代你的代码库，但将每次会话视为你已经做出的产品决策的执行，而不是添加新想法的机会。
发布前构建测量框架
误将早期牵引力识别为产品-市场契合的创始人，通常也是那些发布后才开始跟踪数据的人，使用选择来评估什么在起作用的指标，而非揭示什么不起作用的指标。
解药是在第一个用户出现之前就建立测量框架。
用 Claude 定义对你的特定产品重要的指标、基准是什么，以及数据中的什么模式构成真正的产品-市场契合而非讨好的噪音。具体而言：在发布 MVP 之前设定你的留存基准、激活标准，以及 Day 7 和 Day 30 目标。
接下来，定义对你的特定产品而言假阳性是什么样子：注册但未激活、有收入但无留存、或初始热情但无重复使用等。当数据到来时，让 Claude 对你的牵引力提出反面论证：一个怀疑论者会对这些数字说什么？
管理发现和用户反馈的运营
一旦真实用户进入产品，运营层就快速扩张。Claude Cowork 处理重要但繁琐的工作，如构建和维护用户联系人列表、运行外联序列、安排反馈会话、分类错误报告，以及跟踪迭代周期。管理发现运营时使用的相同 MCP 集成在这里也适用。
保持人类在反馈收集循环中，以进行用户反馈的细微探索。例如，用户说「这很好，但我希望它也能……」需要解读：这是一个核心需求还是锦上添花？是这个客户特有的，还是代表一个细分群体？缺失的功能是真正的问题，还是上游某个入门的障碍？没有工具能回答这些问题。
练习：配置 Claude Cowork 运行你的 MVP 阶段反馈循环：起草外联给你的早期用户列表、安排反馈会话、为错误报告和功能请求设计结构化摄入流程，并编写每周综合报告。先自己审查综合报告；之后，你可以让 Claude 分析信息，以捕捉你可能忽略的任何重要要点。
向证据迭代，而非向完整性迭代
MVP 阶段在你拥有真正产品-市场契合的证据时结束，无论产品感觉有多「完成」。宣布你已实现产品-市场契合并准备从 MVP 阶段进入发布阶段，最终是一个结合创始人直觉和收集证据的判断练习。不过，有一些有用的试金石：
- 肖恩·埃利斯测试 (Sean Ellis Test)：问你的活跃用户：「如果你不能再使用这个产品，你会有什么感受？」如果超过 40% 的人回答「非常失望」，那这就是一个有意义的产品-市场契合指标。
- 努力测试：产品-市场契合之前，留存需要持续的干预，包括频繁的外联、激励、个人跟进，以及创始人花费的英雄精力来保持用户参与。产品-市场契合之后，产品开始自己做这项工作。当事情开始从推转为拉时，这种努力转变就是发生了真正变化的最清晰信号之一。
最终，没有任何单一数据点能确认产品-市场契合，因为它是一个必须在多个迭代周期中保持的模式，你才能确定地称之为产品-市场契合。
当证据要求时果断转型
如果你投入了所有这些工作之后，仍然无法到达产品-市场契合怎么办？你的结果不能证实你最初方向这一事实，不是失败，而是系统在运作：MVP 阶段的设计目的是在你过度投资于错误答案之前，就揭示这一信息。
当数据不支持你当前的产品时，用 Claude 来梳理数据在告诉你什么：
- 探索替代客户细分：也许没有转化的用户从一开始就不是正确的目标。通常正确的受众已经在你的数据中，只是权重不足。
- 调整产品的价值主张：也许你有正确的受众，但你的 MVP 只是没有与用户产生共鸣。对入门流程、信息传递或核心功能重点的调整，可能可以在不改变已构建内容的情况下解决这个问题。
- 保持开放，这种脱节可能深到需要更根本的改变。
练习：如果你已完成三个或更多迭代周期而没有向产品-市场契合基准有意义的进展，用 Claude 运行诊断，然后决定下一步。输入你的留存数据、用户反馈和你原始的问题假设，并问它三个问题：
- 数据中是否有一个细分群体与其他群体的反应不同？
- 设计价值与体验价值之间的差距是定位问题还是产品问题？
- 当前产品要找到真正的产品-市场契合，什么必须为真，而鉴于你所看到的，这个场景现实吗？
让答案决定你是调整、转型还是回到想法阶段。