LLM结合探索CodeArts团队实战总结——CNCC 2026会议管理平台

作业基本信息

这个作业属于哪个课程	2601_FZU_SE
这个作业要求在哪里	LLM结合探索CodeArts团队实战总结
这个作业的目标	基于大语言模型开发CNCC 2026智能会议管理平台，实现会议论坛展示、用户注册登录、论坛报名、角色权限管理及智能论坛推荐等功能，完成系统设计、编码实现与服务器部署，并在实践中掌握AI辅助编程、团队协作和软件工程开发流程。
其他参考文献	CNCC 2026官方网站及论坛议程资料；Vue 3官方文档；Spring Boot官方文档；OpenAI兼容Chat Completions API文档；华为云CodeArts官方文档。

目录

1. 团队分工与协作管理

项目部署地址：CNCC-Hub

1.1 团队成员职责分工

本项目采用多人协同开发模式，团队共8名成员。为提高开发效率、明确责任分工，团队根据系统功能模块及前后端开发依赖关系，将项目划分为后端基础与部署、会议数据管理、用户认证与报名、会议业务管理、LLM智能推荐、前端平台与国际化、前端业务交互以及视觉优化与质量测试八个主要方向。

具体职责分工如下：

成员	姓名	负责角色	主要工作内容
M1	连一帆	架构与部署负责人	后端基础配置、服务器部署、项目文档整合
M2	徐宇扬	会议数据与论坛目录负责人	官方数据包整理、论坛数据导入、会议及论坛查询接口
M3	邱宇翔	账号与报名负责人	JWT身份认证、安全配置、用户注册登录、论坛报名管理
M4	苏涵棋	会议业务负责人	会议及论坛人数统计、通知管理、个人日程与时间冲突检测
M5	李燕玲	智能推荐负责人	本地论坛候选召回、LLM服务接入、推荐结果验证及故障回退
M6	王馨怡	前端平台与国际化负责人	Vue前端基础架构、通用语言资源、论坛标题与简介翻译
M7	林子璇	前端业务负责人	首页及论坛浏览、注册登录、用户报名、AI推荐及角色管理工作台
M8	谢思晨	视觉与质量负责人	全站样式优化、云图背景与鼠标交互效果、日程冲突边界测试

在具体实施过程中，各成员按照模块职责开展开发，并通过接口约定和模块协作完成前后端功能整合。团队在保证各模块相对独立的同时，注重模块之间的数据交互与功能衔接，共同完成CNCC 2026智能会议助手的开发。

1.2 CodeArts仓库

团队使用华为云CodeArts作为项目代码托管与协同开发平台，对项目源代码及相关文档进行统一管理。

项目仓库信息如下：

• 项目仓库名称： [CNCC-Hub]
• CodeArts仓库地址： 仓库地址
• 主要开发语言： Java、JavaScript
• 项目类型： 前后端分离的Web应用

在团队协作过程中，各成员根据事先确定的职责分工开展对应模块的开发，并通过代码提交记录保留开发过程。团队根据模块之间的依赖关系安排开发顺序，优先完成后端基础配置和会议数据接口，再逐步实现用户认证、业务接口及智能推荐功能，随后完成前端页面、国际化资源和视觉优化，最后进行部署配置与项目文档整合。

通过统一的代码仓库和提交记录，团队能够追踪各成员的开发进度，明确功能模块的修改情况，为后续代码整合、问题排查和项目维护提供依据。

1.3 团队Commit记录

为保证团队协作开发的可追溯性，团队将项目开发任务进一步拆分为24个逻辑开发阶段，每名成员负责三个阶段，对应不同的功能模块和代码文件。

具体任务分配如下：

成员	对应开发任务	主要提交内容
M1	C01、C23、C24	后端基础配置、服务器部署、项目文档
M2	C02、C03、C04	官方数据包、论坛数据导入、目录查询接口
M3	C05、C06、C07	身份认证、注册登录、论坛报名
M4	C08、C09、C10	角色统计、论坛通知、个人日程
M5	C11、C12、C13	本地推荐、LLM接入、多服务回退
M6	C14、C15、C16	Vue前端基线、五种语言资源、论坛翻译
M7	C17、C18、C19	首页论坛浏览、用户交互、推荐及管理工作台
M8	C20、C21、C22	全站视觉优化、云图动效、日程边界测试

CodeArts提交记录展示：

通过明确成员职责、细化开发任务和保留代码提交记录，团队实现了开发任务的合理分配与过程管理，也为后续项目维护和团队贡献度评价提供了依据。

2. 项目运行效果与团队开发总结

2.1 系统整体运行效果展示

经过团队成员的协同开发，项目最终实现了一个基于Vue 3和Spring Boot的CNCC 2026智能会议助手。系统采用前后端分离架构，整合会议论坛浏览、用户注册登录、论坛报名、角色权限管理、消息通知、个人参会日程以及LLM智能推荐等功能，为不同角色的会议参与者提供统一的Web服务平台。

系统整体运行效果如下。

（1）会议首页与论坛浏览

系统首页展示CNCC 2026会议基本信息、会议日期、举办地点、论坛数量及主题分类等内容，并通过精选论坛区域展示具有代表性的论坛。用户可以进入论坛目录页面，通过关键词搜索和主题筛选快速查找感兴趣的论坛。

（2）论坛详情与官方议程展示

用户点击论坛卡片后，可以查看论坛类别、主题、主席、所属单位、召开时间、地点、简介、报名人数及信息来源等内容。对于已建立官方议程映射的论坛，还可以进一步查看相关主持人、嘉宾、报告题目、讲者、所属单位及报告摘要等详细信息。

（3）用户注册登录与论坛报名

系统支持普通参会者注册和登录，并通过JWT实现用户身份认证。用户注册成功后，可以登录个人账户，在论坛详情页面选择感兴趣的论坛进行报名，也可以查看已有报名情况并取消报名，实现个人参会信息的管理。

（4）角色管理与参会数据统计

系统根据用户角色提供不同的管理功能。会议主席可以查看会议整体参会人数、论坛数量、报名总数及热门论坛；论坛主席可以查看自己负责论坛的报名人数；秘书可以查询参会者基本信息及其已报名的论坛，实现不同管理角色的业务需求。

（5）论坛通知与个人参会日程

系统提供站内论坛通知功能，论坛主席和秘书可以发布相关通知，参会者能够在通知中心查看自己所报名论坛的消息。同时，系统根据用户的报名情况自动生成个人参会日程，并检测不同论坛之间的时间冲突，为用户合理安排参会计划提供支持。

（6）LLM智能论坛推荐

系统支持用户通过自然语言描述研究方向和参会兴趣，由大语言模型结合现有论坛数据进行智能推荐，并提供相应的推荐理由。用户可以进一步查看推荐论坛的详细信息，并直接进行报名。

（7）多语言与视觉交互效果

系统支持简体中文、繁体中文、英语、德语和日语五种语言，通过统一的语言资源管理机制实现界面切换。同时，页面采用毛玻璃视觉设计、动态云图背景、鼠标粒子拖尾、精选论坛轮播及响应式布局等设计，进一步提升系统的视觉表现和交互体验。

通过以上功能的整合，系统形成了从会议信息浏览、论坛智能推荐、用户报名到个人日程管理及后台业务管理的完整功能体系。

2.2 各组员遇到的困难及解决方法

在项目开发过程中，团队成员分别负责不同的功能模块。由于系统涉及前后端协同、数据库设计、身份认证、外部大模型调用及服务器部署等多个方面，各模块在开发过程中面临着不同的技术问题。团队成员结合实际需求，借助AI Coding工具进行方案分析、代码生成和迭代优化，逐步完成各项开发任务。

（1）M1：连一帆——架构配置与服务器部署

遇到的困难：

项目需要同时支持本地开发、文件持久化运行和服务器MySQL部署，不同环境下的数据库连接及运行配置存在差异。同时，项目还需要兼顾Docker容器化部署和传统服务器部署，前端静态资源、后端API、Nginx反向代理及服务进程之间需要进行合理配置。

解决方法：

采用Spring Profile机制区分不同运行环境，分别配置默认H2数据库、本地文件型H2数据库和MySQL数据库，并通过统一的schema.sql管理数据库结构。在部署方面，提供Docker Compose配置，整合MySQL、Spring Boot和Nginx服务，同时提供systemd和Nginx配置，支持服务器部署。最后整理README、系统架构说明及AI Coding相关文档，完成项目资料整合。

（2）M2：徐宇扬——会议数据与论坛目录管理

遇到的困难：

CNCC官方数据包包含论坛目录、完整会议活动、报告信息及相关人员资料，不同数据文件之间存在结构和编号差异。完整活动列表中还包含开幕式及其他非论坛活动，不能直接将所有活动作为可报名论坛。同时，项目论坛与官方详细议程之间需要建立可靠的关联关系。

解决方法：

对官方数据包进行分类整理，将170场项目论坛作为系统论坛目录，并将官方报告和人员信息保存在独立的议程数据中。通过project-forum-crosswalk建立项目论坛ID与官方编号之间的映射关系，由OfficialProgramService提供关联查询服务。同时保留原始数据、来源说明和质量检查记录，确保论坛信息能够追溯到对应的官方资料。

（3）M3：邱宇翔——账号认证与论坛报名管理

遇到的困难：

系统包含普通参会者、会议主席、论坛主席和秘书等不同角色，需要实现相应的身份认证和权限控制。同时，用户注册、登录及演示账户初始化涉及密码配置、登录状态和数据库数据的一致性；论坛报名还需要避免重复记录，并确保用户只能操作自己的报名信息。

解决方法：

采用Spring Security和JWT实现身份认证及角色权限控制，用户密码通过BCrypt进行编码保存。通过JwtAuthFilter解析登录令牌，并使用SecurityConfig限制不同角色的管理接口访问。注册登录功能由AuthController统一提供，演示账户与登录校验使用相同的DEMO_PASSWORD配置。论坛报名通过RegistrationController实现，并利用用户ID与论坛ID的组合唯一约束避免重复报名。

（4）M4：苏涵棋——会议业务与个人日程管理

遇到的困难：

不同管理角色需要查看不同范围的参会数据，例如会议主席需要统计去重后的参会人数，论坛主席只能查看自己负责的论坛，秘书则需要获取完整参会者名单。此外，论坛通知需要进行权限控制，个人日程还涉及多个论坛之间的时间冲突判断。

解决方法：

根据角色设计独立的数据查询接口，通过registration表中的不同user_id统计会议参会人数，并限制论坛主席只能查看负责论坛的统计信息。通知功能根据发布者角色和参会者报名情况进行权限控制。在个人日程方面，采用时间区间重叠判断条件：

a.start < b.end && b.start < a.end

通过该条件判断两个论坛是否存在时间重叠，论坛首尾相接时不判定为冲突。对于缺少起止时间的论坛，跳过冲突判断；同时支持会议主席和秘书通过后端接口更新论坛时间及地点，并在用户再次查询日程时重新计算冲突情况。

（5）M5：李燕玲——LLM智能论坛推荐

遇到的困难：

智能推荐需要理解用户自然语言描述的研究兴趣，并从系统已有论坛中筛选相关内容。单纯依靠大模型生成论坛名称，容易出现推荐结果与数据库不一致的问题。此外，外部模型服务可能出现超时、调用失败、返回格式异常等情况，影响推荐功能的稳定性。

解决方法：

首先根据论坛标题、主题、简介和单位进行本地关键词匹配，形成候选论坛集合，再调用OpenAI兼容的Chat Completions接口进行筛选和排序。通过限制模型只能返回候选论坛ID、匹配分数和推荐理由，并在后端进行结果校验，确保推荐结果对应真实论坛。

在模型服务方面，采用多服务回退机制，按照SenseNova、TokenRhythm、DeepSeek的顺序调用外部模型。当模型服务不可用或返回结果不符合要求时，继续尝试后备服务；全部失败时，使用本地关键词匹配结果作为回退方案，从而保证推荐功能具有基本可用性。

（6）M6：王馨怡——前端平台与国际化

遇到的困难：

前端需要统一管理不同页面的路由和API请求，同时支持五种语言。如果直接在Vue组件中使用大量if-else判断不同语言，随着页面和翻译内容增加，会导致代码结构复杂、维护困难。此外，论坛标题和简介数量较多，直接放入通用界面翻译文件不利于维护。

解决方法：

使用Vue Router管理页面路由，通过Axios建立统一的API请求实例，实现请求配置和JWT令牌传递。在国际化方面，采用vue-i18n和JSON资源文件管理五种语言的界面文案，通过统一的语言键进行调用，并在缺少翻译时回退到简体中文。针对论坛标题和简介，进一步按照稳定论坛ID建立独立翻译资源文件，使界面翻译与论坛数据翻译相互独立，提高了国际化模块的可维护性。

（7）M7：林子璇——前端业务功能开发

遇到的困难：

前端需要整合论坛浏览、用户登录、论坛报名、LLM推荐、个人日程、消息通知及不同角色的管理工作台。不同业务模块依赖不同的后端API，需要保证请求数据、页面状态和后端业务数据之间的一致性。

解决方法：

依托统一的API请求模块完成前后端数据交互，逐步完善首页、论坛目录、论坛详情、用户登录和报名等页面。在业务功能整合过程中，将LLM推荐、个人日程、通知中心及角色工作台接入统一的前端交互流程。用户完成论坛报名或取消报名后，及时刷新相关数据，使论坛报名状态、个人日程和时间冲突提示保持一致。

（8）M8：谢思晨——视觉优化与质量测试

遇到的困难：

系统采用动态云图背景和毛玻璃视觉设计，需要兼顾背景展示效果、组件透明度和文字可读性。在开发过程中，曾出现弹窗背景过暗、文字对比度不足以及透明度滑块布局溢出等问题。同时，云图背景在循环播放时出现拼接接缝，需要进一步优化。此外，个人日程的时间冲突判断还涉及首尾相接、缺少时间等边界情况。

解决方法：

通过CSS变量统一管理毛玻璃面板、弹窗及输入控件的透明度，并针对不同屏幕宽度调整页面布局。云图背景采用多图块循环方式实现连续运动，通过图块边缘重叠减少拼接缝隙。鼠标粒子效果使用Canvas绘制短寿命彩色粒子，同时保留浏览器默认鼠标指针，并在触屏和减少动态效果的环境下停用。针对日程冲突功能，补充时间重叠、结束时间与开始时间相等以及缺少时间等边界测试用例，完善时间冲突判断的处理逻辑。

通过上述分工与协作，八名成员分别完成了各自负责的功能模块，并共同参与了系统功能整合与项目交付。

2.3 团队成员贡献度评价

本项目采用模块分工与协同开发相结合的方式，各成员围绕自身负责的功能模块开展工作，并通过代码开发、接口联调、功能优化和项目文档整理共同推进项目完成。

团队成员贡献度主要从以下几个方面进行评价：

1. 功能开发贡献： 根据成员负责模块的开发内容、功能复杂度及实际完成情况进行评价。
2. 代码提交贡献： 结合CodeArts实际提交记录，考察成员的代码开发参与情况。
3. 协同配合贡献： 根据成员在前后端联调、模块整合及问题排查中的实际参与情况进行评价。
4. 项目交付贡献： 根据成员在功能完善、系统部署、测试及文档整理等方面的工作进行评价。

团队成员贡献比例统计如下：

成员	姓名	主要贡献	贡献比例
M1	连一帆	项目架构、部署配置及文档整合	14.5%
M2	徐宇扬	官方数据整理、论坛数据导入及查询接口	15%
M3	邱宇翔	用户认证、权限管理及论坛报名	12%
M4	苏涵棋	会议统计、通知管理及个人日程	12.5%
M5	李燕玲	LLM智能推荐及多模型故障回退	13%
M6	王馨怡	前端基础架构及五种语言国际化	11.5%
M7	林子璇	前端业务页面及核心交互功能	10.5%
M8	谢思晨	视觉设计、交互优化及边界测试	11%
合计	8人	—	100%

团队结合各成员负责的功能模块、开发工作量、代码提交情况及项目交付贡献进行综合评价，确定最终贡献比例。

2.4 PSP个人软件过程记录

为记录团队成员在项目开发过程中的工作投入与任务完成情况，团队采用PSP表格，对每位成员在项目开发过程中的需求分析、方案设计、编码实现、测试优化及文档整理等阶段进行记录。

本次团队冲刺周期为两天，PSP记录以两天内各成员承担的主要开发任务为依据，分别统计计划耗时和实际耗时，并通过时间偏差分析任务执行情况。

（1）M1：连一帆

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
需求与架构	后端运行环境及数据库配置规划	2.0	2.0	0.0
编码实现	Spring Boot基础配置及运行环境完善	2.0	2.5	+0.5
部署整合	Docker、Nginx及服务器部署配置	3.0	3.0	0.0
文档整理	README、架构说明及博客材料整合	3.0	3.0	0.0
合计		10.0	10.5	+0.5

（2）M2：徐宇扬

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
数据分析	CNCC官方论坛及议程数据整理	2.0	2.0	0.0
数据处理	论坛主数据整理与导入	3.0	3.5	+0.5
数据关联	官方议程编号映射及详情关联	2.5	3.0	+0.5
接口开发	会议和论坛目录查询接口完善	2.0	2.0	0.0
合计		9.5	10.5	+1.0

