我最近在 Show HN 上看到一个项目标题写得很直接I built a tool that finds people asking for what you sell。翻译过来就是我建了一个工具帮你找到那些正在询问你所售产品的人。这个标题让我停下来看了好一会儿。因为很多独立开发者都干过类似的事每天去不同平台搜关键词看有没有人正好在问自己卖的东西然后小心翼翼地回复一句。这个工具想解决的就是这种重复劳动。但这个项目真正有价值的点可能不是“找到提问的人”而是它把一种很随意的搜索行为变成了可追踪、可筛选、可执行的销售线索流。换句话说它不是在帮你刷帖子而是在替你维护一条流水线。今天我想从工程角度聊聊如果让我从零搭这样一个系统我会怎么做以及为什么很多人会在第二步就卡住。1. 先搞清楚这个工具真正解决的是哪类重复劳动1.1 手动搜帖子再逐个判断是效率最低的获客方式独立开发者做产品早期最常见的获客方式不是投广告而是去各个社区找目标用户。尤其当你卖的是开发工具、模板、课程、咨询服务这类有明确使用场景的东西潜在客户常常已经在公开讨论里表达了需求。比如你做了一款备份工具就会去搜“备份方案”“数据恢复”“有没有推荐”然后看有没有人正好在问相关问题。找到了以后再点进帖子看上下文判断对方是不是目标用户最后小心翼翼地回复一句“我们刚好在做类似的东西要不要看看”这个流程用起来不难但效率非常低。手动搜索有四个问题时效性差。你不可能每小时都去刷新所有平台很多帖子发布后几小时就沉底了。覆盖面有限。一个人同时盯三五个平台已经很吃力多平台交叉搜索更是浪费时间。结果不稳定。搜出来的内容大量是无关新闻、SEO 文章、旧帖真正的高质量线索可能只占很小比例。没有沉淀。今天看到一条潜在线索只能靠收藏或复制链接明天想复盘转化情况又得重新手动整理。这类工具真正解决的不是“替你找客户”这么简单而是把“搜一下、看一眼、碰运气”变成了一个可以持续运行的流程。它让你不用再刷新页面也能知道现在有哪些人在公开提问。1.2 它本质上是把“客户主动提问”变成结构化信号源如果只从表面看这工具就是一个关键词监控器。但换一个角度想它在做的事情更像是把分散在多个平台的非结构化文字加工成一条条结构化线索。每发现一条潜在帖子工具至少应该记录这些信息原文链接发布时间来源平台作者信息或作者标识匹配到的关键词命中的帖子上下文后续处理状态有了这些字段你就不再只是“看过一个帖子”而是拥有了一条可以排序、筛选、回访、复盘的线索记录。今天发现了什么下周是否跟进三个月后是否产生转化都能查得到。这个区别很重要。手动搜索得到的是“一次性信息”工具得到的是“可积累的数据”。对于做产品的人来说后者才是长期能产生复利的部分。所以我的主判断是这类工具的核心价值不是让你少搜几次而是把销售线索从“即时反应”变成“可运营资产”。1.3 一个容易误判的点搜索词相同不等于意图相同很多人在做这类工具时会犯一个非常常见的错误以为只要把关键词设好匹配到的都是客户。实际上搜索词相同意图可能完全不同。举个例子。你卖的是 CRM 系统关键词是“CRM 推荐”。你会匹配到很多内容但用户意图可能有好几种有人在问“我们公司想上 CRM有没有适合小团队的推荐”——这是明显的购买需求。有人在问“CRM 和 ERP 有什么区别”——这是学习型问题他现在可能没有购买计划。有人写了一篇博客标题是“2025 年 CRM 推荐榜单”——这不是潜在客户而是竞争对手或 SEO 文章。有人在抱怨“我们公司刚换了 CRM好难用”——这可能是机会也可能只是吐槽。如果只按关键词匹配不去判断意图工具就会变成一个噪音制造机。每天推给你几十条消息真正值得联系的却没有几条时间一长你就不想再看了。所以关键词匹配只是第一步真正的难点在于意图分级。这也是我想在下一部分展开讨论的。2. 从最小流程开始第一个版本只做四件事如果你也想做这样一个工具我的建议非常明确不要一开始就想着接五个平台、做 AI 意图识别、搭仪表盘。先把最小流程跑通再慢慢升级。2.1 第一步选一个数据源而不是同时接五个平台先问自己一个问题你的目标客户最常出现在哪里如果你做的是开发者工具可能应该先去 Hacker News 或 Reddit 的开发者板块如果你做的是设计素材Twitter/X 和设计类社区可能更合适如果你做的是本地服务本地论坛或微信群反而是更好的来源。第一个数据源的选择标准不是你熟悉哪个平台而是你的客户最可能在那里“公开提问”。在验证这个假设之前接再多平台都是增加维护成本。从工程经验看只选一个平台还有一个隐藏好处你可以很清楚地观察到匹配准确率。如果同时接多个数据源一旦出现误报你很难判断是关键词问题、平台问题还是某个平台的更新格式变了。2.2 第二步用一个关键词先跑通“采集-匹配-通知”真正开始搭建时不要用一堆关键词。选一到三个高意图的词或短语就够了。比如你是做在线表单工具的可以先搜“form builder alternative”或“recommend a survey tool”这样的短语。不要一开始就用太宽泛的词比如“form”或“survey”否则会命中大量与购买无关的内容。一个最小可用的流程只有四步定时去目标数据源抓取最新内容。用关键词过滤留下可能相关的帖子。将匹配结果写入一个本地文件或数据库。把结果推送到你的通知渠道。这个阶段不需要机器学习不需要自然语言处理甚至不需要数据库。先跑一个星期看看每天能发现多少条内容、多少条是真正值得看的。如果这个比例太差再考虑调整关键词。2.3 第三步把结果交给人工确认而不是自动出击这里要特别提醒一点第一版工具只负责“发现”不负责“联系”。不要做自动私信不要做自动回复更不要做自动加好友。原因很简单社区对广告行为非常敏感一旦被判定为垃圾信息你的账号和产品口碑都会受影响。很多开发者做这类工具看到一个潜在用户就恨不得立刻触达。但我更建议把自动化停在通知这一步。后续是否回复、怎么回复、什么时候回复都交给人工判断。这样看起来是“慢”了但实际效果通常更好。因为一条真诚的、结合上下文的回复远比一百条模板私信有价值。2.4 一个能跑通但别当成生产方案的示例结构这里我给一个非常简化的示例结构目的是帮助你理解整个流程而不是直接推荐用于生产环境。# 示例结构最小可用的线索发现流程 def run_once(): # 1. 获取最新内容通常是最近一小时或最近一天的增量 raw_items fetch_public_posts( sourceconfig[source], sinceconfig[since_time] ) # 2. 用关键词过滤 matched_items [] for item in raw_items: if match_keywords(item.text, config[keywords]): matched_items.append(item) # 3. 写入本地结果方便后续人工查看 save_items(matched_items, output_pathleads.json) # 4. 通知到你的聊天工具或邮件 for item in matched_items[:config[daily_limit]]: notify(item)用一句话概括这个脚本只是把“手动搜索并收藏”变成了“定时搜索并通知”。它可以帮你验证需求但还不算一个完整的销售线索系统。真实的工程实现还需要处理分页、增量游标、幂等去重、失败重试、日志和权限控制。第一次做的时候不必全部上但如果要长期使用这些迟早要补。3. 把关键词过滤升级成销售线索打分跑通最小流程之后你很快会遇到一个新问题关键词过滤确实能找到相关帖子但相关不等于值得联系。这时候就需要引入“信号打分”的概念。3.1 为什么简单关键词匹配一定会淹没在噪音里假设你设置的关键词是“备份工具”。系统确实会找到很多包含这四个字的帖子但这些帖子里有很多只是内容里的顺带提及根本不是核心需求。还有一些是旧帖被搜索引擎抓取后重新出现实际上已经没有时效性了。更麻烦的是同一个词在不同语境下的意图差别非常大。“我想找一个自动备份工具能每小时备份一次”——强需求。“备份工具哪个最好用”——中强需求但未必现在要买。“备份工具的原理是什么”——学习问题基本不是目标用户。“整理了五个备份工具推荐第一个”——竞品内容甚至可能是同行的推广文。布尔过滤只能判断“有没有出现”不能判断“有多相关”。这时候你需要对每条结果做一次打分。3.2 设计一个可调整的信号打分表信号打分的思想很简单把“这像不像一个潜在客户”拆成具体可判断的信号每个信号给一个分数最后按总分排序。你可以从几个维度开始信号类型示例建议分值说明明确求推荐“有人能推荐一个……吗”3最高强度信号说明用户有主动寻找意愿描述使用场景“我们小团队想找一个……”2有具体需求通常离购买更近提到预算“希望价格在 50 美元以内”1预算意识强可能是付费用户表达解决问题“最近一直在找办法解决……”2正在被问题困扰有动力尝试新方案出现竞品名称“感觉 A 工具不好用”1已经了解过市场但可能已有倾向需要谨慎判断纯理论提问“备份工具是怎么工作的”-2学习型问题现阶段不适合作为线索帖子不是来自目标用户来自明显是服务商或写手的内容-3很可能是营销内容不是真实需求这个表只是一个起点不要直接照搬。每个业务的目标用户不同你需要根据自己的经验调整分值。目的是让真正值得关注的帖子排在前面而不是让分数系统代替你思考。打分之后你可以设置一个阈值。比如总分大于等于 4 的实时通知总分在 1 到 3 之间的每天汇总一次0 分及以下直接过滤掉。这样既能减少干扰又不会因为阈值太紧错失机会。3.3 用冷却期和去重避免重复打扰很多人做这类工具一开始不注意去重结果同一个帖子被不同关键词命中三次就连续推送三次。刚开始觉得没什么一周后就会觉得很烦。去重至少要处理两件事内容去重同一篇帖子不管命中多少个关键词只推送一次。作者去重同一个作者在短时间内反复发帖可以合并成一条线索或者设置一个冷却期。冷却期的作用是避免重复打扰。比如同一个用户今天在问“有没有备份工具”三天后又在问“有没有自动同步工具”这不是两个完全独立的线索而可能是同一个人的两个需求。如果你不做冷却期系统会把他当成两个用户来推送长期下来体验很差。在实现上可以用一个很简单的方法以帖子 URL 或者作者标识作为 key记录最近一次处理时间。下次看到相同 key 时如果时间差小于冷却期就直接跳过。3.4 通知分级把高频推送变成日汇总通知设计是很多新手会忽略的地方。第一版工具可能只要收到消息就行但当你把关键词增加到十个、数据源增加到三个之后推送数量会迅速上升。这时候需要做分级通知。我比较推荐这种策略强信号线索实时推送单独一条消息。中等信号线索每小时或每天汇总一次表格形式列出。弱信号或不确定内容不推送只写入待处理列表有空再看。核心原则是工具不应该占用你太多注意力。你打开工具时应该一眼看到最值得关注的几条线索而不是在一百条推送里自己找重点。4. 实际落地时最容易踩的坑这一部分我想集中讲一些真实落地时很容易踩坑的点。如果你只是做一个实验脚本很多问题都不会碰到但只要你想长期使用就一定会遇到。4.1 速率限制、接口权限和条款合规第一个要重视的问题是数据来源的合规性。这类工具通常涉及读取公开平台的内容。在实现时你应该优先使用平台提供的官方 API并遵守平台的速率限制和条款。不要为了“更快”去写爬虫绕过限制更不要去碰登录墙后面的内容。从工程角度你需要关注几个点明确阅读文档中关于自动化访问的规定不同平台要求不一样。保存必要的日志方便排查问题但不要保存不必要的用户个人数据。如果 API 返回了分页和游标一定要按游标走不要暴力翻页。对速率限制要保持保守设置合理的请求间隔避免影响正常访问。这里有一条底线无论技术多方便都不要把公开内容变成骚扰用户的工具。工具负责找线索人负责建立信任。一旦越过这个边界产品口碑和账号安全都会受影响。4.2 误报和漏报的排查链路当系统没有推送、推送太多或推送错误时很多人的第一反应是改关键词。但关键词往往不是唯一原因。我建议按照下面的链路逐层排查。先看现象完全没收到消息。收到太多无关消息。重复推送同一篇帖子。有明确线索却没有被匹配。然后按层排查数据源层接口是否正常返回分页方式是否变了是否因为速率限制导致部分内容没抓到增量逻辑层上次运行时间和当前时间的区间是否正确有没有时候因时区不同导致时间窗口错位关键词层关键词匹配是精确匹配还是包含匹配有没有因为大小写、特殊字符、URL 编码导致匹配失败打分和过滤层是否因为某一个负分信号把强线索误杀了阈值是否设置得太高导致大部分内容被过滤通知层推送通道是否被限流webhook 地址是否变更本地时间和服务器的时区是否一致排查时不要凭感觉修改代码先把每个环节的输出日志打出来。看到哪一步出了问题再针对性修复。4.3 产品边界获客工具不能变成群发工具这是我认为整个项目里最重要的一条边界。技术本身是中立的但使用方式会决定它的口碑。一个“找到正在询问你所售产品的人”的工具如果做成“自动私信所有相关帖子作者”很快就会变成骚扰工具。反过来如果设计成“把线索呈现在人面前由人决定是否回复”它就只是在帮销售和独立开发者省时间整个体验是良性的。我见过一些团队把这类工具当成流量利器设置了大量自动回复话术最后结果是账号被平台封禁品牌在社区里被反复拉黑。原因很简单任何一个社区都不会欢迎“每条相关讨论下面都是你的广告”。所以如果你要做这类工具一定要在设计阶段就明确自动化止步于信息收集和线索呈现人机协同负责后续沟通。一个底线工具可以帮你发现“正在问问题的人”但不能替你做“是否联系、怎么联系”的判断。5. 这类工具的价值边界和一个可复用框架5.1 它适合谁不适合谁任何工具都有适用边界。我的判断是这类“发现提问者”的工具最适合以下几类人。早期独立开发者产品刚上线需要寻找种子用户预算有限愿意花时间在社区里沉淀口碑。小团队销售客单价高、决策链短的产品可以通过直接和用户交流获得线索。内容驱动型产品你的内容本身有能力吸引用户工具只是帮你找到更精准的“对话起点”。专业服务提供者比如摄影师、咨询顾问、外包团队可以通过公开提问发现潜在项目需求。同时它也有明显不适用的情况。大众低价消费品关键词噪音极大很难从公开提问里找到足够多的高质量线索。纯 C 端大流量产品公开社区提问只是极小一部分需求入口效率远低于投放和内容体系。需要极速规模化获客的业务工具找到的线索是分散的、需要一条条处理的不适合作为唯一的增长引擎。选择工具时先想清楚你的产品是“高客单价、低购买频次”还是“低客单价、高购买频次”。前者更适合这种精细化线索发现后者更适合流量型打法。5.2 从单平台原型到多平台系统的判断标准很多人跑通单平台原型后第一反应是赶紧接更多平台。但我更建议先评估一个样本周期再做决定。你可以拿一周的数据作为样本记录这几个指标每天命中多少条内容。真正值得联系的占比有多高。从发现到联系再到产生对话的转化率。每条有效线索平均需要多少人工时间。如果一周下来有效线索只有两三条可能不是平台数量不够而是关键词或数据源没选对。这时候接更多平台结果只是增加了噪音。只有当单平台的流程已经稳定误报率明显下降你才有必要考虑跨平台扩展。而跨平台扩展时一定要先在代码层把数据源抽象成同一种结构这样后续加平台才不会变成维护噩梦。5.3 一个可以用在真实项目里的四层筛选框架最后我把自己过去做类似项目的经验总结成一个框架你可以拿来用。整个筛选过程分成四层来源层只关注目标平台、目标板块、目标作者过滤掉大部分无关内容。文本层用关键词、正则表达式、排除词快速过滤剔除明显不相关的内容。上下文层用信号打分判断意图结合作者历史、发布时间、帖子语境识别真正的高质量线索。人工层由人打开链接阅读原文判断是否值得联系并决定触达方式。这个框架的核心思想是把“找线索”这件事从一层漫无目的的关键词搜索变成层层递进的漏斗。每一层做掉一部分过滤最后让人的注意力集中在最高价值的少数几条上。你可以把它直接套用到自己的项目里。无论是做独立工具、内部销售系统还是做一个简单的本机脚本这个分层方式都适用。结尾那个 Show HN 项目让我印象最深的不是技术难度而是它精准地切中了一个需求在公开信息里找到那些已经表达出需求的人。这类工具真正改变的不是获客速度而是你处理公开信息的方式。它让你从一个临时搜索者变成一个持续接收信号的人。但我也想强调一句工具只会帮你找到“正在问的人”不会帮你判断“应不应该联系”。后一件事最好还是留给人来做。如果你也想做一个类似的系统我的建议是不要一开始就堆功能。先选一个平台设一个关键词让它每天安静地给你推送几条结果。坚持看一个星期你会比任何课程都更了解自己的目标用户到底在问什么。