七匹狼——团队展示

[七匹狼]

这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践团队作业——种子队选拔、团队展示及选题
这个作业的目标	完成团队组建与分工；使用NABCD模型论证学期项目选题；明确团队愿景和绩效考核方式；设计供老师、助教和其他小组使用的百分制评审表
其他参考文献	《构建之法》；你参加团队有什么样的投入；绩效管理

目录

• 一、团队介绍
• 1.1 队名
• 1.2 团队描述
• 1.3 队员风采
• 队员1：林明阳（队长）
• 队员2：罗悦翔
• 队员3：梁强
• 队员4：林佳鹏
• 队员5：林铭宏
• 队员6：林荣皓
• 队员7：林宇轩
• 二、项目选题：校园美食推荐及评论分析
• 2.1 拟作的团队项目选题描述：一句话
• 2.2 项目背景
• 2.3 系统核心功能
• 2.4 本期范围：做什么与暂不做什么
• 本期优先完成
• 暂不承诺的内容
• 2.5 选题材料
• 2.6 NABCD模型分析
• N——Need（需求）
• A——Approach（做法）
• B——Benefit（好处）
• C——Competitors（竞争）
• D——Delivery（交付）
• 2.7 技术选型与团队分工
• 技术选型
• 2.8 项目推进计划与里程碑
• 2.9 风险分析与应对策略
• 2.10 团队愿景
• 三、团队绩效考核方案
• 3.1 考核原则
• 3.2 个人绩效评分方式
• 3.3 四项评分说明
• 3.4 不同角色成员的个人评分重点
• 3.5 评分流程与申诉
• 考核流程
• 申诉机制

一、团队介绍

1.1 队名

我们的团队名称是 七匹狼。

“七匹狼”代表团队成员虽然能力方向不同，但可以围绕共同目标分工协作。软件工程不是一个人完成所有事情，而是需要产品、设计、开发、测试、文档和项目管理共同配合。我们希望在明确分工的基础上互相补位，把想法逐步变成可以验证的Web产品。

团队Slogan：七人同心，认真做饭；分工协作，把校园美食做成好用的推荐平台。

团队CSDN账号：七匹狼

1.2 团队描述

团队确定的项目主题是“校园美食推荐及评论分析”，平台形态为Web端。

团队讨论从多个候选题目开始，先后比较了校园拼车、旅行结伴、实验室设备预约、AI论文阅读助手和校园美食等方向。经过对用户痛点、实现难度、数据来源和课程周期的讨论，团队最终选择校园美食方向，并将评论分析、标签筛选、个性化推荐作为主要特色。

为避免一个人承担过多工作，团队保留五类角色，但采用“7人分配”方式：组长/PM 1人、原型/交互与数据分析 1人、前端 2人、后端 2人、测试/文档 1人。

1.3 队员风采

队员1：林明阳（队长）

项目	信息
学号	102400320
姓名/昵称	林明阳
CSDN地址	https://blog.csdn.net/2401_89058644?type=blog
性格	耐心
擅长的技术	Java、C++
兴趣爱好	游戏
希望的软工角色	后端、测试
Slogan	今日事，今日避

队员2：罗悦翔

项目	信息
学号	052404137
姓名/昵称	罗悦翔
CSDN地址	https://blog.csdn.net/2601_96813060?type=bbs
性格	开朗
擅长的技术	HTML、C++
兴趣爱好	篮球
希望的软工角色	前端、测试
Slogan	patience is key in life

队员3：梁强

项目	信息
学号	102400318
姓名/昵称	梁强
CSDN地址	https://blog.csdn.net/2401_88357340?type=bbs
性格	内敛、负责
擅长的技术	C++、Java
兴趣爱好	游戏、阅读
希望的软工角色	后端
Slogan	心怀荣耀，勇往直前

队员4：林佳鹏

