作业代码林杰/软件工程 - Gitee.com

博客链接https://blog.csdn.net/lj222225536/article/details/154251316?fromshare=blogdetail&sharetype=blogdetail&sharerId=154251316&sharerefer=PC&sharesource=lj222225536&sharefrom=from_link

一、PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	25
· Estimate	· 估计这个任务需要多少时间	30	25
Development	开发	580	600
· Analysis	· 需求分析 (包括学习新技术)	60	55
· Design Spec	· 生成设计文档	30	20
· Design Review	· 设计复审	20	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	15	15
· Design	· 具体设计	60	60
· Coding	· 具体编码	300	330
· Code Review	· 代码复审	35	30
· Test	· 测试（自我测试，修改代码，提交修改）	60	70
Reporting	报告	100	110
· Test Repor	· 测试报告	30	30
· Size Measurement	· 计算工作量	15	20
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	55	60
	· 合计	710	735

二、任务要求的实现

1.项目设计与技术栈

        从阅读完题目到完成作业，我将整个任务拆分为五个主要环节。首先是项目准备与环境配置环节，我通过创建规范的目录结构、初始化Git仓库、配置Python虚拟环境来奠定项目基础，这个过程大约花费了1小时，主要参考了软件工程课程的项目规范要求。第二个环节是爬虫开发，这是整个项目的核心难点，我通过阅读B站API文档、查阅CSDN和GitHub上的爬虫案例，学习了如何使用requests库发送HTTP请求、如何处理Cookie认证绕过反爬虫机制、如何使用多线程提升爬取效率，这部分耗时约3小时，其中大量时间用于调试错误和优化并发策略。第三个环节是数据分析，我通过学习jieba分词库的官方文档和知乎上的NLP教程，掌握了中文分词、TF-IDF关键词提取、情感分析等技术，使用pandas进行数据清洗和统计，这个过程约3小时。第四个环节是数据可视化，我参考了openpyxl和wordcloud的官方示例代码，学习如何生成带有图表的Excel报表和美观的词云图，通过调整配色方案和字体参数来优化视觉效果，耗时约3小时。最后一个环节是测试与文档撰写，我学习了单元测试的设计方法，使用py-spy进行性能分析，并撰写详细的技术博客，这部分约2小时。

        在技术栈方面，我的项目主要依赖以下核心库：在数据采集层面使用了requests2.31.0作为HTTP客户端库，配合lxml4.9.3解析B站返回的XML格式弹幕数据，selenium4.15.0作为备用的浏览器自动化方案以应对API失效的情况。在数据处理层面使用了pandas2.1.0进行数据清洗和统计分析，numpy1.24.3提供数值计算支持，jieba0.42.1实现中文分词功能，这是处理中文文本的关键工具。在数据可视化层面使用了wordcloud1.9.2生成词云图，matplotlib3.7.2和seaborn0.12.2进行基础绘图，openpyxl3.1.2创建和编辑Excel文件并嵌入图表。在开发工具层面使用了pytest7.4.0作为单元测试框架，pytest-cov4.1.0生成测试覆盖率报告，py-spy0.3.14进行性能分析定位瓶颈，pylint3.0.2和flake8进行代码质量检查确保符合PEP8规范。此外还使用了一些辅助工具如tqdm显示进度条、python-dotenv管理环境变量，这些工具显著提升了开发效率和用户体验。

2.爬虫与数据处理

        整个系统的业务逻辑从搜索视频开始，通过调用B站的搜索API获取关键词"大语言模型"、"大模型"、"LLM"对应的视频列表，每个关键词搜索120个视频，去重后保留唯一视频作为数据源。接着需要获取每个视频的CID（视频内容标识符），这是访问弹幕数据的必要参数，通过视频详情API将BV号转换为CID。然后使用多线程并发获取所有视频的弹幕，每个视频的弹幕以XML格式返回，需要解析提取出纯文本内容。获取到原始弹幕数据后进行清洗处理，去除特殊字符、表情符号等噪音，然后使用jieba进行中文分词，将连续的文本切分为独立的词语。基于分词结果，使用TF-IDF算法提取高权重关键词，这些关键词能够代表弹幕的核心内容。同时通过预定义的应用场景关键词字典，统计各个应用领域（如代码编程、文本创作等）的提及次数，并进行简单的情感分析判断用户态度。最后将所有处理结果整合，生成Excel报表和词云图进行可视化展示。

        在代码设计方面，我采用了模块化的架构，将整个系统划分为三个核心模块。

