我可以直接坦白说这个项目最开始不是什么宏大规划纯粹是被“找工具”这件事逼出来的。我自己经常需要在一堆 AI 产品里挑一个合适的来干活比如想找个能把长音频快速转成文字的工具、想找个能批量抠图的、想找个能把产品截图直接变成 UI 代码的。结果每次打开浏览器搜出来的是各种博客软文、榜单合集、赞助位内容真正有用的工具链接被埋在一万字的“行业趋势”里面。那种感觉很崩溃花半小时翻完十篇文章最后下载下来的东西跟描述完全两回事。于是我就萌生了一个念头既然通用搜索引擎对“AI 工具”这个垂直品类不够友好干脆自己做一个只搜 AI 工具的垂直搜索引擎。它能理解用户模糊的需求比如“帮我找个能自动给视频加字幕的软件”也能识别具体产品名还能过滤掉那些包装过度的营销页面。这篇文章就聊聊这个项目的原理、设计思路以及我一路踩过的那些坑。先说清楚它是什么。我做的搜索服务本质上是一个限定在“AI 工具/产品/应用/插件”范围内的检索系统。数据层面我用爬虫和人工整理的方式聚合了几千个 AI 产品和工具的信息包括产品名、官网描述、功能分类、使用场景、定价模式、评分、发布动态等。搜索层面它既支持传统的关键词匹配又加入了语义检索能理解“免费的去背景工具”这种自然语言表达而不是傻傻地只匹配“背景”和“工具”两个字。如果你也在做垂直搜索、信息聚合、或者任意形式的垂直内容检索系统这篇文章应该多少有点用。它不涉及复杂的分布式架构也没有高大上的机器学习团队全部选型都以单机可跑、效果可感知为优先。我会把整个系统的核心模块、每一步的选型原因、以及我实际碰到的典型问题都展开讲确保你可以直接照着思路复现一版。1. 为什么锁定“AI 工具”这个垂直赛道它到底难在哪做搜索最容易犯的错误就是一开始想搜万物结果什么都搜不好。我一开始也纠结过要不要做全领域的 AI 内容搜索比如新闻、论文、工具一起搜后来分析了一下自己的真实使用场景发现高频需求还是集中在“找工具、找产品、找实施方案”上。于是我把范围死死限制在 AI 工具和 AI 应用产品里。选这个垂直赛道还有一个很直接的原因AI 工具领域的术语体系非常混乱。同一个功能可能有十几种叫法比如“AI 写作助手”也可以叫“文案生成工具”、“内容生成平台”、“智能写作软件”不同产品之间的功能定位重叠严重用户搜索时用词高度口语化。这些特性让通用搜索引擎很难做好精度但这恰恰是垂直搜索的生存空间。这个领域的难度主要体现在四个方面第一数据源非常分散。这类工具没有统一的行业数据库信息散落在官网、社区推荐帖、应用商店、导航站点、公众号文章里。有的产品不叫“AI 工具”而叫“插件”“扩展”“组件”“平台”命名方式千奇百怪。第二信息更新极快。一个新工具从发布到出现在导航站可能只要几天而索引它往往需要两周甚至更久。通用搜索对“刚上线的小众工具”反应迟钝因为它们的页面权重低、外链少、社交信号弱。第三语义歧义严重。一个产品名可能同时是普通英文单词比如“mind”“chat”“tune”用户搜某个工具名时很容易被同名内容干扰。搜“chat”到底是要找聊天工具还是想搜聊天这个动作机器需要大量上下文才能判断。第四内容噪音高。很多 AI 工具官网充斥着空洞的营销词比如“empower your workflow”“unleash creativity”“supercharge productivity”这些词对用户没有任何实质帮助却会严重干扰检索效果。我把这些问题当成设计目标这个搜索引擎可以不厉害但在“AI 工具”这个特定领域它必须比通用搜索更能听懂人话必须更懂整个产品生态。1.1 面向真实用户场景的需求拆解要理解这个搜索服务的功能范围可以先看看我收集的代表性用户问题“推荐一个能根据图片生成海报的工具”“有没有开源的语音克隆工具”“在线图片无损放大哪家强”“能跑在本地电脑上的大模型对话工具”“剪辑视频时自动消除停顿和语气词的软件”“Stable Diffusion 的 WebUI 和 ComfyUI 区别”这些查询共有的特征是什么它们都不是单纯的产品名检索而是“功能描述型检索”用户在描述一个使用场景期待搜索引擎返回一个可落地的产品。有些查询明确提出了属性要求比如“开源”“本地”“免费”“在线”搜索引擎必须理解这些属性限定词。我也观察到另一个重要特征用户对结果的时效性高度敏感。一款三年前很火的工具如果半年没更新用户其实不太在意它的历史荣誉。他们更关心的是“现在还能不能正常用”“有没有更好的替代品”。因此我在数据模型里加入了“活跃度”和“最近更新”字段并在排序阶段重点考虑。这里有一个看似简单但实际很重要的设计决定我把搜索对象定为“工具实体”而不是“网页链接”。传统搜索引擎检索的是页面而我希望检索的是一个结构化的“产品卡片”包含产品名、别名、简介、分类、标签、定价、开源状态、上屏截图等字段。用户看到的不是一个蓝色链接跳转到官网而是一个可以直接消化信息的产品卡。1.2 现在的搜索结果到底长什么样说这些可能比较抽象我用两个完全虚构的查询来展示预期效果。查询“本地部署的大语言模型对话工具”理想的第一屏结果产品 A开源支持 chat 界面支持 GPU 加速支持 OpenAI 兼容 API最近一个月发布了新版本产品 B开源纯 CPU 可跑适合低配设备有 Web 端和命令行产品 C 商业版提供桌面应用不上传数据提供 API 和企业版私有化部署每张产品卡右上角标明“最近更新”底部展示“开源/闭源”“免费/付费”“本地/云端” 三个通用筛选标签用户可以一键缩小结果范围。查询“AI 去除图片背景”理想结果应该是在线工具免费直接上传输出透明背景 PNG开源模型可以配合 ComfyUI 或 SD WebUI 使用本地处理隐私安全设计平台内置功能适合批量处理但需要订阅而不是用户在搜索框里输入“remove background”之后得到一堆“best background remover in 2024”的榜单文章。正如用户所见这里的关键差异是用户要的不是文章而是能即刻使用的产品。这个原则贯穿了整个系统的设计。2. 数据层的设计从爬虫、解析到结构化工具的实体索引搜索引擎的地基是数据。如果你搜出来的产品只有名字和官网链接那跟一个分类目录没有区别。要让用户有“啊这就是我要找的”的体验你必须把数据变成结构化格式并且能在不同字段上做过滤和排序。这一部分我重点讲数据是怎么来的、怎么清洗、怎么入库。数据来源我划分成三大类第一类是权威站点采集包括各大 AI 导航站、工具聚合库、开源项目库、产品发布平台的公开列表页。这类站点通常结构清晰适合批量采集而且天然带有分类和标签信息。第二类是社区内容挖掘包括技术社区的热门讨论帖、工具推荐帖、栏目化内容。从这类内容里我会用规则加少量模型的方式提取出“产品名 用户评价 使用场景”的三元组。第三类是官网直采。拿到候选工具名单后我会直接访问官网抓取产品名称、简介、特性列表、定价页面、更新日志。官网信息的准确度最高但抓取成本也最大。坦白讲第三类数据是我认为价值最高但最重的部分。因为官网里藏着大量用户生成内容里不会出现的专业信息比如具体支持的语言、部署环境要求、不同版本的功能差异。2.1 为什么把官网描述拆成“能力标签”而不是一整段文字最初我偷懒把整个官网介绍全部丢进索引用户搜“视频转文字”理论上会命中那些描述里包含该词的产品。但这种思路很快暴露了问题很多产品介绍喜欢泛泛而谈“支持多媒体处理”“提供智能解决方案”根本不会老老实实写“我可以把视频转成文字”。于是我做了一个关键调整把每个产品的信息拆成三层字段。第一层是基础属性包括产品名、公司名、官网链接、上线时间、开源状态、定价模式。这类信息非常结构化直接建字段索引。第二层是能力描述从官网的 Features 列表、FAQ、教程文档里抽取生成“能力标签”比如“视频转文字”“字幕翻译”“人声分离”“会议纪要生成”“关键词高亮”。每个标签和主产品是多对多关系。第三层是场景描述从用户评价、社区讨论里提取描述“什么人用这个东西解决什么问题”比如“字幕组用来自动打轴”“自媒体用来找网络热词”“教师用来出试卷”。这个拆分带来的优势非常明显。用户搜“自动给视频加字幕”我会同时在“能力标签”里匹配“视频转文字”“字幕生成”在“场景描述”里匹配“打轴”“加字幕”召回范围更精准。如果你只索引一段文本分词后你根本不知道哪个词属于哪个语义层次检索效果自然差很多。2.2 抓取频率、优先级的安排与存储模型我遇到一个很现实的问题不可能每天把所有官网数据源全部爬一遍。一来有些站做了反爬二来抓取太多边缘页面会浪费大量时间和资源。所以我把待抓取站点按更新频率和重要性分成了梯度。P0 级是核心工具官网要求每周刷新一次官网的动态、更新日志、价格页P1 级是导航站和分类目录要求每周刷新一次列表检查是否有新工具上线P2 级是社区讨论帖和长尾文章按月更新即可主要用于补充场景描述P3 级是无明确时效要求的静态页面入库后基本不主动重抓这个分级策略看似简单实际效果非常好。最重要的更新信息永远优先处理而那些不重要的页面也不会积压在抓取队列最前面。存储层我使用了一种很朴素的组合整体数据放在关系型数据库里维持事务和结构约束面向搜索的字段则在构建索引时同步到检索系统。搜索阶段不会查关系型数据库避免把业务库拖垮。整体数据量在数千个工具实体、数十万个标签记录的量级时单机完全可以轻松承载。3. 查询理解层搜索框背后到底做了哪些处理用户输入“找一个开源的本地知识库问答工具”这句话丢给传统的关键词搜索结果大概率是垃圾。原因在于传统搜索把这句话切成了“开源”“本地”“知识库”“问答”“工具”五个词然后在索引里做布尔匹配结果返回一堆包含这些词的页面但核心需求“知识库问答工具”可能被“工具”这个泛词带偏。我的做法是先做查询理解把用户的自然语言转换成结构化的检索意图然后再去执行检索。这个过程分三步走。3.1 实体识别和同义词扩展第一步从查询里识别出用户提到的具体产品名或明确指向的功能类别。例如“stable diffusion 的插件怎么装”这句话需要识别出“stable diffusion”是产品实体“插件”是资源类型。识别用规则加模型混合的方式规则基于一份不断积累的产品名词典模型则处理那些词典里没有的名称变体。同义词扩展非常关键。同一个功能用户可能有五种表达方式去除背景 - 抠图、去底、删除背景、透明背景视频转文字 - 视频转字幕、自动生成字幕、提取视频文案、语音转文本文字转语音 - TTS、语音合成、AI配音、文本朗读本地部署 - 私有化部署、离线运行、内网安装、本地安装免费 - 无需付费、免费使用、开源免费、free我用一个给功能标签加同义词表的方式来实现扩展同时利用向量化工具做近义扩展。后者能处理“帮我给声音变个声”这种全新表达把它映射到“变声器”这个已有标签上。3.2 意图拆分和属性抽取第二步是拆分用户查询提取搜索意图。我设计了一种简化版意图模板它把查询拆成几个槽位功能意图用户想做什么比如“视频转文字”“图片放大”“代码审查”属性限定开源还是闭源免费还是付费本地还是云端在线还是下载产品对象已经明确指定的工具名或平台名比如“Midjourney”“ComfyUI”资源类型插件、教程、提示词、接口、数据集还是工具本身比较意图用户是否在对比两个或多个产品举几个例子说明“开源的本地笔记应用带 AI 功能” - 功能意图是“笔记应用”属性限定是“开源本地”产品对象为空资源类型是“工具” “midjourney 英文喂词技巧” - 功能意图是“提示词优化”属性限定为空产品对象是“midjourney”资源类型是“教程/技巧” “A 工具和 B 工具有什么区别” - 比较意图为真系统会优先展示两产品的对比维度这些槽位最终会转成检索语句的 filter 条件而不是单纯加到关键词里。区分“功能词”和“属性词”是我认为这个搜索项目里最重要的优化点之一。很多搜索系统做不好就是因为把所有词一股脑丢进全字段匹配结果“免费”这种词匹配到了正文里“免费试用 30 天”的页面而它可能根本不是免费工具。3.3 无结果和弱结果的查询改写策略用户输入经常是残缺的比如只输入一个“会议纪要”就搜索了或者输入“跟 chatgpt 差不多的国产软件”这种查询信息量太低直接执行检索往往效果很差。我做了一个三级处理策略。第一级先尝试在原查询词上做实体链接确认是否指向已知产品或已知功能标签。能对应上就直接检索。第二级如果原查询的召回结果不足就做查询改写用同义词扩展再加上核心类别词比如“会议纪要”扩展成“会议纪要工具”“会议记录”“语音转文字纪要”三个变体。第三级如果仍然召回不足就改用向量做全文召回。此时不同词语的匹配权重会发生变化核心意图词不变属性限定词降权泛词完全去掉。这样做的核心原则是先精后宽一步步放开口径而不是一上来就做宽松匹配。宽松匹配虽然能保证有结果但用户看到的全是无关内容体验极差。4. 检索与排序向量召回、关键词召回和最终重排的配合查询理解完以后才进入真正的检索环节。我的架构是典型的“召回 精排”两阶段此外还加了一些针对工具类的规则干预。检索层目前同时跑两条线一条是倒排索引的关键词召回另一条是向量的语义召回。关键词召回速度极快适合处理产品名词、标签、开源状态这种准确匹配向量召回适合处理模糊表达比如用户说“帮我找个能把朋友的照片变成动漫风格的东西”这句话里没有任何一个词能直接匹配到现成标签只能依赖语义相似度去找“动漫化”“风格迁移”这类标签。两条线的结果做加权融合然后进入排序模块。排序模块里我不只依赖一个模型打分而是设计了一个多层排序规则确保业务目标和用户预期一致。4.1 关键词召回与向量召回的具体配置关键词召回这块我建立的是字段级倒排索引。简单说不同类型的词会去匹配不同的字段产品词、品牌词只搜索产品名字段和别名段功能标签词搜索能力标签字段场景描述词搜索场景描述字段属性词直接转化为过滤器比如“开源1”“免费1”“本地部署1”字段拆分能显著提升精度。比如用户搜“chat”这个字眼产品名字段里匹配到的是名字真的含 chat 的产品而不是某个网页正文里提到“live chat”的插件。这种字段级匹配对垂直搜索而言比“全文搜索一个筐”可靠得多。向量召回我选了一个中文效果不错的嵌入模型把每个产品的多个字段分别向量化包括产品名向量、能力标签向量、场景描述向量。查询语句也做向量化。然后在向量库里同时搜索三个字段的向量最后取三者的加权相似度。这样设计是为了防止一种情况用户用功能描述去搜产品但产品名的向量和功能描述完全不搭边于是匹配不上。配置完这两条检索线之后我统计了日志数据发现大约 70% 的查询两条线都会返回结果20% 的查询只有关键词线能出结果10% 的查询几乎完全依靠语义线才能救回来。所以两条线并不是竞争关系而是互补关系。4.2 排序层的权重设计和业务目标排序层是我调整得最频繁的地方。最初我把关键词命中数和语义相似度当作唯一的排序依据后来发现用户根本不买账。他们点进一个号称“免费”的工具发现只能免费用 3 次下一次就要充值这种体验对我们来说是致命的。于是我在排序权重里加入了几个业务分项功能匹配度召回时算出的相关性是排序的主权重用户行为反馈点击率、有效访问时长、首屏是否跳转活跃度信号最近更新时间、项目是否仍在维护、开源社区的状态权威性分数来源站点的质量、官网内容完整度口碑信号社区提及的正面评价比例这五项按 6:1:1:1:1 的比例组合出一个最终分数。比例是我拍脑袋先定的后面对比数据迭代调整了几轮。有一个用户特别买账的信号是“活跃度”。一个工具半年没更新哪怕它历史上非常火我也倾向于降低它的排序。因为今天用户打开搜索框搜索是为了解决当下面临的问题而不是考古。4.3 问题排场老牌页权重过高、新工具难露脸的破局办法做垂直搜索最尴尬的一个现象是老牌大工具永远排前面新工具永远没机会。因为大工具的外链多、历史长、在导航站里到处都是它们的名字天然权重就高。而垂直搜索的意义恰恰在于发现那些“好用但小众”的新工具。为了打破这种老牌垄断我在排序里加入了一个“新鲜度奖励”。如果新工具在最近一周内被多个独立数据源同时收录或者开源项目仓库在最近一个月内有高频提交排序时可以适当加权重。另外对用户主动表达“新”“最新”“推荐”这类意图时我会做一次时间衰减排序把最近三个月内上线的工具全部提前。这些规则看着不起眼但不加就很容易被老牌产品霸榜。5. 项目推进中最容易踩的坑以及我的排查思路这部分才是本篇标题里说的“踩坑实录”。在整个项目里我遇到过的麻烦远超想象我挑几个具有共性的问题把完整的排查链路写出来不是直接说答案重点是让你也具备这种定位问题的能力。5.1 踩坑一索引里塞满了“假 AI 工具”很多是套壳网站项目初期我采购了一批公开目录数据结果发现有大量条目其实是“聚合引导站”根本不是真正的 AI 工具。这些站点的套路是首页放一个 AI 聊天框底层调用其他厂商的 API再外包一个渲染页面。用户搜索“AI 写作”会召回几十个这种套壳站真正有自研模型或独特功能的工具反而被淹没了。排查过程是这样的我发现搜索结果里频繁出现一个奇怪现象——很多产品官网上没有任何关于模型、训练数据、技术细节的说明整页只有营销语言。我随机抽了 50 条这类数据做人工标注发现三成以上是“内容农场”式页面一成左右是已经 404 的死链剩下的也缺乏原创能力证明。解决方案分两层第一层是构建质量评分根据页面内容长度、是否提及具体技术方案、是否有更新日志、是否有用户评价等信号计算可信度第二层是过滤凡是质量分低于阈值的工具默认不进入结果排序的第一页只在“更多结果”里低权重展示。这个坑的教训归纳成一句话爬虫获取的是“字符串”不是“真实信息”你需要用规则把它们变成有业务含义的实体并且反复核验。5.2 踩坑二用户关键词千奇百怪向量召回偶尔给出莫名结果向量检索有一个病根它能兜住模糊查询但偶尔也会给你一个看似语义相关、实际完全不能用的结果。我遇到过一个典型情况用户搜“把图片变清晰”系统返回的是“图片尺寸放大”工具两者听起来差不多但实际操作完全不是一回事用户要的是超分辨率修复不是按比例拉伸像素。排查出来之后我给所有能力标签增加了“操作意图”维度的标注。例如“图片变清晰”关联的是“去噪”“修复”“增强细节”“图片放大”关联的是“放大尺寸”“提高分辨率”。两个意图分属不同操作不能再互相替代。这个坑的教训是不要迷信向量相似度。语义相似和功能等价之间还有很长一段距离。垂直搜索一定要有领域知识的约束否则泛语义的坑一个接一个。5.3 踩坑三死链更新不及时用户点击率暴跌上线后第四周我突然发现搜索结果点击率暴跌。排查发现大量产品官网已经过期域名被人抢注跳到了一个充斥着广告的页面。原因是我的抓取任务只关注了新增却没有做好“存量失效检测”。排查链路是这样的我先按点击漏斗拆数据看“展示 - 点击 - 停留超过 30 秒”三个环节。结果发现“点击”环节流失最严重于是抽查最近被点击 100 次以上的 URL发现至少有 15% 的链接已经是死链或跳转异常。修复方案是每次抓取 P0 级页面时检查历史 URL 的返回状态码同时查看页面标题和正文指纹是否与上次抓取一致。如果中途跳转到与 AI 工具无关的域名立刻标为“失效”并降低召回权重连带用缓存的历史快照顶替展示。这个坑让我意识到垂直搜索引擎不是一个“做完上线”的项目而是一个持续运维的数据服务。任何一条数据都可能在下个月失效必须有自动化的健康监测机制。5.4 踩坑四属性筛选和关键词结果矛盾用户被“免费”骗了用户搜“免费录屏工具”排序第一的产品实际免费版只提供 10 分钟录制且需注册才能导出。用户很可能会觉得我们收了赞助费才把这个推上来。这个问题比死链更加隐蔽因为系统层面的数据确实写着“免费”但业务层面的免费并不等于“无限制”。我花了两天时间设计了“免费程度”三级标注完全免费无限制、免费版可用但需登录和导出带水印、有免费试用但核心功能付费。在用户搜索“免费”时优先展示第一级的结果其他结果明确标注“限制级免费”。目前免费的标注主要依赖人工巡查和开源项目许可证信息。我可以直接说这个标注的准确率还达不到完美但比之前那种“一个 free 字段走天下”的做法已经好了一个量级。你可以把它理解成一个阶段性的基础设施不能指望一次性解决所有商业模式的歧义。6. 技术选型复盘单机方案的成本与收益聊到这里很多人会问一句你这一套系统用的是什么技术栈部署复杂度高不高我用的是一个非常克制的方案整站可以单机跑不需要复杂的分布式集群也可以兼顾后续的横向扩展。抓取层用异步爬虫框架配合请求代理池策略基础支持随机延迟和失败重试。解析层主要用 HTML 解析库加规则模板。为了保证解析的稳定我没有完全依赖通用大模型去解析页面因为纯靠模型容易产生幻觉把“推荐阅读”栏目里的链接误当成产品信息。检索层使用开源的全文检索引擎把关系型数据库同步过来的数据映射成文档再利用字段过滤做传统关键词搜索。向量索引部分放在了单独的向量检索库里支持 ANN 近似最近邻和带过滤条件的混合检索。整个链条对外暴露的 API 非常简单接收查询参数返回一个按分数排好的产品卡片列表。搜索耗时经过优化后大部分查询可以压在 100ms 级别不需要大规模机器资源。当然如果将来日均搜索量达到很大级别那肯定要加缓存、加负载均衡、做索引分片但目前这套单机方案在中小规模下非常划算。6.1 为什么没有直接用现成的 “AI 搜索框 大模型” 方案可能有人会问为什么不用大模型直接生成搜索结果我在项目早期确实做了实验直接把用户查询和工具列表一起喂给大模型让它挑选结果并给出推荐理由。跑了一段时间效果是能看但有三个问题让我决定必须回到工程化方案。第一是成本不可控。每个查询都要把候选工具列表进行长上下文处理在高频搜索场景下费用暴涨不适合做成免费的公开服务。第二是结果不可复现。同样的查询大模型两次输出的结果可能不同排序逻辑不透明出了问题很难定位是数据问题还是提示词问题。第三是更新困难。每新增一批工具如果依赖大模型做推理就得重写上下文没办法利用增量索引这种高效方式。于是我把大模型放在了一个更合理的位置做离线数据清洗和查询理解而不是在线检索排序。在线检索继续用确定性的工程方案保持结果的可控性和速度。6.2 日志埋点和效果评测的简陋做法上线后的优化不能靠感觉必须有日志数据的支撑。我做的日志方案非常简单前端上报三件事用户输入了什么 query点击了哪个工具卡片在详情页停留了多长时间。后端记录检索耗时、召回总数、筛选行为。利用这些日志我计算了几个基础指标包括搜索无结果率、首屏点击率、有效访问率。有效访问率定义为“点击后停留超过 30 秒或点了页面内某个外链”它比单纯的点击率更能反映结果质量。一开始我没有用户规模做 A/B 测试于是用了一个很土的办法离线随机抽取上一周的日志查询跑新版排序算法人工看一眼前五条结果对照旧版是否更好。这个方法虽然不科学但很实用能快速发现排序算法的明显退步。如果你也是在做一个中小规模的搜索系统这个思路值得借鉴。7. 从当前版本回头看可扩展方向与个人体会做到现在这个版本我最大的感受是技术层面的复杂度反而不是最难的真正的难点在于你想清楚“自己在为哪一类人提供什么价值”以及你能否长期维持数据质量。搜索引擎是一个内容越丰富越有价值的系统但内容一多噪音也随之增加这是一个永远在平衡的过程。如果让我重跑一遍这个项目我会把更多时间花在“字段级的数据建模”上而不是急着堆算法。垂直搜索的精髓不在模型多高级而在你对整个垂直领域的数据理解有多深。后续我准备做这几件事一是完善付费工具的定价信息抓取尽量识别出不同套餐的实际报价而不是简单贴一个“付费”标签二是增加用户收藏和反馈按钮让排序模型能学会每个人的偏好三是尝试引入更多社区讨论里总结出的“避坑提示”比如某个工具适合什么场景、不适合什么场景这会让搜索结果比单纯罗列产品更有指导意义。最后分享一个个人体会做这类垂直搜索你需要不断提醒自己用户不是来搜索字符串的他们是拿真实问题来找答案的。每一条数据进去索引之前多问一句“这个信息能帮用户省多少时间”答案越大你的搜索就越有价值。如果你也在做类似的东西希望你少踩一点我踩过的坑。