# 如何用 AI 分析 SaaS 竞品：4 个可直接复制的提示词

> 用 4 个以证据为先的 AI 提示词分析 SaaS 竞品评论、定价、更新日志和社区讨论，避免把零散线索写成确定结论。

Source: https://tomako.ai/zh/blog/analyze-saas-competitors-with-ai
Updated: 2026-09-18

竞品分析不一定要从昂贵工具开始。公开评论、定价页、更新日志和社区讨论，已经能提供不少有用线索。下面 4 个提示词会帮你区分重复信号和个别抱怨，跨来源核对发现，再把它们变成值得验证的产品假设。

## 开始前，先守住几条边界

用户评论和论坛帖子适合帮你发现问题，但不能代表整个市场。要把反复出现的问题和个别抱怨分开。重要发现至少要再找一种来源核对，然后才能用于公开定位。

还有一条很重要：用户的抱怨可以证明痛点存在，但不能证明你的产品已经解决了这个痛点。

## 四个分析角度

| 分析角度 | 输入材料 | 可以帮助你了解什么 |
| --- | --- | --- |
| 评论分析 | 公开用户评论 | 反复出现的流程问题和个别抱怨 |
| 定价分析 | 当前定价页和套餐限制 | 已写明的功能门槛、用量限制和可比较的价格变化 |
| 更新日志分析 | 带日期的更新记录和当前产品主张 | 公司在这段时间选择公开了哪些变化 |
| 社区表达 | 公开问题和相关讨论 | 用户如何用自己的话描述问题 |

这些材料只能提供线索，不能直接给出市场结论。把不同来源放在一起，看它们是否指向同一个问题。

## 1. 从用户评论中找出使用摩擦

二星和三星评论常会写出较具体的使用问题，因为评论者通常真正试过产品。但这仍是一组有偏样本，不能说明某个问题在全部客户中有多常见。

只处理你有权使用的内容。删除姓名和个人信息，保留来源链接供自己核对。把评论交给 AI 前，也要查看平台当前的使用条款。

### 提示词 1：提取评论证据

```markdown
你正在为一位独立软件开发者分析用户评论。

只能分析下面提供的文字。不要使用你对这家公司或产品的外部知识。

竞品名称：[竞品名称]

评论：
"""
[粘贴 15-25 条简短评论摘录。先删除个人信息，只粘贴评论文字，不要粘贴整页 HTML。]
"""

规则：
1. 只有至少两条相互独立的评论提到同一个底层问题，才能标记为“重复出现的问题”。
2. 只有一条评论提到的问题，标记为“个别线索”。
3. 只有评论者明确说自己正在寻找、已经改用或考虑改用其他产品时，才能标记为“寻找替代产品的触发点”。否则标记为“仅为使用摩擦”。
4. 每项发现都要附上原文引用和提及该问题的评论数量。
5. 不要根据缺失信息推测用户意图、市场规模或产品影响。
6. 某部分没有足够证据时，写“所提供文字中的证据不足”。

请输出：

### 重复出现的问题
每项包括：
- 简明描述
- 提到该问题的独立评论数量
- 一到两段原文引用
- 原文提到的使用流程或用户背景

### 个别线索
列出只出现一次、但值得继续调查的问题。不要把它们写成趋势。

### 明确的替代产品触发点
只列出评论者明确表示正在寻找或已经选择其他产品的情况。

### 比预期更难完成的任务
找出评论者认为混乱、缓慢、不稳定或步骤过多的流程。

### 证据边界
说明这组样本无法证明什么。
```

原文引用适合保留在研究笔记中。要把用户表达用于公开文案时，尽量改述。只有在拥有必要背景和使用许可时，才直接引用原句。

## 2. 分析定价，但不要为了找机会而曲解它

定价页可以显示明确的功能限制，但很容易被错误比较。月付和年付价格可能不同。有的产品按账号收费，有的按用量收费。地区和税费也可能改变总价。

比较前，先记录页面日期、币种、地区、计费周期、计费单位和套餐限制。

### 提示词 2：定价与套餐分析

