Python电商订单数据可视化分析系统：Django+ECharts+大模型Agent实战

毕业设计年年都在做电商系统，但绝大多数作品停留在了“能登录、能下单、后台CRUD”的水平，答辩时被老师一问“分析了什么”就卡壳。今天这篇博文完全围绕Python电商订单数据可视化分析系统展开，用 Django 做后端、配合 ECharts 做可视化看板，再接入大模型 Agent 实现自然语言查数，把“订单数据”真正变成“决策依据”。我会从技术选型、数据库设计、分析维度、大模型集成、算法优化、常见坑位几个层面完整拆一遍，附带可直接复用的代码思路和部署建议，不管你是准备毕业设计，还是想在公司内部搭一套轻量级数据看板，都能从里面拿到干货。

1. 项目整体设计与技术选型思路

1.1 为什么是 Django 而不是 Flask 或 Spring Boot

做数据分析类系统，第一反应是 Flask，轻量、灵活、适合单脚本。但真正要把系统做成一个“能演示、能扩展、能写进论文/答辩PPT”的完整项目，Django 的优势就出来了。

• 自带 Admin 后台，订单表、商品表、用户表可以直接在后台管理，演示时不用额外写管理页面。
• ORM 层做复杂查询很顺手，按日期聚合、按商品分组统计这类操作比写原生 SQL 更安全，也更好展示给老师看。
• 自带模板引擎，配合 Django REST Framework 可以同时支撑服务端渲染页面和前端 Ajax 请求。
• 用户认证、CSRF 防护、分页组件都是现成的，省去自己造轮子的时间。

有同学担心 Django “太重”，其实在电商订单可视化这个业务场景里，重量反而变成了优点——项目结构清晰，每写完一个模块都能对应到框架的一个标准部分，答辩时可以很自然地说“这里用了 Django 的 Class-Based View，那边借用了 ORM 的 annotate 做聚合”。这套话术，老师爱听。

1.2 可视化方案选型：为什么核心图表用 ECharts

可视化渲染方案市面上主流的几个我都有试过，简单对比一下就知道为什么最终推荐 ECharts。

ECharts 在电商订单分析里最实用的几个点：

1. 折线图 + 柱状图混合展示每日订单量和销售额趋势，视觉直观，答辩加分。
2. 饼图 / 环形图展示商品类目销售占比，几乎零学习成本。
3. **数据缩放组件（dataZoom）**直接支持在图表中拖拽查看某个时间段，这个功能在展示 365 天订单走势时尤其好用。
4. 异步加载：通过 Ajax 从后端接口拿 JSON 数据，动态 setOption，和 Django REST Framework 配合非常顺。

我不建议在这个项目里强行用 D3.js，它的学习曲线会严重挤压你做数据分析和大模型集成的时间，而毕业设计考察的是“完整度”和“分析深度”，不是炫技。

1.3 大模型、Agent 在项目里的角色定位

2025 年了，数据可视化项目如果一点 AI 能力都不沾，答辩竞争力会弱不少。但也不能为了蹭热点而乱接大模型。这个项目里大模型承担两个非常明确的职责：

1. 自然语言转查询：用户输入“上个月销售额最高的商品是什么”，Agent 组件负责解析语义、生成 Django ORM 查询代码或 SQL，返回结果并自动渲染成图表。
2. 智能归因分析：当某个指标出现异常波动（比如订单量突然下跌 20%），大模型结合订单数据和商品数据给出可能的归因方向，比如“某商品库存不足导致下架”或“促销活动结束”。

这里我建议用大模型 API 而不是本地部署大模型。原因是本地部署需要显卡资源，而且把几十 GB 的模型跑起来之后，你们实验室或笔记本的风扇会教你做人。用 API 的好处是：

• 不占用本地资源，系统其余部分运行流畅。
• API 输出质量通常高于本地小模型，尤其在 SQL 生成和归因分析场景。
• 可以随时切换不同模型供应商，不会被某一个平台的限制绑死。

Agent 的设计上，我推荐用一个简化的 ReAct 风格结构：意图识别 → 工具调用（查数据库） → 结果解释 → 图表渲染。后面第六章我会把完整流程展开讲。

2. 数据库设计与数据处理链路拆解

2.1 订单相关模型怎么设计才合理

