在正式开发前用可丢弃的 PoL 探针低成本验证高风险假设

当你有一个具体、可证伪的假设或风险阻碍下一步决策，且不想先构建生产级软件时，用它设计一次快速、窄范围、必删的验证实验。

适用场景

解决思路

1. 先明确要验证的假设或风险；最好同时提供「什么证据会改变你的判断」、可用时间/资源、以及已验证内容。
2. 如果调用时已经附带了文本、上下文或 ARGUMENTS: 行，把它们当作已回答内容，直接使用并跳过重复提问，不要重复询问。
3. 即使空手开始也可行；在设计探针前，先向用户索取假设和其中风险最高的假设。
4. 把探针定义为 Proof of Life (PoL) probe：一个刻意设计、可丢弃、只回答一个问题的验证实验；不是产品、不是 MVP、不是 pilot。
5. 确保它满足 5 个核心特征：Lightweight（几小时/几天而非几周）、Disposable（计划删除而非扩展）、Narrow Scope（只测一个假设/风险）、Brutally Honest（暴露残酷真相而非虚荣指标）、Tiny & Focused（侦察任务而非 MVP）。
6. 检查反模式：如果原型精致到舍不得删除，它就不是 PoL 探针，而是 prototype theater。
7. 明确它与 MVP 的区别：PoL 探针是 pre-MVP 侦察，用于决定是否应该构建 MVP，而不是发布产品。
8. 从 5 种原型风味中选择一种，并让类型匹配假设，而不是匹配你熟悉的工具。
9. 若问题是「我们能不能构建它？」，选择 Feasibility Check，用 1-2 天，通过 GenAI prompt chains、API tests、data integrity sweeps、spike-and-delete code 验证；适用于技术风险未知或第三方依赖不清楚。
10. 若问题是「用户能否无摩擦完成这个任务？」，选择 Task-Focused Test，用 2-5 天，通过 Optimal Workshop、UsabilityHub、task flows 验证；适用于关键节点（field labels、decision points、drop-off zones）需要验证。
11. 若问题是「这个工作流能否赢得干系人支持？」，选择 Narrative Prototype，用 1-3 天，通过 Loom walkthroughs、Sora/Synthesia videos、slideware storyboards 验证；适用于需要讲而不是测、分享故事并衡量兴趣。
12. 若问题是「能否在不引入生产风险的情况下建模？」，选择 Synthetic Data Simulation，用 2-4 天，通过 Synthea、DataStax LangFlow 验证；适用于探索边缘情况和浮现 unknown-unknowns。
13. 若问题是「这个方案能否经受真实用户接触？」，选择 Vibe-Coded PoL Probe，用 2-3 天，通过 ChatGPT Canvas + Replit + Airtable 组成 Frankensoft 验证；适用于需要用户对工作流/UX 反馈，但不需要生产级代码。
14. 遵循黄金法则：使用能讲出最残酷真相的最便宜原型；如果它不刺痛，很可能只是 theater。
15. 使用 template.md 作为完整填写结构，并用 PoL Probe Template 记录探针。
16. 在模板中写 Hypothesis：一句话陈述你相信为真的事，例如「If we reduce the onboarding form to 3 fields, completion rate will exceed 80%.」。
17. 写 Risk Being Eliminated：要消除的具体风险或未知，例如「We don't know if users will abandon signup due to form length.」。
18. 选择 Prototype Type：从 5 种风味中勾选一种（Feasibility Check、Task-Focused Test、Narrative Prototype、Synthetic Data Simulation、Vibe-Coded PoL Probe）。
19. 写 Target Users / Audience：谁会与探针互动，例如「10 users from our early access waitlist, non-technical SMB owners.」。
20. 写 Success Criteria (Harsh Truth)：定义 Pass、Fail、Learn；Pass 如 8+ users complete signup in under 2 minutes，Fail 如 <6 users complete 或 average time exceeds 5 minutes，Learn 如 identify specific drop-off fields。
21. 写 Tools / Stack：列出构建用什么，例如 ChatGPT Canvas for form UI、Airtable for data capture、Loom for post-session interviews。
22. 写 Timeline：分别给出 Build、Test、Analyze、Disposal 的时间，例如 Build 2 days、Test 1 day (10 user sessions)、Analyze 1 day、Disposal Day 5。
23. 写 Disposal Plan：明确何时以及如何删除，例如 sessions 完成后 archive recordings、delete Frankensoft code、document learnings in Notion。
24. 指定 Owner：一个人对运行和处置该探针负责。
25. 跟踪 Status 清单：Hypothesis defined、Probe built、Users recruited、Testing complete、Learnings documented、Probe disposed。
26. 启动前跑 Quality Checklist：Lightweight（能否 1-3 天构建）、Disposable（是否承诺处置日期）、Narrow Scope（是否只测一个假设）、Brutally Honest（如果你错了，数据是否会让你难受）、Tiny & Focused（是否比 MVP 更小）、Falsifiable（能否描述失败）、Clear Owner（是否一人负责执行和处置）。
27. 如果 Quality Checklist 任意一项为「no」，修改探针或重新考虑是否需要探针。
28. 参考 examples/sample.md 的完整 PoL probe 示例；最小示例可按「Hypothesis、Probe Type、Pass」写，如 Hypothesis: Users can distinguish 「archive」 vs 「delete」；Probe Type: Task-Focused Test；Pass: 80%+ correct interpretation。
29. 可结合相关技能：pol-probe-advisor 选择原型类型、discovery-process 在验证阶段使用 PoL probes、problem-statement 在创建前定义问题、epic-hypothesis 在测试前框定假设。
30. 参考外部框架：Jeff Patton《User Story Mapping》精益验证原则、Marty Cagan《Inspired》2014 prototype flavors framework、Dean Peters《Vibe First, Validate Fast, Verify Fit》。
31. 按需选用工具类别：Feasibility 用 GenAI (ChatGPT, Claude)、API testing tools；Task-Focused 用 Optimal Workshop、UsabilityHub；Narrative 用 Loom、Sora、Synthesia、Veo3；Synthetic Data 用 Synthea、DataStax LangFlow；Vibe-Coded 用 ChatGPT Canvas、Replit、Airtable、Carrd。

适用边界 · 注意事项

• 不要用于向高管炫技、做 prototype theater；不要已经知道答案却只想找确认偏误式验证。
• 当无法说清可证伪假设或处置计划、学习目标太宽泛（如「用户会喜欢吗？」）、或只是用它逃避艰难决策时，不要使用。
• 不要把 PoL 探针当 proto-MVP 拒绝处置；不要用虚荣指标；不要在测试前跳过失败阈值；不要先选工具再选假设；启动前 Quality Checklist 任意一项为 no 时应修改或放弃。