Product Review Report Skill

站在 用户决策者（采购/管理层） 与 用户使用者（一线操作人员） 双重视角，撰写专业、可落地的产品评测报告。

第一步：收集评测信息

在开始评测前，先向用户询问必要信息（已在对话中提供的直接使用，不必重复询问）：

必填项：
1. 产品名称（带版本号更佳）

可选项（有则更完整，无则自行搜集）：
2. 产品相关资料或链接（官网、文档、Demo、白皮书等）
3. 要评测的功能点（如：搜索效率、API 接口、数据安全等）
4. 目标使用场景（如：中型电商日均万单履约、医院HIS系统集成等）
5. 要对比的竞品名称（1~3 个）

收到信息后，直接进入评测流程，不要等用户再次确认。

第二步：信息搜集与研究

使用 web_search / web_fetch 充分搜集：

• 产品官方文档、更新日志、发布说明
• 真实用户评价（G2、Capterra、知乎、少数派、36kr、ProductHunt 等）
• 行业分析报告（Gartner、IDC、艾瑞等）
• 竞品官网、功能列表、定价页、对比测评
• 相关事故、bug 记录、用户投诉（如有）

搜集到的数据要注明来源和时间，不要捏造数据。若无法查到某项数据，在报告中如实说明。

第三步：评测维度框架

评测须覆盖以下维度，根据产品类型适当取舍或扩充：

决策者维度（采购/管理层关心的）

• 总拥有成本（TCO）：采购价、实施成本、年维护费、隐性费用
• ROI 预期：效率提升量化估算、同类案例数据
• 厂商可靠性：融资情况、客户规模、存续年限、服务 SLA
• 合规与安全：数据合规（GDPR/等保/SOC2）、安全认证、审计支持
• 战略契合度：与现有技术栈的集成难度、供应商锁定风险、未来路线图

使用者维度（一线操作人员关心的）

• 核心功能表现：用户提供的关键功能点，逐项评测
• 易用性：学习曲线、UI/UX、操作步骤数
• 性能稳定性：响应速度、并发处理、已知故障记录
• 集成与扩展性：API 质量、插件生态、与主流工具的兼容性
• 文档与支持：文档完整度、社区活跃度、客服响应速度

第四步：竞品对比

若有竞品，逐项对比，输出评分矩阵（1~5 分制）。重点说明：

• 被评产品相对竞品的核心优势（至少 2 条有数据支撑）
• 被评产品相对竞品的核心劣势（不要粉饰，诚实说明）
• 推荐选择被评产品的场景 vs 推荐选择竞品的场景

第五步：生成报告

文件结构

markdown/
├── product-review-{产品名}-{YYYYMMDD}.md     # 主报告
└── assets/
    ├── score-radar.svg                         # 评分雷达图
    ├── tco-comparison.svg                      # TCO 对比图（如有竞品）
    └── feature-matrix.svg                      # 功能矩阵图

报告结构模板

严格按以下结构输出，每个 H2 章节均需有实质内容：

# {产品名} 产品评测报告
> 评测日期：{date} | 评测版本：{version} | 对比竞品：{competitors}

## TL;DR — 一句话结论
[决策者版本：3 行以内，给出"买"或"不买"的明确建议和核心理由]
[使用者版本：3 行以内，给出"好用"或"难用"的明确判断和核心理由]

## 被评产品概览
[产品定位、目标用户、核心卖点、市场地位]

## 评分总览
[引用雷达图 SVG]
[各维度评分表格]

## 决策者视角深度评测
### 总拥有成本（TCO）分析
### ROI 预期
### 厂商可靠性
### 合规与安全
### 战略契合度与风险

## 使用者视角深度评测
### 核心功能逐项评测
[针对用户指定的功能点，逐一评测]
### 易用性体验
### 性能与稳定性
### 集成与扩展性
### 文档与技术支持

## 竞品横向对比
[引用 TCO/功能矩阵 SVG]
[何时选择被评产品 vs 何时选择竞品]

## 风险与注意事项
[已知缺陷、历史事故、需关注的合同条款等]

## 简明实操指南
### 决策者行动清单
- [ ] ...
### 使用者快速上手要点
- [ ] ...

## 综合结论与推荐
[再次明确给出"强烈推荐 / 条件推荐 / 不推荐"，说明适用条件]

## 数据来源
[列出所有引用来源，含访问日期]

图表规范

SVG 图（外挂式）

所有 SVG 图 必须 保存为独立文件到 markdown/assets/ 目录，然后在 Markdown 中用图片引用格式引用：

![评分雷达图](assets/score-radar.svg)

不要 将 SVG 代码内嵌在 Markdown 正文中。

SVG 图要求：

• 使用 viewBox 确保自适应宽度
• 颜色方案：主色 #2563EB（蓝），辅色 #10B981（绿），警示色 #EF4444（红），中性 #6B7280（灰）
• 字体：font-family="'PingFang SC', 'Helvetica Neue', Arial, sans-serif"
• 必须包含图例和数值标注
• 雷达图维度数量：6~8 个
• 评分满分统一为 5 分

Mermaid 图（内嵌式）

适合流程图、时序图、架构对比图，内嵌在 Markdown 中：

```mermaid
flowchart LR
  ...
```

ASCII 文本图

适合简单的表格对比或示意图，直接内嵌。

写作风格要求

1. 结论前置：每个章节先给结论，再展开论据，不要"先铺垫、后点题"
2. 数据说话：每个重要判断必须有数据或事件支撑，不接受"据说""可能""一般来说"等模糊表述
3. 双视角标注：决策者与使用者关心的点不同时，用 🎯 决策者 和 🛠 使用者 标签区分
4. 不粉饰缺点：缺点和风险要如实写出，报告的价值在于帮助用户做出正确决策，而不是为产品做广告
5. 量化优先：能量化的就量化（节省 X 小时/周、错误率降低 Y%），不能量化的要说明原因
6. 中文为主：除专有名词外，报告全程使用中文，专有名词首次出现时提供中文解释

输出后的提示

报告生成后，告知用户：

1. 文件路径（主报告 + SVG 资源文件）
2. 提示用户可以进一步询问："哪个章节需要深入展开？"或"是否需要补充某个竞品对比？"

参考文件

详见 references/ 目录：

• scoring-rubric.md — 各维度评分细则（1~5分标准）
• report-examples.md — 示例报告片段（雷达图 SVG 模板、功能矩阵模板）