企业官网建设流程全解析

假设10月5日的获客任务找到一条“需要升级客服系统”的公开需求。服务内容很匹配，页面也能打开，销售准备跟进时才发现：需求是8月1日发布的。

这条信息是今天被找到的，客户却未必还在寻找供应商。如果线索列表只显示抓取日期，销售就得反复打开页面、找发布时间，再判断是否还来得及参与。自动搜索省下的时间，可能又花在这一步。

星河卓越旗下意客AI按企业业务描述寻找匹配公开需求，把原文与匹配依据积累为销售线索。要让这些材料对客户开发有用，Agent除了“找到什么”，还要保留“为什么现在值得看”。本文拆解其中一段已有实现：公开页面人工补证路径的需求日期判断，以及它如何绑定原文版本和判断结果。

一条线索至少有三种时间

需求发布日期、采集时间、来源核验时间分别回答不同问题。

例如，8月的采购公告在10月仍可访问，只能说明材料还在。它是否进入新一轮采购，要看新的公告或补充内容。另一种情况是9月的需求，10月刚发更正：此时值得读的是更正影响了哪些条件，不能把整条需求的发布日期重写成10月。

这也是线索库区别于搜索历史的一个关键：它应当保存时间的含义，而不只是把几个日期排在一起。

日期要和它的依据一起生效

意客AI的currentDemandDate返回一个当前可用的需求日期；缺少依据或绑定不一致时返回null。函数没有读取collectedAt，因此新采集不会自动把旧需求变成新需求。

它先检查补证是否仍属于当前候选、来源版本和业务版本，再要求当前判断使用这份补证。随后检查两段时间：核验距今不超过24小时，需求发布日期距今不超过60天，且都不能来自未来。

constchecked=Date.parse(receipt.checkedAt);constdate=Date.parse(`${proof.publishedDate}T00:00:00+08:00`);if(!Number.isFinite(checked)||checked>now||now-checked>86_400_000||!Number.isFinite(date)||date>now||now-date>60*86_400_000)returnnull;returndate;

这里采用固定的60天窗口。把这套设计迁移到其他业务时，应按需求生命周期选择窗口，不能直接照搬。一个昨天发布、今天已截止的公告仍可能通过日期检查，所以参与条件与截止阶段还要继续读原文。

超过24小时窗口，流程需要新的核验依据；这个纯函数本身不会发起网络请求。

只比日期，仍会把旧判断接到新材料上

假设来源最初是版本source-v1，后来补充了“暂停项目”。即使两份材料的发布日期相同，旧版本上的匹配判断也不能直接代表新版本。

sourceVerificationMatches为此同时比较候选ID、候选修订号、来源ID、来源版本、平台、业务ID与业务版本。这里只要有一项不一致，日期函数便不采用这份核验记录。

还有一项容易漏掉：判断结果关联的补证ID，必须等于当前核验记录ID。

assessment.demandEvidenceId===receipt.id

销售调整主营业务后，旧的“匹配”结论可能已经不适合新业务；来源更新后，旧的判断也可能错过变化。绑定业务与来源版本，是为了让销售看到的日期、需求摘录和匹配依据来自同一轮材料，而不是各自取一个最近的值拼成线索卡。

九组输入看它如何返回

我们直接调用上述源码函数，将示例判断时刻固定为10月5日05:30，使用同一组候选与补证，只改变一个条件。基准需求日期为10月1日，核验发生在两小时前。

null表示这条路径目前拿不出可用的日期，不能直接翻译成“客户没有需求”。交接给销售时，要区分日期未知、核验过期和版本变更，让下一步对准需要补的材料。这九组返回也不能用于计算客户筛选准确率。

客户端之外，服务端的current_evidence同样检查24小时核验窗口和60天需求日期窗口；validate_evidence还要求作者、需求和日期摘录能在对应原文或补充材料中找到。日期与出处同时保留，才有机会定位问题，而不必让销售从一个“最新”标签重新猜起。

AI获客给销售增加客户来源，价值最终落在可读、可判断的需求材料上。意客AI这段时间与版本设计，解决的是其中一个具体问题：新找到的材料，能否带着一致的时间依据进入下一步判断。

继续阅读：AI获客怎样读出线索的下一步？意客AI的原文行动清单

意客AI产品团队｜星河卓越