p2b-product-form-exploration

---
name: p2b-product-form-exploration
description: 'AI Native 产品方法论——产品形态探索的实操 Skill。

  用户提供能力实验结论，Skill 自动执行产品形态探索：

  能力边界分析 → 交互原型设计 → 工作流嵌入测试 → 产品形态判断 → 输出产品形态建议。

  基于《AI Native 产品方法论》第07章（试验展开-产品形态探索）。

  '
tags:
- ai-product
- methodology
- product-form
- interaction-design
- experiment-driven-design
- book-skill
author: Max
source_book: AI Native 产品方法论
source_chapter: 第07章 试验展开-产品形态探索
version: 1.0
stage: p2b
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p2b-product-form-exploration
---

# 产品形态探索 Skill

## 使用场景

- 能力实验已完成，需要探索能力最终以什么形态服务于用户
- 不确定应该做问答、Copilot、工作流还是 Agent
- 需要用实验驱动设计（Experiment Driven Design）而非拍脑袋定形态

## 核心概念

- **实验驱动设计（Experiment Driven Design）**：先通过实验发现能力边界，再反过来定义产品形态
- **能力入口**：用户进入某项能力的方式（问答、Copilot、工作台、自动流程、Agent）
- **产品形态**：能力最终以什么交互和工作流被用户使用，而非页面长什么样

## 产品形态决策框架

| 能力特征 | 推荐形态 |
|---------|---------|
| 低风险、高重复、边界清晰 | 自动流程 / Agent |
| 中风险、需要人工确认 | Copilot |
| 高风险、需要透明解释 | 工作台（人工主导） |
| 探索期、边界不清 | 问答 + 反馈收集 |

## 探索流程

```
能力实验结论
  → 能力边界分析
    → 候选形态列举
      → 交互原型设计
        → 工作流嵌入测试
          → 产品形态决策
```

## 第一步：能力边界分析

从能力实验结论提取关键维度：

| 维度 | 问题 | 影响 |
|------|------|------|
| 风险等级 | 出错后影响多大？ | 决定自动化程度上限 |
| 边界清晰度 | AI 能明确判断的场景占比？ | 决定自主模式可行性 |
| 任务重复度 | 同一任务出现频率？ | 决定投入产出比 |
| 用户期望 | 用户希望快还是希望准？ | 决定形态侧重 |

## 第二步：候选形态列举

基于能力边界，列举所有形态可能性：

1. **问答**：适合信息查询、规则解释、FAQ 类
2. **Copilot**：适合需要人工确认、高风险、有合规要求的场景
3. **工作台**：适合复杂判断、需要人工整合多源信息的场景
4. **自动流程**：适合低风险、边界清晰、重复高的任务
5. **Agent**：适合多步骤、有工具调用需求、但风险可控的场景

## 第三步：交互原型设计

每个候选形态设计原型，验证：

- 用户如何进入（入口设计）
- 系统如何输出（展示形式）
- 用户如何纠偏（反馈机制）
- 失败时如何处理（降级策略）

## 第四步：工作流嵌入测试

原型必须在真实工作流中测试，而非仅限演示：

- 模拟完整任务链路
- 记录中断点和人工介入点
- 测量效率提升和用户满意度

## 输出物：产品形态建议

1. **形态推荐**：基于能力边界的最优形态
2. **交互原型**：入口、输出、反馈机制设计
3. **工作流嵌入方案**：如何嵌入现有工作流
4. **风险边界**：该形态的风险上限和管理方式
5. **进入下阶段条件**：什么条件下可以进入流程重构

## 与其他 Skill 的关系

- **前置**：@p2a-experiment-overview（提供能力实验结论）
- **后置**：@p2c-process-redesign（深入流程层面）、@p2d-convergence-decision（收敛决策）
- **协同**：@ai-native-ux-design（UX 设计细节）

## 示例

### 用户输入
"客服 Copilot 能力实验已完成，订单查询准确率 92%，物流解释 85%，但售后政策 78%，多轮上下文处理不稳定"

### Skill 执行

```yaml
能力边界分析:
  风险: 中（售后政策出错可能引发投诉）
  边界清晰度: 订单/物流高，售后低
  推荐形态: Copilot（人工确认模式）

形态原型:
  界面: 侧边栏候选回复 + 风险标记
  交互: 一键采纳 / 快速编辑 / 风险提示
  边界: 退款/赔付类必须人工确认后发送

工作流嵌入:
  当前流程: 客服读工单→查系统→组织回复→发送
  新流程: AI预读→建议回复→客服确认→发送
  预期提升: 首响时间-60%，培训周期-50%

进入下阶段条件:
  ✅ 采纳率 > 60%（通过影子验证）
  ✅ 风险标记准确率 > 85%
  ⏳ 售后政策准确率需提升至 85%+
```

---

## 深入核心概念

基于书稿第07章，以下概念在执行本 Skill 时需深入理解：

