最近两年很多企业都在做一件事给业务系统接入 AI。客服要接智能问答销售希望 AI 帮忙分析客户财务开始尝试经营预测管理层希望直接用自然语言问数据研发团队也在探索让 Agent 调用企业知识库、指标库和业务系统。模型越来越强但真正落地后经常会碰到一个很现实的问题AI 已经准备好了数据却供不上。不是企业没有数据。恰恰相反。ERP、CRM、MES、WMS、财务系统、供应链系统、费控平台再加上大量 Excel企业手里的数据越来越多。真正的问题是真正能够被 AI 及时、稳定、准确使用的数据并没有想象中那么多。AI 时代的数据问题已经不只是“把数据存进数仓”这么简单。传统数仓解决的是数据集中、历史沉淀和报表分析。而 AI 应用需要的是一套更完整的数据供应链数据能够及时进入、准确加工、保留业务语义、按权限调用、出了问题能够追溯并且在业务变化后快速调整。这恰恰是很多传统数据架构需要补上的部分。也正因为如此企业现在做 AI 数据底座首先要解决的往往不是模型怎么接而是底层的数据链路能不能先稳定跑起来。ERP、CRM、MES、WMS 等系统里的数据需要按照不同业务场景持续进入数仓和后续分析环境数据变化以后下游也要能够及时跟上。FineDataLink 5.0可以把这部分连接、同步、加工和任务调度串在同一套数据集成流程里根据数据变化频率分别组织定时、增量或实时链路。这样到了 AI 真正开始调用数据的时候企业面对的就不再是一堆临时拼接的接口而是一条相对稳定、持续更新的数据供给链路。而后面要解决的实时性、异构连接、CDC、数据质量和链路可观测本质上都是在这条链路上继续往前补能力。一、AI要的不是更多数据而是“可用的数据”很多企业第一反应是既然 AI 需要数据那就把更多表、更多字段、更多历史数据接进来。但数据越多并不代表 AI 越好用。如果原始数据没有整理数据越多AI 反而越容易找错字段用错指标混淆统计时间把测试数据当正式数据把取消订单算进销售额混用含税和不含税金额重复计算不同组织层级的数据。对 AI 来说一份真正可用的数据至少要满足五个条件。时间上要及时用户问“现在库存还有多少”结果来自昨天晚上的快照即使算法完全正确也已经失去业务意义。结构上要稳定字段频繁改名、表结构经常变化、接口三天两头中断下游分析和 Agent 都会变得非常脆弱。口径上要统一“收入”“客户”“订单”“库存”“毛利”等概念必须有统一定义。否则同一个问题问不同系统可能得到完全不同的答案。权限上要可控AI 能查询数据不代表它天然应该拥有所有数据权限。尤其涉及财务、客户、员工和经营敏感信息时更需要建立权限边界。过程上要可追溯AI 给出一个数字以后企业最好能够回答这个数字从哪里来的什么时候更新经过哪些加工使用的是哪个指标口径所以 AI 项目的第一道门槛往往不是模型而是企业有没有建立一套可信的数据供给体系。二、为什么传统数仓会“供不上”传统数仓当然没有过时。它在统一历史数据、沉淀主题模型、支撑经营报表和管理分析方面依然非常重要。真正的问题是很多企业还在用过去服务报表的方式去支撑今天需要实时交互的 AI。传统数仓常见的工作模式是业务系统产生数据晚上定时抽取ETL 清洗转换加载到数仓第二天生成报表业务人员根据报表判断。这套模式很适合回答“昨天发生了什么”但 AI 开始参与业务之后企业会越来越多地问刚刚发生了什么现在正在发生什么哪些订单马上可能延期哪些客户需要立刻跟进哪些异常应该马上处理Agent 能不能根据最新状态执行下一步动作过去数据晚几个小时问题不大。现在晚几个小时可能直接导致销售错过跟进窗口库存判断失真风险预警延迟客服引用旧信息Agent 根据过期状态执行错误动作。所以传统架构的问题并不是“数仓没数据”。而是它原本就不是按照 AI 的数据供给方式设计的。三、传统数据架构缺少的第一项能力实时供数传统数据平台更习惯按固定周期跑批。晚上抽取晚上加工第二天使用。这种模式稳定、成本可控在传统 BI 场景下完全合理。但 AI 参与业务以后数据时效要求发生了变化。比如一个供应链 Agent 要判断哪些订单可能因为库存不足导致延期它至少需要同时获取最新订单状态当前库存在途采购生产排期供应商交期历史延期记录。如果订单是刚更新的而库存还是昨天的数据那 Agent 拿到的就不是同一时点的业务事实。模型再强也只能对错误的数据做更复杂的推理。不过实时供数并不意味着所有数据都要做到秒级。更合理的方式是根据业务场景划分时效等级关键不是一味追求实时。而是数据更新速度要和业务决策速度匹配。实际落地时这一层通常需要一个稳定的数据集成底座把 ERP、CRM、MES、WMS 等系统的数据按照不同场景持续送到数仓和分析层。像FineDataLink更适合承担的就是这部分基础工作根据不同业务需求组织批量、增量和实时同步任务让数据按规则、按时间进入后续分析链路。它解决的不是 AI 会不会回答。而是AI 开始回答之前正确的数据有没有先供上来。四、缺少的第二项能力异构数据连接企业的数据天然就不会只存在于一个系统。销售在 CRM。订单在 ERP。库存在 WMS。生产在 MES。资金可能又在财务和资金管理系统里。AI 想回答一个完整业务问题往往需要跨系统组合数据。比如“为什么这个客户最近不再下单”可能要同时分析订单金额和频次产品退货客户投诉交付及时率折扣变化回款情况销售拜访记录。问题是这些数据通常散落在不同系统。过去很多企业采用点对点接口。A 对 B。B 对 C。报表再单独连 A、B、C。业务一变再开发一批接口。系统少的时候还能维护。系统越来越多以后很容易出现同一数据被重复同步字段映射规则不一致接口缺乏统一监控上游一个字段改变下游多个任务同时报错出现异常后很难判断到底是哪条链路的问题。所以 AI 时代需要的不只是“接口能不能通”。更需要连接、同步、转换和调度能够复用。这也是 FineDataLink 更适合发挥价值的位置把原来散落在不同项目和脚本里的数据接口逐步组织成统一的数据集成能力。这样以后新增 AI 场景时不必再从头开发一遍数据接入逻辑。五、缺少的第三项能力CDC和增量数据意识很多数据任务到现在还在采用全量抽取。每天整张表重新读一遍、算一遍、写一遍。数据量小的时候简单直接。但规模一上来很快就会遇到任务越来越慢对业务数据库压力越来越大数据更新还是不够及时。更重要的是AI 真正关心的往往不是整张表。而是刚刚发生了什么变化。比如哪个客户刚刚下单哪个订单刚刚取消哪个库存刚刚跌破阈值哪个供应商刚刚发生异常哪个账户刚刚出现风险交易这就是 CDC 的价值。CDC也就是变更数据捕获本质上是捕获新增、修改和删除事件再把变化传递到下游。它代表一种架构思路的变化从“定期搬运整张表”转向“持续传递业务变化”。实际项目中可以通过FineDataLink 5.0这类数据集成平台把全量同步、增量同步、CDC、数据加工和任务调度放在同一套链路中管理。但工具只是负责捕获变化。企业还要明确哪些变化必须同步哪些字段需要脱敏删除事件怎么处理任务失败如何恢复重复数据怎么去重变化数据如何进入指标体系。CDC 只有和业务规则结合起来才真正有价值。六、缺少的第四项能力从字段走向业务语义这是很多企业最容易忽略的一层。数据库里有字段不代表 AI 能理解业务。例如amtstatuscust_typeorg_idflag技术人员可能一眼就知道是什么意思。但 AI 真正需要知道的是销售额是否含税“有效客户”怎么定义订单“完成”是否包含部分交付统计日期按下单、发货还是回款毛利率分母是什么华东区域包含哪些组织如果这些概念没有统一AI 即使写出了正确 SQL也可能回答了错误的问题。所以数据准备至少要经历三层第一层原始数据保留业务系统原始事实。第二层加工数据完成清洗、转换、关联和汇总。第三层业务语义定义指标维度口径权限使用方式。AI 最终回答得准不准很多时候取决于第三层。在这条链路里FineDataLink 更适合解决数据怎么接进来、同步好、加工好。到了上层则需要继续把数据组织成业务能够理解的指标和分析模型。这时候FineBI Next更适合作为后续分析入口让业务人员和 AI 在统一数据和指标基础上进行查询、分析和自然语言交互。如果底层数据没有准备好AI 就是在脏数据上做聪明的推理。七、缺少的第五项能力数据链路可观测传统数据平台经常有一个问题报表错了。所有人只知道“数字不对。”但不知道究竟哪里出了问题。可能是上游系统没产生数据接口连接失败字段结构变化清洗规则执行错误过滤条件错误调度任务延迟下游加载失败数据重复或部分丢失。过去排查一次技术人员可能要在几个系统之间反复翻日志。AI 持续在线以后这种排查方式显然不够。所以关键数据链路至少要关注四类问题。完整性应该到的数据是不是都到了及时性有没有按约定时间更新一致性上下游记录数、金额和状态能不能对得上准确性数据是否符合业务规则FineDataLink 5.0 的价值不仅在于“能把数据搬过来”还在于将数据任务、同步链路、调度过程和数据质量规则纳入统一管理思路。例如当某个数据表突然少了 40% 的记录平台应该能够帮助团队尽快发现异常而不是等业务人员在 AI 对话中问出一个明显不合理的数字才意识到数据链路已经出了问题。八、缺少的第六项能力数据质量要持续运行很多企业的数据质量工作还停留在项目上线前。上线之前查空值。核金额。测接口。确认数据能跑通。上线之后等业务发现问题。但 AI 是持续运行的。数据质量也必须持续运行。因为 AI 场景里的数据错误更危险。传统报表错了一个数字业务可能还能发现。但错误数据进入 AI 后模型可能进一步生成一套看起来非常合理的分析。比如错误销售额被拿去做增长分析重复客户被用于客户价值排序过期库存被用于补货建议错误成本被拿去做利润预测。AI 不一定知道这些数据有问题。因为它们可能“格式完全正确只是业务逻辑错误”。所以质量规则应该直接进入数据加工链路。包括空值检查唯一性检查格式检查金额平衡跨表一致性业务状态校验更新及时性异常波动检查。例如在 FineDataLink 的同步和加工过程中对关键数据设置质量校验。发现异常以后不只是告诉你“数据错了”。还应该继续追到底是业务录入问题、源系统规则问题还是加工逻辑出了问题真正成熟的数据质量管理不是反复修结果。而是不断减少错误产生的原因。九、企业改造传统架构应该先做什么面对 AI 数据需求很多企业容易陷入两个极端要么觉得必须重建整个数仓要么直接把大模型接到数据库这两种方式都不够稳妥。更实际的升级路径可以分为五步。第一步盘点 AI 应用真正需要的数据不要先问“我们有哪些表”而要先问AI 要解决哪些业务问题用户会提出哪些问题每个问题需要哪些指标和维度数据更新频率要求多高哪些字段涉及敏感信息结果需要查询、预警还是触发动作第二步建立核心业务指标和语义先把收入、订单、客户、库存、成本、毛利等核心概念定义清楚。语义没有统一之前接入越多数据争议越多。第三步改造高价值链路不需要一次改造全部数据。可以优先选择AI 使用频率高的数据对时效敏感的数据跨系统关联价值高的数据错误成本较高的数据能够快速验证收益的数据第四步把同步和质量规则平台化将连接、同步、转换、调度和质量检查纳入统一平台减少大量分散脚本和个人维护。第五步建立 AI 数据使用反馈闭环持续记录用户问了什么AI 使用了哪些数据哪些问题回答失败哪些指标经常被追问哪些回答被业务纠正哪些数据需要补充或重新定义这些反馈会反过来推动指标、语义、数据链路和权限体系持续改进。十、不要把 AI 数据问题误判成模型问题当 AI 回答不准确时企业往往第一时间怀疑模型换一个更大的模型调整提示词增加向量库增加 Agent 工具重新训练模型但很多问题其实发生在数据层。如果数据延迟、口径不一、上下游不一致、权限混乱换模型通常只能让错误回答更流畅而不能让结果更可靠。可以用下面这张表判断问题大致属于哪一层表现可能根因优先检查方向查询结果总是过期数据更新延迟同步频率、CDC、调度任务同一问题每次答案不同口径或数据范围不稳定指标定义、语义层、权限AI 找不到相关信息数据未接入或结构不可理解数据源覆盖、加工模型、标签答案数字明显不对数据质量或关联逻辑错误质量规则、主数据、关联关系偶尔完全无法回答链路或服务不稳定任务监控、接口、日志只能回答简单问题缺少业务语义与分析模型指标体系、维度体系、分析场景AI 应用的质量是模型质量、数据质量和业务语义共同决定的。最后总结AI 时代企业要重做的是数据供应链传统数仓并没有过时。过时的是一种单一想象只要把数据定时搬进数仓做几张报表企业就拥有了数据能力。AI 时代数据架构需要补上的能力至少包括从批处理优先走向按场景供数从单一数据库连接走向异构数据组合从全量搬运走向增量和变更传递从字段管理走向业务语义管理从结果交付走向数据服务化从上线前检查走向持续质量治理从任务执行走向全链路可观测从报表消费走向 AI 与业务协同使用AI 的竞争表面上是模型能力的竞争落到企业内部最终往往是数据供应链的竞争。谁能让数据更及时、更准确、更有语义、更可追溯谁就更有可能把 AI 从演示效果变成稳定的生产力。AI 不缺模型企业真正缺的是一条能够持续供数、可信供数、按需供数的数据链路。 
长河君 · 2026/10/14 9:53:20 · 阅读 1.2k AI要数据，数仓却供不上：传统数据架构到底缺了什么？
最近两年很多企业都在做一件事给业务系统接入 AI。客服要接智能问答销售希望 AI 帮忙分析客户财务开始尝试经营预测管理层希望直接用自然语言问数据研发团队也在探索让 Agent 调用企业知识库、指标库和业务系统。模型越来越强但真正落地后经常会碰到一个很现实的问题AI 已经准备好了数据却供不上。不是企业没有数据。恰恰相反。ERP、CRM、MES、WMS、财务系统、供应链系统、费控平台再加上大量 Excel企业手里的数据越来越多。真正的问题是真正能够被 AI 及时、稳定、准确使用的数据并没有想象中那么多。AI 时代的数据问题已经不只是“把数据存进数仓”这么简单。传统数仓解决的是数据集中、历史沉淀和报表分析。而 AI 应用需要的是一套更完整的数据供应链数据能够及时进入、准确加工、保留业务语义、按权限调用、出了问题能够追溯并且在业务变化后快速调整。这恰恰是很多传统数据架构需要补上的部分。也正因为如此企业现在做 AI 数据底座首先要解决的往往不是模型怎么接而是底层的数据链路能不能先稳定跑起来。ERP、CRM、MES、WMS 等系统里的数据需要按照不同业务场景持续进入数仓和后续分析环境数据变化以后下游也要能够及时跟上。FineDataLink 5.0可以把这部分连接、同步、加工和任务调度串在同一套数据集成流程里根据数据变化频率分别组织定时、增量或实时链路。这样到了 AI 真正开始调用数据的时候企业面对的就不再是一堆临时拼接的接口而是一条相对稳定、持续更新的数据供给链路。而后面要解决的实时性、异构连接、CDC、数据质量和链路可观测本质上都是在这条链路上继续往前补能力。一、AI要的不是更多数据而是“可用的数据”很多企业第一反应是既然 AI 需要数据那就把更多表、更多字段、更多历史数据接进来。但数据越多并不代表 AI 越好用。如果原始数据没有整理数据越多AI 反而越容易找错字段用错指标混淆统计时间把测试数据当正式数据把取消订单算进销售额混用含税和不含税金额重复计算不同组织层级的数据。对 AI 来说一份真正可用的数据至少要满足五个条件。时间上要及时用户问“现在库存还有多少”结果来自昨天晚上的快照即使算法完全正确也已经失去业务意义。结构上要稳定字段频繁改名、表结构经常变化、接口三天两头中断下游分析和 Agent 都会变得非常脆弱。口径上要统一“收入”“客户”“订单”“库存”“毛利”等概念必须有统一定义。否则同一个问题问不同系统可能得到完全不同的答案。权限上要可控AI 能查询数据不代表它天然应该拥有所有数据权限。尤其涉及财务、客户、员工和经营敏感信息时更需要建立权限边界。过程上要可追溯AI 给出一个数字以后企业最好能够回答这个数字从哪里来的什么时候更新经过哪些加工使用的是哪个指标口径所以 AI 项目的第一道门槛往往不是模型而是企业有没有建立一套可信的数据供给体系。二、为什么传统数仓会“供不上”传统数仓当然没有过时。它在统一历史数据、沉淀主题模型、支撑经营报表和管理分析方面依然非常重要。真正的问题是很多企业还在用过去服务报表的方式去支撑今天需要实时交互的 AI。传统数仓常见的工作模式是业务系统产生数据晚上定时抽取ETL 清洗转换加载到数仓第二天生成报表业务人员根据报表判断。这套模式很适合回答“昨天发生了什么”但 AI 开始参与业务之后企业会越来越多地问刚刚发生了什么现在正在发生什么哪些订单马上可能延期哪些客户需要立刻跟进哪些异常应该马上处理Agent 能不能根据最新状态执行下一步动作过去数据晚几个小时问题不大。现在晚几个小时可能直接导致销售错过跟进窗口库存判断失真风险预警延迟客服引用旧信息Agent 根据过期状态执行错误动作。所以传统架构的问题并不是“数仓没数据”。而是它原本就不是按照 AI 的数据供给方式设计的。三、传统数据架构缺少的第一项能力实时供数传统数据平台更习惯按固定周期跑批。晚上抽取晚上加工第二天使用。这种模式稳定、成本可控在传统 BI 场景下完全合理。但 AI 参与业务以后数据时效要求发生了变化。比如一个供应链 Agent 要判断哪些订单可能因为库存不足导致延期它至少需要同时获取最新订单状态当前库存在途采购生产排期供应商交期历史延期记录。如果订单是刚更新的而库存还是昨天的数据那 Agent 拿到的就不是同一时点的业务事实。模型再强也只能对错误的数据做更复杂的推理。不过实时供数并不意味着所有数据都要做到秒级。更合理的方式是根据业务场景划分时效等级关键不是一味追求实时。而是数据更新速度要和业务决策速度匹配。实际落地时这一层通常需要一个稳定的数据集成底座把 ERP、CRM、MES、WMS 等系统的数据按照不同场景持续送到数仓和分析层。像FineDataLink更适合承担的就是这部分基础工作根据不同业务需求组织批量、增量和实时同步任务让数据按规则、按时间进入后续分析链路。它解决的不是 AI 会不会回答。而是AI 开始回答之前正确的数据有没有先供上来。四、缺少的第二项能力异构数据连接企业的数据天然就不会只存在于一个系统。销售在 CRM。订单在 ERP。库存在 WMS。生产在 MES。资金可能又在财务和资金管理系统里。AI 想回答一个完整业务问题往往需要跨系统组合数据。比如“为什么这个客户最近不再下单”可能要同时分析订单金额和频次产品退货客户投诉交付及时率折扣变化回款情况销售拜访记录。问题是这些数据通常散落在不同系统。过去很多企业采用点对点接口。A 对 B。B 对 C。报表再单独连 A、B、C。业务一变再开发一批接口。系统少的时候还能维护。系统越来越多以后很容易出现同一数据被重复同步字段映射规则不一致接口缺乏统一监控上游一个字段改变下游多个任务同时报错出现异常后很难判断到底是哪条链路的问题。所以 AI 时代需要的不只是“接口能不能通”。更需要连接、同步、转换和调度能够复用。这也是 FineDataLink 更适合发挥价值的位置把原来散落在不同项目和脚本里的数据接口逐步组织成统一的数据集成能力。这样以后新增 AI 场景时不必再从头开发一遍数据接入逻辑。五、缺少的第三项能力CDC和增量数据意识很多数据任务到现在还在采用全量抽取。每天整张表重新读一遍、算一遍、写一遍。数据量小的时候简单直接。但规模一上来很快就会遇到任务越来越慢对业务数据库压力越来越大数据更新还是不够及时。更重要的是AI 真正关心的往往不是整张表。而是刚刚发生了什么变化。比如哪个客户刚刚下单哪个订单刚刚取消哪个库存刚刚跌破阈值哪个供应商刚刚发生异常哪个账户刚刚出现风险交易这就是 CDC 的价值。CDC也就是变更数据捕获本质上是捕获新增、修改和删除事件再把变化传递到下游。它代表一种架构思路的变化从“定期搬运整张表”转向“持续传递业务变化”。实际项目中可以通过FineDataLink 5.0这类数据集成平台把全量同步、增量同步、CDC、数据加工和任务调度放在同一套链路中管理。但工具只是负责捕获变化。企业还要明确哪些变化必须同步哪些字段需要脱敏删除事件怎么处理任务失败如何恢复重复数据怎么去重变化数据如何进入指标体系。CDC 只有和业务规则结合起来才真正有价值。六、缺少的第四项能力从字段走向业务语义这是很多企业最容易忽略的一层。数据库里有字段不代表 AI 能理解业务。例如amtstatuscust_typeorg_idflag技术人员可能一眼就知道是什么意思。但 AI 真正需要知道的是销售额是否含税“有效客户”怎么定义订单“完成”是否包含部分交付统计日期按下单、发货还是回款毛利率分母是什么华东区域包含哪些组织如果这些概念没有统一AI 即使写出了正确 SQL也可能回答了错误的问题。所以数据准备至少要经历三层第一层原始数据保留业务系统原始事实。第二层加工数据完成清洗、转换、关联和汇总。第三层业务语义定义指标维度口径权限使用方式。AI 最终回答得准不准很多时候取决于第三层。在这条链路里FineDataLink 更适合解决数据怎么接进来、同步好、加工好。到了上层则需要继续把数据组织成业务能够理解的指标和分析模型。这时候FineBI Next更适合作为后续分析入口让业务人员和 AI 在统一数据和指标基础上进行查询、分析和自然语言交互。如果底层数据没有准备好AI 就是在脏数据上做聪明的推理。七、缺少的第五项能力数据链路可观测传统数据平台经常有一个问题报表错了。所有人只知道“数字不对。”但不知道究竟哪里出了问题。可能是上游系统没产生数据接口连接失败字段结构变化清洗规则执行错误过滤条件错误调度任务延迟下游加载失败数据重复或部分丢失。过去排查一次技术人员可能要在几个系统之间反复翻日志。AI 持续在线以后这种排查方式显然不够。所以关键数据链路至少要关注四类问题。完整性应该到的数据是不是都到了及时性有没有按约定时间更新一致性上下游记录数、金额和状态能不能对得上准确性数据是否符合业务规则FineDataLink 5.0 的价值不仅在于“能把数据搬过来”还在于将数据任务、同步链路、调度过程和数据质量规则纳入统一管理思路。例如当某个数据表突然少了 40% 的记录平台应该能够帮助团队尽快发现异常而不是等业务人员在 AI 对话中问出一个明显不合理的数字才意识到数据链路已经出了问题。八、缺少的第六项能力数据质量要持续运行很多企业的数据质量工作还停留在项目上线前。上线之前查空值。核金额。测接口。确认数据能跑通。上线之后等业务发现问题。但 AI 是持续运行的。数据质量也必须持续运行。因为 AI 场景里的数据错误更危险。传统报表错了一个数字业务可能还能发现。但错误数据进入 AI 后模型可能进一步生成一套看起来非常合理的分析。比如错误销售额被拿去做增长分析重复客户被用于客户价值排序过期库存被用于补货建议错误成本被拿去做利润预测。AI 不一定知道这些数据有问题。因为它们可能“格式完全正确只是业务逻辑错误”。所以质量规则应该直接进入数据加工链路。包括空值检查唯一性检查格式检查金额平衡跨表一致性业务状态校验更新及时性异常波动检查。例如在 FineDataLink 的同步和加工过程中对关键数据设置质量校验。发现异常以后不只是告诉你“数据错了”。还应该继续追到底是业务录入问题、源系统规则问题还是加工逻辑出了问题真正成熟的数据质量管理不是反复修结果。而是不断减少错误产生的原因。九、企业改造传统架构应该先做什么面对 AI 数据需求很多企业容易陷入两个极端要么觉得必须重建整个数仓要么直接把大模型接到数据库这两种方式都不够稳妥。更实际的升级路径可以分为五步。第一步盘点 AI 应用真正需要的数据不要先问“我们有哪些表”而要先问AI 要解决哪些业务问题用户会提出哪些问题每个问题需要哪些指标和维度数据更新频率要求多高哪些字段涉及敏感信息结果需要查询、预警还是触发动作第二步建立核心业务指标和语义先把收入、订单、客户、库存、成本、毛利等核心概念定义清楚。语义没有统一之前接入越多数据争议越多。第三步改造高价值链路不需要一次改造全部数据。可以优先选择AI 使用频率高的数据对时效敏感的数据跨系统关联价值高的数据错误成本较高的数据能够快速验证收益的数据第四步把同步和质量规则平台化将连接、同步、转换、调度和质量检查纳入统一平台减少大量分散脚本和个人维护。第五步建立 AI 数据使用反馈闭环持续记录用户问了什么AI 使用了哪些数据哪些问题回答失败哪些指标经常被追问哪些回答被业务纠正哪些数据需要补充或重新定义这些反馈会反过来推动指标、语义、数据链路和权限体系持续改进。十、不要把 AI 数据问题误判成模型问题当 AI 回答不准确时企业往往第一时间怀疑模型换一个更大的模型调整提示词增加向量库增加 Agent 工具重新训练模型但很多问题其实发生在数据层。如果数据延迟、口径不一、上下游不一致、权限混乱换模型通常只能让错误回答更流畅而不能让结果更可靠。可以用下面这张表判断问题大致属于哪一层表现可能根因优先检查方向查询结果总是过期数据更新延迟同步频率、CDC、调度任务同一问题每次答案不同口径或数据范围不稳定指标定义、语义层、权限AI 找不到相关信息数据未接入或结构不可理解数据源覆盖、加工模型、标签答案数字明显不对数据质量或关联逻辑错误质量规则、主数据、关联关系偶尔完全无法回答链路或服务不稳定任务监控、接口、日志只能回答简单问题缺少业务语义与分析模型指标体系、维度体系、分析场景AI 应用的质量是模型质量、数据质量和业务语义共同决定的。最后总结AI 时代企业要重做的是数据供应链传统数仓并没有过时。过时的是一种单一想象只要把数据定时搬进数仓做几张报表企业就拥有了数据能力。AI 时代数据架构需要补上的能力至少包括从批处理优先走向按场景供数从单一数据库连接走向异构数据组合从全量搬运走向增量和变更传递从字段管理走向业务语义管理从结果交付走向数据服务化从上线前检查走向持续质量治理从任务执行走向全链路可观测从报表消费走向 AI 与业务协同使用AI 的竞争表面上是模型能力的竞争落到企业内部最终往往是数据供应链的竞争。谁能让数据更及时、更准确、更有语义、更可追溯谁就更有可能把 AI 从演示效果变成稳定的生产力。AI 不缺模型企业真正缺的是一条能够持续供数、可信供数、按需供数的数据链路。