很多毕业设计的一号坑位就是数据表设计得过于简陋，一张 Order 表里恨不得塞进所有字段。你要记住一个原则：表结构设计是为了分析服务的，不是为了存数据服务的。电商订单分析系统至少要有四张核心表：

users 用户表 products 商品表 orders 订单表 order_items 订单明细表

Django 里 models.py 的建议结构如下：

from django.db import models from django.contrib.auth.models import User class Category(models.Model): name = models.CharField(max_length=50, verbose_name="类目名称") parent = models.ForeignKey("self", null=True, blank=True, on_delete=models.CASCADE) class Product(models.Model): name = models.CharField(max_length=200, verbose_name="商品名称") category = models.ForeignKey(Category, on_delete=models.CASCADE) price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="售价") cost = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="成本") stock = models.IntegerField(default=0, verbose_name="库存") class Order(models.Model): order_no = models.CharField(max_length=64, unique=True, verbose_name="订单号") user = models.ForeignKey(User, on_delete=models.CASCADE) status = models.CharField(max_length=20, verbose_name="订单状态") total_amount = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="订单金额") pay_time = models.DateTimeField(null=True, blank=True, verbose_name="支付时间") created_at = models.DateTimeField(auto_now_add=True, verbose_name="下单时间") class OrderItem(models.Model): order = models.ForeignKey(Order, related_name="items", on_delete=models.CASCADE) product = models.ForeignKey(Product, on_delete=models.CASCADE) quantity = models.IntegerField(verbose_name="购买数量") price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="成交单价")

几点经验之谈：

1. Order和OrderItem必须拆成两张表。一个用户可能购买多件商品，一件商品也可能出现在多个订单里，这是典型的一对多关系。如果强行塞在同一张表，聚合查询会痛苦到怀疑人生。
2. total_amount要在下单时就算好并冗余存储。不要指望每次展示都sum(quantity * price)，性能扛不住，逻辑也容易出问题。
3. 状态字段不要用数字 0/1/2，用字符串更直观。write 代码时判断起来舒服，别人读你的代码也舒服。
4. 订单量不大的情况下，user = models.ForeignKey(User, ...)直接用 Django 自带用户模型没问题，不要过度设计。

2.2 订单数据的清洗与预处理：哪些字段最容易被忽略

数据库里的原始订单数据肯定不能直接用，典型问题包括：支付时间为空（用户下单了但没付款）、订单状态重复、商品类目名称前后不一致（比如“手机”和“智能手机”其实是同一个类目）。我建议在 Django 里用management command做数据清洗，而不是写一次性脚本之后就不管了。

python manage.py clean_orders

自定义命令的核心步骤：

1. 剔除支付时间为空的记录，或标记为“未支付” 2. 统一状态字段枚举值，例如 pending / paid / shipped / completed / cancelled 3. 商品类目归一化，用正则或映射表处理同义词 4. 校验金额，确保订单总金额等于明细金额之和 5. 异常数据单独导出到 exceptions.csv，方便追溯

有一个非常隐蔽的坑：时区问题。Django 开启USE_TZ = True之后，数据库里存的是 UTC 时间，如果你的线上用户都在中国，直接按日期分组统计会发现在每天 8 点前的订单被算到前一天去了。解决方法是：

from django.db.models.functions import TruncDate from django.db.models import Sum from django.utils import timezone # 将 UTC 时间转换为北京时间再截断到日期 order_daily = ( Order.objects .filter(status="paid") .annotate( local_date=TruncDate( timezone.localtime(TruncDate("pay_time")) ) ) .values("local_date") .annotate(total=Sum("total_amount")) )

实际开发中更稳妥的做法是处理时，统一使用固定偏移，或者干脆关闭 USE_TZ，仅用本地时间存储。毕业设计演示场景，时间一致性比“国际化标准”重要得多。

2.3 数据分析的核心维度与指标设计

数据可视化不能只局限于“看图表”。一个合格的电商订单分析系统至少要覆盖下面几个维度，每个维度都需要计算对应的核心指标。

• 订单趋势分析：按日/周/月统计订单量和销售金额，观察整体走势、环比增长率、同比变化。
• 商品销售分析：按商品维度统计销量、销售额、毛利率，并计算 Top N 爆款商品。
• 类目结构分析：各品类销售额占比、类目下商品数量分布。
• 用户行为分析：用户订单频次、客单价、复购率、新老用户占比。
• 区域分布分析：基于用户收货地址统计地区销售分布，用地图或柱状图展示。
• 支付与履约分析：未支付订单占比、配送时长分布、取消订单原因统计。