（3）M3：邱宇翔

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
方案设计	JWT身份认证与角色权限设计	2.0	2.0	0.0
编码实现	用户注册、登录及演示账户接口	3.0	3.5	+0.5
功能开发	论坛报名、查询及取消报名	3.0	3.5	+0.5
测试优化	登录状态、权限及重复报名处理	1.5	1.5	0.0
合计		9.5	10.5	+1.0

（4）M4：苏涵棋

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
需求分析	会议及论坛管理业务需求分析	1.5	2.0	+0.5
编码实现	会议统计、论坛统计及参会者查询	3.0	3.0	0.0
功能开发	论坛通知发布与查询	2.0	2.5	+0.5
功能优化	个人日程与时间冲突判断	2.0	2.0	0.0
合计		8.5	9.5	+1.0

（5）M5：李燕玲

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
方案设计	智能论坛推荐流程及Prompt设计	2.0	2.0	0.0
编码实现	本地候选召回及LLM接口接入	3.0	3.0	0.0
功能优化	多模型调用及故障回退	3.0	3.5	+0.5
测试验证	推荐结果约束及异常处理	2.0	2.5	+0.5
合计		10.0	11.0	+1.0

（6）M6：王馨怡

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
前端设计	Vue应用入口、路由及API请求设计	1.5	1.5	0.0
编码实现	前端基础架构与统一请求模块	3.0	3.5	+0.5
功能开发	五种语言资源及统一加载机制	3.0	3.0	0.0
功能完善	论坛标题、简介多语言资源整理	2.0	2.0	0.0
合计		9.5	10.0	+0.5

（7）M7：林子璇

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
页面设计	首页及论坛浏览页面规划	1.5	2.0	+0.5
编码实现	首页、论坛目录及详情交互	3.0	3.5	+0.5
功能开发	注册登录及用户报名界面	3.0	3.0	0.0
功能整合	AI推荐、日程、通知及角色工作台	2.0	2.0	0.0
合计		9.5	10.5	+1.0

（8）M8：谢思晨

工作阶段	主要工作内容	计划耗时（h）	实际耗时（h）	偏差（h）
界面设计	全站视觉风格与交互效果设计	1.5	1.5	0.0
编码实现	毛玻璃样式及组件布局优化	3.0	3.0	0.0
功能优化	云图背景、鼠标粒子及动画效果	3.0	3.5	+0.5
测试工作	响应式布局及日程边界测试	2.0	2.0	0.0
合计		9.5	10.0	+0.5

通过PSP个人软件过程记录，团队能够对两天冲刺期间的任务安排和时间投入进行系统整理。各成员围绕自身负责的模块完成需求分析、编码实现及功能整合，在有限的开发周期内协同推进项目建设，也进一步积累了多人协作和AI辅助软件开发的实践经验。

3. 选题展示后的思考与行动

3.1 对老师及同学提出问题的重新思考

在此前心晴屿项目的选题展示过程中，老师针对产品定位提出了一个值得深入思考的问题：

问题：项目与传统番茄钟有什么区别？

重新审视这一问题后，我们认为，心晴屿与传统番茄钟最大的区别在于产品定位和设计理念。传统番茄钟主要围绕时间管理展开，通过设定专注时长、休息间隔和任务目标，帮助用户提高时间利用效率。而心晴屿并不希望仅仅成为一个计时工具，而是希望将任务管理、情绪表达、专注体验与成长激励结合起来，构建更加完整的个人成长陪伴体系。

具体而言，心晴屿将待办任务与专注功能相结合，帮助用户将日常目标转化为具体行动；通过情绪天气表达用户的心理状态，使产品不仅关注任务完成情况，也关注用户在完成任务过程中的情绪体验；同时，通过奖励机制和岛屿成长体系，将用户的日常行动转化为可感知的成长反馈，增强持续使用的动力。

因此，我们认为，番茄钟解决的主要是如何合理安排时间的问题，而心晴屿更加关注如何帮助用户在完成现实任务的同时，关注自身情绪，并通过持续行动获得正向成长。两者虽然都包含专注计时功能，但产品的核心目标和功能组织方式存在明显区别。

这也让我们认识到，在软件项目设计中，不能仅仅通过功能数量体现产品特色，更重要的是明确产品定位，围绕核心用户需求组织功能，形成具有内在联系的完整产品体验。

3.2 团队新的思考与想法

在完成心晴屿项目的Alpha冲刺阶段后，团队成员对软件工程项目开发有了更加深入和具体的认识。相比于最初仅仅关注功能设计和技术实现，我们逐渐意识到，一个软件项目能否顺利完成，不仅取决于技术能力，更取决于需求分析、任务分解、人员分工、进度管理和团队协作等多个方面。

首先，我们认识到，合理分工是提高团队开发效率的重要前提。多人协作并不是简单地将任务平均分配给每个人，而是需要结合项目整体架构、功能模块之间的依赖关系以及成员的技术特点进行安排。明确每个人的职责和任务边界，才能减少重复开发和职责交叉，提高协作效率。

其次，制定科学且切实可行的开发计划至关重要。在实际开发过程中，任务之间往往存在先后依赖关系，部分功能还需要前后端共同配合才能完成。如果计划过于理想化，或者没有充分考虑开发难度和人员实际投入，就容易出现进度失衡、功能整合困难等问题。因此，项目计划不仅要明确最终目标，还需要细化到具体任务、负责人和完成节点，并根据实际开发情况及时调整。

此外，我们也更加深刻地认识到，软件工程强调的是完整的工程过程，而不仅仅是代码编写。从需求分析、总体设计，到模块开发、接口联调、测试优化和最终部署，每个环节都需要得到充分重视。一个功能在单独模块中实现，并不意味着整个系统已经具备相应能力，只有经过合理的接口设计和系统整合，才能真正形成完整的软件产品。

最后，经过前一阶段的实践，我们认识到AI Coding能够有效提高开发效率，但AI生成的代码和技术方案仍然需要开发人员进行分析、检查和验证。合理拆分开发任务、提供明确的需求约束，并通过持续迭代完善AI生成结果，是发挥AI辅助编程价值的重要方式。

3.3 具体改进措施与落实情况

基于心晴屿Alpha冲刺阶段积累的经验，团队将上述认识落实到本次CNCC 2026会议管理平台的开发过程中，在任务组织、协同开发、AI辅助编程和质量管理等方面进行了改进。

（1）提前规划开发任务，明确成员职责

在项目正式开发前，团队根据系统功能和技术架构，将开发工作划分为后端基础与部署、会议数据管理、用户认证与报名、会议业务管理、LLM智能推荐、前端平台与国际化、前端业务交互、视觉优化与质量测试八个方向，分别安排八名成员负责。

同时，将整体开发工作进一步细化为C01—C24共24个逻辑任务，明确每个任务的主要工作内容和负责成员，使开发目标更加具体，减少任务交叉和职责不清的问题。

（2）合理安排开发顺序，加强模块之间的协作

根据各模块之间的依赖关系，团队优先推进后端基础配置、数据库及会议数据接口，再逐步完成用户认证、报名管理、业务接口和LLM推荐功能，并行开展前端基础架构、国际化资源和业务页面开发。

在开发过程中，注重前后端接口约定和模块之间的数据交互，使不同成员负责的功能能够按照统一的业务逻辑进行整合。

（3）利用CodeArts规范团队协作

团队使用华为云CodeArts统一管理项目代码和相关文档，通过代码提交记录跟踪开发进度和代码变更。各成员围绕自身负责的模块开展编码工作，并通过提交记录保留开发成果，为后续代码整合、问题排查和项目维护提供依据。

（4）改进AI Coding使用方式，采用分阶段迭代开发

结合前一阶段的实践经验，本次项目没有简单地让AI一次性生成整个系统，而是根据具体功能拆分开发任务，向AI提供明确的项目背景、功能目标、实现约束和验收标准，再根据实际开发情况进行多轮调整。

例如，在LLM智能论坛推荐功能开发中，团队不仅要求AI实现模型调用，还进一步明确了真实论坛候选约束、多模型调用顺序、异常结果校验和本地回退机制。在官方数据接入过程中，则要求AI区分论坛目录与完整会议活动，并保留官方数据来源及编号映射关系。

通过这种方式，使AI辅助开发更加贴合实际业务需求，也提高了生成代码的可控性。

（5）加强功能整合与问题排查

团队将系统整体运行效果作为开发的重要目标，不仅关注各模块能否独立实现，还注重不同功能之间的衔接。例如，用户修改论坛报名后，需要同步更新个人日程和时间冲突提示；LLM推荐结果需要与真实论坛数据关联，并支持后续查看详情和报名。

同时，针对毛玻璃透明度、云图背景循环以及演示账号登录等实际开发问题，团队结合用户反馈和代码检查进行迭代优化，并将时间冲突边界、推荐异常处理等情况纳入功能检查范围。

通过本次项目的开发实践，团队进一步将心晴屿Alpha冲刺阶段形成的经验运用到新的软件工程项目中，在任务分解、人员协作、进度组织、AI辅助开发和系统整合等方面积累了更加具体的实践经验，也对软件工程中规范化、协作化和迭代式开发的重要性有了更加深刻的认识。

4. 项目需求分析与总体设计

4.1 项目背景与建设目标

2026中国计算机大会（CNCC 2026）是由中国计算机学会主办的计算领域年度学术盛会，于2026年10月21日至24日在成都举办。本届大会以“数聚驱动·智算未来”为主题，设置大会论坛及167个专题论坛，涵盖人工智能、软件工程、计算机网络、数据科学等多个研究领域，为计算机领域的专家学者和科研人员提供学术交流平台。

随着会议规模不断扩大，参会者需要从大量论坛中快速找到符合自身研究兴趣的活动，同时还需要管理个人报名信息、接收论坛通知并合理安排参会时间。传统的会议网站主要提供静态信息展示和人工检索功能，难以充分满足用户个性化的信息获取与参会管理需求。

针对上述问题，本项目设计并实现了CNCC 2026智能会议助手，将会议论坛信息管理、用户报名、角色权限管理与大语言模型智能推荐相结合，构建集信息浏览、智能检索、报名管理和个人日程服务于一体的Web平台。

项目的主要建设目标包括：

1. 会议论坛信息管理： 整理CNCC 2026官方公开数据，建立统一的会议和论坛信息管理体系，为用户提供论坛目录、主题筛选、详细议程及官方资料查询功能。
2. 用户报名与权限管理： 建立多角色用户体系，实现用户注册登录、论坛报名与取消报名，并为会议主席、论坛主席和秘书提供相应的管理功能。
3. LLM智能推荐： 引入大语言模型，使用户能够通过自然语言描述研究兴趣，由系统结合真实论坛数据进行智能匹配，提供个性化论坛推荐及推荐理由。
4. 个人参会服务： 根据用户报名情况生成个人参会日程，自动检测时间冲突，并通过站内通知帮助用户及时获取论坛相关信息。
5. 国际化与用户体验： 提供五种语言支持，并通过响应式布局、毛玻璃效果及动态交互等设计，提升系统的易用性和视觉体验。

最终，项目实现了一个可以通过浏览器直接访问的智能会议管理平台，为CNCC 2026参会者提供更加便捷、个性化的会议服务。

4.2 用户角色与需求分析

根据CNCC 2026会议的实际业务场景，系统主要涉及普通参会者、会议主席、论坛主席和秘书四类用户。不同角色具有不同的业务需求和数据访问权限，因此系统采用基于角色的权限管理机制，为不同用户提供相应的功能入口。

（1）普通参会者（Attendee）

普通参会者是系统的主要使用群体，其核心需求是查找感兴趣的论坛并完成个人参会安排。

主要需求包括：

• 浏览会议介绍、会议议程及论坛目录。
• 通过关键词搜索和主题筛选查找论坛。
• 查看论坛详细信息及关联的官方议程。
• 注册账号并登录系统。
• 通过自然语言描述研究兴趣，获取LLM智能论坛推荐。
• 对感兴趣的论坛进行报名，支持多个论坛的报名、查询和取消。
• 查看个人参会日程及时间冲突提示。
• 接收已报名论坛发布的相关通知。
• 根据需要切换系统显示语言。

（2）会议主席（Conference Chair）

会议主席主要负责了解整个会议的参会情况，关注会议整体参与规模和论坛报名情况。

主要需求包括：

• 查看会议总体参会人数。
• 查看论坛总数量及报名总数。
• 查看报名人数较多的热门论坛。
• 通过整体统计信息了解会议的参与情况。

（3）论坛主席（Forum Chair）

论坛主席主要负责自己所管理的分论坛，关注论坛报名情况，并向参会者发布相关通知。

主要需求包括：

• 查看自己负责的分论坛信息。
• 查看各负责论坛的报名人数。
• 发布所属论坛的相关通知。
• 向已经报名相应论坛的参会者传达会议安排及重要信息。

（4）秘书（Secretary）

秘书主要承担会议参会者信息管理及论坛通知传达等辅助工作。

主要需求包括：

• 查询系统中的参会者信息。
• 查看参会者的基本资料及已报名论坛。
• 发布指定论坛的相关通知。
• 协助论坛主席完成参会信息整理和消息传达。

四类用户的主要需求汇总如下：

用户角色	核心需求	主要功能
普通参会者	查找论坛、报名及管理个人参会信息	论坛浏览、智能推荐、报名管理、个人日程、通知查看
会议主席	掌握会议整体参会情况	会议统计、热门论坛统计
论坛主席	管理负责论坛并关注报名情况	论坛统计、通知发布
秘书	管理参会者信息并协助传达通知	参会者查询、报名信息查看、通知发布

通过上述角色划分，系统将普通参会者的参会服务需求与会议管理人员的业务需求相结合，实现不同角色之间的功能隔离和业务协作。

4.3 系统总体架构与功能模块

（1）系统总体架构

本项目采用前后端分离的Web应用架构，整体由前端展示层、后端业务层、数据存储层及外部智能服务组成。前后端通过REST API进行数据交互，Nginx负责前端静态资源服务和后端接口反向代理。

系统总体架构如下：

flowchart TB
    U["系统用户<br/>参会者 / 会议主席 / 论坛主席 / 秘书"]

    subgraph CLIENT["客户端展示层"]
        B["浏览器"]
        FE["Vue 3 前端应用<br/>Vue Router + Element Plus + vue-i18n"]
        AX["Axios 统一 API 请求模块"]
        B --> FE
        FE --> AX
    end

    subgraph DEPLOY["服务器部署层"]
        N["Nginx<br/>静态页面服务与 /api 反向代理"]
    end

    subgraph BACKEND["后端业务服务层"]
        SEC["Spring Security<br/>JWT 身份认证与角色权限控制"]
        CTRL["Controller API 接口层<br/>会议、论坛、用户认证、报名、通知与管理"]
        SVC["Service 业务逻辑层<br/>ForumQueries / OfficialProgramService<br/>报名管理 / 日程管理 / 通知管理"]
        REC["RecommendationService<br/>智能论坛推荐"]
        KEY["本地关键词召回<br/>筛选候选论坛"]
        LLM["LLM 模型服务提供方链"]

        SEC --> CTRL
        CTRL --> SVC
        SVC --> REC
        REC --> KEY
        KEY --> LLM
        LLM -->|"推荐结果"| REC
        KEY -->|"全部模型服务不可用时回退"| REC
    end

    subgraph DATA["数据存储与资源层"]
        DB[("H2 / MySQL 数据库<br/>会议表 / 用户表 / 论坛表<br/>报名表 / 通知表")]
        SOURCE["CNCC 2026 官方数据资源<br/>论坛主数据 / 官方议程 / 编号映射"]
    end

    U --> B
    AX -->|"HTTPS API 请求"| N
    N -->|"静态资源"| FE
    N -->|"/api 反向代理"| SEC
    SVC <--> DB
    SVC --> SOURCE
    KEY -.->|"读取论坛候选数据"| DB

各层主要职责如下：

• 前端展示层： 基于Vue 3构建完整的GUI界面，负责会议论坛展示、用户交互、智能推荐结果展示及不同角色的管理工作台。
• 后端业务层： 基于Spring Boot构建REST API，负责用户认证、角色权限控制、论坛数据查询、报名管理、消息通知、个人日程及LLM推荐等核心业务。
• 数据存储层： 使用关系型数据库保存会议、用户、论坛、报名记录和通知等业务数据，同时通过项目资源包保存CNCC官方论坛及详细议程数据。
• 外部智能服务层： 通过OpenAI兼容的Chat Completions接口接入多个大语言模型服务，实现自然语言需求理解和论坛智能推荐，并结合本地关键词召回提供备用推荐方案。
• 部署与访问层： 使用Nginx提供前端静态资源访问及API反向代理，后端Spring Boot服务负责处理业务请求。

系统整体请求流程为：用户通过浏览器访问前端页面，前端通过HTTP请求调用后端REST API，后端根据业务需求访问数据库或官方数据资源；在智能推荐场景下，后端进一步调用本地候选召回及外部LLM服务，最终将处理结果返回前端展示。

