软件工程实践第二次作业

102400118 林嘉祚 2026-09-24 22:10:06

软件工程实践第二次作业------与AI结对编程（顶会热词统计）

作业基本信息

项目内容

这个作业属于哪个课程 https://bbs.csdn.net/forums/FZU_university_2026

学号-姓名 102400118 林嘉祚

这个作业要求在哪里 https://bbs.csdn.net/topics/620526370

这个作业的目标完成顶会热词统计项目的需求分析、原型设计、编码、测试和部署，并熟悉Git、CodeArts等开发工具的使用

其他参考文献

一、项目相关链接与AI工具说明

1.1 CodeArts仓库

项目仓库地址：

仓库地址

1.2 代码规范

codestyle.md：

规范链接

代码规范来源：

PEP 8 -- Style Guide for PythonCode Google JavaScript StyleGuide Conventional Commits 1.0.0

1.3 项目部署地址

云服务器访问地址：

http://1.15.91.93/

项目已部署至腾讯云服务器，通过 Nginx + Gunicorn 对外提供 Flask Web
服务。

1.4 AI编程助手说明

项目内容

AI工具 ChatGPT、Claude

模型/版本 GPT-5.6 Sol、Claude Opus 5.5 Thinking

主要用途 ChatGPT主要用于前期作业要求分析、项目思路整理、博客编写和开发方案讨论；Claude主要用于后续代码编写、调试和优化。

使用方式在开发过程中根据当前任务向AI提出问题，并通过多轮对话逐步修改需求和提示词。对于AI给出的方案和代码，由本人进行检查和实际运行，根据运行结果继续要求AI修改和优化。

二、PSP表格

2.1 PSP时间记录

说明：开发过程中未使用计时工具逐项记录，以下"实际耗时"根据本次项目的开发、调试、部署与博客整理过程进行回顾性估算，用于
PSP 总结。

PSP Personal Software Process 预估耗时（分钟）实际耗时（分钟）
Stages

Planning 计划 30 35

· Estimate · 估计任务所需时间 20 25

Development 开发 720 905

· Analysis · 需求分析（包括学习新技术） 80 95

· Design Spec · 生成设计文档 60 70

· Design Review · 设计复审 30 35

· Coding · 代码规范 20 25
Standard

· Design · 具体设计 90 105

· Coding · 具体编码 240 270

· Code Review · 代码复审 40 45

· Test · 测试、修改代码 160 260

Reporting 报告 210 285

· Test Report · 测试报告 50 55

· Size · 计算工作量 20 20
Measurement

· Postmortem & · 事后总结，并提出过程改进计划 140 210
Process
Improvement
Plan

合计 960 1225

2.2 PSP预估与实际耗时分析

本次 PSP 记录中，预估总耗时为 960 分钟，实际回顾估算为 1225 分钟，实际耗时比预估多约 265 分钟。整体来看，需求分析、设计文档、代码规范和代码复审等阶段与最初估计较为接近，而测试、修改代码以及事后总结阶段的偏差相对明显。

其中，测试与修改代码预估为 160 分钟，实际约为 260 分钟，是偏差较大的环节。主要原因是项目从“代码能够生成”到“系统能够稳定运行”之间还需要处理 Python 虚拟环境、依赖安装、数据库数据、DBLP 在线接口异常以及前后端联调等问题。尤其是 DBLP 批量获取过程中出现 JSON 解析异常后，需要进一步判断问题来源并调整展示方案，因此增加了调试时间。

事后总结与过程改进预估为 140 分钟，实际约为 210 分钟。主要原因是本次作业不仅要求完成程序，还需要整理 NABCD、原型设计、AI 结对过程、关键代码、问题解决过程、CodeArts 版本管理和博客文档，因此最终文档整理工作量高于最初预期。

通过本次 PSP 对比可以看出，我对“直接编码”的时间估计相对接近，但容易低估调试、部署和文档整理所需要的时间。以后进行类似项目时，应当为外部接口、环境配置、部署测试和文档整理预留更充分的缓冲时间。

三、NABCD需求分析

3.1 N------Need 需求

3.1.1 用户痛点

计算机领域的顶级会议每年都会发表大量论文，论文数量多、研究方向分散。对于刚开始接触科研的学生来说，如果仅通过逐篇阅读论文来了解当前研究热点，需要花费较多时间，也很难快速发现不同年份之间研究热点的变化。

现有的论文检索网站虽然能够提供论文标题、作者等基本信息，但对于"某一顶会当前有哪些热门研究方向""某个关键词近几年热度如何变化"等问题，往往还需要用户自行收集论文数据并进行整理和统计。

因此，希望通过对顶会论文数据进行收集、整理和关键词统计，将大量论文信息转换为更加直观的热词排名和可视化结果，降低用户了解顶会研究热点的成本。

3.1.2 目标用户

本项目的主要目标用户包括：

计算机相关专业学生：希望了解计算机领域不同顶会的热门研究方向，为课程学习、科研入门等提供参考。
科研初学者：需要快速了解某个研究领域近年来的热点关键词及发展趋势。
论文阅读者：希望根据会议、年份或关键词快速查找相关论文，而不是逐篇浏览大量论文信息。
对计算机前沿技术感兴趣的用户：希望通过直观的统计结果了解不同阶段较热门的研究主题。

3.1.3 核心需求

根据上述用户痛点，本项目需要实现以下核心需求：

论文数据展示：展示顶会论文的标题、作者、会议、年份等基本信息。
论文查询：支持用户根据关键词、会议或年份等条件查找论文。
热词统计：对论文数据进行处理和统计，得到出现频率较高的研究关键词，并展示
Top 10 热词。
可视化展示：通过图表等方式直观展示热词统计结果，降低用户理解数据的成本。
趋势分析：对不同年份的热词数据进行比较，展示部分研究关键词随时间的热度变化。
论文与热词关联：用户查看某个热词时，可以进一步了解与该热词相关的论文，为后续论文阅读提供便利。

3.1.4 用户使用场景

场景一：了解某顶会的研究热点

用户希望了解某一顶级会议当前主要研究哪些方向，可以选择对应会议和年份，系统对相关论文进行统计，并展示
Top 10 热词及可视化结果，使用户能够快速了解该会议的热门研究主题。

场景二：查找感兴趣的论文

用户对某个研究方向感兴趣，可以输入关键词进行查询，系统展示与该关键词相关的论文信息，用户可以进一步查看论文的标题、作者等内容。

场景三：观察研究热点变化

用户希望了解某个研究主题近几年的发展情况，可以查看不同年份的热词统计结果或趋势图，通过比较关键词在不同年份的变化情况，直观了解该研究主题的热度变化。

场景四：科研入门与选题参考

对于刚开始接触科研的学生，可以先通过系统查看目标领域顶会的热门关键词，再根据感兴趣的热词进一步查找相关论文，从而辅助了解研究方向并开展后续文献阅读。

3.2 A------Approach 做法

3.2.1 总体解决方案

针对用户难以快速了解顶会研究热点的问题，本项目计划构建一个集论文信息获取、论文检索、热词统计、关键词可视化和历年趋势分析于一体的顶会热词统计平台。

系统首先获取指定顶级会议不同年份的论文信息，并对论文标题、摘要、关键词等文本数据进行整理和预处理。在此基础上统计高频关键词，并通过
Top 10 热词、关键词图谱和热度趋势图等方式进行可视化展示。

用户可以根据会议、年份和关键词等条件查看论文及统计结果，从大量论文数据中快速了解某一会议或研究领域的热门研究方向。

整体处理流程如下：

论文数据获取
    ↓
数据清洗与整理
    ↓
关键词提取与统计
    ↓
热门研究方向分析
    ↓
可视化处理
    ↓
论文列表 / Top 10热词 / 关键词图谱 / 热度趋势
    ↓
Web页面展示

3.2.2 论文信息获取方案

系统需要获取顶会论文的基本信息，主要包括：

论文标题（Title）
作者（Authors）
会议名称（Conference）
发表年份（Year）
摘要（Abstract）
关键词或研究主题（Keywords）
论文访问地址（URL）

数据获取阶段计划优先选择公开、可靠的论文数据来源，根据实际开发情况采用公开
API 或公开会议论文页面获取数据。

获取论文数据后，将不同来源的数据整理为统一的数据结构，例如：

title
authors
conference
year
abstract
keywords
url

随后对重复数据、缺失数据和格式异常的数据进行清洗，为后续关键词统计和趋势分析提供统一的数据基础。

3.2.3 热门研究方向分析方案

热门研究方向主要通过对论文文本中的关键词进行统计得到。

基本处理流程为：

获取论文标题/摘要等文本
        ↓
文本预处理
        ↓
关键词提取
        ↓
去除无实际研究意义的高频词
        ↓
统计关键词出现频率
        ↓
按照频率排序
        ↓
得到Top 10热门关键词

系统可以按照会议和年份分别进行统计。例如，用户选择某个会议及年份后，系统统计该范围内论文的关键词出现情况，并按照出现频率进行排序，最终展示
Top 10 热词。

为了减少无意义词语对统计结果的影响，在数据处理过程中需要进行必要的文本清洗，并设置停用词列表，对部分缺乏实际研究意义的词语进行过滤。

后续开发过程中将根据实际论文数据对关键词提取和统计方法进行调整，使统计结果能够较合理地反映论文研究主题。

3.2.4 关键词图谱方案

为了让用户更加直观地观察不同研究关键词之间的关系，本项目计划提供关键词图谱功能。

图谱以关键词作为节点，根据关键词在同一篇论文中的共同出现情况建立关键词之间的联系。

基本思路如下：

论文A：LLM、Transformer、Reasoning
论文B：LLM、Agent、Reasoning
论文C：Transformer、Vision

↓

统计关键词共同出现关系

↓

LLM —— Reasoning
 │        │
Agent     Transformer
             │
           Vision

图谱中：

节点表示研究关键词；
连线表示两个关键词存在一定的共同出现关系；
可以根据关键词出现频率调整节点的视觉大小；
可以根据共同出现次数反映关键词之间联系的强弱。

用户可以通过关键词图谱快速观察哪些研究主题经常同时出现，从而辅助了解不同研究方向之间的联系。

具体的图谱生成算法和展示方式将在实际开发过程中根据数据规模进一步调整。

3.2.5 热度走势分析方案

为了观察研究热点随时间的变化，本项目计划按照年份统计同一关键词的出现情况，并通过折线图等方式展示其变化趋势。

例如：

关键词：Large Language Model

2022    ███
2023    ███████
2024    ███████████
2025    █████████████

系统可以首先统计某关键词在不同年份论文中的出现次数，并形成类似以下的数据：

年份出现次数

2022 25
2023 68
2024 103
2025 127

随后将统计结果通过折线图进行展示。

用户选择感兴趣的关键词后，可以查看该关键词在不同年份中的统计结果，从而更加直观地观察研究主题随时间发生的变化。

需要注意的是，该功能展示的是基于本项目所收集论文数据得到的关键词统计变化，并不直接代表整个学术领域的实际热度。

3.2.6 AI辅助需求分析过程

在项目需求分析阶段，我主要使用 ChatGPT 辅助分析作业要求和整理项目需求。

首先将作业要求及项目主题提供给 AI，让 AI
帮助梳理项目需要解决的问题以及可能需要实现的功能。在得到初步方案后，我结合项目实际要求对方案进行筛选和修改，并继续通过多轮对话讨论论文检索、热词统计、关键词图谱和趋势分析等功能的具体需求。

AI在这一阶段主要起到辅助分析和整理思路的作用，最终的项目需求仍根据作业要求和项目实际开发能力进行确定。

AI辅助需求分析过程截图：

主要讨论内容：

分析顶会热词统计项目的目标用户；
分析用户在查找和了解顶会研究热点时存在的问题；
确定论文查询、Top 10 热词等核心功能；
讨论关键词图谱的展示思路；
讨论历年热度走势功能；
对 NABCD 需求分析内容进行整理和修改。

3.3 B------Benefit 好处

本项目希望通过对顶会论文信息进行统一整理和可视化分析，降低用户了解计算机领域研究热点的成本。

相比于用户逐篇浏览大量论文，本项目可以将论文数据转换为热词排名、关键词图谱和趋势图等更加直观的信息，使用户能够快速形成对某个会议或研究方向的整体认识。

平台主要能够带来以下价值：

降低信息获取成本
用户不需要逐篇阅读大量论文，即可通过热词统计快速了解某一会议或年份较为集中的研究主题。
提高论文查找效率
用户可以通过会议、年份和关键词等条件筛选论文，更快找到自己感兴趣的论文。
直观展示研究热点 通过 Top 10
热词和可视化图表，将大量文本数据转换为更容易理解的统计结果。
观察研究方向变化
通过历年关键词统计和趋势图，帮助用户观察特定研究主题在不同年份中的变化情况。
辅助科研入门
对于刚开始接触科研的学生，可以先通过热门关键词了解某个领域，再进一步查找相关论文，从而为后续文献阅读提供参考。
展示关键词之间的联系
通过关键词图谱展示不同研究关键词之间的共同出现关系，使用户能够从整体角度观察不同研究主题之间可能存在的关联。

3.4 C------Competitors 竞争

3.4.1 竞品分析

本项目选择 Google Scholar、Semantic Scholar 和 Connected Papers
作为参考对象。这些工具的主要定位并不完全相同，因此以下比较主要用于说明本项目所关注功能与现有学术工具之间的差异，而不是对平台整体能力进行评价。

对比维度本项目 Google Scholar Semantic Scholar Connected Papers

论文检索支持，主要面向收集到的顶会论文支持支持主要围绕种子论文探索相关论文

按会议/年份分析计划支持可通过检索条件辅助查找支持论文检索及年份等条件筛选不是主要定位

Top 10热词统计核心功能不是主要功能不是本项目这种按顶会/年份统计热词的主要展示形式不是主要功能

关键词可视化计划提供关键词关系图谱不是主要功能不是主要功能提供论文关系的图可视化，但节点主要是论文

历年热词趋势核心功能不是主要功能可获得论文及年份等数据，但不是本项目这种热词趋势展示不是主要功能

主要使用场景快速了解顶会研究热点及其变化学术文献搜索学术搜索与论文信息探索从一篇论文出发探索相关论文

本项目重点顶会热词统计与趋势可视化文献检索论文检索及学术数据论文关系可视化

注：上述比较针对本项目所需要的"顶会热词分析"使用场景，不代表对各学术平台全部功能的完整比较。

3.4.2 本项目的特点

本项目并不试图替代现有的大型学术搜索平台，而是针对"快速了解顶会研究热点"这一具体需求进行设计。

主要特点包括：

聚焦计算机顶会数据
将分析范围集中在指定计算机顶级会议及年份，使统计结果更贴近课程项目所关注的研究范围。
突出 Top 10 热词统计
对论文文本数据进行关键词统计，并直接展示当前数据范围中的热门研究关键词。
提供关键词关系可视化
根据关键词共同出现关系构建图谱，使用户能够观察不同研究主题之间的联系。
提供历年趋势分析
将同一关键词在不同年份中的统计结果进行可视化，方便用户观察研究热点随时间的变化。
论文检索与热点分析结合
用户在发现感兴趣的热门关键词后，可以进一步查看相关论文，使"发现研究方向"和"查找论文"形成联系。