```markdown
你正在分析 [竞品名称] 的公开定价和套餐结构。

只能使用下面提供的信息。没有列出的功能，不要自行判断它是包含还是不包含。

定价记录日期：[日期]
币种和地区：[币种 / 地区]
计费方式：[月付、年付、按账号、按用量或其他]

定价资料：
"""
[粘贴相关定价表、套餐限制和超额费用。不要粘贴整页 HTML。]
"""

规则：
1. 只有计费周期和计费单位一致时，才能直接比较价格。
2. 数据允许时，同时给出可比套餐之间的价格差额和涨幅百分比。
3. 分开说明固定费用、按账号费用、用量费用和超额费用。
4. 页面没有写明的功能或限制，标记为“所提供定价资料未说明”。
5. 没有用户证据时，不要把某项限制写成不公平、随意或不适合用户。
6. 无法完成某项比较时，写“缺少可比较的数据”。

请输出：

### 已写明的功能门槛
列出明确限制在更高套餐中的功能。

### 可比较的价格变化
每项包括：
- 比较的套餐
- 计费单位
- 价格差额
- 可以计算时给出涨幅百分比
- 增加的用量或功能

### 值得继续调查的套餐错配
如果某项核心功能必须与团队管理或治理功能一起购买，请列出这些情况。除非用户证据证明它确实造成问题，否则标记为“待验证假设”。

### 入门付费套餐的限制
只根据明确写出的信息制作表格。证据支持几行就写几行，不要为了凑数补全缺失项。

### 证据边界
说明仅凭这张定价页无法得出哪些结论。
```

输出结果可能指出一个值得继续调查的用户群，但不能证明他们愿意购买另一个产品。

## 3. 把更新日志当作公开公告，而不是内部资源报告

公开更新日志只能说明公司选择公布了什么。它不能完整反映研发投入、维护工作或内部优先级。

你仍然可以把近期更新与产品当前主张放在一起比较，但要缩小结论范围，并记录样本覆盖的时间。

### 提示词 3：比较更新日志与产品主张

```markdown
你正在比较 [竞品名称] 的公开产品主张和更新日志。

只能分析下面提供的文字。更新日志是一份经过选择的公开记录，不是全部研发工作的清单。

当前产品主张：
"""
[粘贴 2-4 条当前首页或产品页主张，包括功能承诺或定位表达。]
"""

更新日志样本：
"""
[粘贴带日期的更新记录。只粘贴更新文字，不要粘贴整页 HTML。]
"""

规则：
1. 写明样本中最早和最晚的日期。
2. 只描述这段时间公开宣布的内容。
3. 某项功能没有出现在样本中，不等于它被忽视、停止维护或放弃。统一写“本次样本未记录”。
4. 每条更新只分配一个主要类别。确有必要时，可以再加一个次要类别。
5. 不要推测团队规模、研发投入、路线图优先级或客户采用情况。
6. 文字不足以支持比较时，写“所提供文字中的证据不足”。

请输出：

### 样本范围
说明分析了多少条记录，以及覆盖的日期范围。

### 公开宣布的工作方向
按产品领域或用户流程分组，并统计这组样本中的公告数量。

### 更新类型
给每条更新分配一个主要类别：
- 稳定性改进或 Bug 修复
- 流程改进
- 管理或治理功能
- 集成
- 面向用户的新功能

### 与当前产品主张的关系
针对每条主张，标记相关工作是：
- 本次样本有记录
- 本次样本未记录
- 信息过于模糊，无法分类

### 证据边界
说明公开更新日志无法证明什么。
```

这项分析更适合帮你提出下一步问题，例如：产品近期更新后，某个流程是否仍然让用户觉得麻烦。不要把它写成“竞品已经停止投入某项功能”。

## 4. 把社区表达变成待验证的定位

社区讨论可以显示用户遇到问题时会怎么描述它。这些表达有助于理解用词和场景，但抱怨帖本身不能证明市场需求，也不能证明你的产品效果。

### 提示词 4：基于证据生成定位思路

```markdown
你要帮助一位独立软件开发者，把社区调研整理成待验证的定位思路。

只能使用下面提供的评论。不要使用你对竞品、品类或开发者产品的外部知识。

社区评论：
"""
[粘贴 5-10 条简短的公开评论或问题。先删除个人信息，不要粘贴整页 HTML。]
"""

可选的产品证据：
"""
[粘贴测试结果、演示观察或已经核实的产品能力。没有就留空。]
"""

规则：
1. 把用户问题与开发者自己的产品主张分开。
2. 一条评论可以支持痛点，但不能证明开发者的产品已经解决了它。
3. 没有证据支持的结果或对比，标记为“待验证假设”。
4. 保留用户使用的技术词，但没有许可或足够背景时，不要把有辨识度的原句直接放进公开文案。
5. 评论只支持少量思路时，就减少输出数量。
6. 没有足够发现时，写“所提供文字中的证据不足”。

请输出：

### 有证据支持的问题描述
最多列出三个问题。每项附原文引用，并在原文提及时说明相关用户或流程。

### 候选标题
最多写三个简明标题，并为每个标题标记：
- 有证据支持：痛点和承诺的产品结果都有证据
- 待验证假设：产品结果还没有被证明

### 对比假设
制作一张表，包含：
- 用户任务
- 已观察到的摩擦
- 可能更简单的做法
- 证据状态

### 下一步要验证的问题
列出阻碍开发者公开做出确定主张的最小问题集合。
```

