Product Review Report

Overview

为决策者和使用者同时编写一份可决策的产品评测报告，覆盖业务价值 / 成本 / 风险 / 易用性 / 日常效率等维度，输出图文并茂的 markdown 报告到当前项目 markdown/ 目录。

何时使用

• 用户说 "评测 XX 产品"、"对比 X 和 Y 的差异"、"帮我选型"、"XX 工具好不好用"
• 用户给出产品名 + 1-2 个评测维度，需要结构化报告
• 涉及付费 / 长期投入决策，需要论据和依据

何时不要使用

• 用户只是简单问"XX 是什么"——直接回答即可，不需要评测报告
• 单纯技术问题（API 怎么用、bug 排查）—— 用相关技术 skill
• 用户没给产品名——直接问，不用启动完整 skill

Workflow

Step 1: 收集 4 项必填信息

用 AskUserQuestion 一次性收集（避免多轮来回）。如果用户已经提供部分信息，跳过对应项：

1. 被评测产品名（必填）— 厂商 + 产品全称
2. 资料/链接（可选项）— 官网、文档、白皮书、博客文章、第三方测评链接
3. 评测功能点（必填）— 重点考察哪些功能（如"向量检索性能"、"多租户隔离"、"中文支持"）
4. 目标使用场景（必填）— 谁会用、用来干什么、规模多大
5. 对比的竞品（必填，至少 1 个）— 候选方案有哪些

多选题用 multiSelect=true 即可；用户没填的可选项允许跳过。

Step 2: 网络核实最新状态

必须用 mcp__MiniMax__web_search 搜索验证以下事实，禁止只用训练记忆：

• 产品的最新版本、最近一次大版本发布时间
• 厂商融资 / 收购 / 重大公告
• 竞品的最新动态（避免单方面稻草人）
• 公开的 benchmark / 性能数据
• 真实用户反馈（Reddit / Hacker News / V2EX / 即刻 / 知乎）

金融类产品（IPO 状态、估值、营收、市场份额）必须二次核实，绝不照搬训练记忆。 跨公司对比时双方都要查最新状态。

Step 3: 选定评测维度

读 references/evaluation-framework.md：

• 按"产品类型"选用对应维度（功能 / 性能 / 易用性 / 生态 / 安全 / 成本 / 厂商 / 扩展性 / 可靠性 / AI 智能化）
• 不要全用——只选真正影响决策的 3-7 个
• 同时明确"决策者关注点"和"使用者关注点"在每个维度上的差异

Step 4: 撰写报告

报告结构参考 assets/report-skeleton.md：

1. TL;DR（30 秒读完）— 一句话定位 + 双视角结论 + 总评分
2. 产品概览— 基本信息、关键时间线（mermaid timeline）、核心定位
3. 评测维度详解— 每个维度小标题 + 打分 + 论据
4. 竞品对比— 对比表（1-5 星）+ 差异化分析 + mermaid 选型决策树
5. 决策者视角结论— 业务价值、ROI、风险、战略契合度、决策建议
6. 使用者视角结论— 上手体验、日常效率、故障求助、推荐上手路径
7. 实操指南— 3 步上手，含代码 / 命令
8. 参考与依据— 所有引用的链接（数据来源、官方文档、用户反馈）

Step 5: 图示选型

• 架构 / 流程 / 决策树 / 时序 / 状态 / 类图 → Mermaid（首选）
• 组织关系 / 业务流 → Mermaid
• 复杂数据可视化 / 品牌色块 / Logo → 外挂 SVG
• 简单结构 → ASCII text 图

SVG 外挂强制规则：

• SVG 文件保存到 markdown/svg/{report-name}-{chart-name}.svg
• markdown 中用 ![描述](./svg/xxx.svg) 引用
• SVG 内禁止外链资源（防失效）
• 字体用系统通用字体（system-ui, -apple-system, sans-serif）

Step 6: 输出

将最终报告保存到当前工作目录下的 markdown/ 目录：

• 文件名：{产品名}-评测报告.md（中文产品名直接用；含空格或特殊字符用连字符替换）
• 路径示例：/Users/digoal/new/markdown/{产品名}-评测报告.md
• SVG 子目录：/Users/digoal/new/markdown/svg/
• 如目录不存在，先 mkdir -p markdown/svg

Step 7: 自检

输出前逐项检查：

• 决策者结论清晰可执行（采购/试用/观望/放弃 + 关键决策点）
• 使用者结论可感知（上手难度 + 推荐路径）
• 每个对比打分都有依据 / 引用
• 推演逻辑链完整（事实 → 推断 → 结论）
• 至少 1 张图示（mermaid / svg / ascii）
• 引用链接齐全，且都是实际访问过的（不是训练记忆编造）
• 实操指南 ≤ 5 步

完成后向用户报告文件路径 + 关键结论速览。

Resources

references/evaluation-framework.md

评测维度、权重、双视角关注点的完整定义。写报告前必读。

assets/report-skeleton.md

报告结构的 markdown 骨架，用于规范化输出，避免章节遗漏。

scripts/

（本 skill 不需要确定性脚本——报告生成是 LLM 推理任务，无重复代码。）

---

写作规范

• 结论先行：每个章节第一句话就是结论/判断，论据跟在后面
• 避免模糊：用"延迟 P99 200ms"代替"性能不错"
• 数据可追溯：所有数字必须有来源（官方文档 / 第三方测评 / 用户报告）
• 承认局限：找不到的数据写"未公开"或"无独立验证"，不要编
• 语言：默认中文输出；用户明确要求英文则英文
• 长度：典型报告 1500-4000 字；超过 5000 字考虑分章节或合并简化