赛博厨神队——CodeArts团队实战总结

赛博厨神队 2025-11-13 00:00:32
这个作业属于哪个课程2501_CS_SE_FZU
这个作业的要求在哪里软工实践——CodeArts团队实战总结
这个作业的目标设计实现基于大语言模型的购车意向咨询系统
其他参考文献无

目录

  • 1. 项目地址
  • 2. Commit记录
  • 2.1 用户端
  • 2.2 管理端
  • 2.3 服务端
  • 3. 程序运行环境
  • 3.1 用户端
  • 3.2 管理端
  • 3.3 服务端
  • 4. 功能需求建模分析
  • 4.1 NABCD分析
  • 4.2 用例建模分析
  • 4.2.1 参与者（Actors）定义
  • 4.2.2 用例图（Use Case Diagram）
  • 4.2.3 核心用例详述
  • 用例1：发起购车咨询（C-01）
  • 用例2：查看咨询历史（C-05）
  • 用例3：汽车专家问答（E-01, E-02）
  • 用例4：管理员查看数据统计（A-04）
  • 4.3 类图建模分析
  • 4.3.1 完整类图设计
  • 4.3.2 核心类详细说明
  • User（用户类）
  • Consultation（咨询类）
  • ConsultationReport（咨询报告类）
  • 4.4 业务流程建模
  • 4.4.1 购车咨询业务流程
  • 4.4.2 积分系统业务流程
  • 4.5 数据模型设计
  • 4.5.1 主要数据实体关系
  • 4.5.2 关键数据字段设计
  • 4.6 系统架构设计
  • 5. 功能实现思路
  • 5.1 用户模块
  • 5.1.1 登录与注册
  • 5.1.2 用户基本信息
  • 5.1.3 用户如何快速了解系统功能并开始咨询？
  • 5.1.4 如何保护用户隐私和数据安全？
  • 5.2 购车咨询模块
  • 5.2.1 咨询信息设计
  • 5.2.2 LLM生成咨询
  • 5.2.3 咨询结果设计
  • 5.3 汽车相关专业知识解答
  • 5.4 咨询积分系统（附加功能1）
  • 5.4.1 积分获取
  • 5.4.2 积分兑换
  • 5.4.3 积分记录
  • 5.5 管理员模块（附加功能2）
  • 5.5.1 查看与管理所有咨询记录
  • 5.5.2 用户行为统计与热门咨询话题分析
  • 5.5.3 管理用户账号
  • 6. 程序截图说明
  • 6.1 用户端
  • 6.1.1 登录
  • 6.1.2 注册
  • 6.1.3 主要功能界面
  • 6.2 管理端
  • 6.2.1 登录
  • 6.2.2 数据统计看板
  • 6.2.3 用户管理
  • 6.2.4 咨询记录查看
  • 7. 工作流程
  • 7.1 简化开发流程
  • 7.1.1 快速启动阶段（4小时）
  • 7.1.2 并行开发阶段（32小时）
  • 7.1.3 部署测试阶段（4小时）
  • 7.2 极简协作流程
  • 7.2.1 代码管理
  • 7.2.2 沟通机制
  • 7.2.3 任务优先级
  • 8. 组员分工与贡献度
  • 9. 困难与解决
  • 9.1 郭晶晶
  • 9.1.1 遇到的困难
  • 9.1.2 解决方案
  • 9.2 陈茜蕾
  • 9.2.1 遇到的困难
  • 9.2.2 解决方案
  • 9.3 黄子妍
  • 9.3.1 遇到的困难
  • 9.3.2 解决方案
  • 9.4 季致涵
  • 9.4.1 遇到的困难
  • 9.4.2 解决方案
  • 9.5 侯晴宇
  • 9.5.1 遇到的困难
  • 9.5.2 解决方案
  • 9.6 季煜晟
  • 9.6.1 遇到的困难
  • 9.6.2 解决方案
  • 9.7 林琬茗
  • 9.7.1 遇到的困难
  • 9.7.2 解决方案
  • 9.8 王成桢
  • 9.8.1 遇到的困难
  • 9.8.2 解决方案
  • 9.9 肖窈
  • 9.9.1 遇到的困难
  • 9.9.2 解决方案
  • 9.10 许云湘
  • 9.10.1 遇到的困难
  • 9.10.2 解决方案
  • 10. PSP表格
  • 10.1 郭晶晶
  • 10.2 陈茜蕾
  • 10.3 黄子妍
  • 10.4 季致涵
  • 10.5 侯晴宇
  • 10.6 季煜晟
  • 10.7 林琬茗
  • 10.8 王成桢
  • 10.9 肖窈
  • 10.10 许云湘

