数据画像与客户适配

1. 数据准备是交付工作，不是项目的默认前提

客户给了 CRM 会员表和 POS 订单表，不代表可以直接开始做 Agent。你首先要知道每张表的一行代表什么、主键是否稳定、时间是否统一、历史是否完整、字段含义是否可信。没有这些检查，模型可能在很快地解释一份错误数据。

本周目标是建立一条可追溯的数据链：原始快照 → 质量检查 → 异常隔离 → 客户适配 → 标准数据契约 → 对账结果。原始文件只读，清洗和修正形成新版本。不要为了让演示成功覆盖源表，也不要丢弃异常后只展示漂亮的通过率。

2. 数据画像至少检查哪些内容

先做结构检查，再做业务检查。结构检查包括列名、类型、空值、唯一性和分布；业务检查包括订单状态含义、退款如何表示、会员与订单是否能关联、是否有未来日期、金额单位是否一致。每个异常都应说明影响哪一项业务计算，而不是只报“存在脏数据”。

抽样时不要只看前 20 行。至少包括高频值、低频值、空值、边界日期和异常聚集的来源。数据字典中的“会员状态”可能多年未更新，需用样本与业务说明交叉验证。

3. 原始、隔离与标准三层如何划分

原始层用于追溯，保留接收时间、文件摘要、来源与访问级别。隔离层存放不能确定如何解释的记录，附错误码和复核状态。标准层只接收满足当前契约的记录，同时保留源系统 ID，方便回查和回写。

“清洗后剩余 95%”本身没有意义：被隔离的 5% 如果集中在高价值门店，结果仍可能严重偏差。质量报告需要按来源、门店、时间和异常类型分布说明覆盖范围。没有覆盖的范围应体现在产品界面和验收文档里，而不是埋在日志中。

下面是与现有教学包一致的处理方式示意：完全重复可记录后去重，冲突主键不能随意保留最后一行，必须隔离并等待可验证的更新规则。

# 设计片段：业务映射和错误处理需按实际契约补全。
seen = {}
accepted, duplicates, quarantine = [], [], []
for raw in source_rows:
    try:
        row = adapter.validate_and_map(raw)
        key = (row.source, row.order_id)
        if key in seen:
            if row == seen[key]:
                duplicates.append(raw)
                continue
            raise ValueError("CONFLICTING_SOURCE_ID")
        seen[key] = row
        accepted.append(row)
    except ValueError as error:
        quarantine.append({"source_row": raw, "reason": str(error)})

4. 客户适配器与标准契约

适配器负责翻译来源，不应擅自替业务定义规则。例如源系统金额以分保存，标准契约也采用整数分，可以避免二进制小数带来的金额表示问题；源系统时间带时区时，应统一到约定时区再计算业务日期。源表字段 user_no 是否代表会员、账户还是家庭，需要先确认。

建议每个字段记录来源、目标、转换、空值策略、异常策略和证据。例如 legacy_member_id → source_member_id 只改变字段名称，不意味着完成实体消歧；remark → notes 不应自动转为营销标签。客户系统升级后，契约测试应首先发现列名或枚举变化，避免错误悄悄流入下游。

处理大批量假注册时，也不能因为名字看起来相似就删除。先建立可解释的候选规则，观察关联交易和来源，交业务复核。教学可以使用合成假注册样本；真实数据中的“异常”不等同于欺诈事实。

5. 对账不仅比较总数

先检查守恒关系，再逐层定位差异。教学包中原始订单 14 行，接受 11 行，完全重复 1 行，隔离 2 行；这些是合成数据机制测试结果，不是任何客户项目的数据质量。

raw_count = accepted_count + duplicate_count + quarantine_count
14        = 11             + 1               + 2

接着按门店、日期、状态比较数量和金额，确认变化符合解释。最后挑选少量会员逐单追踪，从原始记录到指标结果。计数对上但金额不对，可能是单位或退款问题；金额对上但会员数不对，可能是身份映射问题；总数都对上也不能证明单条映射正确，因此需要行级抽样。

6. Demo 内循环：用最小真实链路验证，而不是展示所有页面

本周演示只需完成一条受控链路：选择 A 店 → 读取冻结数据 → 显示清洗覆盖范围 → 重算一个指标 → 展示一个异常为什么没有被计入。让业务人员使用自己熟悉的样例检查，比增加十个图表更能发现问题。

区分三个阶段：POC 验证关键技术假设；试点验证真实工作中的可用性与采用；生产上线要求安全、可靠性、运维和责任到位。MVP 是最小可用业务能力，MVA 是支撑它的最小必要架构。最小架构仍需要数据边界、错误处理和证据记录，并不意味着“所有工程要求以后再说”。

每次演示后记录：输入是否符合现场、结果是否被接受、拒绝理由、需要补充的数据和下一次验证。不要用一批过度清洗的演示数据替代后续评估集，否则会把真正的失败模式从测试里删掉。

7. 案例练习：字段为真，业务含义仍可能为假

设想一份合成物流表中 loaded_on_time = true。仓库认为它表示按计划开始装车，运输部门认为它表示车辆准点离场。如果你据此回答“本周所有订单都按时发出”，就把技术字段误当成共同业务事实。

正确做法是保留“开始装车时间”“完成装车时间”“车辆离场时间”三个事件，再定义每项准时率对应哪一事件、计划版本和例外。提交事件映射表，使用“准时开始装车但延迟离场”的反例检验查询结果。

进一步阅读 投放报表对账实作。同一活动可能按曝光日期或转化日期归因，也可能因重复导出被累计两次。先固定活动键、时区、窗口和快照版本，再解释差额；不能让模型用一段流畅解释代替对账。

8. 必做作业、思考与验收

必做：实现并运行数据画像和适配脚本；提交原始/接受/重复/隔离对账；选择一个字段污染问题和一个时间问题，展示修订前后的业务影响；完成最小链路演示计划。

思考：如果当前数据只支持一个低风险分析任务，不支持第 3 周计划的分群，你会继续修数据、调整试点，还是暂停？用价值、成本和下一次可验证结果解释选择。

进阶：为数据快照增加文件摘要、契约版本和可重跑的质量报告；模拟一次源字段新增枚举，证明测试能够发现变化。

验收要求：原始数据未被覆盖；异常不是静默丢弃；对账关系成立；每项业务转换有依据；演示含至少一个失败或隔离样例；限制范围与第 3 周指标契约同步。第三方能用同一输入得到同一质量报告。