一人公司划定 MVP 边界，核心不是判断“还能删掉哪些功能”，而是明确：在资源极其有限的情况下，产品必须先证明哪一个价值成立。MVP 不是粗糙版的完整产品，也不是把所有功能各做一点，而是围绕一个目标用户、一个具体场景，交付一次可感知的核心结果。

先锁定一条最小价值路径

在开发前，先把用户从问题出现到结果获得的完整过程写出来，再只保留不可缺少的环节。可以用一句话定义范围：

对于某类用户，在某个场景下，帮助其完成某项关键任务，并获得一个明确结果。

例如，项目进度工具的早期版本，可能只需要让用户创建项目、更新状态并看懂下一步行动。账户体系、权限管理、复杂报表和多用户协作，如果不影响首次价值，就不应进入第一版。

判断一个功能是否属于 MVP，可追问三个问题：它是否直接支撑核心任务？删掉后用户是否无法获得结果？它是否已经有用户证据支持？只要答案含糊，就应暂缓，而不是用“以后可能会需要”作为开发理由。

用低成本方式验证，而非提前系统化

一人公司最容易犯的错误，是用开发工作逃避需求验证。后台自动化、完整页面和复杂流程都可以暂时由人工完成。手工流程、表单、模板组合，甚至由创业者代替系统交付，都是有效的早期方案。MVP 的任务是验证价值和行为，不是证明技术架构已经成熟。

测试时不要让用户参观页面，而要让其完成一个具体任务。重点观察他是否知道下一步做什么、在哪里停顿或绕开功能，以及完成后是否认为结果有价值。测试过程中解释得越多，越可能测到讲解能力，而不是产品本身。

用行为设定边界，而不是凭感觉扩张

MVP 上线前，应先定义最小行为路径：了解产品、开始尝试、完成核心任务、获得结果，并观察是否再次使用或愿意继续测试。用户的口头认可只能算弱信号；主动提交需求、提供样本、再次参与测试或愿意付费，才更接近有效证据。

当用户持续遇到同一问题、能够完成核心任务，并愿意采取后续行动时，可以优化路径；若问题真实但方案过于复杂，应调整用户、场景或交付方式；若始终找不到稳定用户，且只能依靠不断解释来证明价值，就应暂停投入。MVP 的边界，本质上是证据的边界：没有新证据支持的功能，暂时都不属于产品。