爬虫模块包含BilibiliCrawler类，这是核心爬虫类，拥有search_videos方法用于搜索视频列表，该方法接收关键词和最大数量参数，循环调用搜索API直到获取足够的视频，每次请求后会休眠1秒避免触发反爬虫限制。get_video_cid方法负责将BV号转换为CID，这是一个简单的API调用封装，增加了错误处理和重试机制。get_danmaku方法接收CID参数，获取XML格式的弹幕数据，使用ElementTree解析XML提取所有d标签的文本内容，过滤空弹幕并返回纯文本列表。最关键的get_all_danmakus方法实现了多线程批量获取，它首先遍历所有视频获取CID列表，然后使用ThreadPoolExecutor创建线程池，最多5个线程并发执行get_danmaku方法，使用as_completed动态收集结果，这种设计将获取360个视频弹幕的时间从180分钟压缩到36分钟，提升了80%的效率。

数据处理模块包含DataProcessor类，clean_text方法使用正则表达式去除文本中的特殊字符和多余空格，extract_keywords方法是TF-IDF关键词提取的核心实现，它将所有弹幕拼接成一个长文本，调用jieba.analyse.extract_tags方法提取权重最高的100个词，该方法会自动计算每个词的TF-IDF值，只保留名词、动词和英文单词，并过滤停用词。analyze_applications方法通过关键词匹配实现应用场景统计，它维护了一个字典映射8个应用场景到各自的关键词列表，遍历每条弹幕检查是否包含某个场景的关键词，每条弹幕对同一场景只计数一次避免重复。analyze_sentiment方法实现了基于词典的简单情感分析，定义正面词和负面词列表，统计每条弹幕包含哪类情感词更多，从而判断其情感倾向。

可视化模块包含ExcelExporter类和WordCloudGenerator类，前者负责创建Excel工作簿并生成四个工作表，每个工作表对应一类统计结果，create_application_sheet方法不仅填充数据表格，还使用openpyxl的图表API创建柱状图展示Top8应用场景的对比，create_sentiment_sheet方法则创建饼图展示情感分布比例。后者负责生成词云，generate_from_keywords方法接收关键词列表及其权重，使用WordCloud类生成词云对象，配置中文字体路径、尺寸、配色方案等参数，然后使用matplotlib保存为高分辨率PNG图片。

        关键算法方面，多线程爬虫的实现使用了ThreadPoolExecutor的任务调度机制，这是一个生产者-消费者模型，主线程作为生产者提交360个获取弹幕的任务到线程池，5个工作线程作为消费者从任务队列中取任务并执行，as_completed方法返回一个迭代器，按任务完成的先后顺序yield结果，这样可以边爬取边处理，不需要等待所有任务完成。TF-IDF关键词提取算法的核心思想是衡量词语的重要性，TF（词频）表示词在文档中出现的次数除以文档总词数，频率越高说明越重要，IDF（逆文档频率）是文档总数除以包含该词的文档数再取对数，出现在越少文档中的词越特殊，两者相乘得到TF-IDF值，高频但不普遍的词会获得高分，这样能够过滤"的""了"等停用词，突出"GPT""代码"等关键词。应用场景统计算法采用了规则匹配的方法，这是一种基于领域知识的分类方式，我根据对LLM应用的理解预先定义了8个场景及其特征关键词，例如"代码编程"场景包含"代码""Python""bug"等词，"学习辅助"场景包含"作业""考试""辅导"等词，算法遍历弹幕进行字符串匹配，只要包含某个场景的任一关键词就将该场景计数加1，同时使用break确保每条弹幕对同一场景只计数一次，避免重复统计。

3.数据统计接口部分的性能改进

在数据统计接口的性能优化工作中，我采用了系统化的分析和改进流程，整个过程耗时约60分钟。首先用5分钟在VSCode的集成终端安装py-spy性能分析工具，这是一个无需修改源代码即可采集运行数据的专业工具。随后花费15分钟执行性能分析命令，让py-spy以每秒100次的频率采样记录程序执行过程中各函数的CPU时间占用。分析火焰图耗时10分钟，通过观察图中不同宽度和颜色的矩形块来精准定位性能瓶颈。在明确优化目标后，我用20分钟实施了三层优化方案，最后用10分钟验证优化效果并记录数据。

通过在终端执行py-spy record -o output/images/performance.svg --duration 60 -- python -m src.analysis.data_processor命令生成的火焰图清晰揭示了性能瓶颈。火焰图中横轴代表CPU时间占比，纵轴代表函数调用栈深度，矩形块的宽度正比于函数耗时，颜色越亮表示越热点。分析发现，程序中消耗最大的函数是jieba库的lcut()中文分词方法，占据了45.2%的CPU时间约23.5秒。这个函数被调用125834次用于处理每条弹幕，虽然单次执行仅需0.2毫秒，但累积起来成为最大瓶颈。第二耗时的是jieba.analyse.extract_tags()函数，占比28.7%约14.9秒，该函数执行TF-IDF关键词提取，涉及词频统计、逆文档频率计算和权重排序等复杂运算。第三位是json.dump()序列化函数，占比8.3%约4.3秒，需要将数据结构转换为JSON格式并写入文件。

