验证实验设计（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）

常见坑

1. 混淆 Probe 类型——用 Feasibility（"能做出来"）代替 Task（"用户能用"）
2. 没有成功标准——做完不知道是成功还是失败
3. 时间预算超支——PoL 不该比正式开发还久
4. 结果偏向自己想要的——选择性看数据
5. 失败结果不沉淀——失败的实验也是宝贵经验
6. 过度验证——不需要每个想法都做 PoL，明显的事直接做
7. 验证完不决策——做完实验就放着，不进入下一步

配套模板

• templates/pol-probe-template.md — 实验设计模板
• templates/probe-result-template.md — 实验结果记录模板

与其他 skill 的协作

上游：
  opportunity-tree → 提供需要验证的假设

平行：
  user-story → 验证某个用户故事的核心假设
  prioritization → 验证高分但低置信度的方案

下游：
  实验通过 → mvp-scoping 进入 MVP 范围
  实验失败 → 调整 OST 或放弃
  实验沉淀 → field-journal