Doubao Product Analysis

---
name: doubao-product-analysis
description: 围绕具体产品、产品想法或存量方案，产出用于产品进入、定位、竞争策略、上市路径、能力建设与路线图决策的证据型分析报告。适用于“值不值得做或发布”“进入哪个细分”“目标用户和市场是否成立”“竞品为何这样设计”“该借鉴、差异化或放弃什么”“核心能力与 Roadmap 怎么定”“如何调整已有产品”等请求，也适用于将用户研究、市场信息、竞品实测、内部资料和业务约束整合为决策建议。支持 0→1、存量产品调整、竞品专项与组合分析；默认交付为可独立阅读的飞书云文档，并用正文内 HTML5 block 呈现必要的产品定位图或能力路线图。不用于只需罗列功能、直接撰写实施 PRD，或在缺少依据时给出确定性预测的任务。
---

# 产品分析报告

## 目标

产出能支持具体决策的报告，而不是资料汇编。让读者快速看清：服务谁、解决什么问题、为什么现在做或不做、选择什么、放弃什么、关键依据是什么，以及下一步如何验证。

## 工作原则

1. **以决策问题组织分析**：先明确待选择的选项，再研究会改变选择的证据。不要为了框架完整而堆章节。
2. **以真实现状为起点**：分析存量产品、内部方案或已有文档时，先读取现状、数据、反馈和约束，再提出变化。
3. **先过事实门，再做战略推导**：关键事实必须逐条连接到能直接支持它的原始来源；只有来源标题清单不算可追溯。
4. **区分证据与判断**：分开标注已证实事实、用户提供、本地实测、推断、待验证假设和产品建议；不把推断写成事实。
5. **比较机制与取舍**：从用户任务提炼少数结构性分野，说明产品如何产生结果、依赖什么、牺牲什么、适合谁；不要停留在功能勾选。
6. **保留不确定性**：缺数据时降低结论强度并设计验证，不补造数字、模型归属、用户反馈、成功率、商业目标或时间表。
7. **必须形成取舍**：结论至少包含优先项、放弃项和重审条件；任务包含产品规划时，再明确目标用户、P0、Non-goals 和验证方式。规划深度不得超过目标产品现状与资源证据。
8. **让结构服从任务**：用户指定问题、对象或维度时优先遵循；只选择有助于当前决策的分析模块。
9. **以飞书正文承载结论**：飞书云文档是唯一主报告；HTML5 block 只用于压缩复杂关系，不替代正文证据和结论。

## 工作流

### 1. 建立决策简报

先从用户材料中提取以下信息，不重复询问已经能确认的内容：

| 字段 | 要回答的问题 |
|---|---|
| 决策 | 这份报告要支持哪个选择？有哪些现实选项？ |
| 对象与状态 | 分析什么产品、想法、品类或存量方案？现在处于什么阶段？ |
| 读者 | 谁会据此拍板、投入资源或承担结果？ |
| 用户与范围 | 目标用户、购买者、场景、地区和时间范围是什么？ |
| 约束 | 战略、资源、技术、数据、渠道、合规或品牌边界是什么？ |
| 已有证据 | 已有文档、数据、研究、实测和已知反例是什么？ |
| 交付 | 写入或更新哪份飞书云文档？是否需要定位图或能力路线图？ |

只追问会实质改变分析方向且无法安全假设的信息。能够推进时，写明工作假设和分析边界后继续。若用户没有给出明确决策，将其请求收束为一个可回答的问题，不擅自扩大为完整战略规划。

### 2. 选择最短分析路径

按决策选择模块，可组合但不要默认全部执行。详细方法见 [analysis-patterns.md](references/analysis-patterns.md)。

| 决策类型 | 优先回答 |
|---|---|
| 进入、发布或继续投入 | 问题强度、目标细分、机会成立条件、替代方案、进入壁垒、时机与验证方式 |
| 竞品或品类研究 | 可比用户任务、解决机制、体验与商业取舍、适用边界、可迁移启示 |
| 存量产品调整 | 当前表现、保留/调整/停止/新增、迁移成本、依赖与风险 |
| 定位或差异化 | 目标用户、价值主张、可信优势、竞争边界和明确放弃 |
| 能力与路线图 | 目标结果、能力缺口、关键依赖、阶段证据门与停止条件 |

