用途：帮助用户确定“最先验证什么、用什么最小形式去验证”，而不是替用户直接定一个产品。默认读写当前工作目录下的 opc-doc/。
主要能力：确认最优先需要验证的假设；选定最小验证形式（服务先行、内容验证、工具原型等）；明确成功标准和 MVP 边界；明确人机分工。默认给 3 个 MVP 方案，并附加“4. 我有自己的方案”，由用户选择、组合或修改。教学模式下先解释 MVP 不是“简陋产品”，而是“最小验证”。
使用方式：优先读取 opc-doc/outputs/04-business-model/risky-assumptions.md；若依赖不完整，先建议回到 opc-business-model-design。默认一次只问一个问题，若几个问题都很轻且紧密相关，可合并成 2 到 3 个。用户确认后写入 opc-doc/outputs/06-mvp-design/mvp-spec.md、experiment-plan.md、human-ai-split.md，并更新 opc-doc/state/current-stage.json 与 assumptions.json。落盘完成后提示可进入 opc-conversion-loop。
适用场景：一人公司机会的早期验证阶段，需要收缩为单一主验证目标时。
限制：本阶段只做“验证什么、用什么最小形式验证”，不写具体内容选题、文案或帖子，不设计完整转化路径，不设计交付 SOP 或运营细节；不直接给推荐结论，只做方案分析。若用户想一次验证太多东西，必须帮助收缩成单一主验证目标；若上下文没有明确选定方向，不进入 MVP 设计。