| name | product-evolution-planner |
| description | 主动式产品演进规划 Skill。基于「AI时代产品问题全景框架」等设计原则，主动分析当前产品现状，识别原则缺口，生成有理据的改进建议。与 role-产品经理 的区别：后者执行具体设计任务；本 Skill 是「对照原则做战略诊断，主动思考产品应该怎么演进」。触发词：「基于产品原则看看有什么可以改进的」「帮我看看产品还缺什么」「给我一些迭代建议」「从第一性原理看这个产品」「主动分析产品」「这个产品符合马斯洛新瓶颈吗」「产品演进建议」。 |
主动式产品演进规划（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）
