先说结论这次我们拆的对象不是又一个新模型而是一类经常被忽略的“信息过滤问题”。Hacker News 上有人发布过一条 Show HN 性质的帖子说自己围绕一个创业想法收集了 992 条社区讨论结果一条一条排查下来真正能落到这个想法相关的只有 7 条。很多人第一反应是拿这个结论判断“需求不存在”但如果你做过社区数据抓取应该能理解更真实的挫败感关键词一搜讨论数很多点进去细读大部分是噪声。这个案例的价值不在“992 对 7”这个数字本身而在于它揭示了一条非常常见的数据管线缺陷你以为自己在筛选“相关文章”实际上只是做了“关键词交集匹配”。关键词重叠不代表问题一致问题一致不代表用户已经意识到自己的需求用户有表达也不代表愿意为方案付费。这篇文章会以这个现象为起点拆解一套可以自建的需求信号过滤系统覆盖数据采集、相关性过滤、语义匹配、意图分类、聚类去重、人工复核和定时监控。适合正在做创业想法验证、社区舆情分析、竞品信息收集或者纯粹想搭建“文本噪声过滤器”的读者。需要说明的是下面所有的代码和流程是给你自己搭建分析系统用的通用实现思路不是原帖代码的复刻。你可以把它套用到 HN、技术论坛、Reddit、即刻、V2EX 等任何你能合法读取数据的公开社区上。1. 现象复盘与核心能力速览先复盘这个案例出现的原因。原帖作者面对的场景是自己有一个具体的创业想法然后通过某个或多个社区的搜索、订阅、关键词匹配拿到了大量候选讨论。直观感受是“这个话题很多人聊方向应该有人关注”。但 992 条候选经过细读后真正和 idea 指向同一问题的只有 7 条。这种落差在数据工程里非常常见本质上等于做了一次“召回”和“精确率”的对比维度说明原始召回规模约 992 条候选帖子/评论数字来自原帖作者统计不代表通用标准有效命中规模约 7 条真正与 idea 讨论点重复核心问题关键词碰撞、话题相关不等于问题相关、缺少意图标签、缺少人工复核可复用目标从大规模公开讨论中过滤出与“特定创业想法”强相关的少量信号建议技术路线关键词召回 - 语义向量过滤 - 意图分类 - 聚类去重 - 人工复核建议数据来源Hacker News 公开 API、评论接口、其他公开社区页面的合规导出输入创业想法描述、种子问题列表、竞品关键词列表输出候选帖子清单、相关性评分、意图标签、聚类话题卡、信号登记表API 能力可以封装成检索接口或定时任务脚本批量任务支持批量处理帖子文本开发语言Python 为主单机即可跑通原型合规要求遵守目标平台服务条款、robots、隐私和数据使用边界如果你只是想解决“992 条里挑出 7 条”这个动作最省力的方案不是继续调搜索关键词而是把过滤分成两阶段第一阶段用低价方式找出“弱相关候选”第二阶段用更贵的语义分类模型判断“是否同一个问题”。后文会逐层展开。2. 为什么只有 7 条问题出在过滤链路很多人看到“我收集了 992 条只有 7 条关于我的想法”第一反应是需求太小。但千万别急着否定市场因为你还没有排除链路本身造成的漏报和误报。先看典型的过滤链路从创业想法里取出几个关键词粘贴到搜索框得到候选列表然后把候选列表里的帖子标题扫一遍凭感觉判断相关最后把看起来相关的评论也抓下来数量一多就停止人工筛选。这条链路存在四个问题。第一关键词是“主题标签”不是“问题定义”。比如你的想法是“帮海外独立开发者批量生成产品文档”那么关键词“独立开发者”“产品文档”“SaaS 工具”都能召回大量帖子。但这些帖子可能是在讲定价策略、在讨论开发者社区运营、在问博客写作工具和你真正要解决的“产品文档生成”没有关系。关键词只能确保文本里有相同词不能确保做的是同一件事。第二标题过滤会丢掉大量细节。HN 上很多真实需求信号不在标题里而在评论区。主帖标题是“Ask HN: How do you document your side projects?”评论区里才有人描述自己因为文档不完善流失了多少用户。如果你只看标题这部分会被漏掉。第三缺少“问题是否被你解决”的判断层。一个讨论“文档生成器很难写”的帖子和一个讨论“我已经用 Notion 模板解决了文档问题”的帖子在你看来可能都算相关但前者代表真实需求后者代表替代方案。两者需要分开打标签不能混在一起统计。第四没有做去重和聚类。同一个热门事件可能在多天内有几十条后续讨论。如果不去重你可能把同一个声音重复算成几十个信号放大虚假繁荣如果没聚类你又可能把同一个问题的多种描述理解成不同需求错过真正聚集的痛点。所以一个合格的过滤系统不能直接问“这条帖子跟我的想法相似吗”而要逐步问“它的话题域是否重叠它描述的问题是否相同用户是否在表达具体痛点他是否已经尝试过其他方案他是否愿意为解决方案付费”3. 数据采集先把评论区变成结构化语料要做相关性分析第一步是拿到原始语料。以 Hacker News 为例最常用的方式是通过公开搜索接口。下面用一个通用示例说明采集思路实际使用时要按目标平台最新文档调整地址和参数。3.1 获取候选新闻列表Hacker News 的搜索接口通常支持按关键词和标签过滤。这个阶段不需要太强的过滤重点是把所有可能出现相关讨论的帖子都捞回来宁可多不能漏。import requests import json import time # 替换成你要验证的创业想法关键词 query side project documentation params { query: query, tags: story, hitsPerPage: 100, } resp requests.get( https://hn.algolia.com/api/v1/search, paramsparams, timeout30, ) data resp.json() print(服务端匹配到的候选总数:, data.get(nbHits)) hits data.get(hits, []) for item in hits: print(item.get(objectID), item.get(title), item.get(created_at)) time.sleep(0.1)返回内容通常是 JSON 格式每条记录包含帖子的 ID、标题、作者、发布时间、评论数等。把结果落盘成 JSONL方便后续离线处理mkdir -p idea-signal/data/raw python collect_hn.py idea-signal/data/raw/hn_stories.jsonl3.2 抓取评论和嵌套回复创业需求信号往往藏在评论区所以对初筛后的每个故事 ID需要再拉取评论数据。HN 的评论是树状结构一条评论可能包含多条子评论建议做一个递归抓取。def fetch_item(item_id: str) - dict: # 以 Hacker News 官方 Firebase API 为例 url fhttps://hacker-news.firebaseio.com/v0/item/{item_id}.json resp requests.get(url, timeout30) resp.raise_for_status() return resp.json() def get_comment_texts(item_id: str, max_depth: int 5) - list[str]: texts [] stack [(item_id, 0)] while stack: cur_id, depth stack.pop() if depth max_depth: continue item fetch_item(cur_id) if item is None: continue kids item.get(kids, []) if item.get(type) comment: text item.get(text, ) if text: texts.append(text) for kid in kids: stack.append((kid, depth 1)) time.sleep(0.1) return texts这里要特别注意接口频率和访问限制建议在脚本中加限速。如果你只需要原型验证可以先只抓前 200 条主帖的评论不必把整站跑一遍。3.3 数据清洗思路抓回来的 HTML 文本需要清洗。评论区经常包含链接、引用块、代码块。建议保留代码块因为读者描述技术方案时代码是一种强信号但要把明显无意义的页面噪声、广告内容、重复楼层删掉。清洗阶段还要统一分词大小写和标点。对英文社区可以按空格和标点切分对中文社区需要先用分词工具做粗切分再提取关键词。4. 相关性过滤从关键词召回走向语义过滤清洗后的候选帖子数量可能仍然很大。这时候如果直接送进大模型 API 做判断会因为 token 成本过高而很难持续。更合理的做法是分两层。4.1 第一层关键词 规则召回把创业想法拆成三种词场景词例如“side project”“indie hacker”“产品文档”。问题词例如“documentation is painful”“no time to write docs”。方案词例如“doc generator”“docs as code”“wiki tool”。用这些词做 OR 召回允许候选更多但不要用复杂的负向规则做太强过滤因为早期去掉太多反而危险。SCENE_WORDS [side project, indie hacker, solo developer] PROBLEM_WORDS [documentation, docs, write docs] SOLUTION_WORDS [generator, template, doc tool] def is_weak_candidate(text: str) - bool: text_lower text.lower() has_scene any(w in text_lower for w in SCENE_WORDS) has_problem any(w in text_lower for w in PROBLEM_WORDS) has_solution any(w in text_lower for w in SOLUTION_WORDS) return has_scene and (has_problem or has_solution)这一步做的是“弱相关候选筛选”目标不是精确找出 7 条而是把 992 条先压到几百条。4.2 第二层语义向量相似度规则匹配无法处理“换一种说法”。比如原文写到“nobody wants to maintain a separate website for API docs”和你的想法“用 Markdown 自动生成产品文档”在字面上几乎不共享多少词但语义上有重叠。这时候可以引入文本向量模型。用开源文本向量模型做原型时建议先小批量测试再决定模型和数据量级。下面代码提供一个可替换的骨架。from sentence_transformers import SentenceTransformer import numpy as np # 请替换为实际可用的向量模型名称 # 在英文社区和中文社区可能需要不同模型务必先做小样本验证 model SentenceTransformer(your-embedding-model-name) idea_text Generate product documentation automatically for solo developers candidate_texts [ I spent three hours maintaining API docs for my open source project, Launching a new static site generator written in Rust, ] idea_embedding model.encode(idea_text, normalize_embeddingsTrue) candidate_embeddings model.encode(candidate_texts, normalize_embeddingsTrue) for text, vec in zip(candidate_texts, candidate_embeddings): score float(np.dot(idea_embedding, vec)) print(round(score, 4), text)这里的分数就是一个余弦相似度越高表示与 idea 的向量方向越接近。但直接对整篇帖子做编码会引入大量无关段落比如帖子可能只在前半段讲需求后半段全在聊编程语言选型。因此更稳的做法是先切句再计算每句与 idea 的相似度取最大相似度作为整条帖子的分数并记录是哪一句命中了这个分数。这能让你后来人工复核时快速定位判断依据。4.3 给“真正相关”写清楚标准做语义过滤之前应该先召集项目参与者一起定义“真正相关”的细则。典型的强相关标准可以包含以下几条帖子里存在具体用户描述了当前工作流里的困难。用户明确提到想找一个更好/更自动化的方案。用户描述了自己尝试过的工具并指出它们为何失败。帖子发生在目标用户群体所在的频道或子社区里。不要用“这个话题会不会对我有启发”作为判断标准。如果只凭感觉你会把技术背景文章、竞品新闻、大佬吐槽全都算进来最后又回到“992 条里能看的只有一点点”。5. 从“相关”到“有效需求”意图分类与标签体系经过语义过滤后留下的候选相关性已经比原始集合高很多。但对创业验证来说还不够因为相关讨论并不等于付费意愿。下一步要建立统一的标签体系。5.1 单条讨论的标签字段我建议用下面这一组字段{ source: hackernews, post_id: 123456, text: I never wrote docs for my side project because it always felt like a chore, is_related: 1, pain_signal: 1, has_solution: 0, user_segment: solo_developer, willingness: unknown, timestamp: 2025-01-01T12:00:00Z, matched_sentence: docs for my side project always felt like a chore, reason: explicitly mention docs writing pain and lack of time }is_related是否与 idea 描述的问题域强相关。pain_signal是否明确表达痛苦、低效、时间浪费。has_solution是否提到正在使用或见过的替代方案。user_segment目标用户是独立开发者、小团队还是企业。willingness是否出现过付费或付费意愿相关词。matched_sentence支撑判断的关键句。5.2 人工规则判断与大模型分类结合在量级不大时建议先人工标 50 到 100 条形成示例集再让大模型按示例格式输出标签。这样做有两个好处一是你能发现自己定义的“相关”存在含糊之处二是后续即使要换成开源模型跑也可以用这套人工标签评估效果。下面是一个提示词骨架实际使用时可以按项目情况调整SYSTEM_PROMPT 你是一个需求分析助手。 我会给你一条社区讨论文本和一个创业想法说明。 请判断这条讨论是否与创业想法描述的问题域强相关。 只输出 JSON不要解释。 字段含义 - related: 强相关填 true否则 false - pain_signal: 用户是否表达当前工作流中的困难 - existing_solution: 用户是否提到了替代方案 - key_sentence: 原文中最能支撑判断的一句话 因为社区文本往往杂乱建议不要直接用一条超大文本跑分类先拆句再对关键句分类。5.3 用漏报率校准分类器判断分类系统好坏不能只看“它能报出几条相关”还要关注漏报。原帖里的 7 条如果是靠人工逐条读完才找到的那就说明任何自动化系统都存在把真实信号埋没的风险。建议在建透视表时统计三组数字召回阶段共捞回多少帖子。语义过滤后保留多少帖子。二次人工复核发现但系统漏判的有多少。只要你发现“人工复核总能找到系统漏掉的高价值评论”就说明过滤条件太严格。下一步是降低向量相似度阈值而不是继续加严筛选。6. 聚类与去重把 992 条压成几张“话题卡”相关性判断做完之后剩下的讨论仍然不是等价的。很多时候同一个问题会在不同标题下被反复提起新闻网站也可能批量转发类似事件。如果不去重你最后拿到的“需求数量”会被媒体转载和口水战污染。6.1 聚类思路先把所有强相关文本的向量储存在一个矩阵里然后做聚类。原型阶段推荐用 DBSCAN 这类不需要预设类别数的算法。你可以先看一下不同参数下得出的簇数量再结合人工阅读判断哪个结果最合理。from sklearn.cluster import DBSCAN import numpy as np # embeddings 是过滤后文本的向量矩阵 # 计算文本簇 cluster_model DBSCAN( eps0.35, min_samples2, metriccosine, ) labels cluster_model.fit_predict(embeddings)DBSCAN 的eps和min_samples必须根据实际向量分布调整没有任何一个固定参数能通用。每次调整参数后都需要随机抽样检查簇内文本是否确实在讨论同一件事。聚类结果中标签为-1的往往属于独立话题也要单独进入后续复核池。6.2 生成话题摘要对每一个聚类可以取出最靠近聚类中心的句子也可以把簇内文本喂给文本模型生成一句话摘要。我们需要的是“话题卡”方便快速浏览话题ID: cluster_3 簇内帖子数: 5 代表性发言: I gave up maintaining docs after the second release 核心痛点: 独立开发者没有时间维护文档现有工具需要手工整理结构 替代方案: 提到过 docfx, Notion, mdBook 相关想法: 自动从代码注释和 Markdown 生成站点这样992 条原始帖子会先压到几十个候选簇再去掉明显属于媒体蹭热度或者与技术问题无关的簇剩下需要人工精读的量级通常就很低了。7. 人工复核把“7 条”读成判断依据自动化能帮你缩小范围但创业想法验证里最关键的还是人工精读。这里给出一套可复用的人工复核动作。7.1 建立信号登记表不要只记录“这 7 条跟我的想法有关”要具体回答里面的用户到底在抱怨什么、用什么方案、为什么没有解决。建议用表格管理来源原帖/评论用户身份痛点原文当前方案付费信号与想法的关联点HN 评论“I always postpone writing docs…”solo developer写文档耗时、拖延没写或复制 README无需要零成本的自动文档工具HN 讨论“API docs are outdated after every release”open source maintainer发布后文档不同步手动截屏提到愿意付费需要和 CI 集成的文档生成服务原帖作者提到 992 条候选里只有 7 条真正相关如果这 7 条里大比例都在表达同一个痛点那至少说明“有少数真实用户存在同样感受”但如果这 7 条只是泛泛提到方向没有任何具体痛点、工作流和替代方案那这 7 条其实也不构成有效验证。7.2 用 5 个问题检验每一条对每一条强相关讨论可以按下面 5 个维度打分是否来自目标用户群体。是否描述了具体场景。是否表达当前方案不够好。是否尝试过替代工具。是否愿意为“少花时间/减少痛苦”付出成本。每个问题只填“是/否/未知”不填模糊描述。只有当多条讨论同时命中前三个问题才说明这个方向值得继续做深度访谈。8. 扩展成“创业想法信号监控系统”单次分析只解决一次判断。如果你希望持续观察竞品、用户需求和社区风向可以把上述流程固化成定时任务。8.1 目录结构建议idea-signal/ ├── configs/ │ └── idea.json ├── data/ │ ├── raw/ │ ├── filtered/ │ └── labeled/ ├── logs/ ├── outputs/ └── scripts/ ├── collect_hn.py ├── filter_by_keyword.py ├── embed_and_match.py ├── classify_intent.py └── daily_report.py建议保持原始数据、中间数据和输出数据分开这样修改分类规则时不需要重新爬取也方便审计。8.2 配置文件示例{ idea_name: autodocs, idea_text: Generate product documentation automatically for solo developers, seed_questions: [ How do solo developers maintain product docs?, Why do side projects rarely have good documentation? ], source_communities: [hn], search_queries: [side project docs, api docs maintenance], similarity_threshold: 0.65, report_tz: Asia/Shanghai }8.3 定时执行用法根据你自己的系统环境调整。如果你跑在 Linux 服务器上可以加一条 cron0 3 * * 1 cd /path/to/idea-signal python scripts/daily_run.py logs/daily.log 21建议每周跑一次而不是每分钟。社区讨论不是订单交易系统过度频繁地采集只会增加封禁风险和数据处理成本。9. 接口 API 与批量任务设计如果你不只想自己在命令行里跑还想把这种过滤能力接入到内部工具或定时报表服务可以把过滤模块包成一个 HTTP 服务。9.1 最小的 FastAPI 封装思路下面是一个很通用的服务骨架具体路由和数据字段要按你的项目情况调整from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class AnalyzeRequest(BaseModel): idea_text: str texts: list[str] class AnalyzeResponse(BaseModel): total_input: int related_ids: list[int] clusters: list[dict] app.post(/api/analyze, response_modelAnalyzeResponse) def analyze(req: AnalyzeRequest): # 这里替换成你的相关性过滤与聚类逻辑 pass9.2 批量任务设计采集阶段一定要把批量写入做成“可断点续跑”的。最简单的方案是每次都把处理过的 URL、帖子 ID 或内容 hash 记录到一个本地 seen 文件里下次跑的时候跳过已经处理过的。不要让脚本从头重跑。对每一条候选文本建议记录三个层面的日志第几轮采集。关键词召回了哪些。语义过滤后走到了哪一层。如果调用外部文本分类 API还需要单独记录 token 消耗和请求耗时避免月底账单失控。10. 常见问题与排查方法不同社区的页面结构、接口规则差异很大实际搭建时大概率会遇到下面这些问题。问题现象可能原因排查方式解决方案相关候选太少人工复核后依然只有个位数关键词覆盖不足或采集源太窄查看各关键词命中的帖子数检查是否有重叠把想法拆成 5 到 10 个种子问题再扩到不同社区关键词召回很多但语义过滤后全部被丢掉相似度阈值过高或向量模型不适合该语言/领域抽样看低于阈值的文本降低阈值或换用更适配目标语言的向量模型同一热点事件被重复统计多次没有去重或聚类粒度太粗查看簇内文本是否都是同一链接先按链接去重再按语义聚类分类模型把很多明显不相关的文本判成相关人工标注样本不一致提示词缺少边界情况说明随机抽 50 条人工复核增加“目标用户”和“问题域”两个硬性判断条件评论递归抓取时接口报错请求频率过高或接口路径已变化查看日志中的 HTTP 错误码加限速按官方最新接口调整 URL批量任务中途失败没有断点续跑机制检查已处理列表是否记录完整写一个seen_ids.json下次启动时跳过已处理 ID输出看似合理但无法追溯判断依据系统只记录了最终标签没有保存匹配句回看数据库字段是否保存matched_sentence所有标签都必须附上原文片段11. 成本与性能观察社区文本分析和文本生成不同它的主要成本通常不在推理本身而在“重复处理无价值文本”。所以性能优化的核心是让贵价判断尽可能晚出现。判断逻辑应该按成本递增排列先排除明显与想法无关的帖子成本约等于一次字符串匹配。再对候选做向量相似度过滤成本与帖子数量和向量模型有关。最后才对少量候选做意图分类、聚类摘要和人工精读。如果你用 CPU 跑开源文本向量模型通常需要对文本做批处理不要一条一条 encode。单条循环不仅慢还会成倍增加 Python 调用开销。可以用类似model.encode(list_of_texts, batch_size32)的方式一次处理一批文本。实际能跑的 batch size 和内存占用没有统一答案取决于模型大小和本机配置建议从小样本开始调整。如果你调用外部大模型 API 做分类必须提前压缩文本。一条 2000 字的帖子直接进入提示词会消耗大量 token而且多数段落对判断没有帮助。可以先做句子切分只把包含关键词或与 idea 向量相似度最高的前 3 句送入分类器。还有一个容易被忽视的性能点输出文件要追加写入不要在内存里攒到千万条再落盘。普通笔记本跑千条级数据没什么压力但如果扩大到几十万条建议把抓取和过滤拆成两个独立任务跑完抓取再跑过滤。12. 最佳实践与合规建议社区数据天然包含个人信息和版权内容搭建这类系统时必须注意边界。第一只采集你能合法访问的公开数据。要遵守目标平台的服务条款、robots 协议和接口限制。Hacker News 的开放 API 是典型可公开使用的数据源但其他平台不一定如此。不要为了获取数据绕过登录、验证码或访问限制。如果需要抓取商业平台或付费社区应先获得明确授权或改用官方提供的导出与数据服务。第二不要把原始帖子打包成公共数据集二次发布。你做需求验证时可以记录帖子 ID、URL 和自己写的标签但不要大规模复制全文并公开传播。写入中间结果时可以对文本做裁剪只保留与判断相关的关键句。第三涉及个人身份时要做匿名化处理。社区用户名本身不一定是敏感信息但不要额外关联邮箱、真实姓名、手机号或地理位置字段。如果你要写分析文章尽量引用“某条 HN 评论用户在讨论中提到……”而不直接点出与判断无关的个人信息。第四用分类模型判断商业机会时不要把模型输出当成交的结论。模型只能告诉你“这条文本看起来与某个问题相关”不能替代与真实用户的访谈、问卷和小规模产品测试。尤其是涉及医疗、金融、法律建议等高风险领域必须在结论前增加人工审核环节。第五监控系统如果部署在公网要给接口加访问限制。分析脚本本质上是内部工具不要直接把抓取和分类能力暴露给所有人。生产环境建议放在内网或搭配鉴权服务使用。13. 总结与下一步这个案例最有价值的点不是“7 条说明市场不存在”而是它告诉我们在没有设计过滤系统之前任何大数字都可能只是关键词碰撞的副产品。与其为一个模糊的方向反复争论不如先把想法拆成 10 个具体种子问题然后建一套类似本文的最小脚本去目标社区跑一遍数据采集、关键词召回、语义匹配、意图标注和人工复核。最先应该验证的功能是你看到一条相关讨论时能否写出具体判断理由。如果连这个判断都说不清楚后面的自动化只会放大错误。最容易踩的坑是过早调高相似度阈值导致原本可能找到的信号被过滤掉。建议第一次跑就把所有中间结果保存下来复盘时能清楚看到“哪一环节丢掉了真实需求”。下一步可以扩展的方向有三个一是接入更多来源例如 HN、Reddit、GitHub Issue、产品评论平台做横向对比二是对命中讨论做时间趋势分析观察痛点是否在变强三是把最终判断结果导出成结构化表格直接作为访谈邀约的候选名单。这个系统不建议一开始就追求复杂先跑通“1000 条候选找到几十条值得阅读的讨论”比堆一堆好看但无用的报表重要得多。