← 全部项目

AI 工作台可信数据分析

AI能不能不只“生成一份分析”,还清楚交代数据是否可用、证据在哪里、结论为什么能信?

跟着图解看项目怎么完成从数据到结果,逐步查看处理过程
2026 · 可信分析工作台

项目介绍

我在阅读一篇讨论Data Agent风险的文章时,对其中一个问题产生了共鸣:企业把AI直接接到数据库以后,仍然需要回答数据口径是否一致、结论依据在哪里、谁批准结果发布。早期方案曾经计划把爬取、数据工程、分析、审核和报告全部交给一条Agent流程。继续调研以后,我把产品范围收缩到分析就绪数据进入BI之前的检查与报告过程,让现有分析工具继续完成擅长的工作。

3档探索/标准/治理模式
4阶段质量、分析、审查、报告
4种系统/AI/人工/批准责任
3色可用/谨慎/暂不发布
PythonFastAPIJinja2SQLiteDuckDBPandasLLM AdapterHTML

工作台流程

工作台接收整理好的表格,按约定规则检查数据、计算指标、审查结论,再生成报告。下面展示一次使用流程;AI 可以在审查之后按需解释已有结果。

程序计算与检查 → 人确认用途与发布

质量检查、计算数据结果、结果审查和报告生成均可由程序独立执行。AI 解释有单独入口与记录。

1提交整理好的数据,说明要解决的问题

整理好的表格订单表 / 站点小时表
分析输入合同记录单位、关键字段、时间、金额单位
检查输入结构选择对应案例
确认字段要求
保存本次输入文件副本
任务与版本记录
AdventureWorks 使用订单汇总表,CitiBike 使用 Silver 站点小时表。两类数据分别进入对应的计算流程。

先确认一行代表什么、哪些字段用来计算,再保存本次实际读取的数据,方便之后追查。

工具与方法:FastAPI 是接收网页请求的 Python 库;SQLite 是本地数据库,保存任务和状态;文件另行保存。

查看处理方法与依据收起处理方法与依据
  1. 用户提交符合案例字段要求的表格和分析问题
  2. 填写分析输入合同,说明记录单位、编号、时间和单位
  3. 选择已有计算案例,预测要求另存预测配置
  4. 检查输入结构,保存任务与文件版本
信息放在哪里具体内容程序怎样使用
分析输入合同一行含义、唯一键列、时间列、时区、金额单位、整理时间与工具、已知限制供输入检查与任务记录使用
案例计算代码经营案例要求 revenue、cost、returned 等实际列名按已有公式计算;中文描述不会自动映射成任意英文列
预测配置目标字段、允许或禁止字段、时间和评估要求供预测案例的检查和评估使用
任务配置保存分析问题、案例选择、输入合同等内容将本次输入与执行条件关联

分析输入合同是一份结构化的数据说明。用户或开发者可以填写,也可以让 AI 协助整理,再确认实际列名。具体指标公式由案例代码实现,预测字段限制由预测配置提供。

FastAPI 接收请求,SQLite 保存任务状态,文件另行保存。程序记录文件校验值,用于检查后续读取的文件内容是否发生变化。

2确认用途,选择检查要求

结果给谁用采用的模式发布要求
个人初步探索探索保留待验证草稿
团队内部报告标准发布前人工批准
预测、对外或高风险任务治理先确认任务,再批准发布
自动选择依据真实用途与风险,用户可以提高检查要求。文件规模另外用于估算执行方式与资源。

根据报告给谁用、是否用于预测等条件,确定检查范围与批准要求,并判断本机是否适合执行。

工具与方法:Python 按预先编写的规则执行运行前检查,读取文件信息并估算资源。

查看处理方法与依据收起处理方法与依据
  1. 读取任务用途、风险与数据规模
  2. 按程序规则建议探索、标准或治理模式
  3. 展示需要确认的内容与资源条件
  4. 记录本次执行方式
模式适合什么用途需要怎样确认
探索个人初步查看数据保留待验证草稿,不作为正式发布结果
标准团队内部常规报告发布前由人批准具体报告
治理预测、对外或高风险任务执行前确认输入和计算要求,发布前再批准报告

模式由明确的用途和风险规则决定;数据大小还用于估计资源需求。用户可以提高要求,不能通过降低模式跳过已识别风险所需的检查。

3检查数据是否符合本次任务的要求

字段需要的列齐全吗?

编号、日期、金额等
符合当前任务要求

记录数据有异常吗?

统计空值、重复
及规则规定的异常

预测案例另查是否违反已提供的预测限制?

按配置核对字段限制
与时间划分要求

规则来自分析输入合同、预测任务配置和程序内置检查。CitiBike 的禁止字段由工作台之外的 AI 编程助手阅读项目代码后提出,再通过配置传入。上传数据不会触发源代码复核,工作台也不会自行生成这份清单。