1. 项目地址

服务端署地址
用户端署地址
用户端 CodeArts
管理端 CodeArts
服务端 CodeArts

2. Commit记录

2.1 用户端

总计23次提交

人员次数
王成桢9
林婉茗4
许云湘4
肖窈6

2.2 管理端

img

总计31次提交

人员次数
郭晶晶12
陈茜蕾12
黄子妍7

2.3 服务端

img

总计62次提交

人员次数
季致涵42
季煜晟6
侯晴宇14

3. 程序运行环境

3.1 用户端

3.2 管理端

操作系统：Windows11
浏览器：Chrome

3.3 服务端

服务器后端：macOS 15.6
服务器前端：Ubuntu 22.04

4. 功能需求建模分析

4.1 NABCD分析

维度内容
N（需求）消费者在购车过程中面临信息不对称、选择困难、专业知识匮乏等问题，需要一个专业、可信、个性化的购车咨询平台。
A（做法）构建一个基于大语言模型的购车意向咨询系统，通过结构化表单收集用户需求，调用多个 LLM 生成个性化购车报告，并提供积分激励与管理员后台。
B（好处）- 用户：节省研究时间，获得客观、全面的购车建议- 系统：智能化、可扩展、支持高并发- 平台：积累用户行为数据，优化推荐策略
C（竞争）与传统汽车媒体（汽车之家、懂车帝）相比，本系统更注重个性化咨询与智能交互，而非信息堆砌；与普通问答机器人相比，本系统更结构化、专业化。
D（推广）- 通过汽车论坛、社交媒体、KOL 合作推广- 与汽车品牌合作，提供试驾或优惠券作为积分奖励- 提供"邀请好友得积分"机制

4.2 用例建模分析

4.2.1 参与者（Actors）定义

参与者描述特征
普通用户有购车意向的消费者注册、登录、使用咨询功能、管理个人信息
管理员系统后台管理人员用户管理、数据统计、咨询记录管理
LLM服务外部大语言模型API提供智能分析和专业汽车知识问答服务
积分系统积分模块自动积分计算和兑换处理

4.2.2 用例图（Use Case Diagram）

img

4.2.3 核心用例详述

用例1：发起购车咨询（C-01）

  • 参与者：用户
  • 前置条件：用户已登录
  • 主流程：
    1. 用户进入咨询页面
    2. 填写咨询表单（预算、车型、场景、燃料类型等）
    3. 提交表单
    4. 系统调用LLM生成咨询报告
    5. 系统保存咨询记录并展示报告
  • 后置条件：咨询记录保存，用户获得积分

用例2：查看咨询历史（C-05）

  • 参与者：用户
  • 前置条件：用户已登录
  • 主流程：
    1. 用户进入个人中心
    2. 点击"咨询历史"
    3. 系统展示历史记录列表
    4. 用户点击某条记录查看详情
  • 后置条件：无

用例3：汽车专家问答（E-01, E-02）

  • 参与者：用户
  • 前置条件：用户已登录
  • 主流程：
    1. 用户输入问题
    2. 系统调用LLM生成回答
    3. 系统展示回答
  • 后置条件：无记录保存

用例4：管理员查看数据统计（A-04）

  • 参与者：管理员
  • 前置条件：管理员已登录
  • 主流程：
    1. 管理员进入数据看板
    2. 系统展示用户增长、热门车型、预算分布等图表
  • 后置条件：无

4.3 类图建模分析

4.3.1 完整类图设计

img

4.3.2 核心类详细说明

User（用户类）

职责：管理用户基本信息、认证和偏好设置

关键属性：

  • userId: 用户唯一标识
  • phone: 登录账号（手机号）
  • passwordHash: 加密存储的密码
  • preference: 关联的用户购车偏好

主要方法：

  • register(phone, password): 用户注册
  • login(credential, password): 用户登录
  • updateProfile(preferenceData): 更新用户偏好

Consultation（咨询类）

职责：管理购车咨询的全生命周期

关键属性：

  • consultationId: 咨询记录唯一标识
  • formData: 用户填写的咨询表单数据
  • llmResponse: LLM生成的原始响应
  • processingTime: LLM处理耗时