项目	信息
学号	102400319
姓名/昵称	林佳鹏
CSDN地址	https://blog.csdn.net/2403_89205378?type=blog
性格	务实、追求效率
擅长的技术	C语言
兴趣爱好	游戏、小说
希望的软工角色	后端
Slogan	let's goooooooooo

队员5：林铭宏

项目	信息
学号	102400321
姓名/昵称	林铭宏
CSDN地址	https://blog.csdn.net/2403_87683844?type=bbs
性格	随和
擅长的技术	Vue
兴趣爱好	看日漫、玩二游
希望的软工角色	前端或测试
Slogan	可以睡觉了吗

队员6：林荣皓

项目	信息
学号	102400323
姓名/昵称	林荣皓
CSDN地址	https://blog.csdn.net/lin_12_03?type=blog
性格	做事沉稳细心，遇到bug不急躁，乐于和队友沟通讨论，有较强的责任心，遇到难题愿意主动钻研，团队协作意识强
擅长的技术	熟悉Python基础开发、MySQL数据库，了解前端HTML+CSS，能够完成简单接口编写与数据处理
兴趣爱好	阅读技术文档、刷算法题；喜欢研究开源项目，闲暇时会写小工具提升效率；也喜欢看科幻类作品
希望的软工角色	后端开发
Slogan	代码筑基石，耐心解万题

队员7：林宇轩

项目	信息
学号	102400324
姓名/昵称	林宇轩
CSDN地址	https://blog.csdn.net/2401_87607404?type=blog
性格	较内向
擅长的技术	python爬虫、web前端
兴趣爱好	弹琴、骑行
希望的软工角色	前端、测试
Slogan	加油

二、项目选题：校园美食推荐及评论分析

2.1 拟作的团队项目选题描述：一句话

【主题】校园美食推荐及评论分析是一款面向高校师生的Web平台，聚合校园食堂和周边餐饮信息，支持按口味、场景、价格等条件筛选美食，并通过评分、评论净化、评论总结和个性化推荐辅助用户快速做出用餐选择。

英文描述：A campus food recommendation and review analysis web platform that helps students find suitable food through structured tags, trustworthy reviews, and personalized recommendations.

2.2 项目背景

校园内食堂、窗口和周边商铺数量较多，但相关信息通常分散在同学群聊、朋友圈、外卖平台和个人口头推荐中。用户经常知道“想吃点什么”，却很难根据预算、口味、距离、时间和用餐场景快速找到合适的店铺。

现有分享内容还存在三个问题。第一，店铺信息可能不完整，菜单、价格、位置和营业时间需要用户自己反复确认；第二，评论区容易混入广告、重复灌水、与菜品无关的内容，用户需要阅读大量无效信息；第三，通用平台的推荐不一定适合校园场景，不能充分体现学生的预算、上课时间、宿舍距离和聚餐需求。

团队讨论认为，平台首期应先解决“找得到、看得懂、选得快”三个问题，再考虑更复杂的推荐算法。项目以Web端为主要形态，既方便电脑访问和展示，也方便后续适配手机浏览器。

2.3 系统核心功能

模块	计划功能	优先级
店铺信息	店铺名称、图片、位置、营业时间、菜品、价格区间和简介	P0
搜索与筛选	按关键词、口味、用餐场景、价格、距离和评分筛选	P0
店铺详情	查看店铺信息、菜品、评分、评论和推荐理由	P0
评分评论	用户发布文字/图片评论，进行评分、查看和管理	P0
评论处理	识别广告、无关、重复和明显无效评论；保留人工处理入口	P1
评论总结	根据有效评论概括店铺优点、短板和适合场景，并标明“系统总结”	P1
个性化推荐	根据用户口味、预算、浏览、收藏和评价行为进行轻量推荐	P1
标签体系	口味、场景、价格和特色标签组合筛选	P0
收藏管理	收藏常去店铺，按分类查看和取消收藏	P1
价格/优惠	展示团队确认来源的价格或优惠信息	P2

评论总结和推荐结果属于系统分析结果，不能替代真实用户评论，也不能把自动生成的内容伪装成用户原创评价。

