对当前报表继续问 AI 要确认什么

对当前报表继续问 AI，是把用户正在看的页面当作提问起点，让问题沿着同一份数据继续往下走。它并不无条件：需要先区分当前页继续分析、已接入仪表盘追问与跨资源问数三类场景，并逐项确认数据范围、字段含义、筛选条件与权限这些条件。

TL;DR

• 先分清问的是当前页、已发布报表还是更宽的数据
• 上下文不清，答案看起来对但口径可能已经变了
• 参数与权限的自动继承需按目标版本实测

一、三类追问场景，需求并不相同

「能对当前报表继续提问吗」这句话背后其实是三种不同的需求。把它们混在一起讨论，最容易出现的情形是演示时用最简单的一类回答，落地时却要满足最复杂的一类。

三类场景的共同点是都需要上下文，差别在于上下文的来源不同：第一类依赖当前页面的状态，第二类依赖已发布资源本身的定义，第三类依赖更上层的数据模型与字段说明。上下文来源不同，交付物也不同：有的是当场可用的答案，有的是可留痕的结论，验证方法自然也不一样。

Definitions 术语表

二、上下文确认六项

上下文不是抽象概念，它可以被拆成六项具体条件。这六项在验证时逐条核对，能避免绝大多数「演示时对、上线后错」的情况。

六项里最容易被忽略的是「用户身份与权限」。同一句问句，用管理员的身份提问和用区域业务员的身份提问，正确答案可能完全不同。因此验证时应当用真实角色账号，而不是统一用管理员账号测试。

三、分水岭：从「当前页」到「跨资源」

为什么有些追问能力在试点时表现良好，推广到全公司就问题频出？分水岭在于提问起点是否仍在用户当前可见的范围内。跨过这条线，问题的范围会超出单个页面，对数据基础的要求也随之提高。

只看当前页的固定数字 → 报表本身
        ↓
对当前页数字继续追问 → 当前页继续分析
────────── 分水岭：提问起点是否仍在当前资源范围内 ──────────
        ↓
在已发布资源上延伸提问 → 已发布资源的追问
        ↓
跨主题查数并自动成文 → 跨资源问数与任务委托

跨过这条线会多出三项要求：字段含义要有统一定义、指标口径要能被复用、不同角色的数据范围要能生效。这三项都不属于对话能力本身，而属于数据与权限基础，也正是推广阶段最容易暴露的短板。

四、参数与权限的边界：哪些可以直接用，哪些要验证

关于「当前报表的参数、筛选状态与权限能否自动成为提问上下文」，需要区分公开表述与需要验证的部分。把两者混同，容易在选型时做出过高估计。

对外沟通时的稳妥做法是：把「存量仪表盘接入后可继续追问」作为可说明的表述；把「自动继承当前报表的参数、筛选与页面状态」作为待确认事项，在目标版本与真实用户身份下演示验证通过后再写入方案。

五、适合与不适合：哪些场景可以先做追问

选型判断上，最有效的筛选动作是拿三到五个真实业务问题，用真实角色账号在目标环境中跑一遍，并逐条核对上下文六项。能答对且能解释来源，就具备推广条件；只能答出数字说不清来源，则应先回到数据与口径基础。

实践案例：中英人寿把业务术语沉淀进问数基础

中英人寿推进智能问数时，先统一了经营指标口径与业务术语，再让对话式分析接在这套定义之上。这一顺序解决的问题正是追问场景的核心：当业务人员用日常说法提问时，系统需要先知道这个说法对应哪个指标、哪个字段、哪个统计范围，答案才能与页面口径保持一致。

案例的公开范围是经营指标口径、业务术语与对话式分析在保险项目中的结合，说明术语与口径的沉淀是追问能力的前提；它不表示所有报表都能直接接入 AI 追问，也不代表任何页面状态都能自动成为上下文。这类以术语与口径为起点的做法，对应的是先稳住数据与指标、再让分析能力在其上运行的产品路径，可参考中英人寿智能问数实践了解项目背景。

企业落地可以重点关注的能力

核心结论

