TashanGKD 产品反馈处理 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步，在产品问题追踪台写入一条「待纳入下轮开发」的提醒条目
验证结果：
- 正向验证：产品反馈通过后，产品问题追踪台应有新条目
- 负向验证：拒绝/暂缓路径不变