p2c-process-redesign

---
name: p2c-process-redesign
description: 'AI Native 产品方法论——流程重构与任务设计的实操 Skill。

  用户提供产品形态建议，Skill 自动执行流程重构设计：

  任务拆解 → 人机协作模式选择 → 工作流设计 → 节点标注 → 验证与迭代 → 输出流程重构方案。

  基于《AI Native 产品方法论》第08章（试验展开-流程重构与任务设计）。

  '
tags:
- ai-product
- methodology
- workflow-design
- human-ai-collaboration
- task-design
- book-skill
author: Max
source_book: AI Native 产品方法论
source_chapter: 第08章 试验展开-流程重构与任务设计
version: 1.0
stage: p2c
homepage: https://github.com/gmaxxxie/ai-native-product-agent-skills/tree/main/skills/p2c-process-redesign
---

# 流程重构与任务设计 Skill

## 使用场景

- 产品形态已确定，需要具体设计 AI 如何嵌入工作流程
- 需要在"完全自动"和"纯人工"之间找到正确的协作边界
- 需要把高重复、高信息密度的子任务分配给 AI，把高责任、高例外的部分留给人类

## 核心概念

- **工作流设计**：围绕任务完成，而非围绕页面跳转来设计产品
- **助手模式（Assistant Mode）**：AI 提供建议，人保留主要判断权
- **协同模式（Copilot Mode）**：AI 与人协同推进任务，人持续修正与确认
- **自主模式（Autonomous Mode）**：AI 在明确边界内自动执行，但仍需治理与回退机制
- **人在回路中（Human-in-the-Loop）**：AI 持续推进任务，关键节点由人确认
- **人在监督中（Human-on-the-Loop）**：AI 在边界内持续运行，人负责监控、干预、叫停和回滚

## 人机协作模式选择

| 场景特征 | 推荐模式 | 说明 |
|---------|---------|------|
| 高风险、不可逆 | 人在回路中 | 每个关键动作需人确认 |
| 中风险、可监控 | 人在监督中 | AI 执行，人监控，可随时干预 |
| 低风险、边界清晰 | 自主模式 | AI 在规则内自动执行 |
| 高频率、低价值 | 批量自动化 | 定时批量处理，无需实时监控 |

## 流程重构四步法

### 第一步：任务拆解

把完整任务拆解为原子子任务：

```
完整任务
  → 子任务1（高重复、AI可做）→ 自动化
  → 子任务2（中风险、AI辅助）→ Copilot
  → 子任务3（高责任、人为主）→ 人工
  → 子任务4（边界不清、待验证）→ 实验
```

### 第二步：分配人机职责

| 子任务 | 模式 | 判断理由 |
|--------|------|---------|
| 信息召回 | AI 自主 | 高频、标准化、无风险 |
| 规则解释 | AI 辅助（Copilot） | 中等风险，需人确认 |
| 风险判断 | 人在回路中 | 高风险、不可逆 |
| 客户沟通 | 人工 | 高同理心需求 |

### 第三步：节点标注

在流程图上标注关键节点：

- 🔴 **决策节点**：需要人工判断或确认
- 🟡 **AI 辅助节点**：AI 提供建议，人最终决定
- 🟢 **AI 执行节点**：AI 自动处理，无需干预
- ⚫ **回退节点**：异常情况回退到人工

### 第四步：验证与迭代

在真实工作流中测试：

1. 记录每个节点的通过率和人工介入频率
2. 识别流程瓶颈（AI 处理慢、还是人工确认多）
3. 调整节点模式（哪些可以自动化，哪些需要收紧）
4. 迭代优化

## 输出物：流程重构方案

1. **任务拆解图**：完整任务的原子化拆解
2. **人机协作矩阵**：每个子任务对应的人机模式
3. **流程节点图**：含节点标注的完整工作流
4. **回退机制**：每个节点的降级策略
5. **验证计划**：如何验证流程重构的有效性

## 与其他 Skill 的关系

- **前置**：@p2b-product-form-exploration（确定产品形态）
- **后置**：@p2d-convergence-decision（收敛决策）、@p2e-shadow-validation（影子验证）
- **协同**：@ai-native-agent-skill-design（Agent 形态设计）、@ai-native-ux-design（交互细节）

## 示例

### 用户输入
"客服 Copilot 已确定 Copilot 形态，需要设计具体工作流程"

