Product evolution planner

主动式产品演进规划（product-evolution-planner）

核心定位：AI 不等待指令，主动对照原则思考「这个产品应该往哪里演进」。 强绑定 Rule：R2 NO_FABRICATION / R3 READ_FIRST / R1 EVIDENCE_FIRST / R6 ARTIFACT_FIRST

与其他 Skill 的区别：

• role-产品经理：执行具体的产品设计任务（闭环递进法、动线设计）

---

知识导航表（执行前必须理解的概念根）

层级	文档	需要理解的概念
D0 认知根（必读）	_内部总控/认知结构/L1_系统性文档/产品理论维度/AI时代产品问题全景框架.md	§五 产品构建五大原则；§六 五条判断原则；§七 马斯洛新瓶颈；§八 闭环递进法（产品演进的理论依据）
D3 规范参考	—	本 Skill 是战略诊断，不修改任何文档，无需规范参考
D4 运行时数据	各项目 产品定义.md + 开发计划.md	当前产品现状（被诊断的对象）

核心概念速查： ① 原则驱动 = 以L1产品理论为标准评估，不是凭感觉或竞品对标来建议改进 ② 战略诊断 ≠ 产品设计：本 Skill 只产出建议报告，不创建或修改产品文档 ③ 缺口 = 当前产品与产品原则之间的差距（证据必须引用具体章节）

• architecture-gap-mapper：对比两个已有系统/方案的差距
• product-evolution-planner：对照设计原则，主动诊断当前产品，生成战略级改进建议

---

激活后立即执行（顺序不可跳过）

Step 1  读取原则文档（R3 READ_FIRST：必须先读完再分析）
        用 explore 子智能体并行读取以下文档：
        
        【必读，不存在则中止】
        - _内部总控/产品定义/AI时代产品问题全景框架.md
          ⚠️ 该文档约1400行，必须读取以下核心章节（不允许只读摘要）：
          - 第三章：各马斯洛层的新瓶颈（一到五层）
          - 第五章：Human-Readable + Agent-Operable 双层设计原则
          - 第六章：五条判断原则（马斯洛定位/AI放大/需求质量/Taste/研发壁垒）
        - 当前项目的 产品经理/产品定义.md
        
        【可选，不存在则跳过，不报错】
        - _内部总控/产品定义/体系架构原则.md（未来会建立）
        - 当前项目的 技术架构师/技术架构.md
        
        若「必读」文档不存在：
        → 若产品原则文档不存在：中止并提示「_内部总控/产品定义/ 目录下未找到框架文档」
        → 若产品定义不存在：提示「当前项目没有产品定义，建议先运行 role-产品经理 完成定义，再做演进分析」

Step 2  从每条原则出发，对照当前产品做原则检验
        
        对照 AI时代产品问题全景框架 的核心原则（R1 EVIDENCE_FIRST：每条必须引用原则文档具体论断）：
        
        【原则一：马斯洛新瓶颈检验】
        → 这个产品服务的是哪一层的需求？
        → 它解决的是「AI时代的新瓶颈」，还是「旧瓶颈」（已被AI直接解决或即将解决的）？
        → 判据：AI越强，这个需求是更强烈还是消失？
        
        【原则二：AI放大检验】
        → AI能力再强10倍，这个产品的需求变大了还是消失了？
        → 若消失：本质是在填AI能力空缺，不是长期方向
        
        【原则三：Human-Readable + Agent-Operable 双层设计检验】
        → 人层：产品是否极简可读、体验先于功能？
        → 智能体层：所有功能是否有对应的API/接口，AI可以完整操作？
        → 有没有「只为人设计、AI无法操作」或「只有API、人不知道怎么用」的情况？
        
        【原则四：闭环完整性检验】
        → 主干用户动线是否有明确的入口和出口？
        → 有没有「用户走到一半找不到下一步」的断点？
        → 有没有功能「没有反馈分支」（不论用户做什么，系统反应一样）？
        
        【原则五：研发壁垒检验】
        → 6-12个月内，竞品是否可以完整复制这个产品？
        → 背后有没有持续生产新知识的研究方向？
        → 数据飞轮是否存在（越用越强）？
        
        【技术架构原则检验（若文档存在）】
        → 读取体系架构原则.md，逐条对照当前技术架构
        
        每项检验必须同时给出：
        - 当前产品的具体证据（引用产品定义中的具体描述）
        - 通过/部分通过/未通过的判断
        - 未通过时：具体体现在哪里

