| name | product-multi-role-analysis |
| description | 输入某个产品的文档、URL 或简要描述，自动抓取关键信息，分别扮演「用户、投资人、产品经理、市场运营、品牌运营、友商、合作伙伴」7 个角色对该产品进行深度分析，中间结果分角色保存，最终整合为一篇图文并茂（SVG/Mermaid/ASCII）的综合分析报告，结论明确、有权威数据支撑、逻辑清晰、小白可读，并附有结论边界、前提假设及假设变动时的结论调整说明。
触发条件：用户提到"产品分析"、"多角色分析"、"7个角色"、"投资人视角"、"用户视角"、"产品竞争分析"、"全面分析这个产品"、"帮我分析一下 XX 产品"、"从多个角度看这个产品"、"product analysis"、"multi-role analysis"，或提供产品文档/链接并希望获得深度产品分析报告时，必须使用本 skill。即使用户只说"帮我全面分析一下这个产品"，也应立即使用本 skill。
|
Product Multi-Role Analysis Skill
总览
本 Skill 对任意产品进行「7 角色全景分析」，最终输出一份可直接发布或用于决策的综合报告。
7 个分析角色：
- 👤 用户 — 真实使用体验、痛点满足、愿意付费的理由
- 💰 投资人 — 市场规模、商业模式、增长曲线、退出路径
- 🛠 产品经理 — 核心功能、产品架构、roadmap 合理性、技术壁垒
- 📣 市场运营 — 获客渠道、增长策略、转化漏斗、ROI
- 🎨 品牌运营 — 品牌定位、视觉/语言一致性、用户心智占位
- ⚔️ 友商 — 差异化威胁、可抄功能、对方弱点在哪
- 🤝 合作伙伴 — 合作切入点、互补价值、潜在风险
执行流程
Phase 0 — 信息抓取与整理
输入来源（按优先级）：
- 用户提供的产品 URL → 使用
web_fetch 抓取官网/产品页
- 用户提供的文档（PDF/Word/Markdown）→ 读取内容
- 用户的文字描述 → 直接使用，并补充网络搜索
必须收集的信息维度：
产品名称、所属品类、目标用户、核心功能列表
定价策略、商业模式（SaaS/交易/广告/订阅等）
融资历史（轮次/金额/投资机构）
团队背景（创始人/核心成员）
主要竞品（至少3个）
用户评价（App Store/G2/Trustpilot/ProductHunt 等）
市场规模数据（TAM/SAM/SOM）
搜索策略：
- 搜索
[产品名] review site:g2.com OR site:producthunt.com
- 搜索
[产品名] funding crunchbase
- 搜索
[产品名] vs [主要竞品]
- 搜索
[所属品类] market size [当前年份]
将抓取结果整理为 00_raw_intel.md 保存到 markdown/ 目录。
Phase 1 — 7 角色独立分析（分文件保存）
每个角色的分析独立保存为单独的 Markdown 文件，命名规则：
markdown/01_user.md
markdown/02_investor.md
markdown/03_pm.md
markdown/04_growth.md
markdown/05_brand.md
markdown/06_competitor.md
markdown/07_partner.md
每个角色文件的标准结构，参见 references/role-templates.md。
分析深度要求：
- 每个角色视角至少 800 字
- 必须引用 Phase 0 中收集到的真实数据（不得凭空捏造数字）
- 每个角色有 1 个核心结论句（便于后续整合）
- 每个角色标注「该结论成立的前提假设」
Phase 2 — 综合报告整合
将 7 个角色文件整合为最终报告 markdown/[产品名]-analysis-report.md。
报告结构详见 references/report-structure.md。
图表生成规则：
- SVG 图表 → 单独保存为
markdown/assets/[图表名].svg，在报告中用相对路径引用
- Mermaid 图表 → 直接嵌入报告的代码块
- ASCII 图表 → 直接嵌入，用于简单对比表格
必须包含的图表（至少 4 张）：
- 产品竞争力雷达图（SVG）
- 商业模式 / 收入结构图（Mermaid flowchart 或 SVG）
- 用户旅程地图（Mermaid or ASCII）
- 市场定位矩阵（SVG 四象限）
可选图表（根据产品类型选择）：
- 增长漏斗图
- 产品功能对比矩阵（竞品 vs 本品）
- 融资时间线
Phase 3 — 结论边界与假设体系
这是本 Skill 区别于普通产品分析的核心价值。报告末尾必须包含：
3.1 结论适用边界
本报告结论在以下条件下成立：
- 时间范围：[分析时间] ±12 个月内
- 地理范围：[主要市场，如：中国大陆 / 北美 / 全球]
- 竞争格局：[当前竞品格局未发生颠覆性变化]
- 宏观环境：[利率/监管/技术范式 未发生根本性转变]
3.2 关键前提假设（KPA）
列出 3-5 个支撑核心结论的关键假设，格式：
KPA-1: [假设内容]
观测指标: [用什么数据可以验证/证伪]
验证周期: [多长时间可以看出端倪]
KPA-2: ...
3.3 假设变动时的结论调整
用「如果…那么…」的条件句清晰表达：
如果 KPA-1 不成立（[具体情形]）→ 结论调整为：[修订结论]
如果 KPA-2 不成立（[具体情形]）→ 结论调整为：[修订结论]
Phase 4 — 文件整理与输出
markdown/
├── 00_raw_intel.md # 原始情报汇总
├── 01_user.md # 用户视角分析
├── 02_investor.md # 投资人视角分析
├── 03_pm.md # 产品经理视角分析
├── 04_growth.md # 市场运营视角分析
├── 05_brand.md # 品牌运营视角分析
├── 06_competitor.md # 友商视角分析
├── 07_partner.md # 合作伙伴视角分析
├── assets/
│ ├── radar.svg # 竞争力雷达图
│ ├── market-matrix.svg # 市场定位矩阵
│ └── [其他SVG图表]
└── [产品名]-analysis-report.md # 最终综合报告
使用 present_files 工具呈现最终报告和关键中间文件。
质量检查清单
完成后对照检查：
注意事项
- 数据真实性优先：若找不到真实数据，明确标注「数据缺失，以行业均值估算」，禁止伪造权威引用。
- 角色立场要鲜明：每个角色视角要有真实的利益偏向，不能千篇一律说好话。友商视角必须写出威胁和攻击方向。
- 图表要有信息量：不要为图而图，每张图必须传递文字难以表达的洞察。
- 结论要有勇气：避免「可能」「也许」「或许」的模糊表达，结论要明确，不确定性用「假设体系」来承接。
- 项目目录：优先使用当前项目的
markdown/ 目录；若不存在，创建 /home/claude/markdown/ 并使用。
参考文件索引
references/role-templates.md — 7 个角色的详细分析模板references/report-structure.md — 综合报告的完整章节结构references/chart-guide.md — SVG/Mermaid/ASCII 图表制作规范