根据合同、预测任务配置和程序已有规则,检查字段是否齐全、关键值是否缺失、记录是否重复,以及是否存在规则规定的异常,并保存检查结果。

工具与方法:DuckDB 是本地数据查询引擎,通过 Python 调用;SQL 查询负责统计空值、重复和异常。

查看处理方法与依据收起处理方法与依据
  1. 读取合同、案例规则与预测限制
  2. DuckDB 查询字段、缺失值、重复和异常
  3. 预测案例另核对禁止字段与时间要求
  4. 保存通过项、问题项和对应原因
检查范围规则从哪里来检查例子
列与类型分析输入合同和案例要求计算收入需要的列是否存在
重复和缺失指定的唯一编号及程序检查规则按站点+小时统计重复,统计关键列空值
异常数值程序已经实现的质量规则经营案例统计收入小于 0 且未标记退货的记录
预测限制外部复核后写入的预测配置核对是否使用禁止字段,是否符合时间划分要求

CitiBike 的电动车比例、会员比例和平均骑行时长,由我与外部 AI 编程助手结合原项目代码确认存在同小时信息问题,再写进预测配置。工作台负责按配置检查,上传表格本身不会让工作台读取外部代码。

程序能检查已经声明并实现的规则。字段实际代表什么、生成过程是否合理,需要用户结合业务和来源确认。

重复数按每组记录数减 1 后求和计算,例如同一个订单编号出现三次,重复数记为 2。空值统计读取各列的 NULL 数量。

4按已有公式计算数据结果

输入三张订单收入:100、200、150
执行收入求和100 + 200 + 150
收入合计 450保存查询和结果
普通经营数据:按公式汇总,再看月份与业务分组。
CitiBike 数据:用历史均值等参考方法预测,再计算误差。
三张订单及金额均为假设,单位相同,用来说明程序计算方式。实际运行读取本次输入的完整数据。

调用当前案例已有的计算代码,把数据转为指标,并保存查询、结果文件和结论依据。

工具与方法:经营任务使用 DuckDB 和 SQL 汇总数据;预测案例使用 Python 执行参考方法与误差计算。

查看处理方法与依据收起处理方法与依据
  1. 读取本次输入和已确认的计算定义
  2. 运行对应案例的固定查询或预测评估
  3. 保存数值结果及查询依据
  4. 将结论关联到对应计算结果
案例怎样计算得到什么
经营数据DuckDB 用 SQL 汇总收入,再按月份、渠道等分组整体指标与分组结果
CitiBike 预测案例从允许的历史训练数据计算参考预测,再评估后续时段参考预测及误差指标
假设订单例子三张订单收入分别为 100、200、150,求和收入合计 450,保存对应查询和结果

DuckDB 是在本地执行表格查询的数据库工具。这里的计算由预先实现的程序完成,AI 不需要逐行读取数据或临时决定公式。

预测参考方法可以使用历史相同时段的平均需求。计算历史统计量时只使用训练部分,后面的验证、测试记录用于评价预测。

5检查结论能否由当前计算结果支持

待审查的结论收入合计为 450
本次保存的计算结果收入合计为 450
同时核对:输入版本 · 文件内容 · 结论引用位置 · 任务规则
继续使用上一步的假设金额。数值相同还需要其他检查满足;引用旧文件或违反预测字段规则时,结论仍可能不通过。

核对结论引用的文件是否存在、是否属于本次运行、数值是否相符,以及计算是否遵守任务规则。

工具与方法:Python 校验文件内容与版本,逐项对照结论及依据;预测案例另外检查时间与特征规则。

查看处理方法与依据收起处理方法与依据
  1. 读取待审查结论和对应计算文件
  2. 核对结论数值、引用位置与任务版本
  3. 检查文件内容及预测规则
  4. 保存审查状态,并按共同原因汇总问题
核对内容如何判断为什么要查
数值依据结论所写数值与引用的计算结果比较防止结论脱离实际计算
输入与版本比对任务记录、文件校验值及产物对应关系防止使用旧输入或被替换的文件
预测条件重新核对配置中的字段和时间要求数值算出来,也需要满足使用条件
问题展示将相同拒绝原因归并,保留逐条记录CitiBike 的 112 条重复拒绝可以先看共同原因

沿用上一阶段的假设例子:结论写收入 450,程序找到对应结果也是 450,再确认输入版本和其他要求。检查状态由这些规则产生;AI 解释不会改变检查状态。

6把结果、检查状态和限制写进报告

质量检查记录计算结果审查状态
本次分析报告结果是什么?依据在哪里?

任务范围与数据来源
主要结果与检查状态
尚存问题与适用限制

报告模板组织已有结果。报告生成完成与人工批准发布分别记录。

把前面得到的结果按固定模板组织起来,让读者先看到结论与问题,再展开查看技术记录。

工具与方法:Jinja2 是生成网页内容的 Python 模板库;Python 读取阶段产物并填写报告。

