竞品分析不一定要从昂贵工具开始。公开评论、定价页、更新日志和社区讨论，已经能提供不少有用线索。下面 4 个提示词会帮你区分重复信号和个别抱怨，跨来源核对发现，再把它们变成值得验证的产品假设。
用户评论和论坛帖子适合帮你发现问题，但不能代表整个市场。要把反复出现的问题和个别抱怨分开。重要发现至少要再找一种来源核对，然后才能用于公开定位。
还有一条很重要：用户的抱怨可以证明痛点存在，但不能证明你的产品已经解决了这个痛点。
| 分析角度 | 输入材料 | 可以帮助你了解什么 |
|---|---|---|
| 评论分析 | 公开用户评论 | 反复出现的流程问题和个别抱怨 |
| 定价分析 | 当前定价页和套餐限制 | 已写明的功能门槛、用量限制和可比较的价格变化 |
| 更新日志分析 |
一套持续运转的 GTM 系统
可免费试用，从你的真实产品开始
| 带日期的更新记录和当前产品主张 |
| 公司在这段时间选择公开了哪些变化 |
| 社区表达 | 公开问题和相关讨论 | 用户如何用自己的话描述问题 |
这些材料只能提供线索，不能直接给出市场结论。把不同来源放在一起，看它们是否指向同一个问题。
二星和三星评论常会写出较具体的使用问题，因为评论者通常真正试过产品。但这仍是一组有偏样本，不能说明某个问题在全部客户中有多常见。
只处理你有权使用的内容。删除姓名和个人信息，保留来源链接供自己核对。把评论交给 AI 前，也要查看平台当前的使用条款。
Eren
SEO/GEO
学习闭环你正在为一位独立软件开发者分析用户评论。
只能分析下面提供的文字。不要使用你对这家公司或产品的外部知识。
竞品名称：[竞品名称]
评论：
"""
[粘贴 15-25 条简短评论摘录。先删除个人信息，只粘贴评论文字，不要粘贴整页 HTML。]
"""
规则：
1. 只有至少两条相互独立的评论提到同一个底层问题，才能标记为“重复出现的问题”。
2. 只有一条评论提到的问题，标记为“个别线索”。
3. 只有评论者明确说自己正在寻找、已经改用或考虑改用其他产品时，才能标记为“寻找替代产品的触发点”。否则标记为“仅为使用摩擦”。
4. 每项发现都要附上原文引用和提及该问题的评论数量。
5. 不要根据缺失信息推测用户意图、市场规模或产品影响。
6. 某部分没有足够证据时，写“所提供文字中的证据不足”。
请输出：
### 重复出现的问题
每项包括：
- 简明描述
- 提到该问题的独立评论数量
- 一到两段原文引用
- 原文提到的使用流程或用户背景
### 个别线索
列出只出现一次、但值得继续调查的问题。不要把它们写成趋势。
### 明确的替代产品触发点
只列出评论者明确表示正在寻找或已经选择其他产品的情况。
### 比预期更难完成的任务
找出评论者认为混乱、缓慢、不稳定或步骤过多的流程。
### 证据边界
说明这组样本无法证明什么。
原文引用适合保留在研究笔记中。要把用户表达用于公开文案时，尽量改述。只有在拥有必要背景和使用许可时，才直接引用原句。
定价页可以显示明确的功能限制，但很容易被错误比较。月付和年付价格可能不同。有的产品按账号收费，有的按用量收费。地区和税费也可能改变总价。
比较前，先记录页面日期、币种、地区、计费周期、计费单位和套餐限制。
你正在分析 [竞品名称] 的公开定价和套餐结构。
只能使用下面提供的信息。没有列出的功能，不要自行判断它是包含还是不包含。
定价记录日期：[日期]
币种和地区：[币种 / 地区]
计费方式：[月付、年付、按账号、按用量或其他]
定价资料：
"""
[粘贴相关定价表、套餐限制和超额费用。不要粘贴整页 HTML。]
"""
规则：
1. 只有计费周期和计费单位一致时，才能直接比较价格。
2. 数据允许时，同时给出可比套餐之间的价格差额和涨幅百分比。
3. 分开说明固定费用、按账号费用、用量费用和超额费用。
4. 页面没有写明的功能或限制，标记为“所提供定价资料未说明”。
5. 没有用户证据时，不要把某项限制写成不公平、随意或不适合用户。
6. 无法完成某项比较时，写“缺少可比较的数据”。
请输出：
### 已写明的功能门槛
列出明确限制在更高套餐中的功能。
### 可比较的价格变化
每项包括：
- 比较的套餐
- 计费单位
- 价格差额
- 可以计算时给出涨幅百分比
- 增加的用量或功能
### 值得继续调查的套餐错配
如果某项核心功能必须与团队管理或治理功能一起购买，请列出这些情况。除非用户证据证明它确实造成问题，否则标记为“待验证假设”。
### 入门付费套餐的限制
只根据明确写出的信息制作表格。证据支持几行就写几行，不要为了凑数补全缺失项。
### 证据边界
说明仅凭这张定价页无法得出哪些结论。
输出结果可能指出一个值得继续调查的用户群，但不能证明他们愿意购买另一个产品。
公开更新日志只能说明公司选择公布了什么。它不能完整反映研发投入、维护工作或内部优先级。
你仍然可以把近期更新与产品当前主张放在一起比较，但要缩小结论范围，并记录样本覆盖的时间。
你正在比较 [竞品名称] 的公开产品主张和更新日志。
只能分析下面提供的文字。更新日志是一份经过选择的公开记录，不是全部研发工作的清单。
当前产品主张：
"""
[粘贴 2-4 条当前首页或产品页主张，包括功能承诺或定位表达。]
"""
更新日志样本：
"""
[粘贴带日期的更新记录。只粘贴更新文字，不要粘贴整页 HTML。]
"""
规则：
1. 写明样本中最早和最晚的日期。
2. 只描述这段时间公开宣布的内容。
3. 某项功能没有出现在样本中，不等于它被忽视、停止维护或放弃。统一写“本次样本未记录”。
4. 每条更新只分配一个主要类别。确有必要时，可以再加一个次要类别。
5. 不要推测团队规模、研发投入、路线图优先级或客户采用情况。
6. 文字不足以支持比较时，写“所提供文字中的证据不足”。
请输出：
### 样本范围
说明分析了多少条记录，以及覆盖的日期范围。
### 公开宣布的工作方向
按产品领域或用户流程分组，并统计这组样本中的公告数量。
### 更新类型
给每条更新分配一个主要类别：
- 稳定性改进或 Bug 修复
- 流程改进
- 管理或治理功能
- 集成
- 面向用户的新功能
### 与当前产品主张的关系
针对每条主张，标记相关工作是：
- 本次样本有记录
- 本次样本未记录
- 信息过于模糊，无法分类
### 证据边界
说明公开更新日志无法证明什么。
这项分析更适合帮你提出下一步问题，例如：产品近期更新后，某个流程是否仍然让用户觉得麻烦。不要把它写成“竞品已经停止投入某项功能”。
社区讨论可以显示用户遇到问题时会怎么描述它。这些表达有助于理解用词和场景，但抱怨帖本身不能证明市场需求，也不能证明你的产品效果。
你要帮助一位独立软件开发者，把社区调研整理成待验证的定位思路。
只能使用下面提供的评论。不要使用你对竞品、品类或开发者产品的外部知识。
社区评论：
"""
[粘贴 5-10 条简短的公开评论或问题。先删除个人信息，不要粘贴整页 HTML。]
"""
可选的产品证据：
"""
[粘贴测试结果、演示观察或已经核实的产品能力。没有就留空。]
"""
规则：
1. 把用户问题与开发者自己的产品主张分开。
2. 一条评论可以支持痛点，但不能证明开发者的产品已经解决了它。
3. 没有证据支持的结果或对比，标记为“待验证假设”。
4. 保留用户使用的技术词，但没有许可或足够背景时，不要把有辨识度的原句直接放进公开文案。
5. 评论只支持少量思路时，就减少输出数量。
6. 没有足够发现时，写“所提供文字中的证据不足”。
请输出：
### 有证据支持的问题描述
最多列出三个问题。每项附原文引用，并在原文提及时说明相关用户或流程。
### 候选标题
最多写三个简明标题，并为每个标题标记：
- 有证据支持：痛点和承诺的产品结果都有证据
- 待验证假设：产品结果还没有被证明
### 对比假设
制作一张表，包含：
- 用户任务
- 已观察到的摩擦
- 可能更简单的做法
- 证据状态
### 下一步要验证的问题
列出阻碍开发者公开做出确定主张的最小问题集合。
下面四条评论是虚构示例，只用于演示这套方法如何工作，并不来自任何真实产品的用户。
评论 A：“工作区数据较多时，CSV 导出会超时。”
评论 B：“完整导出会失败，我们只能拆成几批处理。”
评论 C：“我们升级套餐只是为了 API 权限，不是为了更多账号。”
评论 D：“第一次同步前，设置流程要经过好几个页面。”
比较克制的分析应该得到以下结果：
| 发现 | 状态 | 证据 | 可以怎么说 |
|---|---|---|---|
| 大量数据导出可能失败，或需要分批处理 | 重复出现的信号 | 评论 A 和 B | 这组样本中有两条评论提到大量数据导出问题 |
| API 权限可能与不需要的容量绑定 | 个别线索 | 评论 C | 一位评论者表示，升级是为了 API 权限，而不是更多账号 |
| 设置流程可能步骤过多 | 个别线索 | 评论 D | 一位评论者认为初次设置流程较长 |
这组样本支持继续调查导出稳定性，但不支持“多数客户都因为导出故障而离开”这种说法。它也不能证明一款更简单的竞品就能赢得这些客户。
下一步是从另一种来源寻找同类导出问题，与遇到问题的用户交流，再测试自己的产品能否稳定处理对应的数据量。完成这些检查后，才能把发现写成产品承诺。
四个提示词只能生成一次调研快照。可以按下面的顺序继续推进：
收集公开材料
|
v
提取有来源支持的线索
|
v
区分重复信号和个别线索
|
v
用另一种来源核对重要发现
|
v
通过用户交流或产品测试验证
|
v
写出范围明确的定位主张
|
v
在相关社区讨论中提供帮助
不要因为评论里出现了很多抱怨，就把它们全部放进产品路线图。先选一个对目标用户真正重要的任务。
至少再找一种来源确认同一个问题。如果用户评论、社区问题、产品文档或帮助资料都指向类似摩擦，这个假设更值得调查。但多种来源相互印证，仍然不等于它能代表整个市场。
询问受影响的用户：问题多久出现一次？他们现在怎么绕过？付出了什么成本？然后再测试你的产品能否兑现准备公开承诺的结果。痛点证据和产品效果证据不是一回事。
除非你有公平、最新的对比，否则不要直接说“比某竞品更好”。更稳妥的写法是说明具体任务、已经验证的结果和适用用户。
参与相关讨论时，先回答问题或提供可行的解决方法。只有产品确实能帮上忙，而且社区允许推荐时，才提到自己的产品。
如果你正在决定把发布精力放在哪里，可以先比较 Product Hunt、Reddit 和 Hacker News 的特点和限制。
这套流程跑通后，可以把它放进固定的小时间段，避免竞品调研打断产品开发。独立开发者的每日 30 分钟营销流程 提供了一种安排方式。
手动分析适合用来判断哪些信号真正有用。之后更难的工作，是保留这些背景，并把经过筛选的线索整理成团队可以审阅的增长工作。
Tomako 是面向软件公司的主动型 AI CMO。它把产品背景和经过筛选的市场信号，整理成团队可以审阅、执行并从结果中学习的增长工作。
Tomako 可以把选中的信号整理成可审核的机会，并准备草稿或后续任务。团队仍然掌握策略、品牌判断和重要外部操作。
可以先用本文提示词手动验证这套方法。工作开始重复后，再了解 Tomako 如何协助调研和准备工作。
公开发布基于竞品的主张前，请确认：
竞品分析应该帮助你减少不确定性。证据不足时，正确的结果是提出一个更好的问题，而不是写出一个更强的结论。