Step 3  生成原则缺口清单
        
        对每个「未通过」或「部分通过」的检验，生成一条缺口描述：
        
        格式：
        [优先级] 缺口：[一句话描述]
        原则依据：[引用框架文档的具体论断]
        当前产品的体现：[引用产品定义的具体描述]
        改进方向：[建议的方向，不是具体实现]
        类型：产品功能类 / 技术架构类

Step 4  优先级排序
        
        P0：违反核心原则（会让产品往错方向持续投入）
            → 对应：解决旧瓶颈 / AI越强需求消失 / 数据飞轮反转
        P1：明显改进机会（现有框架内可做，改了明显更好）
            → 对应：闭环有断点 / 双层设计缺失某一层 / 研发壁垒薄弱
        P2：中长期演进方向（需要新资源或新研究，当前不紧急）

Step 5  输出「产品演进建议报告」（R6 ARTIFACT_FIRST：必须写文件）
        
        写入：产品经理/产品演进建议_YYYYMMDD.md
        
        格式见下方「报告格式」

Step 6  路由询问
        
        「📊 产品演进分析完成。共发现 N 条改进建议（P0: N，P1: N，P2: N）。
        
          是否现在执行某项？
          - 产品功能类建议 → 加载 role-产品经理 继续设计
          - 技术架构类建议 → 加载 role-技术架构师 继续设计
          - [选择第几条执行] [先看报告，稍后决定]」
        
        若用户选择执行某条：
        → 将该条建议的完整内容（原则依据 + 当前问题 + 改进方向）作为上下文
        → 加载对应角色 Skill，将建议内容传入作为「本次任务背景」

---

报告格式

# 产品演进建议报告

**分析日期**：YYYY-MM-DD
**参照原则**：AI时代产品问题全景框架 v[版本] / 体系架构原则（若有）
**当前产品**：[产品名，从产品定义提取]

---

## 原则检验结果

| 原则 | 状态 | 关键发现 |
|---|---|---|
| 马斯洛新瓶颈 | ✅/⚠️/❌ | [一句话] |
| AI放大 | ✅/⚠️/❌ | [一句话] |
| 双层设计 | ✅/⚠️/❌ | [一句话] |
| 闭环完整性 | ✅/⚠️/❌ | [一句话] |
| 研发壁垒 | ✅/⚠️/❌ | [一句话] |

---

## P0 改进建议（核心方向性问题）

### P0-01 [建议标题]
**原则依据**：[引用框架文档具体论断]
**当前问题**：[引用产品定义具体描述]
**改进方向**：[方向性建议]
**类型**：产品功能类 / 技术架构类
**建议路由**：role-产品经理 / role-技术架构师

## P1 改进建议（明显改进机会）
[同上格式]

## P2 中长期演进方向
[同上格式]

---

## 结论
[一段话总结：产品目前在原则层面的核心优势和核心风险]

---

注意事项

• 禁止泛泛而谈：每条建议必须引用原则文档中的具体论断（章节 + 原话/概括），不允许「建议加社交功能」而不说原则来源
• 禁止直接执行：本 Skill 只输出建议，不修改任何产品定义。执行需要用户确认后路由到对应角色 Skill
• 接受不完整文档：产品定义不完整时仍可分析，但需在报告中说明「以下分析基于现有产品定义，部分结论可能因文档不完整而有偏差」
• 体系架构原则文档缺失时：跳过该检验维度，在报告末尾注明「体系架构原则文档未找到，该维度暂未分析」

---

变更记录

v1.0 — 2026-03-19 — 初始创建

根因：用户提出：AI 应该能基于产品设计原则主动分析产品演进方向，而不只是等待执行指令。当前所有角色类 Skill 都是反应式的，没有「主动战略诊断」能力。

经验核心：产品演进建议的可信度来自「每条建议都有原则文档的明确依据」——没有依据的建议只是 AI 的感觉，有依据的建议才能推动产品方向的讨论。

强绑定 Rule：R2（禁止捏造） / R3（先读后析） / R1（证据优先） / R6（输出工件）

验证状态：✅ 已验证（2026-03-19 tashan-openbrain首次真实执行：发现P0×2/P1×3/P2×2共7条改进建议，流程完整有效）

v1.1 — 2026-03-19 — 新增逆向场景处理说明（首次真实执行验证）

根因：首次真实执行发现「逆向场景」：项目已有大量开发但无产品定义文档时，Step 1 读不到产品定义，原流程只描述了正向（定义→分析）路径。

修改内容：若产品定义不存在，Step 1 应先建议「用 role-产品经理 补写产品定义」再做分析，而非跳过或报错。

验证状态：✅ 已验证（2026-03-19）