查看处理方法与依据收起处理方法与依据
  1. 读取已经保存的质量、计算和审查记录
  2. Jinja2 模板填入结果、状态与限制
  3. 生成可阅读的 HTML 报告
  4. 保留对应任务和产物信息
报告内容具体说明什么
任务范围和来源本次问题、使用的数据与时间范围
计算结果指标、分组结果及对应依据
检查状态哪些规则通过,哪些存在问题及原因
适用限制结果适用于什么范围,还有哪些条件未满足

Jinja2 是把已有数据填入页面模板的工具。报告排版读取已保存的数字,计算仍由前面的程序完成。报告生成后,还要按当前模式完成相应的人工确认才能正式导出。

7由人确认发布,再导出所需材料

读取当前报告确认模式
检查问题与限制
用户批准发布标准 / 治理模式
记录具体报告版本
正式导出HTML 报告
经营分析 BI 数据包
探索模式保留待验证草稿。修改输入后,需要重新检查和批准新报告;AI 解释不能代替批准。

确认报告能用于什么场景,记录人工批准,再按该版本导出材料。

工具与方法:Python 检查发布条件;SQLite 保存批准记录;导出程序打包数据、查询和指标说明。

查看处理方法与依据收起处理方法与依据
  1. 用户阅读当前报告的问题和限制
  2. 程序确认模式及发布条件
  3. 记录对这份报告的人工批准
  4. 导出 HTML 报告或经营分析 BI 数据包
导出材料包含什么后续怎样使用
HTML 报告结果、依据、检查状态和适用范围供他人阅读本次运行结果
经营分析 BI 数据包数据、查询、指标说明和 Power BI 建议继续搭建报表并核对计算定义
批准记录具体报告版本和批准决定确认此次导出对应哪次运行

输入或报告改变后,需要重新确认相关结果。探索模式保留草稿;标准和治理模式按各自要求完成批准,AI 解释不能代替人的发布决定。

返回工作台流程目录 ↑

图片与材料

项目结果

  1. 01

    稳定分析需要先固定输入、口径、证据和发布边界,再让AI解释检查结果和可能影响。

  2. 02

    同一套严格规则不适合所有任务;按风险、数据规模与用途分档,才能平衡时间、成本和可信度。

  3. 03

    CitiBike复核证明:工作台能发现实验设计疑点,但复杂判断仍需要人工理解业务后确认。

分析中的判断与处理

CitiBike成为工作台第一次完整的项目复核。初版界面输出了112条重复拒绝,专业词汇也让我很难快速判断问题的实际影响。这个使用过程直接推动新版修改:重复问题合并成总览;普通视图按“发生了什么、影响是什么、下一步怎么办”解释;系统规则、AI解释、人工确认和最终批准分别标明;绿色、黄色和红色状态说明当前结果能否使用。工作台保留专业证据,但普通用户不必先读完整技术报告才能知道下一步。

我与 AI 如何完成项目

Codex + ChatGPT-sol

个人产品设计与交付。本人定义使用场景、运行分档、证据规则、中文普通视图和验收标准;AI协助实现与测试。

需求怎样从已有项目开始

我先阅读朋友的HomeWork-PipeLine,并让AI继续查找数据流程、Agent分工和审查机制的开源项目。调研帮助我理解Spec、阶段依赖和执行记录,也让我看见原始设想包含了过多功能。

AI怎样参与

AI主要负责读取代码库、实现FastAPI、SQLite、DuckDB、Jinja2页面、测试和文档并参与产品定位、使用流程和结果解释。我负责确定产品服务谁、哪些阶段保留、每种状态代表什么,以及哪些结果允许导出。

Skill与固定规则怎样进入项目

前端修改会调用界面设计Skill,通俗解释会使用固定的中文表达规则。Skill负责提供可重复执行的检查方法;我根据实际使用反馈继续修改规则,例如要求专业术语第一次出现时立即解释,并为拒绝结果提供具体修改建议。

当前Agent流程实现到哪里

数值检查仍由固定代码完成,AI只解释已经生成的结果。Planner、Analyst、Reviewer和Reporter按顺序处理解释任务。当前版本没有实现多个Agent并行探索,也没有使用LangGraph或独立MCP Server。

参考与使用说明

86thAuspiciousVerse / HomeWork-PipeLine ↗

参考了Spec提取、阶段执行和审核记录的组织方式。当前工作台聚焦分析输入、质量检查、结果审查和发布,并保留各阶段的证据与责任记录。

结果适用范围
  • 当前是本地求职展示版,不是企业级多用户云平台。
  • 工作台接收分析就绪数据,不承担所有繁重的数据清洗工作。
  • 它提高的是“结果能否被检查和解释”,不能保证AI自动得到唯一正确结论。

查看项目动画图解 ↗

下一个项目青岛公交线路与换乘网络分析
项目截图打开原文件 ↗
100%滚轮缩放 · 拖动查看