{"id":"683332bf-540d-4509-9509-dc3c260ce1a3","entityType":"agent","slug":"clawhub-ebandao777-oss-product-management","name":"product-management","canonicalUrl":"https://www.xpersona.co/agent/clawhub-ebandao777-oss-product-management","canonicalPath":"/agent/clawhub-ebandao777-oss-product-management","generatedAt":"2026-10-10T11:52:49.097Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T09:28:29.232Z","emptyReason":null},"description":"产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。 PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano模型。 Skill: product-management Owner: ebandao777-oss Summary: 产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。 PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.5K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17en637qww2q9z3kz1ep6w79988dec4:product-management","sourceUrl":"https://clawhub.ai/ebandao777-oss/product-management","homepage":"https://clawhub.ai/ebandao777-oss/skills/product-management","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/ebandao777-oss/product-management","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/ebandao777-oss/skills/product-management","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":64,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。 PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T09:28:29.232Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T09:28:29.232Z","emptyReason":null},"stars":null,"forks":null,"downloads":1525,"packageName":null,"latestVersion":"0.1.0","tractionLabel":"1.5K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T09:28:29.227Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T09:28:29.232Z","lastCrawledAt":"2026-10-10T09:28:29.227Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T09:28:29.227Z","lastVerifiedAt":null,"highlights":[{"version":"0.1.0","createdAt":"2026-08-15T17:32:21.699Z","changelog":"Initial release of the product-management skill – a comprehensive toolkit for product management workflows. - Includes 8 key sub-skills: PRD generation, product brainstorming, metrics review, user feedback analysis, user story breakdown, competitive analysis, roadmap updates, and requirement prioritization. - Enforces step-by-step execution via reading detailed templates for each sub-skill, ensuring process rigor and output quality. - Aligns with the six-step closed-loop workflow standard, supporting analysis, solution development, execution, verification, delivery, and review. - Provides a flexible routing system for user requests with clear intent identification and collaboration guidelines between sub-skills. - Introduces structured multi-role collaboration (controller, analyst, producer, reviewer) and strict quality gates for final outputs.","fileCount":14,"zipByteSize":53310}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17en637qww2q9z3kz1ep6w79988dec4:product-management","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T11:52:49.095Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-ebandao777-oss-product-management/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T09:28:29.232Z","emptyReason":null},"readme":"Skill: product-management\n\nOwner: ebandao777-oss\n\nSummary: 产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。 PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano模型。\n\nTags: latest:0.1.0\n\nVersion history:\n\nv0.1.0 | 2026-08-15T17:32:21.699Z | auto\n\nInitial release of the product-management skill – a comprehensive toolkit for product management workflows.\n\n- Includes 8 key sub-skills: PRD generation, product brainstorming, metrics review, user feedback analysis, user story breakdown, competitive analysis, roadmap updates, and requirement prioritization.\n- Enforces step-by-step execution via reading detailed templates for each sub-skill, ensuring process rigor and output quality.\n- Aligns with the six-step closed-loop workflow standard, supporting analysis, solution development, execution, verification, delivery, and review.\n- Provides a flexible routing system for user requests with clear intent identification and collaboration guidelines between sub-skills.\n- Introduces structured multi-role collaboration (controller, analyst, producer, reviewer) and strict quality gates for final outputs.\n\nArchive index:\n\nArchive v0.1.0: 14 files, 53310 bytes\n\nFiles: .gitattributes (66b), README.md (1921b), references (0b), references/competitive-analysis.md (14519b), references/prd-generation.md (12454b), references/product-brainstorm.md (11333b), references/product-metrics-review.md (15636b), references/requirement-prioritization.md (12001b), references/roadmap-update.md (10521b), references/user-feedback-analysis.md (14800b), references/user-story-breakdown.md (9708b), skill-card.md (2928b), SKILL.md (10547b), _meta.json (137b)\n\nFile v0.1.0:SKILL.md\n\n---\nname: product-management\ndescription: |\n  产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。\n  PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano模型。\nversion: \"1.0.1\"\nauthor: \"智慧半岛\"\n---\n\n# product-management -- 产品管理综合技能\n\n本技能是一个综合技能套件，包含多个子技能。接到用户请求后，按以下流程执行。\n\n## 执行流程\n\n### Step 1: 意图识别与路由匹配\n\n分析用户输入，与下方路由表逐一比对。匹配规则：\n- 用户输入中包含路由表中「子技能」列的关键词 → 匹配该子技能\n- 用户输入中包含路由表中「功能说明」列中提到的场景 → 匹配该子技能\n- 多个子技能同时匹配时，选择匹配度最高的\n- 无法唯一确定时，向用户确认意图\n\n### Step 2: 加载子技能模板\n\n匹配到子技能后，根据子技能索引表找到对应的文件路径，**必须**使用 `read_text` 工具读取 `references/` 目录下的完整执行模板。\n\n### Step 3: 按模板执行\n\n严格按照加载的模板逐步执行。模板中定义了：\n- 输入要求（用户需要提供什么）\n- 执行步骤（每一步做什么、如何判断）\n- 输出格式（最终产出的结构和规范）\n- 质量标准（产出必须满足的底线）\n\n### Step 4: 输出结果\n\n按模板规定的格式输出结果。如果模板要求生成文件，写入后声明产出物。\n\n## 约束规则\n\n1. **必须先读模板再执行**：匹配到子技能后，严禁凭记忆或猜测执行，必须先读取对应的 references 文件\n2. **严格遵循模板**：不得跳过步骤、不得省略检查项、不得自行简化流程\n3. **输入不足时主动索取**：模板中标注「必填」的输入项缺失时，向用户索取\n4. **质量底线不妥协**：模板中的质量标准必须逐条满足\n\n## 本包特色\n\n- **方法论多样性**：需求优先级排序支持RICE/ICE/MoSCoW/Kano四种模型，根据输入数据特征自动推荐最优模型\n- **全链路协同**：PRD生成→竞品分析→用户故事拆解→路线图更新形成完整产品管理闭环\n- **数据驱动决策**：产品指标复盘、用户反馈分析两个子技能共同构成数据驱动产品迭代的基础设施\n\n## 路由表\n\n| 子技能 | 功能说明 |\n|--------|----------|\n| PRD生成 | 输入功能需求，生成含背景、目标、功能清单、交互设计的PRD文档。 |\n| 产品指标复盘 | 输入产品指标数据或时间周期，输出指标健康度评估、趋势分析、归因分析和行动建议。 |\n| 产品脑暴 | 围绕产品问题或机会点进行结构化创意发散，输出经过初步筛选的创意清单。 |\n| 用户反馈分析 | 上传用户反馈数据（Excel/CSV/文本），自动分类统计并提取高频模式... |\n| 用户故事拆解 | 从Epic或大需求中拆解出独立可交付的User Story... |\n| 竞品分析 | 输入竞品列表，输出功能对比矩阵、SWOT、五力分析和差异化策略。 |\n| 路线图更新 | 汇总迭代状态、评估里程碑进度、记录优先级变更... |\n| 需求优先级排序 | 输入需求列表，用RICE/ICE/MoSCoW/Kano模型辅助排序... |\n\n## 子技能索引\n\n| 子技能 | 英文标识 | 文件 |\n|--------|----------|------|\n| PRD生成 | `prd-generation` | [references/prd-generation.md](./references/prd-generation.md) |\n| 产品指标复盘 | `product-metrics-review` | [references/product-metrics-review.md](./references/product-metrics-review.md) |\n| 产品脑暴 | `product-brainstorm` | [references/product-brainstorm.md](./references/product-brainstorm.md) |\n| 用户反馈分析 | `user-feedback-analysis` | [references/user-feedback-analysis.md](./references/user-feedback-analysis.md) |\n| 用户故事拆解 | `user-story-breakdown` | [references/user-story-breakdown.md](./references/user-story-breakdown.md) |\n| 竞品分析 | `competitive-analysis` | [references/competitive-analysis.md](./references/competitive-analysis.md) |\n| 路线图更新 | `roadmap-update` | [references/roadmap-update.md](./references/roadmap-update.md) |\n| 需求优先级排序 | `requirement-prioritization` | [references/requirement-prioritization.md](./references/requirement-prioritization.md) |\n## 跨技能协同指引\n\n| 协同技能 | 典型场景 |\n|---------|---------|\n| 市场营销 | PRD通过后调用市场营销生成配套营销文案 |\n| 咨询交付 | PRD和竞品分析可作为咨询方案框架的输入 |\n\n> 以上为推荐协同路径。执行复合任务时，请根据实际需求灵活组合。\n\n## 六步闭环工作流对齐\n\n> 本章节使本技能包对齐「六步闭环工作流_融合数字员工体系.md」标准，实现分析→方案→执行→验证→交付→复盘的全流程闭环。\n\n### 一、六步闭环映射\n\n本技能原有四步流程（意图识别→加载模板→按模板执行→输出结果）映射到六步闭环：\n\n| 闭环步骤 | 对应本技能环节 | 具体动作 |\n|----------|--------------|---------|\n| 1. 分析指令 | Step 1: 意图识别与路由匹配 | 提取用户需求中的目标、范围、限制；标注不确定信息；判断子技能匹配度 |\n| 2. 制定方案 | Step 2: 加载子技能模板 | 根据子技能索引读取模板；确认输入要求、执行步骤、输出格式；定义验收口径 |\n| 3. 执行任务 | Step 3: 按模板执行 | 严格按模板逐步执行；记录关键步骤和偏差 |\n| 4. 验证结果 | Step 3 末尾 + 自查 | 对照模板质量标准逐条自检；未通过项返回修复 |\n| 5. 交付结果 | Step 4: 输出结果 | 按模板格式输出；附带验证结论；标注风险与建议 |\n| 6. 复盘沉淀 | （新增） | 将本轮 PRD/竞品分析中的修正经验固化为产品方法论 → 更新产品规范库与模板 → 形成可复用 Checklist |\n\n### 二、数字员工角色配置\n\n本技能包对应的角色分工如下：\n\n| 职能类型 | 角色名称 | 职责 |\n|----------|---------|------|\n| 中枢型 | 主控 | 调度子技能选择、判定交付质量、控制轮次节奏 |\n| 分析型 | 产品规划师 | 需求拆解、意图识别、子技能路由、PRD结构设计 |\n| 产出型 | 产品文案 | 实际执行模板、生成PRD/分析报告等产出物 |\n| 验收型 | 产品审核员 | 质量验证、逻辑一致性检查、模板符合性审查（连接Figma后扩展为设计规范一致性审核） |\n\n**角色间接口协议**：\n- 主控 → 分析角色：传递用户原始需求，指明约束条件\n- 分析角色 → 产出角色：传递匹配的子技能模板路径、输入要求和验收标准\n- 产出角色 → 验收角色：传递交付产物和自检结果\n- 验收角色 → 主控：传递验证结论（通过/需修复/已知限制）\n\n### 三、轮次控制与收敛规则\n\n| 参数 | 默认值 | 说明 |\n|------|--------|------|\n| 默认循环轮次 | 3 | 无复杂子任务时的标准轮次 |\n| 安全最大轮次 | 6 | 防无限迭代的硬上限 |\n| 每轮最大改动点数 | 3 | 单轮内子任务修改/优化上限 |\n| 失败熔断 | 同一问题2轮未解决即标记已知限制 | 防止反复尝试无效修复 |\n| 低收益检测 | 连续2轮仅做格式/措辞微调时建议结束 | 避免过度优化 |\n\n**收敛判定逻辑**：\n1. 子技能模板质量标准全部满足 → 正常结束\n2. 达到默认轮次且核心产出达标 → 默认结束\n3. 达到安全最大轮次 → 强制结束，输出未完成清单\n4. 连续2轮仅做P2级微调改动 → 建议提前结束\n\n### 四、验收标准\n\n每个子技能执行完毕后，必须对照以下检查项：\n\n| 检查维度 | 检查项 | 判定标准 | 适用子技能 |\n|----------|--------|---------|-----------|\n| 功能完整性 | 是否覆盖模板所有必填输出 | 全部必填项已产出 | 全部 |\n| 结构一致性 | 输出格式是否符合模板规范 | 章节/字段/表格与模板一致 | 全部 |\n| 规则符合性 | 是否违反约束规则 | 无越权、无跳过步骤 | 全部 |\n| 质量底线 | 是否满足模板质量标准 | 核心指标达标 | 全部 |\n| 逻辑一致性 | 结论是否有充分论据支撑、推论是否无跳跃 | 产品逻辑链条完整 | 全部 |\n| 可追溯性 | 结论是否有输入/数据支撑 | 引用来源可定位 | 全部 |\n| 数据准确性 | 引用的竞品数据/用户反馈数据是否可校验、指标口径是否一致 | 关键数据可复验、口径无歧义 | 产品指标复盘、用户反馈分析、竞品分析 |\n\n> 注：产品脑暴 侧重创意发散，不涉及数据校验，对应「数据准确性」维度自动跳过。\n\n### 五、模板化交付\n\n关键产出的标准模板由各子技能的 `references/` 文件定义。本技能包级别的通用交付格式：\n\n```markdown\n## 任务交付说明\n\n### 1. 子技能与路由\n- **匹配子技能**：（名称）\n- **路由依据**：（用户输入关键词/场景匹配）\n\n### 2. 执行摘要\n- **输入信息**：（用户提供的核心输入）\n- **执行过程**：（关键步骤简述）\n- **产出清单**：（交付物列表）\n\n### 3. 验证结论\n| 检查项 | 状态 | 备注 |\n|--------|:----:|------|\n| （逐条列出） | 通过/未通过 | （说明） |\n\n### 4. 风险与建议\n- **已知限制**：\n- **后续建议**：\n\n### 5. 复盘记录\n- **本次经验**：（可复用的处理模式/需注意的陷阱）\n```\n\n### 六、项目启动模板\n\n处理复杂复合任务时，启动前填写：\n\n```markdown\n## 任务启动信息\n- **任务目标**：（用户核心诉求，一句话描述）\n- **识别子技能**：（如有多个，列出优先级）\n- **输入完备性**：完备 / 缺失（列出缺失项）\n- **预期交付物**：\n- **验收条件**：\n- **预估轮次**：\n- **协同技能**：（如需跨包协作，列出）\n```\n\nFile v0.1.0:README.md\n\n# 产品管理 - product-management\n\n面向产品经理的全栈产品管理工具集。从PRD生成、用户故事拆解到竞品分析、路线图更新，覆盖产品全生命周期的核心工作流。\n\n## 子技能列表\n\n| 子技能 | 功能 | 触发关键词 |\n|--------|------|-----------|\n| PRD生成 | 输入功能需求，生成结构化PRD文档 | PRD生成, 写PRD, 需求文档, 功能规格 |\n| 产品指标复盘 | 输入产品指标数据，输出健康度评估和趋势分析 | 指标复盘, 数据复盘, DAU分析 |\n| 产品脑暴 | 围绕产品问题进行结构化创意发散 | 产品脑暴, 头脑风暴, brainstorm |\n| 用户反馈分析 | 上传用户反馈数据，自动分类统计提取高频模式 | 用户反馈分析, 用户反馈, 用户声音 |\n| 用户故事拆解 | 从Epic拆解出独立可交付的User Story | 用户故事拆解, 用户故事, story拆分 |\n| 竞品分析 | 输入竞品列表，输出功能对比和SWOT分析 | 竞品分析, 竞品调研, 竞品跟踪 |\n| 路线图更新 | 汇总迭代状态，评估里程碑进度 | 路线图更新, roadmap, 版本规划 |\n| 需求优先级排序 | 用RICE/ICE/MoSCoW/Kano模型辅助排序 | 需求排序, 需求优先级, RICE |\n\n## 使用方法\n\n通过 Marvis 对话自然触发，说出需求即可自动匹配对应子技能。\n\n## 协同技能\n\n- 市场营销：PRD通过后调用市场营销生成配套营销文案\n- 咨询交付：PRD方法论和用户研究支持咨询项目的需求分析阶段\n\n## 版本\n\nv1.0.0 | 更新日期: 2026-06-19\n\n## 变更日志\n\n### v1.0.1 (2026-06-19)\n- 对齐 description 子技能名与路由表名称\n- 压缩路由表说明列至40字以内\n- 新增跨技能协同指引章节\n- 删除冗余英文 description 行\n\n## 文件结构\n\n- `SKILL.md` - 技能运行时指令\n- `README.md` - 本文件，用户入口文档\n- `references/` - 子技能详细模板（共8个子技能）\n\nFile v0.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7096hdmqr56bh0825xpz8ft188dh24\",\n  \"slug\": \"product-management\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1786815141699\n}\n\nFile v0.1.0:references/competitive-analysis.md\n\n# 竞品分析\n\n对竞品产品进行系统化多维度分析，输出功能对比矩阵和差异化策略。内置 Porter 五力、SWOT 交叉策略、竞品定位对比和战略推演等方法论，按分析目的走不同深度和侧重的模板。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | 竞品报告写入 Notion 页面，构建竞品知识库 |\n| **Figma** | 引用竞品UI截图和交互流程对比素材 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 竞品列表 | 是 | 2-5个竞品名称（超过5个建议分批） |\n| 我方产品 | 否 | 自身产品信息，用于对比定位 |\n| 分析目的 | 否 | 产品设计/融资BP/战略规划/年度汇报，默认\"产品设计\" |\n| 分析维度 | 否 | 功能/定价/用户体验/技术架构/商业模式，默认\"功能+定价\" |\n\n> **信息完整度判断**：仅提供竞品名称 → 输出标准功能对比矩阵；提供分析目的 → 按目的走差异化模板。\n\n## 执行流程\n\n### 第一步：确定分析目的与深度\n\n| 分析目的 | 侧重维度 | 输出重点 | 建议篇幅 |\n|---------|---------|---------|---------|\n| **产品设计** | 功能对比+交互体验 | 功能矩阵+差异化功能清单 | 中等（2-3页） |\n| **融资BP** | 市场格局+差异化壁垒 | 竞争格局图+壁垒分析 | 精简（1页） |\n| **战略规划** | 全维度深度分析 | SWOT+五力+定价+路线图 | 详细（5-8页） |\n| **年度汇报** | 市场份额变化+趋势 | 同比变化+趋势判断 | 中等（2-3页） |\n\n### 第二步：信息收集\n\n基于用户提供的信息和AI已有知识进行分析。若用户提供了竞品官网链接、截图、定价页等补充材料，优先使用。\n\n**标注信息时效性**：所有竞品信息标注数据来源和时效（如\"基于2025年Q1公开信息\"），提醒用户核实最新情况。\n\n**信息可信度分级**：\n\n| 可信度 | 来源类型 | 标注方式 |\n|--------|---------|---------|\n| **高** | 官网公开信息、定价页、官方公告 | 直接引用 |\n| **中** | 媒体报道、用户评论、行业报告 | 标注来源 |\n| **低** | 传言、推测、过期信息 | 标注[待核实] |\n\n**竞品信息收集清单**：\n\n| 维度 | 具体收集项 | 典型来源 |\n|------|----------|---------|\n| 基本面 | 成立时间、融资轮次、团队规模、用户量 | 官网、36kr、天眼查 |\n| 产品 | 核心功能列表、最近更新、功能路线图 | 官网、更新日志、官方博客 |\n| 定价 | 套餐类型、价格区间、免费版限制 | 定价页 |\n| 口碑 | 用户好评点、差评点、NPS | G2、知乎、应用商店评价 |\n| 策略 | 目标市场、获客渠道、合作伙伴 | 媒体报道、社交媒体 |\n\n### 第三步：Porter 五力分析\n\n从行业结构角度评估竞争环境：\n\n| 竞争力量 | 分析维度 | 评估要点 |\n|---------|---------|---------|\n| **供应商议价力** | 上游依赖度 | 关键技术/人才/资源的供给是否集中？切换成本高不高？ |\n| **买家议价力** | 下游客户力量 | 客户集中度如何？切换成本高不高？价格敏感度如何？ |\n| **新进入者威胁** | 进入壁垒 | 技术壁垒、资金壁垒、品牌壁垒、网络效应、政策准入 |\n| **替代品威胁** | 替代方案 | 用户当前的替代方案是什么？替代品的性价比如何？ |\n| **行业竞争强度** | 现有玩家博弈 | 竞争者数量、市场集中度、差异化程度、退出壁垒 |\n\n**五力评估输出**：\n- 每个力量评为：强/中/弱\n- 附一句话评估理由\n- 综合判断：行业整体吸引力（高/中/低）\n\n### 第四步：多维度对比分析\n\n**功能对比矩阵**（核心产出）：\n\n| 功能模块 | 子功能 | 我方 | 竞品A | 竞品B | 竞品C |\n|---------|--------|-----|------|------|------|\n| {模块1} | {子功能1} | ✅完善 | ✅完善 | ⚠️基础 | ❌无 |\n| | {子功能2} | ⚠️基础 | ✅完善 | ✅完善 | ⚠️基础 |\n\n标注方式：✅完善 / ⚠️基础（有但不完善）/ ❌无（缺失）/ 🔜规划中\n\n**竞品定位深度对比**：\n\n| 对比维度 | 对比方法 | 评分标准 |\n|---------|---------|---------|\n| **功能矩阵评分** | 按功能模块1-5分打分，加权汇总 | 5=行业标杆，3=及格，1=基本缺失 |\n| **用户体验对比** | 核心流程步骤数、学习成本、完成效率 | 对比关键路径的点击数和完成时间 |\n| **技术架构对比** | 架构模式、技术栈、性能指标、开放性 | API开放度、集成能力、扩展性 |\n\n**SWOT分析框架**（每个竞品）：\n\n| | 正面 | 负面 |\n|---|------|------|\n| **内部** | Strengths（核心优势） | Weaknesses（明显短板） |\n| **外部** | Opportunities（可利用的机会） | Threats（需警惕的威胁） |\n\n> 每个象限写2-3条，每条必须有事实支撑，不写\"团队很强\"\"技术先进\"等空话。\n\n**SWOT交叉策略矩阵**：\n\n| 策略类型 | 含义 | 行动方向 |\n|---------|------|---------|\n| **SO策略** | 用优势抓机会 | 发挥我方强项抢占市场窗口 |\n| **WO策略** | 补弱点抓机会 | 通过弥补短板来把握新机会 |\n| **ST策略** | 用优势防威胁 | 用我方壁垒抵御竞品攻击 |\n| **WT策略** | 补弱点防威胁 | 最需紧急应对的防守方向 |\n\n**定价策略对比**（如分析维度含定价）：\n\n| 对比项 | 我方 | 竞品A | 竞品B | 竞品C |\n|--------|-----|------|------|------|\n| 免费版能力 | {范围} | {范围} | {范围} | {范围} |\n| 入门版月费 | {价格} | {价格} | {价格} | {价格} |\n| 企业版月费 | {价格} | {价格} | {价格} | {价格} |\n| 计费模式 | {按人/按量/按功能} | | | |\n| 核心差异 | {定价策略解读} | | | |\n\n**定价策略类型判断**：\n- **渗透定价**：低价抢市场份额（看免费版是否功能丰富）\n- **撇脂定价**：高价走高端路线（看是否有大量高级功能门槛）\n- **免费增值**：核心免费，高级收费（看免费版和付费版的功能差距）\n\n### 第五步：竞争定位分析\n\n**竞争定位矩阵**（用两个关键维度画四象限）：\n\n选取两个最能区分竞品的维度（如\"功能深度 vs 易用性\"或\"价格 vs 功能广度\"），将所有产品放入四象限：\n\n| 定位象限 | 特点 | 代表产品 |\n|---------|------|---------|\n| 高功能+高价格 | 企业级全能型 | {产品列表} |\n| 高功能+低价格 | 性价比型 | {产品列表} |\n| 低功能+高价格 | 细分市场型 | {产品列表} |\n| 低功能+低价格 | 入门级 | {产品列表} |\n\n### 第六步：竞品战略推演\n\n根据竞品近期动作推断其下一步可能的战略方向：\n\n**推演方法**：\n\n1. **信号收集**：竞品近3-6个月的产品更新、融资动态、招聘方向、合作公告\n2. **模式识别**：从信号中提取战略意图\n - 连续发布某领域功能 → 可能在押注该方向\n - 大量招聘某类人才 → 可能在筹备新产品线\n - 降价或推出免费版 → 可能在抢市场份额\n3. **推演输出**：\n\n| 竞品 | 近期关键动作 | 推断战略意图 | 对我方影响 | 信心度 | 建议应对 |\n|------|------------|------------|----------|--------|---------|\n| {竞品A} | {动作描述} | {意图推断} | {影响评估} | {高/中/低} | {应对策略} |\n\n**推演注意事项**：\n- 区分\"确定的事实\"和\"推断的意图\"，后者必须标注信心度\n- 一个信号可能有多种解读，列出最可能的2-3种\n- 推演的时间窗口：短期（1-3个月）和中期（3-12个月）\n\n### 第七步：差异化策略输出\n\n基于功能对比结果，按以下框架输出策略：\n\n**差异化三层策略**：\n\n| 层级 | 说明 | 行动建议 |\n|------|------|---------|\n| **追平层** | 竞品都有但我方缺失的功能 | 列出需补齐的功能+优先级+预估工作量 |\n| **差异层** | 我方独有或明显领先的功能 | 列出需持续加强的优势+营销话术建议 |\n| **创新层** | 所有竞品都未做但有机会的方向 | 列出可探索的蓝海功能+验证方法建议 |\n\n### 第八步：写入文档（如已连接）\n\n**如果连接了Notion：**\n1. 竞品分析报告写入指定文档空间\n\n**如果未连接：**\n1. 以Markdown格式输出完整报告\n\n## 质量标准\n\n1. 功能对比基于可验证的公开信息，标注信息来源和时间\n2. 评价维度统一——同一维度用相同尺度评判所有产品\n3. SWOT每条有事实支撑，禁止空泛描述\n4. 差异化建议具体可执行，含优先级排序\n5. 明确标注信息时效性（如\"数据截至2025年Q1\"）\n6. 定价对比数据标注获取日期\n7. 竞品战略推演明确区分事实和推断\n8. Porter五力评估有行业数据支撑\n\n## 红线规则\n\n1. **不编造数据**：未查证的竞品信息标注\"[待核实]\"\n2. **不主观贬低**：对竞品的评价必须客观，不使用贬义词\n3. **标注时效**：所有数据标注获取时间，提醒用户核实最新情况\n4. **推演标注信心度**：竞品战略推演必须标注推断的信心度\n\n## 竞争格局判断\n\n**市场集中度评估**：\n\n| 格局类型 | 特征 | 竞争策略建议 |\n|---------|------|------------|\n| **一超多强** | 一家>50%份额，其余分散 | 差异化细分，避免正面对抗 |\n| **双寡头** | 两家合计>70%份额 | 选边站队或做第三选择 |\n| **群雄混战** | 前5名各<20%份额 | 快速抢占细分市场第一 |\n| **新兴市场** | 无明显领导者 | 抢先教育市场，建立品牌认知 |\n\n## 竞品监测节奏\n\n| 频率 | 监测内容 | 触发动作 |\n|------|---------|---------|\n| **每周** | 竞品产品更新日志、社交媒体动态 | 重大更新记入跟踪表 |\n| **每月** | 定价变化、新功能上线、媒体报道 | 更新功能对比矩阵 |\n| **每季度** | 全面竞品报告更新、战略推演刷新 | 输出竞品季度简报给团队 |\n| **事件驱动** | 竞品融资/并购/重大发布/高管变动 | 即时评估影响并输出应对建议 |\n\n## 输入不足处理\n\n- **仅提供竞品名称**：输出标准功能对比矩阵+简要SWOT\n- **未明确我方产品**：仅输出竞品之间的横向对比，不做差异化建议\n- **竞品超过5个**：建议分批分析，或仅做核心3个的深度分析+其余简要对比\n\n## 关联Skill\n\n- **PRD生成** — 竞品分析中发现的差异化功能转化为PRD\n- **需求优先级排序** — 功能补齐清单用RICE排优先级\n- **用户反馈分析** — 用户反馈中的竞品提及补充竞品感知数据\n- **产品脑暴** — 竞品分析后的差异化创意发散\n- **产品指标复盘** — 竞品动作与自身指标异动交叉验证\n- **路线图更新** — 差异化策略输出指导路线图调整\n\n## 输出格式\n\n```markdown\n# 竞品分析报告：[分析目的]\n\n**分析日期**：[YYYY-MM-DD] **分析人**：[待填] **数据截至**：[YYYY-MM-DD]\n\n## 一、行业竞争格局\n\n| 竞争力量 | 评级 | 评估理由 |\n|---------|------|---------|\n| 供应商议价力 | 强/中/弱 | [一句话理由] |\n| 买家议价力 | 强/中/弱 | [一句话理由] |\n| 新进入者威胁 | 强/中/弱 | [一句话理由] |\n| 替代品威胁 | 强/中/弱 | [一句话理由] |\n| 行业竞争强度 | 强/中/弱 | [一句话理由] |\n\n**综合判断**：行业吸引力 高/中/低\n\n## 二、功能对比矩阵\n\n| 功能模块 | 子功能 | 我方 | 竞品A | 竞品B | 竞品C |\n|---------|--------|-----|------|------|------|\n| {模块1} | {子功能1} | ✅完善 | ✅完善 | ⚠️基础 | ❌无 |\n\n✅完善 / ⚠️基础 / ❌无 / 🔜规划中\n\n## 三、竞品 SWOT 分析\n\n### 竞品A：[名称]\n| | 正面 | 负面 |\n|---|------|------|\n| 内部 | S: [核心优势] | W: [明显短板] |\n| 外部 | O: [可利用机会] | T: [需警惕威胁] |\n\n## 四、竞品定位四象限\n\n| 象限 | 代表产品 |\n|------|---------|\n| 高功能+高价格 | [产品列表] |\n| 高功能+低价格 | [产品列表] |\n| 低功能+高价格 | [产品列表] |\n| 低功能+低价格 | [产品列表] |\n\n## 五、竞品战略推演\n\n| 竞品 | 近期关键动作 | 推断战略意图 | 对我方影响 | 信心度 | 建议应对 |\n|------|------------|------------|----------|--------|---------|\n| {竞品A} | {动作} | {意图} | {影响} | 高/中/低 | {策略} |\n\n## 六、定价对比（如适用）\n\n| 对比项 | 我方 | 竞品A | 竞品B | 竞品C |\n|--------|-----|------|------|------|\n| 免费版能力 | {范围} | {范围} | {范围} | {范围} |\n| 入门版月费 | {价格} | {价格} | {价格} | {价格} |\n| 企业版月费 | {价格} | {价格} | {价格} | {价格} |\n\n## 七、差异化策略\n\n| 层级 | 行动建议 | 优先级 |\n|------|---------|--------|\n| **追平层** | {竞品都有但我方缺失的功能} | P0/P1/P2 |\n| **差异层** | {我方独有或领先的功能} | P0/P1/P2 |\n| **创新层** | {蓝海功能方向} | P1/P2 |\n\n## 八、信息可信度说明\n\n| 竞品 | 信息可信度 | 主要来源 | 时效标注 |\n|------|----------|---------|---------|\n| {竞品A} | 高/中/低 | {来源} | {日期} |\n```\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|-----------------|\n| 信息收集 | 竞品公开信息不足（如闭源企业级产品） | 标注\"[信息不足]\"并基于公开文档做有限对比，空缺功能位标注为\"未知\"而非\"缺失\" | 1次 | 建议用户提供内部使用体验或采购竞品试用账号 |\n| 多维度对比分析 | 竞品功能信息不足以支撑完整功能矩阵 | 输出已确认部分的功能对比，缺失模块标注\"[待补充]\" | 2次 | 对信息不足的竞品降级为简要对比，专注信息充分的竞品 |\n| 竞争定位分析 | 维度选取不当导致竞品无法有效区分 | 切换备选维度（如\"功能深度vs易用性\"→\"价格vs目标客群\"）重新定位 | 2次 | 输出多组维度下的定位图，标注每组维度的适用场景 |\n| 竞品战略推演 | 竞品近期无公开动作可追踪 | 标注\"近期无可观测公开动作，推演暂停\" | 1次 | 降级为静态竞争格局分析，待有信号后再触发推演更新 |\n| 差异化策略输出 | 差异化方向无法基于现有数据支撑 | 输出已确认的追平层策略，差异层和创新层标注\"[需进一步验证]\" | 1次 | 建议结合用户反馈分析和产品脑暴补充差异化方向 |\n\nFile v0.1.0:references/prd-generation.md\n\n# PRD生成\n\n根据功能需求描述，生成可直接交付评审的产品需求文档（PRD）。内置产品类型分支（B2C/B2B/内部工具/平台型），不同类型侧重不同模块。包含PRD质量自检清单，确保文档完整度。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | PRD写入 Notion 页面，搜索已有PRD作为参考 |\n| **Figma** | 引用设计稿链接和组件规范，增强交互说明部分 |\n\n## 输入要求\n\n用户需提供以下信息（缺失项主动追问）：\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 功能描述 | 是 | 要做什么功能、解决什么问题，至少一句话 |\n| 目标用户 | 否 | 面向谁，未提供则根据功能推断 |\n| 业务目标 | 否 | 期望达成的业务指标（DAU、转化率、营收等） |\n| 产品类型 | 否 | B2C/B2B/内部工具/平台型，未指定则自动推断 |\n| 约束条件 | 否 | 技术限制、时间要求、资源限制 |\n| PRD深度 | 否 | 概要版（评审用）/ 详细版（开发用），默认详细版 |\n\n> **信息完整度判断**：若用户仅说\"写个PRD\"未给需求，进入**引导模式**追问功能描述；若提供了功能描述+目标用户+业务目标，进入**快速模式**直接生成。\n\n## 执行流程\n\n### 第一步：需求解析与产品类型分支\n\n解析用户输入，确定产品类型。不同类型的PRD侧重点差异显著：\n\n| 产品类型 | PRD侧重模块 | 关键差异 |\n|----------|-----------|---------|\n| **B2C** | 用户体验流程、增长指标、A/B测试方案 | 重交互、重数据、多写用户旅程 |\n| **B2B** | 权限模型、多租户、SLA、集成接口 | 重功能完备性、重安全合规、多写API对接 |\n| **内部工具** | 操作效率、与现有系统集成、培训成本 | 重实用性、轻视觉、多写操作流程 |\n| **平台型** | 多角色交互、供需匹配、生态规则 | 重角色拆分、重规则引擎、多写各角色视角 |\n\n**类型自动推断规则**：含\"用户/会员/积分/商城\"→B2C；含\"企业/SaaS/CRM/后台管理\"→B2B；含\"内部/管理系统/工单\"→内部工具；含\"平台/市场/撮合/双边\"→平台型。\n\n**B2B产品必须额外覆盖**：\n- 权限矩阵（角色 x 功能 x 数据范围）\n- 多租户数据隔离方案描述\n- 与客户现有系统的集成接口清单\n\n**平台型产品必须额外覆盖**：\n- 各角色（供方/需方/平台运营）独立功能视角\n- 供需匹配规则和排序策略\n- 平台佣金/抽成/结算规则\n\n### 第二步：结构化需求拆解\n\n**如果连接了Notion：**\n1. 搜索团队知识库中已有的相关PRD作为参考\n2. 获取团队的PRD模板规范（如有）\n\n**如果未连接：**\n1. 使用内置标准模板结构\n\n**功能拆解三步法：**\n1. **用户旅程法**：画出用户从入口到完成目标的完整路径，每个节点即一个功能点\n2. **角色拆分法**：列出所有涉及的角色（终端用户、管理员、运营等），每个角色的操作即一个功能模块\n3. **CRUD法**：对核心数据对象，梳理创建/读取/更新/删除四类操作\n\n对每个功能模块，填充以下字段：\n- 功能描述（一句话说做什么）\n- 用户故事（作为[角色]，我希望[操作]，以便[价值]）\n- 业务规则（穷举所有规则，不留模糊地带）\n- 交互说明（操作入口 → 操作步骤 → 成功/失败反馈）\n- 异常处理（网络超时、数据异常、权限不足等边界情况）\n\n### 第三步：生成完整PRD\n\n按以下模板输出。**每个占位符旁标注了填充逻辑**：\n\n## 输出格式\n\n```markdown\n# PRD：{功能名称}\n\n**版本**：v1.0\n**作者**：{产品经理名，用户未提供则写\"[待填写]\"}\n**日期**：{当前日期}\n**状态**：草稿\n\n---\n\n## 1. 背景与目标\n\n### 1.1 背景\n<!-- 填充逻辑：回答三个问题——为什么现在做？不做会怎样？做了能怎样？ -->\n{问题现状 + 用户痛点 + 为什么现在是做的时机}\n\n<!-- 示例：客服团队每天处理 2000+ 重复性问题，人力成本月均 15 万，响应时长超 30 分钟。不做自动化将无法支撑 Q4 业务翻倍目标。上线后预计 60% 重复性问题可自助解决，年节省人力成本 120 万。 -->\n\n### 1.2 目标用户\n<!-- 填充逻辑：用\"[角色]+[特征]+[场景]\"的格式，不泛泛说\"所有用户\" -->\n| 用户角色 | 特征描述 | 核心诉求 | 使用场景 |\n|---------|---------|---------|---------|\n| （示例：坐席客服 | 日均处理50+工单 | 快速检索标准答案并一键回复 | 用户来电时边通话边查知识库） |\n\n### 1.3 业务目标与成功指标\n<!-- 填充逻辑：每个目标必须SMART化——有具体数字和截止时间 -->\n| 目标 | 衡量指标 | 目标值 | 监测方式 |\n|------|---------|--------|---------|\n| （示例：减少重复性人工处理 | 自助解决率 | ≥60%（上线3月内） | 客服系统统计） |\n\n<!-- 示例：| 减少重复性人工处理 | 自助解决率 | ≥60%（上线3月内） | 客服系统统计 | -->\n\n## 2. 需求概述\n<!-- 填充逻辑：一段话概括核心需求，30字以内 -->\n\n## 3. 功能详细设计\n\n### 3.1 {功能模块1}\n**功能描述**：{做什么}\n**用户故事**：作为{角色}，我希望{操作}，以便{价值}\n**优先级**：P0/P1/P2（P0=必须上线，P1=强烈建议，P2=锦上添花）\n\n**业务规则**：\n1. {规则1——写清楚触发条件和处理逻辑}\n2. {规则2}\n\n**交互流程**：\n<!-- 填充逻辑：从入口开始，写到任务完成，覆盖正常流程+异常分支 -->\n1. 用户从{入口}进入\n2. {操作步骤}\n3. 成功：{反馈}\n4. 失败：{错误提示和处理方式}\n\n**异常处理**：\n| 异常场景 | 处理方式 | 用户提示 |\n|---------|---------|---------|\n\n（后续模块同上格式）\n\n## 4. 非功能需求\n<!-- 填充逻辑：B2C 侧重性能和体验，B2B 侧重安全和可用性 -->\n| 类别 | 要求 | 验收标准 |\n|------|------|---------|\n| 性能 | {如：页面加载时间} | {如：<2秒} |\n| 安全 | {如：数据加密} | {如：传输层TLS 1.2+} |\n| 兼容性 | {如：浏览器/设备} | {如：Chrome/Safari/微信浏览器} |\n\n## 5. 数据需求\n<!-- 填充逻辑：列出所有需要采集的数据事件，用事件名+触发条件+属性格式 -->\n| 事件名 | 触发条件 | 关键属性 | 用途 |\n|--------|---------|---------|------|\n\n## 6. 验收标准\n<!-- 填充逻辑：每个功能模块至少3条AC，用Given-When-Then格式 -->\n| 编号 | 场景 | Given（前提） | When（操作） | Then（预期结果） |\n|------|------|-------------|-------------|-----------------|\n\n## 7. 排期建议\n<!-- 填充逻辑：拆到开发/测试/联调/上线四个阶段 -->\n| 阶段 | 预估工时 | 依赖 | 风险点 |\n|------|---------|------|--------|\n\n## 8. 风险与依赖\n| 风险 | 概率 | 影响 | 缓解措施 |\n|------|------|------|---------|\n\n## 附录\n- 相关文档链接\n- 竞品参考（详见 `competitive-analysis.md` 获取完整竞品分析方法与功能对比框架）\n- 设计稿地址\n```\n\n### 第四步：PRD质量自检\n\n生成后按以下清单逐项检查：\n\n| 序号 | 检查项 | 判断标准 |\n|------|--------|---------|\n| 1 | 背景不空泛 | 回答了\"为什么做\"而非只说\"需要做\" |\n| 2 | 目标可量化 | 至少一个数字型成功指标 |\n| 3 | 用户画像具体 | 不含\"所有用户\"这种描述 |\n| 4 | 业务规则穷举 | 无\"等\"、\"其他情况\"等模糊表述 |\n| 5 | 异常流程覆盖 | 每个功能至少覆盖2个异常场景 |\n| 6 | 验收标准可测试 | 使用Given-When-Then格式 |\n| 7 | 数据埋点完整 | 核心操作路径均有埋点 |\n| 8 | 无技术方案 | PRD只描述\"做什么\"，不写\"怎么实现\" |\n| 9 | 优先级明确 | 功能模块标注了P0/P1/P2 |\n| 10 | 排期有依据 | 工时评估考虑了开发/测试/联调 |\n\n不通过的项标注并提示修改建议。\n\n## 质量标准\n\n1. PRD结构完整——包含背景/目标/用户/功能/非功能/数据/验收/排期/风险九大模块\n2. 业务目标可量化——至少1个SMART化成功指标（含数字和截止时间）\n3. 用户画像具体——不含\"所有用户\"等泛化描述\n4. 业务规则穷举——无\"等\"\"其他情况\"等模糊表述\n5. 异常流程覆盖——每个功能模块至少2个异常场景\n6. 验收标准可测试——使用Given-When-Then格式，QA可直接转化为测试用例\n7. 优先级明确——功能模块标注P0/P1/P2\n8. 不越界——PRD只描述\"做什么\"，不写技术实现和视觉设计细节\n9. 产品类型适配——B2B覆盖权限矩阵/多租户/集成接口；平台型覆盖多角色视角/供需匹配规则\n\n## PRD常见反模式（自检防护）\n\n| 反模式 | 表现 | 正确做法 |\n|--------|------|---------|\n| **需求镀金** | 一期就写了50个功能点 | 划分MVP/V1.1/V2，一期聚焦核心3-5个功能 |\n| **伪需求** | \"用户可能需要...\"没有数据或调研支撑 | 标注需求来源：用户反馈/数据分析/竞品参考/业务判断 |\n| **交互越界** | PRD里写了按钮颜色、字号、布局 | 只描述信息层级和交互逻辑，视觉交给设计师 |\n| **技术越界** | PRD里指定用Redis缓存、MySQL存储 | 只描述性能要求（如\"<2秒\"），实现方案交给技术 |\n| **规则黑洞** | \"按照业务规则处理\"但不写具体规则 | 穷举每条规则的触发条件、处理逻辑、边界值 |\n\n## 红线规则\n\n1. **PRD不写技术实现**：不指定数据库类型、编程语言、框架选型\n2. **不替代设计稿**：不详细描述UI布局、配色、字号，只描述交互逻辑和信息层级\n3. **不编造数据**：用户未提供的业务数据（日活、转化率等）标注\"[待补充]\"\n4. **不遗漏角色**：涉及多角色的功能，每个角色的视角都要覆盖\n\n## 输入不足处理\n\n| 缺失项 | 处理方式 | 交付降级 |\n|-------|---------|---------|\n| 仅说\"写个PRD\"无任何描述 | 追问功能描述，给出示例引导（如\"是想做一个类似XX的功能吗？预计解决什么问题？\"） | 不交付，进入引导模式 |\n| 只有一句话需求（如\"做个商城\"） | 生成概要版PRD框架含基础功能清单，标注需补充的关键信息清单（目标用户/核心流程/差异化定位） | 交付框架版，标注\"信息不足\" |\n| 未提供用户画像或目标用户 | 根据产品类型推断典型用户群体并用\"[假设用户画像：XX]\"标注，提示用户确认或修正 | 标准交付，用户画像标注假设 |\n| 需求过于庞大（50+功能点） | 按MVP → V1.1 → V2.0分层拆分，先输出MVP范围PRD，标注\"以下为MVP范围，完整需求见后续版本\" | 交付MVP版PRD，其余入backlog |\n| 未说明业务背景或问题 | 不交付，追问\"为什么要做这个功能？用户/业务当前遇到的痛点是什么？\" | 不交付，进入引导模式 |\n\n## 关联Skill\n\n- **用户故事拆解** — PRD评审通过后，将功能拆解为开发可执行的User Story\n- **竞品分析** — PRD撰写前，先做竞品分析获取功能参考\n- **需求优先级排序** — 多个需求并行时，用RICE排序确定优先级\n- **用户反馈分析** — PRD需求来源可结合用户反馈数据支撑\n- **产品指标复盘** — PRD上线后通过指标复盘验证需求效果\n- **产品脑暴** — 需求早期用脑暴发散创意再沉淀为PRD\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|-----------------|\n| 需求理解 | 用户描述模糊无法形成功能列表 | 输出\"需求澄清问卷\"引导用户补充 | 2次 | 建议用户提供竞品参考或截图，由Agent基于参考反推需求 |\n| 用户画像推断 | 无法从已知信息合理推断 | 标注\"用户画像缺失\"并使用通用模板 | 1次 | 输出PRD框架，明确标注用户画像部分需用户补充 |\n| 功能边界划定 | 需求范围持续膨胀无法收敛 | 强制暂停，输出已收敛的MVP范围 + 待确认清单 | 1次 | 由用户做最终范围决策，Agent不自行扩大范围 |\n| 验收标准编写 | 对特定场景无法给出可测试标准 | 标注\"[待补充验收标准]\"并说明原因（如涉及第三方系统行为不可控） | 2次 | 建议用户提供该场景的历史数据或预期行为描述 |\n\nFile v0.1.0:references/product-brainstorm.md\n\n# 产品脑暴\n\n作为产品经理的思维搭档，围绕一个具体的产品问题或机会点进行结构化创意发散。不只是列想法——而是通过提问、挑战假设、跨界借鉴，帮你想到原本想不到的方案。最终输出经过初步筛选的创意清单，直接可流转到下一步。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | 脑暴记录写入团队文档，供团队评审和投票 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 脑暴主题 | 是 | 要解决的问题或要探索的机会（越具体越好） |\n| 背景信息 | 否 | 用户画像、当前数据、已知约束等上下文 |\n| 发散模式 | 否 | 全量发散/聚焦某框架（如仅用SCAMPER），默认\"全量发散\" |\n| 约束条件 | 否 | 技术约束、时间约束、资源约束 |\n\n> **好的脑暴主题**：\"如何让新用户在首次使用的5分钟内感受到产品价值\"\n> **不好的脑暴主题**：\"如何改进产品\"（太宽泛）\n\n## 执行流程\n\n### 第一步：问题聚焦\n\n在发散之前，先确保问题定义足够清晰：\n\n**追问清单**（逐项确认）：\n1. **谁有这个问题？** 具体的用户类型和场景\n2. **现在怎么解决的？** 用户当前的替代方案或workaround\n3. **为什么重要？** 不解决的后果是什么\n4. **什么算成功？** 好的解决方案长什么样\n5. **有什么约束？** 技术/时间/资源的边界\n\n将问题重述为 **\"How Might We\"** 句式：\n- \"我们如何能让{目标用户}在{场景}中更轻松地{完成目标}？\"\n\n### 第二步：SCAMPER 七维度发散\n\n围绕当前产品/功能/流程，逐一用七个视角激发新想法：\n\n| 视角 | 核心问题 | 发散方向 |\n|------|---------|---------|\n| **S - 替换** | 什么组件可以被替换？ | 换个技术方案？换个交互形式？换个入口？ |\n| **C - 组合** | 能不能把两个功能合并？ | 合并步骤？合并场景？打包功能？ |\n| **A - 调整** | 能不能借鉴其他产品的做法？ | 抖音的做法能借鉴吗？微信的做法呢？ |\n| **M - 修改** | 放大10倍或缩小10倍会怎样？ | 极简版长什么样？极致版长什么样？ |\n| **P - 另作他用** | 这个功能还能服务什么场景？ | 其他用户群会怎么用？ |\n| **E - 消除** | 去掉什么反而更好？ | 减少步骤？去掉注册？移除某个字段？ |\n| **R - 重排** | 换个顺序会怎样？ | 先体验后注册？倒着来？ |\n\n每个视角至少产出1-2个想法，总计产出7-14个初始创意。\n\n### 第三步：5 Why 根因追问\n\n从用户痛点出发，逐层追问到根因，再从根因发散解决方案：\n\n**追问过程**（示例）：\n\n**痛点**：用户注册后第二天就不来了\n- **Why 1**：因为第一天没找到想要的功能\n - **Why 2**：因为功能入口太深\n - **Why 3**：因为导航结构按产品架构设计，不是按用户任务设计\n - **Why 4**：因为没做过用户任务分析\n - **Why 5（根因）**：产品设计脱离用户实际使用场景\n - **方案**：重新做用户任务分析，按任务重组导航\n - **方案**：增加搜索功能/智能推荐入口\n - **方案**：新手引导直接带到核心功能\n - **方案**：注册时询问使用目的，个性化首页\n\n**规则**：\n- 至少追问到第3层Why\n- 每层Why可以分叉（一个现象可能有多个原因）\n- 从不同层级的Why出发，各想1-2个解决方案\n\n### 第四步：竞品启发法\n\n不是抄竞品——是看竞品做了什么，思考\"我们能做什么不同的\"：\n\n**跨界启发**：\n1. 列出3-5个虽然不是直接竞品但解决类似用户需求的产品\n2. 分析它们的亮点做法\n3. 思考：如果把这个做法搬到我们的场景会怎样？需要做什么适配？\n\n**差异化启发**：\n1. 竞品都在做X → 我们如果反其道做Y会怎样？\n2. 竞品的X功能被用户吐槽的点 → 我们能不能从这个痛点切入？\n3. 竞品没做但用户在social media上频繁讨论的需求 → 是否是我们的机会？\n\n### 第五步：约束创新法\n\n故意设置约束条件，在约束中激发创意：\n\n**常用约束设定**：\n\n| 约束类型 | 设定方式 | 激发思路 |\n|---------|---------|---------|\n| **时间约束** | \"如果只有1周开发时间\" | 逼出最小可行方案 |\n| **技术约束** | \"只能用现有技术栈\" | 发现已有能力的新用法 |\n| **成本约束** | \"零开发投入\" | 运营手段、配置变更、文案优化 |\n| **极端约束** | \"只能改一行代码\" | 找到杠杆最大的单点突破 |\n| **反转约束** | \"如果让用户来设计\" | 换视角思考 |\n\n每种约束产出1-2个方案，约束越紧往往创意越巧妙。\n\n### 第六步：反向脑暴法\n\n先思考\"怎么让这个问题变得更糟糕\"，再逆转每个\"恶化方案\"：\n\n**操作步骤**：\n1. 重新定义问题为反面：\"如何让新用户第一天就卸载？\"\n2. 列出所有会导致问题恶化的做法（通常比正面思考更容易产出）\n3. 将每个\"恶化方案\"逆转为改进方案\n\n**示例**：\n| 恶化方案 | 逆转后的改进方案 |\n|---------|-------------|\n| 注册要填20个字段 | 只要手机号一键注册，其余渐进式补充 |\n| 首页全是广告 | 首页只展示与用户目标相关的核心内容 |\n| 隐藏所有帮助入口 | 在用户可能困惑的节点主动提供引导 |\n\n> 反向脑暴的优势：绕过\"正确答案\"的心理压力，发散阶段更自由。\n\n### 第七步：创意评估初筛\n\n用 Impact/Effort 快速矩阵对所有脑暴结果做初步筛选：\n\n| 象限 | Impact | Effort | 策略 | 创意列表 |\n|------|--------|--------|------|---------|\n| **Quick Wins** | 高 | 低 | 优先验证 | {列表} |\n| **Big Bets** | 高 | 高 | 值得投入但需仔细规划 | {列表} |\n| **Fill-ins** | 低 | 低 | 有空再做 | {列表} |\n| **Money Pits** | 低 | 高 | 放弃 | {列表} |\n\n**评估标准**：\n- **Impact**：解决痛点的程度 x 受影响用户范围\n- **Effort**：开发工作量 + 设计工作量 + 联调测试\n\n### 第八步：输出创意清单\n\n## 输出格式\n\n```markdown\n# 产品脑暴记录\n\n**主题**：{脑暴问题}\n**HMW**：我们如何能{重述为HMW}\n**日期**：{日期}\n**产出创意数**：{N}个（筛选后保留{M}个）\n\n## 创意清单\n\n| 编号 | 创意描述 | 解决的痛点 | 来源框架 | 预期价值 | 实现难度 | 象限 | 下一步验证方式 |\n|------|---------|----------|---------|---------|---------|------|-------------|\n| 1 | {描述} | {痛点} | SCAMPER-消除 | 高/中/低 | 高/中/低 | Quick Win | {验证方式} |\n\n## Top 3 推荐创意\n\n### 创意1：{名称}\n- **描述**：{详细描述}\n- **解决的痛点**：{具体痛点}\n- **预期效果**：{量化预期，如\"预计提升次日留存5-10%\"}\n- **实现路径**：{简要技术/设计方案}\n- **验证方式**：{如何快速验证，如A/B测试、灰度发布}\n- **风险**：{可能的风险和应对}\n\n### 创意2：{名称}\n...\n\n### 创意3：{名称}\n...\n\n## 被放弃的创意（存档参考）\n- {创意X}：放弃原因——{原因}\n- {创意Y}：放弃原因——{原因}\n\n## 下一步行动\n- [ ] {行动1}\n- [ ] {行动2}\n```\n\n## 脑暴原则\n\n1. **先发散后收敛**：发散阶段不评判，收敛阶段才筛选\n2. **量产出质**：先追求数量（15+个想法），再从中筛选\n3. **具体胜过抽象**：\"在注册第3步加个进度条\"比\"优化注册体验\"更有用\n4. **敢于极端**：极端的想法经过修正后往往变成好创意\n5. **挑战假设**：质疑\"这不可能\"\"一直都是这样做的\"\n\n## 质量标准\n\n1. 产出创意数>=10个（发散充分）\n2. 每个创意有具体描述（不是\"优化XX\"这种模糊表述）\n3. 至少来自3个不同的发散框架\n4. 筛选后的Top 3有明确的验证方式\n5. 创意清单可直接作为下一步决策的输入\n\n## 红线规则\n\n1. **不在发散阶段否定**：发散时不说\"做不到\"\"不可能\"\n2. **不输出空泛建议**：\"优化用户体验\"不是创意，是废话\n3. **不替代决策**：脑暴产出方案，不做最终选择\n\n## 输入不足处理\n\n- **主题太宽泛**：帮助用户聚焦（追问具体场景和用户）\n- **缺乏背景信息**：基于通用产品逻辑进行发散，标注\"建议补充具体数据以提高创意针对性\"\n- **指定单一框架**：仅用指定框架发散，但建议\"可追加其他框架获得更多维度的创意\"\n\n## 跨技能联动\n\n脑暴后的优质创意可通过以下技能进一步落地：\n- `PRD生成`：将Top创意转化为正式的产品需求文档\n- `需求优先级排序`：创意清单整体纳入需求池进行正式排序\n- `用户故事拆解`：将创意拆解为可开发的用户故事\n- `竞品分析`：验证创意的差异化程度\n\n## 关联Skill\n\n- **PRD生成** — 脑暴Top创意转化为正式产品需求文档\n- **需求优先级排序** — 创意清单整体纳入需求池进行正式排序\n- **用户故事拆解** — 创意拆解为可开发的User Story\n- **竞品分析** — 验证创意的差异化程度，评估竞品是否已实现\n- **用户反馈分析** — 从用户痛点中获取脑暴灵感输入\n- **路线图更新** — 脑暴创意纳入路线图的Later规划区\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|------------------|\n| 第一步：问题聚焦 | 脑暴主题过于宽泛无法聚焦 | 追问具体场景和用户，帮助用户将主题收敛为HMW句式 | 2次 | 基于宽泛主题做发散，标注\"主题较宽泛，创意可能不够聚焦\" |\n| 第二步：SCAMPER七维度发散 | 某些视角无法产出有效创意 | 跳过该视角，标注\"本视角暂无有效创意\"，确保其余视角产出 | 1次 | 至少保证5个视角有产出，标注\"部分视角未产出创意\" |\n| 第三步：5 Why根因追问 | 痛点描述不清晰导致追问偏离 | 基于已有信息追问到第3层Why，标注\"深层根因需补充背景信息\" | 1次 | 输出浅层根因分析，标注\"深层根因待补充信息后完善\" |\n| 第四步：竞品启发法 | 无法找到合适的跨界参考产品 | 基于通用产品体验做启发，标注\"参考为通用产品而非跨界产品\" | 1次 | 跳过跨界启发，仅做差异化启发，标注\"跨界参考不足\" |\n| 第五步：约束创新法 | 约束条件不明确 | 使用默认约束集（时间/技术/成本）进行发散 | 1次 | 基于通用约束产出方案，标注\"约束为假设值，需用户确认\" |\n| 第六步：反向脑暴法 | 问题难以逆转为反面表述 | 跳过反向脑暴，标注\"本主题不适合反向脑暴\" | 0次 | 跳过该步骤，确保其余框架的创意产出充足 |\n| 第七步：创意评估初筛 | 创意数量不足（<10个）无法有效筛选 | 放宽筛选标准，对所有创意做评估，标注\"创意数量不足，建议补充发散\" | 1次 | 输出全部创意及评估，标注\"样本不足，筛选结果仅供参考\" |\n| 第八步：输出创意清单 | Top 3创意无法明确选定 | 输出Top 5创意供用户选择，标注\"需用户做最终选择\" | 1次 | 输出全部创意清单，标注\"由用户自行筛选Top 3\" |\n\nFile v0.1.0:references/product-metrics-review.md\n\n# 产品指标复盘\n\n对产品核心指标进行系统化复盘，识别趋势变化、定位问题根因、给出行动建议。内置北极星指标体系、留存分析框架、转化漏斗方法论和A/B实验解读能力，帮助产品经理从数据中提取决策洞察。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | 复盘报告写入团队知识库 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 指标数据 | 是 | Excel/CSV文件、粘贴数据表格、或口头描述关键指标 |\n| 复盘周期 | 否 | 周复盘/月复盘/季度复盘，默认\"周复盘\" |\n| 关注焦点 | 否 | 全面复盘/某指标异动分析/实验结果解读 |\n| 业务上下文 | 否 | 本周期内的产品发布、运营活动、故障等影响因素 |\n\n> **复盘模式判断**：提供全量数据 → 输出完整复盘报告；仅提供单一指标变化 → 输出聚焦的异动分析。\n\n## 执行流程\n\n### 第一步：数据获取与整理\n\n解析用户上传的文件或粘贴的数据。若用户口头描述（如\"DAU从10万降到8万\"），基于描述进行分析。\n\n**数据完整性检查**：\n- 确认时间维度覆盖（当前期 vs 对比期）\n- 确认指标维度（北极星/L1/L2哪些指标有数据）\n- 缺失的关键数据标注并提醒用户补充\n\n### 第二步：北极星指标体系构建\n\n**指标拆解方法**（北极星 → L1 → L2）：\n\n**北极星指标**（产品核心价值度量）\n- **L1-用户增长**：DAU/WAU/MAU、新增、回流\n- **L1-用户活跃**：核心行为频次、使用时长、功能渗透率\n- **L1-用户留存**：次日/7日/30日留存率\n- **L1-转化效率**：注册→激活→付费各环节转化率\n- **L1-商业价值**：付费率、ARPU、LTV\n- **L1-用户满意度**：NPS、客诉率、评分\n\n**北极星指标选择指南**（按产品类型）：\n\n| 产品类型 | 推荐北极星 | 典型L1指标 |\n|---------|----------|----------|\n| 社交/社区 | 周活跃发帖用户数 | DAU/MAU比、人均互动数、7日留存 |\n| 工具/效率 | 周完成核心任务的用户数 | 任务完成率、使用频次、功能渗透 |\n| 电商/交易 | 周交易用户数 | GMV、客单价、复购率、转化率 |\n| 内容/媒体 | 周内容消费时长 | 人均阅读/观看时长、完读率、回访率 |\n| SaaS/B端 | 周活跃团队数 | 团队渗透率、功能使用深度、续费率 |\n| 小程序 | 周访问用户数(UV) | PV/UV比、分享率、次日回访率 |\n\n### 第三步：用户增长指标分析\n\n**DAU/WAU/MAU 定义与计算**：\n- **DAU**：当日启动/访问并执行有效行为的独立用户数\n- **WAU**：7日内至少有1天活跃的独立用户数\n- **MAU**：30日内至少有1天活跃的独立用户数\n- **DAU/MAU比（粘性）**：>0.5 极高粘性，0.3-0.5 高粘性，0.2-0.3 中等，<0.2 低粘性\n\n**用户分层**：\n\n| 用户类型 | 定义 | 关注点 |\n|---------|------|--------|\n| **新增用户** | 首次使用产品 | 获客渠道质量、激活率 |\n| **活跃用户** | 本期和上期均活跃 | 使用深度、功能渗透 |\n| **回流用户** | 上期沉默、本期重新活跃 | 回流原因、二次留存 |\n| **流失用户** | 上期活跃、本期沉默 | 流失原因、挽回可能性 |\n| **沉默用户** | 连续多期不活跃 | 是否已永久流失 |\n\n**增长公式**：本期MAU = 上期活跃留存 + 新增 + 回流 - 流失\n\n**微信生态补充指标**：\n- 小程序：UV/PV、页面访问深度、分享率、收藏率\n- 公众号：打开率、阅读完成率、分享率、取关率\n- 视频号：完播率、互动率、关注转化率\n\n### 第四步：留存分析\n\n**留存定义与计算**：\n- **次日留存（D1）**：注册/首次使用后第2天回来的比例\n- **7日留存（D7）**：注册后第8天回来的比例\n- **30日留存（D30）**：注册后第31天回来的比例\n\n**留存健康基准值**（中国互联网产品）：\n\n| 产品类型 | D1基准 | D7基准 | D30基准 | 说明 |\n|---------|--------|--------|---------|------|\n| 社交通讯 | >70% | >50% | >35% | 高频刚需，基准最高 |\n| 工具应用 | >40% | >25% | >15% | 用完即走，基准适中 |\n| 内容资讯 | >35% | >20% | >10% | 替代品多，留存偏低 |\n| 电商交易 | >25% | >15% | >8% | 低频场景，看复购率 |\n| 游戏 | >40% | >20% | >10% | 品类差异大 |\n| B端SaaS | >60% | >45% | >30% | 切换成本高，基准较高 |\n| 小程序 | >20% | >10% | >5% | 无安装，留存天然偏低 |\n\n**留存曲线诊断**：\n- **陡峭下降型**（D1→D7 损失>60%）：激活体验有问题，用户没找到价值\n- **缓慢衰减型**（D7→D30 持续下降不收敛）：缺乏长期使用动力\n- **L型收敛**（D7后趋于平稳）：健康，已形成核心用户群\n- **回升型**（某一天突然回升）：可能有周期性使用场景（如周一用、工作日用）\n\n**留存分群对比**：\n- 按渠道分：自然量 vs 投放量的留存差异\n- 按行为分：完成激活动作 vs 未完成的留存差异\n- 按时间分：不同月份注册用户的留存曲线对比（判断产品改进效果）\n\n### 第五步：转化漏斗分析\n\n**漏斗定义方法**：\n1. 明确漏斗起点和终点（如：首页访问 → 支付成功）\n2. 拆分中间关键步骤（每步应代表一个用户决策点）\n3. 计算每步转化率 = 到达下一步人数 / 到达本步人数\n\n**漏斗分析框架**：\n\n| 分析步骤 | 具体动作 | 输出 |\n|---------|---------|------|\n| **绘制漏斗** | 列出各步骤及转化率 | 漏斗全景图 |\n| **识别瓶颈** | 找到转化率最低的步骤 | 优化聚焦点 |\n| **对比基准** | 与历史/行业/竞品对比 | 差距量化 |\n| **拆分维度** | 按渠道/设备/用户类型拆分 | 定位问题人群 |\n| **生成假设** | 分析瓶颈可能的原因 | 优化方向 |\n| **建议实验** | 提出验证假设的A/B实验 | 行动计划 |\n\n**常见漏斗类型**：\n- **获客漏斗**：曝光 → 点击 → 下载/注册 → 激活\n- **激活漏斗**：注册 → 引导完成 → 核心行为首次触发\n- **付费漏斗**：浏览 → 加购 → 下单 → 支付成功\n- **分享漏斗**：触发分享入口 → 点击分享 → 好友打开 → 好友转化\n\n### 第六步：A/B实验解读\n\n**实验结果判断框架**：\n\n| 判断维度 | 标准 | 说明 |\n|---------|------|------|\n| **统计显著性** | p值<0.05 | p>0.05 → 结果不确定，不应据此决策 |\n| **效果量** | 相对提升>MDE（最小可检测效果） | 即使显著但提升极小，投入产出可能不值 |\n| **样本量** | 达到预设样本量 | 未达样本量的\"显著\"结果不可信 |\n| **持续时间** | 覆盖完整周期（至少1-2个自然周） | 避免周末/工作日差异误判 |\n| **AA校验** | 实验前两组基线一致 | 基线不一致说明分流有问题 |\n\n**决策框架**：\n- 显著+效果大 → 全量上线\n- 显著+效果小 → 评估长期价值和实施成本后决策\n- 不显著 → 不上线，分析原因（假设错了？样本不够？执行问题？）\n- 指标冲突（A指标升B指标降） → 综合评估，以北极星指标为准\n\n**实验常见陷阱**：\n- 过早看结果（未达样本量就下结论）\n- 只看主指标不看护栏指标\n- 多次peek导致假阳性\n- 忽略新奇效应（新功能初期数据可能虚高）\n\n### 第七步：OKR对齐检查\n\n审查指标与团队OKR的对应关系：\n\n| 检查项 | 健康标准 | 异常信号 |\n|--------|---------|---------|\n| **覆盖度** | 每个KR至少对应1个可追踪指标 | 有KR无法用数据衡量 |\n| **一致性** | 指标变化方向与KR目标一致 | 指标涨了但KR没进展 |\n| **进度** | 按时间线性进度≥50%（季度中期） | 严重滞后于时间进度 |\n| **归因** | 指标提升可归因于团队行动 | 指标好转但与团队无关（如行业红利） |\n\n**OKR进度评估表**：\n\n| OKR | KR指标 | 目标值 | 当前值 | 进度% | 趋势 | 风险评估 |\n|-----|--------|--------|--------|-------|------|---------|\n| {O1} | {KR1} | {目标} | {当前} | {X%} | 上升/平稳/下降 | 按时/有风险/严重滞后 |\n\n### 第八步：指标异动归因\n\n当发现指标异常变化时，按以下框架定位原因：\n\n**归因分析步骤**：\n1. **量化异常**：具体变化了多少？从什么时候开始？\n2. **维度拆解**：按渠道/地域/版本/用户群拆分，定位异常集中在哪里\n3. **时间对齐**：异常时间点前后发生了什么（发版、活动、故障、竞品动作）\n4. **排除法**：逐一排除可能原因，直到锁定最可能的根因\n5. **交叉验证**：用其他指标验证归因是否成立\n\n**常见异动原因清单**：\n\n| 原因类别 | 典型表现 | 验证方式 |\n|---------|---------|---------|\n| 版本发布 | 与发版时间高度吻合 | 分版本对比 |\n| 运营活动 | 活动期间升，结束后回落 | 分渠道对比 |\n| 技术故障 | 突然下跌+恢复 | 看错误日志和可用性 |\n| 外部因素 | 全行业普遍变化 | 对比竞品/行业数据 |\n| 渠道变化 | 某渠道数据剧变 | 分渠道拆解 |\n| 季节性 | 同比去年类似 | 看同期历史数据 |\n\n### 第九步：生成复盘报告\n\n**如果连接了Notion：**\n1. 将报告写入团队知识库指定位置\n\n**如果未连接：**\n1. 以Markdown格式输出完整报告\n\n## 输出格式\n\n```markdown\n# 产品指标复盘报告\n\n**复盘周期**：{日期范围}\n**产品名称**：{产品}\n**复盘类型**：{周复盘/月复盘/季度复盘}\n\n## 一、指标健康度总览\n\n| 指标层级 | 指标名称 | 当前值 | 上期值 | 环比变化 | 目标值 | 状态 |\n|---------|---------|--------|--------|---------|--------|------|\n| 北极星 | {指标} | {值} | {值} | {+/-X%} | {目标} | 达标/预警/异常 |\n| L1 | {指标} | {值} | {值} | {+/-X%} | {目标} | 达标/预警/异常 |\n\n**整体健康判断**：{一句话总结}\n\n## 二、用户增长分析\n- DAU：{值}，环比{变化}\n- MAU：{值}，DAU/MAU比={粘性值}\n- 用户构成：新增{X}% / 活跃留存{Y}% / 回流{Z}%\n\n## 三、留存分析\n| 留存指标 | 当前值 | 上期值 | 行业基准 | 评估 |\n|---------|--------|--------|---------|------|\n\n## 四、转化漏斗\n| 步骤 | 到达人数 | 转化率 | 环比变化 | 是否瓶颈 |\n|------|---------|--------|---------|---------|\n\n**瓶颈诊断**：{描述}\n\n## 五、实验/功能效果（如有）\n| 实验名称 | 主指标变化 | 显著性 | 结论 |\n|---------|----------|--------|------|\n\n## 六、OKR进度\n| KR | 目标 | 当前 | 进度 | 风险 |\n|----|------|------|------|------|\n\n## 七、异动归因\n| 异常指标 | 变化幅度 | 起始时间 | 归因 | 信心度 |\n|---------|---------|---------|------|--------|\n\n## 八、关键洞察\n1. {洞察1：发现+数据+意义}\n2. {洞察2}\n3. {洞察3}\n\n## 九、行动建议\n| 优先级 | 行动项 | 关联指标 | 预期效果 | 负责方 |\n|--------|--------|---------|---------|--------|\n```\n\n## 复盘节奏指南\n\n| 复盘类型 | 频率 | 时长 | 参与者 | 重点 |\n|---------|------|------|--------|------|\n| **周复盘** | 每周一 | 15-30分钟 | 产品经理 | 北极星+异动+实验进展 |\n| **月复盘** | 每月初 | 30-60分钟 | 产品团队 | 全L1指标+留存+漏斗+OKR进度 |\n| **季度复盘** | 季度末 | 60-90分钟 | 产品+运营+技术 | 战略复盘+OKR评分+下季度规划 |\n\n## 质量标准\n\n1. 指标定义清晰——每个指标附计算口径说明\n2. 数据有对比——当前值必须对比上期、同期或目标\n3. 归因有证据——不能仅凭相关性断定因果\n4. 建议可执行——行动项具体到可分配到人\n5. 标注数据局限——样本量不足或数据质量问题明确说明\n\n## 指标分析常见陷阱\n\n| 陷阱 | 表现 | 正确做法 |\n|------|------|---------|\n| **辛普森悖论** | 整体指标上升，但每个分群都在下降 | 永远做分群对比，不只看总体 |\n| **幸存者偏差** | 只看留存用户的数据，忽略流失用户 | 对比留存vs流失用户的行为差异 |\n| **虚荣指标** | 累计注册数只升不降，但无法指导决策 | 用活跃指标（DAU/WAU）替代累计指标 |\n| **时间窗口陷阱** | 选的对比时间段正好是异常点 | 多看几个时间窗口交叉验证 |\n| **Goodhart定律** | 指标成为目标后就不再是好的度量 | 设置护栏指标防止刷量 |\n\n## 红线规则\n\n1. **不编造数据**：没有的数据标注\"缺失\"，不做猜测填充\n2. **不混淆相关与因果**：归因必须说明是\"高度相关\"还是\"确认因果\"\n3. **不过度乐观**：指标小幅波动不要过度解读，标注\"属于正常波动\"\n4. **不忽略负面信号**：即使整体向好，也要指出潜在风险\n\n## 输入不足处理\n\n- **仅提供单一指标**：聚焦该指标的异动分析，不做全面复盘\n- **无历史数据**：仅分析当前快照，标注\"缺乏对比基线，建议建立持续追踪\"\n- **口头描述数据**：基于描述进行分析，但标注\"建议补充精确数据验证\"\n- **缺乏目标值**：提供行业基准作为参考，建议团队设定明确目标\n\n## 关联Skill\n\n- **用户反馈分析** — 指标异动时结合用户反馈定性理解原因\n- **需求优先级排序** — 基于指标复盘结果调整需求优先级\n- **路线图更新** — 基于OKR进度调整路线图规划\n- **产品脑暴** — 基于指标瓶颈发散优化方案\n- **竞品分析** — 指标异动可能与竞品动作有关，交叉验证\n- **PRD生成** — 基于数据洞察转化为功能需求PRD\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|-----------------|\n| 数据获取与整理 | 数据文件解析失败或格式不支持 | 提示用户重新上传标准格式（Excel/CSV），并给出模板示例 | 2次 | 接受口头描述数据，标注\"基于描述分析，建议补充精确数据\" |\n| 北极星指标体系构建 | 无法从数据中识别北极星指标 | 根据产品类型从推荐表中选默认北极星，标注\"[假设北极星]\" | 1次 | 输出多个候选指标，由用户确认主指标 |\n| 用户增长指标分析 | 用户分层数据缺失无法拆解 | 仅分析总量指标，标注\"缺少分层数据，未做用户构成分析\" | 1次 | 建议用户补充新增/活跃/回流/流失的分层数据 |\n| 留存分析 | 留存数据缺失或时间维度不足 | 跳过留存曲线诊断，仅输出当前快照 | 1次 | 标注\"无留存数据，建议建立D1/D7/D30持续追踪\" |\n| 转化漏斗分析 | 漏斗步骤数据不完整 | 基于已知步骤绘制部分漏斗，标注缺失步骤 | 1次 | 建议用户补充完整漏斗各步骤数据 |\n| A/B实验解读 | 实验未达样本量或无显著性 | 标注\"结果不确定，不应据此决策\"，不做结论推断 | 1次 | 建议延长实验周期或扩大样本量后重新分析 |\n| OKR对齐检查 | 团队OKR未提供 | 跳过OKR对齐章节，标注\"未提供OKR，跳过进度评估\" | 1次 | 建议用户提供团队OKR以完成对齐检查 |\n| 指标异动归因 | 异动原因无法通过维度拆解定位 | 输出\"归因未明\"并列出已排除的可能原因 | 2次 | 建议结合用户反馈分析和定性调研进一步归因 |\n| 生成复盘报告 | 关键章节因数据缺失无法完整输出 | 输出已分析部分，缺失章节标注\"[数据缺失，待补充]\" | 1次 | 交付部分复盘报告，标注未完成章节及所需数据 |\n\nFile v0.1.0:references/requirement-prioritization.md\n\n# 需求优先级排序\n\n使用结构化框架对需求进行优先级排序。内置框架选择决策树——RICE适合有数据的量化决策，MoSCoW适合快速对齐，Kano适合功能分类。输出透明可追溯的排序结果和Sprint规划建议。\n\n## 跨技能联动\n\n本技能可与其他产品管理技能联动使用。典型工作流：先用 `用户反馈分析` 收集痛点 → 用 `竞品分析` 评估市场机会 → 用 `PRD生成` 编写需求文档 → 最后用本技能（`需求优先级排序`）对需求池进行排序。\n\n联动场景示例：\n- 从 `用户反馈分析` 的 Top 10 痛点直接导入为待排序需求\n- 从 `竞品分析` 的\"追平层\"功能清单导入为待排序需求\n- 排序完成后，高优先级需求流转到 `PRD生成` 撰写详细需求文档\n- 从 `产品脑暴` 输出的创意清单导入为待评估需求\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | 排序决策记录写入团队知识库，保留决策可追溯性 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 需求列表 | 是 | 需求名称+简要描述，至少3个。可直接引用 `用户反馈分析` 的痛点排序结果或 `PRD生成` 的需求列表作为输入 |\n| 排序框架 | 否 | RICE/ICE/MoSCoW/Kano，未指定则自动推荐 |\n| 业务目标 | 否 | 当前核心目标（增长/留存/营收/效率），影响权重分配 |\n| 资源约束 | 否 | 本Sprint/季度可用的开发资源（人天或Story Points） |\n\n## 执行流程\n\n### 第一步：框架选择\n\n如果用户未指定框架，按以下逻辑推荐：\n\n**框架选择决策表**：\n\n| 条件 | 推荐框架 | 理由 |\n|------|---------|------|\n| 有各需求的用户影响数据（DAU、转化率等），且数据可信 | **RICE** | 最量化、最可追溯 |\n| 有一定感知但缺乏精确数据 | **ICE** | 快速打分，容忍主观性 |\n| 需要快速分四档对齐优先级（适合团队会议） | **MoSCoW** | 逼出\"必须做\"和\"不做\"的共识 |\n| 需要理解需求性质，做功能规划 | **Kano** | 识别哪些功能能制造惊喜 |\n\n**四种框架对比**：\n\n| 框架 | 适用场景 | 核心优势 | 核心局限 | 耗时 |\n|------|---------|---------|---------|------|\n| **RICE** | 有数据支撑的季度规划 | 最客观，可横向对比 | 依赖数据质量 | 中 |\n| **ICE** | 快速决策、头脑风暴 | 简单快速 | 高度主观 | 低 |\n| **MoSCoW** | 版本规划、利益相关方对齐 | 逼出共识 | 容易全归Must Have | 低 |\n| **Kano** | 功能规划、用户满意度研究 | 识别惊喜功能 | 需用户调研数据 | 高 |\n\n### 第二步：需求评估\n\n**RICE 框架（默认）**：\n\n| 维度 | 含义 | 打分标准 | 常见错误 |\n|------|------|---------|---------|\n| **R**each | 一个周期内影响的用户数 | 填具体数字（如\"月影响5000人\"） | 把\"理论上所有用户\"当作Reach |\n| **I**mpact | 对单个用户的影响程度 | 3=巨大/2=高/1=中/0.5=低/0.25=极低 | 所有需求都打3分（过于乐观） |\n| **C**onfidence | 估算的信心程度 | 100%=有数据/80%=间接证据/50%=直觉 | 没数据也打100% |\n| **E**ffort | 所有人的总工作量（人月） | 含设计+开发+测试+联调 | 只算开发不算测试和联调 |\n\n**RICE Score = (R x I x C) / E**，分数越高优先级越高。\n\n**评分校准机制**：\n- 先对所有需求的同一维度集中打分（如先打完所有R，再打所有I），避免逐个需求打分导致的锚定偏差\n- R值校准：选一个基准需求（如\"登录功能\"影响所有用户），其他需求与之对比\n- I值校准：不允许超过50%的需求打3分，强制拉开差异\n- E值校准：必须包含设计(20%)+开发(50%)+测试(20%)+联调(10%)全链路\n\n**ICE 框架（快速版）**：\n\n每项1-10分打分，ICE Score = I x C x E / 10\n\n| 维度 | 打分标准 |\n|------|---------|\n| **I**mpact（影响） | 1=几乎无影响，5=中等，10=根本性改变 |\n| **C**onfidence（信心） | 1=纯猜测，5=有间接证据，10=有A/B测试数据 |\n| **E**ase（容易度） | 1=极难（>3个月），5=中等（2-4周），10=极易（<1天） |\n\n**MoSCoW 框架**：\n\n| 分类 | 判断标准 | 占比建议 |\n|------|---------|---------|\n| **Must Have** | 没有就不能上线，砍了用户无法使用核心功能 | <=60% |\n| **Should Have** | 重要但有workaround，延期一个Sprint不会致命 | ~20% |\n| **Could Have** | 锦上添花，有了更好，没有也行 | ~10% |\n| **Won't Have (this time)** | 明确不做，但未来可能做 | ~10% |\n\n> **常见陷阱**：所有需求都被归为Must Have。对策：限定Must Have不超过总需求的60%，逼出取舍。\n\n**Kano 模型**：\n\n| 需求类型 | 特征 | 识别方法 | 产品策略 |\n|---------|------|---------|---------|\n| **基本型（Must-be）** | 没有会不满，有了觉得理所当然 | 用户不主动提，但缺失会差评 | 必须做到及格线，但不值得过度投入 |\n| **期望型（One-dimensional）** | 做得越好满意度越高，线性关系 | 用户主动提的需求多属于此类 | 核心竞争力，做到行业前列 |\n| **兴奋型（Attractive）** | 没有不会不满，有了会惊喜 | 用户想不到但体验到会\"Wow\" | 差异化亮点，但会随时间退化为期望型 |\n| **无差异型（Indifferent）** | 有没有都无所谓 | 用户对此无反应 | 不投入 |\n| **反向型（Reverse）** | 做了反而降低满意度 | 增加复杂度、打扰用户 | 立即移除 |\n\n**Kano退化定律**：今天的兴奋型需求，2-3年后会退化为期望型甚至基本型（如手机指纹解锁从兴奋变基本）。所以必须持续创造新的兴奋型功能。\n\n### 第三步：排序输出\n\n**RICE排序结果表**：\n\n| 排名 | 需求 | R(触达) | I(影响) | C(信心) | E(工作量) | RICE Score | 建议 |\n|-----|------|---------|---------|---------|----------|-----------|------|\n| 1 | {需求名} | {数字} | {0.25-3} | {50-100%} | {人月} | {分数} | 本期必做 |\n\n**四象限分析（影响 x 工作量）**：\n\n| 象限 | 影响 | 工作量 | 策略 | 需求列表 |\n|------|------|--------|------|---------|\n| **Quick Wins** | 高 | 低 | 优先做 | {列表} |\n| **Strategic** | 高 | 高 | 规划做 | {列表} |\n| **Fill-ins** | 低 | 低 | 有空就做 | {列表} |\n| **Avoid** | 低 | 高 | 不做 | {列表} |\n\n**Sprint规划建议**：\n- 按资源约束分配需求到Sprint\n- Quick Wins优先填入，Strategic按Score排序分配\n- 每个Sprint留10-20%缓冲应对突发需求\n\n### 第四步：决策记录\n\n输出排序决策记录：\n- **核心取舍**：本期选了A不选B的原因是什么\n- **争议需求**：哪些需求的排序可能有争议，争议点是什么\n- **信心标注**：哪些评分的信心较低（C<80%），建议做什么来验证\n- **下期候选**：本期Won't Have中，下期最可能晋升的需求\n\n### 第五步：写入文档（如已连接）\n\n**如果连接了Notion：**\n1. 将排序结果和决策记录写入团队知识库\n\n**如果未连接：**\n1. 以Markdown格式输出完整排序结果\n\n## 质量标准\n\n1. 评分标准透明——每项评分有一句话依据\n2. Effort评估含设计+开发+测试+联调全链路\n3. Confidence<80%的需求标注\"建议先做小实验验证\"\n4. Must Have不超过总需求的60%\n5. 评分经过校准机制验证，避免锚定偏差\n\n## 红线规则\n\n1. **不替代决策**：排序结果是建议而非决定，最终优先级需团队对齐\n2. **不隐藏假设**：所有评分的假设前提必须显式标注\n3. **不忽略Effort**：禁止只看Impact不看Effort就推荐\"必做\"\n\n## 输入不足处理\n\n- **需求列表不足3个**：仍然排序，但提醒\"样本过少，建议补充更多需求\"\n- **缺乏数据**：自动切换到ICE或MoSCoW，标注\"因缺乏量化数据，使用定性排序框架\"\n- **未指定业务目标**：按通用权重排序，建议用户补充以获得更精准结果\n\n## 关联Skill\n\n- **PRD生成** — 排序确认后，Must Have需求撰写详细PRD\n- **用户故事拆解** — 排序完成后高优先级需求拆解为User Story\n- **用户反馈分析** — 反馈中提取的功能需求导入为待排序需求\n- **竞品分析** — 竞品功能补齐清单导入为待排序需求\n- **产品脑暴** — 脑暴创意清单导入为待评估需求\n- **路线图更新** — 排序结果影响路线图的需求排期调整\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|------------------|\n| 第一步：框架选择 | 需求特征不明确无法推荐合适框架 | 默认使用ICE框架（最快速），标注\"未明确需求特征，使用ICE快速排序\" | 1次 | 输出ICE排序结果，建议用户补充信息后切换RICE做精细排序 |\n| 第二步：需求评估 | 缺乏数据导致RICE的Reach/Impact无法量化 | 降级为ICE定性打分，标注\"缺乏量化数据，使用定性评估\" | 2次 | 切换到MoSCoW框架做快速分类，标注\"数据不足，仅做定性排序\" |\n| 第三步：排序输出 | 需求间评分差异过小无法有效区分 | 增加校准环节（重新集中打分），标注\"评分接近，需二次校准\" | 2次 | 输出排序但标注\"部分需求优先级接近，建议团队讨论决定\" |\n| 第四步：决策记录 | 排序结果存在明显争议 | 在决策记录中标注争议点和各方观点，不做单方面裁定 | 1次 | 输出排序结果 + 争议清单，标注\"需团队对齐后确认最终排序\" |\n| 第五步：写入文档 | Notion连接失败 | 以Markdown格式输出完整结果，标注\"未连接Notion，请手动录入\" | 1次 | 输出Markdown格式结果，标注\"待Notion恢复后手动同步\" |\n\n## 输出格式\n\n```markdown\n# 需求优先级排序结果\n\n**分析日期**：[YYYY-MM-DD] **框架**：[RICE/MoSCoW/Kano] **业务目标**：[目标描述]\n\n## RICE 排序结果\n\n| 排名 | 需求 | R(触达) | I(影响) | C(信心) | E(工作量/人月) | RICE Score | 建议 |\n|-----|------|---------|---------|---------|---------------|-----------|------|\n| 1 | {需求名称} | {月活用户数} | {0.25/0.5/1/2/3} | {50-100%} | {设计+开发+测试+联调} | {(R\\*I\\*C)/E} | 本期必做 |\n| 2 | {需求名称} | {月活用户数} | {0.25/0.5/1/2/3} | {50-100%} | {设计+开发+测试+联调} | {(R\\*I\\*C)/E} | 下期候选 |\n\n**评分说明**：\n- Reach: 预估月活用户触达数（如 5000人）\n- Impact: 3=巨大/2=高/1=中/0.5=低/0.25=极小\n- Confidence: 100%=有数据支撑/80%=有行业基准/50%=直觉估算\n- Effort: 含设计+开发+测试+联调的全链路人月\n\n## 影响 × 工作量四象限\n\n| 象限 | 策略 | 需求列表 |\n|------|------|---------|\n| Quick Wins（高影响+低工作量） | 优先做 | {需求1, 需求2} |\n| Strategic（高影响+高工作量） | 规划做 | {需求3} |\n| Fill-ins（低影响+低工作量） | 有空做 | {需求4} |\n| Avoid（低影响+高工作量） | 不做 | {需求5} |\n\n## Sprint 规划建议\n\n| Sprint | 需求 | 工作量(人天) | 累计工作量 |\n|--------|------|------------|-----------|\n| Sprint 1 | {Quick Win需求} | {X}人天 | {Y} / {团队产能} |\n| Sprint 2 | {Quick Win + Stretch} | {X}人天 | {Y} / {团队产能} |\n\n## 决策记录\n\n**核心取舍**：本期选[{需求A}]不选[{需求B}]的原因是[{理由}]\n**争议需求**：[{需求C}]的评分可能有争议，争议点在于[{争议点}]\n**低信心需求**：[{需求D}]的Confidence<80%，建议[{验证方式}]\n**下期候选**：本期Won't Have中[{需求E}]最可能在下期晋升\n\n## Kano 分类（如使用）\n\n| 需求 | Kano类型 | 策略建议 |\n|------|---------|---------|\n| {需求A} | 期望型 | 核心投入，做到行业前列 |\n| {需求B} | 兴奋型 | 差异化亮点，标注退化时间窗口 |\n| {需求C} | 基本型 | 做到及格线即可 |\n```\n\nFile v0.1.0:references/roadmap-update.md\n\n# 路线图更新\n\n汇总当前迭代状态、评估里程碑进度、追踪优先级变更和依赖关系，输出路线图状态总览和未来规划建议。帮助产品经理保持路线图的时效性和可执行性。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | 路线图报告写入团队知识库 |\n| **Linear** | 拉取Project/Cycle状态和Issue进度 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 迭代状态 | 是 | 当前迭代的任务完成情况（手动输入或从 Linear 自动拉取） |\n| 路线图范围 | 否 | 本季度/本半年/本年，默认\"本季度\" |\n| 变更事项 | 否 | 需要调整优先级或时间线的事项及原因 |\n| 依赖信息 | 否 | 跨团队依赖、技术依赖的当前状态 |\n\n## 执行流程\n\n### 第一步：获取当前状态\n\n**如果连接了项目管理（Linear）：**\n1. 自动拉取当前Sprint/迭代的任务列表\n2. 按状态分类：已完成/进行中/未开始/阻塞\n3. 计算完成率和燃尽进度\n\n**如果未连接：**\n1. 请用户提供当前迭代的任务列表和状态\n2. 接受任何格式：列表、表格、截图、口头描述\n\n### 第二步：迭代状态汇总\n\n**当前迭代总览**：\n\n| 维度 | 数据 |\n|------|------|\n| 迭代名称/周期 | {Sprint X / 日期范围} |\n| 计划任务数 | {N}个 |\n| 已完成 | {X}个（{X/N%}） |\n| 进行中 | {Y}个 |\n| 未开始 | {Z}个 |\n| 阻塞/延期 | {W}个 |\n| 预计按时交付率 | {估算%} |\n\n**延期任务分析**（如有）：\n\n| 任务 | 原计划完成 | 预计完成 | 延期原因 | 影响评估 |\n|------|----------|---------|---------|---------|\n| {任务名} | {日期} | {日期} | {原因} | 是否影响里程碑 |\n\n**延期根因分类（五类归因法）**：\n\n| 根因类别 | 典型表现 | 改进方向 |\n|---------|---------|---------|\n| **需求变更** | 开发中途改需求、增加scope | 加强需求冻结机制，变更走审批 |\n| **估算偏差** | 实际工作量远超预估 | 引入历史数据校准，增加Buffer |\n| **技术风险** | 方案不可行、性能瓶颈、技术债阻碍 | 前置技术调研Spike |\n| **依赖阻塞** | 等其他团队/第三方/审批 | 依赖前置2周预警机制 |\n| **人力变动** | 请假、离职、临时抽调 | 容量规划留20%缓冲 |\n\n> 如果同类延期原因连续出现3次以上，应升级为流程改进项。\n\n### 第三步：里程碑进度评估\n\n| 里程碑 | 目标日期 | 关键交付物 | 当前进度 | 状态 | 风险项 |\n|--------|---------|----------|---------|------|--------|\n| {里程碑1} | {日期} | {交付物} | {X%} | 按时/有风险/延迟 | {风险描述} |\n\n**里程碑状态判断标准**：\n- **按时**：进度>=时间进度，无阻塞依赖\n- **有风险**：进度略落后或有未解决的依赖\n- **延迟**：进度严重落后或关键依赖阻塞\n\n### 第四步：优先级变更记录\n\n| 变更项 | 变更类型 | 原优先级 | 新优先级 | 变更原因 | 影响范围 |\n|--------|---------|---------|---------|---------|---------|\n| {需求/任务} | 提升/降低/新增/移除 | {P0/P1/P2} | {P0/P1/P2} | {原因} | {影响了什么} |\n\n**变更原因分类**：\n- 用户反馈驱动（从 `用户反馈分析` 获得新信息）\n- 竞品动态驱动（从 `竞品分析` 发现紧迫性变化）\n- 数据驱动（从 `产品指标复盘` 发现指标问题）\n- 资源变化（团队人力变动、技术方案变更）\n- 外部因素（政策合规要求、合作方需求）\n\n### 第五步：依赖关系追踪\n\n| 依赖项 | 类型 | 依赖方/提供方 | 需要日期 | 当前状态 | 风险等级 |\n|--------|------|------------|---------|---------|---------|\n| {依赖描述} | 技术/团队/外部 | {谁依赖谁} | {日期} | 已解决/进行中/阻塞 | 高/中/低 |\n\n**依赖类型**：\n- **技术依赖**：底层服务、API接口、基础设施\n- **跨团队依赖**：其他业务线、设计团队、数据团队\n- **外部依赖**：第三方服务、合作伙伴、审批流程\n\n### 第六步：未来规划建议\n\n基于当前状态，对未来2-3个迭代给出规划建议：\n\n**路线图视图（Now / Next / Later）**：\n\n| 时间段 | 事项 | 优先级 | 信心度 | 依赖 |\n|--------|------|--------|--------|------|\n| **Now**（当前迭代） | {进行中的工作} | 确定 | 高 | {已解决} |\n| **Next**（下1-2个迭代） | {已规划的工作} | 确定/待定 | 中-高 | {需跟进} |\n| **Later**（3+迭代后） | {方向性规划} | 方向性 | 低-中 | {待评估} |\n\n**容量评估**：\n- 下个迭代可用人力：{X}人天\n- 建议分配：70%计划功能 + 20%技术债务 + 10%缓冲\n- 结合当前延期项，建议下期优先处理：{列表}\n\n**路线图健康度评分**（每次更新时计算）：\n\n| 维度 | 权重 | 评分标准 | 得分 |\n|------|------|---------|------|\n| 按时交付率 | 30% | >80%=5分, 60-80%=3分, <60%=1分 | {X} |\n| Scope稳定度 | 20% | 变更<10%=5分, 10-30%=3分, >30%=1分 | {X} |\n| 依赖解决率 | 20% | >90%=5分, 70-90%=3分, <70%=1分 | {X} |\n| OKR对齐度 | 15% | 所有工作可追溯到OKR=5分 | {X} |\n| 团队信心 | 15% | 团队认为能按时交付=5分 | {X} |\n\n**综合健康度**：加权总分 >=4分健康 / 3-4分有风险 / <3分需紧急调整\n\n**Feature Cut决策框架**（当容量不足时的砍需求原则）：\n\n| 优先砍的 | 原因 | 条件 |\n|---------|------|------|\n| Nice-to-have 功能 | 不影响核心价值 | 直接砍 |\n| 可拆分功能的后半段 | 先交付MVP | 确认MVP独立可用 |\n| 技术完美度 | 先能用再优化 | 不引入不可逆技术债 |\n| 低置信度需求 | 未被验证的假设 | 标注\"移入下期验证\" |\n\n> 原则：砍scope优于延期，延期优于加人（Brook's Law：向延期项目增加人手只会让它更延期）。\n\n### 第七步：输出报告\n\n**如果连接了Notion：**\n1. 将路线图更新报告写入团队知识库\n\n**如果未连接：**\n1. 以Markdown格式输出完整报告\n\n## 输出格式\n\n```markdown\n# 路线图更新报告\n\n**更新日期**：{日期}\n**覆盖周期**：{本季度/本半年}\n**当前迭代**：{Sprint名称/日期}\n\n## 一、当前迭代状态\n完成率：{X%}（{已完成}/{总数}）\n阻塞项：{N}个\n\n## 二、里程碑进度\n| 里程碑 | 目标日期 | 进度 | 状态 |\n|--------|---------|------|------|\n\n## 三、优先级变更\n| 变更项 | 变更说明 | 原因 |\n|--------|---------|------|\n\n## 四、依赖与风险\n- 高风险依赖：{描述}\n- 需协调事项：{描述}\n\n## 五、路线图视图（Now/Next/Later）\n（表格）\n\n## 六、下一步建议\n1. {建议1}\n2. {建议2}\n3. {建议3}\n```\n\n## 质量标准\n\n1. 状态信息准确——延期任务标明具体原因和预计完成时间\n2. 里程碑评估有据——不用\"差不多\"\"快了\"等模糊表述\n3. 变更有追溯——每次优先级调整记录原因和决策人\n4. 风险提前预警——不等问题发生才报告\n5. 建议具体可行——下一步行动明确到人\n6. 健康度评分持续追踪——可观察改善趋势\n\n## 路线图沟通指南\n\n不同受众需要不同粒度和视角的路线图信息：\n\n| 受众 | 关注点 | 呈现方式 | 更新频率 |\n|------|--------|---------|---------|\n| **CEO/VP** | 战略方向、里程碑、风险 | Now/Next/Later高层视图 | 月度 |\n| **研发团队** | Sprint任务、依赖、技术细节 | 详细任务列表+依赖图 | 每日/每周 |\n| **销售/客户成功** | 客户承诺的功能、ETA | 功能上线时间线 | 月度 |\n| **外部客户** | 即将推出的能力 | 季度主题（不承诺具体日期） | 季度 |\n\n**路线图沟通三不原则**：\n1. 不对外承诺具体日期——只承诺\"Q2\"不承诺\"4月15日\"\n2. 不隐藏延期信息——早报比晚报好\n3. 不把路线图当承诺——路线图是计划，计划会变\n\n## 红线规则\n\n1. **不隐瞒延期**：有延期如实报告，不报喜不报忧\n2. **不做虚假承诺**：对未来时间线不过度乐观\n3. **不忽略依赖**：跨团队依赖必须显式追踪\n\n## 输入不足处理\n\n- **无具体任务列表**：请用户至少提供里程碑和关键交付物的状态\n- **不清楚优先级变更**：仅输出当前状态汇总，标注\"建议补充变更记录\"\n- **首次使用无历史数据**：帮助建立路线图基线框架\n\n## 关联Skill\n\n- **需求优先级排序** — 路线图中的需求重新排序\n- **产品指标复盘** — 指标复盘结果影响路线图调整方向\n- **产品脑暴** — 路线图中创新方向探索\n- **用户反馈分析** — 用户反馈趋势影响路线图优先级调整\n- **竞品分析** — 竞品动态影响路线图竞争策略调整\n- **PRD生成** — 路线图确认的需求撰写PRD\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|------------------|\n| 第一步：获取当前状态 | Linear连接失败或未配置 | 请用户手动提供迭代任务列表和状态，接受任何格式 | 2次 | 基于用户口头描述做状态汇总，标注\"数据为人工提供，需核实\" |\n| 第二步：迭代状态汇总 | 任务状态信息不完整 | 基于已有信息做部分汇总，标注\"部分任务状态未知\" | 1次 | 输出已确认部分的状态汇总，标注\"需补齐任务状态后完善\" |\n| 第三步：里程碑进度评估 | 里程碑定义不清晰或缺失 | 基于已有交付物做进度评估，标注\"里程碑定义不完整\" | 1次 | 输出当前可见的进度评估，建议用户明确里程碑定义 |\n| 第四步：优先级变更记录 | 无变更记录或变更原因不明 | 仅输出当前状态汇总，标注\"无变更记录，建议补充\" | 1次 | 跳过变更分析，标注\"变更记录缺失，无法追溯优先级调整\" |\n| 第五步：依赖关系追踪 | 依赖信息未提供 | 标注\"依赖信息缺失\"，仅输出已知的依赖 | 1次 | 输出已知依赖，标注\"需补充跨团队依赖信息\" |\n| 第六步：未来规划建议 | 历史数据不足无法做趋势预判 | 基于当前快照做短期规划建议，标注\"缺乏历史数据，仅做短期建议\" | 1次 | 输出框架版规划建议，标注\"待积累数据后完善长期规划\" |\n| 第七步：输出报告 | Notion连接失败 | 以Markdown格式输出完整报告，标注\"未连接Notion\" | 1次 | 输出Markdown格式报告，标注\"待Notion恢复后手动同步\" |\n\nFile v0.1.0:references/user-feedback-analysis.md\n\n# 用户反馈分析\n\n对用户反馈数据进行结构化分类、情感分析和模式提取，输出可驱动产品决策的洞察报告。内置反馈分类体系、痛点优先级排序模型、主题聚类方法和趋势分析框架。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | 洞察报告写入团队知识库 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 反馈数据 | 是 | Excel/CSV文件、粘贴文本、或应用商店评论截图 |\n| 分析目的 | 否 | 产品改进/满意度评估/专题分析（如某功能上线后的反馈），默认\"产品改进\" |\n| 时间范围 | 否 | 反馈收集的时间段，用于标注报告时效和趋势分析 |\n| 数据来源渠道 | 否 | 如有多渠道数据可标注来源，便于三角验证 |\n\n> **数据规模判断**：<=20条 → **精读模式**（逐条分析，输出详细解读）；>20条 → **统计模式**（自动分类统计，输出聚合报告）。\n\n## 执行流程\n\n### 第一步：数据预处理\n\n解析用户上传的文件或粘贴的文本。\n\n**数据清洗规则**：\n- 去除完全重复的反馈\n- 合并高度相似的反馈（相似度>90%），标注合并数量\n- 超短反馈（<5字且无实质内容，如\"好\"\"差\"）单独统计，不纳入深度分析\n- 若数据含评分列（1-10分或1-5星），自动提取用于NPS计算\n- 识别反馈来源渠道（微信客服、钉钉反馈群、App Store评论、小红书评论、知乎问答、飞书反馈表单、400热线工单等）\n\n### 第二步：反馈分类\n\n**反馈分类体系（6大类+判断标准）**：\n\n| 类别 | 判断标准 | 示例 |\n|------|---------|------|\n| **功能需求** | 用户希望有但目前没有的功能 | \"希望能支持批量导出\" |\n| **Bug报告** | 功能存在但表现异常 | \"点击保存后数据丢失了\" |\n| **使用咨询** | 不知道怎么用，找不到功能 | \"怎么修改密码？\" |\n| **体验吐槽** | 功能有但体验不好 | \"加载太慢了\"\"界面太复杂\" |\n| **正面评价** | 满意、好评、推荐 | \"这个功能很好用，推荐！\" |\n| **其他** | 无法归类或与产品无关 | 灌水、广告、无意义内容 |\n\n分类不确定时（一条反馈可能属于多类），标注主分类+次分类。\n\n### 第三步：情感分析\n\n每条反馈标注情感倾向：\n\n| 情感 | 判断信号 | 校准规则 |\n|------|---------|---------|\n| **正面** | 点赞、好评、推荐、感谢、表扬 | 仅表述事实的好评（\"功能可用\"）判为中性而非正面 |\n| **中性** | 陈述事实、提问、建议（语气平和） | 功能需求默认中性，除非带有明显不满语气 |\n| **负面** | 抱怨、愤怒、失望、威胁 | \"希望能支持XX\"是中性，\"为什么还不支持XX\"是负面 |\n\n**情感强度分级**（负面反馈额外标注）：\n- **轻度**：语气平和的不满（\"不太方便\"）\n- **中度**：明确表达失望（\"很失望\"\"体验很差\"）\n- **重度**：威胁性表达（\"再不修就卸载\"\"要投诉\"）→ 高优先级处理\n\n### 第四步：主题聚类\n\n运用两种方法对反馈进行主题聚类，提取核心议题：\n\n**方法一：亲和图法（Affinity Mapping）**\n\n1. **拆分观察点**：将每条反馈中的独立观点拆分为单独的\"卡片\"\n2. **自然聚类**：按相似性将卡片分组，不预设分类标签，让主题从数据中自然浮现\n3. **命名主题**：为每个聚类命名（如\"支付流程繁琐\"\"搜索结果不相关\"）\n4. **识别层级**：小聚类归入更大的主题群（如\"支付流程繁琐\"+\"退款周期长\" 归入\"交易体验\"主题）\n5. **标注异常值**：无法归入任何聚类的反馈单独标注——这些可能是早期信号\n\n**方法二：主题编码（Thematic Coding）**\n\n1. **开放编码**：逐条反馈标注描述性标签（如\"加载慢\"\"闪退\"\"找不到入口\"）\n2. **轴心编码**：将描述性标签归类为更抽象的主题（\"加载慢\"+\"闪退\" → \"性能问题\"）\n3. **选择性编码**：识别核心主题，建立主题之间的逻辑关系\n4. **量化频次**：统计每个主题被提及的次数和占比\n\n**聚类输出格式**：\n\n| 主题 | 子主题 | 提及次数 | 占比 | 代表性反馈 |\n|------|--------|---------|------|----------|\n| {主题1} | {子主题a} | {N} | {X%} | \"原文引用\" |\n\n### 第五步：NPS分析（如数据含评分）\n\n若反馈数据包含数字评分（1-10分制），自动计算NPS：\n- **推荐者**（9-10分）占比 - **贬损者**（0-6分）占比 = NPS分数\n- NPS基准参考：SaaS行业平均30-40，消费类App平均20-30\n- 5星制评分自动换算：5星=10分，4星=8分，3星=6分，2星=4分，1星=2分\n\n### 第六步：趋势分析（如有时间维度数据）\n\n当反馈数据包含时间信息时，进行趋势分析：\n\n**环比变化计算框架**：\n- 按周/月统计各类反馈的数量变化\n- 计算环比增长率 =（本期 - 上期）/ 上期 x 100%\n- 关注增长率>30%的异常变化，标注为\"需关注\"\n\n**趋势拐点识别**：\n- 监测连续3期以上的单方向变化（持续上升或持续下降）\n- 识别突然的方向反转（如负面反馈连续下降后突然上升）\n- 关联外部事件：版本发布、运营活动、竞品动态等可能的触发因素\n\n**趋势分析输出**：\n- 各类别反馈的时间变化曲线描述\n- 显著变化点标注及可能原因\n- 预警：哪些指标在恶化、哪些在改善\n\n### 第七步：三角验证\n\n当数据来自多个渠道时，通过交叉验证提升结论可信度：\n\n**方法论三角**：同一问题用不同分析方法验证\n- 如：主题聚类发现\"加载慢\"是Top1痛点 → 检查NPS贬损者的开放回答是否也集中在性能问题\n\n**来源三角**：同一发现在不同渠道的出现情况\n- 如：App Store差评提到\"闪退\" + 微信客服工单也反映\"闪退\" + 钉钉群用户也提到 → 高可信度\n- 仅单一渠道出现 → 标注\"单源发现，需进一步验证\"\n\n**时间三角**：同一问题在不同时间的持续性\n- 持续3周以上的问题 → 系统性问题\n- 仅在特定时间出现 → 可能是偶发或已修复\n\n**可信度分级**：\n| 等级 | 条件 | 标注 |\n|------|------|------|\n| **高** | 多渠道+多方法+持续出现 | 可直接驱动决策 |\n| **中** | 2种验证维度支持 | 建议补充数据后决策 |\n| **低** | 单一来源或单一方法 | 仅作参考，需进一步验证 |\n\n### 第八步：用户画像提炼\n\n从反馈数据中识别典型用户类型：\n\n**画像构建方法**：\n1. **行为聚类**：根据反馈内容推断用户类型（新手/老用户/高频用户/偶尔使用）\n2. **需求聚类**：哪些用户关注效率、哪些关注体验、哪些关注价格\n3. **情感聚类**：忠实拥护者 / 沉默使用者 / 积极抱怨者 / 流失边缘者\n\n**画像模板**：\n```\n[画像名称]：{一句话描述}\n- 典型特征：{使用频率、关注点、行为模式}\n- 核心诉求：{最关心什么}\n- 主要痛点：{遇到的问题}\n- 反馈风格：{倾向如何表达}\n- 占比估算：{在反馈数据中的比例}\n- 代表性原文：\"{引用}\"\n```\n\n> 画像数量控制在3-5个，过多则不具备行动指导意义。\n\n### 第九步：痛点排序\n\n**痛点优先级 = 频次 x 严重度 x 用户权重 x 可信度**\n\n| 维度 | 赋值标准 |\n|------|---------|\n| **频次** | 高频(>10次)=3, 中频(3-10次)=2, 低频(<3次)=1 |\n| **严重度** | 致命(功能不可用)=3, 严重(影响核心流程)=2, 一般(体验不佳但可用)=1 |\n| **用户权重** | 付费用户=1.5, 免费用户=1.0（如无用户类型数据则均为1.0） |\n| **可信度** | 高(三角验证通过)=1.2, 中=1.0, 低(单源)=0.8 |\n\n按综合分数降序排列，输出Top 10痛点。\n\n### 第十步：生成洞察报告\n\n**如果连接了Notion：**\n1. 将报告写入团队知识库指定位置\n\n**如果未连接：**\n1. 以Markdown格式输出完整报告\n\n## 输出格式\n\n```markdown\n# 用户反馈分析报告\n\n**分析期间**：{日期范围}\n**反馈总量**：{N}条（去重后{M}条）\n**数据来源**：{渠道列表，如\"App Store评论、微信客服工单、钉钉反馈群\"}\n\n## 一、分类统计\n| 类别 | 数量 | 占比 | 环比变化(如有) |\n|------|------|------|--------------|\n\n## 二、情感分布\n**正面**：{X}% | **中性**：{Y}% | **负面**：{Z}%\n（负面中：轻度{a}条 / 中度{b}条 / 重度{c}条）\n\n## 三、主题聚类\n| 主题 | 子主题 | 提及频次 | 占比 | 可信度 |\n|------|--------|---------|------|--------|\n\n## 四、NPS分析（如有评分数据）\n**NPS分数**：{分数}（推荐者{X}% - 贬损者{Y}%）\n**行业基准对比**：{高于/低于}行业平均{差值}分\n\n## 五、趋势分析（如有时间数据）\n- 显著上升趋势：{类别}，环比+{X}%\n- 显著下降趋势：{类别}，环比-{X}%\n- 拐点事件：{描述}\n\n## 六、Top 10 痛点\n| 排名 | 痛点描述 | 频次 | 严重度 | 可信度 | 综合分 | 代表性原文 | 产品建议 |\n|------|---------|------|--------|--------|--------|----------|---------|\n\n## 七、用户画像\n<!-- 3-5个典型画像 -->\n\n## 八、关键洞察\n<!-- 每条洞察格式：发现+数据佐证+可信度+意义 -->\n1. {洞察1}\n2. {洞察2}\n3. {洞察3}\n\n## 九、改进建议（按优先级排序）\n| 优先级 | 建议 | 关联痛点 | 预期效果 | 验证方式 |\n|--------|------|---------|---------|---------|\n\n## 十、统计说明\n- 分类置信度：{高/中}（样本量{N}条）\n- 存疑分类：{数量}条\n- 三角验证覆盖率：{X}%的发现经过多源验证\n- 统计有效性：{样本量充足/样本量有限，结论仅供参考}\n```\n\n## 质量标准\n\n1. 分类有据——不确定的分类标注置信度\n2. 洞察基于数据——每条洞察引用具体数字\n3. 改进建议可操作——具体到功能层面\n4. 样本量<50条时标注\"样本量有限，结论仅供参考\"\n5. 统计结果用代码执行计算，确保准确\n6. 情感判断经过校准规则验证\n7. 主题聚类结果互斥且完整（MECE）\n8. 三角验证明确标注可信度等级\n\n## 红线规则\n\n1. **不过度推断**：20条反馈中3条提到某问题，不能说\"大量用户反馈\"\n2. **保留原文**：痛点需附代表性原文，确保可追溯\n3. **不编造趋势**：无历史数据时不做环比分析\n4. **不虚构画像**：用户画像必须基于数据聚类结果，不能凭想象编造\n\n## 输入不足处理\n\n- **反馈数量<10条**：输出逐条详细解读，不做统计分析（样本太少无统计意义）\n- **无渠道/时间信息**：正常分析，但标注\"缺少数据来源和时间信息，建议补充\"；跳过趋势分析和三角验证\n- **混杂多语言反馈**：按语言分组分别分析\n- **单一渠道数据**：正常分析，但在报告中标注\"单一数据源，建议补充其他渠道数据进行交叉验证\"\n\n## 反馈量不足时的主动补充策略\n\n当可用反馈<30条时，分析价值有限。建议主动补充数据：\n\n| 补充方式 | 获取周期 | 适用场景 | 预期补充量 |\n|---------|---------|---------|----------|\n| 应用商店评论爬取 | 即时 | C端产品 | 50-500条 |\n| 客服工单导出 | 1天内 | 有客服体系的产品 | 100+条 |\n| 产品内嵌反馈弹窗 | 1-2周收集 | 需定向收集某功能反馈 | 视DAU定 |\n| 用户1v1访谈 | 1-2周 | 深度挖掘痛点 | 5-10人（质>量） |\n| 社交媒体监测 | 即时 | 用户自发讨论多的产品 | 不定量 |\n\n> 原则：先穷尽已有数据源再考虑新增收集，避免\"数据不够就做调研\"的冲动。\n\n## 反馈渠道参考\n\n中国互联网产品常见反馈渠道（按数据质量排序）：\n\n| 渠道 | 数据特点 | 适合分析维度 |\n|------|---------|------------|\n| **微信客服/企业微信** | 即时反馈，语境完整，可追问 | 深度痛点分析 |\n| **钉钉反馈群/飞书反馈群** | B端用户为主，需求明确 | 功能需求提炼 |\n| **App Store/应用宝评论** | 公开评分+文字，量大 | NPS计算、情感分析 |\n| **小红书评论/笔记** | 真实体验分享，含竞品对比 | 竞品感知、体验洞察 |\n| **知乎问答/讨论** | 深度讨论，专业用户 | 深层需求挖掘 |\n| **400热线/工单系统** | 结构化记录，紧急问题 | Bug和紧急痛点 |\n| **产品内嵌反馈入口** | 使用中即时反馈，场景明确 | 功能体验优化 |\n\n## 关联Skill\n\n- **需求优先级排序** — 将反馈中提取的功能需求用RICE排优先级\n- **PRD生成** — 高频需求转化为PRD\n- **竞品分析** — 反馈中的竞品提及进一步竞品研究\n- **产品指标复盘** — 反馈趋势与产品指标交叉验证\n- **产品脑暴** — 基于用户痛点发散改进创意\n- **用户故事拆解** — 将反馈驱动的需求拆解为可执行Story\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|-----------------|\n| 数据预处理 | 文件解析失败或数据量过大 | 提示用户分批上传或粘贴文本，单次上限500条 | 2次 | 接受原始文本逐条解析，标注\"未去重\" |\n| 反馈分类 | 反馈内容过短无法判断类别 | 归入\"其他\"类并标注\"[分类不确定]\" | 1次 | 输出存疑反馈清单供人工复核 |\n| 情感分析 | 反馈含反讽或混合情感难以判断 | 标注\"情感不确定\"并给出两种可能倾向 | 2次 | 降级为中性处理，不纳入负面统计 |\n| 主题聚类 | 反馈数量<10条无法有效聚类 | 跳过聚类，逐条输出分析 | 1次 | 标注\"样本不足，未做主题聚类\" |\n| NPS分析 | 数据无评分列无法计算NPS | 跳过NPS章节，标注\"无评分数据\" | 1次 | 建议用户补充评分数据或改用情感分析替代 |\n| 趋势分析 | 数据无时间维度无法做趋势分析 | 跳过趋势分析章节，标注\"缺少时间信息\" | 1次 | 建议用户补充反馈收集时间后重新分析 |\n| 三角验证 | 仅有单一渠道数据无法交叉验证 | 标注\"单一数据源，结论需进一步验证\" | 1次 | 建议补充其他渠道数据后重新验证 |\n| 用户画像提炼 | 反馈数据不足以构建画像 | 跳过画像章节，标注\"数据不足以提炼画像\" | 1次 | 输出已识别的用户类型线索，不强行构建完整画像 |\n| 痛点排序 | 痛点频次和严重度数据不足 | 仅按频次排序，标注\"缺少严重度评估\" | 1次 | 输出已识别痛点，不做综合评分排序 |\n| 生成洞察报告 | 关键章节因数据缺失无法输出 | 输出已完成部分，缺失章节标注\"[数据不足]\" | 1次 | 交付部分报告，标注局限性和建议补充的数据 |\n\nFile v0.1.0:references/user-story-breakdown.md\n\n# 用户故事拆解\n\n将大需求或Epic拆解为独立可交付的User Story，确保每个Story符合INVEST原则。内置5种拆分模式和Story Point估算参考，输出可直接录入Jira等工具。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | Story Map写入 Notion 数据库，结构化管理 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 需求描述 | 是 | Epic或大需求的描述，可粘贴PRD片段 |\n| 拆分粒度 | 否 | Sprint级（1-3天）/ 迭代级（1-2周），默认Sprint级 |\n| 团队构成 | 否 | 前后端分离/全栈/含移动端，影响按端拆分的决策 |\n| 估算体系 | 否 | Fibonacci（1/2/3/5/8/13）/ T-shirt（S/M/L/XL），默认Fibonacci |\n\n## 执行流程\n\n### 第一步：需求全貌梳理\n\n提取需求中的：\n- **涉及角色**：谁会用？（终端用户、管理员、运营...）\n- **核心流程**：主路径是什么？有哪些分支路径？\n- **业务规则**：有哪些约束和条件？\n- **数据实体**：涉及哪些数据对象？\n\n### 第二步：选择拆分模式\n\n**5种Story拆分模式（按需求特点选择）**：\n\n| 拆分模式 | 适用场景 | 示例 |\n|---------|---------|------|\n| **按工作流步骤** | 需求是一个完整流程 | 下单流程 → 选商品/填地址/选支付/确认订单 |\n| **按业务规则变体** | 同一功能有多种规则 | 优惠计算 → 满减/折扣券/积分抵扣/组合优惠 |\n| **按数据操作（CRUD）** | 需求围绕一个数据对象 | 地址管理 → 新增/编辑/删除/设为默认 |\n| **按角色视角** | 多角色使用同一功能 | 订单管理 → 用户看订单/商家处理订单/运营查数据 |\n| **按复杂度递进** | 功能有简单版和完整版 | 搜索 → 关键词搜索/筛选过滤/搜索建议/搜索历史 |\n\n> **选择原则**：先看需求像哪种模式，混合型需求组合使用。目标是每个Story可在1个Sprint内完成。\n\n**拆分粒度校准**：\n- 拆出的Story数量 < 3个 → 可能拆得太粗，检查是否有隐藏的子流程\n- 拆出的Story数量 > 20个 → 可能拆得太细或需求本身是多个Epic，建议先分Epic\n- 单个Story估算 > 8 Points → 粒度太大，需继续拆分\n\n### 第三步：编写User Story + AC\n\n每个Story使用以下格式：\n\n```\n### US-{编号}：{Story标题——动词开头，如\"选择支付方式\"}\n\n**角色**：作为{角色}\n**需求**：我希望{具体操作}\n**价值**：以便{业务价值}\n**优先级**：P0（必须）/ P1（重要）/ P2（Nice-to-have）\n**Story Points**：{估算值}\n\n**Acceptance Criteria**：\n- [ ] Given {前提条件}, When {操作}, Then {预期结果}\n- [ ] Given {异常前提}, When {操作}, Then {错误处理}\n\n**依赖**：{依赖的其他Story编号，无则写\"无\"}\n**技术备注**：{开发需要注意的点，可选}\n```\n\n**Story Point估算参考（Fibonacci体系）**：\n\n| 点数 | 复杂度 | 参考工作量 | 典型场景 |\n|------|--------|----------|---------|\n| 1 | 极简 | <0.5天 | 改文案、调配置、加埋点 |\n| 2 | 简单 | 0.5-1天 | 简单CRUD的一项、表单验证 |\n| 3 | 中等 | 1-2天 | 带业务逻辑的完整功能点 |\n| 5 | 较复杂 | 2-4天 | 涉及多个模块联动的功能 |\n| 8 | 复杂 | 4-7天 | 新系统/新流程的核心模块 |\n| 13 | 需再拆 | >1周 | 说明Story粒度太大，必须继续拆分 |\n\n**AC质量评估**：每条AC必须满足：\n- **具体**：Given中有明确的前置条件（如\"用户已登录且余额>=100元\"），而非\"用户已登录\"\n- **可测试**：Then中有可验证的结果（如\"余额减少100元且订单状态变为已支付\"），而非\"支付成功\"\n- **覆盖边界**：每个Story至少1条正常流程AC + 1条异常流程AC\n\n### 第四步：INVEST校验\n\n对每个Story逐项校验：\n\n| 原则 | 校验问题 | 不通过的处理 |\n|------|---------|------------|\n| **I**ndependent | 删掉这个Story，其他Story还能独立交付吗？ | 有循环依赖的Story需合并或重新拆分 |\n| **N**egotiable | Story描述的是\"做什么\"还是\"怎么做\"？ | 删掉实现细节，只保留用户价值描述 |\n| **V**aluable | 这个Story交付后，用户能感知到价值吗？ | 纯技术重构类Story需挂靠到用户可感知的功能上 |\n| **E**stimable | 团队能在5分钟内给出一致的Story Point吗？ | 估算分歧大说明需求不清，先澄清再估算 |\n| **S**mall | 一个Sprint内能完成吗？ | 超出的Story继续拆分 |\n| **T**estable | AC是否具体到QA可以直接写测试用例？ | 补充具体的边界值和预期结果 |\n\n不通过的项标注警告并建议修正方案。\n\n**Story Definition of Ready（进入开发前必须满足）**：\n\n| 检查项 | 标准 | 不满足时的处理 |\n|--------|------|------------|\n| AC完整 | 至少1正常+1异常流程AC | 补充AC后再排入Sprint |\n| 无阻塞依赖 | 所有前置Story已完成或可Mock | 标注\"Blocked\"并排入后续Sprint |\n| 设计稿就绪 | 涉及UI的Story有对应设计稿 | 无设计稿则标注\"需设计\" |\n| 估算共识 | 团队对Points估算分歧<2倍 | 重新讨论需求范围直到达成共识 |\n| 业务规则确认 | 所有\"[待确认]\"项已有结论 | 找PM/业务方确认后再开发 |\n\n**依赖关系判断规则**：\n- **数据依赖**：Story B需要Story A创建的数据 → B依赖A\n- **接口依赖**：Story B调用Story A提供的接口 → B依赖A\n- **无依赖**：两个Story操作不同数据对象或不同角色 → 可并行开发\n- **伪依赖**：看起来有依赖但可以用Mock数据解耦 → 标注\"可用Mock解耦\"\n\n### 第五步：输出Story Map\n\n**如果连接了Notion：**\n1. 将Story Map写入 Notion 数据库\n\n**如果未连接：**\n1. 以Markdown格式输出完整Story Map\n\n## 输出格式\n\n````markdown\n# Epic：[需求名称]\n\n**需求来源**：[PRD链接/用户反馈] **拆分日期**：[YYYY-MM-DD]\n\n## Story Map（用户旅程 → Story映射）\n\n| 用户旅程阶段 | Story ID | Story标题 | 优先级 | Points | 依赖 |\n|-------------|----------|----------|--------|--------|------|\n| 注册与登录 | US-001 | 手机号注册 | P0 | 3 | - |\n| 注册与登录 | US-002 | 微信授权登录 | P0 | 2 | - |\n| 内容浏览 | US-003 | 首页信息流 | P0 | 5 | US-001 |\n\n## INVEST 校验\n\n| Story ID | I(独立) | N(可谈判) | V(有价值) | E(可估算) | S(小) | T(可测试) | 通过 |\n|----------|---------|----------|----------|----------|-------|----------|------|\n| US-001 | ✅ | ✅ | ✅ | ✅(3pt) | ✅ | ✅ | ✅ |\n| US-002 | ✅ | ✅ | ✅ | ✅(2pt) | ✅ | ✅ | ✅ |\n\n## 验收条件（AC）示例 — US-001 手机号注册\n\n**正常流程**：\n- Given 用户未登录 When 输入有效手机号并获取验证码 Then 60秒内收到6位短信验证码\n- Given 已收到验证码 When 输入正确验证码并设置密码 Then 注册成功，跳转至首页\n\n**异常流程**：\n- Given 用户已注册 When 输入已注册手机号 Then 提示\"该手机号已注册，请直接登录\"\n- Given 验证码输入错误3次 When 再次提交 Then 锁定30秒并提示\"验证码错误次数过多，请30秒后重试\"\n\n## Sprint 规划建议\n\n| Sprint | 目标 | Story列表 | Points | 累计Points |\n|--------|------|----------|--------|-----------|\n| Sprint 1（MVP） | 核心注册+内容浏览闭环 | US-001, US-002, US-003 | 10 | 10 |\n| Sprint 2 | 社交互动功能 | US-004, US-005 | 8 | 18 |\n\n## 依赖关系图\n\n```\nUS-001 ──→ US-003 ──→ US-005\nUS-002 ──→ US-004 (可并行)\n```\n````\n\n## 质量标准\n\n1. 每个Story必须通过INVEST六项校验\n2. AC必须使用Given-When-Then格式，至少覆盖1个正常流程和1个异常流程\n3. Story之间的依赖关系需明确标注，并标注是否可用Mock解耦\n4. 估算为13点的Story必须继续拆分\n5. 输出的Story Map需包含Sprint规划建议\n\n## 输入不足处理\n\n- **仅一句话需求**：先输出功能全貌脑图，确认范围后再拆Story\n- **需求过大（超过20个Story）**：建议拆为多个Epic，先确定MVP范围\n- **缺少业务规则**：标注\"[业务规则待确认]\"，给出可能的规则假设供用户确认\n\n## 关联Skill\n\n- **PRD生成** — 先写PRD明确需求，再用本技能拆解为Story\n- **需求优先级排序** — Story数量多时，用RICE排序确定Sprint优先级\n- **用户反馈分析** — 从反馈中提取需求后拆解为Story\n- **竞品分析** — 竞品功能参考转化为Story\n- **产品指标复盘** — 基于指标优化方向拆解改进Story\n- **产品脑暴** — 需求发散后拆解为可执行Story\n\n## 失败回退机制\n\n| 步骤 | 失败条件 | 回退目标 | 最大重试 | 不可恢复时升级路径 |\n|------|---------|---------|---------|-----------------|\n| 需求全貌梳理 | 需求描述过于模糊无法提取角色和流程 | 输出\"需求澄清问卷\"引导用户补充 | 2次 | 建议用户先完成PRD再拆解Story |\n| 选择拆分模式 | 需求混合多种模式无法单一归类 | 组合使用多种模式，标注各模式适用的Story范围 | 1次 | 输出多种拆分方案供用户选择 |\n| 编写User Story + AC | 业务规则缺失无法编写完整AC | 标注\"[业务规则待确认]\"，给出规则假设供确认 | 2次 | 建议用户与业务方确认规则后再补全AC |\n| INVEST校验 | Story存在循环依赖无法通过I校验 | 标注依赖关系并建议合并或重新拆分 | 1次 | 输出依赖关系图，由用户决策拆分方案 |\n| 输出Story Map | Story数量过大无法放入单页 | 按Epic分组输出，标注各Epic的Story范围 | 1次 | 建议拆为多个Epic分别管理 |\n\nFile v0.1.0:skill-card.md\n\n## Description:\n\nProduct Management is a Chinese-language product management workflow suite for generating PRDs, brainstorming product ideas, reviewing metrics, analyzing user feedback, breaking down user stories, comparing competitors, updating roadmaps, and prioritizing requirements.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[ebandao777-oss](https://clawhub.ai/user/ebandao777-oss)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nProduct managers and product teams use this skill to route natural-language product-management requests to structured templates that produce PRDs, analysis reports, user stories, roadmap updates, and prioritization recommendations.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can handle confidential PRDs, metrics, feedback, and roadmaps and may persist that work to shared tools.\n\nMitigation: Require explicit confirmation before every connector read or write, especially for Notion, Figma, or Linear.\n\nRisk: The skill can update shared standards or templates without clear approval controls.\n\nMitigation: Route proposed updates through a reviewed draft process before changing shared standards or reusable templates.\n\nRisk: Product recommendations, competitive claims, and metric interpretations may be incorrect or stale.\n\nMitigation: Review generated reports against source data and verify current market facts before using them for decisions.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/ebandao777-oss/skills/product-management)\n- [Server-resolved GitHub source](https://github.com/ebandao777-oss/product-management)\n- [PRD generation template](artifact/references/prd-generation.md)\n- [Product brainstorming template](artifact/references/product-brainstorm.md)\n- [Product metrics review template](artifact/references/product-metrics-review.md)\n- [User feedback analysis template](artifact/references/user-feedback-analysis.md)\n- [User story breakdown template](artifact/references/user-story-breakdown.md)\n- [Competitive analysis template](artifact/references/competitive-analysis.md)\n- [Roadmap update template](artifact/references/roadmap-update.md)\n- [Requirement prioritization template](artifact/references/requirement-prioritization.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance]\n\n**Output Format:** [Markdown reports and structured tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May produce connector-backed drafts when the runtime has access to external tools.]\n\n## Skill Version(s):\n\n0.1.0 (source: server release metadata; artifact frontmatter reports 1.0.1)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.","readmeExcerpt":"Skill: product-management Owner: ebandao777-oss Summary: 产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。 PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"## 任务交付说明\n\n### 1. 子技能与路由\n- **匹配子技能**：（名称）\n- **路由依据**：（用户输入关键词/场景匹配）\n\n### 2. 执行摘要\n- **输入信息**：（用户提供的核心输入）\n- **执行过程**：（关键步骤简述）\n- **产出清单**：（交付物列表）\n\n### 3. 验证结论\n| 检查项 | 状态 | 备注 |\n|--------|:----:|------|\n| （逐条列出） | 通过/未通过 | （说明） |\n\n### 4. 风险与建议\n- **已知限制**：\n- **后续建议**：\n\n### 5. 复盘记录\n- **本次经验**：（可复用的处理模式/需注意的陷阱）"},{"language":"markdown","snippet":"## 任务启动信息\n- **任务目标**：（用户核心诉求，一句话描述）\n- **识别子技能**：（如有多个，列出优先级）\n- **输入完备性**：完备 / 缺失（列出缺失项）\n- **预期交付物**：\n- **验收条件**：\n- **预估轮次**：\n- **协同技能**：（如需跨包协作，列出）"},{"language":"markdown","snippet":"# 竞品分析报告：[分析目的]\n\n**分析日期**：[YYYY-MM-DD] **分析人**：[待填] **数据截至**：[YYYY-MM-DD]\n\n## 一、行业竞争格局\n\n| 竞争力量 | 评级 | 评估理由 |\n|---------|------|---------|\n| 供应商议价力 | 强/中/弱 | [一句话理由] |\n| 买家议价力 | 强/中/弱 | [一句话理由] |\n| 新进入者威胁 | 强/中/弱 | [一句话理由] |\n| 替代品威胁 | 强/中/弱 | [一句话理由] |\n| 行业竞争强度 | 强/中/弱 | [一句话理由] |\n\n**综合判断**：行业吸引力 高/中/低\n\n## 二、功能对比矩阵\n\n| 功能模块 | 子功能 | 我方 | 竞品A | 竞品B | 竞品C |\n|---------|--------|-----|------|------|------|\n| {模块1} | {子功能1} | ✅完善 | ✅完善 | ⚠️基础 | ❌无 |\n\n✅完善 / ⚠️基础 / ❌无 / 🔜规划中\n\n## 三、竞品 SWOT 分析\n\n### 竞品A：[名称]\n| | 正面 | 负面 |\n|---|------|------|\n| 内部 | S: [核心优势] | W: [明显短板] |\n| 外部 | O: [可利用机会] | T: [需警惕威胁] |\n\n## 四、竞品定位四象限\n\n| 象限 | 代表产品 |\n|------|---------|\n| 高功能+高价格 | [产品列表] |\n| 高功能+低价格 | [产品列表] |\n| 低功能+高价格 | [产品列表] |\n| 低功能+低价格 | [产品列表] |\n\n## 五、竞品战略推演\n\n| 竞品 | 近期关键动作 | 推断战略意图 | 对我方影响 | 信心度 | 建议应对 |\n|------|------------|------------|----------|--------|---------|\n| {竞品A} | {动作} | {意图} | {影响} | 高/中/低 | {策略} |\n\n## 六、定价对比（如适用）\n\n| 对比项 | 我方 | 竞品A | 竞品B | 竞品C |\n|--------|-----|------|------|------|\n| 免费版能力 | {范围} | {范围} | {范围} | {范围} |\n| 入门版月费 | {价格} | {价格} | {价格} | {价格} |\n| 企业版月费 | {价格} | {价格} | {价格} | {价格} |\n\n## 七、差异化策略\n\n| 层级 | 行动建议 | 优先级 |\n|------|---------|--------|\n| **追平层** | {竞品都有但我方缺失的功能} | P0/P1/P2 |\n| **差异层** | {我方独有或领先的功能} | P0/P1/P2 |\n| **创新层** | {蓝海功能方向} | P1/P2 |\n\n## 八、信息可信度说明\n\n| 竞品 | 信息可信度 | 主要来源 | 时效标注 |\n|------|----------|---------|---------|\n| {竞品A} | 高/中/低 | {来源} | {日期} |"},{"language":"markdown","snippet":"# PRD：{功能名称}\n\n**版本**：v1.0\n**作者**：{产品经理名，用户未提供则写\"[待填写]\"}\n**日期**：{当前日期}\n**状态**：草稿\n\n---\n\n## 1. 背景与目标\n\n### 1.1 背景\n<!-- 填充逻辑：回答三个问题——为什么现在做？不做会怎样？做了能怎样？ -->\n{问题现状 + 用户痛点 + 为什么现在是做的时机}\n\n<!-- 示例：客服团队每天处理 2000+ 重复性问题，人力成本月均 15 万，响应时长超 30 分钟。不做自动化将无法支撑 Q4 业务翻倍目标。上线后预计 60% 重复性问题可自助解决，年节省人力成本 120 万。 -->\n\n### 1.2 目标用户\n<!-- 填充逻辑：用\"[角色]+[特征]+[场景]\"的格式，不泛泛说\"所有用户\" -->\n| 用户角色 | 特征描述 | 核心诉求 | 使用场景 |\n|---------|---------|---------|---------|\n| （示例：坐席客服 | 日均处理50+工单 | 快速检索标准答案并一键回复 | 用户来电时边通话边查知识库） |\n\n### 1.3 业务目标与成功指标\n<!-- 填充逻辑：每个目标必须SMART化——有具体数字和截止时间 -->\n| 目标 | 衡量指标 | 目标值 | 监测方式 |\n|------|---------|--------|---------|\n| （示例：减少重复性人工处理 | 自助解决率 | ≥60%（上线3月内） | 客服系统统计） |\n\n<!-- 示例：| 减少重复性人工处理 | 自助解决率 | ≥60%（上线3月内） | 客服系统统计 | -->\n\n## 2. 需求概述\n<!-- 填充逻辑：一段话概括核心需求，30字以内 -->\n\n## 3. 功能详细设计\n\n### 3.1 {功能模块1}\n**功能描述**：{做什么}\n**用户故事**：作为{角色}，我希望{操作}，以便{价值}\n**优先级**：P0/P1/P2（P0=必须上线，P1=强烈建议，P2=锦上添花）\n\n**业务规则**：\n1. {规则1——写清楚触发条件和处理逻辑}\n2. {规则2}\n\n**交互流程**：\n<!-- 填充逻辑：从入口开始，写到任务完成，覆盖正常流程+异常分支 -->\n1. 用户从{入口}进入\n2. {操作步骤}\n3. 成功：{反馈}\n4. 失败：{错误提示和处理方式}\n\n**异常处理**：\n| 异常场景 | 处理方式 | 用户提示 |\n|---------|---------|---------|\n\n（后续模块同上格式）\n\n## 4. 非功能需求\n<!-- 填充逻辑：B2C 侧重性能和体验，B2B 侧重安全和可用性 -->\n| 类别 | 要求 | 验收标准 |\n|------|------|---------|\n| 性能 | {如：页面加载时间} | {如：<2秒} |\n| 安全 | {如：数据加密} | {如：传输层TLS 1.2+} |\n| 兼容性 | {如：浏览器/设备} | {如：Chrome/Safari/微信浏览器} |\n\n## 5. 数据需求\n<!-- 填充逻辑：列出所有需要采集的数据事件，用事件名+触发条件+属性格式 -->\n| 事件名 | 触发条件 | 关键属性 | 用途 |\n|--------|---------|---------|------|\n\n## 6. 验收标准\n<!-- 填充逻辑：每个功能模块至少3条AC，用Given-When-Then格式 -->\n| 编号 | 场景 | Given（前提） | When（操作） | Then（预期结果） |\n|------|------|-------------|-------------|-----------------|\n\n## 7. 排期建议\n<!-- 填充逻辑：拆到开发/测试/联调/上线四个阶段 -->\n| 阶段 | 预估工时 | 依赖 | 风险点 |\n|------|---------|------|--------|\n\n## 8. 风险与依赖\n| 风险 | 概率 | 影响 | 缓解措施 |\n|------|------|------|---------|\n\n## 附录\n- 相关文档链接\n- 竞品参考（详见 `competitive-analysis.md` 获取完整竞品分析方法与功能对比框架）\n- 设计稿地址"},{"language":"markdown","snippet":"# 产品脑暴记录\n\n**主题**：{脑暴问题}\n**HMW**：我们如何能{重述为HMW}\n**日期**：{日期}\n**产出创意数**：{N}个（筛选后保留{M}个）\n\n## 创意清单\n\n| 编号 | 创意描述 | 解决的痛点 | 来源框架 | 预期价值 | 实现难度 | 象限 | 下一步验证方式 |\n|------|---------|----------|---------|---------|---------|------|-------------|\n| 1 | {描述} | {痛点} | SCAMPER-消除 | 高/中/低 | 高/中/低 | Quick Win | {验证方式} |\n\n## Top 3 推荐创意\n\n### 创意1：{名称}\n- **描述**：{详细描述}\n- **解决的痛点**：{具体痛点}\n- **预期效果**：{量化预期，如\"预计提升次日留存5-10%\"}\n- **实现路径**：{简要技术/设计方案}\n- **验证方式**：{如何快速验证，如A/B测试、灰度发布}\n- **风险**：{可能的风险和应对}\n\n### 创意2：{名称}\n...\n\n### 创意3：{名称}\n...\n\n## 被放弃的创意（存档参考）\n- {创意X}：放弃原因——{原因}\n- {创意Y}：放弃原因——{原因}\n\n## 下一步行动\n- [ ] {行动1}\n- [ ] {行动2}"},{"language":"markdown","snippet":"# 产品指标复盘报告\n\n**复盘周期**：{日期范围}\n**产品名称**：{产品}\n**复盘类型**：{周复盘/月复盘/季度复盘}\n\n## 一、指标健康度总览\n\n| 指标层级 | 指标名称 | 当前值 | 上期值 | 环比变化 | 目标值 | 状态 |\n|---------|---------|--------|--------|---------|--------|------|\n| 北极星 | {指标} | {值} | {值} | {+/-X%} | {目标} | 达标/预警/异常 |\n| L1 | {指标} | {值} | {值} | {+/-X%} | {目标} | 达标/预警/异常 |\n\n**整体健康判断**：{一句话总结}\n\n## 二、用户增长分析\n- DAU：{值}，环比{变化}\n- MAU：{值}，DAU/MAU比={粘性值}\n- 用户构成：新增{X}% / 活跃留存{Y}% / 回流{Z}%\n\n## 三、留存分析\n| 留存指标 | 当前值 | 上期值 | 行业基准 | 评估 |\n|---------|--------|--------|---------|------|\n\n## 四、转化漏斗\n| 步骤 | 到达人数 | 转化率 | 环比变化 | 是否瓶颈 |\n|------|---------|--------|---------|---------|\n\n**瓶颈诊断**：{描述}\n\n## 五、实验/功能效果（如有）\n| 实验名称 | 主指标变化 | 显著性 | 结论 |\n|---------|----------|--------|------|\n\n## 六、OKR进度\n| KR | 目标 | 当前 | 进度 | 风险 |\n|----|------|------|------|------|\n\n## 七、异动归因\n| 异常指标 | 变化幅度 | 起始时间 | 归因 | 信心度 |\n|---------|---------|---------|------|--------|\n\n## 八、关键洞察\n1. {洞察1：发现+数据+意义}\n2. {洞察2}\n3. {洞察3}\n\n## 九、行动建议\n| 优先级 | 行动项 | 关联指标 | 预期效果 | 负责方 |\n|--------|--------|---------|---------|--------|"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: product-management\ndescription: |\n  产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。\n  PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano模型。\nversion: \"1.0.1\"\nauthor: \"智慧半岛\"\n---\n\n# product-management -- 产品管理综合技能\n\n本技能是一个综合技能套件，包含多个子技能。接到用户请求后，按以下流程执行。\n\n## 执行流程\n\n### Step 1: 意图识别与路由匹配\n\n分析用户输入，与下方路由表逐一比对。匹配规则：\n- 用户输入中包含路由表中「子技能」列的关键词 → 匹配该子技能\n- 用户输入中包含路由表中「功能说明」列中提到的场景 → 匹配该子技能\n- 多个子技能同时匹配时，选择匹配度最高的\n- 无法唯一确定时，向用户确认意图\n\n### Step 2: 加载子技能模板\n\n匹配到子技能后，根据子技能索引表找到对应的文件路径，**必须**使用 `read_text` 工具读取 `references/` 目录下的完整执行模板。\n\n### Step 3: 按模板执行\n\n严格按照加载的模板逐步执行。模板中定义了：\n- 输入要求（用户需要提供什么）\n- 执行步骤（每一步做什么、如何判断）\n- 输出格式（最终产出的结构和规范）\n- 质量标准（产出必须满足的底线）\n\n### Step 4: 输出结果\n\n按模板规定的格式输出结果。如果模板要求生成文件，写入后声明产出物。\n\n## 约束规则\n\n1. **必须先读模板再执行**：匹配到子技能后，严禁凭记忆或猜测执行，必须先读取对应的 references 文件\n2. **严格遵循模板**：不得跳过步骤、不得省略检查项、不得自行简化流程\n3. **输入不足时主动索取**：模板中标注「必填」的输入项缺失时，向用户索取\n4. **质量底线不妥协**：模板中的质量标准必须逐条满足\n\n## 本包特色\n\n- **方法论多样性**：需求优先级排序支持RICE/ICE/MoSCoW/Kano四种模型，根据输入数据特征自动推荐最优模型\n- **全链路协同**：PRD生成→竞品分析→用户故事拆解→路线图更新形成完整产品管理闭环\n- **数据驱动决策**：产品指标复盘、用户反馈分析两个子技能共同构成数据驱动产品迭代的基础设施\n\n## 路由表\n\n| 子技能 | 功能说明 |\n|--------|----------|\n| PRD生成 | 输入功能需求，生成含背景、目标、功能清单、交互设计的PRD文档。 |\n| 产品指标复盘 | 输入产品指标数据或时间周期，输出指标健康度评估、趋势分析、归因分析和行动建议。 |\n| 产品脑暴 | 围绕产品问题或机会点进行结构化创意发散，输出经过初步筛选的创意清单。 |\n| 用户反馈分析 | 上传用户反馈数据（Excel/CSV/文本），自动分类统计并提取高频模式... |\n| 用户故事拆解 | 从Epic或大需求中拆解出独立可交付的User Story... |\n| 竞品分析 | 输入竞品列表，输出功能对比矩阵、SWOT、五力分析和差异化策略。 |\n| 路线图更新 | 汇总迭代状态、评估里程碑进度、记录优先级变更... |\n| 需求优先级排序 | 输入需求列表，用RICE/ICE/MoSCoW/Kano模型辅助排序... |\n\n## 子技能索引\n\n| 子技能 | 英文标识 | 文件 |\n|--------|----------|------|\n| PRD生成 | `prd-generation` | [references/prd-generation.md](./references/prd-generation.md) |\n| 产品指标复盘 | `product-metrics-review` | [references/product-metrics-review.md](./references/product-metrics-review.md) |\n| 产品脑暴 | `product-brainstorm` | [references/product-brainstorm.md](./references/product-brainstorm.md) |\n| 用户反馈分析 | `user-feedback-analysis` | [references/user-feedback-analysis.md](./references/user-feedback-analysis.md) |\n| 用户故事拆解 | `user-story-breakdown` | [references/user-story-breakdown.md](./references/user-story-breakdown.md) |\n| 竞品分析 | `competitive-analysis` | [references/competitive-analysis.md](./references/competitive-analysis.md) |\n| 路线图更新 | `roadmap-update` | [references/roadmap-update.md](./references/roadmap-update.md) |\n| 需求优先级排序 | `requirement-prioritization` | [references/requirement-prioritization.md](./references/requirement-prioritization.md) |\n## 跨技能协同指引\n\n| 协同技能 | 典型场景 |\n|---------|---------|\n| 市场营销 | PRD通过后调用市场营销生成配套营销文案 |\n| 咨询交付 | PRD和竞品分析可作为咨询方案框架的输入 |\n\n> 以上为推荐协同路径。执行复合任务时，请根据实际需求灵活组合。\n\n## 六步闭环工作流对齐\n\n> 本章节使本技能包对齐「六步闭环工作流_融合数字员工体系.md」标准，实现分析→方案→执行→验证→交付→复盘的全流程闭环。\n\n### 一、六步闭环映射\n\n本技能原有四步流程（意图识别→加载模板→按模板执行→输出结果）映射到六步闭环：\n\n| 闭环步骤 | 对应本技能环节 | 具体动作 |\n|----------|-----"},{"path":"README.md","content":"# 产品管理 - product-management\n\n面向产品经理的全栈产品管理工具集。从PRD生成、用户故事拆解到竞品分析、路线图更新，覆盖产品全生命周期的核心工作流。\n\n## 子技能列表\n\n| 子技能 | 功能 | 触发关键词 |\n|--------|------|-----------|\n| PRD生成 | 输入功能需求，生成结构化PRD文档 | PRD生成, 写PRD, 需求文档, 功能规格 |\n| 产品指标复盘 | 输入产品指标数据，输出健康度评估和趋势分析 | 指标复盘, 数据复盘, DAU分析 |\n| 产品脑暴 | 围绕产品问题进行结构化创意发散 | 产品脑暴, 头脑风暴, brainstorm |\n| 用户反馈分析 | 上传用户反馈数据，自动分类统计提取高频模式 | 用户反馈分析, 用户反馈, 用户声音 |\n| 用户故事拆解 | 从Epic拆解出独立可交付的User Story | 用户故事拆解, 用户故事, story拆分 |\n| 竞品分析 | 输入竞品列表，输出功能对比和SWOT分析 | 竞品分析, 竞品调研, 竞品跟踪 |\n| 路线图更新 | 汇总迭代状态，评估里程碑进度 | 路线图更新, roadmap, 版本规划 |\n| 需求优先级排序 | 用RICE/ICE/MoSCoW/Kano模型辅助排序 | 需求排序, 需求优先级, RICE |\n\n## 使用方法\n\n通过 Marvis 对话自然触发，说出需求即可自动匹配对应子技能。\n\n## 协同技能\n\n- 市场营销：PRD通过后调用市场营销生成配套营销文案\n- 咨询交付：PRD方法论和用户研究支持咨询项目的需求分析阶段\n\n## 版本\n\nv1.0.0 | 更新日期: 2026-06-19\n\n## 变更日志\n\n### v1.0.1 (2026-06-19)\n- 对齐 description 子技能名与路由表名称\n- 压缩路由表说明列至40字以内\n- 新增跨技能协同指引章节\n- 删除冗余英文 description 行\n\n## 文件结构\n\n- `SKILL.md` - 技能运行时指令\n- `README.md` - 本文件，用户入口文档\n- `references/` - 子技能详细模板（共8个子技能）"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7096hdmqr56bh0825xpz8ft188dh24\",\n  \"slug\": \"product-management\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1786815141699\n}"},{"path":"references/competitive-analysis.md","content":"# 竞品分析\n\n对竞品产品进行系统化多维度分析，输出功能对比矩阵和差异化策略。内置 Porter 五力、SWOT 交叉策略、竞品定位对比和战略推演等方法论，按分析目的走不同深度和侧重的模板。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | 竞品报告写入 Notion 页面，构建竞品知识库 |\n| **Figma** | 引用竞品UI截图和交互流程对比素材 |\n\n## 输入要求\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 竞品列表 | 是 | 2-5个竞品名称（超过5个建议分批） |\n| 我方产品 | 否 | 自身产品信息，用于对比定位 |\n| 分析目的 | 否 | 产品设计/融资BP/战略规划/年度汇报，默认\"产品设计\" |\n| 分析维度 | 否 | 功能/定价/用户体验/技术架构/商业模式，默认\"功能+定价\" |\n\n> **信息完整度判断**：仅提供竞品名称 → 输出标准功能对比矩阵；提供分析目的 → 按目的走差异化模板。\n\n## 执行流程\n\n### 第一步：确定分析目的与深度\n\n| 分析目的 | 侧重维度 | 输出重点 | 建议篇幅 |\n|---------|---------|---------|---------|\n| **产品设计** | 功能对比+交互体验 | 功能矩阵+差异化功能清单 | 中等（2-3页） |\n| **融资BP** | 市场格局+差异化壁垒 | 竞争格局图+壁垒分析 | 精简（1页） |\n| **战略规划** | 全维度深度分析 | SWOT+五力+定价+路线图 | 详细（5-8页） |\n| **年度汇报** | 市场份额变化+趋势 | 同比变化+趋势判断 | 中等（2-3页） |\n\n### 第二步：信息收集\n\n基于用户提供的信息和AI已有知识进行分析。若用户提供了竞品官网链接、截图、定价页等补充材料，优先使用。\n\n**标注信息时效性**：所有竞品信息标注数据来源和时效（如\"基于2025年Q1公开信息\"），提醒用户核实最新情况。\n\n**信息可信度分级**：\n\n| 可信度 | 来源类型 | 标注方式 |\n|--------|---------|---------|\n| **高** | 官网公开信息、定价页、官方公告 | 直接引用 |\n| **中** | 媒体报道、用户评论、行业报告 | 标注来源 |\n| **低** | 传言、推测、过期信息 | 标注[待核实] |\n\n**竞品信息收集清单**：\n\n| 维度 | 具体收集项 | 典型来源 |\n|------|----------|---------|\n| 基本面 | 成立时间、融资轮次、团队规模、用户量 | 官网、36kr、天眼查 |\n| 产品 | 核心功能列表、最近更新、功能路线图 | 官网、更新日志、官方博客 |\n| 定价 | 套餐类型、价格区间、免费版限制 | 定价页 |\n| 口碑 | 用户好评点、差评点、NPS | G2、知乎、应用商店评价 |\n| 策略 | 目标市场、获客渠道、合作伙伴 | 媒体报道、社交媒体 |\n\n### 第三步：Porter 五力分析\n\n从行业结构角度评估竞争环境：\n\n| 竞争力量 | 分析维度 | 评估要点 |\n|---------|---------|---------|\n| **供应商议价力** | 上游依赖度 | 关键技术/人才/资源的供给是否集中？切换成本高不高？ |\n| **买家议价力** | 下游客户力量 | 客户集中度如何？切换成本高不高？价格敏感度如何？ |\n| **新进入者威胁** | 进入壁垒 | 技术壁垒、资金壁垒、品牌壁垒、网络效应、政策准入 |\n| **替代品威胁** | 替代方案 | 用户当前的替代方案是什么？替代品的性价比如何？ |\n| **行业竞争强度** | 现有玩家博弈 | 竞争者数量、市场集中度、差异化程度、退出壁垒 |\n\n**五力评估输出**：\n- 每个力量评为：强/中/弱\n- 附一句话评估理由\n- 综合判断：行业整体吸引力（高/中/低）\n\n### 第四步：多维度对比分析\n\n**功能对比矩阵**（核心产出）：\n\n| 功能模块 | 子功能 | 我方 | 竞品A | 竞品B | 竞品C |\n|---------|--------|-----|------|------|------|\n| {模块1} | {子功能1} | ✅完善 | ✅完善 | ⚠️基础 | ❌无 |\n| | {子功能2} | ⚠️基础 | ✅完善 | ✅完善 | ⚠️基础 |\n\n标注方式：✅完善 / ⚠️基础（有但不完善）/ ❌无（缺失）/ 🔜规划中\n\n**竞品定位深度对比**：\n\n| 对比维度 | 对比方法 | 评分标准 |\n|---------|---------|---------|\n| **功能矩阵评分** | 按功能模块1-5分打分，加权汇总 | 5=行业标杆，3=及格，1=基本缺失 |\n| **用户体验对比** | 核心流程步骤数、学习成本、完成效率 | 对比关键路径的点击数和完成时间 |\n| **技术架构对比** | 架构模式、技术栈、性能指标、开放性 | API开放度、集成能力、扩展性 |\n\n**SWOT分析框架**（每个竞品）：\n\n| | 正面 | 负面 |\n|---|------|------|\n| **内部** | Strengths（核心优势） | Weaknesses（明显短板） |\n| **外部** | Opportunities（可利用的机会） | Threats（需警惕的威胁） |\n\n> 每个象限写2-3条，每条必须有事实支撑，不写\"团队很强\"\"技术先进\"等空话。\n\n**SWOT交叉策略矩阵**：\n\n| 策略类型 | 含义 | 行动方向 |\n|---------|------|---------|\n| **SO策略** | 用优势抓机会 | 发挥我方强项抢占市场窗口 |\n| **WO策略** | 补弱点抓机会 | 通过弥补短板来把握新机会 |\n| **ST策略** | 用优势防威胁 | 用我方壁垒抵御竞品攻击 |\n| **WT策略** | 补弱点防威胁 | 最需紧急应对的防守方向 |\n\n**定价策略对比**（如分析维度含定价）：\n\n| 对比项 | 我方 | 竞品A | 竞品B | 竞品C |\n|--------|-----|------|------|------|\n| 免费版能力 | {范围} | {范围} | {范围} | {范围} |\n| 入门版月费 | {价格} | {价格} | {价格} | {价格} |\n| 企业版月费 | {价格} | {价格} | {价格} | {价格} |\n| 计费模式 | {按人/按量/按功能} | | | |\n| 核心差异 | {定价策略解读} | | | |\n\n**定价策略类型判断**：\n- **渗透定价**：低价抢市场份额（看免费版是否功能丰富）\n- **撇脂定价**：高价走高端路线（看是否有大量高级功能门槛）\n- **免费增值**：核心免费，高级收费（看免费版和付费版的功能差距"},{"path":"references/prd-generation.md","content":"# PRD生成\n\n根据功能需求描述，生成可直接交付评审的产品需求文档（PRD）。内置产品类型分支（B2C/B2B/内部工具/平台型），不同类型侧重不同模块。包含PRD质量自检清单，确保文档完整度。\n\n## 连接器（可选增强）\n\n| 连接器 | 增强能力 |\n|--------|---------|\n| **Notion** | PRD写入 Notion 页面，搜索已有PRD作为参考 |\n| **Figma** | 引用设计稿链接和组件规范，增强交互说明部分 |\n\n## 输入要求\n\n用户需提供以下信息（缺失项主动追问）：\n\n| 字段 | 必填 | 说明 |\n|------|------|------|\n| 功能描述 | 是 | 要做什么功能、解决什么问题，至少一句话 |\n| 目标用户 | 否 | 面向谁，未提供则根据功能推断 |\n| 业务目标 | 否 | 期望达成的业务指标（DAU、转化率、营收等） |\n| 产品类型 | 否 | B2C/B2B/内部工具/平台型，未指定则自动推断 |\n| 约束条件 | 否 | 技术限制、时间要求、资源限制 |\n| PRD深度 | 否 | 概要版（评审用）/ 详细版（开发用），默认详细版 |\n\n> **信息完整度判断**：若用户仅说\"写个PRD\"未给需求，进入**引导模式**追问功能描述；若提供了功能描述+目标用户+业务目标，进入**快速模式**直接生成。\n\n## 执行流程\n\n### 第一步：需求解析与产品类型分支\n\n解析用户输入，确定产品类型。不同类型的PRD侧重点差异显著：\n\n| 产品类型 | PRD侧重模块 | 关键差异 |\n|----------|-----------|---------|\n| **B2C** | 用户体验流程、增长指标、A/B测试方案 | 重交互、重数据、多写用户旅程 |\n| **B2B** | 权限模型、多租户、SLA、集成接口 | 重功能完备性、重安全合规、多写API对接 |\n| **内部工具** | 操作效率、与现有系统集成、培训成本 | 重实用性、轻视觉、多写操作流程 |\n| **平台型** | 多角色交互、供需匹配、生态规则 | 重角色拆分、重规则引擎、多写各角色视角 |\n\n**类型自动推断规则**：含\"用户/会员/积分/商城\"→B2C；含\"企业/SaaS/CRM/后台管理\"→B2B；含\"内部/管理系统/工单\"→内部工具；含\"平台/市场/撮合/双边\"→平台型。\n\n**B2B产品必须额外覆盖**：\n- 权限矩阵（角色 x 功能 x 数据范围）\n- 多租户数据隔离方案描述\n- 与客户现有系统的集成接口清单\n\n**平台型产品必须额外覆盖**：\n- 各角色（供方/需方/平台运营）独立功能视角\n- 供需匹配规则和排序策略\n- 平台佣金/抽成/结算规则\n\n### 第二步：结构化需求拆解\n\n**如果连接了Notion：**\n1. 搜索团队知识库中已有的相关PRD作为参考\n2. 获取团队的PRD模板规范（如有）\n\n**如果未连接：**\n1. 使用内置标准模板结构\n\n**功能拆解三步法：**\n1. **用户旅程法**：画出用户从入口到完成目标的完整路径，每个节点即一个功能点\n2. **角色拆分法**：列出所有涉及的角色（终端用户、管理员、运营等），每个角色的操作即一个功能模块\n3. **CRUD法**：对核心数据对象，梳理创建/读取/更新/删除四类操作\n\n对每个功能模块，填充以下字段：\n- 功能描述（一句话说做什么）\n- 用户故事（作为[角色]，我希望[操作]，以便[价值]）\n- 业务规则（穷举所有规则，不留模糊地带）\n- 交互说明（操作入口 → 操作步骤 → 成功/失败反馈）\n- 异常处理（网络超时、数据异常、权限不足等边界情况）\n\n### 第三步：生成完整PRD\n\n按以下模板输出。**每个占位符旁标注了填充逻辑**：\n\n## 输出格式\n\n```markdown\n# PRD：{功能名称}\n\n**版本**：v1.0\n**作者**：{产品经理名，用户未提供则写\"[待填写]\"}\n**日期**：{当前日期}\n**状态**：草稿\n\n---\n\n## 1. 背景与目标\n\n### 1.1 背景\n<!-- 填充逻辑：回答三个问题——为什么现在做？不做会怎样？做了能怎样？ -->\n{问题现状 + 用户痛点 + 为什么现在是做的时机}\n\n<!-- 示例：客服团队每天处理 2000+ 重复性问题，人力成本月均 15 万，响应时长超 30 分钟。不做自动化将无法支撑 Q4 业务翻倍目标。上线后预计 60% 重复性问题可自助解决，年节省人力成本 120 万。 -->\n\n### 1.2 目标用户\n<!-- 填充逻辑：用\"[角色]+[特征]+[场景]\"的格式，不泛泛说\"所有用户\" -->\n| 用户角色 | 特征描述 | 核心诉求 | 使用场景 |\n|---------|---------|---------|---------|\n| （示例：坐席客服 | 日均处理50+工单 | 快速检索标准答案并一键回复 | 用户来电时边通话边查知识库） |\n\n### 1.3 业务目标与成功指标\n<!-- 填充逻辑：每个目标必须SMART化——有具体数字和截止时间 -->\n| 目标 | 衡量指标 | 目标值 | 监测方式 |\n|------|---------|--------|---------|\n| （示例：减少重复性人工处理 | 自助解决率 | ≥60%（上线3月内） | 客服系统统计） |\n\n<!-- 示例：| 减少重复性人工处理 | 自助解决率 | ≥60%（上线3月内） | 客服系统统计 | -->\n\n## 2. 需求概述\n<!-- 填充逻辑：一段话概括核心需求，30字以内 -->\n\n## 3. 功能详细设计\n\n### 3.1 {功能模块1}\n**功能描述**：{做什么}\n**用户故事**：作为{角色}，我希望{操作}，以便{价值}\n**优先级**：P0/P1/P2（P0=必须上线，P1=强烈建议，P2=锦上添花）\n\n**业务规则**：\n1. {规则1——写清楚触发条件和处理逻辑}\n2. {规则2}\n\n**交互流程**：\n<!-- 填充逻辑：从入口开始，写到任务完成，覆盖正常流程+异常分支 -->\n1. 用户从{入口}进入\n2. {操作步骤}\n3. 成功：{反馈}\n4. 失败：{错误提示和处理方式}\n\n**异常处理**：\n| 异常场景 | 处理方式 | 用户提示 |\n|---------|---------|---------|\n\n（后续模块同上格式）\n\n## 4. 非功能需求\n<!-- 填充逻辑：B2C 侧重性能和体验，B2B 侧重安全和可用性 -->\n| 类别 | 要求 | 验收标准 |\n|------|------|---------|\n| 性能 | {如：页面加载时间} | {如：<2秒} |\n| 安全 | {如：数据加密} | {如：传输层TLS 1.2+} |\n| 兼容性 | {如：浏览器/设备} | {如：Chrome/Safari/微信浏览器} |\n\n## 5. 数据需求\n<!-- 填充逻辑：列出所有需要采集的数据事件，用事件名+触发条件+属性格式 -->"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。 PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano模型。 Skill: product-management Owner: ebandao777-oss Summary: 产品管理技能套件：PRD生成、产品脑暴、产品指标复盘、用户反馈分析、用户故事拆解、竞品分析、路线图更新、需求优先级排序。 PRD生成: 帮我写个PRD, 帮我出个需求文档, 写PRD, 需求文档, 功能规格; 产品脑暴: 产品脑暴, 头脑风暴, brainstorm, 创意发散; 产品指标复盘: 产品指标复盘, 数据复盘, DAU分析, 转化漏斗; 用户反馈分析: 帮我分析下用户反馈, 帮我看看用户都在说什么, 用户声音, NPS分析; 用户故事拆解: 用户故事拆解, 用户故事, story拆分, 敏捷需求; 竞品分析: 帮我分析下竞品, 帮我做个竞品调研, 竞品跟踪, 功能对比; 路线图更新: 路线图更新, roadmap, 版本规划, 排期; 需求优先级排序: 需求优先级排序, 需求优先级, RICE, Kano","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":671,"uniquenessScore":57,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T09:28:29.232Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T09:28:29.232Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T11:52:49.097Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}