### Skill 执行

```yaml
任务拆解（客服工单处理）:
  1. 读取工单信息 → AI自主 ✅
  2. 查询订单状态 → AI自主 ✅
  3. 召回相关规则 → AI辅助（Copilot）🔶
  4. 生成回复建议 → AI辅助🔶
  5. 风险标记 → AI辅助🔶
  6. 客服确认 → 人工 ✅
  7. 发送回复 → 人工 ✅
  8. 异常升级 → 人工+AI协助 ⚠️

人机协作矩阵:
  | 子任务 | 模式 | 边界 |
  |--------|------|------|
  | 信息读取 | AI自主 | 无需边界 |
  | 规则召回 | Copilot | 高置信度自动推荐 |
  | 回复生成 | Copilot | 涉及退款需人工 |
  | 风险标记 | AI辅助 | 标记但不拦截 |
  | 人工确认 | 人在回路 | 所有高风险项必须确认 |

回退机制:
  - AI无响应 → 自动转纯人工流程
  - 风险标记>2项 → 强制人工审核
  - 会话超过5轮 → 提示转接人工
  - 情绪检测异常 → 直接转人工

验证计划:
  - 影子验证2周，记录各节点人工介入率
  - 目标：信息读取自主率>95%，人工确认集中在风险节点
```

---

## 深入核心概念

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

- **AI 改变的是流程而非单个功能**：最容易犯的错误是只给现有系统加一个"智能入口"，却不重构背后的业务流程。AI 的真正价值来自流程重排——例如客服场景中，AI 不只是替代一句回复，而是可以提前理解问题、查询订单、生成候选答复、标记风险。
- **AI Native 工作流基本结构**：传统流程是 Human → System → Human；AI Native 流程更常见的是 Human → AI → System → AI → Human。AI 可以位于流程前端（理解意图）、中段（信息组织与任务分解）和末端（总结与复盘）。
- **三种控制结构**：人在定义中（Human-in-Definition，人定义方向和边界，AI 展开候选路径）、人在回路中（Human-in-the-Loop，AI 推进任务，关键节点人确认）、人在监督中（Human-on-the-Loop，AI 在边界内持续运行，人负责监控和回滚）。三种模式常出现在同一产品的不同节点里。
- **分工原则**：AI 适合高重复、高信息密度、大量候选生成、快速比较和持续执行；人适合方向定义、边界设置、关键确认、例外处理、责任承担和最终放行。流程重构的重点不是"把人拿掉"，而是把人从重复劳动里抽离，放回判断和责任的位置。
- **工作流设计是桥梁**：工作流设计是试验展开和系统构建之间的重要桥梁。很多能力单看实验不错，但进入流程后暴露出上下文不足、责任边界不清、异常处理缺失等问题。

## 分步执行指南

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

### 步骤 1：任务拆解与原子化
- 把完整任务拆解为原子子任务
- 每个子任务标注特征：重复度、风险等级、信息密度、例外频率
- 区分哪些子任务可以交给 AI，哪些必须保留人工
- 输出任务拆解图

### 步骤 2：人机协作模式分配
- 对每个子任务选择模式：AI 自主（高频标准化无风险）、Copilot（中等风险需人确认）、人在回路中（高风险不可逆）、人工（高同理心需求）
- 注意：不是追求"越自动越好"，而是判断哪段流程适合交给 AI，哪段必须保留人为确认
- 输出人机协作矩阵

### 步骤 3：流程节点设计与标注
- 在流程图上标注关键节点：🔴 决策节点（需人工判断）、🟡 AI 辅助节点（AI 建议人决定）、🟢 AI 执行节点（自动处理）、⚫ 回退节点（异常回退到人工）
- 设计每个节点的输入、输出、上下文需求和系统权限
- 明确失败后谁接管、如何回退、是否保留人工确认

### 步骤 4：回退机制与降级策略设计
- 为每个节点设计降级策略：AI 无响应 → 转纯人工；风险标记过多 → 强制人工审核；会话超限 → 提示转接；情绪异常 → 直接转人工
- 设计熔断机制：连续 N 次异常自动暂停
- 确保回退路径始终可用