2.4 本期范围：做什么与暂不做什么

本期优先完成

1. 完成Web端店铺浏览、搜索、筛选和详情查看；
2. 完成店铺评分、评论查看和基础评论管理；
3. 完成口味、场景、价格和特色等标签体系；
4. 完成评论有效性处理的演示流程，并保留人工复核入口；
5. 使用样例或经授权的数据展示评论总结和轻量推荐；
6. 完成需求分析、原型、测试记录、项目说明和展示材料。

暂不承诺的内容

• 未经授权抓取淘宝、京东、美团、大众点评等外部平台数据；
• 依赖外部平台实时价格、优惠券或完整评论数据；
• 仅靠AI自动判断评论真实性并直接删除；
• 复杂的商业化推荐、支付、配送和商家结算；
• 在没有真实用户数据的情况下宣称推荐效果已经经过大规模验证。

2.5 选题材料

• 选题PDF：
  

  校园美食推荐及评论分析-选题材料.pdf 126.48K

• 团队评审表：腾讯文档评审表

• 课程作业要求：软件工程实践团队作业——种子队选拔、团队展示及选题

• 团队CSDN账号：七匹狼

2.6 NABCD模型分析

N——Need（需求）

1. 学生和普通校园用户的信息查询需求

校园食堂、窗口和周边商铺较多，用户需要按照口味、预算、距离、营业时间和用餐场景快速筛选。例如，用户可能需要“20元以内的清淡午餐”“适合宿舍夜宵的店”“适合多人聚餐且分量足的餐馆”，但群聊和口头推荐很难提供结构化结果。

2. 真实有效评论参考需求

社群分享和平台评论中可能存在广告、重复灌水、与菜品无关的内容或过于简单的情绪表达。用户真正关心的是口味、分量、价格、服务、环境和性价比等信息，需要一种更快的方式总结有效评论。

3. 个性化推荐需求

统一的热门榜单不一定适合每个人。有人偏好麻辣，有人偏好清淡；有人关注价格，有人更关注距离和营业时间。用户希望平台能够结合自己主动选择的标签和使用行为，给出可解释的推荐理由，而不是只显示一个无法理解的排序。

4. 店铺信息维护需求

店铺的菜单、价格、位置和营业时间可能变化。管理员或信息维护者需要补充、修改和核对店铺信息，用户也需要看到数据更新时间，避免根据过期信息做决定。

综合来看，平台要解决的不是“再做一个店铺列表”，而是把校园美食信息、真实评论和用户选择条件组织起来，缩短从“想吃什么”到“决定去哪家”的路径。

A——Approach（做法）

本项目采用“店铺信息结构化—多维筛选—评论处理—结果总结—个性化推荐”的Web端流程。

1. 店铺信息结构化

为每家店铺建立统一信息结构，包括店铺名称、类别、位置、营业时间、菜品、价格区间、口味标签、场景标签、特色标签和数据更新时间。首期以课程演示所需的样例数据、团队实地整理数据或经授权的数据为主，不把未经授权的外部爬取作为系统运行前提。

2. 多维标签筛选

围绕校园场景建立标签体系：口味包括麻辣、清淡、酸甜等；场景包括早餐、午餐、晚餐、夜宵、聚餐和快餐等；价格包括平价和较高预算；特色包括分量足、减脂、网红等。用户可以组合条件筛选，并清楚看到当前筛选条件和没有结果时的下一步操作。

3. 评论管理和净化

评论先进入待处理状态。系统可以使用关键词规则、重复检测和文本分类辅助识别广告、无关、重复或明显无效内容，但不能把模型判断当成绝对正确。疑似问题评论应展示原因并提供人工复核、恢复或标记处理入口；正常评论保留原文和发布时间。

4. 评论总结和分析

针对通过筛选的有效评论，系统提取口味、价格、服务、环境、分量等信息，形成“优点、短板、适合人群和注意事项”的摘要。摘要页面必须标注“系统根据评论生成”，并提供查看原始评论的入口，避免用户把系统总结误解为商家或用户原话。

