让 LLM 参与数据分析前，先补齐这三道护栏

可信的数据上下文#

模型看到的上下文应来自受维护的语义层，而不是临时拼接的表名清单。每个可用指标至少说明定义、时间字段、所属数据源、更新频率和常见过滤条件；维度的枚举值、主键关系与脱敏规则也要能被检索。这样，“收入”才能被解析成约定的已支付金额，而不会把退款前的订单金额当作同一件事。

上下文还应有版本和责任人。指标定义改动后，应同步更新可供模型读取的说明，并保留变更记录。模型可以引用这些定义，却不应自行发明口径；遇到名称相近、字段含义不明或数据新鲜度不足时，应要求澄清，或把不确定性写在回答里。

模型提议，执行权限归系统#

LLM 的职责是提出候选 SQL 和解释计划，不是获得数据库账号。服务端应解析候选语句，只允许受控数据集、已批准的表列和只读语法；禁止多语句、写入、导出、权限变更和绕过租户条件。执行器用独立的只读身份运行，并在网络、超时、扫描量和返回行数上设置上限。用户身份和数据域授权仍由系统验证，不能让提示词代替权限判断。

一个紧凑的流程可以写成：

1
用户问题 -> LLM 候选 SQL -> 解析 / 表列白名单 -> 用户与数据域授权策略门
2
-> 只读且限行、强制执行授权的执行器
3
-> 指标校验 -> LLM 解释

其中，解析阶段应把 SQL 变成结构化语法树，再检查表、列、函数和条件，不能只靠关键词拦截。白名单只界定可查询的结构；执行器必须在每次请求中按用户身份和数据域授权策略强制判定，不能由 LLM 或白名单代替。执行前还可自动补上时间范围、租户过滤和 LIMIT。审计日志应记录问题、经过审批的查询、执行身份、耗时和结果摘要，便于定位错误，但日志本身也要避免保存不必要的敏感明细。

结果必须可校验#

自然语言回答不能遮住查询条件。每次输出至少以符合访问策略的脱敏形式暴露时间范围、数据来源、返回行数和实际过滤条件；若用到了聚合，也要说明指标口径。这样读者可以判断“下降”是按自然周、滚动七天还是某个业务周期计算，也能知道结果来自正式宽表还是尚未完成刷新的明细表。

数值必须来自已执行的查询结果，模型不能补全缺失的小数、增长率或排名。对关键指标，系统可比较历史区间、总分项是否相加一致、空值比例和异常阈值；必要时再跑一条独立的对照查询。空结果、明显异常或执行超时都不是“没有变化”的证据，回答应明确说明无法得出结论，并给出可复查的状态，而不是把失败包装成业务解释。

同样要区分事实与推测。查询能说明某时间段、某筛选条件下的数值变化；“促销结束导致下降”属于待验证的假设，需要结合活动、价格、渠道或实验数据进一步检验。LLM 可以整理假设和下一步检查，但不应把相关性写成因果结论。

更稳妥的落地方式，是先选少量口径稳定、敏感度可控且已有人工分析流程的指标，限定在只读问答和结果复核场景中试运行。等到数据目录、授权审计和校验规则经得起日常使用，再逐步扩展范围；不应一开始就把所有数据资产交给一个会生成 SQL 的对话框。