一、引言：财务数仓为什么需要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 应用场景：
- 测试用例自动生成：向 AI 提出测试要求后，AI 能够自动生成完整的测试 SQL 和说明文档，包括：
- 正向-冲销=冲销之后的验证逻辑；
- 子项相加等于汇总项的验证逻辑；
- 业务规则转化的验证逻辑；
- 边界场景的验证逻辑。
-
规则理解层面的测试补充：AI 能够从规则理解层面补充测试案例，如抽样验证、精度验证等，减少因理解不一致带来的质量问题。特别是在复杂的跨周期分摊场景中，AI 能够识别出人工容易忽略的测试点。
-
复杂逻辑的逐步分析：针对复杂的业务逻辑，AI 能够逐步分析不符合预期的环节，帮助找到潜在的代码 Bug。例如在邮费冲销逻辑中，AI 能够分析退小仓场景下的多种分支情况，识别出逻辑漏洞。
-
上下游影响分析：AI 能够分析一个字段的改动对上下游的影响，帮助识别需要同步验证的相关字段，避免遗漏。
-
公式验证与精度问题诊断：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平台的设计与应用｜得物技术
文 /丹克
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。