### 步骤 5：最小检查表验证
- 回答五个关键问题：AI 承担的是助手/协同执行者/受限代理？哪个节点由 AI 触发/人触发？AI 需要哪些上下文和权限？失败后谁接管如何回退？哪些输出可直接使用/必须确认？
- 只有这五个问题被回答清楚，流程设计才不是概念图，而是真正可被工程化的工作链

### 步骤 6：真实工作流验证与迭代
- 在真实工作流中测试完整流程
- 记录每个节点的通过率和人工介入频率
- 识别流程瓶颈（AI 处理慢 vs 人工确认多）
- 调整节点模式（哪些可以自动化，哪些需要收紧）
- 输出流程重构方案文档

## 示例一：客服工单处理流程重构

### 用户输入
"客服 Copilot 已确定 Copilot 形态，需要设计具体工作流程。当前流程是客服读工单、查订单、查物流、翻政策、组织回复、发送。"

### Skill 执行

```yaml
任务拆解（客服工单处理）:
  1. 读取工单信息
    特征: 高重复、无风险、标准化
    模式: AI 自主 ✅
  2. 查询订单状态
    特征: 高重复、无风险、系统调用
    模式: AI 自主 ✅
  3. 查询物流状态
    特征: 高重复、无风险、系统调用
    模式: AI 自主 ✅
  4. 召回相关规则
    特征: 中等风险、需匹配准确性
    模式: AI 辅助（Copilot）🔶
  5. 生成回复建议
    特征: 中等风险、需上下文理解
    模式: AI 辅助（Copilot）🔶
  6. 风险标记
    特征: 高重要性、不能漏过
    模式: AI 辅助（标记但不拦截）🔶
  7. 客服确认与编辑
    特征: 高责任、需判断力
    模式: 人在回路中 🔴
  8. 发送回复
    特征: 不可逆、需最终确认
    模式: 人工 ✅
  9. 异常升级
    特征: 高复杂度、需同理心
    模式: 人工 + AI 协助 ⚠️

人机协作矩阵:
  | 子任务 | 模式 | 边界 | 上下文需求 |
  |--------|------|------|-----------|
  | 工单读取 | AI 自主 | 无 | 工单内容 |
  | 订单查询 | AI 自主 | 无 | 订单号 |
  | 物流查询 | AI 自主 | 无 | 物流单号 |
  | 规则召回 | Copilot | 高置信度自动推荐，低置信度标记 | 工单类型+客户历史 |
  | 回复生成 | Copilot | 查询类可直接生成，退款类需标记 | 全部上下文 |
  | 风险标记 | AI 辅助 | 标记但不拦截（人工做最终判断） | 风险规则库 |
  | 人工确认 | 人在回路 | 所有高风险项必须确认 | AI 生成的全部建议 |
  | 发送回复 | 人工 | 最终不可逆动作 | 确认后的内容 |
  | 异常升级 | 人工+AI | AI 提供摘要，人工做判断 | 会话全程记录 |

流程节点图:
  🟢 工单进入 → 🟢 AI 读取工单 → 🟢 AI 查询订单/物流
  → 🟡 AI 召回规则+生成回复 → 🟡 AI 风险标记
  → 🔴 客服确认/编辑 → 🔴 发送回复
  → ⚫ 异常时: 转人工升级

回退机制:
  - AI 无响应（> 5秒）→ 自动切回纯人工流程
  - 风险标记 > 2 项 → 强制人工逐项审核
  - 会话超过 5 轮未解决 → 提示转接高级客服
  - 情绪检测异常（愤怒/投诉倾向）→ 直接转人工
  - 连续 3 次 AI 建议被标记不准确 → 暂停该场景 AI 辅助

最小检查表验证:
  ✅ AI 承担角色: 协同执行者（Copilot）
  ✅ 触发节点: 工单进入由系统触发，确认由人触发
  ✅ AI 所需上下文: 工单内容、订单状态、物流状态、规则库、客户历史
  ✅ 失败接管: 纯人工流程（降级路径已设计）
  ✅ 输出处理: 查询类可直接使用，回复类必须人工确认

验证计划:
  - 影子验证 2 周，记录各节点人工介入率
  - 目标: 信息读取自主率 > 95%，人工确认集中在风险节点
  - 迭代: 根据影子验证结果调整哪些节点可以提升自动化程度
```

## 示例二：智能运维告警处理流程重构（对比案例）

