第四章 数据管理与文件上传
数据管理用于把分散在本地表格、业务系统和历史分析中的资料统一沉淀为可复用的数据资产。对于普通业务用户而言,它的价值不只是“把文件传上去”,而是让后续的快速分析、报告生成和团队协作建立在同一份可信数据之上。
本章以销售运营团队的月度复盘为例:运营人员每月从业务系统导出区域销售明细,上传到系统后确认解析状态和字段内容,再将该文件用于下降原因分析、门店对比和经营报告生成。
1. 查看数据管理总览
进入左侧导航栏的“数据”页面后,系统会汇总展示数据源、数据文件、数据快照和分析制品。用户可以在这里快速判断当前组织已经沉淀了哪些数据资产、最近上传了哪些文件,以及是否存在需要处理的数据健康问题。

总览页适合用作日常数据工作的起点。业务人员可以优先查看“最近活动”,确认新上传的文件、数据源快照和可复用制品是否已经进入系统;管理员则可以结合数据质量提示,及时发现转换未完成、架构缓存缺失、REST API 缺少 OpenAPI 配置等问题。
2. 管理数据源连接
数据源用于连接可长期复用的业务系统或数据库。进入“数据源”页面后,可以看到 REST API、SQLite、OLAP 等不同类型的数据连接,每个卡片会展示名称、类型、说明和快速操作入口。

建议在添加数据源时写清楚业务系统名称、数据范围和使用限制。例如“销售运营 REST API”适合承载订单、门店、库存与客户成功指标,“经营分析 ClickHouse”适合承载生产分析库中的宽表或聚合表。
点击某个数据源后,可以进入详情页查看连接配置、表结构或 API 配置。对于 OLAP 数据源,页面会展示主机、数据库、账号、建表语句,并提供自然语言查询入口,便于用户在正式分析前先验证数据是否可用。

如果数据源来自 REST API,应优先补充 OpenAPI/Swagger 规范,帮助系统理解接口路径、参数和返回结构。缺少规范的数据源仍可以被记录,但会在数据健康区域提示需要补充配置。
3. 上传本地业务文件
当需要分析新的业务数据时,点击“上传文件”进入上传窗口。系统支持 CSV、Excel、JSON 和文本文件,适合承载销售明细、客户清单、库存台账、问卷结果等常见办公数据。

上传前建议先检查文件内容是否满足以下要求:
- 文件名能够说明业务主题和时间范围,例如“华东区月度销售明细(2026年4月).csv”。
- 第一行包含清晰的字段名,避免使用“列1”“金额2”这类难以理解的标题。
- 关键字段保持一致口径,例如日期、区域、门店、品类、销售额、订单数等。
- 删除无关的空行、合并单元格和临时备注,降低后续解析和分析的不确定性。
4. 确认文件状态与可见性
上传完成后,进入“数据文件”页面查看文件库。文件卡片会展示文件标题、创建时间、文件类型、大小和处理状态。处理状态为 ready 时,代表文件已经可以被后续分析流程引用;如果显示 queued 或其他处理状态,说明文件仍在准备中。

点击文件后进入文件详情页。这里会显示文件类型、大小、创建时间、备注、可见性和处理状态。可见性用于控制数据共享范围。默认保持私有时,文件只服务于当前用户或受控流程;当团队需要共同复用同一份数据时,再根据组织规则调整共享方式。

文件详情页还提供“分析数据”入口。确认状态正常后,用户可以直接跳转到分析页面,把当前文件作为问题分析的数据基础,减少在不同页面之间反复选择数据的步骤。
5. 预览数据内容
数据预览可以帮助用户在发起分析前做一次快速校验。以上传的销售明细为例,预览中可以看到月份、区域、城市、门店类型、门店名称、品类、销售额、订单数、访客数、客单价和上月销售额等字段。

这个步骤能显著减少“分析结果不符合预期”的情况。比如销售额下降分析依赖 sales_amount 和 last_month_sales,门店效率分析依赖 orders、visitors 和 avg_order_value。如果字段缺失或单位不一致,用户应先修正源文件后再上传。
6. 将文件转换为数据库
当一个文件需要反复查询、关联分析,或包含多个工作表和较多记录时,可以在文件详情页点击“转成数据库”,把文件转换为 SQLite 数据源。转换后的结果会出现在数据源列表中,后续可以像使用其他数据库一样进入查询、分析和模板流程。

转换页面会自动检查当前文件是否已经存在目标 SQLite 数据库。如果已经转换过,页面会提示检测到的表,并提供“查看数据源”“查看已创建表”或“重置并转换”等操作,避免用户在不知情的情况下覆盖已有结果。
首次转换时,系统会启动一个代理式转换流程:AI 会先理解文件结构,再规划表结构、推断字段类型、生成建表 SQL,并按批次写入数据。它不是简单地把表格原样搬进数据库,而是会根据标题、样式、数据模式和多工作表关系,尝试整理出更适合查询和后续分析的 SQLite 结构。
转换页面左侧展示总体进度、已执行 SQL 数量、成功步骤和已创建表;右侧展示实时事件流,包括开始转换、处理工作表、执行 SQL、插入结果和数据源创建事件。这个日志能让用户看到代理每一步做了什么,也方便在出现问题时追溯原因。
转换过程中如果遇到数据格式或 SQL 执行问题,系统可能会暂停并提示用户选择处理方式。通常建议先查看错误信息和当前 SQL,再决定重试、忽略当前问题或中止转换。即使用户主动停止转换,已经写入的数据也会被保留,并可在条件满足时创建部分转换的数据源。
适合转换为数据库的文件包括月度销售明细、库存流水、客户续费清单、多工作表 Excel 和需要反复筛选聚合的大型 CSV。对于只需阅读的一次性纪要、说明文档或少量补充文本,直接作为文件参与分析通常更轻量。
7. 真实使用建议
在月度经营复盘中,推荐将数据管理作为固定流程的一部分:先上传本月数据,再检查解析状态和字段预览,最后进入快速分析或报告生成。这样团队可以围绕同一份数据讨论问题,避免多人各自使用不同版本表格导致口径不一致。
当数据文件需要长期复用时,建议在标题和备注中写清楚业务周期、数据来源和用途。例如“华东区月度销售明细(2026年4月)”适合用于本月销售下降分析,而“华东区门店基础信息表”则更适合作为长期维表反复引用。
对于稳定的业务系统,优先沉淀为数据源;对于一次性导出的表格或临时补充材料,优先上传为数据文件。两者都可以进入分析流程,但数据源更适合持续更新和多人复用,文件更适合快速验证和单次复盘。
8. 本章小结
通过数据管理,用户可以把本地文件、业务 API 和数据库连接转化为系统中的可用数据资产。它带来的直接收益是减少重复上传和重复选择,长期收益是让分析流程建立在更清晰、更统一、更容易协作的数据基础上。