Translation in progress
This guide is not yet published in your selected language — you are reading another available version below.
比较页与 Alternatives 页面：有用，而不是自封第一
公平比较不是削弱销售，而是把说服力从口号换成证据。
比较页的任务是帮助选择
用户问“哪个更好”，真正需要的不是一个永远把你排第一的榜单，而是：在什么条件下，哪个方案更合适。
Google 的高质量评测指南强调用户视角、专业经验、定量证据、优缺点、关键决策因素和第一手材料。即使你的页面由品牌自己发布，这套原则仍适合作为质量标准。
公平比较不是削弱销售，而是把说服力从口号换成证据。
一、先披露身份和利益关系
在页面显著位置说明：
- 页面由谁撰写；
- 你是否销售其中某个产品；
- 是否含联盟链接或商业合作；
- 信息核验日期；
- 比较方法和资料来源。
FTC 的代言与推荐指南要求清楚披露可能影响受众判断的重要关系。披露应接近相关主张，而不是藏在页脚。
二、按用户任务选择比较维度
不要只比较你恰好领先的功能。对 Vibe Coding 产品，可采用：
| 维度 | 为什么重要 | 证据来源 |
|---|---|---|
| 目标用户 | 决定学习成本 | 官方定位、真实试用 |
| 代码所有权 | 影响迁移与锁定 | 导出测试、条款、文档 |
| 后端能力 | 影响可交付范围 | 实际构建任务 |
| 部署方式 | 影响运维与控制 | 官方文档、部署记录 |
| 价格模型 | 影响总成本 | 定价页与账单示例 |
| 限制 | 影响长期适配 | 配额、地区、套餐说明 |
| 支持质量 | 影响故障恢复 | 支持政策、真实记录 |
三、定义可复现的方法
一个可信比较至少说明：
- 测试日期和产品版本；
- 使用的套餐与地区；
- 统一任务和输入；
- 成功标准；
- 哪些数据来自官方，哪些来自实际测试；
- 哪些项目没有验证。
例如，不要写“生成速度更快”，应记录相同需求、测试次数、成功定义和结果分布。没有真实测试就写“官方声称”或“未验证”。
四、允许不同场景有不同赢家
如果你最重视快速原型：A 更适合。
如果你必须导出并自托管：B 更适合。
如果团队需要权限与审计：目前资料更支持 C。
如果预算低于每月 20 美元：需要先核对用量限制。这比“我们在所有方面最好”更贴近用户决策，也更不容易因产品更新而失真。
五、写清缺点和不适用情况
高质量比较应主动说明：
- 自家产品的不足；
- 竞争产品真正做得好的地方；
- 尚未验证的项目；
- 版本变化可能导致的差异；
- 适合和不适合的用户。
Google 的 reviews system 旨在奖励有深入研究的评测，而非只汇总产品的薄内容。长度不是目标，原创研究和决策价值才是。
六、Alternatives 页面应如何组织
# Example AI 的替代方案：按使用场景选择
## 快速结论
不同方案适合谁；信息核验日期；利益披露。
## 比较方法
任务、套餐、版本、证据与未验证项。
## 决策维度
为什么选这些维度。
## 对比表
事实、条件、来源和日期。
## 按场景推荐
原型、自托管、团队治理、低预算等。
## 每个产品的优缺点
包括自家产品。
## 如何自行验证
提供测试步骤和检查清单。七、维护比首次发布更重要
价格、额度、功能和产品名称经常变化。给每个易变字段指定负责人和复核周期；更新时记录实质变化，不要只改“最后更新”。
如果无法持续维护，不如缩小比较范围，而不是保留一张过期的“20 款最佳工具”大表。
八、常见失败方式
- 自建榜单永远把自己排第一；
- 维度专门挑选自家优势；
- 把官网宣传语当成实测结论；
- 隐藏联盟或商业关系；
- 不写测试日期、套餐和地区；
- 复制第三方表格，不核对来源；
- 竞争产品更新后仍保留旧结论；
- 使用虚假评论或无法验证的客户评价。
本文行动清单
- 页面披露作者、商业关系和核验日期。
- 比较维度来自用户任务，而非自家功能列表。
- 官方事实、实测结果和主观判断已分开。
- 测试方法、版本、套餐和限制可复核。
- 明确写出自家缺点和不适用对象。
- 不同场景允许出现不同推荐结果。
- 易变信息有负责人和更新机制。
小结
真正有价值的比较页，不是裁判宣布自己获胜，而是向用户公开规则、证据和取舍。
最可信的推荐，往往从承认“不一定适合所有人”开始。
Last updated on