关于指标定义，有一个容易出错的地方：销售额是含税还是不含税？做毕业设计可以简化处理，但要在文档里写清楚。我更推荐统一使用“实付金额”来统计，即剔除退款和取消订单后的实际收入。后面所有图表都基于同一套口径，不然会出现折线图上升但柱状图下降的矛盾结果，答辩时会被当场抓住。

3. 可视化看板与后端接口的完整实现

3.1 Django REST Framework 接口怎么给前端喂数据

可视化页面的数据来源我统一走 DRF 的 API 接口，和前端页面完全解耦。这样做的好处是同一个接口，网页看板能用，大模型 Agent 也能用，未来如果要写小程序/App，后端一行不用改。

一个典型的订单趋势接口实现如下：

# views.py from rest_framework.views import APIView from rest_framework.response import Response from django.db.models.functions import TruncDate from django.db.models import Sum, Count from .models import Order class OrderTrendAPIView(APIView): def get(self, request, format=None): # 按天聚合订单量和成交金额 daily_data = ( Order.objects .filter(status="paid") .annotate(day=TruncDate("pay_time")) .values("day") .annotate( order_count=Count("id"), total_sales=Sum("total_amount") ) .order_by("day") ) days = [] order_counts = [] sales_amounts = [] for item in daily_data: days.append(item["day"].strftime("%Y-%m-%d")) order_counts.append(item["order_count"]) sales_amounts.append(float(item["total_sales"])) return Response({ "days": days, "order_counts": order_counts, "sales_amounts": sales_amounts })

注意三个细节：

1. TruncDate("pay_time")可以截断到天，但类型是datetime.date，转 JSON 前需要strftime格式化，否则前端拿到的时间不好处理。
2. float(item["total_sales"])必须做类型转换。Django 的DecimalField聚合出来是Decimal类型，Django REST Framework 序列化时会出幺蛾子，手动转成 float 最保险。
3. 接口地址用名词复数，如/api/orders/trend/，不要用动词，保持 RESTful 风格。

3.2 ECharts 动态渲染订单趋势看板

前端我推荐用原生 HTML + JavaScript，尽量减少框架依赖。加载 ECharts 的方式直接走 CDN，不能联网演示的话可以下载 echarts.min.js 放到 static 目录。

订单趋势图的核心逻辑：

fetch("/api/orders/trend/") .then(response => response.json()) .then(data => { var myChart = echarts.init(document.getElementById("trendChart")); var option = { tooltip: { trigger: "axis" }, legend: { data: ["订单量", "销售额"] }, grid: { left: "10%", right: "5%", top: "15%", bottom: "10%" }, toolbox: { feature: { dataZoom: { show: true }, saveAsImage: { show: true } } }, dataZoom: [ { type: "inside", start: 0, end: 100 }, { type: "slider", start: 0, end: 100 } ], xAxis: { type: "category", data: data.days }, yAxis: [ { type: "value", name: "订单量" }, { type: "value", name: "销售额" } ], series: [ { name: "订单量", type: "line", smooth: true, data: data.order_counts }, { name: "销售额", type: "bar", yAxisIndex: 1, data: data.sales_amounts } ] }; myChart.setOption(option); window.addEventListener("resize", () => myChart.resize()); });

几个提升演示效果的小技巧：

• 双 Y 轴刻度一定要分开，订单量和销售额根本不在同一个数量级，共用 Y 轴的话订单量那条折线会始终趴在地上。
• smooth: true让折线更平滑，视觉上更有“数据分析”的味道。
• toolbox.saveAsImage导出的图表图片可以直接粘贴到论文附录里，答辩时老师问“你的分析依据是什么”，直接甩图。

3.3 数据大屏布局的 CSS 网格方案

单一图表页面太单薄，毕业设计要往“可视化大屏”的方向靠。我用的方案是 CSS Grid 布局，不依赖任何 UI 库：

