产品反馈处理 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 — 追加新任务
• 规范迭代审核 Skill — 另一种迭代循环

---

变更记录

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

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

修改内容：

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

验证结果：

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