平台 · 数据分析

进去是日常语言，出来是受管的 SQL

Text-to-SQL 很好演示，却很难信任。差距全在查询周围：字段到底是什么意思、提问的人有权看哪些行、以及这个数字下个季度还能不能复现。

PostgreSQL · MySQL · 数仓
只读执行
SaaS 或自托管

查询方案只读

本季度毛利损失最大的三条线路

select lane, sum(margin_delta) as loss
from fct_margin_daily
where quarter = '2026Q3'
  and region in (/* 你的数据角色 */)
group by lane order by loss limit 3

高亮的这一行由平台追加，不是模型写的。行级规则跟着提问的人走。

lane	loss	share
CTU-RTM	-2.1 pts	62%
SHA-LAX	-0.8 pts	24%
SZX-HAM	-0.5 pts	14%

那句不是你写的条件

治理是被追加的，不是被提示的

让模型自觉遵守权限，不叫控制。在 DataFact 里，限定范围的条件是在查询生成之后由平台追加的，依据是提问者的数据角色。

这就是「能演示的 demo」和「能推给四百个人、每人看到不同切片的系统」之间的差别。

能力

是什么让一个答案站得住

快只是入场券。真正决定这个数字能不能扛住数字主人质问的，是下面这些。

语义

模型读的是你的定义，不是你的字段名

一个叫 amt_net_3 的字段对谁都没有意义。表和字段的说明、指标定义，以及你的分析师平时手工套用的规则，都存在一个分析模型里，每个问题都对着它来解析。

表、字段、指标的说明集中维护在一处
业务规则以规则的形式记录，可以逐条评审
问题有歧义时会反问澄清，而不是猜

查询

只读、有边界，并且给你看

生成的 SQL 就摆在结果旁边。执行是只读的，带单次请求超时和取消，所以一个昂贵的问题不会一直压在你的数仓上。

查询语句和答案一起展示，供复核
只读执行，带请求超时和取消
结果集有上限，而且上限是明说的，不是悄悄截断

权限

行级规则跟着提问的人走

访问控制不是提示词里的一句话。绑定在数据角色上的表级和行级规则，在查询执行时由服务端施加，所以同一个问题，区域经理和集团管控看到的是各自正确、但不同的范围。

表级和行级规则挂在数据角色上
在执行时施加，而不是拿去问模型
业务身份模板把角色映射到一套可见性配置

版本

上个季度那个数字是可复现的

分析模型每次构建都会冻结一个快照。如果某个指标定义在三月改过，你能看到它当时是什么、对比两版、并回滚——而不是争论哪份报表才是对的。

每次构建一个版本快照，并与上一版给出差异
在原始定义下复现一个历史答案
回滚一个漂移了的定义

不止一个数字

横跨两条通道的问题

最有价值的问题，光靠数仓答不了。DataFact 能把报告里的一个数字和表里的一行，放进同一个推理步骤。

财务
毛利变了——把数仓里的趋势和季度回顾 PDF 给出的归因对上。
供应链
按线路看供应商表现，并对照签署合同里写明的罚则条款核查。
合规
哪些交易落在当前政策文件规定的阈值之外——是当前的，不是去年那版。

来自不光鲜那一半的记录

全部文章

从这里开始

先对准一个 schema 团队真正关心的问题。

给我们一个 schema，和你的分析师每周都会被问到的那些问题。我们会给你看它生成的查询，以及行级规则落在了哪里。

试用 Demo 看它怎么运作

您的数据与每个答案保持联系。