| name | product-review-report |
| description | 编写专业产品评测报告，站在用户决策者与使用者双重视角深度评测产品。输入产品名称（以及可选的产品资料/链接、功能点、使用场景、竞品），自动搜集产品信息、竞品对比数据与行业数据，生成结论清晰、逻辑严谨、有理论依据与数据支撑、图文并茂的 Markdown 评测报告（SVG 图以外挂文件形式引用），输出到项目 markdown/ 目录。触发条件：用户提到"产品评测"、"写评测报告"、"帮我评测XX"、"product review"、"产品对比报告"、"帮我写XX的评测"、"功能评测"、"这个产品怎么样"、"XX和YY哪个更好"、"帮我做个产品调研"、"竞品分析"、"选型报告"。即使用户只提供了产品名称和希望"帮我看看这个产品"，也应立即使用本 skill。 |
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 中用图片引用格式引用：
不要 将 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 文本图
适合简单的表格对比或示意图，直接内嵌。
写作风格要求
- 结论前置：每个章节先给结论，再展开论据，不要"先铺垫、后点题"
- 数据说话：每个重要判断必须有数据或事件支撑，不接受"据说""可能""一般来说"等模糊表述
- 双视角标注：决策者与使用者关心的点不同时，用
🎯 决策者 和 🛠 使用者 标签区分
- 不粉饰缺点：缺点和风险要如实写出，报告的价值在于帮助用户做出正确决策，而不是为产品做广告
- 量化优先：能量化的就量化（节省 X 小时/周、错误率降低 Y%），不能量化的要说明原因
- 中文为主：除专有名词外，报告全程使用中文，专有名词首次出现时提供中文解释
输出后的提示
报告生成后，告知用户：
- 文件路径（主报告 + SVG 资源文件）
- 提示用户可以进一步询问："哪个章节需要深入展开？"或"是否需要补充某个竞品对比？"
参考文件
详见 references/ 目录：
scoring-rubric.md — 各维度评分细则（1~5分标准）report-examples.md — 示例报告片段（雷达图 SVG 模板、功能矩阵模板）