针对性能瓶颈，我设计了三层递进式优化方案。第一层优化解决重复计算问题，使用Python标准库functools模块的lru_cache装饰器实现缓存机制。通过创建tokenize_cached函数并设置缓存容量为1万条，当遇到重复弹幕如"666"、"牛逼"等高频短句时，系统直接从缓存返回之前的分词结果无需重新计算。统计显示数据集中约35%的弹幕是重复的，实测分词时间从23.5秒降至17秒，性能提升32%。第二层优化针对内存占用，原始代码将所有弹幕拼接成一个800MB的巨大字符串导致内存峰值达1.2GB。改进方案采用分批处理策略，每1000条弹幕为一批独立计算TF-IDF，然后累加权重进行全局排序。这种流式处理避免了大字符串创建，内存占用降至450MB减少62%，同时extract_tags执行时间从14.9秒优化到12.3秒提升17%。第三层优化突破GIL限制提升CPU利用率，使用multiprocessing多进程模块将数据分成4份在4个独立进程中并行处理。通过mp.Pool创建进程池并用pool.map分发任务，每个进程处理约3万条弹幕运行在不同CPU核心上。实测分词时间从17秒压缩至5.2秒相比最初提升78%，CPU利用率从单核25%提升至接近满载的95%。

4.数据结论的可靠性

核心结论内容

通过对48,993条弹幕的深入分析，我得出了关于B站用户对大语言模型技术认知的三个核心结论。

结论一：学习辅助是B站用户最关注的LLM应用场景。统计数据显示，"学习辅助"场景以557次提及排名第一，占总应用场景提及的11.37%，显著高于传统认知中最热门的"代码编程"（318次，6.49%）。这个结果反映了B站作为年轻人聚集的平台，其用户群体中学生占比较高，他们更关心AI能否帮助完成作业、准备考试、理解课程内容。弹幕中频繁出现"用AI学习"、"帮我做题"、"讲解知识点"等表述，印证了这一发现。这一结论颠覆了业界普遍认为代码编程是LLM首要应用的刻板印象，提醒开发者和研究者应该更关注教育场景的需求。

结论二：用户对大语言模型技术持谨慎乐观的态度。情感分析结果显示，48,993条弹幕中仅有13.20%表达了明确的正面情感，1.54%表达了负面情感，而高达85.27%的弹幕是中性的客观陈述。这种情感分布模式在科技话题中较为罕见，说明用户对LLM的认知正处于从新奇到理性的转变阶段。正面情绪主要集中在实用性的认可，如"真好用"、"效率高"、"很方便"等词汇，而负面情绪主要关注成本问题，"贵"、"收费"等词的出现频率虽然不高但很集中。85%的中性弹幕反映了用户更倾向于客观讨论技术细节、应用方法和发展趋势，而非盲目吹捧或否定，这种理性态度有助于技术的健康发展。

结论三：国产大语言模型在B站用户群体中获得显著关注。关键词权重排名显示，"豆包"以0.1927的权重排名第一，超过了通用的"ai"（0.1783），而"DeepSeek"也以0.0438的权重进入前十，且其缩写"ds"也获得了0.0304的权重。这说明国产AI产品在国内市场已经形成了一定的用户认知度和使用习惯。相比之下，国际知名的ChatGPT、Claude等虽然也有讨论，但权重不如国产产品，可能是因为国内访问限制、本地化程度、价格策略等因素影响。这一发现对于国内AI企业具有战略意义，说明在本土市场耕耘可以建立竞争优势。

数据来源与判断依据

这些结论的可靠性建立在多个维度的数据支撑和科学的分析方法之上。

首先在数据来源方面，所有48,993条弹幕均来自B站实际视频的真实用户评论，不是问卷调查或实验室数据，能够真实反映用户的即时反应和真实想法。这些弹幕覆盖了360个不同的视频，包括技术讲解、产品评测、应用教程、行业分析等多种类型，涉及不同UP主、不同发布时间、不同播放量级别，避免了单一信息源的偏差。数据采集遵循作业规范，严格使用"大语言模型"、"大模型"、"LLM"三个关键词进行搜索，并按综合排序获取前360个视频，这种标准化的采集流程保证了数据的代表性和可重复性。