3.4.3 与现有方案的差异

Google Scholar、Semantic Scholar
等平台主要解决大规模学术论文搜索和信息获取问题，而 Connected Papers
更强调通过论文之间的相似关系帮助用户探索相关文献。

本项目关注的问题更加具体，即：

如何从大量顶会论文中快速了解某一年或某一阶段主要研究什么，以及这些研究热点如何发生变化。

因此，本项目将论文检索作为基础功能，将主要展示重点放在：

顶会论文
   ↓
关键词提取
   ↓
Top 10热词
   ↓
关键词关系
   ↓
历年热度变化

这种设计能够对现有论文检索工具形成一定的功能补充，更适合希望快速了解顶会研究热点的学生和科研初学者。

3.5 D------Delivery 推广

本项目属于课程实践性质的学术信息分析平台，因此前期推广主要面向计算机相关专业学生和科研初学者，不以大规模商业推广为主要目标。

项目完成后主要通过以下方式进行展示和推广：

部署 Web 在线版本 项目已部署到腾讯云服务器，用户可以通过公网地址
http://1.15.91.93 直接访问，无需在本地安装开发环境。
通过 CodeArts 公开项目代码
在允许公开的情况下，将项目源代码和相关文档保存在 CodeArts
仓库中，方便其他同学了解项目的实现过程。
通过 CSDN 发布项目博客
在课程作业博客中介绍项目需求、原型设计、开发过程、AI结对过程以及最终成果，并提供项目访问地址。
面向同学进行分享
可以将系统分享给对科研、论文阅读或计算机前沿技术感兴趣的同学试用，并根据使用反馈进一步调整界面和功能。
通过实际使用进行迭代
收集用户在论文查询、热词统计和可视化功能中的实际体验，根据反馈优化搜索方式、数据展示效果和交互流程。

项目初期的主要推广目标不是追求大量用户，而是让目标用户能够方便地访问系统、理解系统功能，并通过实际使用验证顶会热词统计与可视化功能是否具有实际价值。

四、原型设计

4.1 原型开发工具

使用工具： Figma

本项目使用 Figma 进行原型设计。选择 Figma
的主要原因是其网页界面设计和组件布局功能较为完善，可以比较方便地完成导航栏、数据卡片、表格、图表等
Web 页面元素的设计，同时支持多个页面之间的交互跳转。

在正式编码前先通过 Figma
完成页面原型，可以提前确定系统的页面结构、功能布局和主要操作流程，减少后续开发过程中频繁修改页面结构的情况。同时
Figma 支持通过链接分享原型，便于展示和查看最终设计效果。

4.2 原型设计思路

4.2.1 页面信息架构

根据前面的需求分析，本项目围绕"顶会论文数据"和"研究热点分析"两个主要方向设计页面。

系统主要包含以下页面：

顶会热词统计平台
│
├── 首页 / 热门方向总览
│   ├── 论文数量统计
│   ├── 收录会议数量
│   ├── 当前热门关键词
│   └── 热点数据概览
│
├── Top 10热门方向
│   ├── 会议筛选
│   ├── 年份筛选
│   └── Top 10热词统计
│
├── 关键词图谱
│   ├── 关键词节点
│   └── 关键词关联关系
│
├── 热度走势
│   ├── 关键词选择
│   ├── 年份范围选择
│   └── 热度趋势图
│
├── 论文管理
│   ├── 论文搜索
│   ├── 论文列表
│   ├── 论文详情
│   └── 数据筛选
│
├── 数据导入
│   ├── 论文爬取
│   └── 批量导入
│
└── 关于
    └── 项目介绍

其中，首页负责展示系统整体数据和热门研究方向；Top
10、关键词图谱和热度走势主要负责研究热点的分析与可视化；论文管理和论文详情用于论文信息查询；数据导入页面负责论文数据的获取和维护。

4.2.2 UI设计思路

本项目主要面向计算机专业学生和科研初学者，因此 UI
设计以简洁、清晰和数据可视化为主要目标。

整体采用数据分析平台常见的 Dashboard
布局，通过顶部导航栏或侧边导航栏连接不同功能页面。页面主体使用卡片、表格和图表展示数据，避免在同一页面堆积过多文字信息。

主要设计原则如下：

统一导航：各页面使用统一的导航区域，使用户能够快速切换不同功能。
突出数据：论文数量、热门关键词等重要数据使用统计卡片进行展示。
强化可视化：Top 10
热词、关键词关系和历年变化尽量通过柱状图、关系图和折线图展示。
减少操作步骤：会议、年份和关键词等常用筛选条件放置在明显位置。
保持风格一致：按钮、卡片、表格、字体和页面间距保持统一，使整个系统具有一致的视觉效果。

4.2.3 用户操作流程

系统主要围绕"发现热门方向"和"查找相关论文"设计用户操作流程。

典型使用流程如下：

进入系统首页
    ↓
查看顶会数据概览
    ↓
选择会议和年份
    ↓
查看Top 10热门方向
    ↓
选择感兴趣的关键词
    ├──────────────┐
    ↓              ↓
查看关键词图谱    查看历年热度走势
    │              │
    └──────┬───────┘
           ↓
      查看相关论文
           ↓
      查看论文详情

例如，用户希望了解某一会议在某一年的研究热点，可以首先进入 Top 10
热门方向页面，选择会议和年份。系统展示对应的热门关键词后，用户可以进一步进入关键词图谱查看不同关键词之间的关系，也可以查看某个关键词历年的热度变化。

如果用户对某个研究方向产生兴趣，还可以进一步搜索相关论文并查看论文详细信息。

4.3 AI辅助原型设计

初始Prompt

在原型设计阶段，我使用 ChatGPT 辅助分析页面结构和功能布局，初始 Prompt
如下：

我要设计一个"顶会热词统计平台"的 Web
原型，主要面向计算机专业学生和科研初学者。系统需要包含论文查询、Top 10
热门研究方向、关键词图谱、历年热度走势、论文数据导入等功能。请帮我规划系统需要包含哪些页面，以及每个页面应该放置哪些主要内容，并给出一个简洁的数据分析平台
UI 布局方案。

AI给出的建议

AI 根据项目需求建议采用 Dashboard 风格设计，将系统划分为首页、Top 10
热门方向、关键词图谱、热度走势、论文管理、数据导入和关于等主要页面。

在页面布局方面，AI建议使用统一导航栏，并通过数据卡片、柱状图、折线图、关系图和论文表格等组件展示不同类型的数据。

首页主要展示论文总数、会议数量、热门关键词等概览数据；其他页面分别承担热点统计、关键词关系分析、趋势分析和论文查询等具体功能。

我的判断与修改

经过分析，我采纳了 AI 提出的 Dashboard
整体布局，以及使用数据卡片和图表展示统计结果的建议。这样的布局比较适合本项目以数据分析和可视化为主的特点。

同时，我没有完全按照 AI
建议增加过多独立页面，而是对部分功能进行了合并。例如将论文搜索、筛选和列表统一放在论文管理页面中，避免页面数量过多导致操作复杂。

此外，根据项目需求增加了论文数据导入功能，并将"Top 10
热门方向""关键词图谱"和"热度走势"作为三个主要的数据分析功能重点展示。

最终原型结构根据项目实际功能和开发工作量进行确定，而不是完全采用 AI
给出的方案。

AI协作截图

与 ChatGPT 讨论原型页面结构和 UI 布局的对话截图

项目功能截图

4.4 原型页面展示

4.4.1 首页 / 热门方向总览

[插入首页原型截图]

首页作为用户进入系统后的第一个页面，主要展示平台的整体数据概况。页面计划通过统计卡片展示论文总数、收录会议数量、年份范围等基本数据，同时展示当前
Top
热词和部分趋势信息，使用户能够快速了解平台的数据情况和近期热门研究方向。

4.4.2 Top 10热门方向

[插入Top
10热门方向原型截图]

该页面用于展示指定会议和年份下的 Top 10
热门研究关键词。用户可以通过会议和年份选择器调整统计范围，页面通过柱状图等方式展示不同关键词及其出现频率，使用户能够快速发现当前数据范围内较热门的研究方向。

4.4.3 关键词图谱

[插入关键词图谱原型截图]

关键词图谱页面用于展示不同研究关键词之间的关联关系。关键词以节点形式展示，存在共同出现关系的关键词通过连线连接。用户可以通过图谱更加直观地观察不同研究主题之间的联系。

4.4.4 热度走势对比

[插入热度走势原型截图]

热度走势页面主要用于展示研究关键词在不同年份中的变化情况。用户可以选择一个或多个关键词，通过折线图比较这些关键词在不同年份中的统计结果，从而观察研究热点随时间的变化。

4.4.5 论文列表管理

[插入论文列表管理原型截图]

论文列表管理页面用于集中展示系统收录的论文数据。页面提供关键词搜索以及会议、年份等筛选功能，并通过表格展示论文标题、作者、会议、年份等基本信息。用户可以通过列表进一步进入论文详情页面。

4.4.6 论文爬取 / 批量导入

[插入论文数据导入原型截图]

该页面用于管理系统的论文数据来源。用户可以设置需要获取的会议和年份，并执行论文数据获取任务；同时预留批量导入功能，方便将已有论文数据导入系统。

页面还计划展示数据获取或导入任务的执行状态、成功数量和失败数量等信息。

4.4.7 论文详情

[插入论文详情原型截图]

论文详情页面用于展示单篇论文的完整信息，包括论文标题、作者、所属会议、发表年份、摘要、关键词等内容，并提供原始论文链接。

同时可以展示与该论文关键词相关的其他论文或研究方向，使用户能够从热门关键词进一步了解具体论文。

4.4.8 关于 / 了解更多

[插入关于页面原型截图]

关于页面主要用于介绍项目背景、主要功能、数据来源和项目开发信息，帮助第一次使用系统的用户快速了解平台的用途和基本使用方式。

4.5 原型交互逻辑

操作所在页面触发方式交互结果

切换功能页面所有页面点击顶部导航栏跳转至对应功能页面

查看论文详情论文管理点击"查看详情" 进入对应论文详情页面

返回论文列表论文详情点击返回按钮返回论文管理页面

查看图表信息 Top 10 / 鼠标移动到图表数据上显示对应的数据提示
热度走势

调整关键词节点关键词图谱鼠标拖动节点改变节点位置并动态调整关系图

页面之间的数据流转关系

整个原型以首页作为主要入口，通过顶部导航栏连接 Top 10
热门方向、关键词图谱、热度走势、论文管理、数据导入和关于页面。论文管理页面还可以进一步进入论文详情页面，从而形成基本的页面跳转和用户操作流程。

五、系统设计与实现过程

5.1 技术选型

层次使用技术用途

前端 HTML、CSS、JavaScript 实现页面结构、页面样式以及用户交互

后端 Python、Flask 提供 Web
服务，实现业务逻辑以及前后端数据交互

数据库 SQLite 存储和管理论文信息

数据获取 DBLP API、Requests 实现论文数据在线获取功能

数据分析 Python 对论文数据进行处理并完成关键词频率统计

数据可视化 ECharts 实现 Top 10、关键词图谱和热度趋势等图表

运行与部署 TencentOS Server 在腾讯云服务器上运行并通过公网提供 Web
4、Python 服务
3.11、Gunicorn、Nginx

技术选型理由

本项目主要完成顶会论文数据管理、热门研究方向统计以及数据可视化等功能，因此在技术选型上主要考虑开发效率、项目规模以及部署难度。

后端采用 Python 的 Flask 框架。Python
具有较为丰富的数据处理生态，适合进行论文数据处理和关键词统计；Flask
框架本身较为轻量，项目结构清晰，能够比较方便地完成接口设计以及前后端数据交互。

数据库采用
SQLite。由于本项目规模较小，论文数据量有限，不需要额外部署独立的数据库服务器。SQLite
可以直接通过数据库文件完成数据持久化，配置简单，也方便项目运行和迁移。

前端采用 HTML、CSS 和 JavaScript 实现页面及交互，并使用 ECharts
完成数据可视化。ECharts
支持柱状图、折线图和关系图等多种图表形式，可以满足热门研究方向、关键词关系以及历年热度走势等功能的展示需求。

5.2 系统功能结构

5.2.1 功能结构图

本系统围绕顶会论文数据的管理和分析展开，主要包括首页数据总览、数据导入、论文管理、Top
10 热门方向、关键词图谱以及热度走势等模块。

系统功能结构如下：

顶会热词统计系统
│
├── 首页
│   ├── 数据概览
│   ├── 热门方向展示
│   └── 趋势概览
│
├── 数据导入
│   ├── DBLP数据获取
│   ├── 演示数据加载
│   └── CSV数据导入
│
├── 论文管理
│   ├── 论文列表
│   ├── 论文查询
│   ├── 新增论文
│   ├── 修改论文
│   ├── 删除论文
│   └── 论文详情
│
├── Top 10热门方向
│   └── 关键词频率统计
│
├── 关键词图谱
│   ├── 关键词关系可视化
│   └── 关键词与论文联动
│
└── 热度走势
    └── 不同年份关键词热度变化

5.2.2 系统模块说明

系统首页作为整个系统的入口，用于展示论文数量、热门关键词以及研究方向趋势等整体信息，使用户能够快速了解当前数据集的基本情况，并通过导航栏进入其他功能页面。

数据导入模块负责向系统中添加论文数据。系统实现了在线数据获取、CSV
文件导入以及演示数据加载等方式。本次项目成品展示主要采用系统内置的演示数据，以保证各分析和可视化功能能够稳定展示。

论文管理模块负责对数据库中的论文进行统一管理，包括论文列表展示、条件查询、新增、修改、删除以及详情查看等操作。

Top 10
热门方向模块对当前论文数据中的关键词进行统计，根据关键词出现频率得到当前数据集中较为热门的研究方向，并通过图表进行展示。

关键词图谱模块通过关系图展示不同关键词之间的联系，使关键词之间的关系更加直观。同时将关键词和论文数据进行联动，使用户能够进一步查看与关键词相关的论文。

热度走势模块按照年份对关键词出现情况进行统计，并利用折线图展示不同研究方向随时间发生的变化。

5.3 数据获取与处理

5.3.1 数据来源

系统在设计时实现了通过 DBLP 获取论文元数据的功能，同时支持 CSV
文件导入以及内置演示数据加载。

在实际运行过程中，在线数据接口可能受到网络环境以及接口响应情况的影响。为了保证系统主要功能能够稳定测试和展示，本次项目最终使用系统内置的演示数据完成论文管理、关键词统计、关键词图谱以及热度走势等功能的测试。

演示数据主要用于验证系统的数据处理流程和各功能模块是否能够正常运行，不将其中的统计结果作为真实顶会研究趋势的结论。

