Kimi K3 数据治理实测：表结构变更（schema drift）审查，8 条报表 SQL 实测验证

场景：4 张表（orders / order_items / products / ads_daily）+ 少量演示数据（构造数据，非客户数据）。

5 处变更：①order_items.price 改名为 unit_price；②orders.status 新增枚举值 partially_refunded；③products.category_id 从 INT 变 VARCHAR；④total_amount 精度 DECIMAL(10,2)→(12,4)；⑤orders 新增 channel 列。

8 条下游 SQL：每日 GMV、类目 GMV、广告 ROI、商品收入榜、退款率、月均客单价、广告总花费、客户下单数。

方法：K3 静态预判（每条 SQL：报错/静默/安全 + 证据）→ DuckDB 建两版库实测对照。全部脚本与结果随文公开。

q2、q4 直接报错，运维当天就能发现；真正危险的是 q1 和 q6 这种静默变化。完整逐条对照（v1/v2 结果集）以 JSON 工件随文公开。

q2、q4 直接报错，运维当天就能发现。真正危险的是 q1：6 月 3 日的 GMV 从 200 悄悄变成 80——原因是新状态 partially_refunded 不在 status='completed' 的过滤条件里，那张订单从 GMV 里“消失”了。没有任何报错，没有任何告警，周报照样发出去，只是数字是错的。

真实世界里，这类静默错误平均要等到对账、复盘或老板问“这个月怎么跌了”才被发现，通常已经错了几周。

5 处变更里看起来最无害的是②“状态字段加了一个枚举值”——不改名、不换类型、不加表。但它一口气造成了 q1 的静默失真，还在 q5 埋了雷：退款率的口径是 status='refunded'，partially_refunded 算不算退款？没人定义。

这批演示数据恰好没触发差异，但口径地雷已经埋下，数据量一大就会爆。K3 在静态审查里把这种变更单独标红，是对的。

q6 月均客单价从 130.0 变成 130.00088——看起来无伤大雅，但如果这条数进了财务对账或分成计算，尾差就是“两边对不上”的经典悬案来源。K3 把 DECIMAL 精度变化标记为“风险型”，实测确认了尾差真实存在。

K3 的静态预判 7/8 命中，唯一没完全命中的 q5 也是“风险标记正确、本批数据未触发”。这说明一个可落地的工作流。

小团队没有 DBA，但一次 K3 审查 + 半小时实测，就把“靠口头通知”变成了“有证据的变更”。

完整提示词与三级处置规则（破坏型/风险型/安全型）、影响清单模板、签收单模板，我们正在整理为《schema drift 事故证据链包》（打磨中，可在数据自查页留资第一时间获取）。实验脚本与实测结果（schema-drift-test-results.json）随本研究的公开工件提供。

本文场景、数据、脚本全部为构造演示数据，公开可复现，不涉及任何客户数据。真实诊断走受控授权与脱敏流程。

《schema drift 事故证据链包》仍在打磨中，本页不提供购买链接；可在数据自查页留资第一时间获取。

本研究由盈尺科技数据团队完成，我们提供数据链路诊断与 InchStack 企业数据平台服务。Kimi K3 为月之暗面产品，本文为独立第三方使用研究，不构成官方背书。