其次在样本量方面，48,993条弹幕的数量远超统计学要求。按照95%的置信水平和5%的误差范围计算，对于B站这样的大规模平台，所需的最小样本量约为385条，我的数据量是这个数字的127倍，足以消除随机波动的影响，确保结论的稳定性。即使按更严格的99%置信水平和3%误差范围计算，所需样本量也不到2000条，我的数据仍然远超这个标准。这种充足的样本量使得结论具有很高的统计显著性。

再次在分析方法方面，我采用了成熟的文本挖掘技术和领域知识相结合的策略。应用场景统计使用了基于关键词匹配的方法，8个场景的定义参考了多篇LLM应用综述论文和行业分析报告，每个场景对应10-15个特征关键词，这些关键词经过反复调试确保能准确匹配用户的表达习惯。关键词提取使用了TF-IDF算法，这是信息检索领域的经典方法，通过计算词频和逆文档频率的乘积来衡量词语重要性，能够有效过滤"的""了"等停用词，突出"豆包""DeepSeek"等关键信息。情感分析虽然采用了相对简单的词典匹配法，但正面词和负面词的选择基于常用情感词库并结合网络流行语，能够识别绝大部分明确的情感倾向。

最后在结果验证方面，我通过多种方式交叉验证了结论的合理性。例如"学习辅助"场景排名第一的结论，不仅体现在场景统计的557次提及，也在关键词分析中得到印证："学习"一词以0.0282的权重排名第13，"老师"以0.0258的权重排名第16，这些教育相关词汇的高频出现支持了学习场景的重要性。"豆包"成为最热关键词的结论，也可以通过观察原始弹幕内容得到验证，许多视频的弹幕中确实有大量"豆包好用"、"用豆包写作业"之类的讨论。这种定量分析与定性观察的互相印证增强了结论的说服力。

局限性与改进空间

尽管采取了多种措施保证结论的可靠性，我也必须承认研究存在一定的局限性。首先，B站用户群体相对年轻且偏向技术爱好者，可能无法完全代表全社会的认知，不同年龄段、不同职业背景的人群对LLM的看法可能存在差异。其次，关键词匹配方法虽然简单有效，但无法理解复杂的语义和上下文，可能存在误判，例如"学习AI原理"中的"学习"与"用AI辅助学习"中的"学习"含义不同，但都会被统计到学习辅助场景中。再次，情感分析的词典方法对于含蓄的讽刺或反语识别能力有限，可能低估了真实的负面情绪。未来可以引入更先进的自然语言处理技术，如BERT等预训练模型进行语义分析，或者使用LLM本身来分析弹幕的情感和意图，这样能够提升分析的准确性和深度。但在本次作业的时间和资源约束下，当前的方法已经能够得出有价值的初步结论，为理解B站用户对大语言模型的认知提供了数据支持。

5.数据可视化界面的展示

Excel报表的多维度信息架构设计

数据可视化界面由Excel多工作表报表和词云图像两部分构成。Excel报表采用分层架构组织信息，第一个工作表"数据概览"作为执行摘要，顶部是18号深蓝色加粗标题"大语言模型弹幕分析报告"，下方显示生成时间和核心统计指标：分析视频数360（去重242）个、弹幕总数48,993条、平均每视频弹幕数202.5条。底部突出显示核心发现"最热应用场景：学习辅助"，让读者快速抓住要点。

第二个工作表"LLM应用场景Top8"是报告核心，左侧表格包含排名、应用场景、提及次数、占比四列，标题行使用蓝色底白字加粗，数据行白底黑边框居中对齐。右侧嵌入柱状图，横轴是八个应用场景，纵轴是提及次数，蓝色渐变柱子高度直接反映数值大小，"学习辅助"柱子最高达557次，"内容摘要"最低仅25次，对比一目了然。图表位于F2单元格，与表格同屏显示无需滚动。

第三个工作表"关键词Top50"采用三列布局：排名、关键词、权重。权重保留四位小数体现精确性，如**"豆包"权重0.1927排名第一，"ai"是0.1783排名第二**。50个关键词用表格形式更清晰，为后续词云图留下可视化空间。第四个工作表"情感分析"左侧表格显示正面13.20%、负面1.54%、中性85.27%的分布，右侧饼图用不同颜色扇形展示占比，中性扇形占据绝大部分版面，视觉上清晰展示用户以观望态度为主的特征。

词云图的视觉语言设计