- **从"设计功能"转向"设计能力入口"**：AI 产品设计的重点不是先决定按钮位置，而是先决定能力如何被用户触发、理解和信任。产品设计的对象不只是页面，更是"能力入口 + 上下文 + 反馈机制"。
- **能力入口五形态**：用户进入某项能力的方式有五种——问答（适合信息查询和 FAQ）、Copilot（适合需要人工确认的中风险场景）、工作台（适合复杂判断和多源信息整合）、自动流程（适合低风险高重复任务）、Agent（适合多步骤工具调用但风险可控的场景）。
- **产品形态不是一次设计出来的**：AI Native Product Design 的本质是让设计从"静态页面规划"转向"能力与任务协作设计"。产品形态在实验中逐渐稳定，而非在 PRD 中一次确定。
- **设计在方法论中的位置**：产品设计更接近试验展开的后段，而非方向定界之后立刻展开的完整定稿。设计在能力被逐步验证时，开始把"可成立的能力"翻译成"可理解、可使用、可被信任的产品入口"。
- **四个关键判断问题**：用户在什么任务节点最需要 AI？AI 能帮用户完成哪一段关键工作？用户如何判断 AI 的结果是否可用？当 AI 不确定时，如何把控制权交回给用户？

## 分步执行指南

基于书稿方法论，本 Skill 的完整执行分为 5 步：

### 步骤 1：能力边界分析
- 从能力实验结论中提取四个关键维度：风险等级（出错后影响多大）、边界清晰度（AI 能明确判断的场景占比）、任务重复度（同一任务出现频率）、用户期望（用户希望快还是希望准）
- 评估每个维度对产品形态的约束：风险等级决定自动化程度上限，边界清晰度决定自主模式可行性，任务重复度决定投入产出比，用户期望决定形态侧重
- 输出能力边界分析报告

### 步骤 2：候选形态列举与初步筛选
- 基于能力边界，列举所有形态可能性：问答、Copilot、工作台、自动流程、Agent
- 用决策矩阵初步筛选：低风险+高重复+边界清晰 → 自动流程/Agent；中风险+需人工确认 → Copilot；高风险+需透明解释 → 工作台；探索期+边界不清 → 问答+反馈收集
- 排除明显不匹配的形态，保留 2-3 个候选

### 步骤 3：交互原型设计
- 为每个候选形态设计原型，覆盖四个维度：入口设计（用户如何进入）、展示形式（系统如何输出）、反馈机制（用户如何纠偏）、降级策略（失败时如何处理）
- 原型要能回答：用户在什么任务节点最需要 AI、AI 能完成哪段关键工作、用户如何判断结果是否可用、AI 不确定时如何交回控制权
- 快速生成可运行 demo（流程类 / 功能类 / 界面类）

### 步骤 4：工作流嵌入测试
- 在真实工作流中测试原型（而非仅限演示）
- 模拟完整任务链路，记录中断点和人工介入点
- 测量效率提升和用户满意度
- 识别哪些能力单看实验不错，但进入流程后暴露出上下文不足、责任边界不清、异常处理缺失等问题

### 步骤 5：产品形态决策
- 综合能力边界、交互测试和工作流验证结果，做出形态决策
- 确定产品形态推荐、交互方案、工作流嵌入方案、风险边界
- 定义进入下一阶段的条件（如采纳率阈值、风险标记准确率阈值）
- 输出产品形态建议文档

## 示例一：客服 Copilot 形态探索

### 用户输入
"客服 Copilot 能力实验已完成，订单查询准确率 92%，物流解释 85%，但售后政策 78%，多轮上下文处理不稳定。需要探索产品形态。"

### Skill 执行

```yaml
能力边界分析:
  风险等级: 中（售后政策出错可能引发投诉和赔付）
  边界清晰度:
    订单查询: 高（规则明确，AI 可自主处理）
    物流解释: 高（物流状态查询标准化）
    售后政策: 低（政策条款多，例外多，需人工判断）
  任务重复度: 高（日均 500+ 工单，70% 为重复类型）
  用户期望: 快（客服追求首响时间，但不能牺牲准确性）

候选形态评估:
  问答形态: ❌ 排除（客服场景需要嵌入工作流，非独立问答）
  Copilot 形态: ✅ 最优（中风险+需人工确认+嵌入工作台）
  工作台形态: ⚠️ 候选（如果 Copilot 交互不自然可回退）
  自动流程: ❌ 排除（售后场景风险不可控）
  Agent 形态: ❌ 排除（多轮上下文不稳定，不适合自主执行）

交互原型设计（Copilot 形态）:
  入口设计:
    触发: 工单进入时自动读取上下文并生成建议
    位置: 客服工作台右侧侧边栏
  展示形式:
    候选回复: 2-3 条，按置信度排序
    风险标记: 🔴 高风险（退款/赔付）🟡 中风险（政策解释）🟢 低风险（查询类）
    规则引用: 每条建议附带引用的规则来源
  反馈机制:
    一键采纳: 点击即填充到回复框
    快速编辑: 在建议基础上修改
    标记不准确: 反馈到评估系统
    补充上下文: 手动添加工单未包含的信息
  降级策略:
    高风险场景: 必须人工确认后才能发送
    AI 无响应: 自动切回纯人工模式
    多轮不稳定: 超过 5 轮提示转接高级客服

工作流嵌入测试:
  当前流程: 客服读工单 → 查订单系统 → 查物流系统 → 翻售后政策 → 组织回复 → 发送
  新流程: AI 预读工单+查询+召回规则 → 生成建议回复 → 客服确认/编辑 → 发送
  测试结果:
    首响时间: 从 3.2 分钟缩短到 1.1 分钟（-66%）
    采纳率: 67%（订单查询 85%，物流 72%，售后 45%）
    满意度: 82 分
    风险标记准确率: 88%

产品形态决策:
  最终形态: Copilot（侧边栏建议 + 人工确认模式）
  交互方案: 候选回复 + 风险标记 + 规则引用 + 一键采纳
  工作流嵌入: AI 预处理 + 人工确认 + 自动发送
  风险边界:
    退款/赔付类: 必须人工确认
    政策解释类: 标记风险但不拦截
    查询类: 可直接采纳
  进入下一阶段条件:
    ✅ 采纳率 > 60%（已达成 67%）
    ✅ 风险标记准确率 > 85%（已达成 88%）
    ⏳ 售后政策准确率需提升至 85%+（当前 78%，需补充资料）
    ⏳ 多轮上下文稳定性需验证（当前不稳定）
```

