一、引言：财务数仓为什么需要AI？

财务数仓的特殊性

在电商数仓体系中，财务域是复杂度最高、容错率最低的领域。不仅因为财务对于数据准确性的要求高，也因为财务是横向域，与几乎所有的域都有数据交叉，因此对业务 Sense 的要求很高。财务数仓工程师本质上在做三件事：

• 业务翻译： 将交易、支付、资金、促销补贴、成本等数十个业务系统的数据，翻译成通用的财务语言；
• 资产架构： 从 ODS 到 DWD、DWS、ADS 层层构建，确保财务 UE、财务管报等公司核心指标算得准、算得快；
• 质量兜底： GMV 口径是否统一，退款是否扣减，分摊是否跨周期对齐，任何一个字段的偏差都可能导致错误的经营决策。

财务域的独特挑战在于：字段间存在严格的数学公式关系（正向－冲销＝冲销之后），业务规则涉及跨周期分摊，对于质量的要求极高。如果单纯依靠人工兜底，要么容易出错，要么需要冗余大量人力做复核。尤其是在交付压力大的时候，质量问题就更容易被忽视。

痛点聚焦

从财务数仓的特殊性出发，我们可以总结财务数仓的痛点，大体可以分为如下几类：

基本上，在需求承接的每个环节，都可能因为"人"的问题，带来隐患。

AI 大模型能带来什么改变

为了有效解决"人"的问题，比如催得太急、看不过来、没看仔细、理解错误等问题，我们引入 AI 来做改变。核心思路是：大模型的介入不是替代数仓开发工程师，而是在「需求理解 → 代码编写 → 质量测试 → 文档沉淀」每个环节注入强推理能力。利用 AI 来代替人做大量的重复性工作，同时减少低级错误概率。

那么为什么 AI 能做到这一点？从技术发展的趋势看，有三个核心能力支撑了这一变革：

• 超大上下文打破知识孤岛： 200k+ token 的上下文窗口，可以将表结构定义、词根字典、指标计算逻辑一次性注入模型的 “工作记忆”，实现基于全域元数据的推演，让大模型具有记忆；
• 业务语义的自动抽象与对齐： 大模型能理解 “日活”“留存率”“归因窗口” 等业务术语，并映射为具体 SQL 实现，减少因需求理解偏差导致的返工；Claude 在编码领域显著优于其他模型，是因为它能 “懂” 业务逻辑，而不是简单的机械执行；
• 突破人类极限的规范执行力： 人工在紧迫工期下规范遵守率通常明显下降，而大模型注入规范后，可稳定维持在高位。只要指令给得明确，大模型 “几乎” 不会出错。

参考：亚马逊 AWS 对于构建一个强大、具备自我纠错能力且能查询多种数据源的 Text-to-SQL 解决方案架构图。

二、应用场景概览：从「单点提效」到「全链路增强」

场景与提效预期

基于上述观点，在财务领域，大模型可以在哪些具体的环节落地呢？以下是根据笔者近期实践经验，列出的可落地场景及提效预期。

人机协作模式：数仓研发的「L3 时刻」

如果借用自动驾驶的分级标准，当前数仓大模型应用正处于从 L2（辅助驾驶）向 L3（有条件自动驾驶）过渡的阶段，即在明确的 Prompt 约束与规范文档支撑下，AI 能接管绝大部分标准化的执行动作。

在财务域的实践中，我们也是按照这套自动驾驶分级的方法，将日常工作拆解成了三级：

这种分工背后的逻辑是：规范执行是人类的短板、AI 的长板；业务判断是 AI 的短板、人类的长板。 人工在紧迫工期下对命名规范、分区约束、注释要求的遵守率通常明显下降，且容易因疲劳产生遗漏；而 AI 一旦"学会"了团队规范，输出的规范遵守度可稳定维持在较高水平。反过来，AI 无法替代的是那些需要理解业务上下文、权衡取舍、处理分歧的工作。

AI 对于数仓全链路研发的提效作用

学习 Andrej Karpathy 关于 ChatGPT 分享的内容时，最大的感受是：AI 最强的能力，是 "泛化"。 因此，如果我们可以把数仓研发的链路拆分清楚，那么 AI 必然能够对其中的每一个环节提效，最终带来研发效率的大幅度提升！

三、核心应用场景深度解析

AI OneData 标准化建模（财务核算数据项目）

背景：财务核算 OneData 为什么难搞？

因为：仅第一轮模型设计，就涉及百张以上的表、多个子域、十余个业务过程、数百个指标。如果考虑到后续的二次/三次迭代，工作量势必大到无法想象。在当前以交付为主的阶段，很难花费如此多的时间做基建。以某次核算项目为例，各层表数量分布如下：

同时，财务域的核心特征是来源多（全公司系统）、指标多（单表字段数众多），但以可累加指标为主。财务严格意义上没有原子指标，全是基于业务指标加工出来的派生指标，且一个财务指标往往有多种口径：业务口径、资金口径、财管报口径。并且，项目涉及多个子域（核算域、技术成本域、促销补贴域、商业化域、分析域），覆盖从「计费 → 核算 → 结算 → 财务分析」的端到端业务过程体系。如果要彻底理解核算 OneData 的构建，不仅要懂数仓，还要懂财务，还要熟悉公司财务系统，这个要求非常难做到！主要难点集中在四个方面：

口径溯源极其复杂： 大量逻辑在工程侧实现，绝大多数表缺失业务文档、技术文档、口径文档，口径逻辑需要基于代码猜测，存在错误可能性，溯源工作量巨大。