这种设计也使系统在外部数据源暂时不可用的情况下，仍然能够完成主要业务流程和数据可视化功能的测试。

5.3.2 数据清洗

论文数据进入系统后，需要进行基本的数据处理，以保证后续统计分析功能能够正常运行。

主要处理内容包括：

对论文标题、会议名称、年份等字段进行统一处理；
检查必要字段是否存在，减少缺失数据对统计结果的影响；
对文本数据进行基本的格式规范化处理；
将处理后的论文数据转换为统一的数据结构；
将处理后的数据保存到数据库，为后续关键词统计和数据可视化提供基础。

经过处理后的数据统一保存到 SQLite 数据库中，并由后端程序进行读取和管理。

5.3.3 关键词提取

系统根据论文相关文本信息进行关键词统计。

首先对论文数据进行预处理，将文本转换为适合进行统计的形式，然后对其中出现的关键词进行频率统计，并过滤部分缺乏实际研究意义的常见词。

处理后得到的关键词以及对应的出现次数将作为热门研究方向分析的基础，同时也可以用于关键词图谱和热度走势等功能。

通过将关键词处理逻辑放在独立的数据分析模块中，可以避免在不同功能页面重复执行相同的数据处理代码，也方便后续对关键词统计方法进行调整。

5.3.4 热度统计方法

本项目使用关键词出现频率作为研究方向热度的主要参考指标。

对于当前数据集，系统统计不同关键词在论文数据中的出现次数，然后按照出现频率从高到低进行排序，并从中选取排名靠前的关键词构成
Top 10 热门研究方向。

对于历年趋势分析，则进一步按照论文年份进行分组，分别统计同一关键词在不同年份中的出现情况，并将统计结果传递给前端，通过折线图展示关键词热度随时间发生的变化。

需要说明的是，本次成品展示使用的是系统内置演示数据，因此相关图表主要用于展示系统统计分析和可视化功能的运行效果，不代表真实顶会研究方向的实际排名。

5.4 功能模块设计与实现

5.4.1 功能一：论文信息导入

设计思路

为了给后续论文管理和数据分析功能提供基础数据，系统设计了独立的数据导入模块。

数据导入模块支持在线数据获取、CSV
批量导入以及演示数据加载等方式。不同来源的数据进入系统后，需要转换成统一的数据格式，然后保存到
SQLite 数据库中，使其他功能模块能够使用统一的数据来源。

本次成品展示主要使用系统内置的演示数据完成后续功能测试。

实现过程

后端通过 Flask
接收前端发出的数据导入请求，根据用户选择的数据来源执行对应的数据处理逻辑。

对于加载成功的数据，系统将其转换成统一的论文数据结构，并写入 SQLite
数据库。数据保存完成后，论文管理、Top
10、关键词图谱以及热度走势等模块即可读取这些数据进行进一步处理。

系统同时保留了在线获取论文数据的功能，但本次最终功能展示主要采用演示数据，以避免外部接口和网络环境对系统展示造成影响。

实现结果

系统能够成功加载内置演示论文数据。数据加载完成后，可以在论文管理页面查看相应论文，并可以用于后续关键词统计和数据可视化。

5.4.2 功能二：论文列表管理

设计思路

论文管理模块主要用于解决论文数据查看和维护的问题。

为了方便用户管理系统中的论文数据，系统将论文以列表形式进行展示，并提供论文查询、详情查看、新增、修改以及删除等基本操作。

通过该模块，用户可以直接管理数据库中的论文数据，同时论文数据发生变化后，后续统计分析模块也可以基于更新后的数据重新进行分析。

实现过程

后端使用 SQLite 对论文数据进行持久化管理，并通过 Flask
实现相应的数据操作逻辑。

前端向后端发送请求获取论文数据，再将返回的数据展示在论文列表中。当用户执行新增、修改或删除操作时，前端将对应操作提交给后端，由后端完成数据库中的数据更新。

论文详情功能则用于展示单篇论文的相关信息，使用户可以在论文列表之外进一步查看具体论文内容。

这种设计将页面展示与数据操作进行分离，使系统结构更加清晰，也方便后续增加新的论文管理功能。

实现结果

论文管理页面能够正常显示已经加载的演示论文数据，并能够完成论文查询、详情查看以及基本的增删改操作。

论文管理页面

论文查询结果

论文详情或编辑页面

5.4.3 功能三：Top 10热门研究方向

设计思路

如果仅通过论文列表浏览数据，用户很难快速判断当前数据集中哪些研究方向出现得更加频繁，因此系统设计了
Top 10 热门研究方向功能。

该功能通过统计关键词出现频率，将出现次数较多的关键词按照热度进行排序，并选择排名靠前的关键词进行可视化展示，使用户可以快速了解当前数据集中的关键词分布情况。

实现过程

后端首先读取当前论文数据，通过数据分析模块完成关键词统计，得到关键词以及对应的出现次数。

统计完成后，根据关键词出现次数进行排序，并选择排名靠前的数据返回给前端。

前端使用 ECharts
将统计结果绘制成图表，通过图形长度或数值大小直观表现不同关键词之间的热度差异。

实现结果

系统能够根据当前演示数据生成 Top 10
热门研究方向，并通过图表直观展示不同关键词之间的热度差异。

Top 10
热门研究方向

5.4.4 功能四：关键词图谱

设计思路

Top 10
图表能够反映单个关键词的出现频率，但不能直接展示不同研究关键词之间可能存在的联系。

因此，系统进一步设计了关键词图谱功能，通过节点和连线表示关键词及其关系，使用户能够从关系网络的角度观察不同研究方向。

同时，为了避免关键词图谱仅停留在可视化层面，系统将关键词和论文数据进行联动，使用户能够进一步查看与某个关键词相关的论文。

实现过程

后端根据论文数据生成关键词相关统计结果，并将关键词及其关系整理成适合前端关系图使用的数据结构。

前端使用 ECharts
关系图进行可视化展示。关键词以节点形式显示，不同关键词之间的关系通过连线进行表示。

在关键词与论文联动功能中，用户对关键词进行相应操作后，系统可以根据关键词筛选相关论文，从而建立统计结果和具体论文之间的联系。

实现结果

系统能够正常生成关键词关系图，并通过图形化方式展示不同关键词之间的联系，同时能够结合论文信息完成关键词与论文之间的联动展示。

关键词图谱

关键词与论文联动效果

5.4.5 功能五：热度走势对比

设计思路

Top 10
热门方向主要展示当前数据集中的整体关键词分布情况，但研究方向本身具有随时间变化的特点。

因此，系统设计了热度走势分析功能，通过统计关键词在不同年份中的出现情况，以时间序列的形式展示研究方向热度变化。

相比单一的热门方向排名，趋势分析能够从时间维度展示关键词的变化过程。

实现过程

系统首先按照年份对论文数据进行分类，再分别统计目标关键词在不同年份中的出现情况。

后端将年份以及对应的统计结果整理后返回给前端，前端使用 ECharts
折线图进行绘制。

图表横轴表示年份，纵轴表示关键词热度，通过折线变化展示研究方向在不同年份中的变化情况。

实现结果

系统能够根据演示数据生成关键词历年热度变化曲线，并通过折线图展示不同年份之间的变化情况。

热度走势

5.4.6 扩展功能

除了基本的热门方向统计功能之外，本项目还实现了论文增删改查、论文详情查看、CSV
数据导入以及关键词与论文联动等辅助功能。

其中，论文增删改查功能使系统不仅能够展示论文数据，还能够对论文数据进行实际管理。

CSV
数据导入功能为论文数据提供了另一种批量导入方式，使系统的数据来源更加灵活。

关键词与论文联动功能则将数据可视化结果与具体论文信息联系起来。用户在观察研究关键词的同时，还可以进一步查看相关论文，使统计结果不再只是孤立的图表数据，提高了数据分析结果的可解释性。

5.5 Git与CodeArts开发过程

5.5.1 分支管理

本项目使用 CodeArts Repo 进行代码版本管理，并建立了 master 与 dev 两个分支。master 作为相对稳定的主分支，dev 用于开发和修改。

在实际操作中，我先在 dev 分支完成修改并提交，再通过 CodeArts 的合并请求功能将 dev 合并到 master。这种方式使开发修改与稳定版本之间保持一定隔离，也让我实际完成了一次较完整的分支开发流程。

5.5.2 Commit记录

项目在 CodeArts 中保留了实际提交记录。提交时尽量让提交信息能够说明本次修改内容，例如初始化仓库、补充代码规范和更新项目文档等。通过提交记录可以查看文件在不同阶段的变化，也便于后续定位修改内容。

本次实践让我进一步理解了 Commit 的作用：它不仅是“保存代码”，也是记录项目演进过程的重要方式。相比一次性覆盖整个仓库，按照修改内容进行提交更有利于版本追踪。

5.5.3 合并请求

在 dev 分支产生相对于 master 的实际修改后，我创建了从 dev 到 master 的合并请求，检查文件变更后完成合并。

最终该合并请求状态为“已合并”，说明 dev 中的修改已经进入 master。通过这次操作，我实际体验了“开发分支修改 → 提交 → 创建合并请求 → 检查变更 → 合并到主分支”的基本协作流程。

5.5.4 版本标签

在主要功能完成并完成分支合并后，我在 CodeArts 中创建了 v1.0.0 标签，用于标记本次课程作业提交时的稳定版本。

版本标签可以将某一阶段的代码状态固定下来，使普通开发提交与正式提交版本之间更加清晰。本项目以 v1.0.0 作为本次作业的版本标记。

5.6 项目部署与运行

5.6.1 本地运行环境

本项目后端使用 Python 3 和 Flask，数据库使用 SQLite，前端页面由 Flask
应用提供。开发阶段使用 Python 虚拟环境隔离项目依赖，并通过
requirements.txt 管理第三方依赖。

在 Windows 本地开发环境中，项目可以通过以下方式启动：

python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt
python app.py

Flask 开发服务器启动后，可以通过：

http://127.0.0.1:5000

访问系统。本地环境主要用于功能开发、调试和测试。

5.6.2 腾讯云服务器部署

在本地功能基本完成后，我进一步将项目部署到腾讯云服务器，使系统能够通过公网访问。

本次服务器环境为：

项目配置

云服务平台腾讯云
操作系统 TencentOS Server 4
Python Python 3.11
Web 应用 Flask
WSGI Server Gunicorn
Web Server Nginx
数据库 SQLite
公网访问 http://1.15.91.93

首先将项目压缩包上传到服务器并解压到：

/root/conference_hot_topic_analysis

随后在服务器中创建并激活 Python 虚拟环境，安装项目依赖以及
Gunicorn。项目通过 Gunicorn 监听服务器本地的 127.0.0.1:8000：

gunicorn --workers 2 --bind 127.0.0.1:8000 app:app

为了避免 SSH 会话关闭后应用停止运行，我将 Gunicorn 配置为 systemd
服务。服务成功启动后，通过：

systemctl status conference-hot-topic

可以看到：

Active: active (running)

说明项目已经作为后台服务运行。

5.6.3 Nginx反向代理

Gunicorn 只监听服务器内部的 127.0.0.1:8000，因此使用 Nginx 监听公网的
80 端口，并将浏览器请求反向代理到 Gunicorn。

核心 Nginx 配置如下：

