JPDD.AI
JPDD.AI是一个类似企查查和天眼查的企业搜索软件。
在这个项目中我的主要任务是美化前端，写后端加功能，分析埋点数据找产品漏洞等。
我如何找到问题
为了找到问题，我最先使用 PostHog 分析真实用户如何使用产品。排除内部测试、机器人和异常流量后，我从数百位真实用户中抽取了百余次会话和页面轨迹作为样本，观察用户从产品首页、搜索结果到企业详情页的完整路径，以及结果点击、页面停留、滚动深度和各信息模块的使用情况。
埋点告诉我用户在哪里反复操作、在哪里中断，展现他们的功能需求。比如用户尝试搜索某个残缺的地址，但是没有点击搜索结果，那是不是可以思考这个地方的搜索设计不太合理呢？此外，构建一些搜索评测集也是一个很好的方法。
通过人工构建 Gold 评测集，我把实际的 OpenSearch 与端到端 HTTP 查询放进独立测试链路，逐条检查搜索词能否找到目标企业、结果排在什么位置，以及每次查询的接口和搜索引擎耗时。
结合实际的用户埋点和评测集，已经发现很多问题需要解决了哈哈，下一步就是记录需求进行优化。
我做的三件核心工作
-
重构企业详情页：原项目页面把大量信息塞进少数导航入口，用户很难判断某类数据是否存在。我按照企业调查的阅读逻辑，将内容整理为 7 个业务分类和 47 个数据维度，并统一导航、内容顺序和数据计数。长列表改用数字分页，较深内容按需加载，同时增加用户反馈入口，让问题能够回到产品迭代中，这里的用户反馈其实用到了飞书机器人，是个很不错的工具。
-
建立定时数据补充工具：这个需求来源于项目初期数据量比较少的问题，而我们是一个针对企业搜索的项目，不少补充数据可以来源于企业官网，那如果我们能拿到官网数据就可以补充大量的额外数据了，因此针对这个需求我制作了一个面向日本市场的定时脚本。使用 Firecrawl 等供应商的 API，提前过滤聚合站，提取 API 返回的 10 条结果，分别解析提取法人名、地址、联系方式等关键信息组成官网判定证据链，然后再记录能够确认的主域名 URL。针对第一轮搜索不能确认的公司，我还设计了二轮搜索，最终形成一套官网提取脚本，在已核验样本中准确率 100%，但是还是有些公司没法召回，目前还在优化……
-
设计搜索质量评测链路：由于每次优化完搜索，不能确定当前优化是不是只改善了局部，所以我根据公司名、英文名、别名等搜索查询方式生成千余条查询，并人工审核所有用例。每次调整搜索逻辑后，都能重新检查目标是否被召回、排名是否退化，以及 API 和 OpenSearch 的加载耗时，从而把“每次优化是否陷入局部”和“搜索体验不好”变成可以重复验证的问题。
我的思考
这个项目让我真正了解了生产环境里的开发是怎么运转的：用 Docker 统一环境，用独立的 worktree 支持并行开发，也在数据回填和表结构设计中慢慢理解，好的设计往往在简不在繁。
但我收获最大的，还是同事们做事和思考的方式。一个方案走不通，就迅速切换方向、动手验证；不让过去的经验替现在做判断，也始终保持学习，并尊重每个人的投入。相比某一项具体技术，这些习惯可能才是我最想从这个项目里带走的东西。