AI 数据分析最危险的情况，通常不是加总失败，而是用错分母、时间窗或 JOIN 后仍产生一个「很像答案」的数字。若取数逻辑只藏在聊天过程里，团队甚至无法指出错误发生在哪一步。
正确运算，也可能回答错问题
考虑一句常见需求：「比较 6 月和 5 月的付款转化率。」它至少有五个未决条件：
- 分母： 造访者、注册者、建立订单者，还是进入付款页的人？
- 时间窗： 依事件发生月，还是依 cohort 的注册月？
- 粒度： 一人一笔、一个 session 一笔，还是一个订单一笔？
- JOIN： 订单接明细后，一笔订单是否被商品数放大？
- 新鲜度： 6 月资料是否已结算，退款与取消是否已回补？
假设 SQL 把 10,000 笔订单 JOIN 到 28,000 笔明细，再直接 COUNT(*)，资料库会精确地回传 28,000；错的不是算术，而是分析者把「明细列」当成「订单」。如果模型接着写出流畅解读，错误反而更不易察觉。
企业 Text-to-SQL 的原始研究也提醒我们，真实任务远超过「看 schema 后组 SQL」。Spider 2.0 的 632 个企业工作流程题目常需查找 metadata、方言文件与专案程式；论文最新修订版摘要中的 o1-preview code agent baseline 解出 21.3%，这个成绩只代表该资料集与设定，不能直接当作所有 AI 工具的准确率。Spider 2.0 论文
2026 年提出的 EntSQL 更聚焦内部指标、报表惯例与组织规则：多数题目需要超出问题与 schema 的领域知识。这支持一个务实结论：模型不只要会 SQL，还要取得正确的业务 context，而且这些 context 必须可被查核。EntSQL 原始论文
四层防线：让错误在决策前现形
1. Plan：先把「怎么算」写成人话
Plan 至少写明决策问题、分母、粒度、时间范围、join key、排除条件与资料截止时间。这不是形式文件，而是让 PM、财务或营运在不读 SQL 的情况下，先阻止错误口径进入正式执行。
2. SQL：保留可审阅的取数证据
SQL 应让审阅者看见 FROM、JOIN、WHERE、GROUP BY 和时间边界。自然语言适合解释意图；SQL 适合回答「到底哪些列被算进来」。即使 SQL 是 AI 起草，也不应只存在模型的隐藏执行环境。
3. Checkpoint：刻意找反证
在正式结论前加入最小验证：
SELECT
COUNT(*) AS rows_after_join,
COUNT(DISTINCT order_id) AS distinct_orders
FROM joined_orders;
再核对分子与分母、NULL 比例、最大／最小日期，以及抽样五笔原始纪录。Checkpoint 的目的不是证明模型一定对，而是让 fan-out、漏资料或资料尚未结算有机会被看见。
4. Limitations：把不知道的事也交付
Report 应说明资料截止日、未涵盖栏位、代理指标、样本偏差与不能推论的因果。美国 NIST 的生成式 AI 风险框架将错误或虚构内容列为需要管理的风险，治理行动包含测量、监控与文件化，而不是只要求模型「更小心」。NIST AI 600-1：生成式 AI 风险管理框架
Lantide Data 如何让过程可查
在 Lantide Data 的 Project Analysis 里，Agent 先探索资料并草拟 Plan；使用者可在文件上批注分母、时间范围与 checkpoint，满意后才按 Execute。执行时的 SQL 分页、查询步骤与 Report 共同保留分析证据；产品的 SQL-first 分工可见分析师实务指南，状态与工具边界可见Agent 架构说明。
这些机制降低的是「错误无法被发现」的风险，不是把 AI 变成永不犯错的分析师。业务定义、资料品质与最终决策仍由人负责；若来源资料本身缺漏，Plan 和 SQL 只能把限制揭露出来，不能凭空补齐真相。
结语
不要只问「AI 算得准不准」，更该问：「我能不能重建它的分母、资料范围与每一步取数？」下次把 CSV 或 Excel 交给 AI 前，先要求一份 Plan、一段可见 SQL、一组反证 checkpoint，以及 Report limitations。答案慢一点，但更有资格进入决策。