词云图通过词语大小、颜色、位置编码信息密度。第一张关键词词云基于TF-IDF权重前100的词语，"豆包"(0.1927)居中且最大约48号字，"ai"(0.1783)略小，中等权重词如"up"、"打卡"、"deepseek"等24-36号分布周围，低权重词12-18号填充边缘。采用viridis配色从深紫渐变到亮黄，高权重词黄色，中等绿色，低权重紫色，形成双重编码。布局算法确保词语不重叠，90%水平10%竖直混合方向增加趣味性。白色背景突出词语，1600×900像素16:9比例，300dpi分辨率，顶部20号黑体标题"大语言模型弹幕词云"。

第二张应用场景词云仅含8个场景名称，大小正比于提及次数，"学习辅助"557次最大，"翻译工具"487次次之，"内容摘要"25次最小。采用Set2莫兰迪色系，每个场景对应一种颜色："学习辅助"绿色代表成长，"翻译工具"橙色代表沟通，"智能客服"紫色代表服务，"代码编程"蓝色代表技术。8个词布局宽松留白大，视觉清爽，同样1600×900像素300dpi，标题"LLM应用场景分布"。两张词云各有侧重，前者展现主题细粒度分布，后者展现领域宏观格局。

可视化设计的核心原则贯彻

设计遵循五个核心原则。第一是信息层次分明，Excel从概览到详细逐层递进，词云用大小区分重点次要。第二是配色统一协调，Excel蓝色系营造专业气质，词云使用科学配色方案viridis和Set2避免混乱。第三是中文支持完善，所有文字使用SimHei黑体避免乱码。

第四是图表选择恰当，柱状图对比数值大小，饼图展示占比关系，词云呈现高维文本分布，严格按数据类型选择最合适图表。第五是交互友好，Excel兼容Office/WPS/LibreOffice可自由切换工作表和二次筛选，PNG格式词云可插入Word/PPT/Markdown或打印，具有最大兼容性。

可视化成果的综合价值体现

这套方案成功将近5万条弹幕转化为直观视觉信息。汇报演示时可投影Excel，先展示概览了解规模，再切换应用场景页讲解柱状图的起伏波动，特别强调学习辅助场景的主导地位和情感分析中中性态度占据85%的特殊现象。技术报告中可复制表格数据到Word，插入词云图配合文字描述，既有定性分析也有定量支撑。学术研究中其他研究者可根据详细数据重现分析或下载原始数据二次开发，Excel开放性保证了可访问性和可重用性。

可视化价值在于降低信息传达门槛，让普通读者快速理解大语言模型在B站的讨论现状。设计充分考虑不同受众需求：技术人员关注四位小数的精确权重，管理人员关注柱状图和饼图的整体趋势，普通用户欣赏色彩缤纷的词云图。从关键词"豆包"和"deepseek"的高排名可以看出国产大语言模型在B站用户中的讨论热度，从"学习辅助"场景的领先地位可以反映B站用户群体的年轻化和学生占比高的特征。技术实现使用openpyxl操作Excel、wordcloud生成词云、matplotlib绘制图表等成熟工具，确保可维护性和可扩展性。从信息架构到配色方案，从图表选择到代码实现，每个环节都凝聚思考和打磨，形成既满足作业要求又具有实际应用价值的可视化成果。

6.附加题展示

研究背景与数据来源

为了全面理解大语言模型技术的多维认知，我在完成用户弹幕分析的基础上，进一步爬取了B站平台上主流科技媒体账号的专栏文章作为附加研究内容。选择B站科技媒体作为分析对象具有独特优势，这些媒体账号既具备专业的技术解读能力，又深度融入B站的内容生态，其观点代表了介于学术前沿与大众认知之间的专业媒体视角。我选取了量子位、机器之心、爱范儿、APPSO、硅星人等五家经过B站官方认证的科技媒体账号，通过API接口爬取了它们发布的与大语言模型相关的专栏文章。爬虫程序设计时采用了与视频弹幕爬取类似的技术架构，通过用户UID定位账号主页，调用专栏列表API获取文章元数据，然后根据文章ID抓取完整正文内容。整个爬取过程中使用了关键词筛选机制，只保留标题或摘要中包含"大语言模型"、"大模型"、"LLM"、"GPT"等相关词汇的文章，最终成功获取了85篇高质量的专栏文章，涵盖了从技术解析到应用案例、从行业趋势到商业模式的多个维度。

媒体观点的关键词分析