优先研究“影响大且不确定”的问题。背景信息若不改变选择，只保留支撑结论所需的最小内容。

### 3. 建立证据底稿

涉及外部事实、内部材料、数字、用户结论或竞品行为时，读取 [research-and-evidence.md](references/research-and-evidence.md)。先列出会改变决策的主张，再建立“主张—来源”映射；不要先写报告再补来源。

为每条关键事实分配唯一 ID（如 `[F1]`），在执行摘要、对比表、图表说明和建议依据中紧邻引用。证据底稿至少记录：

| ID | 原子事实或主张 | 状态 | 直接来源 | 发布时间/访问时间 | 版本、地区、套餐与口径 | 支持的结论 |
|---|---|---|---|---|---|---|

使用 `已证实事实`、`用户提供`、`本地实测`、`推断`、`待验证假设`、`产品建议` 六种状态。对价格、功能、平台、语言、权限、模型、认证、政策、市场规模、版本和竞争动作标注时间、地区、套餐或口径。

将以下情况视为事实闸门不通过：

- 没有能直接打开或定位的原始链接、文件或内部记录；
- 来源只支持更弱的说法，却被扩大成更强结论；
- 当前状态与“即将推出”“测试中”“申请中”“历史上曾有”混写；
- 数字无法说明指标、单位、样本、测试条件或时间；
- 对比表里出现数字或确定性能力描述，但没有相邻事实 ID；
- 文末只列来源标题，无法知道每个来源支持哪条事实。

事实闸门不通过时，删除该主张或降级为待验证项；不得让它参与横向评分、战略结论或路线图指标。

### 4. 分析用户问题与机会

将问题写成可证伪陈述：**谁在什么触发场景，要完成什么任务，受到什么阻碍，当前如何替代，产生什么可观察后果。**

区分使用者、购买者和受影响者。判断问题强度时至少检查：

- 频率或持续性；
- 时间、金钱、质量、风险或机会损失；
- 用户已付出的替代成本；
- 真实行为、付费、流失、工单或迁移信号；
- 哪些细分最痛，哪些细分并不需要。

只有在会影响决策时分析市场。先判断问题强度、可支付价值、可触达性、时机、可进入性和战略匹配，再决定是否估算规模。口径不足时给区间、方向或验证方法，不用主观市场份额制造 TAM、SAM、SOM。

### 5. 拆解竞品与替代方案

围绕同一用户任务选择代表性对象，包括直接竞品、相邻方案、人工或通用工具，以及“不处理”。不要因品牌知名度加入不可比对象。

优先回答：

- 从哪里触发，关键流程如何完成；
- 核心机制是什么，自动化与人工边界在哪里；
- 给谁创造什么结果，用户为此承担什么成本；
- 依赖哪些数据、生态、渠道、信任或运营条件；
- 在哪些版本、套餐、地区和场景下成立；
- 失败、纠错和恢复如何处理。

用户显式指定对比维度时，以这些维度为主线；可使用一张矩阵、分维度小节或流程对比，选择最能呈现差异的形式。标准维度只用于补缺，不覆盖用户问题。

先建立覆盖检查表，确保每个指定维度都有：比较口径、关键差异、证据 ID、适用边界和一句产品含义。不要用一张宽表掩盖某个维度没有真正研究。

完成维度对比后，再提炼 1–3 个跨维度的产品分野，例如“实时输入 ↔ 深度润色”或“单点工具 ↔ 工作入口”。分野必须来自已证实的产品机制与用户代价，不能只追求措辞好记。

竞品涉及模型归属、性能、平台可用性、语言或方言、价格、权限、数据政策、安全认证时，必须读取 [competitive-fact-check.md](references/competitive-fact-check.md) 并逐项核验。区分“竞品公开声称”“官方文档确认”“本地实测观察”和“由此推断”。竞品有某能力不等于用户需要；竞品没有某能力也不等于存在机会。

### 6. 形成产品选择

先列出真实可选项，再比较，不直接跳到唯一方案。每个主要选项至少说明：

