拾光友人帐——LLM结合探索CodeArts团队实战总结

目录

一、项目基础信息

1. CodeArts仓库信息

仓库在线地址：https://devcloud.cn-north-4.huaweicloud.com/codehub/project/1cc4d1420a3d44a88e53cc3c2084e46f/codehub/3112035/home?ref=master
项目源码分支：dev

使用 PM2 进程管理工具托管前后端服务，实现后台常驻运行，断开 SSH 连接后服务不会停止。本次部署全程没有修改项目源码，通过淘宝 npmmirror 镜像下载 Node24 二进制包解决 node:sqlite 版本依赖问题，顺利在阿里云 ECS 上完成 CNCC2026 会议网站的线上演示部署。服务为 Vite 开发模式，LLM 模块使用模拟数据，满足课程验收演示需求。

部署后云访问链接：http://47.114.54.180:5173/

2. 团队分工

本团队共6人（含队长），分工如下：

1. 刘伟鑫：项目整体统筹、需求评审、CodeArts仓库上传与冲突处理、Docker部署、博客文档整合、答辩准备；负责后端LLM智能推荐模块mock逻辑开发。
2. 刘传浩：前端首页、论坛列表、论坛详情页面开发，页面样式调试。
3. 李明学：前端日程页面、个人中心、通知公告页面开发，多语言国际化适配。
4. 王永臻：后端用户模块开发，登录、注册、身份鉴权、权限控制（普通参会者/论坛主席）。
5. 许毅君：后端业务接口开发，论坛报名、日程统计、数据查询脚本编写。
6. 许煜煌：墨刀原型设计、数据库设计文档、API文档编写、功能测试、bug收集与验证，协助整理PSP与贡献评估表。

3. Commit统计说明

本次代码统一提交至dev分支，一共95个文件变更

说明：代码全部可在dev分支查看。

4. 系统运行截图

首页截图（中文首页）

论坛推荐页面（演示模式）

主席管理面板

个人日程页面

会议总日程页

论坛列表页

论坛详情页

我的报名页面

通知公告页面

参会人员页面

论坛主席专属仪表盘

5. 开发困难与解决方案

1. 困难：LLM模块需要API Key才能调用，申请密钥、充值、接口不稳定会影响演示。
   解决：修改后端llm.js，增加判断逻辑，key为空时自动切换mock演示模式，返回预设推荐结果，保证演示不受第三方接口影响。
2. 困难：前后端联调跨域问题。
   解决：后端配置跨域中间件，开发环境放开跨域限制，保证前端正常请求后端接口。

二、思考与行动

1. 重新回答选题问题

选题：CNCC2026会议服务系统（带LLM智能论坛推荐）
我们最初选题目标：面向参会人员提供会议论坛浏览、报名、日程管理、主席管理能力，借助大模型根据用户兴趣自动推荐匹配论坛。
重新审视选题：我们认为这个选题具备实际价值，学术会议参会者信息繁杂，手动筛选论坛成本高；但真实大模型API存在成本、稳定性、密钥泄露风险，因此我们调整方案，保留完整推荐交互页面，底层采用mock方案保证演示可用，不降低系统展示效果，同时规避外部依赖风险。
项目核心目标不变：完成一套可部署、可演示的会议服务管理系统，满足参会者、论坛主席两类角色的使用需求。

2. 新思考与行动

新思考

1. 软件项目不一定要强依赖第三方在线服务，在课程作业场景下，mock降级方案是很合理的工程手段，优先保证系统整体可用、流程闭环，而不是强行接入不稳定的外部依赖。
2. 版本控制是团队协作的关键，分支保护策略是为了保护主分支，开发时应当养成新建开发分支的习惯，而不是一味使用强制推送覆盖代码。
3. 6人团队分工更需要明确边界，文档、测试、部署、开发任务同等重要，不能只关注写代码，文档、日志、截图也是重要交付物，否则容易出现任务遗漏。
4. 很多开发报错不是代码bug，而是版本工具、仓库配置、环境配置问题，这类问题耗时经常超过写代码本身。

后续行动

1. 后续迭代：如果条件允许，可增加配置页面，可视化切换mock模式/真实LLM接口模式；完善日志输出，方便定位推荐模块运行状态。
2. 团队规范：后续开发统一使用分支开发流程，dev分支作为开发分支，测试稳定后再合并到master，不再直接操作受保护主分支。
3. 测试完善：补充冒烟测试脚本，每次修改代码后自动验证核心接口可用性，减少人工测试工作量。
4. 文档持续维护：API文档、部署文档同步随代码更新，方便其他人拉取代码快速部署运行。

三、PSP表格

刘伟鑫 PSP表
| PSP阶段 | 预估时间(min) | 实际时间(min) | 备注 |
| ---- | ---- | ---- | ---- |
| 计划 | 40 | 35 | 需求确认、6人团队分工安排 |
| 需求分析 | 60 | 70 | 梳理功能、数据库、接口 |
| 设计 | 70 | 80 | 原型、表结构、前后端方案 |
| 编码 | 240 | 270 | 前端、后端业务代码开发 |
| 测试 | 80 | 90 | 功能测试、联调、bug修复 |
| 版本控制 & 部署 | 60 | 110 | CodeArts上传、排错、docker部署 |
| 博客&文档撰写 | 90 | 100 | 写AI Coding、PSP、贡献评估、博客整理 |
| 合计 | 640 | 755 | |