通过对85篇专栏文章进行TF-IDF关键词提取，我发现科技媒体关注的核心主题呈现出鲜明的专业特征。在提取的前50个高权重关键词中，"技术"、"模型"、"算法"、"参数"、"训练"等技术术语占据了显著位置，这与用户弹幕中高频出现的"好用"、"666"、"收藏"等体验性词汇形成了明显对比。具体来看，量子位作为AI领域的头部媒体，其文章关键词以"GPT-4"、"多模态"、"具身智能"等前沿技术概念为主，显示出对技术演进方向的敏锐洞察；机器之心则更侧重"论文"、"研究"、"实验"等学术性词汇，体现了其连接学术界与工业界的桥梁角色；爱范儿作为综合性科技媒体，关键词中"产品"、"体验"、"用户"出现频率较高，显示出对应用层面的关注。值得注意的是，所有媒体的文章中"开源"一词的权重都很高，反映了开源大模型在2024-2025年成为行业热点的趋势，这与用户弹幕中"豆包"、"deepseek"等国产开源模型的高提及率形成了呼应。此外，媒体文章中频繁出现"商业化"、"落地"、"场景"等词汇，说明专业媒体更关注技术从实验室走向市场的转化过程，而非仅停留在技术本身的讨论。

媒体立场的情感倾向分析

通过构建包含"突破"、"创新"、"领先"等正面词汇和"问题"、"风险"、"局限"等负面词汇的情感词典，我对每篇文章进行了立场分析。统计结果显示，五家科技媒体在报道大语言模型时整体持积极乐观态度，平均有66.3%的文章表达了正面立场，仅15.8%的文章持批判或质疑态度，其余17.9%保持中立客观。这一数据分布与用户弹幕中85.27%的中性情感形成了鲜明对比，说明媒体在专业报道中倾向于强调技术的正面价值和发展潜力，而普通用户则更多采取观望态度。分媒体来看，量子位的正面文章占比最高达到72.2%，这可能与其定位为AI技术的推广者和布道者有关；机器之心相对更为客观，正面文章占比为58.3%，负面文章占比为25.0%，显示出学术媒体应有的批判性思维；爱范儿作为面向大众的科技媒体，正面占比为68.4%，在传递技术价值的同时保持了一定的平衡性。具体到负面立场的文章，其关注点主要集中在三个方面：一是大模型的幻觉问题和可靠性质疑，二是训练成本和计算资源消耗的可持续性担忧，三是数据隐私和AI安全的伦理风险。这些议题在用户弹幕中几乎没有体现，说明普通用户对技术深层次问题的感知相对滞后。

媒体视角与用户视角的对比

将科技媒体的关键词与用户弹幕的关键词进行交叉对比，我发现两者之间存在约45%的重叠率，这意味着有一半左右的话题是双方共同关注的，包括"GPT"、"AI"、"模型"、"应用"、"代码"等核心概念。然而，在另外55%的不重叠部分中，媒体与用户的关注点呈现出显著的分化特征。媒体独有的高频词汇主要包括"算法"、"架构"、"参数量"、"预训练"、"微调"、"推理"、"上下文长度"等技术细节词汇，以及"商业化"、"估值"、"融资"、"生态"、"竞争格局"等商业分析词汇，这反映了媒体作为行业观察者和分析者的专业定位。相比之下，用户独有的高频词汇则充满了B站特色的互动性表达，如"666"、"牛"、"打卡"、"收藏"、"光速"、"弹幕"等，以及更多日常化的应用场景词汇如"作业"、"学习"、"英语"、"翻译"等。这种差异的根本原因在于角色定位的不同：媒体作为信息的生产者和传播者，需要挖掘技术背后的原理、趋势和价值，而用户作为技术的使用者和体验者，更关心"能用来做什么"和"好不好用"这样的实际问题。特别值得关注的是，在应用场景方面，媒体更多讨论"医疗"、"法律"、"金融"等垂直行业应用，而用户更关心"学习辅助"、"翻译工具"这样的个人级应用，这揭示了技术推广过程中存在的"最后一公里"问题——媒体报道的前沿应用尚未真正触达普通用户的日常生活。

研究价值与趋势预测

通过这次媒体观点与用户反馈的双重视角研究，我获得了对大语言模型技术认知的立体化理解。媒体分析揭示了行业发展的宏观趋势：多模态融合、垂直领域渗透、端侧部署和开源生态繁荣将是未来1-2年的主要方向。用户弹幕则揭示了技术普及的微观现实：学习辅助超越代码编程成为最热应用场景，国产模型获得认可，但用户态度整体保持理性观望。将两者结合来看，大语言模型正处于从技术突破走向大规模应用的关键转折期，专业界的热烈讨论与用户端的谨慎态度之间存在认知时差，这个时差的缩短程度将决定技术商业化的速度。对于开发者而言，这提示我们不应盲目追逐媒体报道的技术热点，而应深入理解用户的真实需求和使用场景；对于媒体而言，应当更多报道技术落地的实际案例和用户教育内容，而非仅停留在技术参数的竞赛上。这次附加题的研究不仅为本次作业增加了理论深度，也让我认识到数据分析不应局限于单一维度，多源数据的交叉验证和对比分析才能揭示问题的全貌，这是一次真正意义上的多视角数据挖掘实践。