（2）系统功能模块设计

根据项目需求，系统划分为以下八个主要功能模块：

① 会议信息管理模块

负责会议基本信息及论坛目录的展示，包括会议介绍、会议日期、举办地点、论坛分类、主题筛选、关键词搜索和论坛详情查询等功能。同时，支持查看与官方资料建立映射关系的详细议程信息。

② 用户认证与权限管理模块

负责用户注册、登录及身份认证，采用JWT实现登录状态管理，并根据用户角色限制不同业务接口的访问权限，为四类用户提供相应的功能入口。

③ 论坛报名管理模块

负责用户与论坛之间的报名关系管理，支持用户查询已报名论坛、添加报名和取消报名，并通过数据库约束避免重复报名。

④ 会议业务管理模块

负责会议整体参会人数统计、分论坛报名人数统计、参会者信息查询及论坛通知管理，为会议主席、论坛主席和秘书提供相应的管理功能。

⑤ LLM智能推荐模块

负责接收用户自然语言兴趣描述，通过本地关键词召回形成候选论坛集合，再调用外部大语言模型进行筛选和排序，生成推荐结果及理由，并对模型返回内容进行校验，支持推荐结果查看详情和直接报名。

⑥ 个人日程管理模块

根据用户已报名的论坛自动生成个人参会日程，按照论坛开始时间排序，并通过时间区间判断识别存在重叠的论坛，及时更新报名变化对应的日程和冲突信息。

⑦ 国际化与视觉交互模块

通过统一的语言资源管理机制支持简体中文、繁体中文、英语、德语和日语五种语言。同时提供毛玻璃透明度调节、动态云图背景、鼠标粒子效果、精选论坛轮播和响应式布局等交互体验。

⑧ 系统部署与运行管理模块

负责项目运行环境配置、数据库连接、前后端服务部署和访问代理，支持本地开发、持久化运行及服务器部署。

系统功能模块之间相互协作，共同构成完整的会议管理与参会服务体系。

flowchart TB
    A["CNCC 2026 智能会议助手"]

    A --> B["会议业务功能"]
    A --> C["用户与角色管理"]
    A --> D["智能推荐与系统支撑"]

    %% 会议业务功能
    B --> B1["会议信息服务"]
    B --> B2["参会者服务"]

    B1 --> B11["会议首页展示"]
    B1 --> B12["论坛目录与搜索筛选"]
    B1 --> B13["论坛详情与官方议程"]

    B2 --> B21["论坛报名与取消"]
    B2 --> B22["个人报名记录"]
    B2 --> B23["个人参会日程"]
    B2 --> B24["时间冲突检测"]
    B2 --> B25["论坛通知查看"]

    %% 用户与角色管理
    C --> C1["用户认证与权限管理"]
    C --> C2["会议主席功能"]
    C --> C3["论坛主席功能"]
    C --> C4["秘书功能"]

    C1 --> C11["用户注册与登录"]
    C1 --> C12["JWT 身份认证"]
    C1 --> C13["角色权限控制"]

    C2 --> C21["会议参会人数统计"]
    C2 --> C22["会议数据管理"]
    C2 --> C23["论坛排期调整"]

    C3 --> C31["负责论坛人数统计"]
    C3 --> C32["论坛消息通知发布"]

    C4 --> C41["全部参会者信息查询"]
    C4 --> C42["论坛消息通知发布"]
    C4 --> C43["论坛排期调整"]

    %% 智能推荐与系统支撑
    D --> D1["LLM 智能论坛推荐"]
    D --> D2["系统基础支撑"]

    D1 --> D11["自然语言兴趣输入"]
    D1 --> D12["本地关键词召回"]
    D1 --> D13["LLM 智能筛选与排序"]
    D1 --> D14["推荐理由生成"]
    D1 --> D15["真实论坛匹配与异常回退"]

    D2 --> D21["五种语言支持"]
    D2 --> D22["数据库管理"]
    D2 --> D23["官方会议数据管理"]
    D2 --> D24["统一 API 与异常处理"]
    D2 --> D25["服务器部署"]

    %% 样式
    classDef root fill:#244A73,color:#ffffff,stroke:#244A73,stroke-width:2px;
    classDef module fill:#DCEAF7,color:#244A73,stroke:#6996BC,stroke-width:2px;
    classDef submodule fill:#EAF2F8,color:#315A7D,stroke:#9BB8D0;
    classDef item fill:#F7F9FC,color:#333333,stroke:#B8C7D6;

    class A root;
    class B,C,D module;
    class B1,B2,C1,C2,C3,C4,D1,D2 submodule;
    class B11,B12,B13,B21,B22,B23,B24,B25,C11,C12,C13,C21,C22,C23,C31,C32,C41,C42,C43,D11,D12,D13,D14,D15,D21,D22,D23,D24,D25 item;

4.4 核心技术选型

本项目根据系统功能需求、开发效率和团队技术基础，采用前后端分离的技术方案，主要技术选型如下。

（1）前端技术

技术	主要用途
Vue 3	构建前端应用及页面组件
Vue Router	管理前端页面路由
Element Plus	提供通用UI组件及交互控件
Axios	实现前后端HTTP请求与数据交互
vue-i18n	实现五种语言的国际化管理
CSS	实现页面布局、毛玻璃效果及动态视觉样式

前端采用Vue 3 Composition API组织页面逻辑，通过Vue Router管理页面路由，使用Element Plus构建界面组件，并通过Axios统一处理后端API请求。国际化功能采用vue-i18n与JSON语言资源包相结合的方式，实现界面文本的统一管理和动态切换。

（2）后端技术

技术	主要用途
Java 17	后端主要开发语言
Spring Boot 3.4	构建后端应用及REST API
Spring Security	实现身份认证与角色权限控制
Spring JDBC	实现数据库访问与SQL操作
Bean Validation	实现请求参数校验
JWT	实现用户登录状态及身份令牌管理
BCrypt	实现用户密码安全存储

后端采用Spring Boot构建REST API，通过Controller层接收和处理HTTP请求，结合业务Service完成具体功能逻辑，并使用Spring JDBC访问数据库。身份认证方面采用Spring Security与JWT相结合的方式，用户密码通过BCrypt编码保存，登录后签发有效期为24小时的HMAC-SHA256 JWT，并通过角色授权控制不同管理接口的访问权限。

（3）数据库技术

项目采用关系型数据库管理会议业务数据，核心数据表包括：

数据表	主要存储内容
conference	会议基本信息
user_account	用户账号、密码哈希、个人资料及角色
forum	论坛基本信息、主题、主席、时间和地点
registration	用户与论坛之间的报名关系
notice	论坛通知内容、发布者及发布时间

数据库支持H2和MySQL两种方案：默认使用H2内存数据库进行开发运行，本地持久化运行采用文件型H2数据库，服务器部署则支持MySQL 8.4。通过统一的数据库结构定义和不同运行环境配置，保证系统能够适应不同部署场景。

（4）LLM智能推荐技术

智能推荐模块采用本地关键词召回与外部大语言模型相结合的技术方案。

首先，系统根据用户输入的研究兴趣，从论坛标题、主题、简介和单位等信息中召回相关候选论坛；随后调用OpenAI兼容的Chat Completions接口，由大语言模型对候选论坛进行筛选和排序，并生成推荐理由。

模型服务采用多服务调用机制，按照SenseNova、TokenRhythm、DeepSeek的顺序进行调用。当外部服务不可用或返回结果异常时，系统自动切换备用服务，全部失败时回退到本地关键词匹配结果。同时，后端对模型返回的论坛ID、推荐分数、数据格式和推荐理由进行校验，确保推荐结果与系统实际论坛数据保持一致。

（5）部署与运行技术

技术	主要用途
Nginx	前端静态资源服务及后端API反向代理
Docker Compose	管理MySQL、Spring Boot和Nginx服务
systemd	管理服务器上的后端服务进程
Maven	管理后端项目依赖及构建
npm	管理前端依赖及构建

项目使用Nginx统一提供Web访问入口，并将/api/请求转发至Spring Boot后端。部署方面同时提供Docker Compose和systemd运行方案，支持不同服务器环境下的项目部署。

综上，本项目通过Vue 3与Spring Boot构建前后端分离架构，以关系型数据库为业务数据基础，结合JWT身份认证、LLM智能推荐和国际化技术，实现了会议论坛信息管理与个性化参会服务的有机结合。

5. 数据库设计

5.1 数据库总体设计

本项目采用关系型数据库存储会议管理平台的核心业务数据，数据库结构统一定义在backend/src/main/resources/schema.sql文件中。结合系统的业务需求，数据库主要围绕会议信息、用户信息、论坛信息、论坛报名和消息通知五个方面进行设计。

系统核心业务数据库主要包含以下五张数据表：

1. conference（会议信息表）： 保存CNCC 2026会议的基本信息，包括会议名称、主题、简介、举办日期和会场等。
2. user_account（用户账户表）： 保存系统用户的账号信息、BCrypt密码哈希、显示名称、邮箱及角色信息，为身份认证和权限管理提供数据支持。
3. forum（论坛信息表）： 保存各分论坛的基本资料，包括论坛类型、主题、主席、所属单位、简介、召开时间、地点、确认状态及信息来源等。
4. registration（论坛报名表）： 保存用户与论坛之间的报名关系，记录参会者选择参加的论坛。
5. notice（论坛通知表）： 保存论坛通知正文、发布者及发布时间，并关联对应论坛和发布用户。

其中，用户与论坛之间通过报名表建立多对多关系，通知表用于关联论坛和通知发布者。通过对不同业务数据进行分类存储，降低数据冗余，使各业务模块能够通过统一的数据结构进行交互。

此外，项目将CNCC官方详细议程、报告及人员信息保存在独立的数据资源包中，通过论坛编号映射建立项目论坛与官方议程之间的对应关系。当前系统包含170条论坛目录记录，其中168条建立了可靠的官方议程映射。

数据库总体结构如下：

flowchart TD
    A["CNCC 2026 智能会议助手"] --> B["核心关系型数据库"]
    A --> C["官方议程数据资源包"]

    B --> D["conference<br/>会议信息"]
    B --> E["user_account<br/>用户账户"]
    B --> F["forum<br/>论坛信息"]
    B --> G["registration<br/>论坛报名"]
    B --> H["notice<br/>论坛通知"]

    E --> G
    F --> G
    E --> H
    F --> H

    C --> I["官方议程编号映射"]
    I --> F

在数据库运行环境方面，项目支持多种数据库配置：

• H2内存数据库： 默认运行配置，主要用于开发和快速运行。
• 文件型H2数据库： 通过local配置实现本地数据持久化。
• MySQL 8.4： 用于服务器部署及Docker Compose运行环境。

通过统一的数据库结构定义和不同运行环境配置，保证系统在本地开发与服务器部署场景下的数据结构一致性。

5.2 数据库E-R图

根据系统的核心业务实体及其关联关系，数据库主要涉及会议、用户、论坛、报名记录和论坛通知五类实体。

其中，用户与论坛之间存在多对多关系：一个用户可以报名多个论坛，一个论坛也可以被多个用户报名。系统通过registration报名表将这一多对多关系转换为两个一对多关系。

论坛通知分别关联论坛和发布用户，一个论坛可以包含多条通知，同一个用户也可以发布多条通知。

系统核心实体关系如下：