主要方法：

  • saveConsultation(): 保存咨询记录
  • getConsultationHistory(userId): 获取用户咨询历史

ConsultationReport（咨询报告类）

职责：结构化展示LLM生成的咨询结果

关键属性：

  • recommendations: 推荐车型列表
  • visualizations: 可视化数据（雷达图、预算分解等）
  • budgetAnalysis: 预算规划分析

主要方法：

  • generateVisualization(): 生成可视化图表

4.4 业务流程建模

4.4.1 购车咨询业务流程

img

4.4.2 积分系统业务流程

img

4.5 数据模型设计

4.5.1 主要数据实体关系

用户(User) 1:1 积分账户(PointSystem)
积分账户(PointSystem) 1:N 积分记录(PointRecord)
用户(User) 1:N 会话(Session)
会话(Session) 1:N LLM 输出(LlmOutput)
用户(User) 1:N 兑换记录(RedemptionRecord)
统计表独立存在：品牌统计(BrandCount)、关键词统计(KeywordCount)、用量统计(UseCount)、预算统计(BudgetCount)

4.5.2 关键数据字段设计

User表关键字段：

  • userid: BIGSERIAL 主键
  • username: VARCHAR(50) 唯一用户名
  • password: VARCHAR(100)
  • phone: VARCHAR(20)
  • preferences: JSONB（偏好信息，如预算、用途、车类型、燃油类型、品牌等）
  • created_at / updated_at: TIMESTAMP

Session表关键字段：

  • sessionid: BIGSERIAL 主键
  • userid: BIGINT，关联用户
  • prompt: TEXT（LLM 输入）
  • answer: TEXT（LLM 输出）
  • llm_provider: VARCHAR(50)
  • rating: INT (1-5)
  • feedback: TEXT
  • created_at / updated_at: TIMESTAMP

4.6 系统架构设计

层级技术选型
前端管理端：Vue 3 + JavaScript + ElementUI + ECharts 用户端：React 18 + TypeScript + Ant Design + SSE
后端Spring Boot + JPA + Redis + SSE
数据库PostgreSQL
缓存/消息Redis（流式输出、缓存）
LLM接口DeepSeek / 阿里百炼

5. 功能实现思路

5.1 用户模块

5.1.1 登录与注册

手机号验证注册：用户通过手机号、用户名、密码完成注册，支持短信验证码验证
多种登录方式：支持手机号/用户名+密码登录，实现会话保持功能
密码安全策略：使用bcrypt算法加盐存储密码，确保数据安全

5.1.2 用户基本信息

个人资料管理：用户可查看和编辑用户名、手机号等基本信息
购车偏好设置：支持设置购车预算、偏好车型、使用场景、燃料类型、品牌偏好等
偏好数据存储：使用PostgreSQL的JSONB字段存储复杂的偏好设置数据

5.1.3 用户如何快速了解系统功能并开始咨询？

引导式界面设计：主界面清晰分为"开始新的购车咨询"和"查看历史咨询"两大功能区
新手引导流程：首次登录提供可跳过的浮层导览，介绍核心功能和使用方法
直观操作流程：简化咨询流程，用户只需填写结构化表单即可获得专业建议

5.1.4 如何保护用户隐私和数据安全？

数据传输加密：全程使用HTTPS协议确保数据传输安全
敏感信息脱敏：在管理员后台对用户手机号等敏感信息进行部分脱敏显示
隐私政策明确：清晰告知用户数据使用范围，未经同意不向第三方共享数据
API密钥安全管理：LLM API密钥通过后端环境变量管理，不暴露在前端

5.2 购车咨询模块

5.2.1 咨询信息设计

1.如何保证咨询结果的准确性和实用性？
高质量Prompt工程：在Prompt中限定LLM角色为"资深汽车评测顾问"
结构化数据输入：要求LLM基于最新真实市场数据和车型信息进行推荐
多模型验证机制：支持调用至少两种LLM API，对比选取更合理的结果
用户反馈优化：设置五星评分和反馈框，收集用户意见用于持续优化

5.2.2 LLM生成咨询

智能Prompt构建：将用户输入的结构化数据组合成高质量Prompt
多API支持：支持DeepSeek与阿里百炼大模型服务调用
流式响应处理：使用Redis与SSE实现实时流式输出，提升用户体验
性能优化：设置响应超时机制，确保咨询请求响应时间<30秒

5.2.3 咨询结果设计

