立项背景:高校学生在参加学科竞赛、创新创业、课程设计等项目时,组队往往依赖朋友圈和社交群,效率低且匹配不精准。很多同学技能互补但互相不认识,错过合作机会。TeamUp 旨在用 AI 技术解决校园组队信息不对称的问题。
核心功能模块:
1.智能匹配推荐:基于多维度加权算法(技能匹配 35%、综合评分 25%、专业匹配 25%、活跃度 15%),技能匹配区分 Jaccard 相似度和互补度(互补权重 0.6 > 相似权重 0.4,因为组队更需技能互补),自动计算匹配百分比并给出匹配原因(共同技能、技能互补、同专业、活跃用户),按匹配度降序排列候选人。
2.AI 对话助手"小队":基于 LangChain4j + 百度千帆 GLM-5.1 大模型,支持 Tool Calling 能力,AI 可实时调用 searchTeams(搜索团队)、getTeamDetail(团队详情)、recommendTeams(智能推荐)、getMyTeams(我的队)4 个工具获取真实数据后回答。支持 SSE流式输出、会话管理、AI 自动生成会话标题、上下文记忆(最近 10 条历史注入),并注入学生个人上下文(专业、年级、技能标签、项目经验)实现个性化建议。
3. 组队广场与团队管理:用户可创建团队(设置项目类型、人数上限、技能要求、绩点门槛),浏览/搜索/申请加入团队,队长审批申请、邀请用户、移除成员、转让队长。
4. 邀请与申请系统:支持两种模式——邀请入队(队长主动邀请)和申请入队(用户主动申请),邀请/申请可附带消息,接收方可同意或拒绝,待处理邀请在首页实时提醒。
5. 用户画像与评分:综合评分 = 绩点 × 0.6 + 信誉分 × 0.4,技能标签 JSON 存储,个人简介、年级、专业等信息完善用户画像。
6. 安全认证:Spring Security + JWT(7 天有效期),注册支持验证码(Redis 5 分钟过期),BCrypt 密码加密。
以下附上通过内网穿透 部署在 阿里云云服务器的URL
https://zps0619.natapp1.cc/
用户及密码 admin admin123 (登陆时 并未加入微信接口)
整体架构: 采用前后端分离架构。前端 Vue3 + Vite + Element Plus + Pinia 状态管理,通过 Axios 调用后端 RESTful API;后端Spring Boot 3.2 + MyBatis-Plus + Spring Security + JWT,对接百度千帆 GLM-5.1 大模型(通过 LangChain4j OpenAI 兼容接口)。数据层 MySQL 8.0 存储业务数据,Redis 做验证码存储和匹配结果缓存。
我的负责模块与结果:
1. 智能匹配算法模块:设计了四维加权匹配算法,技能维度区分相似度和互补度(Jaccard 系数 × 0.4 + 互补度 × 0.6),解决了传统只看相似度忽视互补性的问题。实现内存批量计算匹配度避免 N+1 查询,匹配结果 Redis 缓存,接口响应 < 200ms。每个候选人附带可解释的匹配原因列表。
2. AI 对话助手模块:基于 LangChain4j AiServices 构建 ChatAssistant 接口,通过 @Tool 注解将 4 个团队查询方法暴露给大模型,实现 Tool Calling 自动路由。设计了 ThreadLocal 传递当前用户 ID 供工具使用。构建了增强系统提示词——动态注入学生上下文(专业、技能、项目经验),使 AI 回答个性化。支持阻塞式对话(带工具调用)和 SSE 流式输出两种模式。
3. 前端全栈开发:10+ 个页面/组件,包括首页仪表盘(统计卡片、快捷入口、最新招募)、智能匹配页(候选人卡片网格、匹配度百分比、匹配原因、邀请对话框)、AI 对话页(侧边栏会话列表、打字指示器动画、消息气泡)、组队广场、团队详情、个人中心、管理后台等。
遇到的难点与解决方案:
1.大模型 Tool Calling 参数识别问题:用户问"有没有 ACM 队伍"时,AI 总是把竞赛名当作 projectType 而非 keyword 传入。解决:在 SystemMessage 中给出明确的参数映射示例(竞赛名→keyword,项目类型→projectType),准确率从约 40% 提升到 90%+。
2. 匹配查询 N+1 问题:最初对每个候选人单独查库计算匹配度,50 个候选人产生 100+ 次查询。解决:改为一次性批量查询候选用户,内存中计算所有匹配度,查询次数从 O(N) 降到O(1),性能提升约 20 倍。
3. LangChain4j 会话记忆管理:LangChain4j 的 @MemoryId 会无限增长历史消息。解决:保留最近 10 条历史消息,超出部分截断,避免上下文窗口溢出和 Token 浪费。