erDiagram
    CONFERENCE {
        string name
        string theme
        string description
        string date
        string venue
    }

    USER_ACCOUNT {
        int id
        string username UK
        string password_hash
        string display_name
        string email
        string role
    }

    FORUM {
        int id
        string type
        string topic
        string chair
        string organization
        string description
        datetime start_time
        datetime end_time
        string location
        string confirmation_status
        string source
    }

    REGISTRATION {
        int user_id FK
        int forum_id FK
    }

    NOTICE {
        int id
        string content
        string author
        datetime created_at
    }

    USER_ACCOUNT ||--o{ REGISTRATION : "报名"
    FORUM ||--o{ REGISTRATION : "被报名"
    USER_ACCOUNT ||--o{ NOTICE : "发布"
    FORUM ||--o{ NOTICE : "关联"

从E-R图可以看出：

• 用户与论坛通过registration表建立多对多关系。
• 用户与通知之间是一对多关系，一个用户可以发布多条通知。
• 论坛与通知之间是一对多关系，一个论坛可以发布多条通知。
• 会议基本信息独立保存，论坛详细议程通过官方数据资源及编号映射进行关联。

5.3 核心数据表设计

根据项目数据库结构，五张核心数据表的设计如下。

（1）conference——会议信息表

该表用于保存CNCC 2026会议的基本资料，为系统首页和会议介绍页面提供数据支持。

数据内容	说明
会议名称	保存会议名称
会议主题	保存会议主题
会议简介	保存会议相关介绍
举办日期	保存会议举办日期
举办地点	保存会议举办会场信息

（2）user_account——用户账户表

该表用于管理系统用户的基本信息和身份角色，是用户认证及权限管理的基础。

数据内容	说明
用户ID	用户唯一标识
用户名	用户登录账号，具有唯一性约束
密码哈希	保存经过BCrypt编码的密码
显示名称	用户在系统中展示的名称
邮箱	用户联系信息
用户角色	区分普通参会者、会议主席、论坛主席和秘书

通过用户角色字段，系统能够识别不同用户的身份，并结合后端权限配置限制相应业务接口的访问。

（3）forum——论坛信息表

该表是会议管理平台的核心业务数据表，用于保存CNCC 2026各分论坛的基本信息，为论坛目录、详情展示、报名管理和个人日程提供数据支持。

数据内容	说明
论坛ID	论坛唯一标识
论坛类型	区分大会论坛、专题论坛等类型
论坛主题	保存论坛研究主题
论坛主席	保存论坛主席信息
所属单位	保存论坛相关单位
论坛简介	保存论坛详细介绍
开始时间	论坛计划开始时间
结束时间	论坛计划结束时间
举办地点	论坛召开地点
排期确认状态	标记论坛时间安排的确认情况
信息来源	保存论坛信息来源

项目通过官方论坛数据包整理形成论坛主数据，目前系统论坛目录包含170条记录。论坛详细议程通过独立的官方数据资源及编号映射关联，实现论坛基本信息与官方报告、讲者等详细资料的对应。

（4）registration——论坛报名表

该表用于记录用户与论坛之间的报名关系，是连接用户账户表和论坛信息表的重要关联表。

数据内容	说明
user_id	关联用户账户，表示报名用户
forum_id	关联论坛信息，表示报名论坛

该表采用用户ID与论坛ID的组合唯一约束，即同一用户不能重复报名同一个论坛。同时，用户或论坛被删除时，对应报名记录会通过外键级联删除，保证关联数据的一致性。

通过该表，系统能够实现以下业务：

• 查询指定用户已报名的全部论坛。
• 查询指定论坛的报名人数。
• 支持用户新增论坛报名。
• 支持用户取消已有报名。
• 根据不同论坛的报名记录统计会议参会人数。

其中，会议整体参会人数按照报名记录中的不同用户ID进行去重统计，避免同一用户报名多个论坛时被重复计算。

（5）notice——论坛通知表

该表用于保存论坛主席和秘书发布的论坛相关通知，为参会者提供统一的站内消息查询入口。

数据内容	说明
通知ID	通知记录唯一标识
通知正文	保存通知具体内容
发布者	关联通知发布用户
发布时间	保存通知发布时间
关联论坛	确定通知所属的论坛

通知表通过论坛关联确定消息所属范围，并通过发布用户关联记录通知来源。

在业务处理方面，论坛主席只能向自己负责的论坛发布通知，秘书可以选择论坛发布通知。普通参会者查询通知时，系统根据其已报名的论坛进行筛选，从而保证用户获取与自身参会安排相关的消息。

以上五张核心数据表共同构成了系统的数据库基础，为会议展示、用户认证、论坛报名、参会统计和消息通知等功能提供数据支持。

5.4 数据表关联关系

本项目数据库主要通过主键、外键及唯一性约束维护不同业务实体之间的关联关系。

（1）用户账户表与论坛报名表

user_account与registration之间是一对多关系。

一个用户可以产生多条报名记录，每条报名记录对应一个具体用户。通过registration.user_id关联用户账户，实现用户报名信息的查询和管理。

（2）论坛信息表与论坛报名表

forum与registration之间同样是一对多关系。

一个论坛可以对应多条报名记录，每条报名记录对应一个具体论坛。通过registration.forum_id关联论坛信息，实现论坛报名人数统计及报名状态查询。

通过上述两组关系，系统实现了用户与论坛之间的多对多关系：

flowchart LR
    A["user_account<br/>用户账户表"] -->|"一对多"| C["registration<br/>论坛报名表"]
    B["forum<br/>论坛信息表"] -->|"一对多"| C

    C --> D["用户报名查询"]
    C --> E["论坛报名人数统计"]
    C --> F["会议参会人数统计"]

报名表对(user_id, forum_id)设置组合唯一约束，避免重复报名，并通过外键级联删除维护关联数据的一致性。

（3）用户账户表与论坛通知表

user_account与notice之间是一对多关系。

一个用户可以发布多条通知，每条通知关联对应的发布用户。系统根据当前登录用户的角色和权限，判断其是否具有通知发布权限，并记录通知的发布来源。

（4）论坛信息表与论坛通知表

forum与notice之间是一对多关系。

一个论坛可以关联多条通知，每条通知属于一个具体论坛。参会者查询通知时，系统根据用户的论坛报名情况筛选相关消息，实现通知的定向展示。

（5）通知业务关联关系

flowchart TD
    A["user_account<br/>用户账户表"] -->|"发布通知"| C["notice<br/>论坛通知表"]
    B["forum<br/>论坛信息表"] -->|"所属论坛"| C

    D["论坛主席"] -->|"发布自己负责的论坛通知"| A
    E["秘书"] -->|"发布论坛通知"| A

    C --> F["通知查询"]
    G["registration<br/>用户报名记录"] --> F
    F --> H["参会者通知中心"]

（6）数据库关联关系总结

关联数据表	关系类型	关联依据	主要业务作用
user_account — registration	一对多	用户ID	管理用户报名记录
forum — registration	一对多	论坛ID	管理论坛报名记录
user_account — forum	多对多	通过registration关联	实现用户与论坛报名关系
user_account — notice	一对多	发布用户关联	记录通知发布者
forum — notice	一对多	论坛关联	管理各论坛通知

通过上述数据表设计与关联关系，系统实现了会议基本信息、用户账户、论坛资料、报名记录和论坛通知的分类管理，减少了业务数据之间的重复存储，并通过唯一性约束和外键级联机制保证数据关联的完整性，为系统各项业务功能提供了可靠的数据基础。

6. GUI界面设计与用户体验

6.1 系统整体界面设计

本项目采用基于Vue 3的前端架构，围绕CNCC 2026会议场景设计统一的Web交互界面。整体界面以简洁、现代和轻量化为设计方向，将会议论坛信息展示、用户交互及不同角色的业务管理整合到统一的平台中。

在视觉设计方面，系统采用毛玻璃（Glassmorphism）设计风格，通过半透明面板、背景模糊、圆角卡片和层次化阴影营造轻盈的视觉效果。同时，页面底部加入动态云图背景，使整体界面具有一定的动态感和沉浸式体验。

系统整体界面主要包含以下几个设计特点：

（1）统一的页面布局与视觉风格

系统通过统一的品牌标识、导航区域、内容容器和卡片样式组织页面。不同功能页面沿用一致的颜色体系、字体层级、圆角和间距规范，使首页、论坛目录、个人日程及管理工作台保持统一的视觉风格。

（2）毛玻璃组件与透明度调节

页面中的导航栏、论坛卡片、功能面板及弹窗采用毛玻璃效果，在保留背景视觉层次的同时保证文字内容清晰可读。

此外，系统在导航区域提供透明度调节滑块，支持40%—88%的透明度范围。用户调整滑块后，相关界面组件会即时更新透明度，并将当前设置保存在浏览器本地存储中，使用户刷新页面后仍能保留自己的视觉偏好。

（3）动态背景与交互效果

页面底部采用四张云图图块组成循环背景，以约360秒为一个周期缓慢向右移动，通过图块边缘重叠减少循环过程中的拼接缝隙。

同时，系统使用Canvas实现多色鼠标粒子拖尾效果，在保留普通鼠标指针的基础上增强页面交互的趣味性。对于不支持精确鼠标指针的设备及开启减少动态效果的用户，自动停用相应粒子动画。

（4）响应式布局与动态交互

系统对不同屏幕宽度进行布局适配，针对导航栏、卡片、弹窗等组件调整尺寸和间距。同时，页面区块采用滚动揭示效果，在进入可视区域时依次上移并淡入，使页面内容呈现更加自然。

（5）多语言界面设计

系统支持简体中文、繁体中文、英语、德语和日语五种语言。界面公共文案通过独立语言资源文件统一管理，论坛标题、简介等业务数据则使用独立翻译资源，使语言切换不依赖大量条件判断，提高了界面的可维护性。

系统前端功能结构如下：

flowchart TD
    A["CNCC 2026 智能会议助手"] --> B["首页"]
    A --> C["论坛议程"]
    A --> D["智能推荐"]
    A --> E["个人中心"]
    A --> F["管理工作台"]

    B --> B1["会议介绍"]
    B --> B2["论坛目录统计"]
    B --> B3["精选论坛"]
    B --> B4["功能入口"]

    C --> C1["关键词搜索"]
    C --> C2["主题筛选"]
    C --> C3["论坛详情"]
    C --> C4["官方议程"]

    D --> D1["自然语言输入"]
    D --> D2["推荐结果"]
    D --> D3["推荐理由"]
    D --> D4["查看详情与报名"]

    E --> E1["个人报名"]
    E --> E2["个人日程"]
    E --> E3["时间冲突提示"]
    E --> E4["论坛通知"]

    F --> F1["会议主席工作台"]
    F --> F2["论坛主席工作台"]
    F --> F3["秘书工作台"]

6.2 核心页面与交互展示

（1）系统首页

首页是用户进入系统后的主要入口，集中展示CNCC 2026会议介绍、举办日期、举办地点、论坛目录统计、主题统计及主要功能入口。

页面设置精选论坛区域，通过循环轮播展示论坛列表中的前六项。轮播区域提供左右切换按钮，同时支持鼠标拖动浏览；当用户将鼠标悬停在轮播区域、使用键盘聚焦或进行拖动时，自动暂停轮播，方便用户查看感兴趣的论坛。

此外，首页还通过页面区块滚动揭示效果，使不同内容区域按照顺序进入视野。

（2）论坛议程与详情页面

论坛议程页面集中展示CNCC 2026的论坛信息，支持用户通过关键词搜索和主题筛选快速定位目标论坛。

用户点击论坛卡片后，可以查看论坛类别、主题、主席、所属单位、召开时间、地点、简介、报名人数和来源链接等详细信息。

对于已经建立官方议程映射的论坛，系统还可以展示对应的主持人、嘉宾、报告题目、讲者、所属单位、人员角色及报告摘要。详情页面默认展示前六条报告信息，用户可以展开查看其余内容。

（3）用户注册与登录页面

系统提供统一的登录弹窗和注册入口。普通参会者可以通过注册表单创建账号，注册成功后获得普通参会者身份。

登录成功后，后端签发JWT令牌，前端保存令牌并在后续API请求中自动携带身份认证信息。

此外，登录弹窗从后端读取演示账户信息，用户点击相应角色的演示账户卡片即可自动填入用户名和密码，方便在项目展示时快速体验不同角色的功能。

（4）LLM智能论坛推荐页面

智能推荐页面是系统的重要特色功能之一。用户可以直接使用自然语言描述自己的研究方向和参会兴趣，例如：

我对大语言模型和软件工程感兴趣，希望参加相关论坛。

提交后，系统根据用户输入召回相关论坛候选，再通过大语言模型进行筛选和排序，最终展示推荐论坛、匹配度和推荐理由。

用户可以点击推荐结果进入论坛详情，进一步了解论坛内容，并直接加入个人参会日程。推荐功能支持匿名使用，不要求用户必须先登录。

（5）个人中心与参会日程页面

个人中心主要展示当前用户的报名情况和参会日程。用户可以查看已经报名的论坛，并通过论坛详情添加或取消报名。

个人日程根据用户当前的报名记录自动生成，按照论坛开始时间排序。系统会检查不同论坛之间的时间区间，对存在重叠的论坛给出冲突提示。

当用户新增或取消报名后，前端会重新获取个人日程及冲突列表，使页面及时反映最新的报名状态。

（6）论坛通知中心

论坛通知中心用于展示与用户已报名论坛相关的消息。论坛主席和秘书可以发布论坛通知，参会者登录后可以在站内通知页面查看对应内容。

系统根据用户的报名记录筛选通知，使用户能够集中获取与个人参会安排相关的信息。

（7）角色管理工作台

系统根据登录用户的角色展示不同的管理功能：

• 会议主席工作台： 展示会议去重参会人数、论坛数量、报名总数及报名人数较多的热门论坛。
• 论坛主席工作台： 展示当前主席负责的论坛及对应报名人数，并提供论坛通知发布功能。
• 秘书工作台： 提供参会者名单查询，展示参会者用户名、显示姓名、邮箱、创建时间及已报名论坛，并支持选择论坛发布通知。

通过不同角色对应的管理页面，系统实现了参会服务与会议管理功能的统一。

6.3 用户操作流程与体验优化

（1）普通参会者操作流程

普通参会者的主要使用流程围绕论坛查找、兴趣推荐、报名管理和个人日程展开。

用户进入系统首页后，可以通过论坛目录搜索和主题筛选查找感兴趣的论坛，也可以进入智能推荐页面，通过自然语言描述自己的研究兴趣获取推荐结果。

确定目标论坛后，用户进入论坛详情页面查看具体信息。如果尚未登录，则先完成注册或登录；登录后即可进行论坛报名。报名成功后，系统更新个人报名列表和参会日程，并根据最新报名情况重新计算时间冲突。

整体操作流程如下：

flowchart TD
    A["进入系统首页"] --> B{"选择查找方式"}
    B -->|"论坛目录"| C["关键词搜索与主题筛选"]
    B -->|"智能推荐"| D["输入研究兴趣"]
    D --> E["LLM智能推荐"]
    E --> F["查看推荐结果"]

    C --> G["打开论坛详情"]
    F --> G

    G --> H["查看论坛信息与官方议程"]
    H --> I{"是否已登录"}
    I -->|"否"| J["注册或登录"]
    I -->|"是"| K["选择加入论坛"]
    J --> K

    K --> L["更新个人报名记录"]
    L --> M["生成个人参会日程"]
    M --> N["检查时间冲突"]
    N --> O["查看日程与论坛通知"]

（2）管理人员操作流程

不同管理角色登录系统后，根据自身权限进入对应的管理工作台。

flowchart TD
    A["用户登录"] --> B{"判断用户角色"}

    B -->|"会议主席"| C["会议主席工作台"]
    B -->|"论坛主席"| D["论坛主席工作台"]
    B -->|"秘书"| E["秘书工作台"]

    C --> C1["查看会议参会人数"]
    C --> C2["查看论坛报名统计"]

    D --> D1["查看负责论坛"]
    D --> D2["查看论坛报名人数"]
    D --> D3["发布论坛通知"]

    E --> E1["查询参会者信息"]
    E --> E2["查看报名论坛"]
    E --> E3["发布论坛通知"]

（3）用户体验优化措施

在完成核心功能开发的基础上，团队围绕操作效率、界面可读性、交互反馈和系统适配等方面进行了进一步优化。

① 降低论坛查找成本

通过关键词搜索、主题筛选和精选论坛轮播等功能，帮助用户从大量论坛信息中快速定位感兴趣的内容。同时，智能推荐允许用户直接使用自然语言表达需求，减少手动筛选和逐个浏览的操作成本。

② 提升界面可读性与视觉舒适度

针对毛玻璃设计中背景透明度与文字可读性之间的平衡问题，团队调整了面板背景、弹窗遮罩和透明度变量，避免通过降低文字本身的透明度实现视觉效果。同时加入透明度滑块，使用户能够根据自己的偏好调整界面。

③ 优化页面交互与动态效果

精选论坛轮播支持自动播放、左右切换和鼠标拖动，并在用户悬停、键盘聚焦或拖动时暂停。页面滚动揭示和鼠标粒子效果进一步丰富了交互体验，同时兼顾减少动态效果的系统偏好。

④ 提高个人参会信息管理效率

用户完成论坛报名或取消报名后，系统自动更新个人日程和时间冲突列表，避免用户手动维护参会安排。对于时间区间首尾相接的论坛，不判定为冲突，减少不必要的提示。

⑤ 改善多设备与多语言使用体验

通过响应式布局适配不同屏幕宽度，并使用统一的语言资源管理机制实现五种语言切换。当前语言保存在浏览器本地存储中，用户刷新页面后仍能保留语言选择。

⑥ 简化演示与角色体验

登录弹窗提供四类角色的演示账户入口，点击对应账户即可自动填入登录信息，方便快速体验普通参会者、会议主席、论坛主席和秘书的不同功能。

通过以上GUI设计与交互优化，系统不仅实现了会议论坛信息展示和业务管理等基础功能，也将智能推荐、多语言、个人日程及动态视觉效果融入统一的Web界面，使不同角色能够更加直观、便捷地完成各自的操作。

7. 基础功能设计与实现

7.1 会议议程与分论坛信息展示

会议议程与分论坛信息展示是系统的基础功能，为参会者提供统一的会议资料查询入口。本项目基于CNCC 2026官方公开数据，整理形成包含170条论坛记录的论坛目录，并结合官方详细议程数据，为用户提供会议介绍、论坛检索和论坛详情查询等服务。

（1）会议首页信息展示

系统首页集中展示CNCC 2026会议基本信息，包括会议名称、会议主题、举办日期、举办地点、论坛数量及主题分类统计等内容。同时，首页设置精选论坛区域，通过论坛卡片展示具有代表性的论坛，为用户提供快捷浏览入口。

（2）论坛目录与条件检索

论坛议程页面以卡片形式展示论坛信息，支持以下查询方式：

• 关键词搜索： 用户可以根据论坛名称及相关关键词查找目标论坛。
• 主题筛选： 根据论坛所属研究主题进行分类筛选，缩小查询范围。
• 论坛详情查看： 点击论坛卡片即可进入详情页面，了解具体论坛信息。

（3）论坛详细信息展示

用户进入论坛详情页面后，可以查看以下内容：

信息类别	展示内容
基本信息	论坛类别、论坛主题、论坛简介
组织信息	论坛主席、所属单位
时间信息	论坛开始时间、结束时间
地点信息	论坛召开地点
参与信息	当前论坛报名人数
来源信息	官方资料来源链接

此外，系统通过官方数据编号映射，将项目论坛与官方议程中的详细资料关联。目前已有168条可靠映射。对于已建立映射的论坛，详情页面还可以展示主席、主持人、嘉宾、报告题目、讲者、所属单位、人员角色及报告摘要等信息。

官方报告信息默认展示前六条，用户可以展开查看其余记录，并通过原始来源链接进一步了解官方资料。

（4）功能实现流程

flowchart TD
    A["用户进入会议首页"] --> B["获取会议基本信息"]
    B --> C["展示论坛目录与主题统计"]
    C --> D{"选择查询方式"}
    D -->|"关键词搜索"| E["关键词匹配"]
    D -->|"主题筛选"| F["按主题筛选"]
    E --> G["展示符合条件的论坛"]
    F --> G
    G --> H["点击论坛卡片"]
    H --> I["查询论坛详细信息"]
    I --> J["查询官方议程映射"]
    J --> K["展示论坛详情及关联官方资料"]

主要实现位置：

• ConferenceController：负责会议及论坛相关接口。
• ForumQueries：集中处理论坛数据查询。
• OfficialProgramService：负责官方议程资源及编号映射查询。

主要API：

API	功能
GET /api/conference	获取会议基本信息
GET /api/forums	获取论坛目录及搜索结果
GET /api/forums/{id}	获取指定论坛详情
GET /api/forums/{id}/official-program	获取关联的官方详细议程

7.2 用户注册、登录与权限管理

为了满足不同参会者和会议管理人员的使用需求，系统建立了统一的用户认证与角色权限管理机制。通过注册、登录、身份认证和角色授权，实现不同用户的功能隔离。

（1）用户注册

普通用户可以通过系统注册入口创建账号。用户提交用户名、密码及相关个人资料后，后端对请求参数进行校验，并将用户信息保存至user_account表。

新注册账号默认获得普通参会者身份，用户完成注册后即可通过登录进入系统。

（2）用户登录与身份认证

用户提交用户名和密码后，后端首先查询对应的账户信息，并使用BCrypt验证密码。验证成功后，系统签发JWT身份令牌，前端保存令牌，并在后续API请求中通过Authorization请求头携带身份信息。

系统采用无状态身份认证机制，JWT有效期为24小时，签名算法为HMAC-SHA256。后端通过Spring Security解析令牌，识别当前登录用户及其角色。

（3）角色权限管理

系统根据CNCC会议业务场景，将用户划分为四种角色：

用户角色	权限范围
普通参会者	浏览论坛、论坛报名、个人日程管理、查看相关通知
会议主席	查看会议整体参会统计、管理会议相关信息
论坛主席	查看负责论坛的报名情况、发布所属论坛通知
秘书	查询参会者信息、查看报名情况、发布论坛通知

系统通过Spring Security与角色授权机制，对管理接口进行权限控制。用户登录后，前端根据当前角色展示对应的功能入口，后端则在接口层再次验证访问权限，保证用户只能执行自身角色允许的操作。

（4）注册与登录实现流程

flowchart TD
    A["用户进入系统"] --> B{"选择操作"}
    B -->|"注册"| C["填写注册信息"]
    C --> D["后端校验注册参数"]
    D --> E["BCrypt处理密码"]
    E --> F["保存用户账户"]
    F --> G["默认分配普通参会者角色"]

    B -->|"登录"| H["提交用户名和密码"]
    H --> I["查询用户账户"]
    I --> J["BCrypt验证密码"]
    J --> K{"验证是否通过"}
    K -->|"否"| L["返回登录失败信息"]
    K -->|"是"| M["签发JWT令牌"]
    M --> N["前端保存令牌"]
    N --> O["后续请求携带身份令牌"]
    O --> P["Spring Security认证"]
    P --> Q["根据角色执行权限校验"]
    Q --> R["访问对应功能"]

主要实现位置：

• AuthController：处理用户注册、登录及身份信息查询。
• Spring Security：负责身份认证与角色授权。
• BCrypt：负责用户密码的安全存储与验证。
• JWT：负责用户登录状态及身份信息传递。
• api.js：统一处理前端API请求，并自动添加身份认证请求头。

主要API：

API	功能
POST /api/auth/register	创建普通参会者账号
POST /api/auth/login	用户登录
GET /api/auth/me	获取当前登录用户信息

7.3 分论坛选择与报名管理

分论坛报名管理是会议平台的核心业务之一，主要负责建立和维护参会者与论坛之间的报名关系。

（1）论坛报名

用户登录后，可以在论坛目录中查找感兴趣的论坛，进入论坛详情页面查看相关信息，并选择加入论坛。

系统允许一个用户报名多个论坛。用户提交报名请求后，后端根据当前登录身份获取用户ID，并结合论坛ID创建报名记录，保存至registration表。

（2）个人报名查询

用户可以在个人中心查看已经报名的全部论坛，系统根据当前登录用户的身份，从报名表中查询对应记录，并关联论坛基本信息，展示个人报名列表。

（3）取消论坛报名

如果用户改变参会计划，可以取消已经报名的论坛。后端根据当前登录用户和目标论坛定位对应报名记录，删除关联关系，更新个人报名情况。

（4）重复报名控制

为了避免同一用户重复报名同一个论坛，系统在数据库层对user_id和forum_id设置组合唯一约束。

同时，报名接口使用后端认证得到的当前用户身份确定报名主体，而不是接受客户端任意指定的用户ID，保证报名操作与实际登录身份一致。

（5）报名业务流程

flowchart TD
    A["用户登录系统"] --> B["浏览论坛目录"]
    B --> C["选择目标论坛"]
    C --> D["查看论坛详情"]
    D --> E["提交报名请求"]
    E --> F["后端获取当前登录用户"]
    F --> G["检查论坛及报名记录"]
    G --> H{"是否已经报名"}
    H -->|"是"| I["返回重复报名提示"]
    H -->|"否"| J["创建报名记录"]
    J --> K["更新个人报名列表"]
    K --> L["生成最新个人参会日程"]

    L --> M["用户可继续报名其他论坛"]
    M --> N["也可取消已有报名"]
    N --> O["删除对应报名记录"]
    O --> K

主要实现位置：

• RegistrationController.java：负责个人论坛报名相关接口。
• registration：保存用户与论坛之间的报名关系。
• CurrentUser：获取当前经过身份认证的用户信息。

主要API：

API	功能
GET /api/me/registrations	查询当前用户的报名记录
POST /api/forums/{id}/registrations	报名指定论坛
DELETE /api/forums/{id}/registrations	取消指定论坛报名

7.4 会议及分论坛参会人数统计

为了满足会议主席和论坛主席对参会情况的管理需求，系统设计了分角色的参会人数统计功能，分别从会议整体和单个论坛两个层面展示报名数据。

（1）会议整体参会人数统计

会议主席登录系统后，可以通过管理工作台查看会议整体参会情况，主要包括：

• 参会人数： 至少报名一个论坛的不同用户总数。
• 论坛数量： 系统中的论坛总数量。
• 报名总数： 所有论坛报名记录的总数。
• 热门论坛： 根据报名人数展示参与度较高的论坛。

其中，会议整体参会人数不能直接使用报名记录总数，因为同一用户可能报名多个论坛。因此，系统通过对registration表中的user_id进行去重统计，得到实际的不同报名用户数量。

（2）分论坛参会人数统计

论坛主席登录系统后，可以查看自己负责的论坛及对应的报名人数。

系统根据当前论坛主席的身份限定查询范围，仅返回其负责的论坛数据，避免不同论坛之间的管理数据相互混淆。

（3）统计实现逻辑

flowchart TD
    A["管理人员登录"] --> B{"判断用户角色"}

    B -->|"会议主席"| C["查询全部报名记录"]
    C --> D["按user_id去重"]
    D --> E["统计会议参会人数"]
    C --> F["统计报名记录总数"]
    C --> G["统计论坛数量及热门论坛"]
    E --> H["会议主席统计工作台"]
    F --> H
    G --> H

    B -->|"论坛主席"| I["获取当前主席身份"]
    I --> J["查询其负责的论坛"]
    J --> K["分别统计论坛报名人数"]
    K --> L["论坛主席统计工作台"]

主要实现位置：

• AdminController.java：负责会议及论坛管理统计接口。
• registration：提供报名人数统计所需的数据。
• user_account：提供当前用户及角色信息。

主要API：

API	功能	访问角色
GET /api/admin/stats	查询会议整体统计数据	会议主席
GET /api/admin/forum-stats	查询负责论坛及报名人数	论坛主席

通过区分报名记录总数和去重后的参会人数，系统能够更加准确地反映会议整体参与情况，并为不同层级的会议管理提供数据支持。

7.5 秘书参会者信息管理

秘书是会议管理工作中的重要角色，主要负责参会者信息整理和论坛相关事务协调。系统为秘书提供独立的参会者信息管理功能，方便其集中查询用户资料及报名情况。

（1）参会者信息查询

秘书登录系统后，可以进入秘书工作台，查询系统中的参会者名单。

系统通过用户账户表和论坛报名表关联查询，返回参会者的基本信息及其报名情况。

主要展示内容包括：

信息类别	具体内容
账户信息	用户名
个人资料	显示名称、邮箱
注册信息	账号创建时间
报名信息	已报名的论坛列表

（2）参会者报名情况管理

秘书可以根据参会者信息查看其已经报名的论坛，了解不同用户的参会安排，为会议组织和信息传达提供依据。

通过用户账户与报名记录之间的关联，系统能够将分散的账户信息和论坛报名信息整合展示，减少人工整理工作。

（3）权限控制

参会者完整名单属于会议管理数据，因此系统仅允许秘书角色访问参会者信息查询接口。后端通过角色授权进行访问控制，其他角色无法直接调用该管理接口获取完整名单。

主要实现位置：

• AdminController.java：提供参会者信息查询接口。
• user_account：保存用户基本资料。
• registration：保存用户已报名的论坛信息。

主要API：

API	功能	访问角色
GET /api/admin/attendees	获取参会者名单及报名信息	秘书

7.6 分论坛消息通知与信息推送

为了方便论坛主席和秘书向参会者传达会议相关信息，系统设计了论坛通知功能。通过通知发布、论坛关联和用户报名关系，实现通知内容的分类管理及定向展示。

（1）论坛通知发布

论坛主席和秘书登录系统后，可以通过管理工作台发布论坛通知。

发布时需要选择对应论坛并填写通知内容，后端根据当前登录用户的身份和角色验证发布权限，随后将通知保存至notice表。

其中：

• 论坛主席只能向自己负责的论坛发布通知。
• 秘书可以选择相应论坛发布通知。

（2）参会者通知查询

普通参会者登录系统后，可以进入论坛通知页面查看相关消息。

系统根据当前用户的报名记录筛选通知，只向已经报名对应论坛的用户展示该论坛发布的消息。

例如，用户A报名了论坛1和论坛2，那么用户A可以查看这两个论坛发布的通知，而不会收到与其报名无关的其他论坛消息。

（3）通知数据管理

每条通知关联对应的论坛和发布用户，并记录通知正文及发布时间。通过这种关联方式，系统能够明确通知所属的论坛以及发布者，便于后续查询和管理。

（4）通知发布与查询流程

flowchart TD
    A["用户登录"] --> B{"判断用户角色"}

    B -->|"论坛主席"| C["选择自己负责的论坛"]
    B -->|"秘书"| D["选择目标论坛"]

    C --> E["填写通知内容"]
    D --> E

    E --> F["提交通知"]
    F --> G["后端校验发布权限"]
    G --> H["保存通知记录"]
    H --> I["通知进入站内通知中心"]

    J["普通参会者登录"] --> K["查询个人报名记录"]
    K --> L["获取已报名论坛ID"]
    L --> M["筛选对应论坛通知"]
    M --> N["展示相关通知"]

主要实现位置：

• NoticeController.java：负责论坛通知的发布和查询。
• notice：保存论坛通知内容、发布者和发布时间。
• registration：提供参会者已报名的论坛信息，用于通知筛选。

主要API：

API	功能	访问范围
GET /api/me/notices	查询当前用户相关通知	登录用户
POST /api/forums/{id}/notices	向指定论坛发布通知	论坛主席、秘书

目前通知通过系统内的“论坛通知”页面进行展示，参会者登录后即可查看与自身报名论坛相关的消息，实现论坛信息的集中传达。

通过上述六项基础功能，系统建立了从会议资料展示、用户身份认证、论坛报名到会议统计、参会者管理和通知传达的完整业务链路，为CNCC 2026会议的参会服务与组织管理提供了统一的平台支持。

8. LLM智能分论坛推荐功能

8.1 智能推荐功能设计

（1）功能设计背景

CNCC 2026包含大量不同研究领域的分论坛，参会者需要根据自身研究方向和兴趣，从大量论坛中筛选出值得参加的活动。传统的关键词搜索主要依赖用户主动输入准确的检索词，对于研究方向较为宽泛或者不熟悉论坛分类的用户而言，查找效率有限。

为此，本项目引入大语言模型（LLM），设计智能分论坛推荐功能。用户不需要提前了解论坛名称或所属类别，只需要通过自然语言描述自己的研究方向、兴趣或参会需求，系统即可结合已有论坛数据进行分析，推荐相关论坛并生成推荐理由。

例如，用户可以输入：

我对大语言模型和软件工程感兴趣，希望参加相关论坛。

系统根据用户描述，从CNCC 2026已有论坛中筛选相关候选，再利用大语言模型进行进一步分析，最终返回匹配度较高的论坛及推荐理由。

（2）总体设计思路

考虑到大语言模型可能产生不存在的论坛名称、错误的论坛信息或无关推荐，本项目没有采用让LLM直接生成完整论坛信息的方式，而是设计了本地候选召回与LLM筛选相结合的推荐机制。

整体分为五个步骤：

1. 用户需求输入： 用户通过自然语言描述研究兴趣，系统同时获取当前界面语言。
2. 本地候选召回： 根据论坛标题、主题、简介和所属单位进行关键词匹配，筛选相关候选论坛。
3. LLM智能筛选： 将用户需求和候选论坛提交给大语言模型，由模型分析相关性并生成推荐结果。
4. 推荐结果校验： 后端对模型返回的论坛ID、推荐分数、数据格式和推荐理由进行检查，确保推荐结果对应真实论坛。
5. 推荐结果展示： 前端展示推荐论坛、匹配度和推荐理由，用户可以进一步查看论坛详情并进行报名。

系统整体流程如下：

flowchart TD
    A["用户输入研究方向与参会兴趣"] --> B["提交推荐请求"]
    B --> C["本地关键词召回"]
    C --> D{"是否存在候选论坛"}
    D -->|"否"| E["返回空推荐结果"]
    D -->|"是"| F["筛选最多8个候选论坛"]
    F --> G["调用LLM服务"]
    G --> H["分析论坛相关性"]
    H --> I["返回JSON推荐结果"]
    I --> J["后端校验论坛ID、分数和理由"]
    J --> K{"结果是否有效"}
    K -->|"否"| L["尝试备用模型或本地回退"]
    K -->|"是"| M["从数据库获取真实论坛信息"]
    L --> M
    M --> N["展示推荐论坛及推荐理由"]
    N --> O["查看详情并选择报名"]

（3）功能架构设计

智能推荐模块主要由以下三个部分组成：

• 前端交互模块： 接收用户自然语言输入，展示推荐结果、匹配度及推荐理由。
• 后端推荐服务： 负责本地候选召回、模型调用、结果校验和异常回退。
• 外部LLM服务： 通过OpenAI兼容的Chat Completions接口提供自然语言理解、候选筛选和推荐理由生成能力。

其中，RecommendationController负责接收推荐请求，RecommendationService负责实现核心推荐逻辑。

8.2 用户需求解析与Prompt设计

（1）用户自然语言需求输入

系统允许用户直接使用自然语言描述自己的研究兴趣，不需要按照固定格式填写研究领域、关键词或论坛类别。

例如：

• 我对大语言模型和软件工程感兴趣，希望参加相关论坛。
• 我主要研究计算机视觉，希望了解医学图像分析和深度学习相关的论坛。
• 我对人工智能在科学研究中的应用比较感兴趣，希望寻找相关学术交流活动。

用户输入的兴趣描述最多支持600个字符。前端在提交推荐请求时，还会将当前界面语言一并发送给后端，以便模型按照用户选择的语言生成推荐理由。

推荐功能支持匿名使用，用户不需要先注册或登录即可体验智能推荐。

（2）Prompt设计思路

在设计Prompt时，团队重点考虑了三个问题：

1. 如何让模型准确理解用户的研究兴趣，并结合论坛信息判断相关性。
2. 如何限制模型的输出范围，避免生成系统中不存在的论坛。
3. 如何规范模型的返回格式，使后端能够稳定解析和处理推荐结果。

因此，Prompt采用明确角色、任务目标、输入数据、输出约束和异常处理要求相结合的结构化设计方式。

以下为根据真实开发需求及后续迭代整理的结构化Prompt复现稿，并非历史聊天记录逐字转录。

核心Prompt示例：

角色：
你是CNCC 2026会议的智能论坛推荐助手，负责根据用户的研究兴趣，
从提供的候选论坛中筛选最相关的论坛。

项目背景：
系统已经建立CNCC 2026论坛数据库，提供论坛ID、标题、主题、
简介及所属单位等真实信息。

输入：
1. 用户使用自然语言描述的研究兴趣。
2. 当前界面语言。
3. 系统根据用户需求召回的候选论坛列表。

任务要求：
1. 理解用户描述的研究方向和参会需求。
2. 分析用户兴趣与候选论坛之间的相关性。
3. 对候选论坛进行筛选和排序。
4. 为每个推荐论坛生成简洁、具体的推荐理由。

输出要求：
1. 仅推荐输入候选列表中存在的论坛。
2. 返回论坛ID、匹配分数和推荐理由。
3. 使用JSON格式输出，保证后端能够解析。
4. 推荐理由必须使用用户当前选择的界面语言。
5. 不得自行编造论坛名称、时间、地点、主席及其他官方信息。

约束条件：
1. 不得返回候选列表之外的论坛ID。
2. 不得返回无效的推荐分数。
3. 推荐理由不能为空。
4. 只保留与用户需求具有实际相关性的论坛。

最终目标：
返回与用户研究兴趣最相关的论坛推荐结果，
帮助用户快速找到值得参加的CNCC 2026分论坛。

（3）Prompt迭代与优化

在实际开发过程中，团队根据推荐功能的运行情况，对Prompt和整体推荐方案进行了多轮调整。

迭代阶段	遇到的问题	优化方向
第一阶段	初步接入OpenAI兼容模型服务	建立统一的模型调用方式，将模型配置放在后端
第二阶段	用户反馈推荐功能仍然失败	从前端请求、后端API、候选数据和模型响应等环节检查完整调用链
第三阶段	单一模型服务存在调用失败的情况	增加TokenRhythm备用服务，并将DeepSeek官网服务作为最后一个模型备用方案
第四阶段	模型可能返回不存在的论坛或无关结果	限制模型只能从本地候选论坛中选择，并增加ID、分数、格式和推荐理由校验

经过多轮调整，团队最终形成了以真实论坛数据为基础、以LLM为智能筛选工具的推荐方案。

8.3 LLM调用与真实论坛数据匹配

（1）本地候选论坛召回

为了避免将整个论坛目录直接交给大模型处理，同时减少无关信息对推荐结果的干扰，系统首先进行本地关键词匹配。

后端根据用户输入，在论坛标题、主题、简介和所属单位等字段中识别相关概念。

目前支持识别的研究方向包括：

• 大语言模型与智能体
• 软件工程
• 数据科学
• 信息安全
• 机器学习
• 机器人
• 计算机网络
• AI4Science等领域。

系统根据匹配到的概念数量对论坛进行排序，最多召回8个候选论坛，作为后续LLM筛选的输入。

本地召回采用以下评分公式：

其中：

• (N) 表示命中的研究概念数量。
• (S_{\text{local}}) 表示本地关键词匹配分数。
• 分数最高不超过0.98。

通过这一方式，系统能够先利用本地数据完成初步筛选，再将规模较小、相关性较高的候选集合交给大语言模型处理。

（2）多模型服务调用机制

考虑到外部大模型服务可能出现网络异常、API调用失败、响应超时等问题，项目没有将智能推荐绑定到单一模型服务，而是设计了多模型依次调用机制。

当前模型服务调用顺序如下：

调用顺序	模型服务	服务定位
第一顺位	SenseNova	主模型服务
第二顺位	TokenRhythm	第一备用服务
第三顺位	DeepSeek	最终备用服务

三个服务均采用OpenAI兼容的Chat Completions接口，由后端统一封装调用。

模型API地址、模型名称和API Key均通过后端环境变量配置，不直接写入前端代码。

当主模型服务调用失败或返回无效结果时，系统继续尝试下一服务，直到获得有效推荐结果或所有模型服务均不可用。

模型调用链路如下：

flowchart TD
    A["RecommendationService"] --> B["调用SenseNova"]
    B --> C{"返回有效结果？"}
    C -->|"是"| G["进入结果校验与处理"]
    C -->|"否"| D["调用TokenRhythm"]

    D --> E{"返回有效结果？"}
    E -->|"是"| G
    E -->|"否"| F["调用DeepSeek"]

    F --> H{"返回有效结果？"}
    H -->|"是"| G
    H -->|"否"| I["本地关键词推荐回退"]

    G --> J["返回LLM推荐结果"]
    I --> K["返回本地推荐结果"]

（3）真实论坛数据匹配

本项目智能推荐功能的核心要求是：模型推荐的论坛必须真实存在于系统中。

因此，模型并不直接生成论坛名称、论坛简介或其他完整信息，而是仅根据系统提供的候选论坛返回对应的论坛ID、匹配分数和推荐理由。

后端收到模型响应后，执行以下校验：

1. 检查模型返回内容是否符合JSON格式要求。
2. 检查论坛ID是否属于本次提供的候选集合。
3. 检查推荐分数是否达到最低要求。
4. 检查推荐理由是否为空，并验证其语言是否符合当前界面语言。
5. 对不符合要求的结果进行拒绝处理，并尝试其他模型服务。

当前LLM推荐结果的最低分数要求为0.5，最多保留5个有效推荐结果。

通过上述方式，将大模型的作用限制在候选论坛筛选和推荐理由生成范围内，论坛标题及其他详细资料始终由系统数据库提供。

（4）推荐服务实现位置

智能推荐功能主要涉及以下代码文件：

文件	主要职责
RecommendationController.java	接收用户推荐请求
RecommendationService.java	实现本地召回、模型调用、结果校验及异常回退
application.yml	配置推荐服务相关参数
.env.example	提供外部模型服务环境变量配置示例

推荐接口：

POST /api/recommendations

通过上述设计，系统将本地论坛数据、外部大模型和后端校验机制结合起来，既利用了LLM理解自然语言和分析语义相关性的能力，也保证了推荐结果能够对应真实的CNCC 2026论坛数据。

8.4 推荐理由生成与论坛详情展示

（1）推荐理由生成

与传统关键词搜索只返回匹配结果不同，本项目要求大语言模型同时生成推荐理由，帮助用户理解系统为什么推荐某个论坛。

模型根据用户的研究兴趣和候选论坛的主题、简介及所属单位等信息，分析两者之间的相关性，并生成对应的推荐理由。

例如，用户输入：

我对大语言模型和软件工程感兴趣，希望参加相关论坛。

系统可以根据实际候选论坛的内容，说明某个论坛与大语言模型、智能体或软件工程研究方向之间的联系，帮助用户判断是否值得参加。

同时，推荐理由支持简体中文、繁体中文、英语、德语和日语五种语言。

如果模型生成的推荐理由不符合用户当前选择的界面语言，系统会使用本地生成的匹配理由进行替代，保证推荐结果的语言一致性。

（2）推荐结果展示

前端将后端返回的推荐结果整理为论坛推荐卡片，主要展示以下信息：

展示内容	具体说明
论坛名称	从系统真实论坛记录中获取
匹配分数	展示模型返回的相关性评分
推荐理由	展示模型生成的个性化推荐说明
详情入口	进入对应论坛的详情页面

通过匹配度与推荐理由相结合的方式，用户不仅能够了解推荐结果，还能够判断推荐论坛是否符合自身的研究兴趣。

（3）论坛详情展示

用户点击推荐结果后，可以进入对应论坛的详情页面。

详情页面展示论坛类别、主题、主席、所属单位、时间、地点、简介及报名人数等信息。对于已经建立官方议程映射的论坛，还可以进一步查看对应的报告题目、讲者、主持人、嘉宾及报告摘要等官方资料。

需要注意的是，推荐理由由LLM根据用户兴趣和候选论坛生成，而论坛名称、时间、地点、主席等正式信息均来自系统已有数据，不由模型自由生成。

8.5 推荐结果直接报名与异常处理

（1）推荐结果与论坛报名衔接

智能推荐不仅用于帮助用户发现感兴趣的论坛，还需要与系统已有的报名功能结合，形成完整的参会操作流程。

用户获得推荐结果后，可以点击相应论坛进入详情页面，进一步了解论坛内容，并直接使用页面中的报名功能。

整个过程不需要用户重新返回论坛目录搜索推荐结果，减少了从兴趣发现到实际报名之间的操作步骤。

报名完成后，系统通过原有的论坛报名管理机制保存用户与论坛之间的关联记录，并更新个人报名情况和参会日程。

具体流程如下：

flowchart TD
    A["用户提交研究兴趣"] --> B["获取智能推荐结果"]
    B --> C["选择感兴趣的论坛"]
    C --> D["进入论坛详情页面"]
    D --> E["查看论坛及官方议程"]
    E --> F{"是否决定参加"}
    F -->|"否"| G["返回推荐列表继续选择"]
    G --> B
    F -->|"是"| H["点击论坛报名"]
    H --> I["后端验证用户身份"]
    I --> J["创建论坛报名记录"]
    J --> K["更新个人报名列表"]
    K --> L["更新个人参会日程"]

（2）异常结果处理

由于智能推荐依赖外部大模型服务，同时涉及自然语言解析和结构化数据返回，因此系统针对不同异常情况设计了相应处理机制。

异常情况	处理方式
外部模型服务未配置	跳过不可用服务，尝试后续服务
API调用超时或HTTP错误	自动尝试下一个模型服务
模型返回JSON格式异常	拒绝当前结果，继续尝试备用服务
模型返回不存在的论坛ID	通过候选ID集合校验并拒绝
推荐分数低于0.5	拒绝该推荐结果
推荐理由为空	拒绝该推荐结果
推荐理由语言不符合要求	使用本地生成的匹配理由替代
所有模型服务均调用失败	返回本地关键词匹配结果
本地召回没有候选论坛	直接返回空结果，不调用LLM

其中，本地关键词推荐是智能推荐功能的重要保障。当所有外部模型服务均不可用时，系统仍然能够根据用户输入的研究兴趣和已有论坛数据返回匹配结果，避免推荐功能完全依赖外部API。

（3）安全性与配置管理

为了保护模型服务的调用凭证，项目将API地址、模型名称和API Key统一放在后端环境变量中，不将密钥暴露在Vue前端代码中。

用户提交的研究兴趣文本由后端转发至当前配置的外部LLM服务，模型调用及其备用切换均由后端统一管理。

同时，模型返回的论坛ID必须经过后端校验，论坛详细信息仍从本地数据库读取，避免模型生成虚假论坛资料。

（4）功能实现效果

通过以上设计，本项目实现了从自然语言需求输入、本地论坛候选召回、LLM智能筛选、多模型故障回退，到论坛详情查看和报名管理的完整流程。

与单纯依靠关键词搜索的传统方式相比，智能推荐允许用户直接表达研究兴趣，并获得具有针对性的论坛推荐及解释。同时，通过真实论坛数据约束和异常回退机制，提高了推荐结果的可靠性与系统的可用性。

9. AI Coding开发过程与实践

9.1 AI Coding工具与开发模式

（1）AI Coding工具选择

本项目采用ChatGPT与Codex相结合的AI辅助开发方式，将大语言模型应用于需求分析、技术方案设计、代码实现、问题排查和测试验证等多个环节。

AI工具	主要用途	具体工作
ChatGPT	需求分析与技术方案讨论	梳理功能需求、讨论系统架构、分析技术方案、优化Prompt及解决开发过程中的技术问题
Codex	项目执行与代码开发	阅读本地项目、理解代码结构、修改多个文件、执行终端命令、运行测试及排查Bug

其中，ChatGPT主要负责辅助思考和方案讨论，Codex则直接参与项目代码的开发与维护。通过这种方式，AI不再只是提供代码片段，而是能够结合项目现有代码理解模块之间的关系，完成跨文件修改和连续调试。

（2）人机协作开发模式

在实际开发过程中，团队采用人工主导、AI辅助的协作模式。

人工主要负责：

• 明确项目需求和功能验收标准。
• 确定系统架构、技术选型和模块划分。
• 向AI提供项目背景、现有代码和具体修改要求。
• 检查AI提出的技术方案，决定是否采纳。
• 结合程序实际运行情况发现问题并提出新的修改要求。

AI主要负责：

• 阅读项目代码，分析现有模块结构。
• 根据Prompt生成或修改相关代码。
• 协助完成前后端接口和业务逻辑。
• 根据错误信息定位问题并提出修复方案。
• 补充测试用例，执行测试和代码检查。

（3）模块化开发流程

考虑到项目涉及前端、后端、数据库、外部LLM服务和服务器部署等多个部分，团队没有要求AI一次性生成整个项目，而是按照八人分工和模块之间的依赖关系，将开发任务拆分为相对独立的工作。

具体开发流程如下：

flowchart TD
    A["分析课程要求与项目需求"] --> B["确定系统架构与模块分工"]
    B --> C["明确当前开发任务"]
    C --> D["向AI提供项目背景与Prompt"]
    D --> E["AI阅读代码并分析实现方案"]
    E --> F["AI生成或修改代码"]
    F --> G["人工检查修改内容"]
    G --> H["运行程序与测试"]
    H --> I{"是否达到预期"}
    I -->|"否"| J["反馈问题与补充约束"]
    J --> D
    I -->|"是"| K["整合模块并提交代码"]

团队按照后端基础与数据、用户认证与报名、会议业务、LLM推荐、前端平台与国际化、前端业务页面、视觉优化和部署文档等模块开展协作。

在开发顺序上，优先确定数据库结构和后端接口，再逐步完成前端页面与交互，最后进行系统整合、问题修复和部署。

9.2 典型开发案例与关键Prompt

本次项目中，团队通过多轮自然语言交互完成了多个具有代表性的开发任务。以下选取两个核心功能开发案例和三个Bug修复案例，展示真实的人机协作过程。

（1）案例一：LLM智能论坛推荐功能开发

开发背景：

课程要求用户能够通过自然语言描述自己的研究兴趣，由大语言模型推荐相关论坛，并给出推荐理由。

这一功能涉及本地论坛数据、候选召回、外部模型调用、结果校验和异常处理。开发过程中，团队最初尝试接入OpenAI兼容模型服务，但实际使用时出现推荐功能无法正常工作的情况。

因此，团队进一步要求AI检查当前推荐API、论坛数据结构、环境配置和前端调用，重新梳理完整推荐链路。

真实Prompt：

角色：你是负责本项目 Spring Boot 后端的工程师。
请先检查当前推荐 API、论坛数据结构、环境配置和前端调用，
再给出最小必要修改。

项目背景：
系统已有论坛目录，论坛 ID、标题、简介和主题来自数据库及
CNCC 官方数据包。用户输入自然语言研究兴趣，要求推荐一到
多个系统中真实存在的论坛，并查看详情、继续报名。

目标行为：

1. 推荐请求接收用户兴趣描述和当前界面语言。
2. 先从本地论坛目录召回候选，再调用 OpenAI 兼容
   Chat Completions 模型做筛选或排序。
3. 模型只允许返回候选论坛 ID、分数和推荐理由；
   论坛标题、介绍和详情必须由系统数据库补回。
4. 按配置顺序调用主服务和两个备用服务；
   服务超时、HTTP 错误、格式不合法、候选 ID 不合法
   或没有有效推荐时继续尝试下一个服务。
5. 全部模型服务不可用时，返回本地关键词匹配结果，
   并在响应中清楚标示推荐来源和是否回退。

约束：

不要让模型自由编造论坛名称、时间、地点、主席或来源。
模型返回的 ID 必须是本次候选列表中的 ID。
API 地址、模型名和 API Key 只从后端环境变量读取，
不放进 Vue 包、Git 记录、日志或截图。

开发过程与AI输出：

在首轮实现后，团队发现推荐功能仍然存在调用失败的问题，于是继续向AI反馈实际情况，并要求其从完整调用链进行排查。

随后，团队明确增加TokenRhythm作为备用模型服务，并指定DeepSeek官网服务作为最后一个模型服务回退。

最终形成以下调用顺序：

SenseNova（主服务）
       ↓ 失败或无有效结果
TokenRhythm（备用服务）
       ↓ 失败或无有效结果
DeepSeek（备用服务）
       ↓ 全部失败
本地关键词匹配推荐

AI根据后续要求完善了候选论坛ID约束、推荐分数校验、JSON格式检查和推荐理由语言检查。

团队最终采纳了本地候选召回与LLM筛选相结合的方案，而没有采用让模型直接生成论坛名称和详细信息的方式。

（2）案例二：CNCC官方数据包接入与论坛数据关联

开发背景：

课程提供了CNCC 2026官方数据包，其中包含论坛目录、完整活动列表、报告明细、主题分类、数据来源和质量说明等资料。

团队需要将这些数据接入系统，使用户能够浏览真实论坛信息，并查看对应的官方议程。

这一任务的难点在于：完整活动列表并不全部属于可报名论坛，同时项目论坛编号与官方议程编号之间也需要建立可靠的对应关系。

真实Prompt：

角色：你是负责会议数据导入和后端数据模型的工程师。
先检查我给出的 CNCC 2026 数据包、当前论坛表结构和导入流程，
再提出数据映射并实施最小修改。

输入：
课程数据包位于：
E:\homework\软件工程实践\CNCC2026作业数据包

项目工作目录为：
E:\homework\软件工程实践\极限编程

目标行为：

1. 识别数据包中的论坛、完整活动、报告明细、
   主题、来源和质量说明文件。

2. 将必要原始文件和来源说明放入项目资源目录，
   保持原始数据可追溯；提供供系统初始化使用的论坛主数据。

3. 支持论坛目录、详情和已关联的官方议程信息查询。

4. 通过稳定编号或明确的交叉映射关联项目论坛与官方议程，
   不以相似标题猜测无法确认的关系。

数据规则：

分开处理“作业论坛目录”与“完整会议活动列表”；
非论坛活动不得自动加入可报名目录。

保留来源中缺失的主题、人员、报告时间和会场；
不推断、不杜撰。

保留采集来源、质量报告、原始 ID 和映射关系。

导入流程应能在空库初始化，也应避免重复启动时
重复插入数据。

开发过程与AI输出：

AI首先对数据包进行分类整理，随后协助建立论坛主数据、官方议程数据和编号交叉映射关系。

团队对AI提出的方案进行了检查，最终决定将项目论坛目录与完整会议活动列表分开处理，并通过独立的crosswalk文件建立可靠关联。

最终数据整理情况如下：

数据类型	实际数量
项目论坛目录	170场
完整会议活动	217条
非报名论坛活动	47条
官方报告明细	758条
可靠论坛议程映射	168组

其中，168组映射包括149组规范化标题匹配，以及19组标题存在变化、结合人员信息核对后确认的映射。

对于未能确认的对应关系，团队保留未匹配状态，没有强行关联。

主要实现位置包括：

• DemoSeedRunner.java：初始化项目论坛数据。
• OfficialProgramService.java：读取官方议程及交叉映射。
• ConferenceController.java：提供论坛目录、详情和官方议程查询接口。
• backend/src/main/resources/cncc2026-source/：保存官方数据资源。

（3）案例三：毛玻璃界面透明度与布局问题修复

问题背景：

在前端视觉优化过程中，团队发现页面卡片虽然能够显示背景云图，但面板底色不够清晰，正文和次级文字的可读性不足。

打开论坛详情或登录弹窗后，背景和弹窗之间的层次也不够明显。同时，导航栏中的透明度滑块出现布局溢出问题。

真实Prompt节选：

角色：你是负责当前 CNCC 页面视觉回归和可访问性的
前端工程师。

先检查 ConferenceView.vue 与 styles.css 中的玻璃面板、
弹窗遮罩和透明度滑块，再复现截图里的问题。

要解决的问题：

背景仍能从卡片和页面中看见，但面板底色足够清晰，
正文与次级文字都有可读对比度。

打开论坛详情或登录弹窗时，背景可以轻微退暗，
但弹窗自身保持明亮，不能出现整块灰蒙或文字
被遮罩压暗的效果。

导航栏有可调滑块，显示百分比；
调整后即时作用于相关玻璃面板，并在刷新页面后保持选择。

滑块轨道、圆形手柄、百分比和容器必须完整留在导航栏内，
不得超出或导致横向滚动。

实现约束：

不降低文字本身的 opacity；
通过面板背景色、遮罩和 CSS 变量调节透明效果。

（4）案例四：云图背景循环动画接缝问题

问题背景：

项目首页采用动态云图作为页面背景，要求上半部分保持纯色天空，下半部分展示缓慢移动的云层。

在实际页面效果中，云图循环移动时出现拼接接缝，影响背景的整体观感。

真实Prompt节选：

角色：你是负责页面背景动效的前端工程师。
检查当前 App.vue、云图资源和 styles.css，
用用户提供的接缝截图复现问题。

目标：

视口上半部保持均匀纯色天空；
云层只出现在下半部，分界自然。

云层缓慢从左向右移动，并连续循环；
循环重置时不能闪白、露底、出现竖直硬边
或亮度、颜色突变。

定位要求：

不要只根据资源文件名判断图片已经无缝；
先检查图像左右边缘和页面轨道位移关系。

检查轨道宽度、单张图块宽度、重复数量、
动画起止位移和图块间隙。

用临时调试速度观察从首帧、中间帧到循环重置前后的边界；
测试结束后恢复慢速正式值。

（5）案例五：演示账号登录失败的全链路排查

问题背景：

系统为参会者、会议主席、论坛主席和秘书提供了四种本地演示账户。

开发过程中，出现点击演示账户后，登录界面连续提示操作失败的情况。

由于问题可能涉及前端账户填充、后端登录接口、数据库初始化和认证配置，团队要求AI从完整登录链路进行排查。

真实Prompt节选：

角色：你是负责 CNCC 助手登录链路的全栈排错工程师。
请依据实际请求和数据库状态定位，
不要先假设问题只在前端。

复现步骤：

1. 启动当前本地配置，打开登录弹窗。
2. 分别点击四种角色的本地演示账户，再点击登录。
3. 在浏览器 Network 中记录演示账户查询和登录请求的
   URL、状态码、响应字段。
4. 检查服务端当前 profile、DEMO_PASSWORD 配置、
   用户表中的账号角色和密码哈希是否一致。

请检查：

ConferenceView.vue
api.js
AuthController.java
DemoSeedRunner.java

修复约束：

演示账户列表、数据库种子和登录校验必须使用
同一份服务端配置。

不要在日志中输出明文密码或 JWT，
不要通过关闭认证来“修复”问题。

保持普通参会者注册和登录逻辑不受影响。

9.3 AI生成结果与迭代优化

通过上述开发案例可以看出，AI生成的代码并不是一次性完成的，而是根据团队反馈不断调整。以下从几个方面总结实际的迭代过程。

（1）LLM推荐服务的多轮迭代

阶段	遇到的问题或新增需求	AI辅助完成的调整
第一阶段	接入OpenAI兼容模型服务	建立推荐API和模型调用流程
第二阶段	实际推荐功能调用失败	检查候选召回、API请求和异常处理
第三阶段	增加备用模型服务	建立SenseNova、TokenRhythm、DeepSeek调用顺序
第四阶段	模型可能返回不存在的论坛	增加候选ID、分数和JSON格式校验
第五阶段	推荐理由语言可能不符合界面语言	增加推荐理由语言检查和本地理由替代
第六阶段	需要进一步提高异常情况下的可用性	增加本地关键词匹配回退和模拟服务测试

最终，系统采用先本地召回、再LLM筛选的方式。

本地根据论坛标题、主题、简介和单位进行关键词匹配，最多召回8个候选论坛。模型最多返回5个推荐结果，推荐分数需要达到0.5。

（2）官方数据接入的迭代优化

数据接入过程中，团队重点完善了官方论坛与项目论坛之间的关联方式。

最终形成以下数据处理流程：

flowchart TD
    A["CNCC官方数据包"] --> B["识别论坛、活动和报告数据"]
    B --> C["保留原始数据及来源说明"]
    C --> D["整理170场项目论坛"]
    C --> E["整理官方议程及758条报告"]
    D --> F["建立crosswalk交叉映射"]
    E --> F
    F --> G["168组可靠映射"]
    G --> H["OfficialProgramService"]
    H --> I["论坛详情展示官方议程"]

在数据关联过程中，团队没有直接采用标题相似度进行强制匹配，而是对标题变化的记录结合人员信息进行核对。

（3）毛玻璃界面的迭代优化

针对页面透明度和文字可读性问题，AI协助调整了ConferenceView.vue和styles.css。

最终采用独立CSS变量管理不同组件的透明度：

样式变量	控制对象	最小值	中间值	最大值
--glass-opacity	页面玻璃面板	0.40	0.64	0.88
--glass-dialog-opacity	弹窗背景	0.93	0.94	0.99
--glass-control-opacity	输入控件背景	0.14	0.22	0.31

同时，透明度滑块范围设置为40%—88%，调整结果实时作用于页面，并保存在localStorage中。

这一方案避免了统一降低文字透明度造成的可读性问题，也使弹窗和页面卡片能够拥有不同的视觉层次。

（4）云图背景的迭代优化

针对云图循环接缝，AI协助调整了App.vue和styles.css。

当前实现采用四张云图重复构成循环轨道，主要参数如下：

项目	当前实现
天空背景色	#d9eff8
云层显示区域	视口底部约45vh
动画周期	360秒
轨道位移	translateX(-50%)至translateX(0)
图块边缘处理	相邻图块重叠2px
图块宽度	clamp(720px, 180vh, 2080px)

同时增加了pointer-events: none，避免背景动效影响页面交互，并对系统减少动态效果的设置进行适配。

团队还检查了实际使用的cloud-sky-seamless.png，其尺寸为2172×724，并对图片左右边缘进行了RGB差异分析，为后续背景接缝优化提供依据。

9.4 AI生成代码的检查与测试

在AI辅助开发过程中，团队不仅关注代码是否成功生成，还通过代码检查、单元测试、接口测试和实际页面操作验证功能。

（1）LLM推荐功能测试

针对推荐服务，团队使用本地模拟模型服务编写测试，避免单元测试依赖真实外部模型API。

测试覆盖内容如下：

测试场景	检查内容
有效候选	模型返回合法候选论坛ID
候选外ID	拒绝模型返回的不存在或不属于候选集的ID
错误JSON	检查异常格式处理
服务超时	检查超时后的备用服务切换
顺序切换	检查多个模型服务是否按照配置顺序调用
全部服务失败	检查本地关键词匹配回退
未配置服务	检查没有外部模型配置时的处理

最终，RecommendationServiceTest.java增加了本地模拟服务测试，不需要调用真实模型。

测试执行结果：

测试通过

• 推荐服务测试：8项。
• 日程测试：3项。
• 合计：11项测试通过。

执行命令：

mvn -q test

此外，团队还执行了Docker Compose配置检查和Git差异检查：

docker compose --env-file .env.example config --quiet
git diff --check

两项检查均通过。

（2）个人日程边界测试

针对个人日程冲突检测，团队重点检查三个边界情况：

测试场景	预期结果
两个论坛时间存在重叠	判定为冲突
一个论坛结束时另一个论坛恰好开始	不判定为冲突
论坛开始或结束时间缺失	不参与冲突判断

系统采用以下判断条件：

通过这一条件，可以正确处理论坛时间首尾相接的情况。

（3）官方数据质量检查

针对官方数据包，团队对数据数量、编号和时间字段进行了检查。

主要检查结果如下：

• 项目论坛共170场，官方完整活动列表共217条。
• 758条报告记录中，318条缺少完整报告时间。
• 86条报告涉及官网占位日期处理。
• 另有3条报告时间超出所属论坛整体时段。
• 官方论坛ID和名称均无重复，起止时间均存在，未发现结束时间早于或等于开始时间的记录。
• 49场论坛未提供官方主题，27场未单独列出主席。

这些数据质量信息保留在官方数据资源和质量说明文件中，避免在数据导入过程中丢失原始信息。

（4）演示账号登录验证

针对演示账号登录失败的问题，团队通过实际HTTP请求和数据库状态进行验证。

主要验证结果：

测试场景	实际结果
获取演示账号列表	HTTP 200
参会者登录	HTTP 200
会议主席登录	HTTP 200
论坛主席登录	HTTP 200
秘书登录	HTTP 200
错误密码登录	HTTP 401
登录后获取当前用户信息	HTTP 200
登录后获取个人报名	HTTP 200
登录后获取个人日程	HTTP 200
登录后获取论坛通知	HTTP 200

四种角色的登录结果分别对应：

• ATTENDEE
• CONFERENCE_CHAIR
• FORUM_CHAIR
• SECRETARY

9.5 开发问题排查与方案验证

本次项目中，团队遇到的问题涉及业务逻辑、外部API、数据关联、前端布局和运行环境等多个方面。通过Codex读取项目代码、执行命令和检查运行结果，逐步形成了从问题复现到定位、修改和验证的排查方式。

（1）毛玻璃弹窗与透明度滑块布局问题

问题现象：

初始页面中，卡片底色较为透明，云层细节与文字叠加，导致正文和次级文字对比度不足。

打开论坛详情或登录弹窗时，遮罩与弹窗背景没有形成清晰层次，使弹窗整体显得发灰。

此外，透明度滑块受导航栏固定宽度和弹性布局影响，轨道、手柄及百分比在有限空间中容易超出容器。

AI排查与修改：

AI首先检查了ConferenceView.vue和styles.css，将问题定位到面板背景、弹窗遮罩和滑块布局三个方面。

随后进行了以下调整：

1. 使用独立CSS变量控制页面玻璃面板、弹窗和输入控件的透明度。
2. 保留文字本身的透明度，改为调整面板背景色。
3. 将弹窗背景设置为更高的不透明度，增强弹窗与页面之间的层次。
4. 调整滑块容器宽度和弹性布局，避免轨道及百分比溢出。
5. 增加透明度数值显示、键盘焦点样式和本地持久化。

修改文件：

• ConferenceView.vue
• styles.css

（2）云图背景循环接缝问题

问题现象：

页面背景使用云图进行循环移动，但在动画衔接过程中出现明显接缝，影响页面整体视觉效果。

AI排查与修改：

AI没有仅通过调整动画速度处理问题，而是进一步检查了云图资源左右边缘、轨道宽度、图块数量、动画位移和图块之间的间距。

最终采用四张云图构成循环轨道，通过360秒缓慢移动，并使用2px负间距减少相邻图块之间的接缝。

同时，团队对实际云图资源进行了边缘分析：

• 图片尺寸：2172×724。
• 左右边缘RGB平均差：2.04。
• 95百分位差值：约5。
• 最大行平均差：15.33。

分析结果表明，图片大部分边缘区域具有较好的相似性，但仍存在局部差异，因此不能仅根据图片文件名称判断其完全无缝。

此外，检查部署资源时发现，frontend/dist中包含当前云图资源，而frontend/deploy-dist中没有该文件。若部署时直接使用旧的deploy-dist，需要重新构建部署包，确保背景资源完整。

修改文件：

• App.vue
• styles.css
• 云图资源cloud-sky-seamless.png

（3）演示账号登录失败问题

问题现象：

在项目测试过程中，用户点击本地演示账户后，页面连续出现“操作失败，请稍后再试”的提示，无法正常完成登录。

AI排查过程：

团队要求AI从完整请求链路进行检查，而不是只修改登录页面。

首先检查前端演示账户加载和登录请求，再检查后端演示账户接口、数据库初始化和认证配置。

实际排查发现，默认请求地址为：

http://127.0.0.1:8080/api/auth/demo-accounts

当时8080端口没有监听进程，接口请求直接被拒绝，没有返回HTTP状态码。

进一步检查发现，Windows TCP排除端口范围为8077—8176，其中包含8080和8081。

解决方案：

团队将后端调整为使用8280端口，并启动local profile，随后重新执行登录验证。

最终验证结果：

1. GET /api/auth/demo-accounts成功返回HTTP 200。
2. 接口正确返回四种角色的演示账户。
3. 四种角色均能够正常登录，返回HTTP 200。
4. 错误密码仍然返回HTTP 401。
5. 登录后获取用户信息、报名、日程和通知的接口均返回HTTP 200。
6. 在空H2数据库初始化后，四种角色均能够正常登录。
7. 对已有持久化数据库副本进行验证，四种账号仍然能够正常登录。

同时，团队检查了BCrypt密码哈希格式、数据库持久化状态和演示账号初始化逻辑，确认本次验证没有复现持久化数据库哈希与当前演示密码不匹配的问题。

涉及文件：

• frontend/src/views/ConferenceView.vue
• frontend/src/api.js
• backend/src/main/java/cncc/assistant/api/AuthController.java
• backend/src/main/java/cncc/assistant/service/DemoSeedRunner.java

（4）问题排查经验总结

通过上述问题的处理，团队逐渐形成了较为清晰的问题排查方法：

排查步骤	具体做法
问题复现	提供实际错误截图、操作步骤和运行环境
代码定位	要求AI检查相关文件及模块之间的调用关系
原因分析	从数据、接口、前端状态和运行环境等方面分析
方案修改	明确修改范围和实现约束，要求AI进行针对性调整
结果验证	通过接口请求、单元测试和实际页面操作检查修改效果

相比只向AI描述“程序无法正常运行”，提供具体的错误信息、文件位置和验收要求，能够帮助AI更准确地定位问题，也减少了无关代码修改。

9.6 AI Coding实践总结与反思

通过本次CNCC 2026智能会议助手的开发，团队对AI辅助软件工程开发有了更加深入的认识。

（1）明确的需求比简单的代码生成更重要

在项目初期，团队逐渐发现，AI生成代码的质量与Prompt的完整程度有很大关系。

如果只提出一个简单的功能要求，AI可能只关注当前页面或单个接口，而忽略数据库结构、前后端调用关系和异常处理。

例如，在智能推荐功能开发中，团队不仅要求AI实现模型调用，还明确规定候选论坛ID约束、推荐分数、语言要求、模型回退顺序和密钥管理方式。

这种带有明确业务规则和验收标准的Prompt，更容易得到符合项目实际需求的实现方案。

（2）AI能够提高跨模块开发效率

本项目采用前后端分离架构，涉及Vue前端、Spring Boot后端、数据库、外部模型服务和部署环境。

在实际开发中，部分问题并不局限于单个文件。例如演示账号登录失败，就涉及前端账户填充、HTTP请求、后端认证接口和数据库初始化。

Codex能够直接阅读项目文件、追踪调用关系并修改多个相关模块，使开发者能够更快地定位问题和完成迭代。

（3）AI生成的方案需要结合实际业务进行判断

AI能够提供多种技术方案，但并不意味着所有建议都应该直接采用。

在官方数据接入过程中，团队最终采用独立crosswalk文件建立论坛映射，而不是简单按照标题相似度进行匹配。

在LLM推荐过程中，团队要求模型只能返回真实候选论坛ID，再由数据库补充论坛详情。

这些设计体现了团队对数据可靠性和业务一致性的重视。

（4）测试验证是AI Coding不可缺少的环节

本次开发使团队认识到，代码能够生成和程序能够正常运行是两个不同的概念。

无论是模型API调用、论坛数据映射，还是用户登录和日程冲突判断，都需要通过实际测试验证。

特别是在涉及外部模型服务和复杂业务边界时，仅依靠AI对代码的解释并不足以判断功能是否正确，必须结合实际运行结果。

（5）软件工程能力不仅体现在编码，还体现在组织与协作

本次项目由八名成员共同完成。团队在开发过程中需要协调不同模块的开发顺序、接口规范和任务依赖关系。

通过实际分工和代码整合，团队更加深刻地认识到，合理的任务拆分、明确的责任划分和可执行的开发计划，是保证项目稳步推进的重要条件。

总体而言，本次项目让团队体验了AI从需求分析、技术设计、代码生成到测试排错的完整开发过程。

AI显著提高了代码实现和问题定位的效率，而开发人员对需求的理解、技术方案的判断、测试结果的分析以及团队协作，仍然决定着最终软件系统的质量。

这也是本次AI Coding实践带给团队最重要的收获。

10. 附加功能实现

除课程要求的基础功能外，团队还实现了多语言支持、个人参会日程和时间冲突检测等附加功能。这些功能进一步完善了系统的实用性，使参会者能够根据自身使用习惯浏览会议内容，并根据已经报名的论坛合理安排参会时间。

10.1 多语言支持

（1）功能需求

CNCC 2026 是面向不同国家和地区计算机领域研究人员的学术会议。考虑到参会者可能使用不同语言，团队在基础论坛浏览功能之上增加了多语言支持。

系统目前支持五种界面语言：

• 简体中文
• 繁体中文
• 英语（English）
• 德语（Deutsch）
• 日语（日本語）

用户可以通过页面的语言切换控件选择所需语言。切换后，系统会同步更新导航菜单、按钮、表单、提示信息、论坛日程、通知中心以及管理工作台等界面文案。

同时，多语言功能不仅作用于固定的界面文字，还覆盖了论坛标题、论坛简介、主题分类和部分地点信息，使不同语言环境下的用户能够正常浏览会议内容。

（2）技术实现

前端采用 Vue 3 和 vue-i18n 实现国际化功能，将不同语言的文本资源集中管理，避免在各个页面中直接编写大量语言判断逻辑。

主要实现方式如下：

第一步：建立统一语言资源目录

在frontend/src/locales/目录下集中保存不同语言的JSON资源文件。

公共界面文案按照功能进行组织，包括：

• 导航菜单和页面标题；
• 按钮、输入框和表单提示；
• 登录注册及错误提示；
• 个人日程和论坛通知；
• 不同角色的管理工作台。

页面组件通过统一的国际化接口获取对应语言的文本。

第二步：建立论坛数据翻译资源

由于论坛标题和简介属于数据库中的动态业务数据，不能简单地通过公共界面翻译文件进行处理，因此团队为论坛内容建立了独立的翻译资源。

目前的数据整理情况如下：

翻译内容	覆盖数量	支持语言
论坛标题	170条	繁体中文、英语、德语、日语
论坛简介	170条	简体中文、繁体中文、英语、德语、日语
主题分类	共享词条	多语言
论坛类型	共享词条	多语言
部分地点	共享词条	多语言

论坛翻译资源采用论坛ID进行关联，使翻译内容能够与对应的论坛记录保持一致，而不依赖标题文本进行匹配。

对于人名、单位名称等专有名称，系统保留官方来源文本，避免不必要的翻译造成信息失真。

第三步：实现语言切换与持久化

用户切换语言时，前端通过vue-i18n更新当前语言环境，使引用国际化资源的页面内容同步刷新。

同时，系统使用浏览器localStorage保存用户选择的语言。用户重新打开页面时，能够继续使用上一次选择的语言。

对于缺少对应翻译的内容，系统默认回退到简体中文，避免页面出现空白文本。

（3）多语言功能实际效果

在实际使用过程中，用户可以通过语言切换控件改变整个系统的显示语言。

例如，当用户将界面切换为英语时：

1. 导航栏中的页面名称同步切换为英文。
2. 论坛列表中的标题和简介显示对应英文内容。
3. 论坛详情中的分类、地点等支持翻译的字段同步更新。
4. 个人日程、通知中心和管理工作台中的固定文案同步切换。
5. 刷新页面后，系统仍然保留用户之前选择的语言。

此外，智能论坛推荐接口也会接收当前界面语言，推荐结果的理由会根据用户当前使用的语言生成；如果模型返回的理由不符合当前语言要求，则使用本地生成的对应语言理由。

通过多语言支持，系统不仅能够满足不同语言用户的基本浏览需求，也使论坛信息、个人日程和管理功能形成了相对完整的国际化体验。

10.2 个人参会日程与时间冲突检测

（1）功能需求

CNCC 2026 包含大量不同主题的论坛，同一时间段可能安排多个论坛。参会者在选择论坛时，如果只依靠论坛详情中的时间信息进行人工判断，很容易出现报名多个时间重叠论坛的情况。

因此，团队设计了个人参会日程功能。

用户登录系统后，可以在论坛详情中选择自己感兴趣的论坛并进行报名。系统根据用户已经报名的论坛，自动生成个人日程，并检查不同论坛之间是否存在时间冲突。

该功能主要包含以下内容：

• 自动获取当前用户已经报名的论坛。
• 按照论坛开始时间对个人日程进行排序。
• 自动检测不同论坛之间的时间重叠情况。
• 用户新增或取消报名后，自动更新个人日程。
• 支持对论坛时间和地点进行受权限控制的更新，并在后续日程查询时重新计算冲突。

（2）个人日程生成流程

个人日程不是由用户单独创建的，而是直接根据用户的论坛报名记录生成。

具体操作流程如下：

1. 用户注册账号并登录系统。
2. 进入论坛议程页面，浏览感兴趣的论坛。
3. 点击论坛卡片进入详情页面。
4. 在论坛详情中选择报名。
5. 后端保存当前用户与论坛之间的报名关系。
6. 前端重新请求个人日程接口，获取最新的报名论坛及冲突信息。
7. 系统按照论坛开始时间排序，生成个人参会日程。

如果用户取消某个论坛的报名，系统也会重新获取日程信息，并重新计算剩余论坛之间的时间冲突。

（3）后端接口设计

个人日程功能主要由后端ScheduleController负责，前端通过统一API请求模块与后端交互。

相关接口如下：

API接口	请求方式	功能
/api/me/registrations	GET	获取当前用户的报名记录
/api/forums/{id}/registrations	POST	报名指定论坛
/api/forums/{id}/registrations	DELETE	取消指定论坛报名
/api/me/schedule	GET	获取个人日程及时间冲突列表
/api/admin/forums/{id}/schedule	PUT	更新指定论坛的时间和地点

其中，个人日程接口会根据当前登录用户的身份获取其报名数据，并返回对应的论坛安排和冲突信息。

前端在用户完成报名或取消报名后，会重新请求个人日程接口，保证页面展示的数据与后端最新状态一致。

在这一过程中，团队还统一了前端API调用方式，避免出现后端报名记录已经更新，但个人日程仍然显示旧数据的问题。

（4）时间冲突检测算法

时间冲突检测是个人日程功能的核心。

情况一：两个论坛存在时间重叠

论坛	开始时间	结束时间
论坛A	09:00	10:30
论坛B	10:00	11:00

两个论坛的时间区间存在交集，因此系统判定为冲突。

情况二：两个论坛恰好首尾相接

论坛	开始时间	结束时间
论坛A	09:00	10:00
论坛B	10:00	11:00

论坛A在10:00结束，论坛B也恰好在10:00开始。

由于采用左闭右开区间，两个论坛并不存在时间重叠，因此不判定为冲突。

情况三：论坛时间信息不完整

如果某个论坛缺少开始时间或结束时间，系统不会直接将其判定为冲突，而是跳过该论坛的时间比较。

这样可以避免因为缺失数据而产生错误的冲突提示。

（5）排期更新与冲突重新计算

除了参会者通过报名和取消报名调整个人日程外，系统还考虑了会议组织方调整论坛时间的情况。

会议主席或秘书可以通过受权限控制的后端接口：

PUT /api/admin/forums/{id}/schedule

更新指定论坛的开始时间、结束时间和地点。

后端会检查更新时间的合法性，确保结束时间晚于开始时间。

当论坛排期发生变化后，用户下一次查询个人日程时，系统会根据数据库中的最新排期重新计算冲突，而不是继续使用旧的时间数据。

因此，个人日程始终以当前报名记录和论坛排期为依据。

（6）功能测试与边界验证

为了保证时间冲突检测的准确性，团队在ScheduleControllerTest.java中针对不同时间情况设置了独立测试用例。

主要测试内容如下：

测试项目	测试输入	预期结果
时间重叠	两个论坛的时间区间存在交集	判定为冲突
时间首尾相接	一个论坛结束时间等于另一个论坛开始时间	不判定为冲突
开始时间缺失	某个论坛没有开始时间	跳过冲突判断
结束时间缺失	某个论坛没有结束时间	跳过冲突判断
报名发生变化	新增或取消论坛报名	重新生成个人日程
排期发生变化	更新论坛时间和地点	后续查询使用最新排期

其中，时间重叠、首尾相接和时间缺失是该功能最重要的三个边界测试场景。

通过个人日程与时间冲突检测功能，系统将原本分散在不同论坛详情中的报名信息整合起来，使参会者能够集中查看自己的会议安排，并及时发现时间重叠问题。

同时，该功能与论坛报名、官方排期和用户身份认证等模块形成了完整的业务关联，进一步提高了系统在实际会议场景中的使用价值。

11. 项目总结与展望

11.1 项目完成情况总结

本项目围绕 CNCC 2026 学术会议的实际参会需求，设计并实现了一套集会议论坛展示、用户注册登录、论坛报名、参会人数统计、参会者信息管理、论坛通知、智能论坛推荐和个人参会日程于一体的智能会议助手系统。经过团队成员的分工协作和多轮 AI Coding 开发迭代，目前已经形成了较为完整的前后端应用，具备了实际运行和交互使用的能力。

在基础功能方面，系统完成了会议首页、论坛目录、论坛详情等页面的设计与实现。系统整理并导入了 CNCC 2026 官方数据，建立了包含 170 条论坛记录的论坛目录，并通过独立的编号映射关联官方议程，目前已有 168 条可靠映射。用户可以通过关键词搜索和主题筛选查找感兴趣的论坛，查看论坛简介、主席、单位、时间、地点以及关联的官方报告信息。

在用户管理方面，系统实现了用户注册、登录、JWT 身份认证和基于角色的权限管理，支持参会者、会议主席、论坛主席和秘书四种角色。不同角色登录后可以使用相应的业务功能，包括会议报名统计、负责论坛统计、参会者信息查询和论坛通知管理等。

在业务功能方面，系统实现了论坛报名与取消报名、参会人数统计、论坛通知发布及个人参会日程管理。参会者可以根据自己的兴趣报名多个论坛，系统自动生成个人日程，并通过时间区间判断识别不同论坛之间的时间冲突。同时，系统支持多语言界面和论坛内容展示，为不同语言背景的用户提供更加便利的使用体验。

在智能化功能方面，项目接入了大语言模型，实现了基于自然语言的智能论坛推荐。用户只需输入自己的研究方向和兴趣，系统便可以从真实论坛数据中筛选候选论坛，并结合大模型生成推荐结果及理由。同时，推荐服务建立了多模型备用调用和本地关键词匹配回退机制，提高了推荐功能在外部模型服务异常情况下的可用性。

在界面设计方面，团队完成了具有会议主题特色的首页和业务页面设计，加入了毛玻璃效果、透明度调节、动态云层背景、鼠标粒子拖尾、响应式布局等视觉交互效果，使系统在满足业务需求的同时具备较好的视觉表现。

在技术实现方面，项目采用 Vue 3、Element Plus 和 vue-i18n 构建前端，使用 Java 17、Spring Boot 3 和 Spring Security 实现后端业务及权限控制，通过 H2、MySQL 支持不同运行环境下的数据存储，并提供 Docker Compose 和 Nginx 等部署方案。

总体而言，项目已经完成了从会议数据管理、用户身份认证、论坛浏览报名到智能推荐和个人日程管理的主要业务链路，实现了一个具有实际应用场景的智能会议助手。

11.2 团队协作与AI Coding实践收获

本次项目采用八人团队协作开发模式，根据系统功能模块和技术依赖关系进行任务分工。团队成员分别负责系统架构与部署、会议数据整理、用户认证与报名、会议业务管理、智能推荐、前端国际化、前端业务页面以及视觉设计与质量优化等工作。

在开发过程中，团队按照先后端基础与数据结构、再业务接口与前端页面、最后视觉优化和系统整合的思路推进开发。通过明确各模块的功能职责和接口关系，减少了不同成员之间的开发冲突，也使各个模块能够逐步整合到统一的系统中。

本次项目的一项重要实践是将 AI Coding 引入软件开发全过程。团队主要通过自然语言 Prompt 向 AI 编程代理描述开发需求，让其先检查现有项目结构和代码，再根据具体任务进行分析、修改和优化。

在实际开发中，我们逐渐认识到，高质量的 AI Coding 并不是简单地向模型提出一个功能需求，而是需要明确角色定位、项目背景、目标行为、实现约束和验收标准，使 AI 能够理解当前项目的实际情况，并在已有代码基础上完成相应工作。

例如，在智能论坛推荐功能开发中，团队并没有仅仅要求 AI 实现一次大模型调用，而是进一步明确了候选论坛必须来自真实数据库、模型只能返回有效论坛 ID、推荐理由需要符合当前界面语言，以及主模型和备用模型的调用顺序等要求。经过多轮交互，最终形成了 SenseNova、TokenRhythm 和 DeepSeek 的备用调用链路，并增加本地关键词匹配回退机制。

在官方数据接入过程中，团队要求 AI 检查 CNCC 数据包中的论坛目录、完整活动列表、报告明细和编号映射，最终将论坛主数据与官方详细议程分开管理，既保留了数据来源，也避免了将非论坛活动错误加入报名目录。

此外，在前端开发和问题排查过程中，团队也通过真实截图与 AI 进行多轮交互。例如，针对毛玻璃面板透明度过高、文字可读性不足和滑块布局溢出等问题，要求 AI 检查相关 Vue 页面和 CSS 样式；针对云层背景循环出现拼接缝的问题，要求 AI 检查图片边缘、轨道宽度和动画位移关系；针对演示账号登录失败的问题，则从前端账号填充、登录 API、后端账户初始化和 BCrypt 密码校验等多个环节进行排查。

这些实际开发经历使我们认识到，AI Coding 不仅能够辅助生成代码，还能够参与需求拆解、代码分析、问题定位和方案优化。但 AI 生成的代码仍然需要结合项目实际情况进行检查，尤其是涉及数据库关系、权限控制、外部 API 和业务边界的部分，不能仅凭代码生成结果判断功能已经正确实现。

通过本次实践，团队主要获得了以下收获：

1. 提高了需求分析与任务拆解能力。 将相对复杂的业务需求拆分为数据处理、接口开发、前端交互和测试验证等具体任务，使开发过程更加清晰。
2. 提升了 AI 辅助开发能力。 学会通过结构化 Prompt 提供上下文、限制实现范围和明确验收标准，使 AI 输出更加符合项目实际需求。
3. 增强了系统集成意识。 在前后端协作过程中，逐渐认识到接口字段、数据库结构、身份权限和页面状态之间的关联关系。
4. 积累了实际问题排查经验。 通过真实错误现象、代码检查和逐步验证，掌握了从用户反馈定位到具体实现环节的基本方法。
5. 加深了对软件工程开发流程的理解。 认识到一个可运行的软件系统不仅需要完成单个功能，还需要考虑模块之间的协作、数据一致性、异常处理、用户体验和部署运行等问题。

总体来看，本次项目让团队从单纯使用 AI 生成代码，逐步转向利用 AI 参与完整的软件开发过程，也使我们对 AI Coding 在实际软件工程中的应用价值有了更加具体的认识。

11.3 项目不足与未来改进方向

虽然目前系统已经实现了主要业务功能，但结合现有实现情况，仍有一些值得进一步完善的地方。

（1）会议数据的完整性与实时性仍有提升空间

目前系统主要使用 CNCC 2026 官方公开数据包作为论坛数据来源，通过本地数据文件和编号映射完成数据导入及详情关联。虽然已经建立了 168 条可靠映射，但仍有少量论坛尚未建立可靠的官方议程对应关系。此外，当前数据属于采集时的公开信息快照，不能自动同步官网后续发生的时间、地点和报告信息变化。

未来可以进一步完善官方论坛与项目论坛之间的映射关系，增加数据更新和校验机制，并探索通过官方数据接口或定期数据采集实现会议资料的增量更新。

（2）智能论坛推荐的召回能力仍需增强

目前推荐功能采用本地关键词匹配召回候选论坛，再利用大语言模型进行筛选和排序。这种方式能够保证推荐结果对应系统中真实存在的论坛，但推荐效果仍然受到关键词覆盖范围的影响，对于用户使用较为宽泛、复杂或者专业性较强的研究描述，可能无法充分召回相关论坛。

未来可以引入向量数据库和语义检索技术，将论坛标题、简介、主题及报告内容转化为语义向量，结合关键词检索与向量相似度进行混合召回，再交由大语言模型完成进一步排序，从而提高推荐结果的相关性和准确性。

（3）消息通知功能可以进一步完善

目前系统已经实现论坛通知的发布和站内查询，参会者能够在通知中心查看自己已报名论坛的相关消息，但通知渠道仍然以站内消息为主。

未来可以增加浏览器消息推送、邮件通知等方式，并根据用户的报名情况和个人日程，在论坛时间调整、重要通知发布或会议即将开始时及时提醒用户。

（4）个人日程功能仍有进一步扩展空间

当前系统能够根据报名记录自动生成个人日程，并检测论坛之间的时间重叠，但暂时没有提供独立的可视化排期编辑工具，管理人员修改论坛排期也主要通过后端接口完成。

未来可以增加日历视图、日程筛选和排期管理界面，使用户能够更加直观地查看每天的参会安排。同时，可以进一步增加日程导出、日历同步和会议提醒等功能，提升系统在真实会议场景中的实用性。

（5）多语言内容覆盖可以继续完善

目前系统已经支持简体中文、繁体中文、英语、德语和日语五种语言，公共界面和主要论坛内容均具有相应的翻译资源。但随着会议资料不断更新，仍然需要持续维护不同语言之间的内容一致性。

未来可以进一步完善翻译资源管理机制，增加新论坛数据的翻译流程，并对不同语言下的页面布局、文字长度和显示效果进行更全面的适配。

（6）系统测试与运行监控可以进一步加强

目前项目已经围绕用户登录、论坛报名、时间冲突、智能推荐和前端交互等功能开展了相应的检查与测试。随着系统功能不断增加，后续还可以进一步完善自动化测试体系。

例如，增加前后端接口集成测试、不同角色的权限测试、数据库异常测试和多浏览器兼容性测试，并结合实际部署环境建立日志监控和服务健康检查机制，提高系统长期运行的稳定性。

通过本次项目开发，团队完成了一个融合传统会议管理功能与大语言模型应用的智能会议助手系统，也在需求分析、系统设计、团队协作和 AI 辅助编程等方面积累了实践经验。

未来，团队希望在现有系统基础上继续完善数据管理、智能推荐和个人日程等核心功能，使系统从当前的课程项目逐步向更加完整、智能和实用的学术会议服务平台发展。