规范执行不一致： 财务域涉及表命名规范（DIM/DWD/DWS/ADM 各有格式要求）、时间周期规范（1d/7d/30d/wtd/mtd/ytd 等多种）、生命周期规范、刷新周期规范、标准字段英文命名原则（{主体}{业务场景}{币种标识}{度量类型}{时间单位}）。规范越细，人工遵守率越低。

跨域依赖复杂： 财务是横向域，与各业务域交叉。核算域依赖大量上游表，技术成本域需要从云服务、算法、产研人力、标注人力等多个来源接入数据。

文档输出繁琐： 每个 ADM 表都必须包含 OnePage 文档（OneData 方案最重要内容），加上口径文档、模型使用说明、下游 mapping 文档，文档间大量重复但需各写一遍。

所以，我们更需要通过 AI 的能力，来做一套新时代的建模方法论，以适应 “低投入、大设计” 的智能建模场景。

建模方法论：规范即 Prompt × 迭代收敛法 × 海量文件阅读

第一个方法论：规范沉淀是前提

AI 的输出质量完全取决于输入的规范文档质量。财务核算项目中，我们沉淀了完整的规范体系作为 Prompt 的核心输入，包括：

• 模型设计规范：表命名、时间周期、生命周期、刷新周期；
• 标准字段英文命名原则：{主体 /fin}{业务场景 / 费用类型}{币种标识}{度量类型}{时间单位}；
• 财务业务全链路设计理念：计费层 → 核算层 → 结算层 → 财务分析层；
• 业务过程总线矩阵：多个业务过程与多个维度的交叉关系；
• 数据质量监控规范：完整性、准确性、一致性、合规性、业务规则等多个大类。

第二个方法论：迭代是常态

不要期望 AI 一次给出完美结果。验证的关键是选择复杂字段进行抽查 —— 在财务场景中，重点验证涉及条件取值的字段（如分摊逻辑、冲销逻辑、多口径指标），对照 SQL 代码验证溯源路径。每次迭代的产物不只是修正后的输出，更重要的是规范文档的完善。因此，针对每次迭代的结果，快速识别要改动的点并修改，这一点就很重要。也就是说，AI 可以显著提升我们的迭代速度！

第三个方法论：海量文件阅读

因为超大的 Context，所以不仅可以把历史上已有的文档一次性灌入进去，也可以把原有设计链路的表和代码交给大模型理解，省去大量阅读和理解的时间。同时，能够帮我们精准地画出业务架构图，辅助数仓工程师理解业务、构建模型。例如财务数仓架构图，很多子模块的逻辑，都是大模型读取代码后输出思路，再由数仓团队整理形成的。

Prompt 和效果

将以上规范作为学习知识输入给模型，再把原始数据表给到模型，模型即可以产出建模建议。

Prompt 示例：

请读取以下规范文档：

• 数仓规范资产细则（含词根字典、命名规范）；
• 离线数仓开发规范白皮书；
• 团队 Cursor Rules；

分析目标表（输入对应的表名）的建表语句，按照数仓建模规范（ODS → DWD/DIM → DWS → ADM）的方式，输出重构后的建模建议。

第一次生成的效果展示了初步建模建议，在经过不断的调优和知识输入后，最终版本要丰富很多，形成了完整的财务核算数据 OneData 方案。

收益

经过一段时间的实施，第一版核算数据结构已经落地，效果如下：

• 效率提升显著： 百张表的口径溯源、文档输出等标准化工作大幅压缩；
• 规范遵守率大幅提升： 表命名、字段命名、时间周期等规范严格执行，遵守率较人工有明显改善；
• 可复用性强： 规范文档、工具脚本、Prompt 模板、工作流程 SOP 均可跨子域复用（已在核算域、技术成本域验证）；
• 数据质量监控体系： 基于口径逻辑自动推荐 DQC 规则（完整性、准确性、一致性、合规性、业务规则等多大类）。

AI SQL Coding 实践（财务 UE 表迭代案例）

实践思路

以财务 UE 表某次迭代为代表的案例，主要成果有：

• 代码结构优化，可读性大幅提升： 指标分段清晰、逻辑分层明确，维护成本明显降低；
• 代码开发速度提升： 在规范与口径已对齐的前提下，从需求到可上线代码耗时缩短；
• 性能优化： 整体基线提前完成，为下游留出更多缓冲时间。

那么，我们是如何实现这种成果的？主要靠两点，一是 PRD 快速阅读与理解，二是代码开发效率提升。

如何理解 SQL Coding 核心能力

PRD 阅读与理解方面，AI 能够帮我们实现：

快速将 PRD 中的目标、指标、维度、过滤条件提炼为结构化要点；对「大促期间」、「小仓卖家」、「冲销」等未精确定义的表述，自动生成待确认问题清单；输出「指标口径」「统计周期」「主键与粒度」等需确认条目。

代码开发效率提升方面，AI 能够帮我们实现：

基于词根、分层、命名规范与建表模板，生成符合数仓规范的 DDL 与 SELECT 语句；多维度聚合、归因逻辑、窗口函数、多层嵌套等复杂逻辑，由模型生成初版 SQL，人工校验微调；对存量长 SQL 进行分段、抽取公共逻辑、统一风格与注释。

实践中大模型显著提升点

财务 UE 表迭代需求使用 AI 开发后，具体效果如下：

指标结构分段、编码规范性、注释清晰度：

• 新表：按数仓分层与命名规范生成 DDL 与 SQL，指标按业务域/统计口径分段组织，注释完整（字段含义、口径说明、KEY 标记等），既符合规范又便于阅读。
• 旧表改造：在保留业务逻辑正确性的前提下，对历史「屎山」代码进行结构化改写——统一别名、补全注释、拆分过长子查询、显式写出分区过滤等，使后续维护与排查成本明显下降。
• 代码展示对比：改动前 vs 改动后，可从「可读性、规范遵守度、注释覆盖」等维度做对比分析。

