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