| 维度 | 内容 |
|---|---|
| 目标用户与结果 | 服务谁，改变什么结果 |
| 价值依据 | 哪些证据支持，强度如何 |
| 产品机制 | 如何产生结果，与替代方案有何不同 |
| 代价与风险 | 复杂度、成本、信任、合规、渠道或定位损害 |
| 可行条件 | 需要哪些能力、数据、资源和合作 |
| 时机 | 为什么现在；延后会怎样 |
| 结论 | 做、先验证、调整、观察或不做 |
| 重审条件 | 出现什么证据时改变判断 |

把建议收束为：目标细分、关键问题、总判断、P0 能力、借鉴与差异化、明确不做，以及下一证据门。空白市场、用户口头喜欢、趋势热度或“竞品都有”都不能单独通过决策门。

当用户要求产品规划启示时，至少交付以下最小闭环：

| 项目 | 最低要求 |
|---|---|
| 目标用户 | 具体角色、场景与选择理由，不写泛人群 |
| P0 能力 | 闭合一个关键任务的最小能力组合，不是竞品功能合集 |
| 借鉴与差异化 | 分别写清机制、适用前提和代价 |
| Non-goals | 明确第一阶段不解决什么，以及为何不做 |
| 验证方法 | 输入、样本、比较基线、观察指标、通过或停止条件 |
| 证据边界 | 哪些来自目标产品现状，哪些只是条件式建议 |

缺少目标产品现状、用户数据、资源或技术评估时，将建议写成条件式的 P0 验证方案；不要直接上升为公司战略、平台定位或完整商业承诺。

### 7. 提炼能力与路线图

只在决策需要时输出能力与路线图。将能力定义为可在多个场景稳定产生结果的系统机制，而非功能列表。说明体验、数据或模型、工作流、质量、运营、生态和合规等组成与依赖。

优先给一个可执行的 P0 验证阶段。只有用户明确需要长期规划，且已有目标产品现状、资源投入、技术依赖和阶段证据时，再扩展为 `Now / Next / Later` 或验证、深化、规模化：

| 阶段 | 目标结果 | 能力与范围 | 非目标 | 最大风险 | 证据与验收 | 继续/调整/停止条件 |
|---|---|---|---|---|---|---|

没有资源和技术评估时不得给月份、季度或 0–N 年排期。没有指标定义、基线、样本、测量窗口和负责人时，不得给准确率、延迟、留存、客户数、收入或市场份额阈值；改写为“先建立基线并确认门槛”。后续阶段必须以上一阶段的证据成立为前提。

## 组织报告

先写执行摘要，再补证据。执行摘要应能独立回答：

- **判断**：建议做、验证、调整、观察还是不做；
- **对象**：服务谁，解决什么关键问题；
- **依据**：哪 3–5 条证据最影响选择；
- **取舍**：优先什么，明确不做什么；
- **行动**：下一步验证、投入或待拍板事项；
- **信心**：最大不确定性是什么，什么证据会改变判断。

竞品分析与产品规划并存时，默认采用以下短结构：

1. **执行摘要**：核心判断、1–3 个产品分野、事实边界与下一动作；
2. **范围与口径**：对象、用户指定维度、版本、地区、套餐和 `as of`；
3. **指定维度对比**：逐维度结论、差异、边界与事实 ID；
4. **机制与战略分野**：解释为什么不同，而不只是哪里不同；
5. **产品选项与取舍**：目标用户、P0、借鉴、差异化、Non-goals；
6. **验证计划**：最小实验、证据门、重审或停止条件；
7. **事实—来源映射**：每条事实对应具体标题、发布者、时间和链接。

纯进入决策、存量产品调整或单一定位任务按需增删模块。删除不影响决策的章节，不保留空标题。每节先给结论，再给关键证据和对产品的含义。把详细研究过程放在附录，不让方法论淹没建议。

需要用于拍板的关键结论，至少用一小段说明主张、关键证据、推理、业务含义与决定；不要求扩成长文，但避免只列短句、框架名或模板套话。

## 飞书云文档与 HTML5 block

读取 [feishu-and-visuals.md](references/feishu-and-visuals.md)，将完整报告写入飞书云文档：

