| name | pol-probe |
| description | 在投入完整开发前，用最小成本验证假设时使用。适用于高不确定需求、新功能想法、有风险的方案。优先使用 5 种 PoL Probe 类型选择最合适的验证方式。 |
验证实验设计（PoL Probe）
参考来源：deanpeters/Product-Manager-Skills 的 pol-probe skill
PoL = Proof of Learning，目标不是证明方案"能做"，而是证明方案"该做"。
适用场景
- 有想法但不确定用户是否真需要
- 多个方案候选，不知道选哪个
- 投入大但失败成本高
- 需要数据支持的提案
- 新功能上线前的小规模测试
不适用场景
- 需求已经验证过，进入开发阶段
- 紧急修复或合规需求（必须做）
- 内部工具改进（不需要外部验证）
核心原则
1. 验证假设，不是验证方案
错：测试"语义搜索是否能做出来"
对：测试"用户是否真的因为找不到商品而流失"
2. 最小成本，最大信息量
能 30 分钟解决的不要花 3 小时
3. 验证失败 ≠ 失败
失败的实验也是有价值的发现
4. 提前定义成功标准
不能事后凑数据
5 种 PoL Probe 类型
1. 可行性验证（Feasibility Probe）
问题：技术上能不能做到？
适用：
- 涉及 AI/算法/性能的不确定方案
- 需要第三方 API 或数据源
- 跨系统集成
做法：
- 写一个最小原型/spike
- 不追求体验，只验证"能不能跑通"
- 时间预算：30~90 分钟
示例：
假设：能用现有数据训练出准确率 > 80% 的推荐模型
实验：用历史数据跑一次，看准确率
成功标准：准确率 ≥ 75%
失败后：放弃方案 / 换数据源 / 换算法
2. 任务验证（Task Probe）
问题：用户能不能完成操作？
适用：
做法：
- 纸面原型 / Figma 静态原型
- Wizard of Oz（人工模拟系统响应）
- 让 3~5 个真实用户尝试完成任务
示例：
假设：用户能在 3 分钟内完成新版下单流程
实验：5 个用户测试，记录耗时和卡点
成功标准：4/5 用户在 3 分钟内完成
失败后：简化流程 / 重新设计
3. 叙事验证（Narrative Probe）
问题：用户是否理解价值主张？
适用：
做法：
- 落地页（Landing Page）
- 假门测试（Fake Door）：放一个按钮但点击后告知"敬请期待"
- A/B 测试不同价值主张
示例：
假设：用户对"AI 智能推荐"的接受度高于"个性化推荐"
实验：两个落地页 A/B 测试，对比转化率
成功标准：A 版转化率 > B 版 20%
失败后：调整价值主张
4. 数据验证（Data Probe）
问题：数据是否支持假设？
适用：
做法：
- SQL 查询历史数据
- 日志分析
- 问卷调查
- 第三方数据源
示例：
假设：每月有 2000+ 用户因为找不到商品而流失
实验：分析最近 30 天的搜索失败 + 退出率数据
成功标准：数据支持月均 1500+
失败后：重新评估机会优先级
5. 快速原型（Vibe-Coded Probe）
问题：端到端能不能跑通？给用户的感觉对不对？
适用：
- 全新概念的产品
- AI 辅助开发的快速 MVP
- 内部 Demo 或路演
做法：
- AI 生成代码 + 现有组件库快速搭建
- 不追求生产质量，追求"能跑能演示"
- 时间预算：1~3 小时
示例：
假设：用 AI 推荐 + 现有商品库，能产生让用户感兴趣的商品流
实验：用 AI 生成一个原型 demo，给 10 个用户试用
成功标准：6/10 用户表示"会再来用"
失败后：调整方向或放弃
选择决策树
问题类型？
├─ 技术能不能做 → Feasibility
├─ 用户能不能用 → Task
├─ 用户买不买账 → Narrative
├─ 数据支不支持 → Data
└─ 整体感觉对不对 → Vibe-Coded
成本预算？
├─ 30 分钟内 → Data / Narrative
├─ 1 小时左右 → Feasibility / Task
└─ 半天 → Vibe-Coded
风险等级？
├─ 低（可逆） → Vibe-Coded（快速做）
└─ 高（不可逆） → Data + Task 双重验证
实验模板
## PoL Probe: [实验名称]
**类型**：Feasibility / Task / Narrative / Data / Vibe-Coded
**待验证假设**：
如果 [条件]，那么 [结果]
**验证方式**：
[具体怎么测，包括工具/数据/对象]
**成功标准**：
[必须是可观察、可量化的指标]
**失败后行动**：
- 如果失败：[放弃 / 调整 / 重新设计]
- 如果部分成功：[继续验证 / 缩小范围]
**时间预算**：
[最多花多少时间]
**所需资源**：
[需要哪些数据/工具/人员]
**实验记录**：
- 开始时间：
- 结束时间：
- 实际耗时：
- 结果数据：
- 结论：
- 后续行动：
工作流程
1. 识别需要验证的假设（来自 OST 或 PRD）
↓
2. 选择 PoL Probe 类型（用决策树）
↓
3. 设计实验（用模板）
↓
4. 设定成功标准（可量化、可观察）
↓
5. 设定时间预算（不超过预算就停）
↓
6. 执行实验
↓
7. 记录结果（成功/失败/部分成功）
↓
8. 决策：继续/调整/放弃
↓
9. 沉淀到 field-journal
质量自检
□ 实验类型是否选对了？（不要用 Feasibility 验证用户接受度）
□ 假设是否具体可测试？（不是"用户喜欢"而是"用户点击率 > X%"）
□ 成功标准是否提前定义？（不能事后凑数据）
□ 失败后行动是否提前规划？（避免"再做一个实验"的循环）
□ 时间预算是否合理？（PoL 不应该比正式开发还久）
□ 是否最小成本？（能 Data 就不 Vibe-Coded）
常见坑
- 混淆 Probe 类型——用 Feasibility（"能做出来"）代替 Task（"用户能用"）
- 没有成功标准——做完不知道是成功还是失败
- 时间预算超支——PoL 不该比正式开发还久
- 结果偏向自己想要的——选择性看数据
- 失败结果不沉淀——失败的实验也是宝贵经验
- 过度验证——不需要每个想法都做 PoL，明显的事直接做
- 验证完不决策——做完实验就放着，不进入下一步
配套模板
templates/pol-probe-template.md — 实验设计模板templates/probe-result-template.md — 实验结果记录模板
与其他 skill 的协作
上游：
opportunity-tree → 提供需要验证的假设
平行：
user-story → 验证某个用户故事的核心假设
prioritization → 验证高分但低置信度的方案
下游：
实验通过 → mvp-scoping 进入 MVP 范围
实验失败 → 调整 OST 或放弃
实验沉淀 → field-journal
