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

从已有证据开始

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

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

沿用已有充分理由支持的来源范围。来源范围指你为研究选定的社区和记录。如果你无法说明选择理由，请先阅读客户研究的 subreddit 选择指南。将该来源范围的局限与证据一同保存。

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

建立问题证据表

1. 写出一个问题假设

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

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

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

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

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

2. 为每项判断附上来源

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

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

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

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

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

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

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

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

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

按你实际检查的单位计数。四则亲身经历的问题叙述，就是四则经历叙述，不是四名已核实的买家，也未必来自四个不同的人。如果重复来源会影响结论，请阅读 Reddit 研究计数单位检查指南。

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 可以根据查询采集公开帖子。其文档列出的输入适用于采集步骤，但它不会替你完成验证方法中的工作。

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

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

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

使用前：

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

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

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

Reddit Post Customer Language Research Task 是一个起始预设。其公开页面及预设标识已核查，但未通过所有者权限读取保存的输入，也没有付费运行。使用前，请检查设置并替换示例值。公开页面的存在不能证明运行状态正常，也不能证明研究方法有效。

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

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

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

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

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

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

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

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

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

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

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

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

提出主张前，先检查记录

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

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

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

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