产品能力对比维度检查清单用于竞品分析评审时逐项核对：先确认对比对象与使用场景，再按功能覆盖、性能与稳定性、集成与扩展、数据与安全、成本与交付、服务与生态六类维度建立对比口径，每项写明通过标准、证据来源和负责人，并把缺少同口径证据的维度标为阻断项，补齐后再进入结论。以下清单可直接用于评审会逐项勾选。
要点总览（TL;DR）
- 清单在三个时点各核对一次：对比框架定稿前确认对象与场景口径，数据收集完成后逐项核对证据，结论输出前确认阻断项全部关闭。
- 六类维度覆盖功能覆盖、性能与稳定性、集成与扩展、数据与安全、成本与交付、服务与生态，每项写明检查内容、通过标准、证据来源与负责人。
- 通过标准要写成可观察、可对比、有判定边界的表述，证据按官方文档、公开演示、试用记录、访谈记录分级使用。
- 对比对象口径不一致、核心维度无同口径证据、安全与合规材料缺失属于阻断项，未关闭时不进入结论环节。
- 评审记录按维度组织并附证据行编号，待验证项写明责任人与复查时间，清单调整记录随版本保存供下次复用。
谁在什么时点使用这份检查清单
这份清单服务于产品规划方向的竞品研究，使用对象包括产品经理、竞品分析负责人，以及参与评审的业务代表和技术代表。三类角色分工不同：产品经理负责确认场景与功能口径，技术代表核对集成、性能与安全证据，业务代表判断成本与交付方式是否符合实际使用条件。清单在三个时点各核对一次，每次核对的目标不同。
| 使用时点 | 核对目标 | 主要参与角色 | 产出 |
|---|---|---|---|
| 对比框架定稿前 | 确认对比对象名单、目标用户与场景已写明，维度分类与权重方向达成一致 | 产品经理、竞品分析负责人 | 对象与场景核对表、维度框架 |
| 数据收集完成后 | 逐项检查六类维度是否有同口径证据，标注待验证项 | 技术代表、业务代表、竞品分析负责人 | 带证据与负责人的维度检查表 |
| 结论输出前 | 确认阻断项全部关闭，结论与证据一一对应 | 全体评审角色 | 评审记录、结论与待验证项清单 |
启动核对前需要准备三项前置输入：对比对象名单（含版本或套餐口径）、目标用户与使用场景说明、已有资料清单。缺少任一项时，先补齐再进入维度打分，否则后续证据无法对齐同一口径。
对比对象与场景口径检查项
进入维度打分前，先核对对比对象是否处于同一产品层级、同一版本或套餐口径。把旗舰版与入门版放在一起比较功能覆盖，得出的差异反映的是套餐差异，无法支撑产品能力判断。场景口径同样需要写明：目标用户是谁、在什么业务规模下使用、核心任务是什么。对比目的限定为产品规划研究；营销投放与广告效果评估属于另一类工作，不纳入本清单。
| 检查项 | 通过标准 | 证据来源 | 负责人 |
|---|---|---|---|
| 对比对象层级一致 | 所有对象处于同一产品层级，版本或套餐口径在表中写明 | 官方产品页、版本说明、销售提供的套餐清单 | 竞品分析负责人 |
| 目标用户与场景写明 | 每个对象对应明确的用户角色、业务规模与核心任务描述 | 需求文档、用户访谈记录 | 产品经理 |
| 对比目的界定 | 目的写明为产品规划研究，结论用途与评审范围一致 | 评审立项说明 | 产品经理 |
| 资料清单完整 | 已有资料按对象列出，缺失资料标注获取方式与时间 | 资料清单表 | 竞品分析负责人 |
任一项未通过时，暂停维度打分，先修正口径。对象口径不一致属于阻断项，处理方式见第五节。
六类对比维度的分项检查表
六类维度覆盖产品能力对比的主要判断面。每项检查内容都对应一个可核验的通过标准，评审时逐项勾选并填写证据来源与负责人。维度权重可按产品类型调整，例如平台型产品提高集成与扩展的权重，数据密集型产品提高数据与安全的权重；权重调整需在框架定稿前完成并记录。
| 维度 | 检查内容 | 通过标准 | 证据来源 | 负责人 |
|---|---|---|---|---|
| 功能覆盖 | 核心任务逐条对应，缺失项单独标注 | 核心任务清单中每项在各对象上都有明确结论：支持、部分支持或不支持，部分支持写明边界 | 官方文档、试用记录、演示 | 产品经理 |
| 性能与稳定性 | 负载、响应时间、可用性是否有可比证据 | 各对象的性能数据来自相同测试条件或公开指标口径，条件不同时注明差异 | 官方性能说明、试用压测记录、公开技术文档 | 技术代表 |
| 集成与扩展 | 接口、开放能力、二次开发支持是否核实 | 接口类型、鉴权方式、扩展点有文档依据，关键集成场景完成一次验证 | 开放平台文档、试用验证记录 | 技术代表 |
| 数据与安全 | 权限、审计、数据导出与合规材料是否齐备 | 权限模型与审计能力有文档说明，数据导出方式明确，合规材料在有效期内 | 安全白皮书、合规证书、官方文档 | 技术代表 |
| 成本与交付 | 计价口径、实施周期、交付方式是否同口径 | 各对象按相同计价单位换算，实施周期与交付方式写明前提条件 | 报价单、实施方案、访谈记录 | 业务代表 |
| 服务与生态 | 支持响应、文档、社区与伙伴资源是否可查 | 支持渠道与服务等级有书面说明，文档与社区资源可实际访问 | 服务协议、官方文档站、伙伴目录 | 业务代表 |
填写时注意两点：功能覆盖的“部分支持”必须写明边界，例如仅支持某类数据格式或某档套餐；成本与交付的换算口径需在表中注明汇率、计价周期等前提，避免不同口径的数字直接比较。
每项维度的通过标准与证据要求
通过标准写成可观察、可对比、有明确判定边界的表述，评审时才能判断是否完成。“界面友好”“性能较强”这类描述无法核验，应替换为具体条件，例如“支持批量导入不少于一万条记录且提供导入日志”。判定边界要写清通过和不通过的分界，部分支持的情况注明支持范围。
证据按可信度分级使用，同一结论优先采用高等级证据；低等级证据可以补充说明，单独使用时标注来源类型。
| 证据等级 | 证据类型 | 适用场景 | 使用限制 |
|---|---|---|---|
| 一级 | 官方文档、安全白皮书、合规证书 | 功能存在性、接口能力、安全与合规结论 | 需确认文档对应版本与套餐 |
| 二级 | 公开演示、官方发布会材料 | 功能流程、界面与操作方式 | 演示环境与实际配置可能存在差异 |
| 三级 | 试用记录、压测记录 | 性能表现、集成验证、实际操作体验 | 需记录测试条件与数据规模 |
| 四级 | 访谈记录、用户反馈 | 服务体验、实施过程、使用中的问题 | 属于个体经验，不扩大为普遍结论 |
未取得证据的维度标注“待验证”，写明计划获取方式与复查时间，不写成确定结论。待验证项在结论中单独列出，不与已验证结论混排。
阻断项与完成条件
阻断项是必须补齐才能输出结论的检查项，共三类：对比对象口径不一致，例如版本或套餐层级混用；核心维度无证据，即功能覆盖、性能与稳定性、数据与安全中任一维度缺少同口径证据；安全与合规材料缺失，包括合规证书过期或权限、审计能力无文档依据。阻断项未关闭时，评审不进入结论环节。
次要维度证据不足，例如服务与生态的部分资源暂未核实，可标注为待验证项，不阻断结论输出，但需在结论中注明影响范围。清单完成的判定条件有三条：全部阻断项关闭并有对应证据；各维度负责人确认签字；结论中的每条判断都能对应到检查表中的证据行。
| 类别 | 具体情形 | 处理方式 | 关闭标志 |
|---|---|---|---|
| 阻断项 | 对比对象版本或套餐口径不一致 | 重新确定对象名单，统一口径后重做相关维度 | 对象与场景核对表通过 |
| 阻断项 | 核心维度无同口径证据 | 补充试用、文档或演示证据 | 证据行填写完整并经负责人确认 |
| 阻断项 | 安全与合规材料缺失或过期 | 获取有效材料或调整结论范围 | 材料在有效期内并归档 |
| 非阻断项 | 次要维度证据不足 | 标注待验证，写明获取计划与复查时间 | 结论中注明影响范围 |
评审后的记录与复用
评审结束后形成一份记录，包含结论、待验证项、责任人与复查时间。结论按维度组织，每条结论后附证据行编号，便于回溯。待验证项单独成表，写明计划获取方式和复查日期，到期由责任人更新状态。评审记录与产品规划文档建立对应关系：规划文档中引用竞品结论时，注明来源评审记录的版本与日期，后续规划调整时可追溯当时的证据基础。
清单本身也需要维护。每次评审后记录维度与通过标准的调整，例如新增某类集成场景的检查项、修改性能证据的测试条件要求，并注明调整原因和生效日期。调整记录随清单版本保存，下一次竞品分析直接沿用最近版本，避免每次从零搭建框架。
在评审记录与待验证项的跟踪环节，可以用ONES承载相关工作：把每个待验证项建为工作项，指定责任人与复查时间，评审记录作为文档与工作项关联，结论更新时同步修改文档状态。这样待验证项的关闭情况在评审会上可以直接查看，减少口头跟进的遗漏。具体使用方式按团队现有的工作项与文档管理习惯配置。
常见问题
对比对象处于不同版本或套餐时，清单该怎么处理？
先把对象名单调整到同一产品层级和同一版本或套餐口径，再重做受影响的维度。如果业务上确实需要跨套餐比较，就在对象与场景核对表中写明各对象的版本或套餐，并在结论里把差异归因到套餐差异，避免把套餐差异写成产品能力差异。这类口径不一致属于阻断项，未处理前不进入维度打分。
性能与稳定性拿不到同条件的测试数据，还能继续评审吗？
可以继续，但要把这一维度标为待验证，并写明计划获取方式，例如安排试用压测或索取公开技术文档。若各对象的数据来自不同测试条件，在表中注明条件差异，结论只描述差异存在，不直接比较数值高低。性能与稳定性属于核心维度，缺少同口径证据时按阻断项处理，补齐后再输出结论。
部分支持的功能项，通过标准怎么写才不算含糊？
把支持范围写进判定条件，例如支持的数据格式、适用的套餐档位、单次处理的数量上限，以及不支持的部分。评审时逐条对照核心任务清单，确认每个对象都有明确结论：支持、部分支持或不支持。部分支持的条目要能回答“在什么条件下可用”，否则视为证据不足，转入待验证。
待验证项一直没关闭，评审记录怎么维护？
待验证项单独成表，写明责任人、计划获取方式和复查日期，到期由责任人更新状态。评审记录保留原版本，结论变更时新增记录并注明变更原因，便于回溯当时的证据基础。待验证项长期未关闭时，在下次评审会上单独说明影响范围，由评审角色决定是否调整结论或缩小结论适用范围。
这套清单能直接套用到不同产品类型吗？
六类维度可以通用，权重和具体检查项需要按产品类型调整。平台型产品可提高集成与扩展的权重，数据密集型产品可提高数据与安全的权重，硬件类产品还需补充交付与现场支持相关的检查项。权重调整在框架定稿前完成并记录调整原因，调整后的版本作为下一次评审的起点。