刘传浩 PSP表

李明学 PSP表

王永臻 PSP表

许毅君 PSP表

许煜煌 PSP表

四、团队贡献比例评估

五、AI辅助开发任务记录

任务1：编写LLM智能推荐模块，要求支持mock降级（代表性开发任务）

关键Prompt（给AI的原始提示）

AI输出摘要
AI生成了llm.js完整接口代码，包含环境变量读取、axios请求封装、成功回调、异常捕获，并且内置了mock分支逻辑。代码结构清晰，区分了真实调用路径和mock演示路径，返回的数据结构和前端页面预设字段保持一致。

迭代记录

1. 第一轮AI输出：mock返回内容比较简单，没有附带推荐理由，前端页面渲染会缺字段。
2. 二次引导Prompt：> mock返回结果里，每条推荐论坛需要增加reason字段，用来展示推荐理由，和真实LLM返回格式统一。
3. 第二轮输出：补齐reason字段，数据格式对齐；但是AI在代码里写死了把.env硬编码导入，存在密钥泄露风险。
4. 第三次调整引导：> 不要直接读取.env文件写死，使用环境变量，并且增加注释提醒不要提交密钥到代码仓库，同时在返回json中增加tag标记demo:true给前端识别。

采纳/修改/拒绝说明

• ✅ 采纳：整体分支判断逻辑、接口入参出参结构、异常捕获逻辑。
• ✏️ 修改：mock返回数据结构、增加demo标记、调整注释、移除直接读取.env的危险写法。
• ❌ 拒绝：AI提出的“直接在代码内置默认key用于演示”方案，理由：密钥硬编码会造成信息泄露，不符合版本仓库安全规范。

任务2：实现基于用户历史报名记录的协同过滤推荐补充逻辑（方案验证、错误排查，课程目标4）

关键Prompt

AI输出摘要
AI给出了三表关联SQL（用户-报名-论坛标签），写了协同过滤查询函数，同时写了合并两套推荐数组、加权打分、去重过滤的JS逻辑。整体思路是：先拿到用户已报名标签，查找同标签其他用户，再取出他们的报名论坛，最后和LLM推荐列表合并打分。

迭代记录

1. 第一轮AI输出：SQL没有做数量限制，当测试数据变多的时候，关联查询返回大量冗余数据，接口响应变慢；并且合并排序只简单拼接，没有加权分数计算。
2. 二次引导Prompt：> SQLite里面加limit控制候选集，不要全量关联；给每条推荐项增加score字段，LLM推荐基础分60，协同过滤基础分40，同一个论坛多次命中可以叠加分数，最后按score降序。
3. 第二轮输出：增加limit、基础分，但是存在一个bug：同一个用户多次报名同一个论坛会造成重复统计，分数虚高。
4. 第三次引导Prompt：> 关联的时候使用distinct去重用户id，避免同一个用户重复报名带来的重复计数；同时增加过滤：过滤掉用户本人已经报名的论坛。

检查验证、采纳判断依据

• 验证方式：构造多组测试数据，分别测试新用户（无报名记录，协同过滤无结果，只返回LLM/mock推荐）、老用户（有历史报名，混合推荐）、边界场景（所有同标签论坛均已报名）；打印接口返回score日志，核对打分逻辑。
• ✅ 采纳：协同过滤的关联思路、结果合并加权框架、去重过滤框架。
• ✏️ 修改：增加distinct去重、限制候选集大小、修复分数叠加逻辑、增加空数据兜底。
• ❌ 拒绝：AI建议的缓存表定时刷新方案，判断依据：课程项目数据量很小，引入定时任务、缓存表会增加系统复杂度，维护成本高，属于过度设计，现阶段不需要。

任务3：Docker一键部署脚本编写与优化

关键Prompt

AI输出摘要
生成Dockerfile、docker-compose.yml，配置前后端容器、端口映射、卷挂载，加入跨域配置。

迭代记录

1. 第一轮：AI默认使用npm，和本项目pnpm包管理器不匹配，构建失败。
2. 引导修改：> 项目使用pnpm，修改镜像构建步骤，使用pnpm install。
3. 第二轮：前端容器和后端容器启动顺序没有控制，后端还没启动前端就发起请求，出现跨域报错。
4. 增加要求：> 增加depends_on控制启动顺序，后端优先启动。

检查验证、采纳判断依据

• 验证方式：本地执行 docker compose up --build，观察容器启动日志，访问前端页面，测试接口请求。
• ✅ 采纳：容器编排整体结构、端口映射、跨域中间件配置。
• ✏️ 修改：包管理器替换为pnpm、增加启动依赖顺序、调整环境变量挂载。
• 判断依据：所有修改都经过本地部署验证，保证一键部署流程稳定，适配项目现有结构。

小结

使用AI时，不会直接采信全部输出，每一段代码、每一个技术方案都会经过人工检查、本地测试验证；遇到不安全、不符合项目约束的方案直接拒绝。通过分轮次、精细化的prompt引导，逐步修正AI输出的缺陷，让AI产出贴合我们项目的约束（不使用真实LLM密钥、轻量化协同过滤、使用pnpm管理）。

回到目录