结论先行
把“网站访客识别”想成一个 API 回包后直接 crm.lead.create()，是最容易把系统做脆的方式。Odoo 的实现明显更像一条事件管道：HTTP 层先记浏览事实，规则层决定哪些访问值得送去 reveal 服务，IAP 返回后再创建 lead，企业版再把这些 lead 继续送进 CRM 分配体系。
第一层：入口或表面动作
第一棒在 website_crm_iap_reveal.models.ir_http。请求进来后，框架会拿 website.visitor、当前 URL、IP、GeoIP 信息去判断是否创建 crm.reveal.view。这里特别关键的一句是：如果 visitor 已经有关联 lead，就避免重复创建 reveal view。也就是说，网站层负责的是采样与去重前置，不是立刻建线索。
第二层：真正的业务护栏
第二棒在 crm.reveal.view / crm.reveal.rule。_create_reveal_view() 先按站点、URL、国家、省州和排除规则把“候选访问”落成待处理记录；cron crm.reveal.rule._process_lead_generation() 再批量取待处理 IP，调用 reveal/IAP 服务，最后经 _create_lead_from_response() 生成 lead。这里还有两道很重要的护栏：它会先 _unlink_unrelevant_reveal_view()，把过去几个月已经生成过 lead 的同 IP 访问清掉；创建前还会检查 clearbit_id 是否已存在，避免同一家公司被重复拉进销售漏斗。
第三层：状态落点与边界
企业版模块 website_crm_iap_reveal_enterprise 与 crm_enterprise_partner_assign 虽然主要是 enterprise counterpart，但它们指向的业务意义很明确：被 reveal 生成出来的线索，不会停在“有公司名的 lead”这一层，而是继续进入 enterprise CRM 的分配、伙伴匹配、销售归属体系。换句话说，访客识别模块产出的不是成交线索，而是可继续被 assignment engine 消化的半成品。
为什么这套设计更稳
这条链为什么值得写成框架题？因为它体现了典型的异步、幂等、批处理设计。HTTP 请求不阻塞外部 enrich；外部 enrich 不直接决定销售归属；分配规则也不回写网站 visitor。每层只接自己的边界，失败了能重跑，重复了能去重，没额度了也只是 reveal state 变化，而不会把 CRM 主数据污染到一团糟。
实战启示
如果你要扩展这条链，最稳的入口往往不是覆盖 lead create，而是补 reveal rule 过滤条件、lead vals 映射、或 assignment 规则。真正该敬畏的不是“怎么更快建 lead”，而是“怎么让一条匿名访问记录，经过多层转换后仍然保持可审计、可重放、可去重”。
DISCUSSION
评论区