3.4 AI 怎样知道我们说的是同一个客户

YS-P-001 的会议记录一直写“华辰零售集团”，CRM 商机也沿用了集团名称，准备签约的主体却是“华辰商业华东有限公司”。人凭经验知道它们有关联，AI 若直接合并，可能把不同法人的合同和付款混在一起。

一次自动合并让问题变得具体

早期演练中，系统按名称相似把集团总部和华东子公司合并，随后把总部的已付款合同当成子公司的信用记录。销售看到“付款良好”，准备为子公司的 18% 折扣提供依据。

财务在批准前发现错误，没有造成损失。这次事件让我停止讨论抽象的“统一知识库”，转而先回答：公司怎样确认一个客户，集团与合同主体是什么关系，谁有权合并和拆分。

我先确定公司最重要的对象：客户、联系人、产品、报价、合同、项目、发票和指标。每个对象有稳定身份，也能说明彼此关系。

我还要求保留来源、有效时间和确认人。同一句“客户已同意”，会议纪要里的草稿和签署合同里的条款不能拥有同等地位。

客户是合作关系，合同主体是承担法律义务的公司，项目又可能服务多个部门。它们有关联，却不是同一个对象。我们为每类对象建立稳定身份，再记录“属于集团”“签署合同”“接受服务”等关系。

事实还要有时间。客户联系人去年负责采购，不表示今年仍有权限；旧合同中的价格不能自动用于新报价。任何 AI 建议都应能说明使用的是哪一条关系、在哪个时间有效。

AI 理解客户全貌，不代表每位员工都能看到全部信息。销售可以看合作背景，项目团队看交付范围，财务看付款，敏感人员和法律资料只对相应角色开放。

共享上下文的“共享”是让被授权的工作使用一致事实，不是建立一个所有人都能搜索的巨大资料库。AI 的权限跟随当前任务和使用者，不能因为它技术上能够连接，就绕过原有资料边界。

客户身份不确定时进入人工核对。销售可提出关系，数据主人确认，财务与法务分别拥有付款和合同事实。AI 全栈工程师建立匹配、来源和权限机制，我负责把业务对象和责任写清。

我让 AI 全栈工程师先建立少量关键对象和关系，不追求一次统一全公司的所有数据。无法确认的匹配进入人工核对，不能自动合并。

我们选择集团客户、同名客户、客户改名和一份跨主体合同，分别追踪销售、项目和财务看到的内容。系统必须保留差异，明确权威来源，并阻止无权岗位查看敏感部分。

若系统连接中断，旧事实要显示更新时间；关系被拆分后，受影响的建议和记录要能找到并复核。上下文不是一次导入完成，而是随真实业务持续维护。

对象	怎样识别和关联	权威来源	谁维护	这次不允许 AI 做什么
客户集团	集团编号，可关联多个法人	客户主数据与人工确认	数据主人	不按名称相似自动合并
签约主体	独立法人编号，与合同关联	正式合同与法务资料	法务	不继承集团内其他主体的付款结论
联系人	联系人、所属主体、角色和有效期	CRM 加销售确认	销售	不把过往负责人当成当前批准人
产品能力	发布版本、适用条件和失效时间	已发布产品资料	产品负责人	不把路线图或销售草稿当成已发布能力
报价与合同	版本、状态、批准和签署时间	报价记录与正式合同	销售、法务	不用草稿覆盖正式版本
项目与付款	项目关联合同，付款保持财务事实	项目系统、财务 ERP	项目、财务负责人	不因项目“正常”推断客户已经付款

在 YS-P-001 中，数据主人可以确认“华辰商业华东有限公司属于华辰零售集团”，法务可以确认它是这次合同主体。两个对象保持独立，AI 只能在获得当前任务权限时使用它们之间已确认的关系。

这次处理没有“统一全公司数据”。我们只建立灯塔需要的身份、关系、来源和可见范围；无法确认的历史客户继续进入人工核对。完整填写表见共享事实不是共享所有文件。

对象可信以后仍不能借用员工权限去读取。下一节把“谁在访问、能看哪笔订单、能做什么、出了问题怎样查”加入蓝图：我为什么给每个 AI 一个身份。