1. 用户提供目标文档时，先回读当前版本，只修改目标范围并保留无关内容、格式、链接和附件；未提供文档时创建新文档。
2. 先完成正文和证据底稿，再判断是否需要视觉。正文表格能清楚表达时不额外做图。
3. 当至少三个可比方案存在有证据的二维战略差异时，基于 `assets/product-positioning-map.html` 制作定位图。
4. 当用户问题、产品选择、核心能力和阶段证据门之间的关系需要一屏呈现时，基于 `assets/capability-roadmap.html` 制作能力路线图。
5. 将模板复制到本次任务的工作目录后替换全部占位符，不直接改动 Skill 内的母版。生成的 HTML 必须单文件、无外部依赖，并在 `<head>` 中保留 `use-iframe=true`、`html-box-height-mode=auto` 和说明图表结论的 `description`。
6. 按当前飞书文档工具说明，将 HTML 作为正文内 extended block 插入相应章节。使用相对执行目录的路径，例如：

```xml
<html5-block path="@product-positioning-map.html"></html5-block>
```

7. 图前先写一句结论，图后说明产品含义、证据边界或最大风险。HTML 不重复正文，也不承载正文缺失的关键事实。
8. 写入后回读并预览，检查执行摘要首屏、标题层级、表格、HTML 块位置与高度、来源链接和待验证标记。

执行“视觉承诺一致性”硬门：正文只要出现“见定位图”“见路线图”或把某图列为交付物，就必须实际生成、插入并在回读中确认对应 HTML5 block。无法插入时，明确标记未完成并删除误导性引用；不得只描述一张并不存在的图。

定位图的轴必须代表不同的用户价值或战略取舍，点位必须可回溯。没有连续可比数据时使用低、中、高等定性位置；将目标产品的当前事实位置与建议选择位置分开表达。无人区域只标为待验证空间，不直接称为蓝海。

## 交付要求

- 遵循用户指定的语言、篇幅和飞书文档位置；未指定篇幅时，优先交付精炼、可直接讨论的报告。
- 飞书正文必须能脱离附件和 HTML 独立理解；视觉组件必须内嵌在其逻辑所属章节。
- 只在关系确实难以用短文或表格表达时使用图。定位图和路线图必须有证据底稿，避免伪精确坐标。
- 引用靠近关键主张；来源表至少包含标题或材料名、发布者或提供者、日期、链接或文件位置、访问时间和支持的主张。
- 无法完成飞书写入、HTML5 block 插入、实测或取证时，说明具体失败原因、已完成内容和未验证边界，并保留可重试的正文与 HTML 文件；不声称已经交付或确认。

## 交付前检查

- 执行摘要、对比表、图表和建议依据中的每条关键事实，是否都能通过事实 ID 找到直接来源？
- 是否存在只有来源标题清单、没有逐条事实映射的情况？有则不通过。
- 模型归属、性能、平台、语言、权限、认证、价格和数据政策是否逐项核验，且没有扩大来源原意？
- 所有数字是否参与过同口径检查；无法比较的数字是否已删除或降级？
- 报告是否围绕一个明确决策，而非复述资料？
- 执行摘要能否在一分钟内支持讨论或拍板？
- 用户问题是否来自场景、任务、阻碍和后果，而不是功能名？
- 市场判断是否先验证目标细分与可进入性，而非只展示规模？
- 竞品比较是否解释机制、价值、代价和边界？
- 关键数字是否有定义、单位、地区、时间、分母和来源？
- 事实、实测、推断、假设和建议是否清楚分开？
- 总结是否同时包含优先项、放弃项、风险和重审条件？
- 需要产品规划时，是否明确给出目标用户、P0、Non-goals 和验证方法？
- 路线图是否由结果与证据门驱动，而非功能和日期堆叠？
- 分阶段路线图是否同时写清继续、调整和停止动作？没有基线时是否只定义测量与确认方式，而未自行填入精确阈值？
- 是否出现没有现状、资源、基线或技术评估支撑的长期排期、指标、客户数或收入承诺？有则不通过。
- 是否删除了不适用章节、重复内容、空洞趋势和无依据精度？
- 是否删除“部分内容由 AI 生成”“报告已完成”等内部过程话术，并确认最终回复承诺的文件、附件和图表真实存在？
- 飞书正文能否独立阅读，HTML5 block 是否内嵌、轻量且不重复正文？
- 报告承诺的每张定位图或路线图是否真实存在于飞书文档并已回读确认？

任何关键项不通过，修正后再交付。