导读传统数仓开发并没有因为 AI 出现而消失变化的是完成工作的方式。围绕统一 Lakehouse数据工程 Agent、CZ-CLI 与数据分析 Agent 串成一条链路从需求理解、建模开发和数据质量治理一直延伸到语义建设、自然语言问数与持续回归。AI 如何改变数仓开发方式传统数仓开发已经形成一套稳定流程业务需求进入后依次完成需求分析、数据接入、数据建模、SQL 开发、调度配置、测试发布和结果验证。问题也很明确开发人员需要掌握多种 SQL 方言以及 Java、Python、建模和调度等技能需求从提出到落地链路长任务故障、数据质量和性能调优持续消耗人工指标口径、字段语义和业务逻辑又往往散落在人员经验和零散文档中。AI 带来的变化不是取消这些环节而是改变完成这些工作的方式。自然语言可以成为新的开发入口由 AI 辅助建模、生成 SQL、配置调度进一步参与数据质量、语义治理和作业诊断同时把开发过程中的规则、口径和知识沉淀为可复用资产最终服务自然语言问数。在云器的产品架构中底层仍是统一的 Lakehouse负责结构化、半结构化和非结构化数据的存储与处理。向上提供三类入口Studio 面向人JDBC、Java SDK、Python SDK 等面向应用ClickZetta CLICZ-CLI面向 Agent。平台上内置数据工程 Agent 和数据分析 Agent并通过 AI Gateway 统一管理模型接入、模型路由、API 密钥和版本等能力。这样一套 Lakehouse 可以同时服务人、应用与 AI Agent共享同一份数据和同一套权限。端到端流程被拆成两个阶段前半段完成需求理解、数据建模、数据准备、质量检查和语义层建设后半段进入日常治理业务人员持续问数问题反馈再回到语义治理与评测形成循环。数据工程 Agent从需求理解到数据准备演示使用一个虚构的“沐林咖啡”连锁零售场景。需求中包含全国门店、自营与联营、会员、SKU、优惠券等业务要素并预设业务波动和异常用于验证从建仓到问数的完整链路。第一步交给数据工程 Agent。它面向数据工程师覆盖数据集成与同步、数据开发与调度、SQL 转换与流式计算、数仓建模与语义层、数据质量与运维诊断、探索分析与资源管理等环节。传统方式下需要在开发界面逐项创建任务、写 SQL、配置调度现在可以直接提交需求文档让 Agent 先理解业务画像、数据模型、数据规模和异常设计再生成 DDL、创建任务并准备数据。需求文档被放入任务目录后Agent 先完成需求理解和建模再生成相关 SQL 与任务。为了完整展示流程样例数据由 Agent 生成真实生产环境中更常见的做法是先通过数据集成接入已有数据源再根据业务逻辑生成 DWD、DWS、ADS 等下游加工链路。核心变化在于开发人员不再需要手工完成每一个界面动作和代码草稿而是把业务逻辑交给 Agent 执行再对结果进行确认。最终准备出 5 张维度表和 5 张事实表总量约100 万行同时定义12 个核心指标和11 个参考 SQL作为后续分析和治理的基础。CZ-CLI先治理数据质量再创建分析域数据准备完成后下一步不是立即问数而是先处理数据质量。CZ-CLI 把 SQL 执行与数据探索、Studio 任务开发与调度、数据集成与实时同步、任务运维诊断、数据质量校验以及数据分析 Agent 的调用统一到一个命令行入口中。它本身也可以作为 Agent 使用或者作为其他智能体的子 Agent被外部开发工具和业务智能体调用。在样例中CZ-CLI 先扫描数据质量识别订单时间、优惠券核销和门店缺货等问题并给出对应的检查与修复过程。订单时间原本全部停留在 00:00:00修复后98.3%的记录包含非零分钟或秒优惠券数据原先无法形成有效核销关联修复后核销率为13%即15,573 / 119,989并补齐 coupon 与 order 的双向关联缺货数据原本只有2,971条缺货事件没有正常状态作为分母补入18,160条正常记录后可以计算约14.1%的断货率。这里的“修复”并不意味着生产环境把业务判断完全交给 AI。质量规则中既有通用规则也有按行业和业务沉淀的规则可以作为 Skill 持续扩充。AI 负责发现问题、分析影响并生成修复建议真实场景仍需要数据开发人员确认业务逻辑再执行修改。完成第一轮数据质量治理后开始创建分析域。数据分析 Agent 面向自然语言分析不要求业务人员知道 SQL 和物理表名管理员负责分析域、语义层、指标和知识的建设。CZ-CLI 可以基于已有 Schema 一句话创建分析域自动加载相关表并识别字段语义、表关联关系和分析上下文。分析域创建后还要进行冒烟测试。表能够加入分析域并不等于已经具备可靠的问数能力关键在于表之间的关系、字段类型、可过滤维度和指标口径是否正确。CZ-CLI 可以继续创建域级提示词和基础指标也可以根据已有指标文档批量生成指标。对于新业务域一部分基础指标可以直接从表结构和业务语义中生成再由人工补充复杂口径。到这里已经可以完成基础的自然语言问数走通了一个基本的端到端通路但这仅仅是开始。语义层治理从基础问数到复杂业务口径基础问数跑通后重点转向语义层质量。首先对分析域进行评估检查字段语义是否一致、维度和指标标记是否正确、表关联是否缺失、关键指标是否遗漏。问题确认后可以通过 CZ-CLI 修改别名、Comment、关联关系、字段语义类型或指标定义再用实际问题做验证。简单指标之外还需要处理复杂业务逻辑。答案构建器通过 SQL 的声明式表达能力把复杂计算固化成可复用模板知识库则承载业务口径、场景规则和业务知识。已有文档可以直接用于生成知识库没有现成文档时也可以先基于 Schema、表关系和业务内容生成基础知识再持续补充。两者共同为复杂问数提供更明确的上下文和计算约束。语义层不是一次建设后就保持稳定。新增表、字段、指标或业务场景都可能重新引入歧义。演示重点展示了三类二义性同名异义例如门店城市与会员常驻城市都叫 city同义异名例如优惠券渠道和订单渠道对同一业务渠道采用不同字符串粒度混淆例如 discount_amount 在订单表和订单明细表中的聚合层级不同。危险之处在于这类 SQL 往往可以正常执行只是结果并非用户真正想要的答案。除了二义性还有更隐蔽的逻辑问题。比如指标公式没有按业务口径过滤订单状态被标记为维度的字段几乎没有区分度同一业务实体在不同表中的数据值不一致同类字段的语义类型标记存在残余。样例中campaign_tag 和 product_family 的 NULL 率分别达到98%和95%属于典型“死维度”stockout_flag 的语义标记不一致则会影响按断货状态进行 GROUP BY 分析。用真实问题和评测集形成持续回归这些问题通过“发现—确认—修复—验证”的方式处理。CZ-CLI 和数据分析 Agent 先扫描语义层给出问题清单、影响和建议业务逻辑确认后再修改指标公式、字段描述、关联关系和语义标记。目标不是追求一次性自动化而是降低排查成本把原来依赖人工逐表检查的工作转成可重复执行的治理流程。治理完成后需要用真实问题验证结果。演示中构造 10 个业务问题覆盖单均毛利、毛利率、GMV、渠道核销率、触达点击率和断货率等指标通过预期值、Agent 回答和判定结果逐项检查。验证后的问题继续沉淀为评测集后续可以定时运行或在模型、表结构、字段和业务逻辑变化后重新回归。在随后的一次日常评测任务中10 条样本全部执行完成通过率为80%。这也说明语义层治理不是“建完即结束”业务人员的正确问答可以沉淀为基线错误问答通过反馈进入治理流程修复后再加入回归集。随着问题不断积累分析域形成持续的质量闭环。回到完整链路需求进入后先由数据工程 Agent 完成理解、建模和数据准备再由 CZ-CLI 处理数据质量和语义构建进入日常阶段后数据分析 Agent 承接业务问数管理员围绕语义问题持续评测与治理。数据工程 Agent 负责 SQL 开发、数仓建模、调度发布和运维诊断数据分析 Agent 为业务人员提供自然语言问数并承载分析域、指标和语义能力CZ-CLI 则连接数仓、Studio 与数据分析 Agent作为可程序化调用的统一接口。三个 Agent 围绕同一个 Lakehouse 串成一条协作链路。自然语言建数仓的重点不只是“用一句话生成 SQL”。更完整的路径是需求进入后用 AI 建模和开发用规则和 AI 做数据质量治理再建立分析域、指标、答案构建器和知识库随后持续识别语义二义性与隐性问题并通过真实问题和评测集做日常回归。代码编写和重复操作被更多交给 AI业务口径判断、修复确认和最终决策仍然保留在人这一侧。云器科技官网 - 改变数据的使用方式更多内容欢迎关注「云器科技」官网云器科技-多云及一体化数据平台提供