每一位准备做独立产品、Side Project 或早期创业验证的开发者都会遇到相同的痛点你以为自己的点子很新鲜结果上线后才发现同类产品已经扎堆你担心点子太偏门没人需要结果搜遍社区找不到几个可参考的样本内心反复摇摆。最近有一个很值得玩味的实验有开发者为了验证自己的创业想法把 Hacker News 的 Show HN 板块里与自己同领域的 992 条帖子全部抓下来做了分析最后发现真正和自己的 idea 构成竞争关系的只有 7 条。换句话说在 992 条“看起来相关”的样本中真正同一赛道的产品不足 1%。这个结果听起来很励志但更值得关注的是背后一套可复用的技术方法用公开 API 获取数据、用关键词召回候选集、再用语义相似度做竞品级判断。这篇文章会把整条链路拆开来讲包含 Python 代码、Hacker News API 的使用细节、数据清洗思路和常见坑点各位做产品验证、技术调研或早期竞品分析的同学可以直接拿去复用。1. 为什么用“992 条帖子”做数据调研而不是直接搜关键词1.1 Show HN 是什么为什么是天然的验证场Hacker News简称 HN是海外技术圈知名度很高的社区以技术、创业、人工智能话题为主。HN 上有一个特殊标签叫 Show HN专门提供给独立开发者、小团队或创业者展示自己刚做出来的产品原型、开源项目或在线服务。Show HN 的价值在于发帖人通常既会描述产品解决什么问题也会在评论区接受来自全球技术用户的第一轮真实反馈。这里的数据恰好具备较强的“创业样本”属性比纯搜索流量关键词更适合做早期市场验证。对方法而言Show HN 还是一个开放的数据源。HN 对外提供官方 Firebase API 和第三方的 Algolia Search API这意味着我们不需要爬虫、不需要登录只需要少量 Python 代码就能把指定时间段内的帖子标题、正文、链接、发布时间、评论数全部拉下来。1.2 关键词搜索的典型误区多数人验证点子时第一反应是在搜索引擎里输入几个自认为精准的关键词比如“AI 写作助手”“团队周报机器人”。这种做法的结果通常不稳定关键词太宽比如“AI 工具”会召回到大量无关产品。关键词太窄比如“基于知识库的自动化周报生成”又会漏掉使用不同表达方式的同类产品。英文和中文表达差异、不同赛道叫法差异、产品早期定位描述不标准都会造成漏检。也就是说关键词搜索解决的是“有没有人提到某个词”但验证创业点子需要回答的是“有没有人在做和我一样的事情”。这是完全不同的两个问题。1.3 从 992 到 7用数据反向验证市场空白那位开发者的思路比较聪明他没有用一两个关键词去试探而是把自己所属领域的帖子整体拉下来再通过“方案级匹配”逐条判断。最终的结果包含两层含义992 条帖子说明这个领域的讨论热度并不低至少有大量开发者在关注或尝试。只有 7 条真正和自己的方案类似说明当前供给端并没有被巨头完全覆盖仍然存在差异化空间。这个方法的启发是不要依赖“搜一下没几个结果”来做决定而要把相关领域整体数据拿回来用一套清晰标准判断“竞争密度”。接下来我们就用 Python 把这一整套流程还原出来。2. 数据获取从 Hacker News API 拉取海量帖子2.1 明确这次分析的目标字段在做采集前先确定要搜集哪些信息。以 Show HN 帖子为例至少需要包含帖子 ID唯一标识便于后续去重。标题产品定位的核心文本。URL帖子指向的落地页或 GitHub 地址。正文/描述很多 Show HN 会在 text 字段里补充产品说明。创建时间用于判断产品出现的早晚。评论数、得分间接衡量社区关注程度。这些信息在 HN API 中都由 JSON 字段直接提供采集工作并不复杂。2.2 环境准备与版本说明本文示例使用 Python 3.9 以上环境需要用到的第三方库如下requests发起 HTTP 请求。pandas做数据清洗与分析。sentence-transformers生成文本向量用于语义相似度计算。scikit-learn备用也可以用来做 TF-IDF 特征提取。在终端执行安装命令pip install requests pandas sentence-transformers scikit-learn版本不必刻意锁定最新版。sentence-transformers 在不同机器上对 torch 版本有要求建议用虚拟环境安装python -m venv hn_research source hn_research/bin/activate # Windows 下执行 hn_research\Scripts\activate pip install requests pandas sentence-transformers scikit-learn2.3 用 Algolia Search API 拉取 Show HN 帖子HN 官方 API 的地址是https://hacker-news.firebaseio.com/v0/它适合按 ID 获取单条数据。更便捷的是 Algolia 提供的 HN Search API可以直接按查询条件搜索。本次场景是通过搜索 API 获取标签为show_hn的帖子。基础请求地址如下https://hn.algolia.com/api/v1/search_by_date?tagsshow_hnhitsPerPage1000先来看一个简化版采集函数它可以按时间范围和标签抓取数据import time import requests import pandas as pd def fetch_show_hn_posts(tagshow_hn, pages10): 通过 Algolia Search API 抓取 Show HN 帖子 :param tag: 固定为 show_hn :param pages: 抓取多少页每页最多 1000 条 base_url https://hn.algolia.com/api/v1/search_by_date all_hits [] for page in range(pages): params { tags: tag, page: page, hitsPerPage: 1000, } try: resp requests.get(base_url, paramsparams, timeout20) resp.raise_for_status() data resp.json() hits data.get(hits, []) all_hits.extend(hits) # 如果返回数量小于 hitsPerPage说明已经到末尾提前结束 if len(hits) 1000: break except requests.exceptions.RequestException as e: print(f第 {page} 页请求失败: {e}) break time.sleep(0.5) # 控制频率避免触发限流 # 只保留需要的字段 records [] for hit in all_hits: records.append({ object_id: hit.get(objectID), title: hit.get(title), url: hit.get(url), text: hit.get(story_text) or , created_at: hit.get(created_at), points: hit.get(points) or 0, num_comments: hit.get(num_comments) or 0, author: hit.get(author), }) df pd.DataFrame(records).drop_duplicates(subset[object_id]) return df if __name__ __main__: posts_df fetch_show_hn_posts(pages20) print(f共获取 {len(posts_df)} 条 Show HN 帖子) print(posts_df.head())这段代码需要注意几个细节Algolia API 默认单页最多 1000 条通过page参数翻页。search_by_date会按时间倒序排列适合抓最近一段时间的帖子。想看最热门结果可以改用search接口。每次请求之间加time.sleep(0.5)避免访问过于频繁导致 IP 被临时限流。story_text字段可能为空要用空字符串兜底否则后续清洗会报错。这里暂时用的“翻 20 页”可以根据实际需要调整。理论上只要 HN 上存在足够多的 Show HN 帖子就能不断翻页直到拿完目标数量。3. 数据清洗把 992 条帖子变成可分析的结构化文本3.1 清洗目标原始推送数据里存在很多干扰项比如标题中的营销话术类似 “Show HN:” 前缀。大量 HTML 标签残留部分帖子的 story_text 内部包含p、a等标签。空值、重复值、纯表情标题。大小写、缩写不统一。所以清洗阶段要完成三件事去前缀、去 HTML、去干扰字符然后拼接出一个干净的analysis_text字段后续关键词提取和向量化都基于这个字段。import re import html def clean_text(text: str) - str: if not isinstance(text, str): return # 去掉 HTML 标签 text re.sub(r[^], , text) # 反转义比如 amp; 转成 text html.unescape(text) # 去掉多余的空白和换行 text re.sub(r\s, , text).strip() return text def build_analysis_text(row): # 把标题和描述拼在一起让文本信息量更大 title clean_text(row[title]) text clean_text(row[text]) return f{title}. {text}.strip() df load_posts_from_csv() # 假设你已经把采集结果存成了 CSV # 下面两行是示例读取实际按自己保存路径调整 # df pd.read_csv(show_hn_posts.csv) df[analysis_text] df.apply(build_analysis_text, axis1) # 去掉明显没有内容的记录 df df[df[analysis_text].str.len() 10] print(f清洗后剩余 {len(df)} 条有效数据)多说一句为什么要把标题和描述拼在一起因为 show HN 发布者会在标题里写“Show HN: 一个自动整理会议纪要约会的 AI 助手”正文里写“我们使用语音转录 大语言模型生成结构化摘要”。标题描述了定位正文描述了方案。只分析标题容易漏掉关键信息只分析正文又可能引入太多背景噪音。两者合并后再做匹配召回率会明显提升。3.2 给帖子打上“领域候选集”标签现在数据是干净了但如果直接用 992 条全量数据去算语义向量很容易造成后续误判。比较稳妥的做法是先构造一个领域词表把明显不属于本领域的帖子剔除。比如目标领域是“团队协作 会议效率工具”那可以先做一轮粗筛。domain_keywords [ meeting, 会议, team, 团队, collaboration, 协作, agenda, 日程, transcript, 转录, action item, 待办, zoom, slack, calendar, 日历 ] def is_in_domain(text: str, keywords) - bool: lower_text text.lower() for kw in keywords: if kw.lower() in lower_text: return True return False df[in_domain] df[analysis_text].apply( lambda x: is_in_domain(x, domain_keywords) ) candidate_df df[df[in_domain] True] print(f领域粗筛后保留 {len(candidate_df)} 条)这一步的价值在于把样本从 992 缩小到所有与你主题相关的候选集。例如原帖里提到的 992 条是某个大行业的数据经过“领域粗筛”后可能剩下 100 多条下一步的语义计算压力就小很多。要提醒的是关键词表必须根据实际目标定制。英文关键词建议用小写匹配中文关键词注意分词问题。如果帖子本身以中文为主可以再用 jieba 分词后做匹配。4. 初筛方法从“相关”走向“同类”4.1 为什么必须做两层筛选关键词模糊匹配只能回答“帖子所在领域是否和你相关”不能回答“帖子里的产品是否和你构成直接竞争”。举例来说你正在做一个“用 AI 自动为设计师生成配色方案”的产品而某条 Show HN 帖子是“为团队提供统一的设计规范管理平台”。两者都包含“设计”“团队”但你的核心方案是 AI 生成工具对方的方案是流程协作平台用户场景并不一样。所以完整流程应该是领域粗筛先找出潜在相关帖子解决“别漏掉”的问题。方案级判断再判断每个帖子是否真的和你的 idea 对应同一需求、同一解决方案。4.2 规则 关键词的“方案级初判”在做向量化之前可以先用更精确的条件组合把候选集进一步缩小。核心思路是不仅要命中原领域关键词还要命中“方案特征词”。假设你的点子描述是“用语音快速记录灵感并自动整理成结构化文档”可以拆成三个维度输入方式voice、speech、录音处理能力transcribe、classify、summarize、自动整理输出形态note、doc、knowledge base、结构化候选帖必须至少命中其中两个维度才算进入“强候选”。def is_similar_solution(text: str): lower_text text.lower() input_kw [voice, speech, recording, audio, 语音, 录音] process_kw [transcrib, summar, classif, extract, transcript, 转录, 摘要] output_kw [note, document, knowledge, structure, 笔记, 文档, 结构化] hit_score 0 if any(kw in lower_text for kw in input_kw): hit_score 1 if any(kw in lower_text for kw in process_kw): hit_score 1 if any(kw in lower_text for kw in output_kw): hit_score 1 return hit_score 2这种简单计分方式能帮你快速把“完全不相干”的帖子过滤掉保留需要细看的内容但它仍然无法覆盖“换一种说法却做同样事情”的帖子。5. 语义匹配让机器判断“这是不是同一个点子”5.1 从 TF-IDF 到语义向量的必要升级关键词方案的短板上文已经说过文字表达差异大时容易漏。怎么解决把文本变成向量。以 TF-IDF 为例它仍然基于词频统计。如果竞品把 “speech to text note” 写成 “transcribe audio into markdown”词表面重合度不高但语义相似。这时就需要用预训练语言模型生成句向量再用余弦相似度衡量文本之间的距离。这里推荐使用sentence-transformers。它会将整句编码成一个固定维度向量适合做短文本语义召回。模型选型默认使用all-MiniLM-L6-v2体积小、速度快在本机没有 GPU 也能运行。from sentence_transformers import SentenceTransformer model SentenceTransformer(all-MiniLM-L6-v2) # 把你的产品 idea 写成一个说明文本 my_idea ( An AI voice assistant that turns meeting recordings into structured documents and action items. ) # 候选文本是初筛后剩余的 analysis_text candidate_texts candidate_df[analysis_text].tolist() idea_embedding model.encode([my_idea], normalize_embeddingsTrue)[0] candidate_embeddings model.encode( candidate_texts, normalize_embeddingsTrue, show_progress_barTrue ) sim_scores [] for emb in candidate_embeddings: # 余弦相似度因为已经归一化可以用点积计算 score float(emb idea_embedding) sim_scores.append(score) candidate_df[similarity] sim_scores top_similar candidate_df.sort_values(similarity, ascendingFalse) print(top_similar[[title, similarity]].head(20))这段代码的运行结果是给每条候选帖一个 0 到 1 之间的相似度分数。分数靠前的往往就是真正在做同一类事的竞品。5.2 设置阈值时不要只看分数绝对值经常有读者问相似度超过 0.7 就算同类吗这个结论不能拍脑袋。因为不同模型、不同文本长度下余弦相似度的分布差异很大。更靠谱的做法是先看降序排名关注 Top 10 到 Top 30 的条目。按分数画出直方图寻找明显断档的位置。最后人工查看 Top 结果的 title 和 url做一次“人工复核”。那位开发者从 992 条里筛出 7 条不可能只靠一个相似度阈值一定还结合了方案拆解和人工识别。语义模型可以提升效率但不应该完全替代人的判断。5.3 辅助判断规则除了文本相似度还可以增加两个扩展规则来提升准确率URL 域名重复如果多个帖子都指向同一产品的更新说明是同一条产品线的不同版本应该归并。作者重复同一开发者多次发布同一产品迭代也应该归并。发布时间接近且标题高度相似很可能是同一产品被多个账号推广属于无效样本。把这些规则合并后可以在原始输出里得到一列分组 ID用来剔除重复产品。6. 完整实战搭建一套“992 → 7”的产品竞争调研脚本6.1 项目结构建议为了便于后续维护建议把代码拆成几个文件hn_research/ ├── config.py # 关键词、阈值、文件路径配置 ├── fetch_posts.py # 数据采集脚本 ├── clean_posts.py # 数据清洗脚本 ├── match_similar.py # 语义匹配主流程 ├── data/ │ ├── raw_posts.csv # 原始数据 │ ├── clean_posts.csv # 清洗结果 │ └── matched_posts.csv # 最终匹配结果 └── requirements.txt这种结构本质上就是一个小型数据处理 pipeline后续想接入定时任务或换成其他数据源只需要替换fetch_posts.py下游代码不用大改。6.2 数据采集脚本完整代码fetch_posts.py的核心是拉取大量 Show HN 帖子并保存到 CSV。Algolia Search API 设计得很友好抓取代码不多。为了让代码具备真实复盘价值这里给出一个带时间范围控制的版本import time import requests import pandas as pd HN_SEARCH_URL https://hn.algolia.com/api/v1/search_by_date def fetch_show_hn_posts(start_date: str None, end_date: str None, max_pages30): 获取 Show HN 帖子。 start_date / end_date 传入 ISO 格式如 2024-01-01 all_hits [] params { tags: show_hn, hitsPerPage: 1000, } if start_date: params[numericFilters] fcreated_at_i{int(time.mktime(time.strptime(start_date, %Y-%m-%d)))} if end_date: current params.get(numericFilters, ) end_ts int(time.mktime(time.strptime(end_date, %Y-%m-%d))) params[numericFilters] f{current},{end_ts} if current else fcreated_at_i{end_ts} for page in range(max_pages): params[page] page try: resp requests.get(HN_SEARCH_URL, paramsparams, timeout20) resp.raise_for_status() data resp.json() hits data.get(hits, []) all_hits.extend(hits) nb_page data.get(nbPages, 0) if page nb_page - 1: break except Exception as e: print(f请求失败: {e}) break time.sleep(0.3) records [] for h in all_hits: records.append({ object_id: h.get(objectID), title: h.get(title), url: h.get(url), author: h.get(author), points: h.get(points) or 0, num_comments: h.get(num_comments) or 0, created_at: h.get(created_at), text: h.get(story_text) or , }) df pd.DataFrame(records).drop_duplicates(subset[object_id]) df.to_csv(data/raw_posts.csv, indexFalse) print(f保存 {len(df)} 条帖子到 data/raw_posts.csv) return df if __name__ __main__: fetch_show_hn_posts()这里用到了numericFilters来过滤时间窗口时间戳需要提前转成 10 位 Unix 时间戳。如果不传时间窗口则默认拉取最新数据。6.3 语义匹配主流程接下来把前面分散的清洗、粗筛、向量化代码合并成主流程。核心逻辑如下import re import html import pandas as pd from sentence_transformers import SentenceTransformer # ---------- 1. 读取原始数据 ---------- df pd.read_csv(data/raw_posts.csv) # ---------- 2. 清洗 ---------- def clean_text(text: str) - str: if not isinstance(text, str): return text re.sub(r[^], , text) text html.unescape(text) text re.sub(r\s, , text).strip() return text df[analysis_text] df.apply( lambda r: clean_text(r[title]) . clean_text(r[text]), axis1, ) # ---------- 3. 领域粗筛 ---------- domain_keywords [meeting, team, collaboration, 会议, 团队, 协作] def in_domain(t): t t.lower() return any(k.lower() in t for k in domain_keywords) candidate_df df[df[analysis_text].apply(in_domain)].copy() # 如果候选集太多可以再加方案维度粗筛这里省略细节 # ---------- 4. 语义匹配 ---------- model SentenceTransformer(all-MiniLM-L6-v2) my_idea ( AI tool that turns meeting recordings into structured meeting notes and action item tracking for product teams. ) candidates candidate_df[analysis_text].tolist() if candidates: idea_vec model.encode([my_idea], normalize_embeddingsTrue)[0] cand_vecs model.encode(candidates, normalize_embeddingsTrue) candidate_df[score] [ float(vec idea_vec) for vec in cand_vecs ] # 保留候选分数前 50方便人工复核 matched candidate_df.nlargest(50, score) matched.to_csv(data/matched_posts.csv, indexFalse) print(f得到 {len(matched)} 条候选结果已写入 data/matched_posts.csv) else: print(清洗后没有候选文本请检查数据采集是否为空)6.4 运行与预期输出依次执行python fetch_posts.py python match_similar.py第一次运行match_similar.py时会从 Hugging Face 下载all-MiniLM-L6-v2模型需要保证网络可以访问模型下载地址。模型下载完成后后续运行不再重复下载。预期输出会是一张按相似度降序排列的表格前几行可能是title score Show HN: Automatic Meeting Notes 0.873 Show HN: Voice To Action Items 0.841 Show HN: AI Scribe for Standups 0.806 GitHub - teamnote ... 0.782看到这些结果你会直观体会到语义匹配比关键词搜索精准得多那些标题里没有“会议”但实际做会议纪要的产品都能被找出来。6.5 为什么最终只剩 7 条数据再压缩的道理在步骤 6.3 中我们按相似度 Top 50 保存了人工复核候选集。真正要得到“7 条竞品”还需要完成最后一轮人工判断。拿“会议纪要 AI 工具”举例Top 50 里可能有同一作者在不同时间发布的多个迭代版本只算 1 个产品。通用团队协作工具唯一卖点是“支持创建待办事项”不属于 AI 纪要工具。开源 SDK不面向终端用户只能算“基础能力”而非竞品。面向英语教育的语音转写工具和团队会议场景无关。人工复核时我会看三个字段title、text、url。URL 可以快速帮助判断产品形态例如 GitHub 链接对应开源项目产品官网链接对应在线 SaaS应用商店链接对应移动端工具。逐条排除后真正的直接竞品才会从几十条收缩到个位数。所以“992 → 7”并不是模型单次输出而是一套“采集 → 清洗 → 语义召回 → 人工复核”的组合流程。7. 常见问题与排查思路这节里面汇总实际操作中可能遇到的问题。问题现象常见原因解决思路API 返回数据为空tags 参数写错大小写不敏感但内容不对确保 tags 为show_hn采集到重复帖子同一帖子可能出现在多页结果使用 objectID 去重清洗后文本过少很多 Show HN 帖子没有正文不要只清洗正文要和标题合并分析sentence-transformers 下载模型失败网络无法访问模型托管地址提前下载模型到本地目录加载时指定本地路径相似度分数普遍很高候选集里存在大量标题风格相似但主题不同的文本先做领域粗筛再看排名而不仅是绝对值结果里出现同一产品多个版本作者多次发布更新帖按 URL 域名和作者名做去重归并下载模型失败是比较常见的坑解决办法有两种一是提前下载后放在本地目录model SentenceTransformer(/your_local_path/all-MiniLM-L6-v2)二是改用其他预训练模型比如paraphrase-MiniLM-L6-v2如果本地网络对该模型路径可达也可以替换模型名。另外如果分析对象是全中文帖子建议不要直接用英文预训练模型。更合理的做法是使用支持中文的双语模型例如paraphrase-multilingual-MiniLM-L12-v2它对中文语义的理解更可靠。8. 工程建议把“点子调研”变成可持续运行的小工具如果你只是临时验证一个 idea跑一次脚本已经足够。但如果未来会反复验证不同点子建议把流程工程化注意以下几点。8.1 关键词表单独配置不要把关键词散落在代码里建议写到config.py或 YAML 文件中。换一个点子时只需要改配置不用改逻辑。示例配置文件# config.py DOMAIN_KEYWORDS [meeting, team, collaboration, 会议, 团队, 协作] SOLUTION_INPUT_KEYWORDS [voice, speech, recording, 语音, 录音] SOLUTION_PROCESS_KEYWORDS [transcrib, summar, extract, 转录, 摘要] SOLUTION_OUTPUT_KEYWORDS [note, document, structured, 笔记, 文档] SIMILARITY_TOP_K 508.2 数据落盘和增量更新每次抓取不能只存在内存里建议保存原始 CSV。时间跨度变长后可以做增量拉取记录上次最新帖子的时间戳下次只拉取该时间点之后记录。这样可以延续自己的调研历史定期更新市场潜在对手数量。8.3 加入人工标注反馈第一次人工复核后把“判断为竞品”的帖子文本和分数记录下来。如果继续迭代可以把这些真实正样本追加到自动判断规则里。例如把人工认定的竞品标题中的特征词抽取出来更新到关键词表让下一次粗筛更精准。8.4 用最小成本验证“看起来空”的市场当你通过数据发现同领域帖子不少、直接竞品很少时并不意味着一定适合冲进去。还需要结合需求侧判断比如评论区人们抱怨最多的点、帖子下方 Ask HN 相关提问数量、目标关键词搜索热度。数据统计能告诉你“供给端是否拥挤”但产品能否成立仍然需要访谈和落地页验证。8.5 不要为了调研而调研这个流程很容易让人沉浸于分析数据本身迟迟不做决定。请给每次调研设置明确产出要么得出结论“赛道有需求但差异化空间可观”要么得出结论“竞品较多需要换切入点”。调研只是手段降低决策风险才是目的。9. 数据调研之外的边界提醒要用好这套“大量收集公开帖子→分析相似度”的思路有几个边界值得想清楚。第一Show HN 只是一个渠道不代表整个市场。很多成熟产品、闭源产品、企业级产品根本不会出现在 Show HN样本有天然的偏斜。992 条帖子里只有 7 条同类只能说明 Hacker News 这个社区中同赛道供给较少不能直接等同于全球市场空白。第二相似度不等于竞争力。即使只有 7 个同类产品如果这 7 个产品已经把市场口碑做起来或者已经绑定大客户后来者依然困难。反过来就算同类产品很多如果多数是粗糙原型也可能说明用户需求仍然未被满足。第三使用 API 时注意尊重服务条款和访问频率。HN 的公开 API 可以免费使用但也请用合理的请求间隔。不要把脚本设计成每秒几十次的并发抓取这对任何公共服务都不友好。建议单线程、带延时、分批拉取既能保证数据稳定也能维护社区的开放生态。第四如果要把他人的产品文案、图片整理成分析报告对外发布建议只保留文本层面的统计结论和观点不做完整内容搬运。涉及他人项目的具体描述可以给出链接而不是复制全文。验证创业点子的过程有些像做冷启动前的用户调研。数据采集和语义分析只是上半场真正有价值的部分是从大量噪声里找出有意义的信号然后根据这些信号做出一两个关键决定。如果你也准备拿 Show HN、GitHub Trending 或 Product Hunt 做一轮市场判断把这套代码改成自己的关键词和分析对象几个小时就能得到一版可参考的数据报告。对只想快速验证点子的人来说没有比这更经济的方式了。