有一个创业想法验证的故事，最近被不少做产品和创业的人拿来讨论：作者说自己围绕一个创业想法收集了 992 条公开帖子，最后逐条看完，真正和自己想做的产品相关的内容只有 7 条。按比例算，0.7%，不到百分之一。
先别急着给这个想法判死刑。我看到很多评论都把这件事当成“需求不成立”的实证，但我不太同意。做搜索式需求调研的人都知道，一个 992 的数字，到底建立在什么关键词、什么平台、什么筛选逻辑上，会得出完全不同的结论。很多情况下，问题不是用户不需要，而是用来发现用户需求的词不对、平台不对、判断口径也不对。
围绕这件事，我会拆三层内容：为什么“相关的帖子”会被数出九百多条，怎么设计一轮能复现的公开帖子调研，以及当你真拿到 7/992 这种难看数字时，下一步到底该怎么走。这篇文章不是教你怎么抄一份创业方法论，而是尽量把筛选过程讲成可操作的动作，适合还没写代码、正在做需求验证的人看，也适合已经做完了产品、发现没人用的朋友对照排查。
1. 992 条帖子只筛出 7 条，先别急着给需求下结论
1.1 你搜的是“行业词”，不是“痛点句”
举一个最常见的场景。假设你的创业想法是：给独立开发者做一个自动整理收入、自动算税的小工具。第一轮搜索时，你大概率会输入“独立开发者收入”“开发者报税”“自由职业记账”这类词。搜出来的是什么呢？是行业经验分享、税务政策新闻、各种记账软件推广、知识付费软文，甚至还有“独立开发者到底多赚钱”的励志长文。
这些内容和你所在的领域有关，但和你的产品假设之间隔着很远。如果你在筛选阶段没有区分“领域相关”和“痛点相关”，最后统计出来的 992 条里，就会包含大量行业资讯、教程和竞品软文。创始人看到 992 会以为自己已经做过一轮完整调研了，实际上真正有信息量的样本可能只有个位数。
我自己的习惯是，看到这类数据时先问一个问题：这 992 条帖子里，有多少条来自目标用户、描述的是自己正在做的事情，而不是作者在谈论某个行业现象？大多数情况，把这个条件加进去，比例会突然变得非常难看。这很正常，因为用户讨论问题时，根本不会使用你预设的产品关键词。
1.2 用户的语言体系里，不会出现你的方案名
第二个常见误区是关键词错位。
还是用自动记账和报税的工具举例。目标用户不会发帖说：“我需要一个自动整理收入和报税的工具，最好是 SaaS。”他们会说的是：“月底对账对到凌晨，头大”“客户打钱到 PayPal 了，到底要不要报税”“Excel 模板怎么改都不对”“去年漏报了一笔收入，罚款比税还贵”。
这些话里没有你的产品名，甚至没有你预想的高大上词汇。如果你只搜索“自动记账”“报税工具”“独立开发者财务软件”，搜出来的大多已经是成熟产品的内容，用户真实的抱怨和求助反而沉在下面。
所以 992 条出来以后，先不要急着分析需求有多大。要看你的搜索词是“方案词”还是“问题词”。方案词能搜出行业内容，问题词才能搜出真实用户。
1.3 真正的“相关”，至少要同时满足三个条件
仅凭“帖子标题里提到了我所在的领域”就判定为相关，样本必然被注水。我建议把相关定义收紧一点，要求帖子回答下面三个问题：
- 发帖人是不是目标用户，还是只是一个行业观察者、媒体人或同行开发者；
- 发帖人是否在描述一个会重复发生、会造成成本或后果的任务；
- 发帖人是否已经有过主动解决行为，例如搜索过方案、尝试过某个工具、或者在做手工替代方案。
如果一个帖子只回答了一两个问题，它可能只是线索，不是直接需求证据。如果三个问题都能回答，那么哪怕只有 7 条，价值也比 700 条行业资讯大得多。
2. 动手收集帖子前，先把创业想法翻译成“问题假设”
2.1 一句话模板：不要写功能，要写用户任务
很多人做需求调研时，喜欢把想法描述成产品形态，例如“我要做一个帮助自由职业者自动记账和报税的工具”。这种描述反过来会影响搜索词，导致你一直在搜自己的解决方案，而不是用户的问题。
更稳妥的做法，是把想法改写成一段用户任务假设，格式可以是这样：
- 目标用户是谁；
- 在什么场景下、什么时间点会被触发；
- 为了完成这件事，现在正在用什么替代方案；
- 这件事多久发生一次，每次花多少时间，做错了有什么后果。
按照这个模板，上面的想法可以改写成：
“独立开发者和自由职业者，每个月会收到来自不同渠道的收入。到了月底，他们需要把收入、支出和税费整理清楚。现在大多数人用 Excel 手工记录，或者等财务代理帮忙处理。这个过程每个月要花两三个小时，而且经常担心漏记、算错、报税逾期。”
请注意，改写结果里没有出现“工具”“自动”“SaaS”这些词，只描述了用户现在任务。这套描述会成为下一步搜索词的重要来源，因为它锁定了场景、行为和代价。
2.2 准备四组搜索词，而不是一组
很多人搜一轮就停，喜欢用单一关键词看结果。搜索式需求调研里，更容易漏掉真实信号。建议至少准备四组词：
| 词类型 | 作用 | 示例 |
|---|---|---|
| 领域词 | 确定大范围 | 独立开发、自由职业、记账、报税 |
| 痛点词 | 找用户的抱怨和求助 | 对账太烦、报销难、收入记录乱、不想手工贴票 |
| 替代词 | 找用户当前的土办法 | Excel 模板、自己写脚本、找代账、用表格记账 |
| 结果词 | 找问题带来的后果 | 算错、漏报、被罚款、发票丢失、月底加班 |
每次搜索都要记录，不要只在脑子里过。最后复盘时，你会想知道 992 条里到底哪几组词贡献了真实信号，哪几组词只是把行业资讯拉进来凑数。
2.3 选择目标用户真的会发言的平台
另一个常见问题是选错平台。开发者工具类和大众消费类产品的公开讨论渠道差异非常大，不能拿一个平台的沉默直接否定需求。
大体上可以按用户类型划分：
- 开发者、工程师、技术人群：GitHub Issues、Hacker News、Reddit 对应板块、V2EX、Stack Overflow、一些垂直技术社区；
- 大众职场人群：知乎、小红书、微博、百度贴吧、垂直行业论坛；
- 传统行业、企业内部流程、制造业场景：公开渠道很少能搜到有效信息，需要去线下活动、行业群或者直接访谈，不能只依赖帖子。
如果你要做的产品面向的是财务代理、企业内部运营、线下餐饮老板这类人群，却只在开发者社区里搜索，搜不到才是正常结果。这时候不要急着否定需求，先把人群和渠道重新对齐。
3. 从 992 条到真正相关的帖子，需要一套可复现的筛选流程
3.1 先建一张信息完整的统计表
在开始阅读帖子之前，先建立一个表格，而不是用浏览器收藏夹收集。每个样本至少包含这些字段：
- 来源平台；
- 帖子链接；
- 发布时间；
- 发帖人 ID；
- 发帖人身份判断；
- 原帖标题或原文摘录；
- 初步判断结果。
保存原话是一条很重要的原则。不要在一开始就替用户“翻译”成你的产品语言，比如看到“每个月记账好烦”就在备注里写“需要自动记账工具”。这种翻译会在后续统计时放大自认为相关的样本，让判断失去可信度。
3.2 用三级标签代替“是/否相关”
筛选时不要只画两个选项：相关、不相关。太粗糙的标注会让真正有价值的样本和大量噪声混在一起。建议至少分三级：
- A 级：真实需求。发帖人是目标用户，描述的是自己正在经历的任务，且带有明确的解决行为或代价描述。
- B 级：线索级。发帖人描述的问题和目标场景有关，但缺少任务细节、行为证据，或者发帖人不确定是不是目标用户。
- C 级：领域噪声。属于行业内容、资讯、教程、招聘、竞品宣传，但与具体问题没有直接关系。
992 条帖子里，真正被筛出来的 7 条，应该尽量落到 A 级。B 级可以用来继续做访谈线索，但单独拿出来当需求证据时，不要高估它的说服力。
3.3 前 100 条帖子用来校准，不要直接冲刺全量
我建议第一次标记时，先抽前 100 条练手。这样做有两个目的。
第一个目的是判断自己的标注尺度是否统一。读到第 80 条时，可能会发现前面把很多行业资讯误标成了 B 级，这时需要回头修正标准。第二个目的是提前判断搜索词是否靠谱。如果连续 50 条都是 C 级，说明当前这组搜索词大概率有问题，应该调整而不是继续硬着头皮把所有结果看完。
不要觉得“必须要看完 992 条才算完整调研”。如果关键词质量差，看完 992 条只是在反复确认无效信息。
3.4 做去重和身份修正
统计的时候还要注意几个去重规则：
- 同一个发帖人，在同一周内到多个板块或平台发同样的问题，只算一个独立样本；
- 同一篇内容被多个自媒体账号转载，应该追溯原始来源；
- 如果发帖人是已有竞品的员工或创始人，这个帖子不能算需求侧的样本；
- 如果一个帖子的评论区里出现了大量真实用户描述自己的经历，评论内容可以单独算样本，但不能整帖算一个。
越早期的需求验证，越要关注“独立发帖人”的数量。一个人因为痛苦而发多帖，说明问题严重；但一个人反复发 10 次内容，不能证明有 10 个潜在用户。
4. 行业热、情绪共鸣和高点赞，都不是真正的需求证据
4.1 行业热是内容供应端推动的，需求热是需求端推动的
很多创业者在看到“大家都在讨论某件事”时，会觉得现在入场时机合适。但真正需要判断的是，究竟谁在讨论。
如果大量讨论来自媒体、投资人、KOL 和行业分析师，那么这属于行业热度，来源于内容供给端。如果没有足够多的目标岗位从业者发帖说“这个问题我每个月都遇到，现在没有好办法”，那么行业热度不会直接转化为你的用户池。
典型例子是低代码和人工智能写作。很多人讨论前景、趋势、市场规模，但真正为某个细分任务买单的客户，并不会因为行业热就支付费用。把“大家都在聊”当成“大家都要买”，是最容易走偏的一步。
4.2 评论区的共鸣，只能证明“处境相似”，不能证明“任务受阻”
还有一种更容易迷惑人的情况：某个帖子描述了生活状态，评论区里几百个人回复“我也是”“太真实了”。
情绪共鸣是需要的，它能帮你判断人群是否存在。但创业产品通常建立在“某个具体任务出了问题”之上，而不是仅仅建立在“某种状态让人难受”之上。
这句话可以作为一个判断标准：
- 状态型发言：“我不想天天加班”“每周写周报好烦”。
- 任务型发言：“我每周要手动从 4 个后台导出数据，再整理成一份周报发给老板，整个过程要花 3 小时，而且经常漏数据。”
前者能引起大量共鸣，但很难推导出支付行为。后者描述了明确的任务链路、时间成本和错误风险，才是产品可以切入的位置。
4.3 高赞、高收藏、高转发反映的是内容指标，不代表购买意向
高赞说明帖子表达方式容易引发共鸣，收藏说明读者觉得内容以后可能有用，转发说明读者认同其中的观点。但这些行为都不等于愿意换掉现有工具，更不等于愿意为新工具付费。
判断需求时，重点看回复里有没有人说到自己的具体经历。比如“我现在用 Excel 做这件事，确实很痛苦”“我试了某某工具，但数据导入格式太死板”“我们团队今年刚踩过这个坑”。这类回复的密度，比帖子的点赞数更有参考价值。
5. 数据难看时，下一步到底该做什么
5.1 先用“问题词”重跑一轮，再判断是不是假阴性
收到 7/992 这个结果后，第一反应不应该是放弃，也不应该是硬撑。要做的第一件事是去看看那 7 条真正的相关帖子，把发帖人描述问题时用的原始措辞提取出来。
还是用记账报税的例子。假设原搜索词是“自动记账工具”“独立开发者报税”，筛出来的相关帖子少得可怜。现在换成人话去搜：“对账到凌晨”“PayPal 报税”“Excel 记账模板”“漏报被罚款”。把这些问题词和替代词组合起来重新搜一遍，结果可能会明显不同。
如果重新搜出来的相关帖子数量明显增加，说明问题确实存在，但你的表达方式、搜索方式或者产品定位出了问题。如果换了问题词和替代词之后，结果依然很稀薄，这时才需要往更悲观的方向考虑。
5.2 检查目标用户是否处于“系统性沉默”
有一类人群不容易出现在公开社区里。
比如企业内部中后台的工具需求、医疗和金融行业内部的流程问题、制造业里偏线下的运营环节，这些场景的用户很少会把痛点发到公开平台上。他们的表达方式是部门内部开会、找供应商询价、让 IT 部门临时写脚本，而不是在社交媒体上吐槽。
如果你的目标用户属于这类人群，公开帖子调研本来就不应该是主要验证手段。正确做法是先通过自己的行业关系、垂直社群或线下展会，找到 10 个以上目标用户做一对一访谈。不要因为公开渠道搜不到就判断需求不存在，这可能只是平台样本偏差。
5.3 真需要放弃时，通常要满足几个条件
经过两轮搜索、多平台排查和若干访谈之后，如果依然没有进展，我会认为这个想法可以暂时放一放。这里有几个更偏向“确认放弃”的判断点：
- 已经换过问题词、结果词、替代词，相关样本依然很少；
- 能找到的目标用户都表示“问题偶尔存在，但能忍”；
- 用户已经习惯现有工具，即使现有方案不完美，也没有切换动力；
- 无法找到 10 个目标用户愿意坐下来认真聊 30 分钟。
只要这几个条件基本满足，7/992 就不再是需求假阳性的问题，而是需求侧的真实结果。这时候继续开发产品，大概率会变成在没人的地方修路，越修越偏。
5.4 如果发现了真实线索，先做小范围访谈，不要直接全量开发
还有一种情况：第二轮搜索后，你找到了多组真实相关帖子，但比例仍然不高。这时候不要急着做完整产品，也不要急着写全功能代码。
比较稳妥的做法，是把那几十个相关帖子里的人约出来访谈。确认三件事：
- 他们描述的问题是否在上一个月内真实发生过；
- 他们目前为了处理这个问题付出了多少时间和多少钱；
- 他们是否愿意先使用一个很粗糙的最小版本，或者愿意为解决方案付费。
等到访谈结果和帖子线索互相印证了，再考虑立项开发。这个阶段投入的工作量不大，但对后续方向的纠偏作用非常大。
6. 复盘时不要只盯着帖子数量，回到几个更有价值的维度
6.1 重新定义分母，别让 992 掩盖真实结构
很多人看到 992 会觉得样本量很大，看到只有 7 个相关会觉得需求不值得做，但实际上这两个数字可能并不在同一个频道上。
992 是用一组或多组关键词从某些平台拉回来的结果，其中可能包含了大量重复转载、行业资讯、竞品宣传和弱相关话题。如果你不重新计算清理后的分母