代码撰写速度大幅度提升：

• AI Coding 的主要步骤：Step 1：整理需求 → 技术文档 将 BI 需求文档中的字段信息整理进技术文档，明确字段范围。
• Step 2：大模型分析字段来源 提示大模型读取 DWD 源码，分析哪些字段已存在、哪些需要新增关联。
• Step 3：大模型编写 ETL 代码 由大模型自动在 DWD → DWS → ADM 三层添加字段代码，输出改动代码集合。
• Step 4：命名规范校准 引入指标字典和 Cursor Rules，让大模型按规范重命名字段（去掉不规范后缀）。
• Step 5：测试 SQL 生成与跑数验证 大模型生成自测 SQL，逐步验证各层数据一致性，不通过时追问原因并溯源。

性能优化及自动调参：

• 自动识别性能瓶颈：结合执行计划、大表扫描、数据倾斜等常见问题，由模型分析 SQL 与表结构，指出潜在慢点。
• 优化建议生成：在分区裁剪、谓词下推、JOIN 顺序、中间结果物化等方面给出具体改写建议。
• 参数调优方案：针对 Spark/ODPS 等引擎的资源配置、并行度、倾斜处理参数，给出可落地的调优建议，供运维或开发同学选用。

基线优化提升案例：

• 原链路：多张表串行/并行产出，整体耗时较长。
• 新链路：经模型辅助做表合并与逻辑下沉，收敛至更少的表，整体耗时明显缩短。
• 优化效果：在保证口径一致的前提下，表数量与运行时间双降，基线提前完成，资源占用与调度依赖均得到简化。

AI 数据测试（财务 UE 表邮费迭代案例）

财务数据测试的特殊挑战

在数仓开发工作中，数据测试是保障数据质量的关键环节，但也是最复杂、最耗时的环节之一。特别是在财务类指标开发中，数据测试面临着多重挑战：

测试复杂度高，影响面广：

一个指标的改动往往不是孤立的，它会引发连锁反应，影响其他相关计算指标。在复杂的业务场景中，一个字段的修改可能需要同步验证数十个相关字段的正确性。这种复杂的依赖关系使得人工测试很难做到全面覆盖，容易出现遗漏

业务逻辑复杂，公式验证困难：

财务指标通常有明确的数学公式关系：正向 - 冲销 = 冲销之后：需要验证每个字段的正向值、冲销值、冲销之后值之间的计算关系；子项相加 = 汇总项：需要验证各个子项字段相加是否等于汇总字段；

财务的分摊逻辑涉及跨周期问题，难以验证：某些业务场景下，订单时间与收入确认时间不匹配，需要进行跨周期分摊，测试逻辑极其复杂。这些公式关系看似简单，但在实际测试中，需要考虑各种边界情况、精度问题、空值处理等，验证工作量巨大。

测试用例设计困难：

一个需求往往衍生出大量测试点，单纯凭借个人经验和能力，很难做到全面覆盖，容易出现测试盲区，包括：

• 字段级别的计算逻辑验证；
• 汇总关系的验证；
• 冲销逻辑的验证；
• 边界场景的验证；
• 精度问题的验证；
• 业务规则转化的验证。

业务语言到数据语言的转化困难：

业务人员描述的需求往往是自然语言，而数据测试需要将其转化为精确的数据验证逻辑。例如："退小仓场景下，卖家邮费出资放在第一笔收入冲销，挂在最后一单"；"邮费返利抵减技术服务费"；"跨周期分摊，商业化订单时间与交易订单时间不匹配"。

AI 在数据测试中的应用实践

那么，我们如何通过 AI，来解决这些复杂问题呢？以某次财务 UE 表邮费迭代项目为例，我们深度应用 AI 进行数据测试，取得了显著效果。

项目背景：

该项目涉及邮费相关字段的全面重构，包括：

• 迭代字段：修改多个邮费相关字段的计算逻辑；
• 新增字段：新增大批量邮费细分字段；
• 删除字段：废弃部分历史字段；
• 逻辑变更：邮费返利抵减逻辑调整、冲销逻辑优化等。

AI 应用场景：

1. 测试用例自动生成：向 AI 提出测试要求后，AI 能够自动生成完整的测试 SQL 和说明文档，包括：

• 正向-冲销=冲销之后的验证逻辑；
• 子项相加等于汇总项的验证逻辑；
• 业务规则转化的验证逻辑；
• 边界场景的验证逻辑。

2. 规则理解层面的测试补充：AI 能够从规则理解层面补充测试案例，如抽样验证、精度验证等，减少因理解不一致带来的质量问题。特别是在复杂的跨周期分摊场景中，AI 能够识别出人工容易忽略的测试点。

3. 复杂逻辑的逐步分析：针对复杂的业务逻辑，AI 能够逐步分析不符合预期的环节，帮助找到潜在的代码 Bug。例如在邮费冲销逻辑中，AI 能够分析退小仓场景下的多种分支情况，识别出逻辑漏洞。

4. 上下游影响分析：AI 能够分析一个字段的改动对上下游的影响，帮助识别需要同步验证的相关字段，避免遗漏。

5. 公式验证与精度问题诊断：AI 能够自动生成公式验证 SQL，并识别精度问题。在测试过程中，AI 能够区分真正的逻辑错误和可接受的精度误差，避免误报。

实际效果与收益

经过 AI 加持之后，效果和收益明显，包括：

