一、核心能力 1. 用业务语言提问，直接查看数据结果 无需先编写 SQL，可以直接描述想了解的指标、时间范围和比较维度。系统结合表结构、业务语义与成员的数据权限生成并执行查询，以文字、表格或图表呈现结果，让提问中的业务含义与可访问的数据范围对应起来。围绕已有结果继续追问，可以逐步缩小范围、补充条件，深入查看业务变化。
2. 从单次查询，延伸到完整分析 简单问题通过数据问答快速查看；需要多步拆解的问题，可以使用深度分析整理报告。对于需要反复查看的指标，将结果组织成看板，让一次分析成为后续持续跟踪的起点。
3. 沉淀业务语义，让分析使用统一口径 通过表字段说明、关联关系、业务术语和 SQL 样例，将业务语言与实际数据结构对应起来。例如，“项目完成率”如何计算、“有效工单”包含哪些状态，都可以通过业务上下文明确，帮助系统按约定口径理解问题和组织查询。
再将常用分析方法整理为技能，组合到面向具体场景的智能体中，让不同岗位复用团队已有的知识与方法。业务规则发生变化时，同步更新相关定义，减少重复解释和口径偏差。
4. 按职责分配权限，让数据使用有边界 管理员根据成员职责分配数据访问范围，通过表、行、列规则限定可查询的数据。例如，区域人员查看本区域记录，财务岗位访问获授权的财务字段。权限规则落实到实际查询，业务语义则帮助明确“这些数据代表什么、应如何计算”，共同支撑团队协作分析。
二、使用流程 接入数据 → 定义业务语义 → 配置数据权限 → 对话分析 → 保存报告或看板。
管理员先完成部署、模型配置和数据源接入，补充表字段含义、指标定义与关联关系，并按岗位配置成员的数据权限。业务人员选择可访问的数据源或智能体，用熟悉的业务语言提问，在既定口径与权限范围内开展分析；需要分析文件时，也可以上传 Excel 或 CSV 开始问答。
查看部署方式 → 了解数据接入 →
三、适用场景 平台围绕数据连接、业务口径和分析方法开展工作，可用于制造、金融、教育、能源、物流、零售及公共服务等领域。具体分析范围取决于接入的数据、成员权限和已配置的业务规则。
经营与运营： 比较不同区域、部门或业务单元的指标表现，观察趋势、结构与阶段变化。财务与成本： 汇总收入、支出、预算与成本，按项目、部门或期间比较执行情况。生产与供应链： 分析产量、质量、库存、采购与交付数据，查看各环节的效率和差异。项目与服务： 跟踪项目进度、资源投入、工单处理与服务质量，整理阶段性分析报告。管理与研究： 围绕专项问题进行多维比较，通过报告梳理结论，通过看板持续查看关键指标。四、面向不同岗位 业务人员在获授权的范围内查询和分析日常数据；分析人员维护业务语义与分析方法，让指标定义可复用；管理者通过统一口径的报告和看板了解业务表现；管理员统一配置模型、数据源、成员权限与商业授权。
1. 下载部署配置 新建一个部署目录，将配置文件保存为 docker-compose.yaml。
下载 docker-compose.yaml ↓
启动前修改配置中的数据库初始密码，应用与 PostgreSQL 两处保持一致。此配置默认使用 latest 镜像；如需固定版本，直接修改 docker-compose.yaml 中应用的 image 标签。
2. 启动服务 在配置文件所在目录执行：
终端 复制命令
docker compose up -d配置会同时启动应用、PostgreSQL 和 Redis，首次启动自动初始化数据库，无需下载源码。
3. 登录并配置模型 浏览器打开 http://服务器地址:18080。
新装账号：admin 初始密码：123456。首次登录后修改密码，并在系统设置中配置模型服务，然后接入数据源。
常用维护 查看服务状态与启动日志：
终端 复制命令
docker compose ps
docker logs --tail=100 aix-db升级前备份数据库和完整 volume/app_data，保留原配置与镜像版本。需要指定版本时，先修改配置文件中的应用镜像标签，再执行：
终端 复制命令
docker compose pull
docker compose up -d数据保存在部署目录的 volume 下，请保留此目录。离线环境需预先导入配套镜像，并准备内网可访问的模型服务。
一、支持的数据来源 常用数据库： MySQL、PostgreSQL、Oracle、SQL Server。分析数据库与数仓： ClickHouse、Apache Doris、StarRocks、Apache Hive 等。国产与云数据库： 达梦、金仓、GaussDB，以及多种 MySQL / PostgreSQL 兼容服务。本地文件： Excel（.xlsx / .xls）、CSV，详见表格分析 。不同数据库的可用能力受版本、兼容协议与驱动影响，实际接入时应先测试连接，再完成元数据同步。
二、连接数据库 新建连接： 进入数据源管理，选择数据库类型，填写地址、端口、账号和数据库名称；需要 Schema 的数据库应填写实际 Schema。测试连接： 确认账号凭据、网络访问和数据库权限可用。同步元数据： 获取可用表与字段信息，为后续问答准备数据结构。验证查询： 使用一个已知结果的简单问题，检查数据范围与统计口径是否符合预期。三、补充业务含义 表名和字段名通常不能完整表达业务规则。接入后，可补充字段说明、表间关联、术语和常用 SQL 样例，帮助系统将问题中的业务语言映射到实际数据。
例如，“销售额”是含税金额还是实收金额，“有效订单”是否排除取消订单。这些规则应提前明确，避免同一指标在不同问题中使用不同口径。
四、连接异常怎么办 连接失败时，依次检查地址端口、账号密码、访问白名单及数据库权限。应用在容器内运行时，localhost 指向容器自身；宿主机上的服务可通过 host.docker.internal 访问。
连接成功但找不到表时，检查数据库与 Schema 是否正确、账号是否有读取元数据的权限，以及同步是否完成。
一、开始一次问答 选择范围： 进入数据问答，选择可访问的数据源或业务智能体。提出问题： 说明想看的指标、时间范围和分析维度。查看答案： 结合文字结论、结果表和图表了解数据表现，并查看 SQL 中的筛选与统计条件。继续追问： 沿着当前问题补充维度、调整时间或缩小范围。二、如何把问题说清楚 一个清楚的问题通常包含三个要素：看什么指标、看哪个时间段、按什么维度比较。 如果指标有特定业务定义，也可以在提问中直接说明。
本月各门店销售额是多少？与上月相比，哪些门店变化最大？销售额按实际支付金额统计。
得到整体结果后，可以继续问“只看华东区域”“按商品分类拆开”“查看变化最大的三家门店”。每次聚焦一个问题，更便于核对结果与判断下一步。
三、理解与复核结果 文字结论帮助概括重点，表格用于查看具体数值，图表便于观察结构与趋势。需要确认某个数字时，应同时检查查询使用的时间范围、过滤条件、分组方式和业务口径。
没有返回数据不一定代表业务没有发生，也可能与权限范围、日期条件或数据同步有关。对于经营决策中的关键数字，建议与已有报表或已知样本交叉核对。
一、适合分析什么 例如，汇总部门费用、比较门店销售、检查商品库存分布，或对某一阶段的订单进行分类统计。文件中的字段和数据决定了可分析的范围；需要额外业务口径时，可以在问题中补充说明。
二、操作步骤 上传文件： 选择需要分析的 Excel 或 CSV 表格。说明目标： 告诉系统需要统计哪些字段、按什么维度分组，以及使用哪个时间范围。查看结果： 检查汇总数值和展示内容，确认单位、日期和计算方式。继续分析： 补充筛选条件或比较维度，围绕文件中的数据继续追问。按部门汇总这份费用表，比较各月支出，找出增长最多的费用类别，金额统一以万元展示。
三、让表格更容易分析 尽量保持一行对应一条业务记录，使用明确的列名，并统一日期格式、金额单位和分类名称。分析区域中避免混入说明文字、重复表头或与明细混排的汇总行。
涉及多个工作表时，说明各表含义与关联字段，例如订单号、商品编码或部门编号。若结果与预期不一致，优先检查空值、重复记录、单位和汇总口径。
一、什么时候使用 当问题不只是“一个数字是多少”，还需要比较多个指标、拆解不同维度、梳理变化来源时，可以使用深度分析。例如季度经营复盘，需要同时查看销售额、毛利率、客单价以及门店间差异。
如果只需要一个明细列表或简单汇总，数据问答通常更直接。明确分析目标后再生成报告，有助于减少无关内容。
二、如何发起分析 确定数据范围： 选择分析使用的数据来源，确认相关数据已接入且具备访问权限。说明目标： 写清时间范围、核心指标、比较维度和希望回答的问题。生成报告： 启动深度分析，等待查询、计算与报告整理完成。阅读复核： 查看指标与图表是否回答了原始问题，结合业务口径核对关键结论。三、一个完整的提问示例 分析前三季度各门店的销售额、毛利率和客单价，比较各季度变化与门店差异，指出值得进一步关注的问题，整理一份经营复盘报告。
可补充报告面向的读者和关注重点，例如经营负责人更关注变化与行动方向，分析人员更关注维度拆解和数据依据。
四、如何使用报告结论 将报告作为梳理问题与形成判断的依据。数据中的相关变化并不自动证明因果关系；涉及经营原因时，应结合促销、价格、供货和组织调整等业务背景进一步验证。
一、创建主题看板 先明确看板服务的业务主题和使用对象，再描述需要展示的指标与维度。可以通过对话搭建看板，也可以将可复用的查询结果加入看板。
创建一个销售看板，展示本月销售额、各渠道占比和每日销售趋势，方便运营团队查看整体表现与变化。
二、调整内容与布局 创建后可继续用自然语言补充指标、修改图表和调整内容，并按阅读顺序组织布局。通常先展示总体指标，再展开趋势和结构，最后保留需要进一步查看的明细。
例如，先提出“增加各区域的销售对比”，再根据使用反馈调整展示。让每张图回答一个明确问题，可以避免看板信息过多却难以阅读。
三、刷新与持续跟踪 需要最新数据时，可刷新看板，也可以配置刷新计划。刷新依赖数据源连接、查询权限与服务运行状态；设置频率时，应结合业务更新节奏和数据库查询成本。
如果某张图没有更新，先检查相关数据源是否可用、查询条件是否仍然有效，以及最新数据是否已经产生。
四、分享分析成果 通过看板的分享入口将成果提供给需要查看的人。分享前确认接收者范围和数据访问设置，并检查页面中的指标名称、单位与说明，让没有参与创建的人也能理解内容。
一、数据智能体：围绕场景组织资源 面向销售、财务、运营等具体场景，将相关数据源、业务文档和技能组合成业务助手。使用者选择对应智能体后，可以围绕该场景提问，减少反复说明数据背景与规则的工作。
例如，销售分析智能体可以围绕门店、商品与渠道组织业务资料，让日常查询和阶段复盘使用同一套背景信息。
二、业务技能：复用分析方法 将稳定的分析步骤、统计规则和输出要求整理成技能，例如月度经营复盘、渠道贡献分析或库存检查。技能在授权范围内供问答和智能体使用。
技能应说明适用问题、所需数据、指标口径和输出结构，让同类分析有可复用的方法，也便于后续检查和维护。
三、如何整理一项技能 明确用途： 说明它适合解决哪类问题，哪些情况不适用。写清口径： 定义时间范围、统计指标和必要过滤条件。组织步骤： 先总体比较，再按关键维度拆解，最后整理结果。验证效果： 用真实的业务问题检查输出，再调整不清楚或不稳定的规则。四、使用与维护建议 优先保存稳定的业务规则，避免把某次查询的临时日期、特定客户或偶然条件写成通用要求。表结构、业务定义或流程发生变化后，也应同步更新相关资料与技能。
一、按岗位配置数据权限 根据岗位与业务职责分配成员可访问的数据，并通过表、行、列规则进一步限定范围。例如，门店人员仅查看本门店的数据，总部人员根据职责查看跨门店汇总。
权限配置完成后，应使用对应成员账号验证实际查询结果，确认可访问的数据与预期一致。调整人员职责或数据源时，也应同步检查已有规则。
二、统一配置模型服务 管理员在系统设置中填写模型供应商、服务地址、凭据和可用模型。配置后通过一个简单问题验证调用是否正常，再开展更复杂的分析任务。
私有化部署使用的模型可以位于内网或其他可访问的服务地址。数据分析的网络边界需要结合模型接口、外部工具及可选追踪服务共同确认。
三、激活商业授权 进入系统设置的「品牌与授权」，查看当前机器指纹与授权状态。 导出申请信息，获取与当前机器匹配的授权证书。 激活证书后，核对有效期和用户额度，以实际证书内容为准。 四、升级与迁移时保留授权资料 授权证书和试用状态保存在持久化目录中，更新镜像或重建容器时应保留该目录。重启不会重置已有试用。
授权与机器身份相关。更换服务器或重置 Docker Desktop 虚拟机前，应确认是否需要重新签发证书，并做好数据库、附件和安全材料的配套备份。