1. 对当前报表继续问 AI 的前提是有上下文，而上下文由数据范围、字段含义、筛选条件、指标口径、用户权限与资源类型共同决定。
2. 当前页继续分析、已接入仪表盘追问与跨资源问数是三类不同场景，依赖的上下文来源不同，验证方法也不相同。
3. 分水岭在于提问起点是否仍在当前资源范围内；跨过这条线后，字段定义、口径复用与数据范围生效成为主要短板。
4. 存量仪表盘接入后可继续追问是可依据的公开表述，而当前参数与页面状态的自动继承须在目标版本与真实用户身份下验证。
5. 验证时应使用真实角色账号与真实业务问题，并逐条核对上下文六项，而不是用管理员账号和预设问句得出结论。

常见问题（FAQ）

1. 对当前报表继续提问，和直接问数有什么区别？

继续提问是从用户正在看的页面出发，答案需要与该页面的数据范围和口径保持一致；直接问数通常从更广的数据模型出发，范围由问题本身决定。前者更强调上下文延续，后者更强调覆盖范围。两者可以衔接，但不能默认前者的上下文会自动传递到后者，需要确认实际的上下文条件。

2. 提问前至少要确认哪些上下文条件？

建议确认六项：问题落在哪个数据集或资源上、字段的业务含义是什么、时间与组织等筛选条件是否延续、指标口径与页面是否同源、以谁的身份提问以及能看到多大数据范围、提问起点是页面还是已发布资源。这六项中任意一项不清，答案都可能在看起来正确的同时口径已经偏移。

3. 为什么用管理员账号测试追问不可靠？

因为管理员通常能看到全部数据，权限边界完全体现不出来。用真实角色账号测试，才能观察到同一句问句在不同身份下返回的数据范围是否真的不同、越权提问是否被阻止。如果只用管理员账号验证，上线后区域用户看到全量数据这类问题很难在测试阶段被发现。

4. 同一句问句在不同时候答案不一样，正常吗？

要看差异来自哪里。如果数据本身在更新，答案变化是正常的；如果数据没变而答案变了，就要检查口径、字段映射或筛选条件是否发生了变化。判断方法是固定时间点与筛选条件再问一次，同时记录当时的指标口径版本，这样才能区分数据变化与规则变化。

5. 页面上的数字和追问得到的数字不一致，先查什么？

先查筛选条件是否延续，包括时间范围、组织范围与版本状态；再查指标口径是否与页面同源，页面可能存在自定义计算；然后核对数据更新时点是否一致；最后才看提问理解是否准确。多数不一致发生在前两步，先怀疑上下文条件比先怀疑理解能力更有效率。

6. 还没有统一指标口径，能做追问吗？

可以先在范围很小的场景里试，但不建议直接推广。口径不统一时，同一个问题在不同页面上会有不同答案，追问结果自然也会飘移，使用者很快会失去信任。更务实的顺序是先挑几个高频指标把定义固定下来，再用这些指标覆盖的场景验证追问效果。

7. 权限不同的人，追问结果应该不同吗？

应该不同。权限的核心含义就是同一句问句、不同身份的用户应当看到不同范围的数据。验证时要专门设计这类用例：用一个较宽权限账号和一个较窄权限账号问同一句话，确认返回结果的范围确实不同，同时确认窄权限账号不会因为提问方式变化而绕过限制看到更多数据。

8. 追问得到的结果需要人工复核吗？

取决于结果的用途。用于日常了解情况、快速定位方向，通常由使用者自行判断即可；如果要进入汇报材料、对外报送或用于决策依据，就需要有人核对数据来源与计算口径。复核的重点不是重算一遍，而是确认口径、时点与范围都符合使用要求。

9. 已发布的仪表盘都能直接追问吗？

不能这样理解。公开表述是存量仪表盘可以接入并继续追问，但是否覆盖你现有的资源类型、需要哪些配置、目标版本中的具体行为，都要在实际环境中确认。稳妥的做法是先选一个使用频次高、口径稳定的仪表盘做验证，跑通之后再逐步扩大接入范围。

10. 怎么判断一个追问场景可以推广了？

看三件事：真实业务问题在真实角色账号下能答对，且答案与页面口径一致；答案能说明数据来源与统计范围，使用者可以自行判断是否可用；提问方式变化时不会绕过权限限制。三项都满足，就可以在同类场景中推广；只满足第一项，说明还停留在演示水平。