PoL Probe - 开发前产品假设验证探针工具

技能概述

PoL Probe（Proof of Life 探针）帮助产品团队在昂贵开发之前，用轻量、可抛弃的验证实验测试一个狭隘假设并消除关键风险——它是侦察任务而非 MVP，目标是拿到残酷真相，而不是做出能演示的产品。

适用场景

1. 新想法立项前验证：为工作流自动化等新想法设计一个几天内可完成的可行性验证，判断"用户真的会这么用吗"，再决定是否投入工程资源。
2. 定价与转化假设测试：在改版定价或注册流程前，用小样本任务测试验证假设（如"表单减到 3 个字段后完成率能否超 80%"），避免拿真实用户当实验品。
3. 功能开发前的低成本风险排查：当某个技术可行性或用户任务完成度的不确定性阻塞决策时，先用探针拿到数据，再决定是否进入 MVP 阶段。

核心功能

1. 结构化探针文档模板：按统一结构填写假设陈述、要消除的风险、原型类型、目标用户、成败阈值（Pass/Fail 标准）、时间线、处置计划和负责人，一份文档即可让团队对"怎样算失败"提前达成共识。
2. 5 种原型类型匹配：可行性检查（能不能做出来）、任务聚焦测试（用户能否无摩擦完成任务）、叙事原型（工作流能否获得支持）、合成数据模拟、Vibe-Coded 探针，按假设选 cheapest 的验证方式而非顺手的工具。
3. 质量检查清单：从轻量（1-3 天可建成）、可抛弃（有明确删除日期）、狭隘范围（只测一个假设）、诚实（数据不好看会疼）、可证伪、有明确负责人等维度自查，防止把探针做成舍不得删的原型剧场。

常见问题

PoL 探针和 MVP 有什么区别？

PoL 探针是 MVP 之前的侦察：只回答一个具体问题，几小时到几天完成，测完即删除，受众是内部团队和小样本用户；MVP 是可上线迭代的最小产品增量，面向真实客户，周期数周到数月。正确顺序是先用探针决定"要不要做 MVP"，而不是直接做一个伪装修的 MVP。

什么时候该用 PoL 探针，什么时候不该用？

适合：有具体可证伪的假设、某个风险正阻塞下一步决策、需要在几天内拿到真相、能提前描述"失败长什么样"。不适合：想向高管炫耀 demo（那是原型剧场）、心里已有答案只想找认同、说不出清晰假设和删除计划、学习目标太宽泛（如"用户会不会喜欢"）。

跑一次 PoL 探针需要多少时间和资源？

典型周期 4-5 天：搭建 1-2 天、测试 1 天（如 10 个用户会话）、分析 1 天、随后按处置计划删除代码只保留学习记录。工具上常用 ChatGPT Canvas、Replit、Airtable、Loom 等拼装，不写生产级代码；探针结束后要销毁工件，只沉淀结论。