财务数仓 Claude AI Coding 应用实战

一、引言财务数仓为什么需要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 设计、上下文组织方式、测试用例模板等经验在团队内分享形成可复用知识库从「人做」为主转向「人定规则与口径、模型执行环节」的协作模式让大模型成为数仓同学的日常助手。未来已来。