.dashboard-grid { display: grid; grid-template-columns: 1fr 1fr 1fr; grid-template-rows: auto auto; gap: 16px; padding: 16px; background: #f0f2f5; } .chart-card { background: #ffffff; border-radius: 12px; padding: 16px; box-shadow: 0 2px 8px rgba(0, 0, 0, 0.08); }

大屏布局一般可以这样分配：

原则是每个图表卡片都不要塞得太满，标题 + 图表主体 + 上下留白，大屏的高级感主要来自布局节奏，不是来自配色花哨。

4. 大模型 Agent 集成：从自然语言到 SQL

4.1 为什么要用 Agent 而不是直接调 API

很多项目接入大模型的方式非常粗暴：前端把用户问题发给后端，后端直接转发给大模型 API，再把返回文本展示到页面上。这不叫“集成大模型”，这叫“套壳”。

正确的做法是让大模型具备调用工具的能力。当用户问“最近 7 天哪个商品卖得最好”时，大模型本身并不知道数据库里有什么，它需要以下过程：

1. 识别用户意图是“查询类问题”。
2. 从数据库 Schema 中选出需要的表（orders、order_items、products）。
3. 生成 Django ORM 聚合查询代码，或直接生成 SQL。
4. 将查询结果转换为自然语言回答，例如“最近 7 天销量最高的商品是 Mini 蓝牙音箱，共售出 328 件，销售额 65272 元”。

这就是 Agent 典型的工具调用模式。我用了一个精简的流程：

用户输入 → 意图判断 → 提取参数（日期范围、指标） → 生成查询代码 → 执行查询 → 校验结果 → 生成自然语言回答 → 渲染图表

4.2 大模型生成 Django ORM 查询的安全控制

允许大模型直接生成 SQL 的最大风险是安全，比如注入攻击、访问了不该访问的表。我采用了一个折中方案：不让大模型任意生成 SQL，而是让它生成一个结构化的查询 JSON。

{ "table": "order_items", "metric": "total_sales", "group_by": "product__name", "order_by": "-total_sales", "limit": 10, "filters": { "order__status": "paid", "order__pay_time__gte": "2025-01-01" } }

后端再用一个简单的解释器来执行这个 JSON，绝对不执行大模型生成的裸 SQL：

from django.db.models import Sum from .models import OrderItem def execute_agent_query(query_json): qs = OrderItem.objects.all() filters = query_json.get("filters", {}) for key, value in filters.items(): qs = qs.filter(**{key: value}) group_by = query_json.get("group_by") metric = query_json.get("metric") result = ( qs.values(group_by) .annotate( total_sales=Sum("price") ) .order_by("-" + metric)[: query_json.get("limit", 10)] ) return list(result)

这个方案的好处非常明显：

• 大模型只需要理解 Schema 并输出 JSON，不需要理解 Django ORM 的细节，生成成功率更高。
• JSON 里每个字段都是白名单校验过的，即使模型输出错误，后端也能安全拒绝大多数情况。
• 同一套 JSON 可以用于图表渲染和自然语言回答，两端数据口径一致。

4.3 完整链路里的 Prompt 设计要点

Prompt 是这个项目的灵魂。我用过一个通用模板效果不错，大家可以直接参考：

你是一个电商数据分析助手。数据库中有以下表： - orders: 订单主表，字段包括 order_no, user_id, status, total_amount, pay_time - order_items: 订单明细表，字段包括 order_id, product_id, quantity, price - products: 商品表，字段包括 id, name, category_id, price, stock 需要你输出严格的 JSON 格式查询条件，不要输出 SQL。 要求： 1. 只使用上面的字段，禁止臆造字段名。 2. 时间条件使用 ISO 格式，如 "2025-06-01"。 3. 如果问题涉及“销售额”，使用 sum(total_amount)；涉及“销量”使用 sum(quantity)。 4. 类别归入 category_id，名称归入 product__name。 5. 只输出 JSON，不要附加解释。 用户问题：{question}

有几个调参经验：

• temperature 设为 0.1 或更低，生成查询条件不需要创造性，低温度能显著降低幻觉率。
• 给出示例（few-shot），在 Prompt 里附上两个“问题 → JSON”示例，效果比只给规则好很多。
• 超时和重试机制必须有，API 调用偶尔会超时，用openai库时要设置timeout=30和max_retries=2。

4.4 Agent 复用同一个后端接口，减少集成成本

上面说的查询 Agent 只是用于自然语言查数，电商订单可视化系统里还有一个更复杂的归因分析 Agent。当订单量在某个时间点异常下跌时，系统需要先检测偏移点，再触发 Agent 分析可能的原因。我的实现思路是：

1. 后端按日聚合订单量。
2. 用三倍标准差法找出异常点（|actual - mean| > 3 * std即视为异常）。
3. 将异常点前后的订单状态分布、商品销售变化、类目占比变化等数据拼成一个摘要文本。
4. 调用大模型 API，要求它“基于以下数据分析可能原因，采用因果归纳 + 商品维度细化”的方式输出洞察。

归因 Prompt 的示例片段：

以下是某电商平台订单量异常下降时间段的数据摘要： - 下降前7天日均订单量：1532，下降后3天日均订单量：862 - 商品销售变化：数码类下跌32%，食品类上涨5% - 未支付订单占比：从8%升至19% 请基于数据推测可能原因，并列出可验证的结论与建议，不要漫无目的地罗列。

这套流程跑下来，你就不只是在“展示数据”，而是在做真正的智能分析。答辩时这是绝对的亮点。

5. 算法优化与后端性能实测

5.1 ORM 查询的 N+1 问题怎么避免

做订单明细分析时最容易踩的坑是 N+1 查询。简单解释一下：当你循环遍历每个订单，并在循环体内再去查一次商品表，100 个订单就会产生 101 条 SQL，性能极差。

# 反面例子 orders = Order.objects.all() for order in orders: # 每循环一次查一次 OrderItem for item in order.items.all(): print(item.product.name)

正确做法是用select_related和prefetch_related：

orders = Order.objects.prefetch_related( "items__product" ).filter(status="paid")

prefetch_related会先查出所有订单，再一次性查出所有相关订单明细和商品，总共 3 条 SQL 解决所有问题。数据量达到几千条之后，这个优化能让页面响应时间从几秒降到几百毫秒。

可以用 Django Debug Toolbar 来验证你的查询次数。装完之后在页面右侧会显示执行了多少条 SQL，如果你的列表页有几十条 SQL，说明 N+1 已经出现了。

5.2 大表聚合查询选择在数据库层做还是 Python 层做

很多人有个误区：聚合逻辑全写在 Python 里，比如把所有订单循环一遍，手动累加金额。这种做法在数据量小的时候没问题，但是当你有几万条订单时，会把内存和 CPU 全部打爆。

正确做法是尽量把聚合下推到数据库层：

我实际测试过，用 ORM 聚合 10 万条订单数据的时候，数据库层聚合大概耗时 300 毫秒左右，而 Python 层循环可能要 5 秒以上，差距是数量级的。

5.3 Redis 缓存可视化接口，扛住演示现场的反复刷新

演示现场最尴尬的事是什么？你每刷新一次页面，后端都要重新计算一次全量聚合，老师一边问问题你一边等页面转圈。

解决方案：把高频统计接口加入 Redis 缓存。在 Django 里的实现非常简单：

from django.core.cache import cache class OrderTrendAPIView(APIView): def get(self, request, format=None): cache_key = "order_trend_daily_2025" cached_data = cache.get(cache_key) if cached_data is not None: return Response(cached_data) # 原有聚合逻辑 compute_data() data = compute_data() cache.set(cache_key, data, timeout=60 * 5) return Response(data)

缓存有效期我设为 5 分钟，因为实际项目中数据几乎不会每分钟变化，就算变了，5 分钟后也能自动更新。演示的时候你甚至可以提前把图表打开，然后不断切换 tab 展示，速度非常顺畅。

5.4 数据量更大时的可扩展方向

如果你的订单数据量真的很大，比如几十万几百万级，Django ORM 的常规聚合还是会吃力。可以考虑两个方向：

1. 预聚合表：每天凌晨用脚本把前一天的统计数据计算好，存到 summary 表里，查询时只读 summary 表。
2. 改用 ClickHouse / Doris 这类列式数据库：架构上把 Django ORM 的读操作分流到数据仓库，分析查询性能提升是数量级的。不过这个对毕业设计来说过于重了，写进“未来展望”章节供讨论即可。

6. 实操部署与疑难杂症速查手册

6.1 本地环境搭建、依赖安装与项目初始化

基础环境需要 Python 3.10+、Django 4.2+（建议 4.2 LTS）、MySQL 5.7+ 或 SQLite（默认）。但我想强调一点，别用 Python 3.7 或更老的版本，Django 新版本已经不再支持，第三方库的兼容性也会不断出问题。

我建议依赖管理直接上requirements.txt：

django==4.2.7 djangorestframework==3.14.0 pandas==2.0.3 pymysql==1.0.2 redis==4.5.4 openai==1.3.0 python-dateutil==2.8.2

创建完虚拟环境后按下面四步走：

pip install -r requirements.txt python manage.py startapp orders python manage.py startapp dashboard python manage.py startapp ai_agent python manage.py makemigrations python manage.py migrate python manage.py createsuperuser

这四步做完，你已经有一个能跑的 Django 项目了。接下来再执行自定义清洗命令导入订单数据：

python manage.py clean_orders python manage.py import_orders --path ./data/orders.csv

6.2 开发时最常见的五个问题

我把近两年带学生做这个项目时遇到的高频问题整理成了一张速查表，你们先收藏，遇到问题直接对号入座。

有一个隐藏很深的坑：本地开发用的 SQLite 换成 MySQL 后，字段类型和聚合函数的语法有差异，比如TruncDate在 SQLite 里支持良好，但在某些 MySQL 版本上会出现奇怪的报错。建议尽早就在 MySQL 上开发，别等最后部署时才换数据库。

6.3 展示环境的部署与小屏适配

毕业设计答辩通常是自带笔记本，但如果要在服务器上部署，我推荐最轻量的方式：

1. Nginx 托管静态文件和反向代理。
2. Gunicorn 启动 Django 应用。
3. MySQL + Redis 各自独立容器。

Nginx 关键配置片段：

server { listen 80; server_name your-server-ip; location /static/ { alias /var/www/yourproject/static/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

大家注意一点：Django 的DEBUG = False时静态文件不会自动由 Django 提供，必须在settings.py里正确配置STATIC_ROOT，并执行：

python manage.py collectstatic

6.4 答辩演示时的数据与节奏建议

项目技术全做完之后，剩下的一关就是演示。数据量太小，看板光秃秃不好看；数据量太大，加载慢。建议的做法是用 Python 脚本生成 3 万条左右的模拟订单数据，覆盖近一年时间跨度。

模拟数据要包含的特点：

• 有明显的高峰期（比如某平台的 618、双 11 前后），方便展示趋势波动。
• 有 3 到 5 个爆款商品，集中贡献 30% 以上的销售额，图表结构更清晰。
• 有部分未支付和取消订单，这样各类分析维度才有对比价值。

演示顺序推荐：

不要一上来就讲代码，先让老师看到完整效果，引起兴趣后再深入细节。

6.5 关键遗留问题与扩展思路

这个项目还有一个值得考虑的方向：多 Agent 协作。目前只有一个查询 Agent 和一个归因分析 Agent，未来可以拆分出更多子 Agent，比如“数据更新 Agent 负责同步订单数据”，“报告生成 Agent 负责定期输出销售日报”，“异常检测 Agent 实时监控关键指标”。每个 Agent 各自聚焦一件事，通过一个协调器统一调度，这就是更复杂的智能数据分析平台了。

再有一个方向是把静态图表升级为交互式钻取分析。用户点击柱状图中的一个柱子，可以继续下钻查看该日期每个类目的销售明细，再点击类目可以查看具体商品列表。ECharts 的events.on("click")完全支持这种交互，实现也不难，但从演示效果上看非常加分。

7. 写在最后的几点真实体会

前前后后帮人调过不少次类似的电商数据分析系统，有一个体会特别深：大多数项目不是死在技术难，而是死在“数据整合不起来”。要么订单数据在数据库里没打通，要么可视化页面和后端接口各写各的，要么大模型 Agent 只是demo版，无法真正从数据库拉数据。所以这个项目最值得花时间的地方，是把数据链路彻底理顺，订单从清洗入库到聚合接口到前端渲染到 AI 分析，整条链路走通之后，后面往上加什么功能都很快。

还有一个建议，别把大量时间花在调 CSS 样式上，一个干净整洁的看板足够应付答辩，把节省下来的时间用来做 Agent 提示词优化，或者多做几个分析维度，性价比高得多。数据分析和 AI 能力才是这个项目的真正卖点，也是大家后面学习和求职最容易直接用上的技能。希望这篇拆解对你有帮助，如果你也在做类似的项目，欢迎留言交流实际踩坑。