### 用户输入
"运维告警分析已确定混合形态（自动流程+工作台+Copilot），需要设计具体工作流程。当前流程是告警触发、运维查看、手动查日志、人工判断、执行修复。"

### Skill 执行

```yaml
任务拆解（运维告警处理）:
  1. 告警接收与分类
    特征: 高重复、无风险、模式明确
    模式: AI 自主 ✅
  2. 告警聚合（去重+分组）
    特征: 高重复、低风险、模式明确
    模式: AI 自主 ✅
  3. 误报识别
    特征: 中风险、需一定判断
    模式: AI 辅助（自动标记+人工批量审核）🔶
  4. 单一故障根因分析
    特征: 中高风险、需准确性
    模式: Copilot（AI 分析+人工确认）🔶
  5. 复合故障关联分析
    特征: 高风险、需经验判断
    模式: 人在回路中（AI 建议+人工判断）🔴
  6. 处理建议生成
    特征: 中风险、需上下文
    模式: Copilot 🔶
  7. 执行修复操作
    特征: 不可逆、高风险
    模式: 人在回路中（人工确认后执行）🔴
  8. 修复验证
    特征: 需系统确认
    模式: AI 自主（自动检测）+ 人工确认 ✅🔴
  9. 复盘与知识沉淀
    特征: 低风险、高价值
    模式: AI 辅助（自动生成复盘草稿）🔶

人机协作矩阵:
  | 子任务 | 模式 | 边界 | 上下文需求 |
  |--------|------|------|-----------|
  | 告警接收 | AI 自主 | 无 | 告警源+时间戳 |
  | 告警聚合 | AI 自主 | 无 | 历史告警模式 |
  | 误报识别 | AI+审核 | 标记疑似误报，人工批量确认 | 历史误报模式 |
  | 单一根因 | Copilot | Top-3 候选+置信度，人工选择 | 告警上下文+日志+架构 |
  | 复合故障 | 人在回路 | AI 提供关联分析，人工做最终判断 | 跨系统日志+拓扑 |
  | 处理建议 | Copilot | 已知故障自动匹配，未知故障人工确认 | 知识库+历史处理记录 |
  | 执行修复 | 人在回路 | 人工确认后执行，AI 预检影响范围 | 变更管理系统 |
  | 修复验证 | AI+确认 | AI 自动检测恢复，人工最终确认 | 监控指标 |
  | 复盘沉淀 | AI 辅助 | AI 生成草稿，人工审核入库 | 全程处理记录 |

流程节点图（分层）:
  低风险路径:
    🟢 告警进入 → 🟢 AI 分类+聚合 → 🟢 AI 误报标记
    → 🟡 批量人工审核误报 → 🟢 已知故障自动匹配处理建议
  中风险路径:
    🟢 告警进入 → 🟡 AI 根因分析 → 🔴 运维确认根因
    → 🟡 AI 处理建议 → 🔴 运维确认+执行
  高风险路径:
    🟢 告警进入 → 🟡 AI 关联分析 → 🔴 运维判断
    → 🔴 人工制定方案 → 🔴 人工执行 → 🔴 验证确认

回退机制:
  - AI 根因分析置信度 < 60% → 提示"建议人工排查"，不展示自动结果
  - 连续 3 次根因判断被标记不准确 → 暂停该类型告警的 AI 分析
  - 复合故障自动降级为 Copilot 模式（仅建议不执行）
  - 修复操作影响范围 > 预设阈值 → 强制人工审批
  - AI 分析延迟 > 30秒 → 跳过 AI 直接人工处理

最小检查表验证:
  ✅ AI 承担角色: 低风险自主执行者，中风险协同执行者，高风险建议者
  ✅ 触发节点: 告警由系统触发，修复由人触发
  ✅ AI 所需上下文: 告警数据+日志+架构拓扑+历史处理记录+知识库
  ✅ 失败接管: 人工全流程处理（低风险也能秒级降级）
  ✅ 输出处理: 聚合和误报标记可自动使用，根因和修复必须人工确认

验证计划:
  - 影子验证 3 周（运维场景更保守）
  - 第 1 周: 仅低风险路径（告警聚合+误报标记）
  - 第 2 周: +中风险路径（单一根因分析）
  - 第 3 周: +高风险路径（复合故障 Copilot）
  - 目标: 告警聚合自主率 > 98%，根因分析采纳率 > 65%，人工确认集中在修复执行节点
```