每年毕业设计选题里“基于Mysql的商业辅助决策系统”基本上属于“常青树”级别的题目答辩现场十个人里能遇到两三个。但有意思的是这个题目的通过率并没有想象中高。原因很统一太多人把“辅助决策”做成了“增删改查”论文写得像软件使用说明书PPT放一堆截图演示视频就是点几个菜单。导师想看的分析逻辑、数据模型、决策场景全都没体现出来。这篇文章我打算把这个毕设课题从需求定位、数据库建模、SQL决策分析、可视化报表、论文与PPT结构、演示视频录制这些环节完整地捋一遍。项目本身不需要多高深的技术但每一步都有容易踩的坑按着下面的思路走至少能保证系统功能像样、论文有内容可写、答辩能讲清楚。1. 题目定位先搞清楚“辅助决策”和普通管理系统的分水岭1.1 辅助决策系统的经典功能模块很多同学拿到这个题目第一反应是做个后台管理系统加上商品管理、订单管理、客户管理然后写个登录注册就交差了。这是认知上的最大误区。“商业辅助决策”和“业务管理系统”的区别核心在数据的使用方向。管理系统解决的是“录入和维护”问题决策系统解决的是“分析和判断”问题。换句话说系统里存的数据不是目的把这些数据变成有说服力的指标和趋势才是决策系统的价值所在。一个合格的商业辅助决策系统至少要覆盖下面几类场景销售趋势分析按月份、季度、年度统计销售额、订单量、毛利率看趋势是上升还是下降。商品结构分析哪些品类贡献了主要收入哪些商品是滞销品库存周转是否健康。客户价值分析高价值客户是谁沉默客户有多少哪些客户具备唤醒潜力。同比环比对比本月和上月比今年和去年同期比涨跌幅度是多少。预警提醒库存低于安全线、连续多月滞销、客户流失率异常系统能主动提示。把这些场景抽象成功能菜单系统的骨架就出来了登录模块、数据看板主页、销售分析模块、商品分析模块、客户分析模块、库存预警模块、以及基础数据管理模块。基础数据管理模块保留简单的增删改查能力目的是让用户能维护商品和订单数据其余的精力都应该放到分析模块上。1.2 为什么这个课题最适合用MySQLMySQL在这个题目里几乎是一张安全牌。数据库选型要支撑的范围包括关系型数据存储、复杂的聚合查询、存储过程辅助自动化、以及和前端报表的数据联通。MySQL在大部分毕设场景里都够用而且有几个明显优势安装和部署成本低Windows和Linux都能跑Navicat、DBeaver等客户端工具成熟。导师熟悉度高。论文评审时MySQL的关系模型、SQL查询可以被直接审查如果是非关系型数据库反而容易在答辩时被追问到答不上来。资料极为丰富遇到报错随手能搜到解决方案不用担心卡在环境上。版权免费学校服务器部署没有风险。有些同学想用SQL Server或Oracle可以做但在毕设这个周期里没有必要。MySQL的窗口函数、视图、存储过程、事件调度器这些能力已经足够支撑决策分析场景。更重要的是数据分析逻辑可以用标准SQL表达出来论文中写SQL分析过程非常直观这也是评分的关键点。1.3 技术栈选择建议Java系、Python系还是纯前端方案这里给出三种可选路线各有适合的场景技术路线后端框架前端方案适用情况Java主流路线Spring BootVue ECharts时间充足打算找工作想走Java方向Python轻量路线Flask/FastAPIECharts或Grafana时间紧张快速出效果论文偏数据可视化前后端一体JSP/ServletBootstrap ECharts学校要求低只有一个月熟悉JSP我的建议是如果你还有两个月以上时间优先选Spring Boot Vue。这个组合在求职简历上也有用而且源码结构清晰论文写“前后端分离架构”会显得专业。如果只剩一个月左右就不要硬撑Java用Flask写几个数据接口前端套一个AdminLTE或者纯HTML调ECharts完成度反而更高。关键点是别在答辩前两周才开始写代码。这个题目的本质是数据建模和SQL分析代码量并不多但造数、调报表、录视频、写论文每一项都要花时间。先定技术栈再排进度才不会到最后手忙脚乱。2. 数据库设计是整个项目的承重墙别把表建得又散又乱2.1 以“销售分析”为核心的事实表和维度表设计商业决策系统的数据模型建议直接参考数据仓库的“星型模型”思路。中心是一张或多张事实表周围是维度表。这样做的好处是查询汇总时连接关系清晰统计报表的性能好而且论文里的E-R图会非常漂亮。实践中最常用的表结构可以按下面的方式设计商品维度表 product字段名类型说明product_idint PK商品IDproduct_namevarchar(100)商品名称categoryvarchar(50)一级分类sub_categoryvarchar(50)二级分类unit_pricedecimal(10,2)零售价cost_pricedecimal(10,2)成本价stock_quantityint当前库存statustinyint状态1上架 0下架客户维度表 customer字段名类型说明customer_idint PK客户IDcustomer_namevarchar(50)客户名称或昵称customer_levelvarchar(20)客户等级普通/银牌/金牌regionvarchar(50)所在地区phonevarchar(20)联系方式created_timedatetime注册时间销售事实表 sales_order字段名类型说明order_idint PK订单IDorder_novarchar(30)订单编号customer_idintFK关联客户IDproduct_idintFK关联商品IDorder_datedatetime下单时间quantityint销售数量sale_amountdecimal(10,2)成交金额cost_amountdecimal(10,2)成本金额profit_amountdecimal(10,2)利润金额冗余字段便于统计pay_statustinyint支付状态这种结构里事实表存“一笔订单里的一种商品”每个订单多行维度表存描述性信息。统计某段时间销售额时直接对 sales_order 做汇总即可。利润字段在录入订单时就算好存进去避免每条SQL都实时算成本演示时报表速度会快很多。表之间不需要过度规范化不要拆出十几张互相外键关联的小表。决策系统的查询复杂度本来就高连接过多必然拖慢性能也会把论文篇幅浪费在无意义的关系描述上。2.2 为什么我建议单独建一张日汇总表很多同学会直接对订单明细表sales_order做所有统计。数据量小的时候没问题但如果你演示时造了五万条以上订单数据每次打开首页看趋势图都要实时扫描全表页面能卡到怀疑人生。我的做法是额外建一张日汇总表作为查询的“加速层”CREATE TABLE daily_sales_summary ( id INT PRIMARY KEY AUTO_INCREMENT, stat_date DATE NOT NULL, category VARCHAR(50) DEFAULT 全部, product_id INT DEFAULT NULL, order_count INT DEFAULT 0, total_quantity INT DEFAULT 0, total_amount DECIMAL(12,2) DEFAULT 0, total_profit DECIMAL(12,2) DEFAULT 0, UNIQUE KEY uk_date_cat (stat_date, category) );报表页面的趋势图、环比、品类占比等查询优先从日汇总表取数只有下钻到具体商品或订单时才会碰明细表。这样的设计在答辩时可以说“系统采用分层数据模型通过预聚合提高决策查询的响应速度。”这个表达在论文里属于很大的加分项而且实现成本很低。注意一个细节日汇总表需要在造数之后、演示之前跑一次初始化。建议写一个存储过程用于刷新汇总数据后面第3章会给出示例。2.3 造数脚本没有真实业务数据时怎么生成演示数据这是毕设最容易忽视的地方。有些同学设计的系统逻辑没问题但为了省事只在库里手工插了二十几条订单结果图表拉出来是一条直线加几个孤零零的点根本没有“决策分析”的视觉效果。反过来也有同学随机生成了几万条数据但时间分布完全均匀趋势图就是个平底锅同样没有说服力。正确做法是用存储过程生成模拟数据并且在生成时间上加入“趋势规律”。比如设定销售基准线从2023年1月到2024年6月总体呈现缓慢上升趋势中间夹杂淡旺季波动和少量随机噪声。这样折线图才有起伏同比环比才有分析价值。下面给出一个造数存储过程的简化思路可以直接改成自己的表名和字段DELIMITER // CREATE PROCEDURE generate_sales_data(IN days_count INT) BEGIN DECLARE i INT DEFAULT 0; DECLARE current_date DATE; DECLARE base_amount DECIMAL(10,2); DECLARE customer_id_tmp INT; DECLARE product_id_tmp INT; DECLARE qty_tmp INT; DECLARE price_tmp DECIMAL(10,2); WHILE i days_count DO SET current_date DATE_SUB(CURDATE(), INTERVAL days_count - i DAY); -- 以 base_amount 为基准加入月度周期波动和随机浮动 SET base_amount 5000 800 * SIN(i / 30.0) RAND() * 1000; SET product_id_tmp 1 FLOOR(RAND() * 30); SET qty_tmp 1 FLOOR(RAND() * 5); SET price_tmp 20 RAND() * 200; INSERT INTO sales_order( order_no, customer_id, product_id, order_date, quantity, sale_amount, cost_amount, profit_amount, pay_status ) VALUES ( CONCAT(SO, DATE_FORMAT(current_date,%Y%m%d), -, LPAD(i,6,0)), 1 FLOOR(RAND() * 200), product_id_tmp, current_date, qty_tmp, price_tmp * qty_tmp, price_tmp * qty_tmp * 0.6, price_tmp * qty_tmp * 0.4, 1 ); SET i i 1; END WHILE; END// DELIMITER ;这个脚本里用了RAND()生成随机数用SIN(i / 30.0)制造月度周期波动整体效果已经能做出“有明显趋势但不完全规律”的曲线。造数时还可以顺便把客户注册时间、商品库存值一起调整保证各表数据逻辑一致。比如库存如果全是一样的数字那预警模块一打开所有商品同时报警看起来会非常假。3. 把决策逻辑翻译成SQL这才是论文的核心素材3.1 同比和环比用一张查询把指标算清楚决策系统里最常挂在嘴边的指标就是同比、环比。所谓环比是和上一个统计周期比所谓同比是和去年同一个周期比。用SQL实现很简单但很多同学的SQL只是把两条查询的日期区间写死页面换一个年份就失去作用那就不能说“支持动态查询”。实际开发时推荐做成存储过程或视图把统计周期作为参数传入。以月度汇总为例SELECT DATE_FORMAT(order_date, %Y-%m) AS month, SUM(sale_amount) AS month_sales, SUM(quantity) AS month_quantity FROM sales_order WHERE order_date 2024-01-01 AND order_date 2025-01-01 GROUP BY DATE_FORMAT(order_date, %Y-%m) ORDER BY month;要在这个基础上算环比可以用 MySQL 8.0 的窗口函数LAG()WITH monthly AS ( SELECT DATE_FORMAT(order_date, %Y-%m) AS month, SUM(sale_amount) AS month_sales FROM sales_order WHERE order_date DATE_SUB(CURDATE(), INTERVAL 12 MONTH) GROUP BY DATE_FORMAT(order_date, %Y-%m) ) SELECT month, month_sales, LAG(month_sales, 1) OVER (ORDER BY month) AS last_month_sales, ROUND( (month_sales - LAG(month_sales, 1) OVER (ORDER BY month)) / LAG(month_sales, 1) OVER (ORDER BY month) * 100, 2 ) AS mom_rate FROM monthly;这里LAG()函数负责把上一行的销售额挪到当前行方便直接算增减率。同比逻辑相同只要把窗口函数的1改成12就变成与去年同期对比。这种SQL写法放到论文里完全能站住脚答辩时也容易解释一条SQL同时完成分组、排序、错位取值、计算比率四个动作。前端页面不需要写复杂的SQL后端把结果以JSON格式返回即可报表展示和SQL逻辑各司其职。3.2 销售排行与ABC分类累计占比怎么算商品销售分析里最常用的方法是帕累托分析也就是“20%商品贡献80%销售额”通常称为ABC分类。决策者关心的是哪些商品属于A类需要重点保障库存哪些商品属于C类需要控制采购量甚至淘汰。实现思路是先按商品聚合出总销售额再计算每个商品销售额在全部商品中的累计占比。MySQL 8.0 的窗口函数让这件事变得很简单WITH product_sales AS ( SELECT product_id, SUM(sale_amount) AS total_sales FROM sales_order GROUP BY product_id ), ranked AS ( SELECT product_id, total_sales, SUM(total_sales) OVER (ORDER BY total_sales DESC) AS cumulative_sales, SUM(total_sales) OVER () AS all_sales FROM product_sales ) SELECT product_id, total_sales, ROUND(cumulative_sales / all_sales * 100, 2) AS cumulative_percent, CASE WHEN cumulative_sales / all_sales 0.7 THEN A WHEN cumulative_sales / all_sales 0.9 THEN B ELSE C END AS abc_class FROM ranked ORDER BY total_sales DESC;注意SUM(...) OVER (ORDER BY total_sales DESC)是累计求和窗口第一行是自身销售额第二行是第一行加第二行这样计算出来的就是“累计占比”。分类阈值可以根据需要调整不一定非得是70和90。把这个结果渲染成柱状图加平滑曲线就是标准的帕累托图放在系统首页分析模块里非常抓眼球。3.3 客户价值分组简化版RFM分析也能出彩客户分析模块如果只做“客户列表查询”那又回到了管理系统的老路。想要体现决策价值可以做一个简化版的RFM客户分层R代表最近一次消费时间F代表消费频次M代表消费金额。完整RFM需要对每个客户打三个分数然后组合成8个客群。毕设阶段可以简化成两个维度比如把客户按“最近30天内是否有下单”和“累计消费金额是否超均值”分成四类SELECT customer_id, CASE WHEN last_order_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) AND total_amount avg_amount THEN 高价值活跃客户 WHEN last_order_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) AND total_amount avg_amount THEN 潜力活跃客户 WHEN last_order_date DATE_SUB(CURDATE(), INTERVAL 30 DAY) AND total_amount avg_amount THEN 高价值沉睡客户 ELSE 低频低价值客户 END AS customer_type FROM ( SELECT c.customer_id, MAX(o.order_date) AS last_order_date, SUM(o.sale_amount) AS total_amount FROM customer c LEFT JOIN sales_order o ON c.customer_id o.customer_id GROUP BY c.customer_id ) t CROSS JOIN (SELECT AVG(total_amount) AS avg_amount FROM ( SELECT SUM(sale_amount) AS total_amount FROM sales_order GROUP BY customer_id ) t2) avg_t;这个查询虽然看起来嵌套比较多但每一层都有明确含义先算每个客户的最近消费时间和累计金额再算全部客户的平均消费金额最后用 CASE 条件分层。论文里放这张分层统计表和饼图就足够证明“辅助决策”的价值了。库存预警相对更直接核心公式是“库存周转天数 当前库存 / 日均销量”。近90天日均销量可以用这段时间的销售总量除以90。当天数低于阈值时系统标红提醒补货。这套逻辑配合2.1节的商品表字段基本就是一个完整的供应链决策小模块。3.4 存储过程、视图和事件调度让分析自动化一套决策系统如果每次报表都要手动刷新汇总表演示起来会露怯。好的做法是把汇总刷新做成存储过程再用MySQL的事件调度器定时执行。刷新日汇总表的存储过程大致是这样DELIMITER // CREATE PROCEDURE refresh_daily_summary() BEGIN INSERT INTO daily_sales_summary(stat_date, category, order_count, total_quantity, total_amount, total_profit) SELECT DATE(order_date) AS stat_date, p.category, COUNT(DISTINCT order_no), SUM(s.quantity), SUM(s.sale_amount), SUM(s.profit_amount) FROM sales_order s JOIN product p ON s.product_id p.product_id WHERE pay_status 1 GROUP BY DATE(order_date), p.category ON DUPLICATE KEY UPDATE order_count VALUES(order_count), total_quantity VALUES(total_quantity), total_amount VALUES(total_amount), total_profit VALUES(total_profit); END// DELIMITER ;启用事件调度器定时执行SET GLOBAL event_scheduler ON; CREATE EVENT IF NOT EXISTS ev_daily_refresh ON SCHEDULE EVERY 1 DAY STARTS 2025-01-01 02:00:00 ON COMPLETION PRESERVE DO CALL refresh_daily_summary();论文写到这里已经很有内部逻辑了明细数据进入事实表存储过程负责预聚合事件调度实现定时刷新报表层使用汇总数据。导师看到这一套设计基本不会怀疑系统的工程含量。4. 可视化报表与前端展示别让数据烂在数据库里4.1 报表接口设计一个模块对应一组JSON接口前后端分离的思路下后端只需要提供可复用的数据接口。比如首页看板要的数据可以通过三个接口完成/api/dashboard/saleTrend返回近12个月销售额和订单量趋势/api/dashboard/categoryPie返回品类销售额占比/api/dashboard/topProducts返回销售额前10的商品列表接口返回统一使用{code, message, data}结构前端拿到data直接渲染图表。这样写论文时“系统接口设计”一节会非常清晰每个接口对应一张功能表不仅内容充实还有实际代码支撑。4.2 ECharts图表嵌入与联动前端图表推荐使用 Apache ECharts作为开源图表库它覆盖折线图、饼图、柱状图、雷达图、仪表盘等常见报表形态而且和Vue、React、原生HTML都能集成。引入方式很简单下载 echarts.min.js 放到静态目录即可。一个基础的销量趋势图示例大概长这样div idtrendChart stylewidth:100%; height:400px;/div script const chart echarts.init(document.getElementById(trendChart)); fetch(/api/dashboard/saleTrend, { headers: { token: localStorage.getItem(token) } }) .then(res res.json()) .then(res { chart.setOption({ tooltip: { trigger: axis }, legend: { data: [销售额, 订单量] }, xAxis: { type: category, data: res.data.months }, yAxis: [ { type: value, name: 销售额, axisLabel: { formatter: {value} 元 } }, { type: value, name: 订单量 } ], series: [ { name: 销售额, type: line, smooth: true, data: res.data.amounts }, { name: 订单量, type: bar, yAxisIndex: 1, data: res.data.counts } ] }); }); /script这段代码需要注意两点一是柱状图和折线图可以共用坐标系也可以各用各的yAxis双Y轴效果在答辩演示时更有冲击力二是图表数据来自后端JSON接口而不是前端写死的数组演示时可以现场切换时间范围图表实时刷新观感完全不同。ECharts生成的图表本身支持鼠标悬浮提示、缩放、导出图片等交互录视频时多展示这些细节会让系统看起来比普通静态报表“高级”很多。4.3 导出Excel和大屏展示两个性价比很高的加分项决策系统里“导出报表”几乎是刚性需求。后端可以用EasyExcel或POI实现前端也可以用xlsx库直接在浏览器生成表格。论文中写“实现了报表导出功能”虽然简单却是很多同学没做、但导师认为“应该要有”的点。导出文件时注意把文本列设置成文本格式避免商品ID在Excel中被自动转成科学计数法这个坑我见过不少次。大屏展示则是可以放在演示视频结尾的加分项。做一个1920×1080的HTML页面把销售额、订单量、品类占比、库存预警几个模块分别放在不同的div里CSSgrid布局排成看板配合ECharts自动轮播或者简单的数字翻牌动画效果一下子就上去了。大屏不需要复杂的后端逻辑数据还是来自那几个接口前端工作量大概一到两天性价比很高。5. 论文与PPT编排让导师快速看懂“两分钟汇报”5.1 论文骨架应该怎么安排毕业论文的字数要求一般在一万字到一万五千字之间。这个题目下合理的章节安排可以按下面表格来章节内容重点建议字数一、绪论研究背景、国内外现状、研究内容和方法1500二、相关技术介绍MySQL、前后端框架、ECharts、开发工具1200三、需求分析业务需求、功能需求、用户角色、用例分析2000四、系统设计总体架构、功能模块设计、数据库设计、接口设计3500五、系统实现各模块详细实现、核心代码、页面效果4000六、系统测试测试用例、测试过程、结果分析1500总结与致谢完成情况、不足与改进600这里特别要留意第三章“需求分析”和第四章“数据库设计”这两个地方是论文体现“辅助决策”定位的关键。需求分析不要通篇写“用户可以登录”要写“决策者需要查看同比环比变化趋势以判断业务增长情况”这类真实业务诉求。数据库设计不要只贴建表SQL要解释每张表解决什么分析场景比如“日汇总表用于提升大时间范围查询的响应速度”。5.2 图表和截图怎么放才显得专业论文中的图一般包括系统总体架构图、功能结构图、用例图、E-R图、数据库表关系图、核心页面截图、图表展示截图、测试用例表格。每一张图插入时都要有编号和图题正文里要有引用语句比如“如图4-3所示”。不要大量堆截图截图只是辅助关键是要有文字解释页面处理逻辑的过程。PPT的结构则更直接封面放题目和基本信息第一页用一句话讲清楚“系统做什么”、面向什么决策场景第二页放技术架构能画一张简单的分层图最好第三页展示数据库模型和核心表关系中间三到五页放运行截图和图表重点页面配合一句“这里用了什么方法”最后放测试结果和总结。PPT总数控制在12到15页就可以答辩时间通常只有5到10分钟讲太快会空讲太慢会超时。每页只放一个核心结论页面文字精简到每页不超过五行细节放到演示视频里去补充。5.3 演示视频与论文内容要能互相印证论文里的“系统实现”章节每一张核心截图都应该在演示视频里有对应操作。比如论文说“系统支持按年度切换查看销售趋势”那么视频里就必须有在页面切换年度的动作。如果只截图不演示答辩老师可能不会逐条对但如果被追问到视频里没有的功能会非常被动。所以论文初稿写完后先列出一个功能清单再逐个确认这个功能我在系统里能跑通吗我在论文里写清楚实现思路了吗演示视频里有对应画面吗三个答案都是“是”这一项才算过关。6. 演示视频的录制细节一份能打动答辩老师的“作品说明书”6.1 录制环境准备演示视频的分辨率尽量用1920×1080帧率30帧就够。屏幕内容小的话可以局部放大但不要放大到失真。录制工具可以用OBS Studio免费且稳定也可以直接在Windows系统里用录屏软件。录制前必做的准备工作包括数据库服务已经启动系统登录页面能直接访问。造数脚本已经执行演示库里有覆盖近两年的数据量。系统端口固定不要录到一半切换窗口时把地址栏暴露出来。把输入法切换成英文模式避免弹框。不要在屏幕上开无关聊天窗口保持桌面整洁。录之前至少完整走一遍流程。按下录制键之后再熟悉操作出来的视频就是不断停顿和鼠标乱晃观感很差。6.2 10分钟演示视频的脚本节奏演示视频不建议超过12分钟控制在8到10分钟比较合适。一个合理的节奏是这样时间段内容0:00-1:00展示系统登录、主界面、菜单结构1:00-3:00演示首页看板介绍销售额趋势、品类占比、核心指标卡片3:00-5:00演示销售分析模块切换年份查看同比环比结果5:00-6:30演示商品分析模块展示ABC分类结果和排行榜6:30-7:30演示客户分析和库存预警7:30-8:30展示数据库设计表结构、存储过程、事件调度器8:30-10:00展示导出功能和大屏页面数据库结构展示要放在视频后半段目的是让导师确认“系统和代码是真实可运行的”。不要一开头就放Navicat截图开头先展示系统效果才能抓住注意力。视频中不需要念PPT式的介绍词直接用操作带出功能。鼠标点击时稍微停顿半秒再操作让画面有时间跟上思考速度。遇到图表切换时可以放大当前页面配合一句“这里可以看到六月份销售额出现了明显回升”。6.3 常见翻车现场这个环节值得单独说。我看过不少学生录的演示视频功能实现了却因为细节问题掉了分。第一个翻车点是图表数据太少。整条趋势线只有三五个点柱状图稀稀拉拉一眼看出是测试数据。在造数阶段就得多花点心思至少生成两到三年的数据数量级要符合“决策分析”的感觉。第二个翻车点是录屏尺寸不对。录下来出现黑边或者缩放比例不对字都是模糊的。录完后第一遍回放检查清晰度再开始完整录。第三个翻车点是中途操作失误。点了页面跳转结果报错或弹窗没处理然后又手忙脚乱往回点。保持冷静鼠标慢慢移动如果录错了直接重新录反复剪不如一次录好。第三个翻车点在库存预警里也经常出现由于没造数所有商品库存数值相同预警规则一执行不是全部标红就是全部正常。造假数据时要把商品库存和销量关联起来热门商品库存少、销量高冷门商品库存多、销量低预警结果才会符合预期。最后再分享一个提升观感的小技巧演示前把系统里不用的菜单、无用的按钮都处理掉只保留演示时要用的功能。过分冗余的界面会干扰导师视线反而显得系统设计缺乏规划。我实际带过的学生里凡是按“定位决策需求、先设计表结构、再写SQL分析逻辑、最后做图表和视频”这个顺序推进的基本上都能在答辩前一周定稿剩下的时间用来背讲稿和打磨细节。遇到这个题目的同学建议先把数据库建模文档放在所有任务的最前面数据模型稳了后面的代码、论文、视频就都是水到渠成的事。