分析域规划指南
分析域是 Analytics Agent 中组织问答能力、数据资产、业务口径和用户访问范围的核心单元。对于企业级场景，分析域规划不是简单地“把表加进去”，而是决定哪些用户围绕哪些业务问题、在什么数据边界内进行分析。
如果企业有上万张表、上百个业务部门和数千名用户，分析域规划会直接影响问答准确性、权限治理复杂度、指标口径一致性和后续运维成本。
核心结论
不要把所有表和所有用户都放进一个“大而全”的分析域。
更推荐按“业务主题 + 使用人群 + 数据口径 + 敏感边界”规划多个分析域，再在每个分析域内配置表、字段语义、知识、指标、答案构建器、推荐问题和权限。
分析域应先完成第一层业务隔离；角色授权、字段隐藏、行级权限和审计日志再负责更细粒度的治理。
从 Agent 设计角度看，分析域规划是在为大模型设计工作边界。不要让模型在全公司所有表、所有口径、所有知识中自由选择，而要先告诉它：这个域服务谁、回答哪些业务问题、使用哪些数据资产、遵守哪些口径和权限。边界越清晰，模型越容易稳定完成分析任务。
为什么不能只建一个大域
一个“大而全”的分析域看起来简单：所有表都加进去，所有用户都能进来，用户想问什么就问什么。但在真实企业环境中，这通常会带来更高的治理和排查成本。
| 问题 | 影响 |
|---|---|
| 表和字段过多 | 模型需要在过多候选表和字段中选择，容易误选。 |
| 业务上下文混杂 | 财务、销售、运营、人力等语义混在一起，用户问题更容易被错误理解。 |
| 指标口径冲突 | 不同部门对同一指标可能有不同定义，例如“收入”“活跃用户”“有效订单”。 |
| 权限规则复杂 | 不同用户群体都在同一个域内，需要大量角色、字段隐藏和行级权限补救。 |
| 知识互相干扰 | 同一个词在不同部门含义不同，放在同一个知识空间中容易冲突。 |
| 答案构建器难维护 | 大量复杂 SQL 模板集中在一个域内，命名、适用范围和变更影响难以管理。 |
| 问答排查困难 | 答案不准时，很难判断是域过大、表误选、字段歧义、知识冲突、指标错误还是权限限制。 |
因此，大规模组织应把分析域当成治理边界，而不是把它当成所有数据资产的容器。
分析域规划原则
按业务问题规划，而不是按表清单规划
规划分析域时，不要从“我有哪些表”开始，而要从“哪些用户要围绕哪些业务问题做分析”开始。
推荐问题：
- 这个分析域服务哪些用户？
- 用户每天或每周最常问的 5 到 10 个问题是什么？
- 这些问题是否围绕同一个业务主题？
- 这些问题是否使用相同或兼容的指标口径？
- 这些问题需要哪些表、文件、知识和指标支撑？
如果无法用 5 到 10 个推荐问题说明一个分析域的核心能力，通常说明该域边界还不清晰。
按稳定业务主题划分
一个分析域应围绕稳定业务主题组织，例如：
- 销售经营分析。
- 客户续费分析。
- 合同回款分析。
- 财务费用分析。
- 人力招聘分析。
- 会员运营分析。
如果一个域内的问题横跨多个互不相关主题，用户提问时更容易触发错误资源。
按使用人群划分
分析域应服务相对明确的用户群体。
例如：
| 用户群体 | 推荐域 |
|---|---|
| 管理层 | 经营总览分析域。 |
| 销售团队 | 销售经营分析域、线索分析域、回款分析域。 |
| 财务团队 | 财务经营分析域、费用分析域、回款核算分析域。 |
| 运营团队 | 用户运营分析域、活动效果分析域。 |
| 人力团队 | 招聘分析域、人员结构分析域。 |
如果一个分析域中有多个权限差异很大的用户群体，通常需要拆域，或者至少拆成“总览域”和“部门域”。
按指标口径划分
指标口径是分析域边界的重要依据。
同一个词在不同业务部门可能有不同定义：
| 指标词 | 可能差异 |
|---|---|
| 收入 | 财务确认收入、订单支付金额、合同签约金额。 |
| 活跃用户 | 登录用户、付费活跃用户、订阅有效用户。 |
| 有效订单 | 支付成功订单、未退款订单、已履约订单。 |
| 客户数 | 注册客户、付费客户、企业客户、活跃客户。 |
如果两个部门对关键指标口径不同，建议拆分分析域，分别维护知识、指标和答案构建器，避免同名指标跨域混用。
按数据敏感度划分
敏感数据应优先独立建域。
适合独立建域的数据包括：
- 薪酬数据。
- 财务凭证和明细。
- 客户隐私数据。
- 合同敏感条款。
- 人员绩效数据。
- 涉及合规审计的数据。
敏感域应更严格地配置：
- 域成员。
- 角色数据权限。
- 字段隐藏。
- 行级权限。
- 审计日志检查。
不要把敏感表混入普通业务分析域中，再完全依赖字段隐藏或行级权限补救。
按上线阶段划分
企业级落地不建议一次性把所有业务都纳入生产域。
推荐采用：
-
试点域
用少量高质量表、知识、指标和答案构建器验证核心场景。 -
生产域
通过验证后，开放给目标业务用户。 -
扩展域
针对新业务主题、新部门或新问题集逐步扩展。
这种方式可以降低一次性上线的风险，也便于用审计日志和问答记录持续优化。
推荐架构模式
跨部门经营总览域
适合管理层、经营分析团队或数据团队使用。
建议只加入：
- 跨部门共用的核心汇总表。
- 已统一口径的核心指标。
- 少量经过验证的答案构建器。
- 管理层常用推荐问题。
不要把所有部门明细表都加入总览域。总览域的重点是统一口径和高层概览，而不是替代所有部门域。
部门分析域
适合每个业务部门维护自己的高频分析场景。
例如：
- 财务分析域。
- 销售分析域。
- 运营分析域。
- 人力分析域。
部门分析域中应加入该部门常用的表、文件、知识、指标和答案构建器。部门内部如果场景仍然复杂，可以继续拆分专题域。
专题分析域
适合业务链路较长、数据量大、口径复杂的部门。
例如销售部门可以拆分为：
- 销售线索分析域。
- 商机推进分析域。
- 合同签约分析域。
- 回款分析域。
- 客户续费分析域。
专题域的好处是问题边界更清晰，字段语义和答案构建器更容易维护。
敏感数据独立域
适合权限要求更高的数据场景。
例如：
- 薪酬分析域。
- 财务凭证分析域。
- 客户隐私分析域。
敏感域应使用更严格的成员管理和字段治理，并定期结合审计日志检查访问和变更情况。
共享基础表多域复用
同一张表可以服务多个业务场景时，不一定要把所有用户放进一个大域。
更推荐：
- 将同一张表加入多个相关分析域。
- 在不同域中配置符合当前业务场景的字段语义、知识和指标。
- 对不同用户群体分别配置域权限和角色权限。
例如客户主表可以同时出现在：
- 销售客户分析域。
- 运营会员分析域。
- 财务回款分析域。
但每个域对“客户”的关注点、指标和推荐问题可以不同。
常见反模式
一个大而全分析域
把所有表、所有指标、所有知识和所有用户放在一个域中。
风险：
- 问答误选表。
- 指标口径混用。
- 权限规则复杂。
- 知识互相冲突。
- 问题排查困难。
每张表一个分析域
把分析域当成单表问答入口。
风险：
- 用户需要频繁切换域。
- 多表业务问题无法自然表达。
- 指标、知识、答案构建器无法围绕完整业务场景组织。
除非是非常明确的单表试验或临时验证，不建议长期采用这种方式。
按数据库目录直接建域
按 Catalog、Schema、数据库名机械划分分析域。
风险：
- 技术目录不等于业务边界。
- 一个业务主题可能跨多个 Schema。
- 一个 Schema 中可能包含多个部门或多个业务主题。
分析域应面向业务问题，而不是照搬底层数据库结构。
把权限隔离完全交给行级权限
行级权限适合控制同一张表中不同用户能看哪些行，但不适合替代分析域隔离。
如果不同部门的问题、指标、知识和答案构建器都不同，应优先拆分分析域，再用行级权限处理域内数据范围差异。
指标口径冲突仍放在同一个域
如果“收入”“活跃用户”“客户数”等核心指标在不同人群中有不同含义，不应只靠知识解释来补救。
更稳妥的方式是拆分分析域，或在总览域中只保留经过统一治理的口径。
分析域拆分决策表
可以用以下问题判断是否需要新建或拆分分析域：
| 判断问题 | 如果答案是“是” |
|---|---|
| 是否有独立业务主题？ | 倾向单独建域。 |
| 是否有独立用户群体？ | 倾向单独建域或至少单独配置域权限。 |
| 是否有独立指标口径？ | 倾向单独建域。 |
| 是否包含敏感数据？ | 倾向单独建敏感域。 |
| 是否需要独立知识和答案构建器？ | 倾向单独建域。 |
| 是否能用 5 到 10 个推荐问题描述清楚？ | 如果不能，说明域边界需要重新梳理。 |
| 是否需要大量例外权限规则？ | 倾向拆域，减少例外配置。 |
| 问答是否经常选错表或混用字段？ | 倾向拆域或减少域内资源范围。 |
推荐实施步骤
第一步：盘点业务问题
先收集目标用户最常问的问题，而不是先盘点所有表。
建议输出：
- 目标用户群体。
- 高频业务问题。
- 涉及指标。
- 涉及维度和过滤条件。
- 涉及文档和业务口径。
第二步：设计分析域边界
根据业务问题，将场景归类为：
- 总览域。
- 部门域。
- 专题域。
- 敏感域。
- 试点域。
每个域都应有明确名称、适用人群和业务范围。
第三步：选择核心资源
不要一次性加入所有表。优先加入能支撑高频问题的核心资源：
- 高频事实表。
- 常用维表。
- 已确认口径的指标。
- 必要知识。
- 必要文件。
- 高价值答案构建器。
后续根据问答验证逐步扩展。
第四步：配置语义和口径
为每个域配置：
- 字段别名。
- 字段描述。
- 列类型。
- 字段用途。
- 隐藏字段。
- 知识。
- 指标。
- 答案构建器。
- 推荐问题。
这些配置应围绕当前域的业务场景，而不是机械复用全部字段说明。
第五步：配置权限
按域配置用户成员，再结合角色授权、资源数据权限、字段隐藏和行级权限细分访问范围。
建议：
- 业务用户只加入自己需要的分析域。
- 域维护人员拥有对应域资源的编辑权限。
- 敏感域成员应单独审批和定期复查。
- 行级权限用于处理同一域内不同用户的数据范围差异。
第六步：用推荐问题验证
每个分析域上线前，至少准备 5 到 10 个推荐问题，覆盖：
- 总览问题。
- 核心指标问题。
- 分组分析问题。
- 筛选分析问题。
- 文档或口径解释问题。
- 复杂分析问题。
逐条验证问答结果、生成 SQL、命中的指标、知识、文件和答案构建器。
示例：大规模企业分析域规划
假设企业有：
- 10000 多张表。
- 100 多个业务部门。
- 2000 多个用户。
可以采用以下规划：
| 层级 | 分析域类型 | 示例 | 使用人群 |
|---|---|---|---|
| 1 | 经营总览域 | 公司经营总览 | 管理层、经营分析团队。 |
| 2 | 部门域 | 财务分析、销售分析、运营分析、人力分析 | 各部门业务用户。 |
| 3 | 专题域 | 销售线索、合同回款、客户续费、招聘漏斗 | 专题负责人和分析人员。 |
| 4 | 敏感域 | 薪酬分析、财务凭证、客户隐私 | 授权小范围用户。 |
| 5 | 试点域 | 新业务试点分析、临时验证域 | 数据团队和试点用户。 |
这种方式可以让每个分析域都保持明确边界，同时支持跨部门总览和部门内深度分析。
判断分析域是否健康
一个健康的分析域通常具备以下特征：
- 业务主题清晰。
- 用户群体明确。
- 表数量可管理。
- 字段语义维护得住。
- 指标口径一致。
- 知识不互相冲突。
- 推荐问题能覆盖核心场景。
- 权限规则不需要大量例外。
- 问答问题可以定位和排查。
- 审计日志能追踪关键变更。
如果一个分析域长期依赖大量例外权限、经常出现问答误选、维护人员无法解释域内资源用途，就应该重新评估是否需要拆分。