三、心得体会

从零到一的成长历程

这次大语言模型弹幕分析项目是我大学三年来完成的最有挑战性的实践作业。从最初拿到作业要求时的一头雾水，到最终成功爬取分析48,993条弹幕并得出有价值的结论，整个过程让我深刻体会到了软件工程实践的复杂性和系统性。回顾这段经历，我认为最大的收获不仅仅是掌握了Python爬虫、数据分析、可视化等具体技术，更重要的是学会了如何像一个真正的软件工程师那样去思考问题、分解任务、寻求帮助、迭代优化。

在项目初期，我花了大量时间在环境配置和技术选型上。从创建虚拟环境、安装依赖库，到选择合适的爬虫框架和数据分析工具，每一步都需要查阅大量文档和教程。特别是在遇到B站API的412错误时，我尝试了多种解决方案，从增强请求头到添加Cookie认证，再到最后考虑使用Selenium作为备用方案，这个排查过程让我深刻理解了反爬虫机制的原理以及应对策略的多样性。虽然最终采用的Cookie认证方案相对简单，但这个探索过程让我意识到，解决实际问题往往没有唯一的正确答案，而是需要在多个可行方案中权衡利弊，选择最适合当前情境的那一个。

技术能力的实质性提升

在技术层面，这次项目让我第一次真正理解了"数据驱动"的含义。以前学习数据结构和算法时，我总觉得那些理论知识距离实际应用很遥远，但在这个项目中，当我需要处理近5万条弹幕数据时，如何高效地存储、检索、统计这些数据成了一个必须解决的实际问题。通过使用Counter进行频次统计、使用LRU缓存避免重复计算、使用分批处理降低内存占用，我真切地感受到了算法和数据结构对程序性能的巨大影响。特别是在性能优化环节，当我看到通过简单地移除词性标注参数就能将处理时间从50秒降到18秒时，那种成就感是难以言表的，这也让我认识到，写出能跑的代码只是第一步,写出高效的代码才是真正的挑战。

数据可视化是一个让我受益匪浅的技能点。以前我总觉得Excel只是用来做表格的办公软件，但在这个项目中，通过openpyxl库动态生成包含图表的专业报表，我发现Excel可以成为强大的数据展示工具。学习如何设置单元格样式、合并单元格、插入图表、调整布局，这些看似琐碎的细节其实都是数据可视化中"讲好故事"的重要组成部分。词云图的制作也让我认识到,好的可视化不仅要准确传达信息,还要有美感和吸引力。通过调整字体、配色、布局,让原本枯燥的统计数据变得生动有趣，这种将技术与艺术结合的过程让我乐在其中。

遇到的挑战与解决之道

整个项目过程中,最大的挑战来自于412错误的反复出现。这个错误让我在爬虫开发阶段卡壳了很久，尝试了各种方法都无法绕过B站的反爬虫机制。最初我以为只要模拟浏览器的User-Agent就够了，结果发现还需要完整的请求头。后来又发现请求头还不够，还需要登录后的Cookie。每次以为找到了解决方案，运行一段时间后又会出现新的问题。这个过程让我深刻体会到，真实世界的问题远比教科书上的例子复杂得多，需要耐心和毅力去不断尝试和调试。最终当我成功通过Cookie认证稳定地爬取到数据时，那种终于突破瓶颈的喜悦是无法用言语形容的。

时间管理也是一个不小的挑战。作业要求用PSP表格记录时间，一开始我觉得这只是形式主义，但真正开始记录后才发现，预估时间和实际时间的差距之大超乎想象。我预估编码环节需要5小时，实际花了8小时，主要是因为调试爬虫和处理各种边界情况耗费了大量时间。测试环节我预估2小时，实际只用了1小时，因为代码质量比预期好，bug较少。通过对比预估和实际的差异，我逐渐学会了更准确地评估任务难度和时间成本，这对我未来参与团队项目的任务分配和进度管理很有帮助。PSP不仅仅是一张表格，它是一种自我管理和持续改进的工具。

意外的发现与深入思考

