---
name: reliability-pmf-diagnosis
version: 2.0
framework: 智能体管理学 · 模块三 · 框架F16
type: 诊断型
description: >
  可靠性产品市场匹配诊断（Reliability-PMF）。当需要评估Agent产品是否达到
  真正的产品市场匹配、识别假PMF信号、或制定PMF路径时触发。关键词：PMF、
  任务完成率、Override率、Re-delegation率、假PMF、可托付。
governance_nerves: [意图管理, 边界与升级]
upstream_frameworks: [F14-需求框架, F15-上下文设计]
downstream_frameworks: [F17-VERITAS评估, F18-CATER治理]
---

# F16 可靠性产品市场匹配诊断（Reliability-PMF）

## SKILL定位

**核心命题**：Agent产品的核心诉求是「可托付」而非「好用」。传统PMF依赖DAU/NPS，但Agent产品的真正匹配信号是——用户愿不愿意把重要任务交给它、交出去之后需不需要反复修正、修正之后还愿不愿意继续用。

**颠覆对象**：传统PMF指标体系（DAU、NPS、留存率）。这些指标对Agent产品存在系统性盲区：一个「好用但不可托付」的Agent可以有高留存和高NPS，但用户从不让它做真正重要的事。

**三指标体系**：
1. **任务完成率（Task Completion Rate, TCR）**≥90%：Agent独立完成任务的比例
2. **Override率（OCR）**≤20%：用户修改Agent输出的比例
3. **Re-delegation率（RDR）**≥60%：用户再次把同类任务交给Agent的比例

---

## 信息采集（INPUT模板）

```yaml
# === PMF诊断输入 ===
product_name: ""
agent_type: ""
launch_duration: ""                 # 上线时长
user_base_size: ""                  # 用户基数

# 三指标数据
task_completion_rate: ""            # 任务完成率（%）
override_rate: ""                   # Override率（%）
re_delegation_rate: ""              # Re-delegation率（%）

# 传统指标（对照用）
dau: ""
nps: ""
retention_rate: ""                  # 留存率
session_frequency: ""               # 会话频率

# 任务分布
task_distribution:
  simple_tasks: ""                  # 简单任务占比
  medium_tasks: ""                  # 中等任务占比
  complex_tasks: ""                 # 复杂任务占比
critical_task_delegation: ""        # 用户是否把重要任务交给Agent（是/否/部分）

# 用户行为信号
user_behavior_signals:
  avg_tasks_per_session: ""
  abandonment_rate: ""              # 中途放弃率
  manual_fallback_rate: ""          # 手动兜底率
  escalation_rate: ""               # 升级到人工率
```

---

## 执行分析引擎（S1-S4）

### S1：三指标数据采集与校验（Data Collection & Validation）

**目标**：获取真实可靠的三指标数据，并校验数据质量。

**执行步骤**：
1. **定义统计口径**：明确「任务」的边界（什么算一次任务？什么算完成？）
2. **数据采集**：从日志/埋点/用户调研获取三指标
3. **数据校验**：检查样本量是否足够（≥100个任务）、是否存在幸存者偏差
4. **分层分析**：按任务复杂度分层统计，避免简单任务拉高均值

**评分锚点**：
- 5分：数据来源可靠，样本量充足，已做分层分析，口径清晰
- 3分：数据基本可靠但样本量偏小或未做分层
- 1分：数据来源不明或存在明显偏差

**输出模板**：
```yaml
data_validation:
  sample_size: ""
  time_range: ""
  data_source: ""                   # 日志/埋点/调研
  stratification:
    simple_task_tcr: ""
    medium_task_tcr: ""
    complex_task_tcr: ""
  bias_check:
    survivorship_bias: ""           # 是否存在
    selection_bias: ""
  overall_quality: ""               # 高/中/低
```

### S2：PMF阶段诊断（PMF Stage Diagnosis）

**目标**：基于三指标组合判断产品所处的PMF阶段。

**阶段定义**：

| 阶段 | TCR | OCR | RDR | 含义 |
|------|-----|-----|-----|------|
| Pre-PMF | <70% | >40% | <30% | Agent能力不足，用户不信任 |
| 早期PMF | 70-85% | 25-40% | 30-50% | 简单任务可用，复杂任务仍需人工 |
| 真PMF | ≥90% | ≤20% | ≥60% | 用户可托付，形成复用习惯 |
| 假PMF | 高 | 低 | 低 | 用户觉得好用但不托付 |

**评分锚点**：
- 5分：三指标均达真PMF阈值，且在复杂任务上也接近
- 3分：简单任务达真PMF，复杂任务处于早期PMF
- 1分：三指标均在Pre-PMF范围

