设计最小验证方案与 MVP 范围

这个场景能帮你做什么

需求清单和原型都已有了，团队仍可能不知道第一版究竟要验证什么。WorkBuddy 可以把关键假设、最小可行产品（MVP）范围、观察证据和继续条件整理成一份验证方案，避免第一版承载所有功能。它关注先验证什么和做到什么程度，区别于完整需求优先级、原型梳理及材料试验排程。

开始前需要准备什么

提供目标用户与实际任务、访谈和使用证据、候选方案、已知技术限制、预算和时间边界。写明当前最担心的是需求不成立、用户不接受解决方式，还是关键技术达不到效果。提供负责人已确认的判定标准；没有标准时，先让工具提出待讨论项，不能自动定为企业门槛。

具体怎么做

第一步：把想做的功能还原为待验证假设

要求 WorkBuddy 为每项功能写出“哪类用户、在什么条件下、会采取什么行为或达到什么结果”，附已有证据和未知部分。“用户觉得好用”过于模糊，应明确观察什么行为、由谁记录、什么情况说明尚未解决任务。

第二步：区分需求验证和技术验证

如果本轮只检验用户是否愿意采用流程，可以使用明确告知的人工服务或交互原型；这些结果只能支持相应需求判断。如果要验证语音识别、推荐或检测效果，就必须有实际技术处理和相应测试条件，人工代做不能证明算法可行。同一产品可能需要两种验证，不强行合并成一个结论。

第三步：确定最小范围和明确排除项

让工具按关键假设保留必要输入、处理和交付，逐一解释每项功能为何影响判断。可以暂缓多语言、多角色或复杂后台，但不能移除验证所必需的核心处理、用户任务或异常反馈。限定用户、场景、样本选择、使用时长、人工介入和资源上限。

第四步：先写判定条件，再执行

输出要观察的证据、记录方法和负责人，列出通过、继续调整、停止和证据不足四种处理。用企业认可的阈值和样本规则，预先约定什么变化需要重新验证。小范围观察只能支持本轮范围的决定，不能推出所有用户都接受。

可以直接交给 WorkBuddy 的完整要求

依据附件用户证据、候选方案、技术约束与资源边界，设计最小验证方案。
先列待验证假设及已有/缺失证据，区分需求与使用接受度验证、技术可行性验证。
为本轮关键假设确定保留功能、排除功能、用户场景、材料、执行过程、人工介入和资源上限，并说明为何足以回答问题。
列观察指标、记录方式及通过/调整/停止/证据不足的处理。只引用已确认阈值，缺阈值、样本规则或权限标待确认。
不把人工代做视为算法有效，不把模拟用户回答视为真实验证，不宣称产品已验证成功。

完成后会得到什么

一份假设与验证方式对应表，以及有范围、资源和判定条件的最小版本说明。以下是教学示例，门槛仅为展示写法，不是通用标准。

内容	需求验证轮	技术验证轮
假设	维修人员愿意用型号和故障描述获取排查入口	检索程序能找到对应型号的已批准指南
最小方式	在告知人工协助的情况下，由人员返回指南链接	固定版本指南库与实际检索程序，使用经专业人员标注的测试问题
保留与暂缓	保留提交问题、收到结果和反馈；暂缓账号体系扩展	保留型号约束、候选结果和无匹配提示；暂缓跨产品线扩展
证据	是否能完成任务、是否继续使用、为何放弃，记录人工介入	对照标准答案，记录命中、错型号、无答案和处理时间
判定	按负责人事先确认的行为标准决定继续或调整	错型号风险触发暂停并修正；具体容许水平和覆盖量须事先批准

第一轮即使获得积极反馈，也不能证明检索算法可靠；第二轮即使检索准确，也不能证明用户愿意长期采用。方案应分别留下结论。

结果应该怎么检查

核对每个保留功能是否服务关键假设，每项指标是否能从真实记录取得。检查人工介入、样本条件和失败记录是否保留，是否在看到结果后才修改通过标准。没有真实执行数据的文件只能叫方案。

遇到这些情况怎么处理

关键需求尚不清楚时先做访谈或任务观察。技术效果直接决定用户价值时，不能只用静态原型替代技术验证。若必须投入过多功能才能回答问题，先缩小用户、任务或场景；缩小后仍无法有效验证，则提交负责人调整验证路线。

哪些必须人工决定

产品负责人确定关键假设和范围，技术负责人确认验证方式能够回答技术问题，业务与资源负责人确认门槛、投入和继续决定。AI 协助组织方案和后续记录，不生成虚构客户反馈或替团队宣布验证成功。