## 一个简短示例

下面四条评论是虚构示例，只用于演示这套方法如何工作，并不来自任何真实产品的用户。

```text
评论 A：“工作区数据较多时，CSV 导出会超时。”
评论 B：“完整导出会失败，我们只能拆成几批处理。”
评论 C：“我们升级套餐只是为了 API 权限，不是为了更多账号。”
评论 D：“第一次同步前，设置流程要经过好几个页面。”
```

比较克制的分析应该得到以下结果：

| 发现 | 状态 | 证据 | 可以怎么说 |
| --- | --- | --- | --- |
| 大量数据导出可能失败，或需要分批处理 | 重复出现的信号 | 评论 A 和 B | 这组样本中有两条评论提到大量数据导出问题 |
| API 权限可能与不需要的容量绑定 | 个别线索 | 评论 C | 一位评论者表示，升级是为了 API 权限，而不是更多账号 |
| 设置流程可能步骤过多 | 个别线索 | 评论 D | 一位评论者认为初次设置流程较长 |

这组样本支持继续调查导出稳定性，但不支持“多数客户都因为导出故障而离开”这种说法。它也不能证明一款更简单的竞品就能赢得这些客户。

下一步是从另一种来源寻找同类导出问题，与遇到问题的用户交流，再测试自己的产品能否稳定处理对应的数据量。完成这些检查后，才能把发现写成产品承诺。

## 从线索走到可信的定位

四个提示词只能生成一次调研快照。可以按下面的顺序继续推进：

```text
收集公开材料
    |
    v
提取有来源支持的线索
    |
    v
区分重复信号和个别线索
    |
    v
用另一种来源核对重要发现
    |
    v
通过用户交流或产品测试验证
    |
    v
写出范围明确的定位主张
    |
    v
在相关社区讨论中提供帮助
```

### 先选一个具体流程

不要因为评论里出现了很多抱怨，就把它们全部放进产品路线图。先选一个对目标用户真正重要的任务。

### 到其他来源中核对

至少再找一种来源确认同一个问题。如果用户评论、社区问题、产品文档或帮助资料都指向类似摩擦，这个假设更值得调查。但多种来源相互印证，仍然不等于它能代表整个市场。

### 分开验证问题与解决方案

询问受影响的用户：问题多久出现一次？他们现在怎么绕过？付出了什么成本？然后再测试你的产品能否兑现准备公开承诺的结果。痛点证据和产品效果证据不是一回事。

### 写出最克制的真实主张

除非你有公平、最新的对比，否则不要直接说“比某竞品更好”。更稳妥的写法是说明具体任务、已经验证的结果和适用用户。

### 先提供帮助，再介绍产品

参与相关讨论时，先回答问题或提供可行的解决方法。只有产品确实能帮上忙，而且社区允许推荐时，才提到自己的产品。

如果你正在决定把发布精力放在哪里，可以先比较 [Product Hunt、Reddit 和 Hacker News](/zh/blog/product-hunt-vs-reddit-vs-hacker-news) 的特点和限制。

这套流程跑通后，可以把它放进固定的小时间段，避免竞品调研打断产品开发。[独立开发者的每日 30 分钟营销流程](/zh/blog/daily-marketing-routine-solo-founders) 提供了一种安排方式。

## Tomako 可以怎样参与

手动分析适合用来判断哪些信号真正有用。之后更难的工作，是保留这些背景，并把经过筛选的线索整理成团队可以审阅的增长工作。

[Tomako](https://tomako.ai) 是面向软件公司的主动型 AI CMO。它把产品背景和经过筛选的市场信号，整理成团队可以审阅、执行并从结果中学习的增长工作。

Tomako 可以把选中的信号整理成可审核的机会，并准备草稿或后续任务。团队仍然掌握策略、品牌判断和重要外部操作。

可以先用本文提示词手动验证这套方法。工作开始重复后，再[了解 Tomako](https://tomako.ai) 如何协助调研和准备工作。

## 最后检查一遍

公开发布基于竞品的主张前，请确认：

- 每项发现都能回到原始文字。
- 重复信号和个别线索已经分开。
- 已记录样本数量和日期范围。
- 重要假设至少得到另一种来源支持。
- 没有把用户痛点写成自己产品效果的证明。
- 定价比较使用了相同的计费周期和单位。
- 没有把更新日志中的缺失信息当成功能被放弃的证据。
- 公开文案没有超出证据范围。

竞品分析应该帮助你减少不确定性。证据不足时，正确的结果是提出一个更好的问题，而不是写出一个更强的结论。