5. 轻量个性化推荐

首期优先使用标签匹配、评分、距离和用户主动选择的偏好进行可解释排序。推荐卡片显示“推荐理由”，例如“符合清淡口味、预算不超过20元、距离较近”。协同过滤或更复杂的算法属于后续扩展，不能在样例数据不足时宣称效果可靠。

6. Web端交付

Web端页面至少包括首页/美食浏览、筛选结果、店铺详情、评论分析、收藏或个人偏好、后台店铺与评论管理等页面。最终页面数量和原型以团队确认的选题材料为准。

候选主流程如下：

进入Web首页
    ├─ 选择口味/场景/价格/距离 → 筛选结果
    ├─ 点击店铺 → 店铺详情 → 查看原始评论和系统总结
    ├─ 发布评论 → 待处理/审核 → 通过后进入分析
    └─ 点击推荐 → 查看推荐理由 → 收藏或查看详情

管理端
    ├─ 维护店铺、菜单、价格和营业时间
    ├─ 查看待处理评论 → 人工确认或保留
    └─ 检查评论总结、推荐结果和数据更新时间

B——Benefit（好处）

对学生： 可以根据自己的口味、预算、用餐时间和距离筛选店铺，减少在群聊和多个平台之间反复询问的时间。

对有经验的校园用户： 可以通过评分、标签和评论总结快速了解店铺的优点和短板，并把常去店铺收藏起来。

对店铺信息维护者： 可以用统一字段管理店铺、菜单、价格和营业时间，减少信息散落和重复维护。

对课程助教： 可以清晰检查搜索筛选、评论分析、推荐理由、数据来源和异常处理，而不是只看一个静态展示页面。

对团队： 这个项目同时涵盖需求分析、前端交互、后端接口、数据处理、文本分析、测试和团队协作，能够体现软件工程实践中的完整过程。

项目收益主要是改善校园美食信息的组织和选择效率，不承诺替代大型生活服务平台，也不把推荐结果当成客观的食品质量认证。

C——Competitors（竞争）

替代方案	优点	局限	本项目的竞争方式
大众点评、美团等通用平台	商户数量多，评价和地图功能成熟	校园店铺可能不完整；内容和推荐不一定围绕学生预算、距离和课程时间	聚焦校园场景，使用更细的校园标签和推荐理由
校园群聊、朋友圈分享	信息传播快，熟人推荐有参考价值	内容分散、缺少结构化筛选，广告和重复内容较多	将分享内容按店铺、标签和评论统一整理
校园自建静态美食小程序	能展示校内店铺，入口较直接	可能只有店铺展示和简单评分，缺少评论处理、总结和推荐	增加评论分析、有效性处理和可解释推荐
个人表格或笔记	记录灵活，可保存个人经验	难以多人共享、自动分析和持续更新	通过Web页面统一维护，并展示更新时间和来源

本项目不与通用平台竞争商户数量，而是聚焦“校园场景 + 结构化标签 + 评论分析 + 轻量推荐”。差异化重点是让用户知道为什么推荐、评论依据是什么以及数据何时更新。

D——Delivery（交付）

课程阶段候选交付物包括：

1. 一份“校园美食推荐及评论分析”的选题PPT/PDF；
2. Web端页面原型和页面跳转说明；
3. 可运行的Web端项目，至少能够演示店铺查询、标签筛选、详情查看、评论展示和分析结果；
4. 店铺、评论、标签和用户偏好的数据字典；
5. 测试用例、缺陷记录、项目说明和演示材料；
6. 团队代码仓库、团队博客和百分制项目评审表。

数据交付优先使用自建样例、团队整理或获得授权的数据。若外部平台拒绝抓取、接口受限或数据授权不清晰，系统应切换为本地样例数据或人工录入，并在页面和文档中说明数据限制。评论总结和推荐功能需要能够展示处理依据，不能只展示一个无法解释的分数。