开发效率提升：

测试 SQL 生成效率明显提升：从提出测试要求到生成完整测试 SQL，时间大幅缩短；测试用例覆盖度提升：AI 能够识别出人工容易忽略的测试点，测试覆盖更全面。

交付质量提升：

一次交付通过率显著提升：从规则理解层面补充测试案例，减少理解不一致带来的质量问题；针对复杂逻辑逐步分析，找到潜在代码 Bug；自动生成全面的测试用例，减少测试盲区。

问题发现能力提升：

AI 在测试过程中能够：发现人工难以发现的逻辑错误，识别精度问题并区分可接受的误差，分析复杂的业务规则转化问题，诊断上下游影响关系。

综合收益较高。通过 AI 辅助数据测试，整体交付质量大幅提升，主要体现在：测试覆盖更全面，减少遗漏，问题发现更及时，减少返工，测试效率更高，缩短测试周期，质量保障更可靠，提升交付信心。

AI 需求文档转换（财务 UE 表邮费复杂逻辑解读）

痛点

理解 PRD 和与业务产品反复核对口径，大约占数仓总体工作时间的较大比例。BI 需求文档往往复杂难懂，第一眼看过去看不懂。

实践案例：邮费 UE 迭代技术文档

以邮费 UE 迭代需求为例，BI 需求文档涉及大量字段口径调整、新增字段、废弃字段、冲销逻辑重写等复杂内容。例如通过飞书 MCP 让 Cursor 直接读取 BI 需求文档，大模型自动总结出两张表（DWS 层和 ADS 层）各自需要改什么。大模型输出的结论结构清晰，按表分类列出：

• 字段含义/口径调整（哪些字段的逻辑需要改）；
• 数据来源与计算点（应收邮费、实收邮费的新口径）；
• 新增字段清单（应收拆分、冲销相关、实收拆分、成本、UE 等）；
• 废弃字段清单（相关历史字段）；
• 冲销逻辑重点（退小仓规则）；
• 两表关系与实现顺序（先改 DWS 再改 ADS）。

Prompt 实例：读取「邮费逻辑梳理」文档内容，分析其文字描述与财务 UE 表的代码，分析要改动的点，帮我生成对应改动代码和改动原因注释。

通过这个分析结果，能够很快地定位要改动的代码，然后一步步理解业务逻辑和具体如何改动。

效果

经过这个过程快速 get 到 PRD 缺失的内容、快速对齐，总体沟通时间有效缩减。虽然在总时间占比上看似不高，但节省的是工程师最头疼的碎片化沟通时间。

四、总结与展望

核心价值

当前市场上，部分头部大厂由于自身产品策略的原因，限制了内部使用最新的大模型和 IDE 工具，导致一线使用大模型的效率受到制约。而我们则能够更灵活地选择最适合的工具组合，在使用技巧和经验积累上具备优势。例如，我们有如下两个方面的优势：

能力层面：

• 规范化规则遵守：注入规范后生成结果遵守度稳定维持在高位；
• 业务抽象能力：快速理解 PRD 中的目标、指标与口径，识别模糊点；
• 实际落地案例丰富：财务 UE 表迭代等项目已有可量化结果。

组织与场景层面：

• 模型选择灵活，不绑定单一厂商，按任务类型选用最优模型；
• 组织精简高效，从确定方向到试点上线路径清晰，试错迭代周期短；
• 离线数仓分层与规范稳定，模型易学易用、效果可预期；
• 离线任务可重跑、可回溯，模型产出便于充分校验后再上线。

未来展望

使用大模型的能力不仅仅局限在财务、局限在个人，也要向整个团队推广，包括：优先选择 1-2 个痛点明确、规范相对清晰的场景做试点；将有效的 Prompt 设计、上下文组织方式、测试用例模板等经验在团队内分享，形成可复用知识库；从「人做」为主转向「人定规则与口径、模型执行环节」的协作模式，让大模型成为数仓同学的日常助手。未来已来。

往期回顾

1.日志诊断 Skill：用 AI + MCP 一键解决BUG｜得物技术

2.Redis 自动化运维最佳实践｜得物技术 

3.Claude在得物App数仓的深度集成与效能演进

4.Claude Code + OpenSpec 正在加速 AICoding 落地：从模型博弈到工程化的范式转移｜得物技术

5.大禹平台：流批一体离线Dump平台的设计与应用｜得物技术

文 /丹克

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。

随着以Claude Code为代表的代码大语言模型（Code Large Language Model，以下简称Code LLM）在软件工程领域的普及，其在企业级数据仓库（以下简称数仓）建设中的应用逐渐从单一的代码补全向全链路辅助演进。本文旨在探讨Code LLM在电商数仓环境下的深度集成逻辑与工程实践。文章首先界定了数据确权中的人机边界，分析了内部数据工具向Agentic工作流演进的趋势，并提出了“认知运行时与执行运行时解耦”的架构范式。

本文认为，大模型在企业级数据仓库中的落地核心，主要体现在两大维度：一是数据确权（Data Rights Confirmation） ，二是规范化输入输出（Standardized I/O） 。以此为框架，结合得物App真实数仓建设与研发实践，系统阐述了基于Galaxy MCP的基础设施集成方案，并对智能视觉埋点、AI OneData建模、智能周报生成、策略孵化中心等典型场景的架构设计与运行逻辑进行深入分析。最后，针对大模型应用中存在的幻觉问题与合规风险，本文提出一套系统性的治理与管控机制。

一、核心逻辑界定：数仓开发中的人机边界与架构演进