1.咨询结果如何清晰、直观地展示给用户？
结构化报告模板：设计非纯文本的结构化展示界面
可视化数据呈现：使用图表、表格等可视化元素增强信息可读性
交互式界面：支持折叠面板、标签页等交互方式，方便用户查看详细信息

2.基于用户需求和偏好的车型推荐
多维度匹配算法：根据预算、场景、燃料类型等多维度进行车型匹配
个性化推荐：结合用户历史偏好和行为数据进行个性化推荐
推荐理由明确：为每个推荐车型提供清晰的推荐理由和适用场景分析

3.不同车型的对比分析
参数对比表格：将推荐车型的关键参数制成对比表格，一目了然
优劣分析详细：提供每个车型的优缺点分析和适用场景评估
可视化雷达图：使用雷达图展示各车型在不同维度的表现差异

4.购车预算规划建议
落地价详细分解：提供包含购置税、保险、上牌费等完整预算分解
多方案对比：针对不同车型提供多个预算方案供用户选择
财务建议明确：给出具体的财务规划和预算调整建议

5.3 汽车相关专业知识解答

即时问答功能：用户可随时询问汽车专业知识问题
LLM智能回答：调用LLM服务提供专业、准确的汽车知识解答
轻量级设计：该模块不保存对话记录
匿名使用支持：支持用户匿名使用，降低使用门槛

5.4 咨询积分系统（附加功能1）

5.4.1 积分获取

多行为积分奖励：完成咨询+100积分，提供有效反馈+200积分，每日登录+100积分
积分自动计算：系统自动记录用户行为并计算相应积分
实时积分更新：用户完成相关行为后积分实时更新

5.4.2 积分兑换

多层级礼品设置：设置低、中、高、尊享四个积分区间的兑换物品
多样化礼品选择：包括汽车周边、养护用品、电子设备、深度体验等
积分充足性检查：兑换时自动检查用户积分是否充足

5.4.3 积分记录

完整积分流水：记录所有积分获取和消耗的详细流水
兑换历史管理：保存用户所有的礼品兑换记录

5.5 管理员模块（附加功能2）

5.5.1 查看与管理所有咨询记录

全平台数据访问：管理员可查看平台所有用户的咨询记录
搜索功能：支持按用户/id/车型搜索咨询记录
查看用户反馈信息：支持查看每次咨询用户反馈信息
内容管理权限：依据咨询反馈结果对prompt进行优化修改

5.5.2 用户行为统计与热门咨询话题分析

多维度数据统计：统计用户增长趋势、热门车型/品牌排行榜等
数据可视化展示：使用图表、词云等方式直观展示统计数据
实时数据更新：数据看板支持实时或近实时数据更新

5.5.3 管理用户账号

用户信息管理：支持查看所有用户列表，进行搜索和CRUD操作
权限管理：管理用户权限和账号状态

6. 程序截图说明

6.1 用户端

6.1.1 登录

  • 展示用户登录界面，包含手机号/用户名、密码输入框

img

6.1.2 注册

  • 展示用户注册表单，包含必填字段验证

img

6.1.3 主要功能界面

  • 咨询表单页面：展示结构化的咨询表单，包含预算选择、场景多选等

img

  • 咨询结果页面：展示结构化的咨询报告，包含推荐车型、对比表格、预算分解等

img

  • 咨询历史查询：专用于查看历史咨询记录的界面

img

  • 咨询打分页面：可根据咨询结果打分并获得积分

img

  • 汽车专家页面：展示针对用户提问的汽车问题科普性质回答

img

6.2 管理端

6.2.1 登录

img


-- 管理员登录界面

6.2.2 数据统计看板

img

  • 展示用户增长趋势图表
  • 展示用户预算分布图和热门咨询话题词云

6.2.3 用户管理

img

  • 展示用户列表界面，支持搜索和筛选

img

  • 显示用户详细信息查看和编辑界面
  • 展示用户行为统计数据

6.2.4 咨询记录查看

img

  • 展示全平台咨询记录列表

img

  • 显示单个咨询记录的详细信息查看界面
  • 展示咨询记录的管理操作界面

7. 工作流程

7.1 简化开发流程

7.1.1 快速启动阶段（4小时）

环境快速搭建
统一开发环境配置
建立基础项目框架
配置必要依赖和工具

任务紧急分配
按功能模块拆分任务，进行项目需求分析
明确各成员职责范围
设定明确完成时间节点

