Resource Guide
AI问数问题集、权限与答案证据验收矩阵
摘要：这份矩阵用于AI问数试点、联调和上线验收。它把真实业务问题、提问角色、允许数据范围、指标口径、预期答案、查询证据、澄清与拒答条件、重复测试和人工复核放在同一张表里，帮助团队判断系统是否在正确权限下给出可复核的答案。
什么时候开始使用
建议在产品选型或概念验证前先建立第一版问题集，并在数据模型、权限和提示语调整后持续回归。不要等到上线前才临时问几道简单问题，也不要只用管理员账号和演示数据测试。
问题集要来自真实工作，而不是功能演示
业务负责人应提供高频问法、模糊问法和实际决策所需的对比维度；数据负责人补充指标定义、公式、来源和可人工复算的标准结果；系统与安全负责人补充越权、敏感信息、写操作和无依据推断等反向测试。模板中的示例仅用于说明字段，不是任何企业的真实数据或默认业务规则。
六类问题应同时覆盖
| 问题类型 | 测试目的 | 可核对结果 |
|---|---|---|
| 标准指标问题 | 验证时间、公式、维度和来源是否正确。 | 与已确认报表或人工复算结果一致。 |
| 模糊问题 | 验证系统是否先澄清缺失的指标、范围或基准。 | 不猜测用户意图，不直接生成伪精确结果。 |
| 越权问题 | 验证页面、语义层、查询与接口是否使用同一权限。 | 拒绝访问且不泄露目标数据是否存在。 |
| 高风险动作 | 区分只读分析与审批、付款、修改、删除等业务动作。 | 不调用写接口，给出正确办理入口并留痕。 |
| 证据不足问题 | 验证系统是否承认数据或模型不足。 | 披露缺口，不把推测包装成事实。 |
| 多轮问题 | 验证上下文继承、修改和清空是否一致。 | 继承范围可见，结果与同条件独立查询一致。 |
答案至少要带回哪些证据
建议展示统计周期、指标定义或公式、筛选条件、分析维度、数据更新时间和来源；条件允许时提供生成SQL、查询计划、语义映射或可追踪的日志编号。证据不是为了让每位用户阅读技术细节，而是让业务、数据和技术人员在出现争议时能沿同一路径复核。
权限验收必须做反向测试
除了确认有权角色可以得到答案，还要验证低权限角色、跨组织参数、失效账号、旧会话、导出与下钻是否会绕过限制。敏感字段应先确定脱敏、聚合或完全不返回的规则。只在界面隐藏按钮，不等于查询和接口已经受到保护。
建议执行顺序
- 由业务、数据、系统和安全责任人共同选定首期问题集。
- 为每道问题确认角色、数据范围、指标口径和数据版本。
- 写明标准结果、核对方法、应返回证据和响应时间目标。
- 补充需澄清、必须拒答、脱敏与只读动作边界。
- 在同一数据版本下重复测试，并保留日志和截图。
- 模型、语义、权限或数据结构变化后执行回归测试。
参考产品能力时要区分“可见”与“正确”
SQLBot智能问数说明展示了自然语言提问、图表、生成SQL和多轮对话等交互；其最佳实践强调业务背景、表字段、关联关系、示例SQL和自定义术语对准确性的影响。也可结合FineBI官方能力说明与DataEase版本记录核对当期产品边界。生成SQL可见有助于复核，但不能替代权限、口径和数据版本检查。
常见问题
AI问数验收只核对答案数字可以吗？
不建议。还应核对角色权限、时间与指标口径、数据来源、查询证据、澄清拒答、重复测试和日志，避免结果碰巧正确但过程不可复核。
问题集应该由技术人员单独编写吗？
不应只由技术人员编写。业务人员提供真实问法与标准结果，数据人员确认口径和来源，安全与系统负责人确认权限和动作边界。
生成SQL可见是否代表答案一定正确？
不代表。SQL可见有助于复核，但仍要检查表关系、过滤条件、指标语义、权限和数据版本。
这份矩阵能直接证明系统合规吗？
不能。它用于项目测试和证据整理，不替代法律、行业监管、等级保护或专业安全评估。
下载与相关资料
建议同时使用BI驾驶舱指标梳理模板和数据大屏角色权限与审计验收矩阵。继续阅读AI+BI智能问数实施与验收方法及FineBI、DataEase与定制BI大屏选型指南。