Code LLM引入数仓的建设流程，并非简单的工具替换，而是对现有研发范式、职责边界及工具链架构的系统性升级。在讨论具体的提效场景前，必须首先厘清底层的逻辑支柱；若未能厘清权责边界与架构定位，大模型的引入极易演变为不可控的技术债务与运维风险。

数据确权边界：管理审批与技术实现的分离

数仓建设的工程起点是原始数据（ODS 层）的接入，该环节涉及数据来源的合法性、数据所有权的界定、个人可识别信息（Personally Identifiable Information，PII）的合规审查，以及数据质量的责任归属。这些属性决定了数据接入不仅是技术动作，更是企业内部的核心数据确权过程。在引入 AI 辅助能力时，必须严格区分**「管理审批」与「技术实现」**的权责边界：

管理审批（人类主导）： 数据的权限审批、合规性定责、业务口径的最终确认，属于具备法律与管理效力的行为。当前法律框架下，AI 不具备独立的民事主体资格，无法独立承担法律与管理责任，因此在确权决策环节，必须由明确的数据治理委员会或业务负责人完成人工审批与权责确认。

技术实现（AI 辅助）： 在完成人工确权与审批后，涉及的 DDL 脚本编写、同步任务模板配置、基础数据质量校验（Data Quality Check，DQC）规则生成等技术执行工作，可由 Code LLM 基于已确权的元数据自动化生成，并经人工复核确认后上线执行。

明确这一边界，既保障了企业数据资产的安全与合规，也为后续工程环节的 AI 深度介入提供了合规前提。

内部工具演进：从被动式 SaaS 到 Agentic 工作流

传统的数仓研发平台（如得物 App 内部数据研发平台 Galaxy）、BI 系统及指标字典，在形态上多属于被动式内部 SaaS 工具：即工具仅提供标准化的功能模块与图形化界面（GUI），无法主动理解并完成用户的业务意图，需依赖工程师的专业技能手动操作，属于典型的「人找功能」的被动响应模式，工具的价值上限取决于功能丰富度与用户的专业熟练度。

Code LLM 的引入，促使内部数据工具向 Agentic（智能体化）工作流演进。在这一模式下，核心交互方式由 GUI 转向意图驱动的自然语言交互界面（Language User Interface，LUI）；系统不再仅仅提供「编写 SQL 的环境」，而是能够接收业务意图（如「按特定维度统计退款归因」），在预设的权限与规则边界内，通过调用底层 API 自主完成元数据检索、逻辑组装，并输出最终的数据洞察或代码草案。这种演进重构了数据工具的核心价值逻辑：从「为专业人员提供功能组件」，转向「为业务用户交付可落地的任务结果」。

架构范式升级：认知运行时与执行运行时的解耦

在探讨 AI 与现有数仓架构的融合时，需先明确大模型在系统中的核心定位：大模型无法替代 Spark、Flink、ClickHouse 等传统大数据计算与存储引擎的核心算力能力，其核心价值是促成了计算架构中「认知决策」与「执行落地」的解耦分离，我们将其拆解为两个核心模块：认知运行时（Cognitive Runtime） 与执行运行时（Execution Runtime） 。

认知运行时： 由 LLM 充当核心载体，负责处理非结构化需求解析、业务逻辑到 SQL 的语义映射、代码规范校验及调优策略生成，核心处理语义与逻辑的推演工作。该模块不直接触碰物理数据，仅在数据权限管控体系的约束下，操作已确权授权的元数据（Metadata）与抽象语法树（Abstract Syntax Tree，AST）。

执行运行时： 由传统大数据计算引擎充当核心载体，负责海量数据的物理扫描、分布式计算与存储落地，核心处理确定性的算力调度与执行任务。

这种解耦架构，使得数仓系统既能保有传统引擎的高吞吐、高可靠特性，又能具备大模型的语义理解与逻辑泛化能力，同时与前文的权责边界、合规要求形成了架构层面的呼应。

本质洞察：规范化的输入与输出（Standardized I/O）

当我们试图用 AI 优化数仓系统时，若仅仅停留在「单点提效」的表层，最终往往会陷入「为了用 AI 而用 AI」的陷阱。大语言模型基于概率分布生成文本，存在固有的幻觉风险；在对数据准确性、口径一致性要求极高的数仓场景中，无约束的自然语言对话式开发（业内俗称 Vibe Coding，即无明确规范、凭感觉自由编码的模式），会导致代码风格发散、业务口径不一致、数据失真等严重问题，甚至引发合规风险。

剥离掉「AI 写代码」的表层形式，触碰数仓与 AI 融合的本质，其核心在于构建规范化的输入与输出（Standardized I/O）契约。无论是埋点设计、OneData 建模，还是周报生成与策略孵化，其底层逻辑高度一致：将模糊的业务需求，通过结构化模板、CSV、JSON 或 API 接口（规范化输入）喂给模型，并强制模型按照预设的 Markdown 模板、DDL 规范或报告框架（规范化输出）进行交付。这种基于规范的驱动开发模式（Spec-Driven Development，SDD），将大模型不可控的自由文本生成，转化为基于规范契约的受限定向编译，从根源上压缩了幻觉的产生空间，构成了 AI 在数仓中规模化应用的安全底座。

综上，明确的数据确权边界，与标准化的输入输出契约，共同构成了 Code LLM 在企业级数仓中安全、合规、规模化落地的两大核心支柱。

二、基础设施底座：Galaxy MCP 的标准化集成

要实现上述的“规范化输入与输出”，大模型必须具备感知和操作企业真实数据环境的能力。在实践中，研发团队基于模型上下文协议（Model Context Protocol, MCP），为内部数据研发平台（Galaxy）构建了标准化的集成底座。

