问题：覆盖真实经营问题
口径：指标和范围说清
证据：结果可以复核
治理：成员和数据可控
行动：洞察进入工作流
先给结论：从“答案像不像”改成“决策能否复核”
企业评估 AI 数据分析，最容易陷入一次性演示：准备几道漂亮的问题，看回答是否流畅。但真实使用会遇到别名、跨表关系、时间口径、权限和追问。更稳妥的验收单位是一条完整链路：提出问题、确认口径、查看结果、追问原因、复核依据，再决定是否采取行动。
建议把验收问题分成高频固定问题、需要多轮澄清的问题、必须限制数据范围的问题。三类问题都通过，才说明系统有进入日常工作的基础。
第一层：问题覆盖与口径确认
为每个场景写出问题、期望指标、时间范围、维度和异常处理。例如“华东销售下降了吗”并不完整，需要明确销售额还是订单数、比较上月还是去年同期、是否排除退款。一个可用的系统应能识别缺口并追问，而不是悄悄选择默认口径。
验收时记录每次追问及最终口径，检查同一问题换一种说法是否仍然指向同一指标。若业务术语只能靠个人记忆解释，先补充术语表、指标定义或语义配置，再继续测试。
第二层：证据、权限与可追溯性
结果页需要让使用者知道数据来自哪个范围、统计到哪个时间、采用了什么维度。不能把相关性描述成因果性，也不能把预测当成事实。对于异常或归因问题，应保留原始明细、筛选条件和进一步核验入口。
企业场景还要做“同问不同权”测试：同一问题由不同项目成员提出，确认其只能看到被授权的数据。AskTable.ai 已确认支持组织成员、角色、项目权限、数据范围及用量管理；具体连接器清单与私有化范围仍应在 POC 中逐项确认。
第三层：从洞察到行动的验收清单
最后测试结果能否变成业务动作：生成周期报告、设置预警、通知负责人，或把问题留给团队继续追问。验收记录应包含问题文本、数据时间、结果截图、复核人和后续动作，而不是只保存一次演示视频。
用一周的真实问题做试运行，统计无效回答、需要人工改口径的次数、复核耗时和行动完成情况。这样得到的是流程证据，而不是对模型“聪明程度”的主观评价。