**输出模板**：
```yaml
pmf_stage:
  overall_stage: ""                 # Pre-PMF / 早期PMF / 真PMF / 假PMF
  by_task_complexity:
    simple: ""
    medium: ""
    complex: ""
  trend: ""                         # 改善中/稳定/恶化
  time_to_pmf_estimate: ""          # 预计还需多久达到真PMF
```

### S3：假PMF识别（False PMF Detection）

**目标**：识别「看起来像PMF但实际不是」的信号。

**假PMF的五个特征**：
1. **高留存+低委托**：用户每天来用，但只做简单任务
2. **高NPS+高Override**：用户说好用，但输出都要改
3. **活跃度集中在低价值任务**：80%的使用场景是「试试看」而非「真干活」
4. **重要任务回流人工**：关键时刻用户一定自己做
5. **增长靠尝鲜而非口碑**：新用户来自营销而非老用户推荐

**评分锚点**：
- 5分：无假PMF信号，用户行为数据显示真正的信任和托付
- 3分：存在1-2个假PMF信号但不严重
- 1分：3个以上假PMF信号，产品可能处于假PMF状态

**输出模板**：
```yaml
false_pmf_check:
  signals_detected:
    - signal: ""
      severity: ""                  # 高/中/低
      evidence: ""
  false_pmf_risk: ""                # 高/中/低
  root_cause_hypothesis: ""         # 为什么会假PMF
```

### S4：PMF路径规划（PMF Roadmap）

**目标**：基于诊断结果，制定从当前阶段到真PMF的行动路径。

**执行步骤**：
1. **差距分析**：当前指标与真PMF阈值的差距
2. **瓶颈识别**：哪个指标是最大瓶颈？（通常是TCR）
3. **杠杆点分析**：提升哪个指标能带动其他指标？
4. **行动排序**：按影响力×可行性排序

**评分锚点**：
- 5分：路径清晰，杠杆点明确，有30/60/90天里程碑
- 3分：方向正确但里程碑模糊
- 1分：路径不清晰，缺乏可执行的下一步

**输出模板**：
```yaml
pmf_roadmap:
  gap_analysis:
    tcr_gap: ""                     # 当前值 → 目标值
    ocr_gap: ""
    rdr_gap: ""
  bottleneck: ""                    # 最大瓶颈指标
  leverage_point: ""                # 杠杆点
  action_plan:
    30_day: []
    60_day: []
    90_day: []
  success_metrics: []
```

---

## 输出格式

### PMF诊断报告

```markdown
# PMF诊断报告 — [产品名称]

## 1. 诊断摘要
- 当前阶段：[Pre-PMF / 早期PMF / 真PMF / 假PMF]
- TCR: [X]% | OCR: [Y]% | RDR: [Z]%
- 最大瓶颈：[指标名称]
- 预计达标时间：[X]天

## 2. 三指标分析
[每个指标的现状、趋势、与阈值的差距]

## 3. 假PMF检查
[是否检测到假PMF信号、具体证据]

## 4. 分层分析
[按任务复杂度的三指标拆解]

## 5. PMF路径
[30/60/90天行动计划]

## 6. 关键假设与风险
[诊断中依赖的假设、数据风险]
```

---

## 治理神经检查

- **意图管理**：三指标是否真正反映了用户意图？用户Override是因为Agent理解错了意图，还是输出质量不够？
- **边界与升级**：TCR低是因为任务超出Agent能力边界，还是因为上下文设计问题？需要区分「不该做」和「做不好」。

---

## 质量自检

- [ ] 三指标数据来源可靠，口径清晰
- [ ] 已做分层分析（按任务复杂度）
- [ ] 假PMF检查已完成
- [ ] PMF路径有明确的里程碑
- [ ] 瓶颈指标已识别
- [ ] 行动计划按影响力排序

---

## 典型误区

1. **「NPS高就是PMF」**：错。NPS衡量的是满意度，不是可托付度。用户可以说「这个工具很好」但从不用它做重要任务
2. **「DAU增长就是PMF」**：错。Agent产品的DAU可能来自尝鲜而非真正价值。要看用户是否反复把同类任务交给Agent
3. **「完成率90%就够了」**：注意分层。简单任务99%+复杂任务50%=整体可能90%，但用户在关键时刻一定不信任你
4. **「Override说明用户参与度高」**：错。Override说明Agent输出不可直接使用，是质量问题不是参与度信号

---

## 框架衔接

- **上游 → F14/F15**：需求定义和上下文设计质量直接影响TCR和OCR
- **下游 → F17**：VERITAS七维评估是提升TCR的工具——知道哪个维度拖后腿
- **下游 → F18**：CATER治理评估解释为什么RDR上不去——可能是治理信任不足
- **横向 → F06**：商业模式设计需要基于真实PMF状态，假PMF会导致错误的商业化节奏