7.1.2 并行开发阶段（32小时）

前端开发组负责用户端的中高优先级任务，同时统一UI组件库和样式规范；后端开发组专注于API接口开发、数据库设计与实现以及LLM接口集成测试工作；前后端部分人员同步进行实时接口联调、基础功能验证和问题快速反馈，确保各模块协同推进。

7.1.3 部署测试阶段（4小时）

快速部署
基础环境配置
应用部署和启动
基础功能验证

重点测试
核心业务流程测试
关键功能验证
紧急问题修复

7.2 极简协作流程

7.2.1 代码管理

CodeArts主分支：master（直接提交）

7.2.2 沟通机制

即时通讯群：实时问题沟通
紧急问题：立即电话沟通

7.2.3 任务优先级

1. P0（必须完成）
用户模块：用户注册、登录、管理基本信息
咨询模块：发起咨询，LLM智能分析，咨询结果反馈，保存咨询记录，查看咨询历史，咨询报告展示
汽车专家模块：询问问题，LLM回答

2. P1（尽量完成）
咨询积分系统：积分获取、积分商城、兑换记录
管理员模块：管理员登录，用户管理，咨询记录查看，数据统计看板

3. P2（可选完成）
用户忘记密码，管理员内容管理，压力测试与性能

8. 组员分工与贡献度

学号工作内容贡献度
222200334 季致涵需求分析，数据流分析，后端框架搭建，llm相关核心业务模块撰写，SSE流式（chunk形式）输出到前端的设计与实现，数据库配置，数据结构，触发器与储存过程设计与实现，redis配置，服务器部署维护，后端其他业务辅助撰写，接口等调试，帮助部分前端成员排查问题，业务拆分与对应任务分工，接口联调。11.56%
102300302 侯晴宇需求分析，用户、管理员模块后端代码编写，对应接口调试10.73%
102300315 季煜晟积分与兑换商城的后端代码编写，对应的接口调试10.37%
102300204 黄子妍用户管理页面，实现了用户信息的列表展示，编辑用户信息功能，删除用户信息功能，分页显示功能，搜索用户功能，API对接10.13%
102300105 郭晶晶需求分析与设计，需求文档编写，管理端框架搭建，管理端登录功能，管理端数据统计面板功能，博客攥写11.92%
102300108 陈茜蕾咨询记录管理页面实现了咨询记录的列表展示支持按用户/ID/车型搜索过滤分页显示功能查看详情弹窗删除记录功能提示词编辑功能管理员可编辑LLM提示词支持保存到服务器和本地存储恢复默认提示词功能友好的错误处理和用户提示，API对接，咨询记录，提示词管理10.73%
102300304 林琬茗积分商城和汽车专家页面实现所有接口调用8.35%
222200402 王成桢购车咨询页面的前端开发，尝试实现购车咨询报告的实时流式输出。9.54%
102300102 肖窈登录、个人信息页面 及其相关接口调用8.35%
102300101 许云湘部分登陆界面以及侧边栏8.35%

9. 困难与解决

9.1 郭晶晶

9.1.1 遇到的困难

  1. 项目初始化已导入所有包，但是 echarts 使用时仍报错
  2. 窗口缩放时图表变形，宽高比例失调，数据可视化效果大打折扣
  3. 热门咨询品牌与热门咨询话题接好接口后，无法正确显示数据

9.1.2 解决方案

  1. 部分图表最新版的 echarts 不支持，需重新导入旧版本与特定包
  2. 利用 ECharts 的 resize 方法配合防抖优化，并为图表容器设置合适的 aspect-ratio 比例
  3. 要先调用获取全量统计的接口

9.2 陈茜蕾

9.2.1 遇到的困难

  1. 接口连接经常失败
  2. 连接接口的时候受到 ssh 协议干扰
  3. 一开始对接后端数据没法传到前端
  4. 和成员沟通协作需要改进，导致有时候对需求不明确

9.2.2 解决方案

  1. 询问后端成员解决方案，同时自己去找解决方案，求助 AI 等等
  2. 让 AI 技术员解决，排除干扰
  3. 按 F12 键查看报错信息，询问 AI 解决方案

9.3 黄子妍

9.3.1 遇到的困难

  1. 接口测试多次失败
  2. 连接删除接口时，用户列表接口的认证检查出现错误
  3. CORS（跨域资源共享）错误
  4. 403 Forbidden 错误