MCP 协议：大模型与数仓环境的通信契约

Galaxy MCP 充当了 Code LLM与企业内部数据资产之间的桥梁。传统模式下，工程师需要手动复制表结构、日志信息喂给大模型；而在 MCP 架构下，大模型被赋予了“手和眼”。

通过提供统一的 HTTP Streamable 接口与 Bearer Token 鉴权机制，MCP 使得大模型能够在安全受控的前提下，直接调用底层数据平台的 API。这种集成的本质，是为大模型提供了标准化的环境感知输入。

核心工具集暴露与场景映射

Galaxy MCP 向大模型暴露了一系列高度结构化的工具（Tools），这些工具构成了 Agent 执行复杂任务的基础原子。核心 API 及其对应的数仓场景映射如下：

• 分析数据结构： 模型在编写 SQL 前，自动获取目标表的建表语句，确保字段名与数据类型绝对准确，消除幻觉。
• 追溯数据来源： 在 OneData 建模或排查数据异常时，模型自动查询上游血缘表，梳理复杂的依赖链路。
• 逻辑审查： 模型直接读取线上调度任务的真实 SQL 逻辑，用于代码重构或口径比对。
• 排查任务失败： 查找特定时间段内失败的运行实例。
• 根因分析： 模型获取完整的执行日志（如 Spark 报错堆栈），结合上下文自动分析报错原因并给出修复建议。

IDE 深度集成：鉴权链路

在工程落地中，Galaxy MCP 实现了与主流 AI IDE 的无缝集成。通过上述配置，开发者在 IDE 中只需输入自然语言指令（如：“读这个表试试：xxx.table_name”），底层大模型即可自动路由至 Galaxy MCP，完成鉴权、API 调用与结果解析的闭环。这标志着数仓开发正式迈入 Agentic 时代。

三、工程实践落地：基于规范化 I/O 的效能演进

本章将结合得物App数仓研发实证，以实际应用阐述上述底层逻辑在实际业务线中的落地场景。下面的每一个场景，均是在内部经过多轮POC验证，是“规范化输入与输出”理念的具体投射。

智能视觉埋点：多模态输入到结构化 JSON 的映射

业务背景： 埋点设计是数仓数据采集的前置环节。传统流程长期存在三大痛点：

• 成本高： PRD 交互复杂，且开发过程中变更频繁，人工对齐耗时。
• 业务参数发散： 历史迭代频繁、经手人多，同类交互动作命名混乱（如 like_click 与 click_like_btn 混用），极大增加下游清洗成本。
• 质量不可控： 埋点规范弱且参数点状上报，不同业务规范不一致，无法准确判断上线/修改埋点会导致下游哪些核心指标发生异常。

规范化 I/O 逻辑：

• 需求解析与确认（前置收敛）： 构建规范化的 PRD 理解 Prompt，结合原生多模态模型（如 Gemini 1.5 Pro，保留 UI 设计稿的颜色、层级、空间位置等视觉特征），输出标准化的“埋点提需文档”。经业务多轮确认无误后，再进入实质埋点设计环节。
• 智能埋点设计（上下文注入）： 整合三类核心资产作为模型输入：① 当前页面历史权威埋点字典；② 人工沉淀的埋点规范与经验；③ 离线大模型梳理的“埋点-指标”血缘关系。模型基于此契约输出设计方案。
• 规范化输出（Schema 强校验）： 强制模型输出符合企业 Schema 校验的 JSON 格式，核心实现三点：埋点格式化： event_id 必须严格符合 [event]_[page]_[block] 的格式，且事件与参数定义强绑定业务规范字典，杜绝开发随意造词。参数收敛： 基于历史权威字典，自动映射并收敛同义参数，消除发散。参数完备性： 结合业务场景自动补全必填上下文参数，避免漏埋。

实测效能： 在某社区线双周迭代抽样中，埋点设计人力投入从平均10人日缩减至5人日。更核心的收益在于：

• 一致性提升至 95%： 通过模型前置校验，有效遏制了存量埋点的无序扩张。
• 质量提升与规则沉淀： 全面盘点并固化了现有埋点规则，将数据质量卡点前置到设计阶段，降低埋点设计引发数仓下游指标计算的事故率。

AI OneData 建模：血缘 CSV 到标准 DDL 的编译

业务背景： OneData 方法论要求严格的数据分层与指标口径统一。但在人工执行时，面对复杂的表血缘关系，规范的遵守率往往存在波动，且梳理历史口径耗时巨大。一个典型的 OneData 项目，纯人工梳理口径溯源、编写白皮书往往需要耗费数月。

规范化 I/O 逻辑：

• 规范化输入： 研发团队摒弃了让模型直接阅读杂乱 SQL 的做法，而是通过脚本预先提取底层表的血缘关系与字段清单，将其转化为高度结构化的 CSV 文件（如 某域onedata_表血缘.csv、某域onedata_字段清单.csv）。这些 CSV 文件连同格式严苛的 Markdown 规范文档（规定了字段分隔符 ##、溯源必须到 ODS 层等）一起作为 Prompt 注入模型。
• 规范化输出： 模型解析多层嵌套的子查询，严格按照契约输出标准化的口径溯源文档与 Mermaid 架构图（如 引力onedata_表血缘_mermaid.md），以及符合分层规范的 DDL 语句。

实测效能： 在某业务线包含 34 张表、涉及 6 个粒度的 OneData 重构项目中，对比历史同等规模项目的纯人工评估耗时（约 60 人日），采用 AI 辅助与人工复核结合的模式，整体交付周期缩短至 16 人日（提效约 74%）。由于机器执行规范的绝对一致性，文档的格式统一度达到 100%。