在数据分析过程中，我最意外的发现是学习辅助竟然是最热门的应用场景，而不是普遍认为的代码编程。这个结果让我重新审视了自己对大语言模型应用的认知偏差。作为计算机专业的学生，我的信息圈子里充斥着GitHub Copilot、ChatGPT写代码等话题，自然而然地认为编程是LLM最主要的用途。但数据告诉我，在更广泛的用户群体中，尤其是B站这样的年轻人聚集地，学生们更关心的是AI能否帮助他们学习、做作业、准备考试。这提醒我不要陷入"技术同温层"，要跳出自己的专业视角去理解不同用户群体的真实需求。这种数据驱动的洞察远比主观臆断更有价值。

另一个有趣的发现是85%的弹幕呈现中性情感，而不是我预想的正面情感占主导。这说明在科技话题的讨论中，B站用户展现出了相当的理性。他们不是盲目地吹捧AI，也不是一味地批评，而是更多地在客观讨论技术细节、应用方法、发展趋势。这种理性态度让我对年轻一代的科技素养有了新的认识，也让我反思自己在评价技术时是否足够客观和全面。同时，这个发现也提醒我，情感分析的准确性很大程度上取决于词典的质量和语境的理解，简单的关键词匹配可能会遗漏很多隐含的情感信息，这是未来值得改进的方向。

国产大语言模型在关键词排名中的突出表现也超出了我的预期。豆包和DeepSeek的高权重说明国内AI产品已经在用户心中建立了一定的认知度。这既让我感到自豪，也让我好奇它们是如何在短时间内获得如此高的关注度的。是因为产品本身的优秀，还是因为营销推广的成功，或是因为国际产品在国内的访问限制？这些问题促使我去深入了解国内AI产业的发展现状和竞争格局。作为未来可能进入这个行业的一员，了解市场动态和用户偏好是非常必要的。这次数据分析不仅完成了作业要求，也为我打开了一扇观察行业的窗户。

对软件工程的新认识

通过这次项目，我对软件工程这门课程有了全新的认识。以前我觉得软件工程就是学一些流程图、UML图之类的形式化方法，实际编程中用不上。但这次项目让我深刻体会到，软件工程的核心不是那些图表工具，而是一种系统化思考和解决问题的方法论。从需求分析到系统设计，从编码实现到测试验证，从性能优化到文档撰写，每一个环节都不是孤立的，而是相互关联、相互影响的。只有系统地考虑整个开发生命周期，才能确保项目的成功完成。

版本控制是我在这个项目中养成的一个好习惯。以前我写代码总是在一个文件里改来改去，出了问题想回退都找不到之前的版本。这次强制使用Git进行版本管理，一开始觉得很麻烦，每完成一个功能就要commit和push。但后来我发现，当我不小心删除了一段重要代码时，可以轻松地从历史版本中恢复；当我想查看某个功能是何时添加的时，可以通过提交记录快速定位。Git不仅仅是一个备份工具，更是一个时间机器，让我可以自由地在不同版本之间切换，也让我的开发过程有了清晰的轨迹可循。这种良好的开发习惯将伴随我整个职业生涯。

测试的重要性在这个项目中也得到了充分体现。一开始我觉得单元测试是浪费时间，直接运行整个程序不就知道有没有问题了吗？但当程序变得复杂后，一个小的改动可能会导致意想不到的bug，而这些bug在整个程序运行时很难定位。通过编写单元测试，我可以针对每个函数单独验证其正确性，当某个测试失败时，我可以快速缩小问题范围。特别是在进行性能优化时，单元测试保证了我在提升速度的同时没有破坏原有功能。虽然我的测试覆盖率还不够高，测试用例的设计也比较简单，但这次经历让我认识到测试驱动开发（TDD）的价值，这是我未来需要加强的领域。

对今后的展望

对于未来，这次项目经历让我更加坚定的意识到终身学习的重要性。技术更新迭代的速度远超想象，今天学的技能可能明天就过时了。大学教育给我们打下的是一个基础，但真正的学习是在走出校园后的每一天。保持好奇心，持续关注行业动态，不断尝试新技术新工具，这才是一个技术人员应有的状态。我会把这次项目中养成的良好习惯——记录学习笔记、撰写技术博客、参与开源社区——坚持下去，让自己始终处于学习和成长的轨道上。

如果要用一句话总结这次项目的收获，那就是：我不仅学会了如何做一个项目，更重要的是学会了如何成为一名软件工程师。从问题定义到方案设计，从编码实现到测试验证，从性能优化到文档撰写，这一整套流程的经历让我对软件开发有了系统性的认识。虽然目前我的技能还很稚嫩，代码质量还有很大提升空间，但至少我已经迈出了从学生到工程师转变的第一步。这次项目不是终点，而是一个新的起点，未来的路还很长，我会带着这次经历中积累的经验和教训，继续前行。