9.3.2 解决方案

  1. 向后端成员求助
  2. 自己寻找解决办法的同时向成员求助，询问 AI 技术员帮助
  3. 修改 api 配置
  4. 修改 userApi.js 中的路径配置

9.4 季致涵

9.4.1 遇到的困难

  1. 采用 bash 调用导致的系统线程池有限
  2. redis 监听返回 llm 的回复格式错误
  3. 部分关联表特定操作的操作数过多，在高并发情况下存在脏读写
  4. 统计部分从中文 string 中提取关键词算法复杂
  5. 服务器 SSE 提供有问题

9.4.2 解决方案

  1. 使用 JDK21 特性虚拟线程
  2. 采用数据库过渡表，在存入正式表前使用格式转换算法
  3. 使用储存过程保证事务原子性
  4. 使用 hankcs 依赖库辅助分析
  5. 时间有限排查失败，将开发用电脑暴露端口作服务器

9.5 侯晴宇

9.5.1 遇到的困难

  1. 触发器出问题导致数据库无法完全建立
  2. 本机 Windows 环境与服务器 Linux 不同，导致编码出错
  3. 表之间关联较多，无法完全删除

9.5.2 解决方案

  1. 修改触发器，移除对不需要表的依赖
  2. 转换环境
  3. 将每个表相对应的连着删除（虽然后面因为数据存储的关系又不用了）

9.6 季煜晟

9.6.1 遇到的困难

  1. schema.sql 中的表创建语句与现有表冲突
  2. @Procedure 注解期望返回结果集，但存储过程没有返回
  3. Bean 无法解析，构造函数参数不匹配

9.6.2 解决方案

  1. 只保留存储过程代码，移除表创建语句
  2. 改用 @Modifying + @Query 原生 SQL 调用
  3. 修复构造函数参数名，移除重复的 Repository 定义

9.7 林琬茗

9.7.1 遇到的困难

不会用接口

9.7.2 解决方案

向后端成员寻求帮助

9.8 王成桢

9.8.1 遇到的困难

  1. SSE 流式输出接口返回 403 Forbidden 错误
  2. 后端重启服务器后需重新登录导致的 token 变动，返回 403 错误
  3. 从测试环境切换到正式环境后，URL 地址变更，且正式环境的 SSL 证书为自签名，同时后端未正确配置 CORS 策略，导致浏览器阻止请求

9.8.2 解决方案

  1. 放弃 EventSource，改用 fetch + ReadableStream 实现流式接收，并确保在请求头中携带 AuthorizationToken
  2. 暂时手动修改，每次重启后手动调整 token 数值
  3. 在 vite.config.ts 中配置代理，将 /api 请求代理到正式环境的 URL 中，并在代理配置中设置 secure：false 以忽略 SSL 证书验证，从而彻底解决 CORS 问题

9.9 肖窈

9.9.1 遇到的困难

  1. 有个接口一直响应为空
  2. 界面代码偏长

9.9.2 解决方案

  1. 及时和后端成员沟通
  2. 划分页面

9.10 许云湘

9.10.1 遇到的困难

  1. 因为权限问题无法使用接口
  2. 对接困难，实现复杂

9.10.2 解决方案

  1. 向后端成员寻求帮助
  2. 向 AI 询问相关问题

10. PSP表格

10.1 郭晶晶

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划6080
• Estimate• 估计这个任务需要多少时间6080
Development开发850960
• Analysis• 需求分析 (包括学习新技术）120140
• Design Spec• 生成设计文档120130
• Design Review• 设计复审4030
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)3030
• Design• 具体设计90110
• Coding• 具体编码300360
• Code Review• 代码复审3040
• Test• 测试（自我测试，修改代码，提交修改）120120
Reporting报告8575
• Test Report• 测试报告4030
• Size Measurement• 计算工作量1515
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划3030
合计9951115

10.2 陈茜蕾

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划6065
• Estimate• 估计这个任务需要多少时间6065
Development开发9951115
• Analysis• 需求分析 (包括学习新技术）120150
• Design Spec• 生成设计文档110115
• Design Review• 设计复审3030
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)4040
• Design• 具体设计90100
• Coding• 具体编码320360
• Code Review• 代码复审3040
• Test• 测试（自我测试，修改代码，提交修改）100110
Reporting报告8080
• Test Report• 测试报告3035
• Size Measurement• 计算工作量1515
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划3040
合计10551180

