从人工检索到可复用脚本：一次企业官网数据补全实践

企查查、天眼查是国内比较成熟的企业信息搜索产品。接触这类产品的时间不算长，我目前也只是懂了一些皮毛。不过在实际参与项目之后，我逐渐意识到，这类产品至少有两项非常核心的能力：一是搜索，二是数据。

搜索决定用户能否快速找到目标企业，数据则决定用户找到企业之后，能够获得多少真实、有效的信息。两者缺一不可。

我们在项目中遇到的一个具体问题，就是部分企业缺少官方网站数据。为了解决这个问题，我尝试做了一套可以重复使用的官网查找工具。

先用 Codex 验证整个流程

第一步是找到缺少官网数据的企业，然后使用 Codex 搜索它们可能对应的官方网站。

整个过程分为两轮。

第一轮是在 Google 中搜索“公司名称＋官网”，从搜索结果中寻找可能的官方网站；第二轮再通过 Google 的 Gemini 功能进行辅助确认。根据得到的证据，我把结果分成了三类：

我先用这套流程处理了 5 家企业，并借助 Codex 的 Record 插件把操作过程整理成了一个 Skill，方便后续重复执行剩下的企业。

完成第一轮处理之后，我开始人工核验 Codex 标记为“可以确认”的官方网站。

结果比预期更好：这些结果的准确率大约为 98%。

这说明整套判断思路基本可行，但也暴露了另一个问题：它并不适合直接应用到百万级数据中。

Codex 自动处理 500 家企业大约需要 200 分钟。即使不考虑人工核验成本，按照这个速度处理百万级数据，耗时也会非常可观。它可以帮助我验证思路，却很难直接成为一个可以大规模复用的解决方案。

于是我开始思考：能不能把 Codex 已经验证过的执行逻辑提取出来，做成一个运行成本更低、速度更快的脚本？

真正开始构建脚本之前，我首先需要把“确认官方网站”这件事拆开。

例如：

将这些问题逐步梳理清楚之后，我开始使用 Codex 搭建脚本。

第一版脚本在 500 家企业中自动确认了 35 家官方网站，自动确认覆盖率为 7%。经过人工核验，这 35 条结果全部正确。

从准确性来看，这个结果很好；但从覆盖范围来看，它显然还远远不够。

脚本输出的结果中，可以直接确认的网站很少，候选网站却很多。

我最初认为，这是因为脚本的判断规则过于保守：只有证据非常充分时，它才会把网站归入“可以确认”。

但在实际检查候选结果之后，我发现真正的问题并不完全在最终判断环节，而是出现在更前面的流程中——部分网站的路由没有被正确解析，页面中的关键数据也没有被完整提取。

换句话说，脚本并不是“看到了证据却不敢确认”，而是根本没有正确看到那些证据。

找到这个问题之后，优化方向就变得清晰了：先调整网站路由解析，再改进关键数据抽取，然后重新运行、人工核验、分析错误，继续优化。

经过多轮试验，我最终得到了一版表现相对稳定、能够重复使用的脚本。

这次工具构建让我重新认识了“经验”在开发中的作用。

开始设计一个工具时，不必立刻追求面面俱到。很多提前设想的问题，在真实运行中可能并不重要；而真正影响结果的问题，又往往只有等工具运行起来之后才会暴露。

比起一开始就构建一套看似完整的系统，更有效的方式通常是先完成一个最小版本，让它处理一批真实数据，再根据结果判断问题究竟发生在哪个环节。

“个人经验有时甚至会成为进步的障碍。”

经验能够帮助我们快速做出判断，但也可能让我们过早认定问题的原因。在这次实践中，我一度认为候选结果过多是因为判断规则太保守，实际问题却是更前面的页面解析与数据抽取没有做好。

如果一直沿着最初的经验判断继续修改规则，不仅解决不了问题，反而可能让脚本变得越来越复杂。

另一个重要收获来自搜索流程。

对于这类官网查找工具，候选网站的召回和最终网站的确认应该被视为两个不同阶段。

候选召回阶段首先要尽可能找到可能相关的网站。如果搜索 API 返回的候选结果本身质量很差，后面的验证逻辑设计得再精细，也无法从不存在的候选中找到正确答案。

最终确认阶段则相反，需要更加谨慎。脚本必须根据企业名称、页面内容和其他关键证据判断候选网站是否真正属于目标企业，尽量避免把错误网站写入正式数据。

也就是说，应该先确认候选集合是否足够完整，再研究如何提高最终结果的准确性。否则，很容易把召回阶段的问题误认为验证算法的问题。

“先抓大，再抓小；先抛出，再优化。”

这里的“先抛出”，不是不加判断地输出结果，而是先构建一条能够运行的完整链路：召回候选、解析页面、抽取证据、完成判断。等数据真正流过这条链路之后，再根据实际结果逐步优化每个环节。

这也是这次工具构建带给我最深的感受：先让系统运行起来，再通过真实结果认识问题。很多时候，真正有效的优化方向并不来自开始时的设想，而来自一次次运行、核验和修正。