server {
    listen 80;
    server_name 1.15.91.93;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

配置完成后使用：

nginx -t

检查配置语法，确认测试成功后重新加载 Nginx。

部署后的请求流程为：

用户浏览器
    ↓
公网IP：1.15.91.93:80
    ↓
Nginx
    ↓
127.0.0.1:8000
    ↓
Gunicorn
    ↓
Flask应用
    ↓
SQLite数据库

5.6.4 部署结果

完成上述配置后，系统已经能够通过公网正常访问。

公网访问地址：

http://1.15.91.93

部署后，我通过浏览器实际访问该地址，项目首页能够正常显示。至此，项目从本地开发环境进一步部署到了云服务器，实现了通过公网浏览器访问。

原有的本地访问地址 http://127.0.0.1:5000
仍可用于本地开发和调试，但最终成品可以通过腾讯云服务器公网地址进行展示。

本章小结

本章主要介绍了顶会热词统计系统的技术选型、系统功能结构、数据处理方式以及各主要功能模块的设计与实现。

系统采用 Flask + SQLite 构建后端和数据存储部分，使用
HTML、CSS、JavaScript 完成前端页面，并通过 ECharts 实现数据可视化。

在功能方面，系统实现了论文数据导入与管理、Top 10
热门研究方向统计、关键词图谱以及历年热度走势等功能，同时增加了论文增删改查、CSV
导入和关键词与论文联动等辅助功能。

本次成品展示主要使用系统内置演示数据完成测试。演示数据用于验证系统完整的数据处理、统计分析和可视化流程，其统计结果不作为真实顶会研究趋势的结论。

经过本地运行和云服务器部署测试，系统的主要功能能够正常运行，并已经能够通过公网地址访问，基本完成了本项目预期的设计、实现与部署目标。

六、成品展示

本项目已部署至腾讯云服务器，可通过公网地址 http://1.15.91.93
访问。由于在线数据接口受到网络环境等因素影响，本次成品展示统一使用系统内置演示数据。演示数据主要用于验证系统各功能模块及数据处理流程，不代表真实顶会研究方向的实际统计结果。

6.1 首页

系统首页

说明：

系统首页作为顶会热词统计平台的主要入口，用于展示当前数据集的整体情况。首页将论文数据统计结果和可视化图表集中展示，使用户进入系统后能够快速了解当前论文数据以及热门研究方向的基本情况。

同时，用户可以通过页面导航栏进入论文管理、数据导入、Top 10
热门方向、关键词图谱和热度走势等功能页面。

6.2 演示数据导入

数据导入页面

说明：

数据导入模块用于向系统中添加论文数据。系统设计了在线数据获取、CSV
文件导入以及演示数据加载等数据导入方式。

本次成品展示主要使用系统内置的演示数据。通过数据导入页面加载演示数据后，系统可以快速获得用于功能测试的论文数据，并将其用于论文管理、关键词统计以及数据可视化等后续功能。

使用演示数据能够减少外部网络环境对系统功能展示的影响，保证系统主要功能可以稳定运行。

6.3 批量导入

演示数据加载成功

说明：

系统支持一次性加载多条论文数据。用户执行演示数据加载操作后，系统将数据按照统一的论文数据结构进行处理，并保存到数据库中。

数据导入完成后，无需再次手动配置，即可直接进入论文管理、Top 10
热门方向、关键词图谱和热度走势等页面进行进一步操作。

本次使用的批量数据为系统内置演示数据，主要用于验证完整的数据导入、存储、分析和可视化流程。

6.4 论文列表

论文列表

说明：

论文管理页面以列表形式展示当前数据库中保存的论文信息，方便用户集中浏览和管理论文数据。

加载演示数据后，论文列表能够显示对应的论文记录。用户可以通过该页面进一步进行论文查询、查看详情以及新增、修改、删除等操作。

论文列表作为数据管理功能和数据分析功能之间的基础模块，为后续关键词统计和热门方向分析提供数据支持。

6.5 论文查询

论文查询结果

说明：

为了方便用户从论文数据中快速找到需要的信息，系统提供了论文查询功能。

用户输入相应的查询条件后，系统根据条件筛选当前数据库中的论文，并将符合要求的结果展示在论文列表中。

相比逐条浏览全部论文数据，查询功能能够减少用户查找目标论文所需的时间，提高论文管理和浏览的效率。

6.6 论文增删改

论文新增、编辑或删除

说明：

除了论文浏览和查询之外，系统还提供了基本的论文数据维护功能，包括新增论文、修改论文以及删除论文。

用户可以根据实际需要向系统添加新的论文记录，也可以修改已有论文的信息。对于不再需要的论文数据，则可以通过删除功能进行移除。

通过论文增删改功能，系统不仅能够展示已有数据，还具备基本的数据管理能力。当论文数据发生变化后，后续的数据统计和分析也可以基于更新后的数据进行处理。

6.7 Top 10热门方向

Top 10
热门方向页面

说明：

Top 10 热门研究方向是本系统的主要数据分析功能之一。

系统对当前论文数据中的关键词进行统计，根据关键词的出现频率计算其热度，并按照统计结果进行排序，选取排名靠前的关键词进行可视化展示。

相比直接查看论文列表，Top 10
图表能够更加直观地反映当前数据集中不同研究关键词之间的热度差异，使用户能够快速了解研究方向的整体分布情况。

本次页面展示基于系统内置演示数据，因此图表主要用于展示系统的关键词统计及可视化能力，不代表真实顶会研究方向的实际排名。

6.8 关键词图谱

关键词图谱页面

说明：

关键词图谱用于从关系网络的角度展示论文关键词之间的联系。

系统根据当前论文数据生成关键词关系数据，并使用可视化图表进行展示。图谱中的节点表示不同关键词，节点之间的连线用于表现关键词之间存在的关联关系。

与传统的关键词列表相比，关键词图谱能够以更加直观的形式展示不同研究方向之间的联系，使用户可以从整体上观察当前数据集中的关键词关系结构。

本次关键词图谱同样基于演示数据生成，主要用于展示系统的数据处理和关系可视化功能。

6.9 关键词与论文联动

关键词与论文联动

说明：

为了增强数据可视化结果与具体论文数据之间的联系，系统实现了关键词与论文之间的联动功能。

用户在关键词图谱等功能中选择相应关键词后，可以进一步查看与该关键词相关的论文信息，从而将抽象的关键词统计结果与具体论文数据联系起来。

通过这种交互方式，用户不仅能够观察某个关键词在可视化结果中的位置和关系，还能够进一步了解与该研究方向相关的论文，提高数据分析结果的可解释性。

6.10 热度走势对比

热度走势页面

说明：

热度走势功能用于从时间维度展示研究关键词的变化情况。

系统按照年份对论文数据进行分类，并统计目标关键词在不同年份中的热度数据，然后使用折线图对统计结果进行可视化展示。

图表横轴表示年份，纵轴表示相应的关键词热度。通过观察折线的变化，可以直观了解某个研究方向在不同年份中的变化趋势。

与 Top 10
热门方向主要展示整体关键词分布不同，热度走势功能增加了时间维度，使用户能够进一步观察研究关键词随年份发生的变化。

本次趋势图使用演示数据生成，主要用于验证系统的年份统计及趋势可视化功能，不作为真实顶会研究趋势的分析结论。

6.11 其他功能展示

论文详情页面

说明：

除上述主要功能外，系统还提供了论文详情查看以及关于页面等辅助功能。

用户可以从论文管理页面进入论文详情页面，进一步查看单篇论文的具体信息，使论文列表和论文详细内容之间形成完整的浏览流程。

此外，系统通过统一的导航栏连接各主要功能页面，使用户能够在首页、数据导入、论文管理、Top
10 热门方向、关键词图谱和热度走势等模块之间快速切换。

这些辅助功能进一步完善了系统的页面结构和用户操作流程。

6.12 成品展示总结

经过实际运行和功能测试，本项目已经能够正常启动并通过浏览器访问。

在加载系统内置演示数据后，可以完成论文数据管理、论文查询、论文增删改、热门研究方向统计、关键词关系可视化、关键词与论文联动以及历年热度走势展示等功能。

系统将论文数据管理、数据分析和数据可视化结合起来，使用户既可以查看和维护具体论文数据，也可以通过
Top 10 图表、关键词图谱和趋势图等方式观察数据中的研究方向信息。

本次成品展示使用系统内置演示数据，主要目的是验证系统各模块以及完整的数据处理流程是否能够正常运行。因此，本章图表中的具体数值和排名仅作为功能展示使用，不代表真实顶会论文的实际统计结论。

七、AI结对协作过程

7.1 AI结对方式

本次作业要求尝试与 AI 进行结对编程，因此在项目开发过程中，我将 AI
作为一名"结对伙伴"参与需求分析、原型设计、代码实现、问题排查以及博客整理等工作。

本项目主要使用 ChatGPT 作为 AI 结对工具。

与传统的"直接让 AI
生成整个项目"不同，我在实际使用过程中主要采用以下方式与 AI 协作：

我首先向 AI 提供作业要求以及项目目标；
由 AI 对需求进行分析，并给出实现方案；
我根据自己的实际情况判断方案是否可行；
对可以接受的方案继续细化，让 AI 生成代码或具体操作步骤；
将生成结果放到本地环境中实际运行；
如果出现问题，将错误信息重新反馈给 AI；
根据 AI 提供的解决方案进行修改或调整；
最终由我决定哪些方案接受、哪些方案舍弃。

因此，本次人机结对过程中，AI
主要承担了需求分析、方案建议、代码辅助生成、问题定位以及文档整理等工作，而项目最终采用什么方案、如何运行以及如何展示，则由我根据实际运行结果进行判断。

7.2 案例一：需求分析与项目方案确定

7.2.1 背景

在项目开始阶段，我首先需要理解"顶会热词统计"这一题目的具体实现范围。

如果一开始直接进行编码，很容易出现功能遗漏或者项目结构混乱的问题。因此，我首先将作业要求提供给
AI，让 AI 帮助我分析需要实现的核心功能，并规划项目整体实现方案。

7.2.2 我的Prompt

我向 AI 提出的需求主要为：

我需要完成软件工程实践第二次作业——与AI结对编程（顶会热词统计）。

请根据作业要求帮助我分析这个项目需要完成哪些功能，并规划一个适合本次作业的实现方案。

项目需要尽量控制复杂度，但要覆盖作业要求中的主要评分点，包括需求分析、原型设计、编码实现、数据可视化、Git版本管理以及博客撰写等内容。

7.2.3 AI输出

AI 根据作业要求，将项目划分为了多个主要功能模块，包括：

1. 系统首页
2. 论文数据导入
3. 论文列表管理
4. 论文增删改查
5. Top 10热门研究方向统计
6. 关键词图谱
7. 关键词与论文联动
8. 历年热度走势分析

同时，AI 建议采用较为轻量的技术方案：

前端：HTML + CSS + JavaScript
后端：Python + Flask
数据库：SQLite
数据可视化：ECharts
论文数据来源：DBLP
版本管理：Git + CodeArts

7.2.4 我的判断与调整

我认为这一方案比较符合本次作业的规模。

如果使用较复杂的前后端分离框架，会增加环境配置和开发成本，而本次项目的重点主要是完成论文数据管理、热词统计以及数据可视化，因此
Flask + SQLite 的方案已经能够满足需求。

同时，ECharts 可以直接完成柱状图、折线图以及关系图等可视化效果，与 Top
10、关键词图谱和热度走势等功能比较匹配。

因此，我接受了 AI
给出的整体技术方案，并以此作为后续原型设计和代码实现的基础。

7.2.5 最终结果

经过这一轮人机协作，我没有直接开始编码，而是先确定了项目功能范围和技术路线。

这一过程让我认识到，AI
在项目早期更适合作为"方案讨论者"，帮助开发者快速整理需求和比较实现方案，而不是一开始就让
AI 大量生成代码。

AI协作案例一：需求分析与技术方案

7.3 案例二：使用AI辅助完成系统原型设计

7.3.1 背景

确定系统功能以后，我需要先完成原型设计。

为了避免后续开发过程中频繁修改页面结构，我先向 AI 描述系统功能，让 AI
根据功能需求规划页面，并生成可交互的 Web 原型。

7.3.2 我的Prompt

我向 AI 提出的需求主要为：

根据顶会热词统计项目的功能需求，帮我设计一个完整的Web原型。

原型需要覆盖主要功能页面，包括：

1. 首页 / 热门方向总览
2. Top 10热门方向
3. 关键词图谱
4. 热度走势对比
5. 论文列表管理
6. 论文爬取 / 批量导入
7. 论文详情
8. 关于 / 了解更多

希望原型能够直接通过HTML运行，并且页面之间可以进行基本交互。

7.3.3 AI输出

AI 根据需求设计了一个包含多个功能页面的 Web 原型，并使用
HTML、CSS、JavaScript 和 ECharts 实现基本页面及图表效果。

原型主要包含：

首页 / 热门方向总览
Top 10热门方向
关键词图谱
热度走势对比
论文列表管理
论文爬取 / 批量导入
论文详情
关于 / 了解更多

在原型中，首页使用统计卡片展示系统数据概况，Top 10
页面使用图表展示关键词排名，关键词图谱使用关系图展示关键词联系，热度走势页面则使用折线图展示不同年份的数据变化。

7.3.4 我的判断与调整

AI
最初生成的原型中使用了一些示例数据，例如论文数量、关键词热度以及示例论文标题等。

这些数据的作用只是展示页面效果，并不是真实统计结果。因此，我没有将这些数字作为真实的顶会论文统计数据使用，而是将其明确作为原型阶段的占位数据。

在确认页面结构能够覆盖主要功能以后，我接受了该原型方案，并将其作为后续正式系统页面设计的参考。

7.3.5 最终结果

通过 AI
辅助原型设计，我在正式编码之前就能够看到系统的大致页面效果，也能够提前检查是否存在功能页面遗漏的问题。

相比直接进行前端编码，先完成原型能够降低后续修改页面结构的成本。

AI协作案例二：原型设计

7.4 案例三：使用AI辅助生成项目并完成本地运行

7.4.1 背景

原型设计完成以后，我开始进入正式编码阶段。

由于项目包含后端、数据库、数据分析和多个前端页面，如果完全从空项目开始搭建，需要花费较多时间。因此，我让
AI
根据前面已经确定的需求和原型生成项目的基础结构，再由我负责本地部署、运行和测试。

7.4.2 我的Prompt

我向 AI 提出的主要需求为：

现在根据已经完成的需求分析和原型设计，帮我实现一个可以实际运行的顶会热词统计项目。

要求：

1. 使用Python Flask作为后端；
2. 使用SQLite保存论文数据；
3. 前端使用HTML、CSS、JavaScript；
4. 使用ECharts实现数据可视化；
5. 实现论文数据导入；
6. 实现论文增删改查；
7. 实现Top 10热门研究方向；
8. 实现关键词图谱；
9. 实现关键词与论文联动；
10. 实现历年热度走势；
11. 项目结构尽量清晰，能够直接在本地运行。

7.4.3 AI输出

AI 根据前面的需求生成了项目的基本目录结构，主要包括：

conference_hot_topic_analysis/
├── app.py
├── database.py
├── analysis.py
├── crawler.py
├── requirements.txt
├── README.md
├── COMMIT_PLAN.md
├── templates/
├── static/
├── data/
└── tests/

不同文件分别负责 Web
服务、数据库操作、数据分析、数据获取以及前端页面等功能。

AI 同时给出了项目运行方式：

python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt
python app.py

项目启动后，通过浏览器访问：

http://127.0.0.1:5000

即可进入系统。

7.4.4 我的实际操作

获得项目代码以后，我没有直接认为 AI 生成的代码就是最终结果，而是按照 AI
给出的步骤在自己的电脑上进行实际运行。

首先配置 Python 环境，然后创建虚拟环境并安装项目依赖，最后执行：

python app.py

启动 Flask 服务。

经过实际配置和运行后，项目能够正常启动，我也成功通过浏览器进入系统页面。

之后，我继续逐个测试首页、论文管理、数据导入、Top
10、关键词图谱以及热度走势等功能。

7.4.5 我的判断

这一阶段让我明显感受到，AI
能够快速生成项目基础代码，但"生成代码"和"项目真正能够运行"并不是同一件事情。

AI
无法代替我完成本地环境中的实际验证。项目是否能够启动、依赖是否正确安装、页面是否能够访问、按钮是否正常工作，都必须经过实际运行以后才能确认。

因此，我将 AI 生成的代码视为开发起点，而不是未经验证的最终答案。

7.4.6 最终结果

经过本地配置和实际运行，系统能够正常启动，并通过浏览器访问。

这一案例中，AI
主要提高了项目搭建和代码编写的效率，而我主要负责环境配置、运行测试以及结果确认。

AI协作案例三：项目实现与运行

7.5 案例四：DBLP数据获取失败后的问题分析与方案调整

7.5.1 问题背景

在项目能够正常运行以后，我尝试使用系统的数据导入功能从 DBLP
在线获取论文数据。

在执行批量获取时，系统出现了以下错误：

批量获取失败：Expecting value: line 1 column 1 (char 0)

此时系统本身能够正常打开，其他页面也能够访问，因此问题并不是 Flask
服务没有启动，而是在在线数据获取过程中出现了异常。

7.5.2 我的Prompt

出现错误后，我将实际运行结果和错误截图反馈给 AI，希望 AI 帮助分析问题。

我的问题主要为：

我已经成功运行项目并进入网页，但是在进行论文批量获取时出现：

批量获取失败：Expecting value: line 1 column 1 (char 0)

应该怎么处理？

7.5.3 AI分析

AI 根据错误信息判断，该异常与 JSON 数据解析有关。

Expecting value: line 1 column 1 (char 0)
通常表示程序尝试将返回内容解析为 JSON 时，没有得到符合预期的 JSON 数据。

AI
分析可能与在线接口响应、网络环境或者返回内容异常有关，同时提出了两种处理思路：

方案一：
继续检查DBLP接口请求以及crawler.py中的数据获取逻辑，
增强异常处理，继续使用真实在线数据。

方案二：
使用项目内置演示数据完成系统主要功能测试，
保证论文管理、Top 10、关键词图谱和热度走势等功能稳定展示。

7.5.4 我的决策

在分析两个方案以后，我最终选择了第二种方案，即使用系统内置演示数据完成本次作业的功能展示。

主要原因是本次作业的核心目标不仅包括论文数据获取，还包括完整的软件工程实践过程、论文数据管理、关键词统计、数据可视化以及人机结对过程。

继续花费大量时间处理外部接口问题会影响后续 Git
管理、功能测试和博客整理。

因此，我没有为了让博客看起来更加完整而将演示数据描述为真实爬取数据，而是在成品展示中明确说明：

本次系统功能展示采用系统内置演示数据。
演示数据用于验证论文管理、关键词统计、
关键词图谱和趋势分析等功能，
相关统计结果不代表真实顶会研究方向排名。

7.5.5 最终结果

加载演示数据以后，系统的论文管理、Top 10
热门方向、关键词图谱以及热度走势等功能可以继续正常运行。

这个案例也是本次 AI 结对过程中比较有代表性的一次协作。

AI
并没有直接替我决定必须选择哪一种方案，而是帮助我分析错误以及可能的解决方向。最终是否继续修复在线数据获取功能，还是优先保证整个项目稳定完成，则由我根据作业时间、项目目标和实际运行情况进行选择。

AI协作案例四：错误分析与方案调整

7.6 AI生成内容的接受与舍弃

在整个项目开发过程中，我并没有直接接受 AI
给出的全部内容，而是根据实际运行情况进行选择和调整。

AI建议或生成内容是否接受原因

使用 Flask 作为后端接受框架轻量，能够满足本项目需求

使用 SQLite 保存论文数据接受项目规模较小，不需要额外部署数据库服务器

使用 ECharts 进行数据可视化接受能够实现柱状图、折线图和关键词关系图

先完成原型再进行正式编码接受能够提前确定页面结构，减少后续修改

使用 DBLP 作为在线论文数据来源部分接受系统保留相关功能，但实际运行受到网络或接口响应影响

继续修复 DBLP 在线获取问题暂不采用为保证整体项目进度，最终展示改用演示数据

使用内置演示数据进行功能测试接受能够稳定验证论文管理、统计分析和可视化功能

将原型中的示例数字作为统计结果不接受原型数据仅用于展示界面，不能作为真实统计结论

AI生成代码直接作为最终结果不接受必须经过本地运行和功能测试后才能确认是否可用

通过这一过程，我认为与 AI 结对编程时非常重要的一点是保持自己的判断。

AI
可以快速提供代码和解决方案，但开发者仍然需要判断这些内容是否符合需求、是否能够实际运行以及是否适合当前项目。

7.7 人机结对过程总结

通过本次项目，我实际体验了一次从需求分析、原型设计、代码实现到问题排查的人机结对开发过程。

在需求分析阶段，AI
能够快速帮助我整理功能范围和技术方案；在原型设计阶段，AI
可以根据文字需求快速生成可运行的页面；在编码阶段，AI
能够减少项目基础结构和重复代码的编写工作；在出现运行问题以后，AI
也可以根据错误信息提供问题分析和解决方向。

但在实际使用过程中，我也发现 AI 并不能完全替代开发者。

例如，AI
生成的项目仍然需要在真实环境中安装依赖并进行运行测试；原型中的示例数据需要人为判断其性质，不能直接当作真实统计结果；在线接口出现异常以后，也需要开发者根据项目目标和时间成本决定是否继续修复。

因此，我认为比较合理的人机结对模式不是：

人提出需求 → AI完成全部工作

而应该是：

人提出需求
    ↓
AI分析并给出方案
    ↓
人进行判断
    ↓
AI辅助实现
    ↓
人实际运行和测试
    ↓
发现问题后反馈给AI
    ↓
AI提供修改方案
    ↓
人决定接受、修改或舍弃

在这个过程中，AI
更像是一名能够快速提供思路和代码的结对伙伴，而开发者仍然需要负责需求判断、方案选择、实际测试以及最终决策。

这也是本次项目中我对"AI结对编程"最直接的理解。

八、关键代码说明

本项目主要采用 Python + Flask + SQLite 完成后端开发，并使用
HTML、CSS、JavaScript 和 ECharts 完成前端页面及数据可视化。

项目没有将所有业务逻辑集中在单个文件中，而是按照不同功能进行了简单的模块划分。其中
app.py 主要负责 Flask 应用和路由，database.py
负责数据库操作，analysis.py
负责关键词统计与数据分析，前端页面则负责将后端处理后的结果进行可视化展示。

下面选取项目中几个具有代表性的功能，对其核心实现思路进行说明。

8.1 Flask应用初始化

系统后端使用 Flask 框架实现。

核心逻辑如下：

from flask import Flask

app = Flask(__name__)

if __name__ == "__main__":
    app.run(debug=True)

Flask 应用对象 app 是整个 Web 系统的入口。

系统启动后，Flask 负责监听浏览器请求，并根据不同 URL
将请求分发到对应的处理函数。

在项目根目录执行：

python app.py

即可启动本地 Web 服务。

项目运行后，通过浏览器访问：

http://127.0.0.1:5000

即可进入系统。

采用 Flask
的主要原因是本项目规模较小，业务逻辑主要集中在论文数据管理、关键词分析和数据可视化等功能，不需要使用结构更加复杂的后端框架。Flask
配置简单，也便于将数据分析结果通过接口传递给前端。

8.2 SQLite数据库连接

本项目使用 SQLite 对论文数据进行持久化存储。

数据库连接的核心思路如下：

import sqlite3

def get_connection():
    conn = sqlite3.connect("data/papers.db")
    conn.row_factory = sqlite3.Row
    return conn

其中：

sqlite3.connect("data/papers.db")

用于建立与 SQLite 数据库文件之间的连接。

设置：

conn.row_factory = sqlite3.Row

以后，可以更加方便地按照字段名称读取查询结果，而不仅仅通过数组下标访问数据。

使用 SQLite 的优点是无需额外部署 MySQL
等数据库服务器，一个数据库文件即可完成论文数据存储，比较适合本项目的规模和使用场景。

8.3 论文数据表设计

论文数据是整个系统进行关键词分析和可视化的基础。

论文表的核心字段可以表示为：

CREATE TABLE IF NOT EXISTS papers (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title TEXT NOT NULL,
    conference TEXT,
    year INTEGER,
    authors TEXT,
    url TEXT
);

其中：

id：论文唯一编号；
title：论文标题；
conference：论文所属会议；
year：论文发表年份；
authors：论文作者信息；
url：论文相关链接。

数据库初始化时，如果数据表不存在，则自动创建相应的数据表。

通过统一的数据表保存论文信息以后，论文管理、关键词统计、Top 10
热门方向以及热度走势等功能都可以基于数据库中的论文数据进行处理。

8.4 演示数据加载

为了保证系统在外部数据源暂时不可用时仍然可以完成完整的功能测试，项目设计了演示数据加载功能。

其核心逻辑可以概括为：

demo_papers = [
    {
        "title": "Example Paper A",
        "conference": "CVPR",
        "year": 2023
    },
    {
        "title": "Example Paper B",
        "conference": "CVPR",
        "year": 2024
    }
]

for paper in demo_papers:
    add_paper(
        paper["title"],
        paper["conference"],
        paper["year"]
    )

演示数据按照与普通论文数据相同的结构进行组织。

加载过程中，程序遍历演示论文，并通过统一的数据库操作函数将数据写入
SQLite。

因此，无论数据来自在线接口、CSV
文件还是演示数据，进入系统以后都可以按照统一的数据结构进行管理和分析。

本次项目最终成品展示主要采用演示数据。演示数据仅用于验证系统的数据管理、统计分析以及数据可视化流程，不作为真实顶会研究趋势的统计依据。

8.5 论文新增功能

论文管理模块支持向数据库中新增论文。

核心逻辑如下：

def add_paper(title, conference, year):
    conn = get_connection()

    conn.execute(
        """
        INSERT INTO papers (title, conference, year)
        VALUES (?, ?, ?)
        """,
        (title, conference, year)
    )

    conn.commit()
    conn.close()

这里使用参数化 SQL：

VALUES (?, ?, ?)

而不是直接通过字符串拼接生成 SQL 语句。

论文标题、会议和年份等参数通过：

(title, conference, year)

传递给 SQLite。

执行 INSERT 操作后，通过：

conn.commit()

提交数据库事务，使新增的数据真正保存到数据库文件中。

8.6 论文查询功能

为了方便用户快速查找论文，系统实现了论文查询功能。

核心思路如下：

def search_papers(keyword):
    conn = get_connection()

    rows = conn.execute(
        """
        SELECT *
        FROM papers
        WHERE title LIKE ?
        ORDER BY year DESC
        """,
        (f"%{keyword}%",)
    ).fetchall()

    conn.close()

    return rows

查询时使用 SQL 中的：

LIKE

进行模糊匹配。

例如用户输入：

Transformer

程序可以构造：

%Transformer%

从而查询标题中包含该关键词的论文。

相比要求用户输入完整论文标题，模糊查询能够提高论文检索的便利性。

8.7 论文修改与删除

除了新增和查询之外，系统还提供论文修改和删除功能，从而实现基本的 CRUD
数据管理。

论文修改的核心思路如下：

def update_paper(paper_id, title, conference, year):
    conn = get_connection()

    conn.execute(
        """
        UPDATE papers
        SET title = ?, conference = ?, year = ?
        WHERE id = ?
        """,
        (title, conference, year, paper_id)
    )

    conn.commit()
    conn.close()

系统根据论文的唯一 id 定位需要修改的数据，然后使用 UPDATE
更新相应字段。

论文删除的核心思路如下：

def delete_paper(paper_id):
    conn = get_connection()

    conn.execute(
        "DELETE FROM papers WHERE id = ?",
        (paper_id,)
    )

    conn.commit()
    conn.close()

删除操作同样根据论文 id 定位对应记录。

通过新增、查询、修改和删除等功能，系统实现了论文数据的基本 CRUD 管理。

8.8 关键词统计

关键词统计是本项目数据分析部分的核心功能之一。

其基本处理流程可以表示为：

读取论文数据
    ↓
获取论文标题
    ↓
文本规范化
    ↓
拆分单词
    ↓
过滤停用词
    ↓
统计词频
    ↓
按照出现次数排序

核心代码思路如下：

from collections import Counter

STOP_WORDS = {
    "a", "an", "the", "of", "for",
    "and", "in", "on", "with", "to"
}

def extract_keywords(titles):
    words = []

    for title in titles:
        tokens = title.lower().split()

        for token in tokens:
            if token not in STOP_WORDS:
                words.append(token)

    counter = Counter(words)

    return counter.most_common()

首先使用：

title.lower()

将英文文本统一转换为小写，减少大小写不同造成的重复统计。

然后将标题拆分为单词，并过滤部分常见停用词，例如：

the
of
for
and
in

这些词虽然可能频繁出现，但是通常不能直接反映论文的研究方向，因此在统计时进行过滤。

最后使用：

Counter(words)

统计各关键词的出现次数。

关键词统计结果将继续用于 Top 10、关键词图谱以及其他分析功能。

8.9 Top 10热门研究方向

在完成关键词统计以后，可以按照关键词出现次数进行排序，并选取排名靠前的关键词作为热门研究方向。

核心逻辑可以表示为：

def get_top_keywords(titles, limit=10):
    keywords = extract_keywords(titles)
    return keywords[:limit]

其中：

keywords[:limit]

用于获取排名靠前的关键词。

当：

limit = 10

时，即得到 Top 10 关键词。

后端可以将结果转换为前端需要的数据格式：

result = [
    {
        "keyword": keyword,
        "count": count
    }
    for keyword, count in top_keywords
]

然后通过 Flask 接口返回给前端。

前端获取数据后，再使用 ECharts 绘制对应图表。

这种设计将：

数据统计

与：

图表展示

进行了分离。

Python 负责完成数据分析，ECharts
负责最终可视化，从而使程序结构更加清晰。

8.10 ECharts数据可视化

前端使用 ECharts 将后端统计结果转换为图表。

以 Top 10 热门方向为例，其核心配置思路如下：

const chart = echarts.init(
    document.getElementById("top10-chart")
);

const option = {
    tooltip: {},
    xAxis: {
        type: "value"
    },
    yAxis: {
        type: "category",
        data: keywords
    },
    series: [
        {
            type: "bar",
            data: counts
        }
    ]
};

chart.setOption(option);

其中：

echarts.init()

用于初始化图表。

keywords 保存关键词名称，counts 保存对应的关键词出现次数。

通过：

type: "bar"

指定使用柱状图进行展示。

最终调用：

chart.setOption(option);

将配置应用到页面中的图表容器。

相比直接通过表格展示关键词出现次数，图表能够更加直观地体现不同关键词之间的热度差异。

8.11 关键词图谱

关键词图谱主要用于展示不同关键词之间的关系。

后端需要将关键词数据整理为节点和关系，例如：

nodes = [
    {"name": "deep learning"},
    {"name": "transformer"},
    {"name": "computer vision"}
]

links = [
    {
        "source": "deep learning",
        "target": "transformer"
    },
    {
        "source": "deep learning",
        "target": "computer vision"
    }
]

前端使用 ECharts 的关系图进行展示：

const option = {
    series: [
        {
            type: "graph",
            layout: "force",
            data: nodes,
            links: links,
            roam: true,
            label: {
                show: true
            }
        }
    ]
};

其中：

type: "graph"

表示使用关系图。

layout: "force"

表示采用力引导布局。

roam: true

允许用户对图谱进行缩放和移动。

通过节点和连线，可以比普通关键词列表更加直观地展示关键词之间的联系。

8.12 关键词与论文联动

为了让关键词统计结果能够进一步关联到具体论文，系统设计了关键词与论文之间的联动功能。

其核心思想是：

用户选择关键词
    ↓
前端获取当前关键词
    ↓
向后端发送查询请求
    ↓
后端查询相关论文
    ↓
返回论文数据
    ↓
前端展示相关论文

后端可以根据关键词查询论文：

def get_papers_by_keyword(keyword):
    conn = get_connection()

    rows = conn.execute(
        """
        SELECT *
        FROM papers
        WHERE title LIKE ?
        """,
        (f"%{keyword}%",)
    ).fetchall()

    conn.close()

    return rows

用户选择某个关键词以后，通过该关键词筛选标题中包含相关内容的论文。

这种设计使用户不仅能够看到抽象的关键词节点，还能够进一步查看与该研究方向相关的具体论文，提高可视化结果的可解释性。

8.13 历年热度走势统计

热度走势功能需要在关键词统计的基础上进一步加入年份信息。

基本处理过程为：

读取论文
    ↓
按照年份分组
    ↓
统计每年关键词出现次数
    ↓
按照年份排序
    ↓
返回前端
    ↓
绘制折线图

核心逻辑可以表示为：

from collections import defaultdict

def keyword_trend(papers, keyword):
    trend = defaultdict(int)

    for paper in papers:
        title = paper["title"].lower()
        year = paper["year"]

        if keyword.lower() in title:
            trend[year] += 1

    return sorted(trend.items())

这里使用：

defaultdict(int)

保存不同年份对应的关键词出现次数。

程序遍历论文数据，如果论文标题中包含目标关键词，则对对应年份的计数进行增加。

最后：

sorted(trend.items())

按照年份进行排序。

前端获得年份和热度数据以后，再使用 ECharts 折线图完成可视化。

例如：

const option = {
    xAxis: {
        type: "category",
        data: years
    },
    yAxis: {
        type: "value"
    },
    series: [
        {
            type: "line",
            data: values
        }
    ]
};

通过这种方式，系统可以从时间维度展示某个关键词在不同年份中的变化情况。

本次项目使用演示数据进行趋势功能展示，因此折线图主要用于验证系统的趋势统计和可视化功能，不作为真实顶会研究趋势的结论。

8.14 前后端数据交互

本项目的统计分析由 Python 后端完成，而图表展示由 JavaScript 和 ECharts
完成，因此前后端之间需要进行数据交互。

后端接口可以将 Python 数据转换为 JSON：

from flask import jsonify

@app.route("/api/top10")
def top10():
    data = get_top_keywords()
    return jsonify(data)

前端通过 fetch() 获取数据：

fetch("/api/top10")
    .then(response => response.json())
    .then(data => {
        console.log(data);
        // 根据返回结果更新ECharts图表
    });

这样形成了：

SQLite数据库
    ↓
Python读取数据
    ↓
analysis.py完成统计
    ↓
Flask接口返回JSON
    ↓
JavaScript获取数据
    ↓
ECharts完成可视化

通过这种结构，数据存储、数据分析以及前端展示之间的职责更加清晰。

8.15 核心数据处理流程总结

整个系统的核心数据处理过程可以概括为：

演示数据 / CSV数据
        ↓
    数据导入
        ↓
 SQLite数据库
        ↓
    论文管理
        ↓
 Python数据分析
        ↓
 ┌──────┼──────────┐
 ↓      ↓          ↓
Top 10 关键词图谱  热度走势
 ↓      ↓          ↓
 └──────┼──────────┘
        ↓
   Flask接口
        ↓
HTML + JavaScript
        ↓
     ECharts
        ↓
  最终可视化结果

从实现上看，本项目没有使用复杂的算法，而是将重点放在完整的数据处理流程上。

论文数据首先进入 SQLite
数据库，通过统一的数据管理模块进行维护；数据分析模块再根据论文信息完成关键词频率、关键词关系以及历年趋势等统计；最后由
Flask 将结果提供给前端，通过 ECharts 完成可视化。

这样的模块划分使论文数据管理、数据分析和页面展示之间保持相对独立，也方便后续继续增加新的统计方式或可视化功能。

8.16 本章小结

本章选取了项目中的部分关键实现，对数据库操作、论文 CRUD、关键词统计、Top
10
热门方向、关键词图谱、关键词与论文联动、热度走势以及前后端数据交互等功能进行了说明。

其中，SQLite 负责论文数据的持久化存储，Python
负责论文数据处理和关键词分析，Flask 负责 Web
服务以及前后端数据交互，ECharts 负责将分析结果以图表形式进行展示。

通过将不同功能进行模块化处理，项目形成了从数据导入、数据存储、数据分析到数据可视化的完整流程。

虽然本次最终成品展示采用演示数据，但演示数据与其他数据进入系统后的处理流程基本一致，因此仍然能够用于验证论文管理、关键词分析以及可视化等核心功能是否能够正常运行。

九、遇到的问题与解决过程

在本次项目开发过程中，并不是所有功能都能够一次完成。从环境配置、项目运行，到数据获取和最终功能展示，都遇到了一些实际问题。

在解决这些问题的过程中，我主要采用了"实际运行 → 观察错误 → 分析原因 → 向
AI 反馈 → 尝试解决方案 → 再次验证"的方式。

下面记录几个开发过程中比较有代表性的问题。

9.1 问题一：项目本地运行环境配置

9.1.1 问题描述

在项目代码基本完成以后，首先需要解决的问题是如何在自己的电脑上真正运行项目。

由于本项目使用 Python Flask 作为后端，并依赖多个 Python
第三方库，因此仅仅拥有项目源代码还不能直接完成系统运行，还需要正确配置
Python 环境以及项目依赖。

项目的运行过程包括：

安装Python
    ↓
进入项目目录
    ↓
创建虚拟环境
    ↓
激活虚拟环境
    ↓
安装requirements.txt中的依赖
    ↓
运行app.py
    ↓
浏览器访问Flask服务

9.1.2 解决过程

首先在项目根目录创建 Python 虚拟环境：

python -m venv .venv

然后激活虚拟环境：

.venv\Scripts\activate

激活成功后，命令行前会出现：

(.venv)

然后安装项目依赖：

pip install -r requirements.txt

依赖安装完成后执行：

python app.py

当终端出现类似：

* Running on http://127.0.0.1:5000

说明 Flask 服务已经成功启动。

最后通过浏览器访问：

http://127.0.0.1:5000

成功进入系统首页。

9.1.3 解决结果

完成环境配置以后，项目能够在本地正常启动，浏览器也能够正常访问系统页面。

通过这个问题，我进一步理解了"代码生成完成"和"项目真正能够运行"之间的区别。

AI
可以帮助生成代码以及提供环境配置步骤，但项目最终能否运行仍然需要开发者在真实环境中完成依赖安装、服务启动以及页面访问等验证。

Flask
本地开发服务器成功启动

9.2 问题二：DBLP批量获取出现JSON解析错误

9.2.1 问题描述

项目成功运行以后，我尝试通过数据导入页面在线获取论文数据。

在执行批量获取时，系统出现了以下错误：

批量获取失败：Expecting value: line 1 column 1 (char 0)

由于此时系统首页和其他页面均能够正常访问，因此可以判断 Flask
服务本身已经正常运行，问题主要出现在外部数据获取阶段。

9.2.2 问题分析

将错误信息反馈给 AI 后，对错误进行了进一步分析。

错误信息：

Expecting value: line 1 column 1 (char 0)

通常出现在程序进行 JSON 数据解析时。

程序原本希望从在线接口得到符合预期的 JSON
数据，但实际返回内容没有成功解析为 JSON。

可能涉及的因素包括：

外部接口没有返回预期的数据；
网络环境导致请求异常；
返回内容为空；
返回内容不是程序预期的 JSON 格式；
在线接口响应发生变化。

因此，该问题与项目中的在线数据获取过程有关，而不是前端页面或 Flask
服务无法运行。

9.2.3 可选解决方案

针对这个问题，当时考虑了两种方案。

第一种方案是继续调试在线数据获取功能。

可以进一步检查请求状态码、接口返回内容以及 crawler.py
中的数据解析逻辑，并增加异常处理。

第二种方案是使用项目已经准备好的演示数据。

因为本项目除在线获取数据之外，还需要完成：

论文数据管理
关键词统计
Top 10热门方向
关键词图谱
关键词与论文联动
历年热度走势

因此，即使暂时不使用在线数据，也可以通过演示数据继续验证系统的核心业务流程。

9.2.4 最终解决方法

综合项目进度以及作业主要目标后，我最终选择使用系统内置演示数据完成成品展示。

进入：

数据导入

页面后，选择：

加载演示数据

系统即可获得用于测试的论文数据。

随后依次测试论文管理、Top
10、关键词图谱以及热度走势等页面，主要功能能够继续正常运行。

9.2.5 解决结果

虽然最终没有继续处理 DBLP
在线获取异常，但是通过演示数据保证了系统其他主要功能能够正常进行测试和展示。

同时，在最终博客中，我也明确将这些数据标记为"演示数据"，没有将演示数据的统计结果描述为真实顶会论文统计结果。

这个问题让我认识到，在实际开发中，外部服务属于系统之外的依赖。当外部服务出现异常时，系统如果具有测试数据、缓存数据或者其他备用方案，可以减少外部环境对核心功能测试的影响。

9.3 问题三：原型中的模拟数据容易与真实数据混淆

9.3.1 问题描述

在原型设计阶段，为了快速展示系统页面效果，我使用了模拟论文数量、热门关键词、趋势数据以及示例论文等内容。

例如原型中的统计卡片、Top 10
图表和趋势图都需要一定的数据才能显示完整效果。

但这些数据只是为了展示：

页面布局
图表效果
交互逻辑
功能结构

并不是通过真实顶会论文统计得到的数据。

如果在后续博客中直接使用这些数字，并将其描述成真实分析结果，就会造成原型数据和真实统计数据之间的混淆。

9.3.2 解决方法

因此，我将不同开发阶段的数据进行了明确区分：

原型阶段数据
→ 用于展示UI和交互效果

演示数据
→ 用于测试正式系统的数据处理和可视化功能

真实在线数据
→ 应通过外部论文数据源获取后再进行统计

在最终成品展示中，对相关图表统一增加说明：

本次成品展示采用系统内置演示数据，
演示数据用于验证论文管理、关键词统计、
关键词图谱和趋势分析等功能，
不代表真实顶会研究方向的实际统计结果。

9.3.3 解决结果

通过明确区分原型数据、演示数据和真实数据，使博客中的系统展示与项目实际运行情况保持一致。

这个问题也让我认识到，数据可视化不仅要关注"图表能不能显示"，还需要关注"图表中的数据来自哪里"。

如果数据来源没有说明清楚，即使图表本身实现正确，也可能导致错误的分析结论。

9.4 问题四：AI生成代码不代表功能一定能够直接使用

9.4.1 问题描述

本项目采用 AI 结对编程，因此部分项目结构、代码实现以及运行方案由 AI
辅助完成。

AI 的优势是能够快速生成代码，但是在实际开发过程中发现：

AI能够生成代码
≠
代码一定能够在本地正常运行

例如，AI 可以根据需求生成数据获取功能，但真正运行以后仍然可能受到：

本地Python环境
第三方依赖
操作系统
网络环境
外部接口
数据格式

等因素影响。

DBLP 在线获取出现异常就是一个比较明显的例子。

9.4.2 解决方法

因此，在后续开发过程中，我没有直接将 AI
输出作为最终结果，而是形成了以下工作方式：

向AI提出需求
      ↓
AI生成方案或代码
      ↓
在本地实际运行
      ↓
检查页面和功能
      ↓
发现错误
      ↓
将错误反馈给AI
      ↓
分析解决方案
      ↓
人工判断是否采用
      ↓
再次运行验证

对于 AI 生成的代码，至少需要检查：

项目是否能够正常启动；
页面是否能够正常访问；
数据是否能够正确显示；
功能按钮是否能够正常操作；
数据库操作是否符合预期；
图表是否能够正常生成；
错误情况是否会影响其他功能。

9.4.3 解决结果

通过实际运行和人工检查，我能够及时发现 AI
生成内容中可能存在的问题，并根据项目目标决定继续修改还是采用其他方案。

这也让我认识到，人机结对编程中的"人"并不是简单负责输入 Prompt。

开发者仍然需要承担测试、判断、取舍和最终确认的责任。

9.5 问题五：原型设计与最终系统之间需要保持一致

9.5.1 问题描述

本项目在正式编码之前先完成了 Web 原型设计。

原型中已经规划了：

首页
Top 10热门方向
关键词图谱
热度走势
论文列表
数据导入
论文详情
关于页面

进入正式编码阶段后，如果完全脱离原型重新设计页面，就会导致前期原型设计失去意义，同时也可能出现：

原型中有功能，但成品中没有

或者：

成品增加大量功能，但原型没有体现

的问题。

9.5.2 解决方法

因此，在正式系统开发时，我将原型页面和系统功能进行了对应：

原型功能正式系统实现

首页系统数据总览
Top 10热门方向关键词频率统计与图表
关键词图谱 ECharts关键词关系图
热度走势历年关键词趋势图
论文列表 SQLite论文数据管理
数据导入在线获取、CSV导入、演示数据加载
论文详情单篇论文信息展示
关于页面项目相关信息说明

在后续开发中，尽量保持原型阶段已经确定的页面结构，同时根据实际实现情况调整细节。

9.5.3 解决结果

最终系统的主要功能与前期原型能够形成较好的对应关系。

这样既能够体现"先设计、再编码"的软件工程开发过程，也方便在博客中展示从原型到最终成品的变化。

9.6 问题六：如何控制项目复杂度

9.6.1 问题描述

在项目设计阶段，可以选择的技术和功能非常多。

例如前端可以使用 Vue、React，数据库可以使用
MySQL，后端也可以使用更加复杂的框架，还可以继续增加用户系统、权限管理、推荐算法等功能。

但是本次作业的时间有限，如果不断增加功能和技术复杂度，可能出现：

功能很多
但核心功能没有完成

或者：

技术栈复杂
但项目无法稳定运行

的问题。

9.6.2 解决方法

经过需求分析以后，我将项目目标确定为：

优先完成核心功能
>
保证系统能够运行
>
保证功能能够展示
>
最后再考虑扩展功能

因此最终采用：

Flask
+
SQLite
+
HTML/CSS/JavaScript
+
ECharts

作为主要技术方案。

同时将主要开发精力集中在：

论文管理
Top 10
关键词图谱
关键词与论文联动
热度走势

这些与"顶会热词统计"直接相关的功能上。

9.6.3 解决结果

通过控制技术和功能范围，项目最终不仅能够在本地正常运行，还完成了腾讯云服务器部署，并形成从论文数据管理到数据统计、可视化展示和公网访问的完整流程。

这个过程让我认识到，软件开发并不是使用的技术越多越好。

对于一个具体项目而言，选择能够满足需求并且自己能够控制的技术方案，比单纯增加技术复杂度更加重要。

9.7 问题七：云服务器部署与Nginx配置

9.7.1 问题描述

在项目本地运行成功后，我进一步尝试将系统部署到腾讯云服务器。服务器使用
TencentOS Server 4，初始环境中虽然已经安装 Python 3.11，但还需要补充
pip、Git、虚拟环境以及项目依赖等运行条件。

项目上传并解压后，我先使用 Flask
开发服务器验证项目能够在服务器上启动，随后安装
Gunicorn，并将应用绑定到：

127.0.0.1:8000

为了让应用能够在退出 SSH 后继续运行，又进一步创建了 systemd 服务。

在配置 Nginx 反向代理时还出现了：

conflicting server name "_" on 0.0.0.0:80, ignored

的警告。检查配置后发现，Nginx 默认配置与项目配置都使用了：

server_name _;

从而产生 server name 冲突。

9.7.2 解决过程

首先确认 Gunicorn 服务能够正常运行：

systemctl status conference-hot-topic

服务状态显示：

Active: active (running)

随后检查 Nginx 中所有监听 80 端口以及 server_name
的配置，定位到默认配置与项目配置之间的冲突。

最终保留 Nginx 默认配置，将项目配置中的：

server_name _;

修改为服务器实际公网 IP：

server_name 1.15.91.93;

再使用：

nginx -t

检查配置语法。确认配置正确后重新加载 Nginx，使公网 80 端口的请求转发到
Gunicorn。

9.7.3 解决结果

完成 Gunicorn、systemd 和 Nginx 配置后，浏览器能够通过：

http://1.15.91.93

正常访问顶会热词统计系统。

这次部署让我进一步理解了开发服务器与生产部署之间的区别：Flask
自带服务器适合开发调试，而公网部署还需要考虑后台进程管理、反向代理、端口监听以及服务器网络配置等问题。

9.8 问题解决过程总结

本次项目中遇到的问题可以总结如下：

问题原因或现象最终处理方式

本地环境配置项目需要Python及第三方依赖使用虚拟环境并安装requirements.txt

DBLP批量获取失败在线返回内容无法按预期解析为JSON 最终使用演示数据完成稳定展示

原型数据与真实数据容易混淆原型需要模拟数据展示页面明确标注模拟数据和演示数据

AI代码不能直接视为最终结果实际环境与AI生成条件存在差异本地运行、测试并人工判断

原型与成品可能产生差异设计和编码属于不同阶段建立原型功能与正式功能对应关系

项目复杂度控制可选技术和扩展功能较多优先完成与题目直接相关的核心功能

云服务器部署 Gunicorn后台运行及Nginx默认站点配置冲突使用systemd管理Gunicorn，并修改Nginx项目server_name后完成反向代理

通过这些问题的解决过程，我逐渐形成了一套比较明确的开发思路：

先明确需求
    ↓
完成原型
    ↓
实现功能
    ↓
实际运行
    ↓
发现问题
    ↓
分析原因
    ↓
选择解决方案
    ↓
重新测试
    ↓
记录开发过程

相比单纯完成一个能够展示的页面，我认为这些实际遇到的问题以及解决过程更能体现软件工程实践的特点。

尤其是在 AI 结对编程的情况下，AI
能够帮助分析问题、提供代码和提出解决方案，但最终仍然需要开发者根据实际运行结果判断方案是否可行。

因此，本次实践让我认识到，AI
可以明显提高开发效率，但"运行、测试、验证和决策"仍然是开发过程中不可缺少的环节。

十、心路历程与收获

完成这次"顶会热词统计"项目以后，回顾整个开发过程，我最大的感受是：这次作业并不只是完成一个能够运行的程序，更重要的是实际经历了一次相对完整的软件工程实践过程。

从最开始阅读题目、分析需求，到原型设计、项目编码、本地运行、问题排查，再到云服务器部署和博客整理，我对软件项目从"想法"变成"可以实际访问的程序"有了更加具体的认识。

同时，这也是我第一次比较完整地将 AI
作为结对伙伴参与整个开发过程，因此除了编程方面的收获之外，我对如何正确使用
AI 辅助软件开发也有了新的理解。

10.1 从"不知道怎么开始"到逐步拆解任务

刚看到"顶会热词统计"这个题目时，我首先想到的是需要获取论文、统计关键词并进行数据可视化。但是如果真正开始实现，就会发现其中还包含页面设计、数据存储、功能划分、运行环境、版本管理、测试和部署等许多问题。

如果一开始就直接写代码，很容易出现写到一半才发现功能缺失或者整体结构不合理的问题。因此，我先借助
AI 对整个任务进行拆解，逐步形成了下面的开发过程：

需求分析
    ↓
NABCD分析
    ↓
原型设计
    ↓
技术选型
    ↓
数据库与项目结构设计
    ↓
功能实现
    ↓
数据分析与可视化
    ↓
本地运行与测试
    ↓
问题排查
    ↓
云服务器部署
    ↓
Git版本管理与博客整理

这让我认识到，面对一个相对完整的软件工程任务时，先进行任务分解和阶段规划，比直接进入编码更容易控制项目进度。

10.2 从"代码生成"到"真正运行"

在使用 AI
进行编程时，最容易产生的一种错觉是：代码生成出来以后，项目就已经完成了。

实际开发过程中我发现，真正让一个项目运行起来还需要处理很多代码之外的问题，例如
Python 环境、虚拟环境、第三方依赖、数据库文件、网络请求和服务器配置等。

本项目在本地运行时需要创建虚拟环境并安装 requirements.txt
中的依赖；部署到腾讯云以后，还需要安装和配置 Gunicorn、systemd 和
Nginx。

尤其是在服务器部署过程中，最终形成的访问链路为：

浏览器
    ↓
腾讯云公网IP
    ↓
Nginx
    ↓
Gunicorn
    ↓
Flask
    ↓
SQLite

当浏览器最终能够通过 http://1.15.91.93
打开项目页面时，我对"项目完成"的理解也发生了变化：不仅要有代码，还要能够在真实环境中稳定运行和被用户访问。

10.3 对 Flask、SQLite 和 ECharts 的实际认识

本次项目让我把之前比较零散的技术知识组合到一个完整项目中。

Flask 负责 Web 路由和后端业务逻辑；SQLite 负责保存论文数据；HTML、CSS 和
JavaScript 负责页面展示与交互；ECharts 则负责 Top
10、关键词图谱和热度走势等数据可视化。

通过实际实现，我更加清楚地理解了前端、后端、数据库和数据分析之间的数据流转关系：

用户操作
    ↓
前端发送请求
    ↓
Flask处理业务
    ↓
SQLite读取或修改数据
    ↓
Python完成统计分析
    ↓
后端返回结果
    ↓
ECharts进行可视化展示

相比只学习单独的语法或
API，把这些技术放在同一个项目中使用，更容易理解不同模块之间为什么需要进行划分。

10.4 DBLP获取失败带来的收获

项目中让我印象比较深的问题是 DBLP 批量获取时出现：

Expecting value: line 1 column 1 (char 0)

这个问题让我认识到，外部接口并不是项目中完全可控的一部分。网络环境、接口响应和数据格式都可能影响程序运行。

在项目进度有限的情况下，我没有为了"看起来功能更完整"而把在线获取结果描述成已经成功，而是选择使用系统内置演示数据继续完成论文管理、关键词统计和可视化流程，并在博客中明确说明演示数据不代表真实顶会排名。

这让我认识到，软件工程中除了"实现功能"，还需要对结果的真实性和可验证性负责。对于没有真正运行成功的部分，应当明确说明，而不是为了文档完整而将其写成已经完成。

10.5 对原型设计作用的重新认识

在正式编码之前完成原型设计，一开始更多是为了满足作业要求。但在后续开发中，我发现原型实际上帮助我提前确定了页面结构和主要功能。

首页、Top 10
热门方向、关键词图谱、热度走势、论文管理和数据导入等页面，在原型阶段已经确定了基本关系，因此正式编码时可以按照这些模块逐步实现。

这让我认识到，原型并不只是最终报告中的一张效果图，而是需求与代码之间的过渡。原型越清楚，后续开发时越容易判断某个功能应该放在哪里、用户应该如何操作。

10.6 对AI结对编程的认识变化

项目开始时，我更倾向于把 AI 当成一个"快速生成答案和代码"的工具，希望通过
Prompt 直接得到可以使用的结果。

但随着项目推进，我逐渐发现更有效的方式是：

提出问题
    ↓
AI给出方案
    ↓
自己判断
    ↓
实际运行
    ↓
发现问题
    ↓
把结果反馈给AI
    ↓
继续修改
    ↓
再次验证

例如 DBLP 获取失败时，AI
可以根据错误信息给出可能原因，但无法仅凭一条报错确定唯一根因；服务器部署时，AI
可以提供配置步骤，但每一步是否真正成功仍然需要我通过终端输出和浏览器访问进行确认。

因此，我认为 AI
更适合作为一个能够快速提供思路、代码和排查方向的结对伙伴，而不是替代开发者完成判断。

10.7 云服务器部署带来的新认识

项目后期将系统部署到腾讯云服务器，是本次实践中一个新的体验。

最开始项目只能通过：

http://127.0.0.1:5000

在自己的电脑上访问。部署以后，项目可以通过：

http://1.15.91.93

从公网浏览器访问。

在这个过程中，我接触了 Linux SSH 操作、虚拟环境、Gunicorn、systemd 和
Nginx，并实际处理了 Nginx server_name 冲突等问题。

这部分经历让我更加直观地理解了"本地开发"和"项目部署"的区别，也让我认识到一个
Web
项目从代码到真正对外提供服务，中间还存在运行环境、进程管理、反向代理和网络端口等环节。

10.8 本次实践的主要收获

综合整个项目，我认为自己的主要收获可以概括为以下几个方面：

学会先分析需求再进行编码。
通过 NABCD 和原型设计，先明确项目解决什么问题以及需要实现哪些功能。
理解了小型 Web 项目的基本结构。
对 Flask、SQLite、前端页面和 ECharts
之间的协作方式有了更加具体的认识。
提高了实际运行和排查问题的能力。
不再只关注代码是否生成，而是关注依赖、环境、错误信息和实际运行结果。
完成了从本地运行到公网部署的过程。
实际使用腾讯云、Gunicorn、systemd 和 Nginx 将项目部署到服务器。
更加重视数据和结论的真实性。
对演示数据、原型模拟数据和真实在线数据进行区分，不把未验证的结果描述成真实统计结论。
形成了更加合理的 AI 使用方式。
将 AI
用于方案讨论、代码辅助和问题分析，同时保留自己的判断、测试和最终决策。

10.9 后续可以改进的方向

虽然目前系统已经完成主要功能并实现公网部署，但仍然存在进一步改进的空间。

首先，可以继续完善 DBLP
在线数据获取功能，在请求过程中增加状态码检查、返回内容验证、重试机制和更完整的异常处理。

其次，目前关键词统计方法相对基础，后续可以尝试更完善的关键词提取方式，提高研究主题统计结果的准确性。

再次，可以进一步完善系统的部署方式，例如配置域名和
HTTPS，使公网访问更加规范。

最后，还可以继续优化前端交互和数据展示，使关键词图谱、趋势分析和论文检索之间的联动更加自然。

10.10 本章小结

这次实践让我真正经历了一个项目从需求分析、原型设计、编码、测试到部署的过程。

项目过程中既有顺利完成的部分，也有 DBLP 在线获取失败、环境配置和 Nginx
冲突等实际问题。正是这些问题让我认识到，软件工程并不是简单地"把代码写出来"，而是需要不断进行分析、实现、测试、验证和调整。

同时，通过与 AI 的多轮协作，我也更加明确了人与 AI 在开发过程中的分工：AI
可以提高信息获取、方案生成和基础实现的效率，而开发者仍然需要负责需求理解、真实环境验证、结果判断以及最终决策。

十一、人机结对与人人结对的思考

通过本次"顶会热词统计"项目，我第一次比较完整地体验了将 AI
作为结对伙伴参与软件开发的过程。

传统的结对编程通常由两名开发者共同完成，一人负责当前代码编写，另一人负责观察、检查和思考，两个人之间不断交换意见和角色。而本次作业将其中的一名开发者替换成了
AI，因此在人机协作方式、沟通效率以及问题处理方式上，都与传统的人人结对存在明显区别。

11.1 人机结对的优势

11.1.1 响应速度快

我认为人机结对最明显的优势是响应速度。

在本次项目中，从最开始的需求分析，到后面的原型设计、技术选型、项目结构设计，再到代码实现和错误分析，我都可以直接向
AI 提出问题。

例如，在确定技术方案时，我只需要描述项目需求，AI 就能够快速给出：

Flask + SQLite + HTML/CSS/JavaScript + ECharts

这样的技术组合，并进一步分析不同技术分别适合解决什么问题。

如果采用传统的人人结对方式，两个人可能需要先查阅资料，再讨论采用什么技术。而
AI 可以在较短时间内给出多个可选方案，因此能够减少前期的信息检索时间。

11.1.2 AI拥有较广的知识覆盖范围

本次项目涉及的内容并不只有 Python 编程，还包括：

需求分析
原型设计
Flask
SQLite
HTML/CSS/JavaScript
ECharts
Git
CodeArts
软件测试
博客撰写

如果全部依靠自己逐项查阅资料，需要在不同网站和文档之间不断切换。

AI 可以同时针对这些不同领域的问题提供帮助。

例如，我既可以询问 Flask 项目如何运行，也可以继续询问 SQLite
数据库设计，还可以让 AI 帮助分析 ECharts 图表应该如何展示。

因此，在涉及多个技术领域的小型项目中，AI
可以起到一个"综合型助手"的作用。

11.1.3 适合处理重复性和基础性工作

软件开发过程中存在不少重复性的工作，例如：

建立项目目录
编写基础CRUD代码
整理数据结构
生成页面基础结构
编写运行说明
整理开发文档

这些工作本身并不一定具有很高的技术难度，但是比较耗费时间。

本次项目中，AI
帮助完成了一部分基础代码和文档框架，使我可以把更多时间用于项目运行、功能检查以及最终方案选择。

因此，我认为 AI 很适合承担开发过程中的基础性和重复性工作。

11.1.4 可以随时进行多轮修改

与 AI 结对时，如果第一次得到的答案不符合要求，可以继续补充条件。

例如：

第一次：
先让AI给出整体实现方案

第二次：
限制项目复杂度

第三次：
要求项目能够直接在本地运行

第四次：
根据实际运行结果继续修改

这种方式使 Prompt 本身也成为了开发过程的一部分。

开发者不需要一开始就将所有需求描述得完全准确，而是可以通过多轮交流逐渐明确最终需求。

11.2 人机结对的不足

虽然 AI
能够明显提高部分工作的效率，但在实际使用以后，我也发现它与真正的人类结对伙伴仍然存在区别。

11.2.1 AI无法代替真实环境中的运行验证

这是本次实践中感受比较明显的一点。

AI 可以告诉我：

python app.py

应该如何启动项目，也可以生成数据获取相关代码，但它给出的代码是否能够在我的电脑上真正运行，仍然需要实际测试。

例如本次项目的 DBLP
数据获取功能，在设计层面具有完整的处理流程，但是实际运行时出现了：

Expecting value: line 1 column 1 (char 0)

这样的异常。

这说明：

AI认为代码逻辑可行

并不等于：

代码在真实环境中一定能够成功运行

网络、操作系统、依赖版本、外部接口以及数据格式都可能影响程序最终运行结果。

11.2.2 AI有时会给出"看起来正确"的内容

AI生成内容通常结构比较完整，因此很容易让人产生"应该没有问题"的感觉。

但如果不进行检查，其中仍然可能存在：

与实际项目不完全一致
假设了不存在的数据
忽略真实运行环境
将示例结果误认为真实结果

等问题。

例如，本项目原型中的统计数字只是用于页面展示。如果没有人为检查，就有可能错误地将这些数字描述成真实的顶会统计结果。

因此，与 AI
结对时，开发者需要保持判断，而不能因为回答看起来完整就直接接受。

11.2.3 AI对项目现场信息的了解有限

传统的人人结对中，两名开发者可以共同查看同一台电脑上的：

代码
终端
运行结果
文件结构
IDE
浏览器

并针对当前状态直接讨论。

而与 AI 协作时，我需要主动将错误信息、代码、截图或者项目情况告诉 AI。

如果提供的信息不完整，AI 就只能根据已有信息进行推测。

因此，人机结对中"如何准确描述问题"本身也是一项重要能力。

11.3 人人结对的优势

经过本次人机结对以后，我也进一步理解了传统人人结对的一些优势。

首先，人类开发者更容易理解项目当前的真实上下文。

如果两个人共同开发同一个项目，双方都可以直接看到当前代码和运行状态，不需要不断通过文字重新描述背景。

其次，人与人之间更适合进行开放性的讨论。

例如在进行功能取舍时，两名开发者可以结合：

实现成本
个人经验
时间安排
项目要求
代码维护

共同做出判断。

此外，人人结对还能够进行真正的代码互审。一名开发者编写代码时，另一名开发者可以实时观察代码逻辑，并立即指出潜在问题。

11.4 人人结对的不足

人人结对同样存在一定限制。

首先，两个人的时间必须进行协调。

如果两名开发者不能同时进行开发，结对效率就会受到影响。而 AI
基本可以在需要时立即进行交互。

其次，两个人掌握的知识范围可能比较接近。

当双方都不了解某项技术时，仍然需要额外查询资料。而 AI
可以快速提供相关背景知识以及可能的解决方案。

最后，人与人之间的讨论通常需要一定沟通成本。

对于一些简单问题，如果只是查找 API
用法、生成基础代码或者解释错误信息，直接询问 AI 的效率可能更高。

11.5 两种结对方式的比较

通过本次实践，我对人机结对和人人结对进行了如下总结：

对比维度人机结对人人结对

响应速度通常较快，可以立即进行多轮交流需要双方时间协调

知识范围覆盖范围广，适合快速查询不同领域问题取决于两名开发者自身经验

项目上下文需要开发者主动提供代码、错误和运行情况双方可以共同观察项目状态

基础代码生成效率较高通常需要开发者手动完成

真实环境验证仍然需要开发者实际操作两人可以共同运行和检查

创意讨论可以快速产生多个方案更容易结合实际经验深入讨论

错误判断可能基于不完整信息进行推测可以直接结合项目环境分析

沟通成本 Prompt描述越准确，结果通常越有效需要双方持续交流

最终决策必须由开发者判断可以由两名开发者共同讨论

我认为这两种结对方式并不是简单的替代关系。

AI 的优势主要体现在：

快速获取信息
快速生成方案
处理重复工作
辅助分析问题

而人类开发者的优势更多体现在：

理解真实项目环境
判断需求是否合理
验证程序运行结果
结合实际情况进行取舍
承担最终决策责任

11.6 我认为更合理的人机协作方式

经过这次实践，我认为 AI 最适合承担的角色不是：

替开发者完成整个项目

而是：

开发者的高效率辅助工具和结对伙伴

比较合理的协作流程应该是：

开发者提出需求
        ↓
AI提供方案
        ↓
开发者判断方案
        ↓
AI辅助实现
        ↓
开发者实际运行
        ↓
发现问题并反馈
        ↓
AI辅助分析
        ↓
开发者选择解决方案
        ↓
重新测试与验证

在这个过程中，AI
可以提高开发效率，但项目方向和最终结果仍然由开发者控制。

如果未来继续进行类似项目，我仍然愿意使用 AI
进行结对编程，但会更加重视代码检查、实际运行以及结果验证，而不是直接使用
AI 的第一次回答。

11.7 本章小结

通过本次作业，我认为人机结对和人人结对各有特点。

人机结对最大的优势是速度快、知识覆盖广、能够快速生成基础内容；而人人结对在理解真实项目环境、共同决策以及代码互审方面仍然具有优势。

AI
的出现并不意味着开发者不再需要学习软件工程知识。相反，当代码生成速度提高以后，开发者判断代码是否正确、需求是否合理、数据是否可信以及方案是否适合当前项目的能力变得更加重要。

因此，我认为未来的软件开发更可能是"人负责需求、判断和决策，AI负责辅助分析和提高效率"的协作模式，而不是简单地让
AI 取代整个开发过程。

十二、对AI结对伙伴的评价

经过本次"顶会热词统计"项目从需求分析到最终成品展示的完整过程，我对 AI
作为结对编程伙伴有了更加具体的认识。

如果只从第一次使用的感觉来看，AI
最明显的特点是"快"。但是经过完整项目实践以后，我认为评价 AI
不能只看代码生成速度，还需要考虑代码质量、需求理解、问题分析、实际运行以及开发者对结果的控制等方面。

因此，下面从几个方面对本次 AI 结对伙伴进行评价。

12.1 需求理解能力

在项目开始阶段，我向 AI
提供了"顶会热词统计"的作业要求以及希望控制项目复杂度的需求。

AI 能够根据这些信息快速整理出：

论文数据导入
论文管理
Top 10热门方向
关键词图谱
关键词与论文联动
热度走势

等主要功能，并进一步提出 Flask + SQLite + ECharts 的技术方案。

这一阶段 AI 对需求的整理比较有效。

特别是在项目刚开始、自己还没有形成完整开发思路时，AI
能够帮助快速将比较宽泛的题目转化成具体功能。

但 AI
给出的需求分析仍然需要开发者根据作业要求进行检查，不能完全代替人工阅读题目和评分标准。

12.2 编程辅助能力

在编码阶段，AI 能够根据已经确定的功能快速生成项目结构和基础实现。

例如项目被划分为：

app.py
database.py
analysis.py
crawler.py
templates/
static/
data/
tests/

这样的结构，使不同功能具有基本的模块划分。

对于 Flask 路由、SQLite CRUD、数据分析以及 ECharts
页面等常见开发任务，AI 能够较快提供代码框架。

因此，在"从零开始搭建项目"这个阶段，AI 对提高开发效率有比较明显的帮助。

12.3 调试辅助能力

本次项目中比较典型的问题是 DBLP 批量获取时出现：

Expecting value: line 1 column 1 (char 0)

在我将错误信息反馈给 AI 后，AI 能够根据错误内容将问题定位到 JSON
解析和外部接口响应这一方向，并进一步提出继续调试在线接口或者使用演示数据两种思路。

这一过程说明 AI 在解释错误信息和提供排查方向方面比较有帮助。

但是需要注意，AI
当时并不能仅凭这一条错误信息确定唯一根因，因此相关分析只能作为排查方向，而不能直接作为已经验证的结论。

最终我根据项目进度选择使用演示数据，也体现了开发者仍然需要负责最终方案取舍。

12.4 文档辅助能力

除了代码以外，本次项目还需要完成：

PSP
NABCD需求分析
原型说明
系统设计
成品展示
AI结对记录
关键代码说明
问题总结
实践反思

等大量文档内容。

AI
在整理这些内容时能够快速建立文章结构，并将开发过程中比较零散的信息整理成相对完整的文字。

对于软件工程实践这种既需要代码又需要大量过程记录的作业而言，这项能力能够减少重复性的文字整理工作。

不过文档同样需要人工检查。

特别是涉及：

项目是否真正实现某项功能
Git操作是否真正完成
数据是否真实
程序是否真正运行成功

这些内容时，不能因为 AI 自动生成了一段描述，就直接写入最终博客。

12.5 AI结对伙伴的优点

综合本次项目实践，我认为 AI 作为结对伙伴主要具有以下优点：

响应速度快

可以快速回答开发过程中出现的问题，不需要等待另一名开发者有空。
知识覆盖范围广

能够同时辅助 Python、Flask、SQLite、JavaScript、ECharts、Git
等不同内容。
代码生成效率高

对于基础项目结构、CRUD 和常见功能，可以快速生成参考实现。
适合进行方案讨论

当一个问题存在多种解决方式时，可以快速给出不同方案供开发者比较。
能够辅助错误分析

可以根据报错信息提供可能原因以及排查方向。
文档整理能力较强

可以将开发过程整理成结构化内容，减少重复的文档编写工作。
适合进行多轮迭代

如果第一次结果不符合需求，可以不断补充条件并继续修改。

12.6 AI结对伙伴的不足

经过实际使用，我认为 AI 也存在一些比较明显的不足。

1. 无法保证生成代码一定能够直接运行

AI 生成的代码需要在实际环境中进行验证。

环境、依赖、网络以及第三方接口都可能导致实际结果和预期不同。

2. 可能根据不完整信息做出推测

如果开发者只提供一个错误提示，而没有提供完整代码、日志和运行环境，AI
的分析就可能只是若干可能原因之一。

3. 容易生成"形式完整但未经验证"的内容

AI 很容易生成结构完整的代码、文档甚至统计说明。

但"看起来完整"并不能证明内容已经通过实际测试。

4. 对真实项目状态的感知有限

如果没有主动提供文件、代码、截图或者错误日志，AI
并不知道本地项目现在真正处于什么状态。

5. 最终仍然需要人工判断

AI
可以给出多个方案，但是哪一个方案适合当前项目，需要开发者结合需求、时间和实际环境做出决定。

12.7 如果再次进行AI结对编程，我会如何改进

经过本次实践，如果以后再次使用 AI
进行软件开发，我会对协作方式进行一些调整。

首先，在提问时提供更加完整的上下文。

相比：

这个报错怎么办？

我会尽量提供：

运行环境
相关代码
完整报错
预期结果
实际结果
已经尝试过的方法

这样 AI 得到的信息越完整，分析结果通常也会越准确。

其次，我会尽量将大型需求拆分成小任务。

例如不直接要求：

帮我完成整个项目

而是拆分为：

先设计数据库
↓
实现论文CRUD
↓
完成关键词统计
↓
实现Top 10
↓
实现关键词图谱
↓
实现趋势分析
↓
逐项测试

这样更容易检查每一步是否真正完成。

最后，我会更加重视测试。

以后使用 AI 生成代码后，我会优先执行：

运行
→ 测试
→ 检查
→ 修改

而不是：

生成
→ 直接使用

12.8 对本次AI结对伙伴的总体评价

通过本次项目，我认为 AI
是一个效率很高的编程辅助伙伴，但并不是一个可以完全替代开发者的"自动编程工具"。

在本次项目中，AI 对我帮助最大的地方主要是：

帮助整理需求
帮助确定技术方案
辅助完成原型
快速搭建项目结构
提供代码实现思路
分析运行错误
整理项目文档

而我仍然需要完成：

理解作业要求
选择最终方案
配置本地环境
实际运行项目
检查系统功能
判断数据性质
处理方案取舍
确认最终结果

因此，我对本次人机结对最大的感受可以概括为：

AI能够提高"完成工作的速度"，但开发者必须负责"判断工作的结果"。

如果开发者本身不了解项目逻辑，只是复制 AI
生成的内容，那么当程序出现问题时会很难继续处理。

相反，如果把 AI
当作一个可以随时讨论问题、快速提供代码和思路的结对伙伴，再由开发者负责验证和决策，就能够更好地发挥
AI 在软件开发中的作用。

本次作业也让我从最开始的"让 AI 帮我写代码"，逐渐转变为"让 AI
提供方案，我负责判断、运行和验证"。

我认为这种变化本身就是本次 AI 结对编程实践中比较重要的收获。

...全文

40 回复打赏收藏举报

写回复

用AI写文章

切换为时间正序

请发表友善的回复…

发表回复

为了实现这一需求，我选择了使用 Selenium 驱动的 WebDriver 来加载网页，并利用 JSoup 来解析网页的内容。本次作业让我学习了网页数据爬取的相关操作，也让我对 Java 编程的基本语法和异常处理机制的使用等更加熟练。然而，这种方法在处理动态内容时存在问题，因为页面中的奖牌数据是只有滚动页面时，新的奖牌数据才会显示出来。正常的输入只需要调用不同的功能接口，而对于异常输入分为两种情况，一种是功能二的不规范日期异常，一种是用户乱输，对于不同的情况就需要做不同的处理。

软件工程实践2019第二次作业转载于:https://www.cnblogs.com/LIU151/p/11532303.html

202601福大-软件工程实践-W班

101

社区成员

172

社区内容

发帖

与我相关

我的任务

软件工程高校福建省·福州市

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章

软件工程实践第二次作业

软件工程实践第二次作业------与AI结对编程（顶会热词统计）

作业基本信息

其他参考文献

目录

一、项目相关链接与AI工具说明

1.1 CodeArts仓库

1.2 代码规范

1.3 项目部署地址

1.4 AI编程助手说明

使用方式 在开发过程中根据当前任务向AI提出问题，并通过多轮对话逐步修改需求和提示词。对于AI给出的方案和代码，由本人进行检查和实际运行，根据运行结果继续要求AI修改和优化。

二、PSP表格

2.1 PSP时间记录

合计 960 1225

2.2 PSP预估与实际耗时分析

三、NABCD需求分析

3.1 N------Need 需求

3.1.1 用户痛点

3.1.2 目标用户

3.1.3 核心需求

3.1.4 用户使用场景

3.2 A------Approach 做法

3.2.1 总体解决方案

3.2.2 论文信息获取方案

3.2.3 热门研究方向分析方案

3.2.4 关键词图谱方案

3.2.5 热度走势分析方案

3.2.6 AI辅助需求分析过程

3.3 B------Benefit 好处

3.4 C------Competitors 竞争

3.4.1 竞品分析

本项目重点 顶会热词统计与趋势可视化 文献检索 论文检索及学术数据 论文关系可视化

3.4.2 本项目的特点

3.4.3 与现有方案的差异

3.5 D------Delivery 推广

四、原型设计

4.1 原型开发工具

4.2 原型设计思路

4.2.1 页面信息架构

4.2.2 UI设计思路

4.2.3 用户操作流程

4.3 AI辅助原型设计

初始Prompt

AI给出的建议

我的判断与修改

AI协作截图

4.4 原型页面展示

4.4.1 首页 / 热门方向总览

4.4.2 Top 10热门方向

4.4.3 关键词图谱

4.4.4 热度走势对比

4.4.5 论文列表管理

4.4.6 论文爬取 / 批量导入

4.4.7 论文详情

4.4.8 关于 / 了解更多

4.5 原型交互逻辑

调整关键词节点 关键词图谱 鼠标拖动节点 改变节点位置并动态调整关系图

页面之间的数据流转关系

五、系统设计与实现过程

5.1 技术选型

技术选型理由

5.2 系统功能结构

5.2.1 功能结构图

5.2.2 系统模块说明

5.3 数据获取与处理

5.3.1 数据来源

5.3.2 数据清洗

5.3.3 关键词提取

5.3.4 热度统计方法

5.4 功能模块设计与实现

5.4.1 功能一：论文信息导入

设计思路

实现过程

实现结果

5.4.2 功能二：论文列表管理

设计思路

实现过程

实现结果

5.4.3 功能三：Top 10热门研究方向

设计思路

使用方式在开发过程中根据当前任务向AI提出问题，并通过多轮对话逐步修改需求和提示词。对于AI给出的方案和代码，由本人进行检查和实际运行，根据运行结果继续要求AI修改和优化。

本项目重点顶会热词统计与趋势可视化文献检索论文检索及学术数据论文关系可视化

调整关键词节点关键词图谱鼠标拖动节点改变节点位置并动态调整关系图

AI生成代码直接作为最终结果不接受必须经过本地运行和功能测试后才能确认是否可用