有些需求表面看是“帮业务出一张报表”实际做起来像考古。上个月我接到一个经营分析报表改版需求业务方给了一个 Excel 样例里面有 12 个指标、4 个筛选条件、3 个统计维度还有几行备注“剔除异常订单”“按实际归属部门统计”“退款订单另算”。这些话单独看都能理解放到数据开发里就很危险到底剔除哪些异常归属部门取订单创建时还是当前组织架构退款另算是从 GMV 里扣掉还是单独展示我没有一开始就让 AI 写 SQL而是先用它做需求拆解和口径校验。为了方便同一个任务在不同模型里复跑我当时把 ChatGPT、Claude、Gemini、DeepSeek、Grok 的输出放在同一个多模型聚合环境里看对比文档理解、代码分析、内容生成和任务拆解的差异。这篇文章记录的不是“哪个模型最强”而是一个更实际的问题国内开发者、数据分析师或 BI 同学如何低门槛使用 AI把一份含糊的报表需求拆成可评审的指标口径、字段映射、SQL 验证清单和测试用例。我的经验是AI 可以大幅减少整理时间但不能替你确认业务事实。一开始我犯的错直接让 AI 生成 SQL第一次我把 Excel 说明和几张表结构贴进去问请根据下面的报表需求生成 SQL。模型很快给了一段看起来不错的 SQLSELECTdept_name,COUNT(DISTINCTorder_id)ASorder_count,SUM(pay_amount)ASgmvFROMdwd_orderWHEREorder_statusPAIDANDis_abnormal0GROUPBYdept_name;问题是这段 SQL 其实没解决核心口径dept_name来自订单表、用户表还是组织快照表is_abnormal 0是否覆盖所有异常订单退款订单是否要从pay_amount中扣减跨月退款算在哪个月取消订单、部分退款、售后中订单怎么处理指标是按支付时间、下单时间还是完结时间统计这类 SQL 最大的问题不是语法错而是“看起来能跑但业务口径错”。所以后面我改变了用法先让 AI 拆需求不让它写 SQL。核心模块一把 Excel 报表拆成指标口径表第一轮输入只包含脱敏后的 Excel 文本、字段备注、业务方补充说明。我会先要求模型做结构化整理。Prompt 示例你是数据需求分析助手请阅读下面的报表需求说明。 要求 1. 不要写 SQL 2. 不要补充原文没有的业务规则 3. 把指标、维度、筛选条件、时间口径、异常规则分别整理 4. 对不确定内容标记“待确认” 5. 输出适合研发、数据分析、业务方一起评审的表格。 输出字段 指标名称 | 业务含义 | 统计口径 | 维度 | 筛选条件 | 时间口径 | 待确认问题模型整理后大概会得到这样的表指标名称业务含义统计口径维度筛选条件时间口径待确认问题支付订单数完成支付的订单数量去重订单数部门、渠道、日期剔除异常订单支付时间异常订单定义不完整GMV支付金额汇总支付金额求和部门、渠道、日期剔除异常订单支付时间退款是否扣减退款金额已发生退款金额退款单金额求和部门、渠道、日期退款成功退款时间或支付时间跨月退款归属待确认净收入GMV 扣减退款GMV - 退款金额部门、渠道、日期剔除异常订单待定是否扣除手续费这一步的价值很高。因为它把“大家以为自己懂了”的需求变成了可以逐条确认的问题。业务方看到表格后通常会更容易意识到原来“退款另算”不是一句备注就能解决。核心模块二字段映射不要靠猜先生成候选清单指标口径初步明确后下一步是字段映射。这里也不能让 AI 自由发挥否则它很容易编出不存在的字段。我会给它一份脱敏后的数据字典例如表dwd_order 字段 - order_id订单 ID - user_id用户 ID - pay_amount支付金额 - order_status订单状态 - pay_time支付时间 - create_time下单时间 - channel_code渠道编码 表dwd_refund 字段 - refund_id退款单 ID - order_id订单 ID - refund_amount退款金额 - refund_status退款状态 - refund_time退款完成时间 表dim_org_snapshot 字段 - user_id用户 ID - dept_id部门 ID - dept_name部门名称 - snapshot_date快照日期然后让模型输出字段映射候选而不是直接定稿请根据指标口径表和数据字典生成字段映射候选清单。 要求 1. 只能使用数据字典中出现的表和字段 2. 如果字段来源不唯一请列出候选方案 3. 不要编造字段 4. 标记需要业务或数据负责人确认的地方 5. 输出表格。示例结果指标/维度候选表候选字段使用方式风险支付订单数dwd_orderorder_idCOUNT DISTINCT需确认订单状态过滤条件GMVdwd_orderpay_amountSUM需确认是否扣退款退款金额dwd_refundrefund_amountSUM需确认退款成功状态值部门dim_org_snapshotdept_name按用户关联组织快照需确认快照日期取支付日还是当前日渠道dwd_orderchannel_codeGROUP BY需补充渠道字典这里有一个很实用的技巧让模型写“风险”列。没有这一列时输出很容易像最终方案加上风险列后它更像评审材料。核心模块三让 AI 生成 SQL 验证清单而不是只生成一条 SQL字段映射确认后才适合让 AI 辅助写 SQL。但我仍然不建议只要一条最终查询。更好的方式是让它生成主查询 SQL中间结果校验 SQL异常数据抽样 SQL口径边界验证 SQL。Prompt 示例请基于已确认的指标口径和字段映射生成 SQL 验证清单。 要求 1. SQL 使用通用 MySQL 风格 2. 不要使用未提供的数据表和字段 3. 每段 SQL 前说明验证目的 4. 输出主查询、分项校验、异常样本检查 5. 对性能风险给出提醒 6. SQL 仅作为草稿需要人工执行和校验。比如 GMV 和退款口径可以拆成几段验证-- 校验 1支付订单基础范围SELECTCOUNT(DISTINCTorder_id)ASpaid_order_cnt,SUM(pay_amount)AStotal_pay_amountFROMdwd_orderWHEREorder_statusPAIDANDpay_time2026-01-01ANDpay_time2026-02-01;-- 校验 2退款成功金额SELECTCOUNT(DISTINCTrefund_id)ASrefund_cnt,SUM(refund_amount)AStotal_refund_amountFROMdwd_refundWHERErefund_statusSUCCESSANDrefund_time2026-01-01ANDrefund_time2026-02-01;-- 校验 3存在退款但订单状态不一致的样本SELECTo.order_id,o.order_status,o.pay_amount,r.refund_amount,r.refund_statusFROMdwd_order oJOINdwd_refund rONo.order_idr.order_idWHEREr.refund_statusSUCCESSANDo.order_statusPAIDLIMIT100;这些 SQL 不一定能直接上线但它们能帮助团队快速确认数据有没有异常、口径是否能落表、哪些边界需要补规则。辅助模块一用多模型做“挑错”但不要搞成投票我会把整理后的口径表和字段映射再交给另一个模型让它只做审查。Prompt你是数据口径评审中的挑错者。 请检查下面的指标口径、字段映射和 SQL 验证清单。 重点检查 1. 指标定义是否含糊 2. 时间口径是否冲突 3. 维度归属是否可能变化 4. 是否存在重复计算 5. SQL 是否使用了未确认字段 6. 还需要业务方确认哪些问题。 不要重写方案只输出问题清单。这种交叉检查经常能发现一些人工忽略的小问题。比如订单按支付时间统计退款按退款时间统计净收入月报会出现错位部门维度如果按当前组织架构取会导致历史报表回刷变化退款金额如果按退款单统计部分退款和多次退款要避免重复扣减渠道编码缺少维表报表展示可能出现不可读编码。但模型之间意见不一致时不能按“谁说得多”来决定。最终还是要回到原始需求、数据字典和业务确认。辅助模块二把“待确认问题”转成评审清单以前开报表评审大家经常围绕 Excel 截图讨论效率很低。现在我会让 AI 把待确认点整理成会议清单。请把下面所有待确认问题整理成评审清单。 要求 1. 按业务口径、数据来源、时间口径、异常处理、权限合规分类 2. 每个问题给出影响范围 3. 标记必须在开发前确认的问题 4. 输出适合会议纪要使用的表格。输出示例分类问题影响范围优先级业务口径GMV 是否扣减退款影响核心指标开发前必须确认时间口径跨月退款归属哪个月份影响月报趋势开发前必须确认数据来源部门取支付日快照还是当前部门影响历史一致性开发前必须确认异常处理异常订单定义包含哪些状态影响订单数和金额开发前必须确认权限合规部门负责人能否查看明细订单影响报表权限上线前确认这张表比一堆聊天记录更适合作为评审输入也方便后续写需求变更记录。辅助模块三让 AI 生成测试用例但必须绑定口径报表类需求最容易漏测边界。AI 可以帮忙生成测试点但一定要要求它关联指标口径。Prompt请基于已确认的报表口径生成测试用例。 要求 1. 按指标准确性、维度聚合、时间边界、异常订单、退款场景、权限控制分类 2. 每条用例必须关联一个指标或口径 3. 不要生成泛泛的“页面展示正常” 4. 对依赖测试数据的用例说明造数要求。示例测试点分类测试点关联口径造数要求指标准确性支付订单数去重统计支付订单数同一订单多条明细退款场景部分退款后净收入计算正确净收入一笔订单多次部分退款时间边界月末支付、次月退款的归属正确时间口径跨月订单和退款维度聚合用户部门变更后历史报表不漂移部门维度组织快照数据异常订单异常订单不计入 GMV异常过滤多种异常状态权限控制部门用户只能看本部门数据权限规则多部门账号测试同学拿到这种用例会比拿到“请测试报表准确性”好很多。数据脱敏和安全边界报表需求经常涉及经营数据、客户数据、财务数据不能原样交给 AI。我的处理方式是表名改成抽象名例如dwd_order、dwd_refund字段保留业务含义但去掉真实客户和组织信息金额可以按比例缩放或改成区间订单号、用户 ID、手机号、邮箱全部替换删除内部 IP、库名、账号、连接串对供应商、渠道、客户名称做匿名化涉及合同、金融、医疗、政务材料时只做结构化辅助不让 AI 给最终判断。还有一点很重要AI 生成的 SQL 必须人工 Review。至少要检查是否误用字段是否多对多 join 导致金额放大是否缺少分区条件是否会扫全表是否使用了未确认口径是否影响线上库性能。如果是生产数据建议先在测试库、离线数仓或抽样数据上验证。我现在会沉淀的模板经过几次报表需求后我把流程固化成了一个模板1. 输入脱敏后的需求说明和样例表 2. AI 输出指标口径表 3. 人工补充业务解释 4. AI 输出字段映射候选 5. 数据负责人确认字段来源 6. AI 生成 SQL 验证清单 7. 开发执行并记录结果 8. AI 生成测试用例草稿 9. 测试补充边界数据 10. 业务方确认最终报表这个流程看起来比“直接写 SQL”慢但实际更省时间。因为报表最贵的成本不是写查询而是上线后发现口径错了再回头解释为什么数对不上。常见误区1. 把 AI 当成数据负责人AI 可以整理口径但不知道你们公司的真实业务规则。比如“有效订单”“异常订单”“归属部门”这些概念必须由业务和数据负责人确认。2. 只生成最终 SQL不生成验证 SQL报表开发需要证据链。主查询能跑不代表结果可信中间校验和异常样本检查更重要。3. 忽略时间口径很多报表问题都出在时间上支付时间、下单时间、退款时间、结算时间、快照时间混在一起趋势图很容易失真。4. 不做权限和合规检查经营报表往往包含敏感信息。能不能看明细、能不能导出、跨部门能不能查看都需要明确规则。结尾让 AI 先帮你把问题暴露出来如果你是数据开发、后端开发、BI 工程师或产品经理可以先拿一个低风险的历史报表需求试试这套流程。不要一上来就让 AI 写最终 SQL而是让它先做三件事拆指标口径、列字段映射、生成待确认问题。真正有价值的不是模型替你写了多少代码而是它把隐藏在 Excel、会议纪要和聊天记录里的不确定性提前暴露出来。只要保留脱敏、人工 Review、SQL 验证和业务确认这几道关AI 就能成为报表开发里的辅助分析员而不是新的风险来源。
