---
name: 产品反馈处理
description: 处理用户或AI使用产品后提出的改进建议（完善，不是Bug）。将建议评估后路由到产品定义或存档。当用户说"我有个改进想法"、"产品可以改进一下"、"增加这个功能"、"优化这个体验"时触发。
---

# 产品反馈处理 Skill

## 与「规范审核迭代」的区别

| | 产品反馈处理（本 Skill）| 规范审核迭代 |
|---|---|---|
| 来源 | 用户/AI 使用产品后的主观感受 | 审核AI系统性对比实现与规范 |
| 类型 | 产品进化需求（完善）| 实现与规范的差距（修复）|
| 修改对象 | 产品定义.md + 开发计划.md | 开发规范.md |
| 起点 | 产品经理角色 | 审核者角色 |

---

## 执行流程

### 第一步：扮演产品经理角色

```
读 产品经理/产品定义.md → 理解当前产品是什么
```

### 第二步：用 4 个问题评估建议

**① 马斯洛定位**
这个改进满足的是哪层需求的新瓶颈？
- 旧瓶颈（AI会自动解决）→ **拒绝**
- 新瓶颈（AI越强越需要）→ 继续

**② AI放大原则**
AI能力再强10倍，这个改进的价值变大还是消失？
- 消失 → **拒绝**
- 变大 → 继续

**③ 闭环连续性**
与现有用户流/闭环自然衔接，还是孤立的？
- 孤立，找不到连接点 → **暂缓**（记录，等时机）
- 衔接现有闭环 → 继续

**④ 成本判断**
开发成本 vs 用户价值合理吗（快速主观判断）？
- 明显不合理 → **降优先级**
- 合理 → **通过**

### 第三步：写入反馈收集表

```
在 产品定义.md 的「第九节 产品反馈与改进建议 9.2 表」追加一行：
| F-XX | [来源] | [日期] | [建议内容一句话] | 通过/拒绝/暂缓 | [处理方式] |
```

### 第四步（通过时）：更新产品和开发计划

```
1. 在产品定义.md 的相关章节更新（用户流/功能描述/MVP边界）
2. 在 开发计划.md 追加新的 ⏳ 小闭环条目
3. 在反馈表里标注「已转入开发计划 小闭环X.X」
4. 在 产品经理/产品问题追踪台.md 追加一条提醒条目：
   | PD-XXX | [日期] | 来自产品反馈：[建议一句话] | 建议已通过，待纳入下轮开发 | [功能模块] | P2 | 未解决 | 已转入开发计划 小闭环X.X |
   → 目的：确保 PM 下次激活时能从追踪台看到这个待处理项，而不需要记住去翻产品定义第九节
```

### 第四步（拒绝时）：存档

```
在 产品定义.md 的「9.4 拒绝存档表」追加一行，写明拒绝理由
（拒绝不等于永远不做，可以在未来重新评估）
```

---

## 不同来源的反馈怎么处理

| 来源 | 特点 | 处理建议 |
|---|---|---|
| 用户主动提出 | 真实感受，可能缺乏系统性 | 直接进入评估 |
| AI审计发现 | 系统性，可能包含多条 | 逐条评估 |
| 数据分析师 | 基于行为数据 | 优先级高，快速通过 |
| 产品经理自己发现 | 使用时的直接感受 | 直接进入评估 |

---

## 在 ai-org-builder 中的自动化实现（未来）

```
用户在主对话界面提出改进建议
    ↓
协调者识别为「产品反馈」类型
    ↓
路由给「产品经理」智能体角色
    ↓
产品经理角色执行本 Skill 的评估流程
    ↓
通过 → 更新产品定义.md + 开发计划.md → 下一轮冲刺
拒绝 → 存档，并向用户解释原因
```

---

## 相关文档

- [产品定义.md](../../产品经理/产品定义.md) — 修改目标（第九节）
- [开发计划.md](../../产品经理/开发计划.md) — 追加新任务
- [规范迭代审核 Skill](../规范迭代审核/SKILL.md) — 另一种迭代循环

---

## 变更记录

### 2026-03-19 02:10 — 断点5修复：产品反馈通过时写入产品追踪台提醒

**根因**：反馈通过后只写入产品定义第九节，PM 激活时不会主动扫描第九节，待处理项可能被遗漏。

**修改内容**：
- 修改：「第四步（通过时）」→ 新增第4步，在产品问题追踪台写入一条「待纳入下轮开发」的提醒条目

**验证结果**：
- 正向验证：产品反馈通过后，产品问题追踪台应有新条目
- 负向验证：拒绝/暂缓路径不变