智能周报生成：SQL 结果集到业务洞察的转化

业务背景： 传统 BI 报表只能展示数据，无法解释数据。业务方需要的是“为什么跌了”，而不是“跌了多少”。但如果直接让 LLM 读取原始 CSV 数据生成周报，极易出现“幻觉”（如 1+1=3 的计算错误），因为 LLM 本质上是概率模型，不擅长精确的数学运算。

规范化 I/O 逻辑： 系统设计上存在两条并行路径，而其底层逻辑的起点是同一份 Prompt 规范文档。

该规范文档充当单一可信源（Single Source of Truth）：在研发阶段，LLM 读取规范文档中精确定义的字段口径、聚合顺序与格式规则，将其编译为 Python 确定性计算模块（Spec-to-Code）；在运行时，同一份规范又作为约束契约传入 LLM，驱动语义叙事输出。这意味着规范的变更（如修改 WoW 计算口径）只需更新一处，两条路径同步收敛。

路径一（Python 计算层）： 由 LLM 依据规范编译生成的 Python 模块负责所有确定性运算——WoW/YoY 计算、渠道贡献度排序、量级格式化（万/亿分档）——输出已预渲染的 Markdown 文本片段，不再含任何原始数值。

路径二（LLM 叙事层）： 模型接收的是无需再做任何数学运算的结构化文本，其唯一任务是完成跨模块的趋势判断与业务归因叙述（如"供给下降叠加搜索量上升 → 供需错配"）。

核心价值： 这一架构的核心价值在于：将 LLM 的不确定性严格限制在语义层，将数值精度的责任锁定在代码层，两者各自处于自身最可控的能力边界内，从根本上规避了"让模型直接计算 CSV 原始数据"所带来的计算幻觉与格式漂移风险。

策略孵化中心：从单点提效到端到端业务策略流

业务背景： 区别于纯粹的 Coding 提效，业务冷启动阶段（如违规作者探查）涉及完整的策略工作流：定义目标 -> 数据收集 -> 特征筛选 -> 模型训练 -> 效果回收。该过程涉及业务方、分析师、数据科学家等多个角色，存在巨大的信息损耗与特征选择的“效率孤岛”。特征选择的质量高度依赖于个人的隐性能力。

规范化 I/O 逻辑：

策略孵化中心将这一复杂的非线性探索过程，重构为基于 AI Agent 的标准化流水线，包含四大核心模块：

• 策略工作流模块（输入端）： 业务人员输入自然语言描述的业务目标（如“异常作者识别”）。
• 样本分析与特征泛化模块： Agent 自动调用 MCP 接口检索资产，推荐相关特征（探索已有的未知），并利用 LLM 的常识推理补充行业通用特征（探索未有的未知）。输出标准化的样本拼接表。
• 模型训练模块： Agent 根据特征类型，自动推荐并调用底层机器学习组件（如逻辑回归 LR、随机森林 RF），标准化输入输出矩阵。
• 可视化分析模块（输出端）： 最终生成包含特征重要性可视化、沙盘推演结果的标准化策略报告。

项目演进里程碑：

• 第一期（MVP 验证）： 完成样本分析模块与模型工厂的基础功能，支持逻辑回归和随机森林，并在“违规作者探查”项目中取得显著的业务增量收益。
• 第二期（Agent 交互）： 开发特征交互式 Agent 的核心对话与 PRD 生成能力，完善特征管理。
• 第三期（高级分析）： 深化可视化模块，完成保序性、显著性等高级统计学分析功能。

实测效能： 策略生成到落地的整体周期由 10 人日缩短至 1-2 人日，提效 3-5 倍。AI 的介入不仅加快了策略迭代的频率（策略新鲜度），更通过标准化流程降低了对个人隐性经验的依赖，使得策略的专业度与准确率显著提升。

智能测试与质量保障：不确定性输出的校验机制

业务背景： 财务级数据指标（如实收、补贴、平台服务费等）具有严格的勾稽关系。针对此类指标编写覆盖全面的边界测试用例耗时极长，且业务语言（如“邮费返利抵减技术服务费”）转化为测试 SQL 极其困难。

规范化 I/O 逻辑：

• 规范驱动开发（SDD）： 将测试环节前置，定义标准化的测试契约（Schema）。
• 规范化输入： 将 DDL、业务口径文档及上游数据分布特征作为上下文输入给模型。
• 智能用例生成： LLM 自动生成覆盖主键唯一性、非空校验、枚举值分布、业务逻辑边界。
• 闭环诊断： 执行测试 SQL 后，若出现报错或精度异常，LLM 通过 MCP 接口自动读取执行日志进行根因诊断，精准区分“底层逻辑错误”与“浮点数计算带来的可接受精度误差”，并输出修复建议。

实测效能： 构建了“质量守夜人”机制，测试覆盖率大幅提升。在某财务项目中，模型自动生成了 20 余个复杂的校验 SQL，将数据质量卡点前置到开发阶段，显著降低了上线后的数据事故率，实现了从“人工抽测”到“机器全量自动化校验”的范式跃迁。

Spark UI Skill：数仓任务排查与智能调优

业务背景： 数仓日常运维中，Spark 任务的排查与调优（如数据倾斜、OOM、执行计划不合理）高度依赖工程师的个人经验。排查过程需要频繁查看 Spark UI，分析 DAG 图、Stage 耗时、Shuffle 数据量等，耗时且门槛高。

规范化 I/O 逻辑：