10.3 黄子妍

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划6080
• Estimate• 估计这个任务需要多少时间6080
Development开发9001000
• Analysis• 需求分析 (包括学习新技术）120140
• Design Spec• 生成设计文档120130
• Design Review• 设计复审4030
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)3030
• Design• 具体设计90110
• Coding• 具体编码330380
• Code Review• 代码复审5060
• Test• 测试（自我测试，修改代码，提交修改）120120
Reporting报告8575
• Test Report• 测试报告4030
• Size Measurement• 计算工作量1515
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划3030
合计10451155

10.4 季致涵

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划6075
• Estimate• 估计这个任务需要多少时间6075
Development开发8251120
• Analysis• 需求分析 (包括学习新技术）120150
• Design Spec• 生成设计文档4545
• Design Review• 设计复审3030
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)1010
• Design• 具体设计120180
• Coding• 具体编码420600
• Code Review• 代码复审2030
• Test• 测试（自我测试，修改代码，提交修改）6075
Reporting报告5555
• Test Report• 测试报告1515
• Size Measurement• 计算工作量1010
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划3030
合计9401250

10.5 侯晴宇

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划
• Estimate• 估计这个任务需要多少时间1020
Development开发
• Analysis• 需求分析 (包括学习新技术）4060
• Design Spec• 生成设计文档2010
• Design Review• 设计复审1010
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)1010
• Design• 具体设计4060
• Coding• 具体编码360420
• Code Review• 代码复审100100
• Test• 测试（自我测试，修改代码，提交修改）240300
Reporting报告
• Test Report• 测试报告3030
• Size Measurement• 计算工作量3015
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划1015
合计9001050

10.6 季煜晟

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划
• Estimate• 估计这个任务需要多少时间2010
Development开发
• Analysis• 需求分析 (包括学习新技术）100120
• Design Spec• 生成设计文档1030
• Design Review• 设计复审1010
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)2020
• Design• 具体设计2020
• Coding• 具体编码300340
• Code Review• 代码复审100100
• Test• 测试（自我测试，修改代码，提交修改）400460
Reporting报告1025
• Test Report• 测试报告2010
• Size Measurement• 计算工作量1020
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划1010
合计9701095

10.7 林琬茗

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划6045
• Estimate• 估计这个任务需要多少时间6045
Development开发385470
• Analysis• 需求分析 (包括学习新技术）120150
• Design Spec• 生成设计文档3025
• Design Review• 设计复审2015
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)1510
• Design• 具体设计4060
• Coding• 具体编码120180
• Code Review• 代码复审2015
• Test• 测试（自我测试，修改代码，提交修改）2015
Reporting报告3525
• Test Report• 测试报告1510
• Size Measurement• 计算工作量105
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划1010
合计480540

10.8 王成桢

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划3060
• Estimate• 估计这个任务需要多少时间3060
Development开发375570
• Analysis• 需求分析 (包括学习新技术）6060
• Design Spec• 生成设计文档3020
• Design Review• 设计复审1530
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)1530
• Design• 具体设计4570
• Coding• 具体编码120300
• Code Review• 代码复审3060
• Test• 测试（自我测试，修改代码，提交修改）60240
Reporting报告7580
• Test Report• 测试报告3060
• Size Measurement• 计算工作量1510
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划3010
合计525710

10.9 肖窈

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划6070
• Estimate• 估计这个任务需要多少时间6070
Development开发560590
• Analysis• 需求分析 (包括学习新技术）4060
• Design Spec• 生成设计文档1010
• Design Review• 设计复审1010
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)2020
• Design• 具体设计2020
• Coding• 具体编码300340
• Code Review• 代码复审10080
• Test• 测试（自我测试，修改代码，提交修改）6050
Reporting报告5040
• Test Report• 测试报告2010
• Size Measurement• 计算工作量2020
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划1010
合计670700

10.10 许云湘