## 示例二：智能运维告警分析形态探索（对比案例）

### 用户输入
"运维告警分析能力实验已完成。单一故障根因识别准确率 85%，复合故障 62%，告警聚合 91%，误报识别 78%。需要探索产品形态。"

### Skill 执行

```yaml
能力边界分析:
  风险等级: 高（运维误判可能导致业务中断）
  边界清晰度:
    告警聚合: 高（模式明确，可自动化）
    单一故障根因: 中高（85% 准确率，大部分可自主）
    复合故障: 低（62%，需人工辅助判断）
    误报识别: 中（78%，需人工确认）
  任务重复度: 高（日均 200+ 告警，80% 为重复模式）
  用户期望: 快+准（运维既要快速响应，又不能误判）

候选形态评估:
  问答形态: ❌ 排除（运维需要嵌入告警流程）
  Copilot 形态: ⚠️ 候选（适合复合故障等需人工场景）
  工作台形态: ✅ 最优（运维已有告警面板，嵌入分析能力最自然）
  自动流程: ⚠️ 候选（适合告警聚合和误报过滤等低风险场景）
  Agent 形态: ❌ 排除（复合故障不稳定，不适合自主执行）

交互原型设计（工作台 + 局部自动流程）:
  入口设计:
    告警聚合: 自动流程（低风险，全自动）
    单一故障: 工作台自动展示根因分析面板
    复合故障: Copilot 模式（建议+人工确认）
    误报: 自动标记+人工审核
  展示形式:
    告警面板: 聚合后的告警分组 + 优先级排序
    根因面板: 疑似根因列表 + 置信度 + 关联日志引用
    处理建议: 推荐操作步骤 + 预期影响
    误报标记: ⚠️ 疑似误报（附判断依据）
  反馈机制:
    确认根因: 标记为已验证
    标记不准确: 反馈到评估系统
    补充信息: 手动添加系统未采集的上下文
    手动升级: 触发复合故障 Copilot 模式
  降级策略:
    复合故障: 自动降级为 Copilot 模式
    置信度 < 60%: 提示"建议人工排查"
    连续 3 次误判: 暂停该场景自动分析

工作流嵌入测试:
  当前流程: 告警触发 → 运维查看 → 手动查日志 → 人工判断根因 → 执行修复
  新流程:
    低风险: 告警聚合（自动）→ 误报过滤（自动+审核）→ 已知故障自动匹配
    中风险: 根因分析面板（自动展示）→ 运维确认 → 建议操作
    高风险: 复合故障 Copilot → 运维判断 → 手动执行
  测试结果:
    MTTR 缩短: 从 45 分钟到 28 分钟（-38%）
    告警聚合采纳率: 92%
    根因分析采纳率: 68%
    误报过滤采纳率: 74%

产品形态决策:
  最终形态: 混合形态
    告警聚合+误报过滤: 自动流程（低风险，全自动）
    单一故障根因: 工作台嵌入（自动展示，人工确认）
    复合故障: Copilot（建议+人工判断）
  工作流嵌入: 分层嵌入，按风险等级选择自动化程度
  风险边界:
    告警聚合: 全自动（可回滚）
    单一故障: 自动分析+人工确认操作
    复合故障: 仅建议，人工决策
    误报: 自动标记+批量人工审核
  进入下一阶段条件:
    ✅ 告警聚合采纳率 > 90%（已达成 92%）
    ✅ 单一根因准确率 > 80%（已达成 85%）
    ⏳ 复合故障准确率需提升至 75%+（当前 62%）
    ⏳ 误报识别准确率需提升至 85%+（当前 78%）
```