# Pol Probe

> 在投入完整开发前，用最小成本验证假设时使用。适用于高不确定需求、新功能想法、有风险的方案。优先使用 5 种 PoL Probe 类型选择最合适的验证方式。

- Skill: `zhaoxuya520/pol-probe` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add zhaoxuya520/pol-probe`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhaoxuya520/pol-probe/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: zhaoxuya520 (https://skillmd.com/u/zhaoxuya520)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhaoxuya520/pol-probe

---


# 验证实验设计（PoL Probe）

参考来源：[deanpeters/Product-Manager-Skills](https://github.com/deanpeters/Product-Manager-Skills) 的 pol-probe skill

PoL = Proof of Learning，目标不是证明方案"能做"，而是证明方案"该做"。

## 适用场景

- 有想法但不确定用户是否真需要
- 多个方案候选，不知道选哪个
- 投入大但失败成本高
- 需要数据支持的提案
- 新功能上线前的小规模测试

## 不适用场景

- 需求已经验证过，进入开发阶段
- 紧急修复或合规需求（必须做）
- 内部工具改进（不需要外部验证）

## 核心原则

```text
1. 验证假设，不是验证方案
   错：测试"语义搜索是否能做出来"
   对：测试"用户是否真的因为找不到商品而流失"

2. 最小成本，最大信息量
   能 30 分钟解决的不要花 3 小时

3. 验证失败 ≠ 失败
   失败的实验也是有价值的发现

4. 提前定义成功标准
   不能事后凑数据
```

## 5 种 PoL Probe 类型

### 1. 可行性验证（Feasibility Probe）

**问题**：技术上能不能做到？

**适用**：
- 涉及 AI/算法/性能的不确定方案
- 需要第三方 API 或数据源
- 跨系统集成

**做法**：
- 写一个最小原型/spike
- 不追求体验，只验证"能不能跑通"
- 时间预算：30~90 分钟

**示例**：
```text
假设：能用现有数据训练出准确率 > 80% 的推荐模型
实验：用历史数据跑一次，看准确率
成功标准：准确率 ≥ 75%
失败后：放弃方案 / 换数据源 / 换算法
```

### 2. 任务验证（Task Probe）

**问题**：用户能不能完成操作？

**适用**：
- 流程复杂的功能
- 新交互模式
- 信息架构改造

**做法**：
- 纸面原型 / Figma 静态原型
- Wizard of Oz（人工模拟系统响应）
- 让 3~5 个真实用户尝试完成任务

**示例**：
```text
假设：用户能在 3 分钟内完成新版下单流程
实验：5 个用户测试，记录耗时和卡点
成功标准：4/5 用户在 3 分钟内完成
失败后：简化流程 / 重新设计
```

### 3. 叙事验证（Narrative Probe）

**问题**：用户是否理解价值主张？

**适用**：
- 新产品定位
- 新功能宣传
- 营销文案验证

**做法**：
- 落地页（Landing Page）
- 假门测试（Fake Door）：放一个按钮但点击后告知"敬请期待"
- A/B 测试不同价值主张

**示例**：
```text
假设：用户对"AI 智能推荐"的接受度高于"个性化推荐"
实验：两个落地页 A/B 测试，对比转化率
成功标准：A 版转化率 > B 版 20%
失败后：调整价值主张
```

### 4. 数据验证（Data Probe）

**问题**：数据是否支持假设？

**适用**：
- 提案需要数据支持
- 用户行为分析
- 市场容量评估

**做法**：
- SQL 查询历史数据
- 日志分析
- 问卷调查
- 第三方数据源

**示例**：
```text
假设：每月有 2000+ 用户因为找不到商品而流失
实验：分析最近 30 天的搜索失败 + 退出率数据
成功标准：数据支持月均 1500+
失败后：重新评估机会优先级
```

### 5. 快速原型（Vibe-Coded Probe）

**问题**：端到端能不能跑通？给用户的感觉对不对？

**适用**：
- 全新概念的产品
- AI 辅助开发的快速 MVP
- 内部 Demo 或路演

**做法**：
- AI 生成代码 + 现有组件库快速搭建
- 不追求生产质量，追求"能跑能演示"
- 时间预算：1~3 小时

**示例**：
```text
假设：用 AI 推荐 + 现有商品库，能产生让用户感兴趣的商品流
实验：用 AI 生成一个原型 demo，给 10 个用户试用
成功标准：6/10 用户表示"会再来用"
失败后：调整方向或放弃
```

## 选择决策树

```text
问题类型？
  ├─ 技术能不能做 → Feasibility
  ├─ 用户能不能用 → Task
  ├─ 用户买不买账 → Narrative
  ├─ 数据支不支持 → Data
  └─ 整体感觉对不对 → Vibe-Coded

成本预算？
  ├─ 30 分钟内 → Data / Narrative
  ├─ 1 小时左右 → Feasibility / Task
  └─ 半天 → Vibe-Coded

风险等级？
  ├─ 低（可逆） → Vibe-Coded（快速做）
  └─ 高（不可逆） → Data + Task 双重验证
```

## 实验模板

```markdown
## PoL Probe: [实验名称]

**类型**：Feasibility / Task / Narrative / Data / Vibe-Coded

**待验证假设**：
如果 [条件]，那么 [结果]

**验证方式**：
[具体怎么测，包括工具/数据/对象]

**成功标准**：
[必须是可观察、可量化的指标]

**失败后行动**：
- 如果失败：[放弃 / 调整 / 重新设计]
- 如果部分成功：[继续验证 / 缩小范围]

**时间预算**：
[最多花多少时间]

**所需资源**：
[需要哪些数据/工具/人员]

**实验记录**：
- 开始时间：
- 结束时间：
- 实际耗时：
- 结果数据：
- 结论：
- 后续行动：
```

## 工作流程

```text
1. 识别需要验证的假设（来自 OST 或 PRD）
   ↓
2. 选择 PoL Probe 类型（用决策树）
   ↓
3. 设计实验（用模板）
   ↓
4. 设定成功标准（可量化、可观察）
   ↓
5. 设定时间预算（不超过预算就停）
   ↓
6. 执行实验
   ↓
7. 记录结果（成功/失败/部分成功）
   ↓
8. 决策：继续/调整/放弃
   ↓
9. 沉淀到 field-journal
```

## 质量自检

```text
□ 实验类型是否选对了？（不要用 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 的协作

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

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

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