很多 AI 项目，演示的时候都挺聪明。
你问它销售额，它能答；问它趋势，它能画图；问它异常原因，它还能分几条解释。会议室里大家点头，觉得这次终于不一样。
真接到生产数据以后，画风就变了。
数据没更新，权限卡住，历史明细取不动，字段解释不一致，上游表半夜失败，模型回答得再漂亮，也只能对着一条喂不动的数据链路干瞪眼。
这时候再调 Prompt，意义不大。
模型不是自来水龙头
很多人想象 AI 问数，就像装一个新水龙头。
打开，答案就流出来。
可数据不是水厂已经处理好的水。它更像公司里很多管子临时接出来的一套系统：有些管子老化，有些阀门没人知道在哪，有些水表读数不准，有些地方还接了私管。
Meta 最近写了 AI Storage Blueprint at Scale。它讨论的是更大规模的 AI 存储和数据供给问题，但对普通数据从业者也有启发：AI 能不能跑起来，不只看模型，还看数据能不能被稳定、快速、可靠地供给。
在公司内部，这个问题会变成更日常的样子：
- 指标数据昨天没跑完；
- 明细表权限申请要等两天；
- 历史分区太慢，模型每次查都超时；
- 同一个字段在不同表里含义不一样；
- 文档没人更新，AI 只能猜。
这些问题没有一个听起来像“AI 问题”。
但它们会决定 AI 项目到底能不能用。
喂不动，通常有 3 种原因
第一种，是数据不及时。
业务希望 AI 回答今天上午的活动效果，可上游数据下午才稳定；希望实时看库存，可库存状态要等系统回写。模型再快，也快不过数据没来。
第二种，是数据不成形。
字段名像谜语，指标没有说明，表之间关系靠老人记忆。人类同事可以在群里问，AI 只能读系统留下来的东西。如果系统里没留下，它就只能猜。
第三种，是数据不可追。
AI 给了一个结论，但你不知道它用了哪张表、哪段时间、哪个口径。这个答案就算看起来对，也很难真正交出去。因为一旦有人追问，你没有证据链。
这 3 种问题都很普通。
也正因为普通，最容易被忽略。
普通数据人应该补什么
如果你不是企业架构师，也不是平台负责人，只是一个数据分析师、BI 或数据开发，这事该怎么转成自己的能力？
我建议先补 3 个动作。
第一，给高频指标留下“可读说明”。
不要只写字段名。至少写清楚指标定义、来源表、更新时间、适用场景和不适用场景。以后 AI 要读，人也要读。
第二，给关键链路留下“异常记录”。
哪几张表经常延迟，哪几个字段经常缺，哪类业务操作会让数据回写变慢。你把这些记录下来，就比只会说“上游不稳定”强很多。
第三，给重要结论留下“来源路径”。
这次分析用了哪些数据，过滤了什么条件，排除了哪些异常，最终结果怎么核对。别只留一张截图。截图很漂亮，但追不回去。
这些动作不宏大。
可它们会让你在 AI 进入工作以后更有位置。因为模型需要上下文，而你正在整理上下文。
不要只盯模型，盯链路
未来很多数据岗位的变化，不会表现为“模型取代你”这么简单。
更可能是：老板觉得 AI 能查数，于是对数据工作的交付速度和可解释性要求更高。你过去可以慢慢解释，现在别人会问：为什么 AI 也查不出来？为什么这个答案不能直接用？为什么同一个问题两次结果不一样？
这时候你如果只懂模型调用，会很被动。
你要能把问题往前拆：不是 AI 不聪明，而是数据链路在哪一段没准备好。
这句话不是甩锅。
前提是你能拿出证据。
能指出哪张表延迟，哪个口径缺说明，哪个字段没有历史，哪个权限阻断了查询，哪个环节没有审计记录。
普通数据人的价值，正在从“把数查出来”，慢慢变成“让答案有地方来、有理由站住、有路径能追”。
模型越聪明，这件事越重要。
我叫石头，在数据行业里摸爬滚打了十几年，越来越觉得 AI 项目最先暴露的，常常是那些没人愿意整理的旧管线。这里写的，就是这些教训——我觉得值得说出来的那部分。
