很多 MVP 失败，并不是产品做得不够好，而是验证成本已经接近正式开发，结果仍无法回答“客户是否愿意为结果付费”。因此，MVP 的低成本边界不应理解为“尽量少做功能”，而应定义为：用可控的时间和资源，获得足以支持下一步决策的真实证据。

先确定要验证什么

验证对象应是商业假设，而不是技术兴趣。至少要明确三件事：目标客户是否存在高频且紧迫的痛点；客户是否愿意为解决结果付费；单人能否在合理范围内完成交付。若只是展示功能、收集泛泛的“看起来不错”，即使原型完成，也不能证明方向成立。

可以先用“能力匹配度、痛点频率、付费意愿、交付难度”四个维度进行初筛，每项按 1—5 分评估。总分达到 15 分以上，再进入小规模验证。这个门槛的价值不在于制造精确结论，而在于迫使团队把模糊判断显性化，及时发现短板究竟位于需求、价格还是交付环节。

低成本不等于低质量

MVP 应只保留验证核心假设所必需的部分。对于报表自动化等场景，可以先用 Notion、Zapier 或低代码平台拼出可交付流程，而不是立即开发完整系统。验证目标可以是获取 5 位潜在客户的付费意向，或完成一次真实交付；投入则应控制在 20—30 小时以内，避免把验证悄悄变成长期研发。

判断是否越过低成本边界，可看三个信号：是否开始补充与核心假设无关的功能，是否投入大量时间处理暂时不影响结果的体验问题，是否还没有获得真实客户反馈就持续优化技术方案。一旦出现这些情况，说明成本已经超过证据价值。

用结果决定是否继续

验证结束后，不要只依据用户口头称赞，而要重新检查价值与价格反馈，并再次评估四项得分。若方向仍达到 15 分以上，可以进入正式产品开发；若分数下降，应优先修改客户定位、价值主张或交付方式，而不是用更多功能掩盖需求不足。

真正合格的 MVP，不是一个缩水版产品，而是一项边界清晰的商业实验：投入足够小，问题足够具体，结果足以支持继续、调整或停止。