需要验证产品假设/消除风险但不确定选哪种验证方法时…

当已有假设或要消除的风险、却在多种验证方式间犹豫时，用核心问题、时间线和资源选择 5 类 PoL 探针之一。

适用场景

解决思路

1. 先收集上下文：询问或提取用户正在测试的假设，建议用一句话或 “If [we do X] for [persona], then [outcome]” 格式描述。
2. 明确要消除的具体风险，例如技术可行性、用户任务完成、干系人对齐、边缘案例行为、工作流验证。
3. 确认时间线：小时（当天验证）、1-2 天（快速 spike）、3-5 天（中等投入）、1 周以上（过长，考虑拆成更小探针）。
4. 盘点可用资源：工程能力（如 1 dev for 1 day）、设计工具（Figma、Loom、Sora）、AI/no-code 工具（ChatGPT Canvas、Replit、Airtable）、用户接触（10 users from waitlist、5 beta customers 等）、预算（UsabilityHub、Optimal Workshop 等）。
5. 如果调用时已提供文本（技能名后的文本、粘贴的上下文、附加的 `ARGUMENTS:` 行），把这些当作已回答，直接使用并跳过对应问题，不要重复询问。
6. 如果用户空手而来，先问“你想学到什么”，然后匹配到 5 类探针之一。
7. 综合用户输入，询问其真正要回答的核心问题，并提供 5 个选项：1) “Can we build this?”；2) “Can users complete this job without friction?”；3) “Does this workflow earn stakeholder buy-in?”；4) “Can we model this without production risk?”；5) “Will this solution survive real user contact?”。
8. 根据用户选择的核心问题，推荐匹配的 PoL 探针类型。
9. 选择 Feasibility Check：核心问题 “Can we build this?”，适合技术未知、API 依赖、数据完整性；时间 1-2 天。
10. Feasibility Check 方法：GenAI prompt chains、API sniff tests、Data integrity sweeps、third-party tool evaluation。
11. Feasibility Check 工具：ChatGPT/Claude、Postman/Insomnia、Jupyter notebooks、throwaway proof-of-concept scripts。
12. Feasibility Check 成功标准示例：Pass 为 API 在 <200ms 内返回预期数据格式；Fail 为 API 超时或数据结构与 schema 不兼容；Learn 为识别具体技术阻塞。
13. Feasibility Check 处置计划：记录发现后删除所有 spike code。
14. Feasibility Check 下一步：询问是否生成 `pol-probe` artifact 记录该 feasibility check。
15. 选择 Task-Focused Test：核心问题 “Can users complete this job without friction?”，适合关键 UI 时刻、字段标签、决策点、导航、drop-off zones；时间 2-5 天。
16. Task-Focused Test 方法：Optimal Workshop（tree testing、card sorting）、UsabilityHub（5-second tests、click tests、preference tests）、Maze（prototype testing with heatmaps）、Loom-recorded task walkthroughs（要求用户 think aloud）。
17. Task-Focused Test 工具：Optimal Workshop ($200/month)、UsabilityHub ($100-300/month)、Maze（free tier available）、Loom（free for basic）。
18. Task-Focused Test 成功标准示例：Pass 为 80%+ 用户在 <2 分钟内完成任务；Fail 为 <60% 完成率，或 3+ 用户卡在同一步骤；Learn 为识别确切摩擦点（具体字段、按钮等）。
19. Task-Focused Test 处置计划：归档 session recordings，记录 learnings，删除 test prototype。
20. Task-Focused Test 下一步：询问是否生成 `pol-probe` artifact 记录该 task-focused test。
21. 选择 Narrative Prototype：核心问题 “Does this workflow earn stakeholder buy-in?”，适合讲故事、解释复杂流程、对齐；时间 1-3 天。
22. Narrative Prototype 方法：Loom walkthroughs（screen recording with voiceover）、Sora/Synthesia/Veo3（AI-generated explainer videos）、Slideware storyboards（PowerPoint/Keynote with illustrations）、Storyboard sketches（使用 `storyboard.md` component skill）。
23. Narrative Prototype 工具：Loom（free, fast）、Sora/Synthesia（text-to-video, paid）、PowerPoint/Keynote（slideware animation）、Figma（static storyboard frames）。
24. Narrative Prototype 成功标准示例：Pass 为 8/10 干系人说 “I’d use this” 或 “This solves the problem”；Fail 为干系人问 “Why would I use this?” 或建议替代方案；Learn 为识别叙事中哪些部分引起共鸣（或没有）。
25. Narrative Prototype 处置计划：归档 video，记录 feedback，删除 supporting files。
26. Narrative Prototype 下一步：询问是否生成 `pol-probe` artifact 记录该 narrative prototype。
27. 选择 Synthetic Data Simulation：核心问题 “Can we model this without production risk?”，适合边缘案例、unknown-unknowns、统计建模；时间 2-4 天。
28. Synthetic Data Simulation 方法：Synthea（synthetic patient data generation）、DataStax LangFlow（test prompt logic without real users）、Monte Carlo simulations（model probabilistic outcomes）、Synthetic user behavior scripts（simulate click patterns, load testing）。
29. Synthetic Data Simulation 工具：Synthea（open-source, healthcare）、DataStax LangFlow（prompt chain testing）、Python + Faker library（generate synthetic data）、Locust/k6（load testing with synthetic users）。
30. Synthetic Data Simulation 成功标准示例：Pass 为系统处理 10,000 synthetic users 且 <1% error rate；Fail 为边缘案例导致崩溃或错误输出；Learn 为识别哪些边缘案例会破坏系统。
31. Synthetic Data Simulation 处置计划：删除 synthetic data，归档 findings，记录 edge cases。
32. Synthetic Data Simulation 下一步：询问是否生成 `pol-probe` artifact 记录该 synthetic data simulation。
33. 选择 Vibe-Coded PoL Probe：核心问题 “Will this solution survive real user contact?”，适合让用户与半功能工作流互动以捕捉 UX/workflow 问题；时间 2-3 天。
34. Vibe-Coded PoL Probe 方法：ChatGPT Canvas（quick UI generation）、Replit（host throwaway code）、Airtable（fake database）、Carrd/Webflow（landing page + workflow mockup）。
35. Vibe-Coded PoL Probe 技术栈示例：ChatGPT Canvas 生成 form UI；Replit 托管 simple Flask/Node app；Airtable 捕获 form submissions；Loom 录制 user sessions 供 post-mortem analysis。
36. Vibe-Coded PoL Probe 警告：这是风险最高的探针类型，看起来真实到容易把 momentum 误认为 maturity；仅在需要真实用户接触且其他方法不够用时使用。
37. Vibe-Coded PoL Probe 成功标准示例：Pass 为 8/10 用户完成 workflow，0 critical confusion moments；Fail 为用户卡住、问 “Is this broken?” 或中途放弃；Learn 为识别用户失去信心的确切步骤。
38. Vibe-Coded PoL Probe 处置计划：用户会话后删除所有 code，归档 Loom recordings，记录 learnings。
39. Vibe-Coded PoL Probe 下一步：询问是否生成 `pol-probe` artifact 记录该 vibe-coded probe。
40. 在推荐后提供组件技能选项：1) 用 `pol-probe.md` 模板生成完整 `pol-probe` artifact（包含假设、成功标准、时间线、处置计划）；2) 走查该探针类型的执行步骤（工具、方法、用户招募）；3) 在继续前精炼假设（如果太宽泛或模糊）。
41. 如果用户不确定或假设太宽泛，询问澄清问题：能先测试的最小事情是什么（隔离一个变量）？失败会是什么样（描述不了失败就无法衡量成功）？这是在测试用户行为、技术可行性还是干系人对齐（选一个焦点）？
42. 根据精炼后的假设重新推荐探针类型。
43. 使用 `workshop-facilitation` 作为默认交互协议：session heads-up + entry mode（Guided、Context dump、Best guess）、one-question turns with plain-language prompts、progress labels（例如 Context Qx/8 和 Scoring Qx/5）、interruption handling and pause/resume、numbered recommendations at decision points、quick-select numbered response options（有用时包含 `Other (specify)`）。
44. 本 skill 定义领域评估内容；如果与 `workshop-facilitation` 冲突，遵循本文件的领域逻辑。
45. 避免 anti-pattern：不要“构建你熟悉的原型”，要把方法匹配假设而不是技能组。
46. 避免 anti-pattern：不要“根据干系人偏好选择”，要优化学习而不是内部政治。
47. 避免 anti-pattern：不要“选择最令人印象深刻的选项”，令人印象深刻 ≠ 有信息量。
48. 避免 anti-pattern：不要“默认写代码”，写代码应是最后手段而不是首选。
49. 常见陷阱修复：如果按工具熟练度选择，先回答核心问题再选方法；若需要 Feasibility Check 但只会设计工具，找工程师配对 1 天。
50. 常见陷阱修复：如果默认写代码，问“能讲述最严酷真相的最便宜原型是什么？”通常不是代码。
51. 常见陷阱修复：如果混淆 Vibe-Coded Probe 与 MVP，构建前设定处置日期；Vibe-Coded probes 按设计就是 Frankensoft，庆祝其 jank，学习后删除。
52. 常见陷阱修复：如果一次测试多个东西，保持一探针一假设；有 3 个假设就跑 3 个探针。
53. 常见陷阱修复：如果跳过成功标准，在构建前写成功标准，定义 pass、fail、learn 阈值。
54. 遵守 Golden Rule：“Use the cheapest prototype that tells the harshest truth.”
55. 示例：假设为 “Users can complete our checkout flow in under 3 minutes”，风险为 mobile 高购物车放弃率，时间 3 天，资源为 UsabilityHub 账号和 20 users from waitlist；选 Task-Focused Test，用 Maze prototype testing，成功标准 80%+ complete checkout in <3 minutes，分析 heatmaps 后删除 prototype。
56. 示例：假设为 “We can auto-tag support tickets using GPT-4 with <5% error rate”，风险为 AI 是否能处理行业术语，时间 1 天，资源为 100 past support tickets 和 ChatGPT API access；选 Feasibility Check，跑 100 tickets through GPT-4 prompt chain 测 error rate，成功标准 <5% misclassified；结果 18% error，决定不 build，节省 6 周开发。
57. 示例：假设为 “Enterprise buyers will understand our multi-tenant security model”，风险为复杂技术概念需要解释，时间 2 天，资源为 Loom 和 5 enterprise prospects；选 Narrative Prototype，用 5-minute Loom explaining security model with diagrams，成功标准 4/5 prospects say “I understand this” without follow-up questions，5 sessions 后归档 video；不要选 Vibe-Coded，因为需要用户理解概念而非操作安全设置。
58. 示例：假设为 “Executives will approve budget if we show a polished demo”，风险为内部政治，时间 3 周，资源为 full design team；这是 prototype theater，不是 PoL probe；跳过 prototype，用 1-day Loom Narrative Prototype 解释概念，用 5 target users（不是 executives）验证假设，向 executives 展示用户反馈而非 polished demo；如果 executives 需要 demo，在真实用户验证后再构建。

适用边界 · 注意事项

• 还没有假设时，先用 `problem-statement.md` 或 `problem-framing-canvas.md` 做问题定义。
• 想取悦高管、做原型表演而不是学习验证时。
• 已经知道答案（确认偏误），或需要交付 MVP 而不是 pre-MVP 侦察时。