PSPPersonal Software Process Stages预估耗时（分钟）实际耗时（分钟）
Planning计划6045
• Estimate• 估计这个任务需要多少时间6045
Development开发360540
• Analysis• 需求分析 (包括学习新技术）60180
• Design Spec• 生成设计文档3015
• Design Review• 设计复审2015
• Coding Standard• 代码规范 (为目前的开发制定合适的规范)1010
• Design• 具体设计4060
• Coding• 具体编码150180
• Code Review• 代码复审1020
• Test• 测试（自我测试，修改代码，提交修改）5060
Reporting报告4535
• Test Report• 测试报告2510
• Size Measurement• 计算工作量105
• Postmortem & Process Improvement Plan• 事后总结, 并提出过程改进计划1020
合计465620
...全文
178 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
YOLO26算法保龄球馆保龄球目标检测+训练好的模型+743张数据集+pyqt可视化界面.zip
数据集可视化效果可参见下方展示。 【数据集概况】 · 检测类别（中文）：[保龄球(bowling)] · 训练集：594 张 · 验证集：75 张 · 测试集：74 张 · 总计：743 张 该数据集聚焦于室内保龄球馆场景，系统性采集了多角度、多姿态下保龄球在不同运动阶段的视觉特征，为保龄球运动过程中的球体识别与轨迹分析提供了高质量标注样本，具有明确的体育训练与智能辅助系统开发价值。... 【训练曲线与评估图】 【模型训练配置】 参数 | 值 模型 | yolo26n 训练轮数 | 100 epochs 输入尺寸 | 640x640 批次大小 | 24 优化器 | auto 初始学习率 | 0.01 训练设备 【关键指标汇总】 训练了 100 个 epoch，最终轮指标： 指标 | 数值 mAP50 | **0.9938** mAP50-95 | 0.6966 Precision | 0.9740 Recall | 0.9974 train/box_loss | 0.9113 train/cls_loss | 0.2862 val/box_loss | 1.1516 val/cls_loss | 0.3116 【训练过程分析】 100 轮训练后 mAP50 达到 0.9938，模型收敛良好。Loss 曲线前段快速下降，后段趋于平稳，val_loss 无反弹，没有明显过拟合。但 mAP50-95 为 0.6966，和 mAP50 差距 0.30，定位精度仍有优化空间。 【模型性能评估】 Precision 0.9740、Recall 0.9974，精召双高，模型对保龄球的检测能力强。 【预测效果展示】 验证集预测效果较好，检测框基本准确覆盖保龄球，置信度整体偏高。 【改进建议】 1. 丰富场景多样性：补充不同光照、背景和遮挡条件下的样本。 2. 提升输入分辨率：640 ...
PaddleOCRApi面向 Windows 与 Linux 的轻量级 OCR 与YOLO目标检测 HTTP 服务
PaddleOCR 与YOLO目标检测 HTTP 服务。 项目通过 PaddleOCROnnx 原生库集成 OnnxRuntime加速能力，围绕 ONNX 模型部署， 以统一接口提供图像文字识别、YOLO 目标检测和 Tensor 数据输出。 功能概览 文字识别：支持图片 Base64、multipart/form-data 上传，以及文本和 JSON 结果。 目标检测：支持 YOLO 图片检测，返回检测框 JSON 或原始 Tensor。 浏览器演示：访问服务根地址，上传图片并切换 OCR、YOLO 模式。 健康检查：通过 /health 查看服务及 OCR、YOLO 引擎初始化状态。 并发处理：通过 OCR 引擎实例池处理并发请求，可调整实例数量。 体验与调用 启动后访问： 入口 地址 浏览器演示 http://localhost:5000/ 健康检查 http://localhost:5000/health 原生依赖 Windows：优先从 runtimes/win-x64/native/ 加载原生 DLL；该目录没有 PaddleOCROnnx.dll 时，尝试从可执行文件所在目录加载。主 DLL 与对应后端依赖应放在同一原生目录中，不要将同一组依赖分散到多个目录。 Linux：原生运行时位于 runtimes/linux-x64/native/，程序使用相对于可执行文件的运行时搜索路径查找随包部署的依赖。 后端选择：CoreOCROnnx 支持 ONNX Runtime、OpenVINO、TensorRT 后端。请使用与平台、进程架构、硬件和后端匹配的一整套运行时，不要混用不同后端或版本的依赖。
goose 是一款在您的设备上运行的通用型 AI 代理
一款开源、可扩展的AI代理，功能远超代码建议——支持安装、执行、编辑以及与任何大型语言模型（LLM）进行测试。
丧尸枪战_1.0
丧尸枪战1.0这是一款我自己做的游戏2d版本的这个游戏我以后会更新
2501_CS_SE_FZU

103

社区成员

407

社区内容

发帖
与我相关
我的任务
社区描述
2501_CS_SE_FZU
软件工程 高校
社区管理员
  • FZU_SE_LQF
  • 木村修
  • 心态773
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章