# Reddit 上的痛点能验证商业想法吗？

Reddit 上的痛点可以帮助你形成具体的问题假设，再通过符合条件的参与者和可观察的行为来检验。问题假设要说明谁遇到了问题、问题何时发生，以及给他们带来了什么代价。仅凭抱怨无法验证一个商业想法。抱怨出现得频繁，也不能证明存在需求或付费意愿。先检查你已有的帖子，再选择一项测试，并在开始前写明什么结果会构成反对假设的证据。

本指南面向已收集相关公开抱怨、需要选择下一项测试的创业者。最终产出是一张问题证据表和一份小规模验证计划。表中每项判断都附有来源及其局限。计划则说明谁可以参与、你将询问或观察什么，以及何时继续、修改或停止。

两个公开提问有助于说明这一需要。一个问：“你们会用哪些方法研究客户的痛点和需求等问题？”另一个问：“如何在 Reddit 上做客户研究？”这些摘录只能说明有人提出过这些问题。它们不能验证商业想法，也不能衡量需求。所提供的记录缺少这两个帖子的发布日期。[客户研究方法提问](https://www.reddit.com/r/ProductMarketing/comments/1liklfb/best_tactics_for_customer_research)、[Reddit 客户研究提问](https://www.reddit.com/r/SaaS/comments/1tb26ri/customer_research_on_reddit)。

## 从已有证据开始

继续采集前，先人工阅读相关的公开帖子。下一步决策取决于文字背后的问题，而不是搜索结果的数量。

读者提问中说到了客户的“痛点和需求”。请将两者分开研究。痛点描述遇到的困难，需求描述一个人必须达成的结果。两者都不能说明这个人是否会购买你的解决方案。

沿用已有充分理由支持的来源范围。来源范围指你为研究选定的社区和记录。如果你无法说明选择理由，请先阅读[客户研究的 subreddit 选择指南](/zh-Hans/articles/%E5%AE%A2%E6%88%B7%E7%A0%94%E7%A9%B6%E5%A6%82%E4%BD%95%E9%80%89%E6%8B%A9subreddit/)。将该来源范围的局限与证据一同保存。

本指南从选定来源范围之后开始，帮助你把他人报告的问题转化为一项测试。这项测试应有可能表明，你最初的解释是错的。

## 建立问题证据表

### 1. 写出一个问题假设

写明涉及的人、情境、当前的变通办法，以及预期后果。变通办法指一个人在问题存在的情况下，目前用来完成任务的做法。

第一版假设不要包含你提出的解决方案。“团队需要我们的审批应用”已经预设了答案。应当描述实际工作和你怀疑存在的困难。

针对你的假设，补全以下四句话：

1. 负责这项任务的人是……
2. 问题发生在……
3. 这个人目前的应对办法是……
4. 预期的代价或后果是……

将尚未证实的部分标为未知。帖子可能描述了延误，却没有说明谁掌握审批权。不要用你偏好的买家画像填补这一空白。

### 2. 为每项判断附上来源

每检查一个帖子，就为它建立一行证据记录。保存支持你解读的公开原文，并将原文与摘要分开。

保存以下字段。其中一些来自采集结果，另一些是你在检查时添加的笔记。

| 保存字段 | 记录内容 |
| --- | --- |
| 来源标识 | `postId` 和 `canonicalPostUrl` |
| 搜索范围 | `inputQuery`、请求搜索的社区、实际匹配的社区、排序方式、时间范围和结果数量上限 |
| 来源日期 | `createdAt` 和 `observedAt`；缺失的日期标为未知 |
| 公开证据 | `title` 或 `body` 中的相关原文 |
| 证据类别 | 亲身经历、提问、推荐、推广或待定 |
| 人物与情境 | 明确提到的角色、任务和条件；未提及的细节保留为未知 |
| 问题与变通办法 | 所报告的困难和当前的应对方式 |
| 重复发生情况与代价 | 明确提到的频率、时间、金钱或其他后果；保留原文所用的单位 |
| 决策与付费证据 | 明确提到的购买决策权或付费行为；两者分开记录 |
| 检查的局限 | `status`、`unavailableFields`、缺失的上下文及尚未解决的问题 |
| 下一项测试 | 需要检验的不确定之处，以及会构成反对假设证据的结果 |

代价缺失不等于代价为零。发布日期缺失不等于发布日期就是观察日期。购买决策权字段为空，不代表作者没有决策权，只代表你不知道。

在研究笔记中保存选定的查询和采集限制。这样，你就能说明检查过哪些公开记录，而不会让人误以为研究覆盖了所有客户。

### 3. 分类说明每个帖子能证明什么

整张表统一使用以下定义：

1. 亲身经历：作者报告自己经历过的问题。
2. 提问：作者寻求信息。仅凭提问不能证明作者有亲身经历。
3. 推荐：作者建议使用某种产品或方法。
4. 推广：文字在推广某项产品或服务。将其主张与亲身经历的问题叙述分开。
5. 待定：现有上下文不足以支持明确分类。

如果一个帖子包含多种证据，请注明哪一段支持有关问题的判断。不要因为推广内容提到了同样的困难，就将其算作亲身经历。

将功能请求与问题分开。请求增加提醒功能，只是提出了一种可能的应对方式。它不能证明审批为何停滞，也不能证明提醒是否有用。

按你实际检查的单位计数。四则亲身经历的问题叙述，就是四则经历叙述，不是四名已核实的买家，也未必来自四个不同的人。如果重复来源会影响结论，请阅读 [Reddit 研究计数单位检查指南](/zh-Hans/articles/%E6%A3%80%E6%9F%A5%E5%8D%95%E4%B8%AAreddit%E5%B8%96%E6%98%AF%E5%90%A6%E4%B8%BB%E5%AF%BC%E7%A0%94%E7%A9%B6%E7%BB%93%E6%9E%9C/)。

### 4. 列出仍然未知的事项

对每个假设，检查以下五个问题：

1. 问题会反复发生，还是只发生过一次异常事件？
2. 问题造成了什么后果？
3. 当前的变通办法需要付出什么代价？
4. 谁能批准变更或购买？
5. 是否已证实存在付费行为？如果有，是什么行为？

将他人报告的行为与你直接观察到的行为分开。帖子可能说手工操作花了数小时。但在获得进一步证据前，这仍然只是一份公开的个人陈述。

公开得分不等于预算。评论数不等于买家人数。措辞强烈也不能证明损失有多大。

选择最影响下一步决策的未知项。如果你还不知道问题是否反复发生，直接询问价格就跳过了前面的步骤。先检验这个问题是否属于日常工作的一部分。

## 选择可能改变决策的测试

### 5. 写出其他可能的解释

其他可能的解释，是指同一种抱怨也可能出现的其他原因。设计测试前，先列出这些解释。

一则描述生动的抱怨，可能说的是少见事件，也可能涉及免费套餐。现有工作流程可能已经能解决这个问题。作者可能遇到了问题，却没有购买决策权。

不要仅凭措辞选定某个解释。写明什么证据有助于区分这些解释。例如，最近实际发生的事件及其变通办法，可以帮助你区分反复出现的工作问题与一般性的担忧。

### 6. 选择下一项测试

选择能检验主要不确定之处的最简单测试。

| 主要不确定之处 | 拟开展的测试 | 需要记录的证据 |
| --- | --- | --- |
| 问题是否在相关工作中反复发生？ | 征得同意后开展访谈 | 最近一次事件、此前的事件，以及当前的变通办法 |
| 改变流程能否减轻困难？ | 人工工作流程试验 | 已完成的步骤、所需帮助，以及仍然存在的困难 |
| 符合条件的人是否会采取某个明确的后续行动？ | 要求和条件明确的行动承诺测试 | 所要求的行动，以及该行动是否发生 |

访谈是与同意参与的人进行有计划的交谈。人工工作流程试验通过直接完成工作来检验流程。行动承诺测试则在明确说明条件后，要求对方采取一个具体行动。

这些测试回答的问题不同。同意接受访谈不能证明有付费意愿。在你的帮助下完成试验，也不能证明未来的产品无需帮助就能发挥作用。应记录这些条件，不要在结果中将其省略。

公开发布的研究相关帖子，并不代表作者同意你联系他们。请通过征得同意的流程招募参与者。不要自动将来源帖子的作者当作联系人名单。

### 7. 测试前，明确参与条件、问题和失败条件

参与条件是决定谁可以参加的规则。应根据你需要了解的工作来设定。不要要求参与者必须不满当前流程，否则会排除反对假设的证据。

访谈时，围绕实际发生的事提出中立问题：

1. 你最近一次处理这项任务是什么时候？
2. 从开始到完成，发生了什么？
3. 工作有没有停下来？如果有，停在哪一步？
4. 你接下来做了什么？
5. 类似的事多久发生一次？
6. 应对这件事需要多少时间、金钱，或哪些其他工作？
7. 谁能批准对这个流程作出改变？

先问发生了什么，再问对方是否喜欢你设想的应用。将“没有延误”和“不需要变通办法”也视为有效回答。

写出失败条件，即什么观察结果会构成反对假设的证据。同时写明如何处理未完成的测试。没有回应，不等于完成访谈后发现没有问题。

### 8. 根据新证据作出决策

从以下三种后续决策中选择一种：

1. 继续：证据支持再开展一次范围明确的测试。说明仍然存在的不确定之处。
2. 修改：问题存在，但发生条件不同。修改假设中的人物、情境、变通办法或后果。
3. 停止：已完成的测试满足失败条件，或证据已不足以支持继续研究这个假设。

不要用一次结果有利的访谈代表整个市场。对方感兴趣，可以成为继续测试的理由，但不能证明其有付费意向。记录什么结果会改变你的下一步决策。

## 使用 Actor 采集公开帖子

Actor 是托管运行的数据采集程序。Task 是保存好的输入预设。[Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper) 可以根据查询采集公开帖子。其文档列出的输入适用于采集步骤，但它不会替你完成验证方法中的工作。

所提供的小规模采集输入如下：

```json
{"maxResults":3,"query":"invoice approval takes too long","sort":"relevance","subreddits":["smallbusiness"],"time":"year"}
```

使用 Actor 采集公开帖子

这份输入的结构已通过公开模式校验。该模式定义了可接受的输入字段和值。本指南没有付费运行 Actor。这份输入是建议读者采取的操作，不代表已完成搜索，也不代表已观察到结果。

使用前：

1. 将 `query` 替换为描述你所研究问题的措辞。
2. 根据有充分理由支持的来源范围替换 `subreddits`。社区名称不要包含 `r/`。
3. 首次小规模检查时，将 `maxResults` 保持为 3。这是整个运行过程中不重复帖子的数量上限。
4. 检查 `sort` 和 `time`。此处，`relevance` 请求按相关性排序，`year` 请求搜索过去一年的内容。
5. 将完整、准确的输入与证据表一同保存。

模式说明指出，按最高得分和最多评论排序时，`time` 的作用最强。保留请求的时间范围，但不要声称它能保证完整覆盖。搜索排名记录的是搜索顺序，不是问题的严重程度。[公开默认构建版本的数据约定，核查日期为 2026-10-25](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)。

文档列出的输出包括帖子 ID、来源 URL、标题、正文、来源日期、观察日期、状态，以及缺失字段说明。一条保存的记录对应一个公开帖子。该 Actor 不采集完整评论串，也不核实作者是否为买家。需要时，请人工阅读来源的上下文。无法判定的记录应继续保留为待定。

[Reddit Post Customer Language Research Task](https://apify.com/chronometrica/reddit-search-scraper/examples/reddit-post-customer-language-research) 是一个起始预设。其公开页面及预设标识已核查，但未通过所有者权限读取保存的输入，也没有付费运行。使用前，请检查设置并替换示例值。公开页面的存在不能证明运行状态正常，也不能证明研究方法有效。

公开帖子与仅限所有者访问的记录也有所不同。你自己获准使用的工作流程记录，可能有助于核查实际延误或变通办法。请通过获授权的所有者使用这些记录，并单独记录其来源。该 Actor 在文档中明确适用的用途是采集公开帖子。不要将私有审批记录表述为 Reddit 输出。

## 原创虚构示例：从八个帖子到一份测试计划

本操作示例中的所有内容均为原创虚构。计数只用于讲解方法，不是实际采集结果，也没有进行任何访谈或试验。

一位创业者有八个提到发票审批延误的相关帖子。检查来源后，这位创业者记录如下：

| 分类 | 帖子数 | 虚构示例中可确认的内容 |
| --- | --- | --- |
| 亲身经历的反复发生的问题 | 4 | 四则叙述描述了反复出现的困难 |
| 一般性提问 | 2 | 两个帖子提出问题 |
| 推广 | 1 | 一个帖子推广某款工具 |
| 待定 | 1 | 一个帖子缺少足够的上下文 |
| 合计 | 8 | 共检查了八个帖子 |

计算结果为 4 + 2 + 1 + 1 = 8 个帖子。亲身经历帖子的占比为 4 ÷ 8 = 50%，分母是已检查的帖子数。这个百分比只描述该虚构样本，不代表遇到这一问题的客户比例。

创业者记录的是四则亲身经历的问题叙述，不是八名买家。待定帖子的情况仍然未知，不能将其算作已确认没有问题的案例。

虚构假设是：负责发票审批的团队负责人会反复遇到延误，使用变通办法，并因此付出不可忽视的代价。现有证据支持进一步调查问题是否反复发生，但代价的大小、购买决策权和付费行为仍然未知。

创业者在招募前写出以下拟议计划：

| 计划字段 | 拟定规则 |
| --- | --- |
| 测试 | 征得同意后开展访谈 |
| 计划参与者 | 五名符合条件的团队负责人 |
| 参与条件 | 目前负责发票审批，并同意讨论实际工作 |
| 避免筛选偏差的措施 | 参与条件不要求此前有过抱怨或延误 |
| 主要问题 | 最近一次审批事件、重复发生情况、变通办法及后果 |
| 需要记录的观察内容 | 每个人的陈述；获准使用的记录另行核查 |
| 不可忽视的代价 | 测试前定义，例如人工催办挤占了原计划的工作时间 |
| 失败条件 | 五人均未遇到反复发生的延误，也未因变通办法付出不可忽视的代价 |
| 当前结果 | 尚未测试 |

计划测试的计数单位是符合条件的团队负责人。来源检查的计数单位是帖子。计划招募五名参与者，并不会给八个帖子的表格增加五条观察记录。

如果完成全部五次访谈后，发现五人均未遇到反复发生的延误，也未因变通办法付出不可忽视的代价，测试就满足失败条件。这会构成该假设在这组选定参与者中不成立的证据，但不能证明没有人遇到发票审批问题。

如果完成的合格访谈少于五次，请将测试记为未完成。如果有人报告了反复发生的问题，请记录细节和局限。这份陈述可以指导下一项测试，但不能证明对方有购买意愿。

这里没有提供任何访谈结果。有用的产出是计划及其失败条件。

## 提出主张前，先检查记录

作出决策前，完成以下检查：

1. 为每则采纳的问题叙述找到对应的来源原文和 URL。
2. 亲身经历的计数不包含提问、推广和待定帖子。
3. 确认各项合计使用相同单位。不要混合计算帖子数、叙述数和人数。
4. 将缺失的频率、代价、日期和决策权与零或没有区分开。
5. 将拟开展的测试与已完成的测试分开。
6. 将结果与测试前写好的失败条件进行比较。

如果采集结果提供的上下文太少，请修改采集步骤。如果招募时找不到符合条件的参与者，请检查招募途径和参与条件。这两种结果都不能证明问题不存在。

保存决策日期、使用的证据、仍然未知的事项，以及下一步决策。这样可以防止后来的热情取代测试实际证明内容的记录。

## 继续采集前，先写好下一项测试

从证据表中选择一个假设。写明谁可以参与、你需要了解哪件实际发生的事，以及什么结果会让你修改假设或停止验证。访谈或工作流程试验开始前，先征得参与者同意。在获得相关证据前，将付费行为作为单独的问题处理。

如果你需要更多公开实例，可以使用 [Reddit Search Scraper Actor](https://apify.com/chronometrica/reddit-search-scraper) 进行一次范围明确的小规模采集。检查帖子，保留未知项，并用这些材料改进测试。采集为决策提供支持；新证据决定下一步。

## 来源和延伸阅读

- [客户研究方法提问——观察日期为 2026-08-11；发布日期未知；仅提供提问措辞](https://www.reddit.com/r/ProductMarketing/comments/1liklfb/best_tactics_for_customer_research)
- [Reddit 客户研究提问——观察日期为 2026-08-11；发布日期未知；仅提供提问措辞](https://www.reddit.com/r/SaaS/comments/1tb26ri/customer_research_on_reddit)
- [Reddit Search Scraper 公开默认构建版本 2.0.6——核查日期为 2026-10-25；依据文档中的数据约定，未进行付费运行测试](https://api.apify.com/v2/acts/vwOCid7mnPXd0rMTz/builds/default)
- [Reddit Post Customer Language Research Task——核查日期为 2026-10-25；仅确认公开页面存在，未通过身份验证读取保存的输入，未付费运行](https://apify.com/chronometrica/reddit-search-scraper/examples/reddit-post-customer-language-research)