2.7 技术选型与团队分工

技术选型

层次	候选技术	说明
前端	HTML、CSS、JavaScript或团队确认的前端框架	实现Web页面、搜索筛选、店铺详情和评论交互
图表/分析	ECharts或其他前端图表库	展示评分分布、标签分布和评论统计
后端	Flask/Express/Spring Boot等，待团队确认	提供店铺、评论、标签和推荐接口
数据存储	SQLite/MySQL等，待团队确认	保存店铺、菜品、评论、标签和用户偏好
文本处理	关键词规则、重复检测、文本分类或团队确认的模型	辅助评论筛选和摘要，不替代人工复核
数据来源	自建样例、团队整理、用户提交或经授权接口	不使用未经授权的外部平台批量抓取

2.8 项目推进计划与里程碑

以下计划是候选版本，具体周次和日期待团队确认。

阶段	计划内容	阶段交付物	验收方式
第1阶段：选题与需求	完成用户角色、痛点、范围和NABCD	需求稿、选题PPT初稿	全员讨论并记录修改意见
第2阶段：原型设计	完成Web端核心页面、筛选流程和异常状态	原型、页面说明	走通“筛选—详情—评论—推荐”流程
第3阶段：数据模型	设计店铺、菜品、标签、评论和用户偏好字段	数据字典、样例数据	能够导入并查询样例数据
第4阶段：核心开发	完成店铺浏览、搜索筛选、详情和评论功能	可运行Web版本	按功能清单逐项演示
第5阶段：分析与测试	完成评论处理、摘要、推荐和异常状态	测试用例、缺陷清单	核对正常和失败场景
第6阶段：汇报与提交	完善代码、博客、演示和评审表	最终博客、项目链接、展示材料	全员检查链接和内容

2.9 风险分析与应对策略

风险	可能影响	应对策略
外部平台不允许抓取或授权不清晰	无法稳定取得店铺和评论数据，可能产生合规风险	不进行未经授权的批量抓取；使用自建、人工整理或授权数据，并记录来源
价格和营业时间实时变化	页面展示过期信息	显示数据更新时间；首期不承诺实时同步，允许管理员手动更新
评论存在广告、重复和无关内容	总结和推荐受到干扰	规则/模型辅助筛选，保留原文和人工复核入口；异常处理结果可追溯
AI总结或推荐出现错误	用户误解店铺情况	标注“系统总结/推荐”；显示依据评论；允许查看原文，不把结果当作事实认证
用户评论包含个人信息	隐私泄露	限制采集字段，脱敏展示，禁止上传无关个人信息；明确数据用途和删除方式
样例数据过少	无法证明推荐算法有效	将首期定位为课程演示和可解释流程，不夸大准确率；使用测试数据验证边界情况
团队任务分配不均	进度延期或考核争议	任务写明负责人和验收标准；保留评审、提交和会议记录

2.10 团队愿景

我们希望把七匹狼建设成一支能把生活观察转化为软件产品的团队。校园美食推荐及评论分析不只是一个店铺列表，而是希望帮助同学更快找到适合自己的食物，也让零散的经验分享变成清晰、可参考的信息。我们会先完成Web端的店铺浏览、标签筛选、评论管理和基础分析，再根据数据质量逐步完善推荐与总结功能。通过这次实践，我们希望每位成员都能参与需求讨论、设计、开发、测试和复盘，留下可验证的过程记录，最终交付一个说明清楚、能够演示、敢于面对限制的校园美食产品。

三、团队绩效考核方案

说明：本节针对每一名队员分别评分，满分100分，不是给团队整体评一个总分，也不是将100分平均分给所有成员。评分对象是成员在校园美食推荐及评论分析项目中的实际投入和协作表现。

3.1 考核原则

