能做的：取数与口径
把业务问题翻译成查询，前提是有指标字典与语义层。指标定义、维度与时间口径写清楚，模型才能稳定给出同一答案；没有语义层的自然语言查询，答得快也错得隐蔽，事后排查更费时间。语义层不牢，后面的问答都建在沙子上，返工代价更高。
能做的：探查与叙述
对趋势、分布与同比环比做自动扫描，标出突变点与离群值，再按模板写成例会可用的说明。它擅长指出哪里不对，不擅长直接说明为什么，措辞与结论仍要业务方确认后才能进汇报。叙述可以自动生成，判断与措辞仍要人来定。
不能做的：因果结论
相关性不等于因果。模型给出的归因只是假设，需要实验、对照或业务验证才能成立。把假设当结论写进汇报，是这类项目最常见的事故来源，一旦被追问就难以自圆其说。把它当假设管理，才能避免汇报被一句话问倒。
不能做的：替代签认
财务、审计与对外披露的数字有明确责任主体，AI 可以核对与提示，但不能替代签认，也不为数字的合规性背书。涉及税务与投资者披露时，应由客户方授权人员复核后发布。签认这件事没有替代品，工具只能提供核对痕迹。
适用与不适用
适合谁
- 已有数仓或统一报表体系，口径可追溯的企业
- 指标口径基本稳定、有分析团队的部门
- 希望缩短周月报制作时间的经营管理部门
不适合谁
- 数据分散在个人表格、没有统一口径的企业
- 希望 AI 直接给出经营决策结论的团队
典型场景
某零售企业的经营例会材料过去由分析团队手工拼。接入语义层后，模型按模板生成各区域同比环比与异动说明，分析师核对关键数字并补上业务解释，财务确认对外口径后才进入会议材料，异常项由区域负责人回应。
可执行步骤
- 先建指标字典与语义层，把口径、维度与时间定义逐项写清
- 选一个业务域接入只读副本，不要直连生产库影响业务系统
- 用一组已知答案的问题测试取数与计算，逐条对账，逐条记录差异原因。
- 把叙述生成限定在模板与已核对的数字范围内，不自由发挥
- 对外披露的数字仍由财务或审计签认后才可发布，签认后再对外报送。
常见坑
- 没有语义层就做问答：同名指标多个定义，模型给出看似合理的错数，排查成本极高，业务方也会慢慢不信。
- 把归因当结论：汇报里写因为促销导致增长，经不起追问，反而削弱数据团队信誉，后续建议也难以推动。
- 权限管理粗放：模型把不该看的明细带进回答，触发合规问题，事后追责找不到环节，审计时说不清授权。
自检与验收清单
- 指标字典与口径是否成文，并指定了维护人
- 数据权限是否按行按列控制，查询与导出是否留痕
- 是否有一组已知答案的测试问题集用于回归
- 归因结论是否明确标注为假设，并附验证方式
- 对外披露数字是否有明确的签认流程与责任人
常见问题
能直接连生产数据库吗？
建议用只读副本或数仓，避免查询压力影响业务系统。确需直连时应限流、限时段，并记录查询日志，便于审计与排障，出问题时也能快速定位到具体查询，出事也能快速定位。
准确率怎么保证？
靠语义层、测试问题集与人工复核三层。先用已知答案的问题回归，再对高影响数字双人核对，不追求一次性全对，而是把错误控制在可发现、可修正的范围内。
数据会不会泄露？
取决于部署与权限设计。敏感数据可不出域部署，查询按最小权限授权，对话与结果留痕；涉及个人信息时按分类分级处理，并由数据安全负责人确认后再上线。