客户情报系统的核心不是抓取更多网页，也不是让大模型给每家公司生成一个看似精确的总分。真正可交付的系统应该输出一个可追溯的 decision package：它说明判断对象是谁、用了哪些来源、信号在什么时间成立、经过哪一版规则、哪些证据被排除，以及最终由谁决定是否写回 CRM。只要其中任何一跳无法重放，评分就只能作为检索提示，不能直接驱动客户淘汰、销售资源投入或行业结论。
这个结论改变了架构优先级。采集器不是系统中心，评分模型也不是。系统首先要保护“观察事实”和“业务判断”之间的边界：网页、招聘、认证、融资与伙伴关系都是带时间和来源的观察；企业实体、画像特征和采购时机则是后续推导。把二者写进同一张宽表，短期查询方便，长期却无法回答“为什么昨天是 75 分，今天变成 40 分”。
本文给出一套六层参考架构，并用一个脱敏、合成的 Node.js 回放验证三项合同：仅凭相似名称的记录不会自动合并；每个派生特征都带 eventTime 与 provenance；解释项使用明确的 ruleVersion，并能相加还原总分。这个回放证明计算链可以复核，不证明生产匹配准确率、转化提升、数据许可或任何真实客户结果。
1. 先定义交付对象：不是公司卡片，而是判断证据包
很多项目从“给销售做一张更丰富的公司卡片”开始，字段很快从公司规模扩展到技术栈、招聘、融资、新闻、访问行为和联系人。字段数量增加后，页面确实更丰富，但使用者仍不知道哪些信息可信、哪些已经过期、哪些只是同名公司的噪声。问题不在 UI，而在交付对象没有被定义。
一个合格的判断证据包至少包含五类对象。第一是稳定的 organization_id 和当时使用的实体版本；第二是原始 observation，包括 URL 或内部事件标识、抓取时间、事件时间、内容 hash 与授权范围；第三是由 observation 派生的 feature，以及 feature 的有效期和缺失状态；第四是 ruleVersion、模型版本、权重、阈值和解释贡献；第五是人工复核状态、操作者、理由与写回目标。缺一项，系统都不应把结果包装成确定事实。
W3C PROV-O 用 Entity、Activity 和 Agent 表达数据对象、生成活动与责任主体之间的 provenance 关系。客户情报平台不必完整采用 RDF 或 OWL，但应保留同样的工程能力：给定一个评分，能够向后找到生成它的特征、活动、来源和责任版本；给定一个来源撤回，也能够向前找出受影响的画像与决策。W3C PROV-O 支持的是这种可交换的 provenance 模型，而不是某个特定销售流程。
因此，UI 里“75 分”只是一个视图。真正的 API 输出应更接近：organization_id=org-nw-001，as_of=2026-09-12T04:00Z，fit=40，engagement=20，in_market=15，rule_version=ci-score-2026-09-12.1，并附四条 contribution 和各自 provenance。当下游只保存总分、不保存版本和来源引用时，它实际上丢失了审计对象。
2. 六层边界决定错误会在哪里停止
第一层是 source observation。它负责保存“某个来源在某个时间呈现了什么”，而不是判断企业是否值得跟进。网页标题、招聘职位、认证状态、CRM 活动和一方产品事件都要保存 observed_at 与 ingested_at。前者表示信号在业务世界发生或被看到的时间，后者表示系统何时接收。两个时间混用，会让延迟到达的数据改写错误的历史窗口。
第二层是 identity resolution。它把 observation 关联到稳定企业实体，但必须允许 unknown、review 和 quarantine。域名、注册号、市场、地址和集团关系是不同强度的证据；相似名称只是候选，不应成为自动合并的充分条件。身份层输出的是匹配决策和置信度，不是画像字段。
第三层是 profile snapshot。它在一个明确的 as_of 时间上，组合已接受 observation，形成企业规模、市场、产品方向或技术环境的快照。快照应该可重建，而不是被新数据原地覆盖。这样才能区分“公司发生变化”和“系统修正了历史错误”。如果集团、子公司和品牌共用一行，销售行为可能被记到错误的法律实体上。
第四层是 feature computation。特征层把 observation 和 profile 转换为可比较的信号，例如目标市场匹配、最近 30 天招聘、已下载架构资料或认证即将到期。每个 feature 都需要 eventTime、计算窗口、缺失策略、provenance 与 feature definition version。没有这些字段，所谓“实时画像”只是不断变化的不可重放状态。
第五层是 scoring。评分层把 Fit、Engagement 与 In-Market Signals 分开计算，再按业务用途组合排序。Fit 回答“是否适配”，Engagement 回答“是否与我们互动”，In-Market 回答“当前是否出现可能的采购时机”。三者不能互相替代。一个高度适配但没有近期行为的账户，不应该因为总分较低就被判断为“不适合”；一个频繁访问但明显不符合市场边界的账户，也不应因 Engagement 较高自动进入重点名单。
第六层是 explanation and decision. 解释层将贡献项、反证、缺失项、置信度和规则版本组织成人能复核的说明；决策层才决定写回 CRM、进入人工队列、保持观察或拒绝动作。这个分层能把错误限制在最早发现它的地方。身份不确定时停在 identity，来源过期时停在 feature，规则未批准时停在 scoring，而不是让错误一路扩散到销售流程。
这张图只表达责任和停止边界。它不意味着所有系统都必须拆成六个微服务。早期版本可以把这些层放在同一应用和数据库里，但表、事件、版本与写权限仍应分开。物理部署可以合并，语义边界不能消失。
3. 实体对齐最重要的能力，是承认“不知道”
实体对齐错误会污染后续所有特征。两个名称相似的企业被合并后，招聘、融资、访问行为和联系人都会汇总到错误账户；拆分时还必须追踪哪些评分与任务受影响。与漏掉一条弱信号相比，错误合并通常具有更大的传播成本，因此自动化阈值应该按误合并成本设计，而不是按“尽量匹配更多”设计。
本轮脱敏回放准备了四条 observation。注册记录以注册号、规范化名称和市场匹配到 org-nw-001；官网与一方事件以唯一域名匹配；另一条新闻只有相似名称，且市场不同，因此进入 quarantine。首次运行时，参考规则把唯一域名只赋予 0.55 置信度，低于 0.85 自动合并阈值。结果是官网和一方事件被隔离，派生特征缺少事件时间，三项断言只通过两项。
修复没有降低自动合并阈值，而是把“已验证的唯一域名”作为强证据，提高到 0.90。重跑后，三条有稳定标识的 observation 被接受，相似名称记录继续隔离，三项断言全部通过。这个小故障说明，实体规则必须用具体反例验证。仅检查最终公司卡片是否“看起来正确”，无法发现证据被错误排除或错误合并。
生产系统还需要处理域名迁移、集团共享域名、品牌站点、收购、公司改名和同一注册主体的多个区域组织。可行的做法是把 organization、legal_entity、brand、domain 和 account 分开建模，再用带有效期的关系连接。销售账户可以合并多个法律实体做协同，但不能反过来修改来源事实。
人工复核也不能只提供“接受/拒绝”按钮。复核者应看到候选实体、冲突字段、来源时间、匹配理由和预期影响，并填写结构化 reason code。批准后要生成新的 resolution event，而不是静默改写旧记录。这样当规则升级或客户提出数据更正时，系统能区分人工判断、自动规则和源数据变化。
4. 画像与特征必须保留时间，而不是只保留最新值
公开信号经常变化。招聘页面可以在一天内下线，认证会过期，融资新闻可能来自转述，伙伴关系页面也可能多年未更新。如果系统只保留 company.is_hiring=true，下游无法知道它是今天的观察、半年前的快照，还是已经失效但未清理的缓存。
每个观察至少需要 observed_at、ingested_at、source_url 或内部 URN、source_hash、解析器版本和授权标签。每个特征还需要计算窗口、valid_from、valid_to、缺失语义与 lineage。false、unknown、not_observed 和 expired 不是同一状态。把缺失当成否定，会系统性压低公开信息较少的行业和地区；把旧值永久延用，则会把历史动向伪装成当前时机。
特征存储可以使用事件表加版本化快照，也可以使用具备 time-travel 的数仓。关键不在具体数据库，而在于能够回答三类查询：某个 as_of 时点系统知道什么；某个评分用了哪一版特征；某个来源删除或规则修正后，哪些下游对象需要重算。若系统只能展示“当前最新值”，它很难支持申诉、复盘和回测。
来源许可同样应进入数据合同。公开可访问不等于可以无限抓取、长期保存或用于自动化商业决策。采集层应记录 robots、许可、用途、保留期和删除请求处理方式；高风险字段应有独立访问控制。本文的合成 .example 域名和内部 URN 不代表任何真实企业，也不构成对具体数据源的法律判断。
5. 评分要分维度，解释要能还原计算
一个单一总分很适合排序，却很不适合解释。参考回放中，目标市场匹配贡献 25 分，边缘 AI 招聘贡献 15 分，架构资料下载贡献 20 分，近期相关招聘作为 In-Market signal 再贡献 15 分，总分为 75。这个数字只有在四个 contribution、事件时间和 ruleVersion 同时存在时才有意义。
更稳妥的 API 会同时返回 fit=40、engagement=20、in_market=15。销售可以据此区分“长期适配但当前没有动作”和“正在互动但并不适配”。模型或规则可以给出建议，但动作权限仍由场景决定。例如，向账户负责人显示解释的风险较低；自动降低客户优先级、停止跟进或向外发送消息的风险高得多，应要求人工确认和更严格证据。
解释不能只生成一段自然语言。大模型可以把贡献项转成可读摘要，但底层必须保留结构化事实：feature 名称、值、分数、来源引用、事件时间、规则版本、反证与缺失项。若自然语言说“公司正在扩张”，却没有对应来源、时间或可撤回的 contribution，这只是更流畅的黑盒。
NIST AI RMF 将透明、可解释、可解释读性、责任与风险治理放在系统全生命周期中考虑。它不是客户评分产品规范，但提供了一个重要边界：解释应服务不同角色理解发生了什么、如何得到结果以及结果意味着什么，而不是用一段技术文本证明系统天然可信。NIST AI RMF 1.0 也明确是自愿、跨行业的风险管理框架，实际部署仍需结合适用法律与组织流程。
6. 人工反馈必须成为版本化事件，而不是备注
许多系统把人工反馈存成 CRM 备注，模型团队之后很难区分“实体匹配错误”“信号已过期”“规则权重不合理”还是“销售暂时不想跟进”。这些反馈对不同层的修正意义完全不同。把它们混在自由文本里，系统只能积累意见，不能形成闭环。
推荐把反馈设计为状态转换。实体层可以有 confirm_match、reject_match、split_entity；特征层可以有 confirm_signal、mark_stale、source_conflict；评分层可以有 override_priority，但必须记录业务理由和有效期。每个反馈事件都要引用原 decision package，并生成新的版本，不删除原状态。
反馈也不能直接当训练标签。销售选择“不跟进”可能因为容量不足、区域策略或已有关系，并不等于账户不适配。只有经过定义、抽样与质量检查的反馈才能进入规则评估或模型训练。否则系统会把组织流程偏差学习成客户偏差。
当多个团队共享平台时，写权限要比读权限更窄。采集团队可写 observation，身份服务可写 resolution，特征作业可写 feature，评分服务可写 versioned score，业务应用只能提交 action 或 feedback。这个原则和多租户设备平台的权限判定类似：展示某个字段，不意味着调用者有权改变其来源或规则。可进一步参考多租户设备管理权限模型。
7. SLO 应围绕“可复核”和“可恢复”，不只围绕抓取吞吐
在没有真实流量输入时，架构设计应给出小、中、大三档容量假设，而不是伪造一个精确 QPS。小型部署可以按 10 万组织、每天 100 万 observation、每小时增量特征计算规划；中型可以按 100 万组织、每天 2000 万 observation、15 分钟增量；大型则可能超过 1000 万组织、每天数亿 observation，并要求分区重算、冷热分层和跨区域治理。这些是容量设计起点，不是本文实测值。
更关键的 SLO 包括 provenance completeness、entity decision latency、feature freshness、score reproducibility 和 correction recovery。示例目标可以是：进入评分的 feature 100% 带来源引用和版本；高置信实体在 15 分钟内完成关联；需要人工复核的记录不进入评分；评分重放在相同输入与版本下得到同一结果；确认错误来源后，受影响 decision package 在既定恢复窗口内标记失效并重算。生产阈值必须由业务风险和数据量确认。
可观测性至少分四层。采集层看来源成功率、延迟、内容变化与许可错误；身份层看自动合并率、复核率、隔离率和后续拆分率；特征层看 freshness、缺失率、漂移与回放差异；决策层看解释完整率、人工覆盖率、写回失败和 override 原因。只监控 API P95 而不监控实体错误，会让一个快速返回错误公司的系统看起来非常健康。
故障恢复也需要按语义边界处理。采集器故障可以重放 observation；解析器错误要保留旧版本并重算受影响 feature；实体误合并要创建 split 事件、撤销错误关系并失效下游 decision package；规则回滚则应切回上一 ruleVersion，而不是删除新结果。离线备份只有在能恢复来源、版本、关系与事件顺序时才有意义。
8. 上线应该分三步，且每一步都有停止条件
第一阶段只建立可搜索的 observation 与企业实体，不产生客户淘汰或自动外部动作。验收重点是来源许可、实体误合并率、人工复核效率、provenance completeness 和删除请求。若同名企业仍频繁合并，继续增加评分模型只会扩大污染范围。
第二阶段生成画像、分维度评分和解释，但保持 observe-only。业务用户可以比较 decision package 与自己的判断，系统记录 disagreement reason。此阶段应使用时间切分的标注集评估实体和特征，不允许用未来信息泄漏到历史回测。若解释无法还原分数，或不同规则版本不能并存，系统不能进入写回阶段。
第三阶段才允许受控写回 CRM。先写独立字段和证据链接，不覆盖人工维护的核心账户信息；高风险动作保持 Human Review。上线应设置 kill switch、写回幂等键、速率限制、权限审计和上一版本回滚。只有当数据责任人、模型责任人、RevOps 与最终使用者对动作范围签字后，系统才从建议工具变成流程参与者。
每个阶段都要能退回。实体质量下降时退回 observation-only；特征漂移或来源中断时冻结受影响维度，而不是沿用过期分数；规则版本异常时停止新 decision package 并恢复上一版；CRM 写回失败时保留队列但不重复创建任务。部署成功的定义不是“模型已上线”，而是错误可以被发现、影响可以被圈定、动作可以被停止、结果可以被重放。
9. 哪些场景不适合建设这套系统
如果组织没有稳定的账户主数据、没有明确的销售决策问题，或者每月只处理几十个已知客户，先做数据清理和简单规则可能比建设完整平台更合适。架构复杂度不会自动产生洞察；当人工可以低成本核对全部账户时，六层系统的收益可能不足以覆盖数据许可、维护和治理成本。
如果业务要求系统自动做拒绝、授信、招聘或医疗等高影响决定，本文的客户情报参考架构也不够。那些场景需要适用市场的法律、合规、偏差、公平性、申诉和人工监督设计，不能把 B2B 账户排序模型直接迁移过去。本文只讨论企业客户研究与销售优先级辅助。
如果可用来源无法获得授权、关键实体没有稳定标识，或者用户不愿记录反馈理由，系统应降低自动化程度。宁可返回 unknown 和待复核，也不要用生成式文本填补证据缺口。客户情报平台最有价值的能力，不是把所有公司都打上分，而是知道哪些判断目前还不能成立。
结论
客户情报系统应围绕可追溯 decision package 设计，而不是围绕抓取数量或黑盒总分设计。source observation、identity resolution、profile snapshot、feature computation、scoring、explanation and decision 六层可以部署在同一应用里，但责任、版本、时间和写权限必须分开。
本轮参考回放证明了三件小而关键的事：相似名称可以被隔离，派生特征可以回到事件时间和来源，解释贡献可以在指定规则版本下还原总分。它没有证明生产准确率或商业效果。真正上线前，还必须用获授权的真实数据、时间切分标注集、人工复核成本、动作风险和适用法律完成验收。
参考资料
- W3C PROV-O: The PROV Ontology
- NIST Artificial Intelligence Risk Management Framework 1.0
- 工业物联网中的数据质量治理
- 多租户设备管理权限模型
FAQ
客户情报系统和 CRM 是一回事吗？
不是。CRM 主要保存关系、流程和人工维护的业务记录；客户情报系统整合来源、实体、特征与解释，为账户研究和优先级提供证据。两者可以集成，但客户情报结果不应无版本、无来源地覆盖 CRM 主数据。
大模型适合放在哪一层？
大模型适合辅助解析非结构化 observation、生成候选实体、归纳结构化 contribution 或把解释转换为角色化摘要。它不应绕过 provenance、置信度、规则版本和动作权限直接给最终业务结论。
为什么总分不能直接驱动销售动作？
因为相同总分可能来自完全不同的 Fit、Engagement 与 In-Market 组合。只有分维度结果、来源时间、反证、缺失项和业务权限同时满足时，动作才有足够上下文。