1. 以实际交付为准。 不以聊天发言数量、代码行数或单次提交次数直接代表贡献；
2. 以任务验收为核心。 每项任务在开始前写清负责人、协作人、截止时间和完成标准；
3. 过程和结果并重。 既看功能是否完成，也看需求理解、测试、文档和问题复盘；
4. 同一标准、角色适配。 前端、后端、数据、测试和PM使用统一原则，但按照角色的实际交付物验收；
5. 及时反馈。 每个里程碑结束后进行一次小结，问题尽量在阶段内修复；
6. 允许说明客观原因。 如果需求变化、接口不可用或任务范围调整，应及时说明，不事后简单归责。

3.2 个人绩效评分方式

每个阶段结束时，对每一名队员单独评分，满分100分。项目结束后，取该成员各阶段成绩的平均分作为最终绩效，不把团队总分平均分配给成员。

考核维度	分值	评分标准
任务完成度	40分	是否完成自己认领的任务，是否按计划交付
工作质量	25分	功能、页面、数据、测试或文档是否符合要求
团队协作	20分	是否积极沟通、配合联调、帮助队友解决问题
参与度与纪律	15分	是否参加会议、同步进度、及时响应并遵守团队约定
个人总分	100分	每名成员分别计算

3.3 四项评分说明

1. 任务完成度（40分）：按时完成并通过验收，得该任务的完整分数；只完成一部分，按实际完成程度评分；因需求调整或技术问题延期，但提前说明的，不按无故拖延处理。
2. 工作质量（25分）：功能能够正常使用，页面或文档清晰，数据和接口正确，测试后没有明显问题，可获得较高分；反复返工或影响主流程的缺陷较多时相应扣分。
3. 团队协作（20分）：积极参加讨论，及时同步进度，配合接口联调和测试，愿意帮助队友解决问题。长期不回复或只完成自己的部分、不配合联调时扣分。
4. 参与度与纪律（15分）：按要求参加会议，按时回复消息，遵守分支、提交、AI使用和资料来源等团队约定。合理请假或提前说明情况，不按无故缺席处理。

不按代码行数、提交次数或聊天数量直接判断贡献；同一项成果不能重复算作多个成员的完整任务。

3.4 不同角色成员的个人评分重点

角色	主要交付物	验收重点
组长/PM	任务表、会议记录、里程碑和风险清单	任务是否明确、风险是否同步、交付前是否组织检查
原型/交互与数据分析	页面原型、流程图、异常状态、样例数据、标签规则、评论处理和摘要	用户能否走通筛选、详情、评论和推荐流程；数据来源是否明确，原文与系统总结是否分开，结果是否可解释
前端（2人）	成员1负责首页、搜索、筛选和店铺详情；成员2负责评论展示、推荐交互、样式联调和异常提示	页面可操作、数据状态清晰、筛选和详情信息正确，两人交付能够顺利联调
后端（2人）	成员1负责数据库、店铺和评论基础接口；成员2负责评论分析、推荐接口、接口测试和部署协助	字段明确、错误返回清晰、接口能被前端调用，分析结果能够解释
测试/文档	测试用例、缺陷记录、部署/使用说明	能复现问题，修复后能够完成回归验证，文档可供他人操作

角色可以一人多担，具体分工由团队讨论确认。共同完成的任务应提前说明每个人负责的部分。

3.5 评分流程与申诉

考核流程

1. 每个阶段开始前明确每位成员的任务和截止时间；
2. 阶段结束时由负责人给出个人初评分数；
3. 团队共同讨论并确认每位成员的分数；
4. 项目结束后取各阶段平均分，作为个人最终绩效。

申诉机制

成员若认为个人评分与实际贡献不符，可以在结果公布后48小时内提出复核，由组长和一名非相关任务成员重新讨论。个人复核结果不修改老师、助教或其他评审人的项目评审分。

不允许临时增加任务、重复计算同一项成果或只看代码行数影响评分。

总的来说，本方案以个人实际贡献和任务交付质量为核心，兼顾团队协作与过程参与，保证每名队员都能得到相对客观、公平的评价。