• 规范化输入： 通过 MCP 接口或监控脚本，自动抓取 Spark UI 的核心指标（如 Stage 耗时、Task 倾斜度、GC 时间、内存使用率）及 SQL 执行计划（Explain 树），将其转化为结构化的 JSON 或文本日志作为 Prompt 注入。
• 智能诊断推演： LLM 充当“认知运行时”，基于输入的结构化日志，结合历史调优专家经验库（如“Shuffle 阶段数据量剧增且单 Task 耗时极长 → 数据倾斜”），进行逻辑推演。
• 规范化输出： 强制模型输出标准化的诊断报告，包含：① 根因定位（如 Join 键倾斜）；② 具体调优建议（如增加 spark.sql.shuffle.partitions，或改写 SQL 引入 Broadcast Join）；③ 优化后的 SQL 代码草案或参数配置。

实测效能： 将单次复杂任务排查时间从数小时缩减至分钟级。不仅大幅提升了运维效率，更将资深专家的调优经验固化为标准化的 Agent 技能（Skill），显著降低了团队的整体技术门槛。

四、提示词工程的系统架构化设计

在上述所有工程实践中，提示词（Prompt）不再是简单的自然语言对话，而是演变为了系统架构的一部分。高质量的提示词工程是实现规范化 I/O 的核心载体。

提示词作为系统配置的演进

在传统的开发模式中，系统配置通常是 YAML、JSON 或 XML 文件，用于指定数据库连接、调度频率等确定性参数。而在 AI Native 的数仓架构中，提示词承载了业务规则、编码规范与逻辑约束，成为了认知运行时的“配置文件”。这些提示词被纳入版本控制系统（如 Git），与底层代码同等对待，接受严格的 Code Review。

结构化提示词的模块化拆解

以智能周报生成场景为例，其核心的 周报数据prompt 采用了高度结构化的模块设计：

# 角色设定 (Role Definition)
你是一位资深的电商数据分析师，擅长从复杂的数据指标中提取业务洞察。
# 核心任务 (Core Task)
请基于提供的 [SQL 结果集 JSON]，撰写本周的业务周报。
# 规范约束 (Constraints)
1. 必须使用 Markdown 格式，包含二级标题与无序列表。
2. 严禁捏造数据，所有数值必须来源于输入的数据集。
3. 环比计算公式为：(本期值 - 上期值) / 上期值，保留两位小数。
# 结构模板 (Output Template)
## 一、 核心指标概览
- GMV：[数值] (环比 [百分比])
- 转化率：[数值] (环比 [百分比])
## 二、 异动归因分析
[基于数据波动的具体分析]

这种模块化的提示词设计，将角色设定、任务描述、约束条件与输出模板严格分离，最大程度地降低了模型的幻觉概率，确保了输出结果的工程级可用性。

五、风险管控与治理机制

在电商数仓中引入 Code LLM，必须建立系统性的风险管控体系，以应对大模型固有的技术缺陷及企业合规要求。

幻觉风险的系统性抑制

大模型在处理复杂表关联时，可能捏造不存在的字段或错误理解业务逻辑。管控方案包括：

• 上下文增强 (RAG) 与 MCP 强绑定： 严禁模型在无上下文的情况下“裸写” SQL。必须通过 Galaxy MCP 实时获取真实的表结构与分区信息，确保模型引用的表名、字段名均真实存在。
• 强类型校验： 模型生成的 SQL 必须经过数仓平台的语法解析器（Parser）进行静态检查，阻断基础语法错误。

数据安全与合规保障

数据仓库包含大量商业机密与用户隐私，使用 LLM（特别是调用外部公有云 API 时）存在数据泄露风险。管控方案包括：

• 数据脱敏拦截： 在 Prompt 提交至模型前，必须经过网关层的正则表达式与 NLP 实体识别扫描，自动屏蔽或替换真实的手机号、身份证号及真实交易金额等敏感数据。
• 元数据隔离： 仅允许模型读取表结构（Schema）与脱敏后的样例数据（Mock Data），严禁模型直接访问生产环境的物理数据。
• 审计追溯： 所有由 AI 辅助生成的代码变更，在版本控制系统（如 Git）中必须带有特定的 AI 标签，并记录对应的 Prompt 与生成日志，确保事故发生时可进行完整的责任追溯。

六、结论

Code LLM 对电商数据仓库的介入，绝非停留在代码补全的表层提效，而是推动了数仓研发范式的底层演进。通过界定数据确权的管理边界，研发团队能够安全地将技术实现环节交由 AI 辅助；通过引入规范驱动开发（SDD）与 Agentic 工作流，并以“规范化的输入与输出”为核心，有效抑制了大模型的不确定性。

从 Galaxy MCP 的底层基础设施打通，到智能埋点、OneData 建模、周报自动化，再到端到端的策略孵化中心，大模型正在重塑数据流转的每一个节点。在这一演进过程中，数据工程师的核心职责正在发生转移：从繁重的 SQL 编码与基础排错，转向业务逻辑的抽象、规范契约的制定以及系统架构的最终决策。未来，基于 LLM 的认知运行时将与大数据执行运行时更加深度地融合，持续推动数据仓库向智能化、自动化的方向演进。

往期回顾

1.Claude Code + OpenSpec 正在加速 AICoding 落地：从模型博弈到工程化的范式转移｜得物技术

2.大禹平台：流批一体离线Dump平台的设计与应用｜得物技术

3.基于 Cursor Agent 的流水线 AI CR 实践｜得物技术

4.从IDE到Terminal：适合后端宝宝体质的Claude Code工作流｜得物技术

5.AI编程能力边界探索：基于 Claude Code 的 Spec Coding 项目实战｜得物技术

文 /博温

关注得物技术，每周更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。