FullAccess ——团队展示

这个作业属于哪个课程	2601_FZU_SE
这个作业要求在哪里	软件工程实践团队作业——种子队选拔、团队展示及选题
这个作业的目标	完成团队组建与团队展示，确定学期项目选题；借助 NABCD 模型分析项目需求与竞争力；制定团队绩效考核方案，明确团队成员分工、合作方式与团队愿景。
其他参考文献	《构建之法——现代软件工程》

---

@

文章目录

---

一、团队介绍

1.1 团队名称：FullAccess

FullAccess 这个名字，最初来自我们使用 AI 工具时经常看到的“完全访问权限”。给 AI 开放权限，是希望它能多帮我们做些事；而做好一个项目，也需要我们彼此信任，愿意分享自己会的东西，遇到难题一起想办法。
这也是我们做 Myriad 的初衷：生活里的很多问题，其实有人发现，也有人能解决，只是中间缺少一个连接。我们希望把这些零散的信息汇聚起来，让反馈有回应，让愿意帮忙的人能参与进来。
从给 AI 开放权限，到给彼此更多信任，这就是 FullAccess 想表达的意思。

---

1.2 队员风采

成员一：纪国一

项目	信息
学号	102400218
姓名 / 昵称	纪国一
CSDN 地址	欢迎关注
性格	内敛，随意
擅长的技术	Java
兴趣爱好	游戏
希望承担的软工角色	后端
Slogan	明天会更好

---

成员二：陈海滨

项目	信息
学号	072403101
姓名 / 昵称	陈海滨
CSDN 地址	欢迎关注
性格	乐观，好奇，肯琢磨
擅长的技术	Golang、Spring、React
兴趣爱好	羽毛球
希望承担的软工角色	后端
Slogan	Think deeper, build better

---

成员三：林培兴

项目	信息
学号	102400322
姓名 / 昵称	林培兴
CSDN 地址	欢迎关注
性格	非确定性输出
擅长的技术	好像都不擅长
兴趣爱好	打篮球被虐、CRUD、写牢题
希望承担的软工角色	后端
Slogan	hello, hell world!

---

成员四：黄芳恒

项目	信息
学号	102400315
姓名 / 昵称	黄芳恒
CSDN 地址	欢迎关注
性格	乐观开朗
擅长的技术	无
兴趣爱好	打游戏、写题
希望承担的软工角色	后端
Slogan	只要会做题就有做不完的题

---

成员五：邱青鹏

项目	信息
学号	102400225
姓名 / 昵称	邱青鹏
CSDN 地址	欢迎关注
性格	想法飘忽不定，喜欢美女
擅长的技术	复制粘贴一把好手
兴趣爱好	喜欢被虐
希望承担的软工角色	后端
Slogan	不求代码优雅，只求成功编译

---

成员六：洪育豪

项目	信息
学号	102400115
姓名 / 昵称	洪育豪
CSDN 地址	欢迎关注
性格	乐观开朗、善于沟通、肯学习
擅长的技术	无
兴趣爱好	运动
希望承担的软工角色	后端
Slogan	行稳致远，笃行不怠

---

成员七：林颖旭

项目	信息
学号	052404138
姓名 / 昵称	林颖旭
CSDN 地址	欢迎关注
性格	乐观，随和
擅长的技术	无
兴趣爱好	羽毛球
希望承担的软工角色	前端
Slogan	行而不辍，终有所得

---

成员八：孙楠

项目	信息
学号	102400328
姓名 / 昵称	孙楠
CSDN 地址	欢迎关注
性格	乐于学习，遇到问题会主动查阅资料，重视团队协作
擅长的技术	Vue 3、TypeScript、JavaScript 前端开发，熟悉 Git、Pinia、Vite；正在学习 Java 后端与 Spring Boot
兴趣爱好	游戏、阅读、跑步
希望承担的软工角色	后端，前端
Slogan	独立思考，携手协作，一起把项目做好。

---

二、项目选题与 NABCD 分析

项目名称

Myriad ——智能事件汇聚与协作平台

选题描述

面向校园、社区、园区、物业等具有明确管理边界的区域场景，打造一个利用 AI 辅助事件解析、相似事件检索与聚合、优先级分析和处理建议生成，并结合区域自治与人工确认机制，实现事件统一上报、协同处理和全过程追踪的智能事件汇聚与协作平台。

选题 PDF

选题pdf

---

2.1 N（Need，需求）

在校园、社区、园区、物业等区域中，设施损坏、环境异常、安全隐患、失物招领等事件往往依赖电话、微信群、线下反馈等方式上报。随着参与人数和事件数量增加，这种方式容易出现信息分散、重复上报、事件描述不统一以及处理进度难以追踪等问题。

其中，一个现实问题是：同一个事件可能被多个用户重复上报。例如同一处路灯损坏、道路积水或公共设施故障，不同用户可能从不同角度分别提交信息。如果每条上报都被视为独立事件，会形成重复处理、重复派单，也会使管理人员难以判断事件的实际影响范围。

另一方面，事件管理具有明显的区域属性和责任边界。校园、社区、园区或物业区域通常都有各自的管理主体，不同区域的管理人员只熟悉自己负责范围内的设施、地点和处理方式。若由一个统一平台直接管理所有区域事件，不仅管理人员难以准确判断各地情况，也难以明确事件最终应由谁负责。因此，区域事件需要由熟悉当地情况、具有实际处理能力的组织负责管理。

同时，用户面对不同类型的问题时，往往难以准确判断事件类别、严重程度以及应该提供哪些信息。管理人员收到大量描述方式不一致的上报后，也需要花费时间进行整理、判断和分类。此外，自由描述的上报还可能缺少处理所需的关键信息——例如位置不精确、没有现场照片、未说明问题发生的时间——管理人员往往需要逐条联系上报者核实，进一步增加了处理前的确认成本。在事件数量较多时，真正紧急或影响范围较大的事件还可能被普通事件淹没。

因此，本平台需要满足的核心需求是：对于校园、社区、园区、物业等具有明确管理边界的区域，建立由区域组织负责的事件上报与协同处理机制，使用户能够以较低门槛向对应区域提交包括设施报修、环境卫生、安全隐患、失物招领在内的各类问题，管理人员能够集中了解、判断和跟踪事件，并系统性地解决信息分散、重复上报、描述不统一、信息不全、责任主体不明确以及事件进展难以追踪等问题，让原本零散的“用户反馈”能够逐步形成可确认、可管理、可协作和可持续跟踪的事件。

2.2 A（Approach，做法）

针对事件信息分散、重复上报、责任主体不明确以及处理过程难以持续跟踪等问题，平台采用“统一事件基础设施 + 分区域自治管理 + AI 辅助分析 + 人工最终确认”的整体方案。

首先，平台提供统一的事件上报入口。用户可以通过文字描述、图片等方式提交问题，并选择事件所属区域。平台利用 AI 对上报内容进行初步解析，提取地点、关键描述等信息，并结合当前区域已经配置的事件标签给出标签推荐，同时给出优先级和处理建议，减少用户填写成本，也降低管理人员后续整理信息的工作量。

在用户正式提交之前，平台可以根据其输入的文字、图片、地点等信息，对当前区域内已有事件进行语义匹配，并展示可能相关的已有事件。该功能仅用于帮助用户判断当前问题是否已经被他人反映，普通用户不能直接修改、归并已有事件，也不能直接向已有事件中追加内容。如果用户认为已有事件已经能够反映当前问题，可以选择不再重复提交；如果认为情况不同，或已有信息不足以覆盖自己发现的问题，则仍可正常创建新的事件上报。

在用户点击提交后、事件正式进入区域管理范围之前，平台增加一步确认环节：AI 基于用户已输入的文字、图片和位置信息进行解析，将提取出的事件要点（如地点、关键描述以及推荐标签）简要呈现给用户确认；如果判断可能缺失影响后续处理的关键信息——例如地点不够精确、缺少现场照片、未说明问题发生的时间——会以少量简短提示的形式向用户询问。

这类提示数量有限且完全可跳过，用户确认无误或直接跳过后即可完成提交，事件照常上报。该环节的目的不是把自由描述变回必填表单，而是在几乎不增加用户成本的前提下提高单次上报的信息完整度；即使个别上报仍有缺失，后续的聚合机制与管理员反馈机制也能继续补全，用户不会因信息不全而被阻塞在提交环节。

对于最终形成的多条相似上报，平台会在后台进一步结合语义内容、地点、时间和事件特征等信息生成候选聚合关系。AI 只负责发现“可能属于同一事件”的上报并给出建议，最终是否聚合由对应事件管理者确认。确认聚合后，各条原始上报仍然保留，其文字、图片、时间和来源等信息共同构成完整的事件记录，从而避免简单去重造成信息丢失。

此外，聚合本身也具有信息补全作用：不同上报者对同一事件的观察各有侧重，一条上报缺少的照片或位置信息，可能可以从其他上报中获得，这在一定程度上降低了单条上报必须一次填写完整的要求。

为了避免由平台统一管理所有地区而带来的责任模糊和管理人员无法了解当地实际情况的问题，平台采用区域组织入驻模式。校园、社区、园区、物业等组织可以申请建立自己的事件管理区域，并自行配置区域管理员。普通用户在上报事件时，需要选择对应区域，事件进入该区域组织的管理范围。平台主要提供事件上报、分析、聚合、协作和跟踪等基础能力，而具体事件是否合并、如何处理以及由谁执行，则由对应区域组织负责决定。

为了适应不同区域的实际管理需求，区域管理员可以为自己的区域配置事件标签，例如“设施维修”“环境卫生”“安全隐患”“失物招领”等，并可为不同标签配置对应的工单模板。工单模板主要用于规定处理此类事件时需要记录哪些信息，例如负责人、处理说明、处理结果、现场图片等，而不强制规定一套固定的审批或业务流程。

对于上报后需要进一步处理的事件，管理员可以结合用户上报内容、聚合结果、AI 给出的优先级和处理建议，以及实际情况进行判断。如果经过上述环节后，事件仍存在影响处理的关键信息缺失，管理员可以向提交者反馈信息不全并请求补充：管理员向该事件的上报者发送补充请求，说明需要补充的内容，例如更准确的位置、现场照片或问题发生的时间；上报者收到通知后可以选择补充或忽略。

为避免事件长期停留在等待状态，平台将“待补充信息”作为一种独立事件状态。如果上报者在一定时间内未响应，事件重新进入管理员待处理范围，由管理员根据已有信息决定继续处理、安排相关人员进行现场核实，或因信息不足关闭事件。

若事件需要安排人员处理，管理员可以根据事件标签创建对应工单，并指定相关处理人员。事件处理过程中主要通过“待处理、待补充信息、处理中、已完成、已关闭”等状态记录进展，同时保留处理说明、处理结果和补充信息，使事件从发现、确认到处理结束形成清晰、可追踪的记录。

因此，平台并不试图让 AI 独立完成事件判断和决策，而是将 AI 定位为辅助工具，主要承担信息提取、缺失信息识别、标签推荐、相似事件检索、候选聚合、优先级分析、处理建议和工单内容辅助生成等工作；涉及事件聚合、标签确认、责任确认、人员分配和最终处理决策时，仍由实际管理者进行确认。

整体处理流程可概括为：

用户填写上报信息 → AI 检索相似已有事件 → 用户决定是否继续提交 → 点击提交，AI 解析事件要点、推荐标签并提示可能缺失的信息（确认环节，可跳过）→ 后台生成候选聚合关系 → 管理者确认是否聚合 → 管理者确认事件标签 → AI 给出优先级和处理建议 → 必要时向提交者反馈信息不全（待补充信息）→ 必要时根据标签生成工单 → 指定处理人员 → 更新事件状态 → 持续跟踪处理结果。

在这一机制中，管理者由对应区域组织提供。通过这种方式，平台既提供统一的智能事件协作能力，又保留清晰的区域边界、管理权限和人工决策机制。

2.3 B（Benefit，好处）

平台的核心价值不是单纯“增加一个事件上报入口”，而是将原本分散、重复、难跟踪的事件信息转化为可整理、可确认、可协作和可持续追踪的事件处理过程，并通过 AI 降低用户和管理人员双方的信息处理成本。

对于普通用户而言，平台降低了事件上报和信息获取的门槛。用户不需要了解复杂的事件分类和处理方式，只需通过文字、图片等方式描述自己发现的问题，平台即可辅助提取关键信息并结合所在区域已有标签给出推荐。在正式提交之前，用户可以看到当前区域内可能相关的已有事件，减少无意义的重复上报，同时也能更快了解问题是否已经被其他人发现或正在处理中。提交时的确认与信息提示均为可跳过的设计，用户不会因为信息不全而被阻塞，也不会因为不熟悉分类而被迫学习一套复杂表单。

对于区域组织和管理员而言，平台能够明显减少人工整理大量零散信息的工作。面对多个用户对同一问题的不同描述，AI 可以先进行相似性分析并给出候选聚合项，管理员只需要对候选结果进行确认，而不必完全依靠人工逐条查找。聚合后的事件能够集中保留多个来源的文字、图片和时间信息，使管理员获得比单条上报更完整的现场情况，并据此判断事件影响范围和处理优先级。

对于提交后仍缺少关键信息的事件，管理员也可以通过平台直接向上报者反馈信息不全并请求补充，而不必依赖电话、微信等渠道私下联系，使信息补充过程与事件记录保留在同一体系中。

平台采用区域组织自治的方式，也能够使事件管理责任更加明确。不同校园、社区、园区或物业组织只需要处理自己负责区域内的事件，不要求平台方或某个统一管理员掌握所有地区的实际情况。这样既降低了管理规模扩大后产生的信息负担，也使事件判断和处理决策能够由真正了解当地情况的人员完成。

通过区域标签和工单模板配置，不同组织还可以根据自身实际情况管理事件，而无需由平台预先定义所有业务类型和复杂流程。管理员可以自行配置常见事件标签，并为需要进一步处理的事件类型设置相应工单模板，使平台在保持统一基础能力的同时，能够适应不同校园、社区、园区和物业场景。

AI 对事件优先级、处理建议和工单内容的辅助生成，可以进一步减少管理人员重复性的分析和文书工作。管理员仍然保留最终确认权，因此既能够利用 AI 提高处理效率，又可以避免将重要决策完全交给自动系统。当事件需要安排人员处理时，平台通过工单和事件状态持续记录待处理、待补充信息、处理中、已完成等进展，使用户和管理人员都能够了解事件当前所处阶段，减少反复询问和信息丢失。

因此，平台能够为不同参与者带来以下整体收益：

1. 降低用户上报成本：用户无需熟悉复杂分类和流程，通过自然语言和图片即可完成事件描述。
2. 减少重复信息带来的管理负担：通过提交前相似事件提示和后台候选聚合，减少管理员人工查找重复事件的工作。
3. 多层机制保障信息完整性：提交时 AI 提示可能缺失的关键信息（可跳过），聚合后多个用户的不同观察互为补充，必要时管理员还可向提交者反馈信息不全——信息缺口始终有下一层机制接住，而不是依赖用户一次填全。
4. 明确管理责任边界：事件由对应区域组织负责，避免统一平台管理所有事件造成责任模糊。
5. 提高事件处理效率：AI 辅助完成信息提取、标签推荐、优先级判断、处理建议和工单内容生成，使管理人员将更多精力投入到真正需要人工判断的环节。
6. 适应不同区域的管理需求：各区域可以自行配置事件标签和工单模板，无需平台预先设计复杂、固定的业务流程。
7. 保留人工决策能力：事件聚合、标签确认、人员分配和最终处理仍由管理者确认，在提升自动化程度的同时降低 AI 误判带来的风险。
8. 增强事件处理过程的可追踪性：从上报、聚合、确认、补充信息到处理和结束均留下状态记录，使参与者能够持续了解事件进展。

通过这些能力，平台将传统的“有人发现问题并上报”进一步转变为“多人提供信息、系统辅助整理、管理者确认、相关人员协同处理”的完整事件协作模式。

2.4 C（Competitors，竞争）

目前，与本平台解决的问题相关的替代方案主要包括即时通讯群组、传统报修或事件上报系统、综合公共事件处理平台以及普通社交平台等。它们分别能够解决部分问题，但在事件聚合、跨来源信息整理和多场景协作方面仍存在不足。

1. 即时通讯群组

微信群、QQ群等是校园、社区和物业中最常见的信息反馈方式之一。其优势是使用门槛低、传播速度快，用户几乎不需要学习新的系统即可发送文字、图片和位置等信息。

但聊天群中的信息主要按照时间顺序排列。当事件数量增加后，同一个问题可能被多次重复讨论，图片、补充描述和处理结果容易分散在不同消息中。管理员还需要人工判断哪些消息描述的是同一个事件，也难以持续维护事件的处理状态。

相比之下，本平台将信息组织单位从“聊天消息”转变为“事件”。AI 可以辅助发现相似上报并生成候选聚合项，再由管理员确认，使多个用户提供的信息围绕同一个事件集中管理，同时保留从上报到处理结束的完整状态记录。

2. 传统报修和事件上报系统

学校、物业和园区通常已经存在设备报修、问题反馈等系统。这类系统具有明确的表单、分类和处理方式，适合处理设施损坏、维修申请等相对固定的业务。

但传统系统通常要求用户主动选择事件类别并填写结构化表单，对事件之间是否重复、多个用户是否在描述同一问题等情况处理较弱；用户为了完成表单还可能随意选择类别，造成分类错误或信息失真。

本平台则通过自然语言和图片降低上报门槛，并利用 AI 辅助完成信息提取、标签推荐、相似事件检索和候选聚合。同时，针对自由描述可能带来的信息不全问题，平台在提交时提供可跳过的缺失信息提示，并允许管理员在必要时向提交者反馈信息不全、请求补充，从而在保持低门槛的同时兼顾信息完整性，而不是完全依靠必填表单来保证信息齐全。

对于区域组织，平台允许管理员自行配置事件标签，并按需要为标签设置工单模板，使不同组织能够在统一事件管理机制上进行轻量适配，而不需要为每个区域单独开发一套新的事件系统。

3. 综合公共事件处理平台

部分城市或组织已经建立较完整的公共问题上报和处理机制，其优势在于责任部门明确、管理规范，并能够形成较正式的事件处理闭环。

这类平台通常面向特定行政区域或组织体系，业务规则和责任主体较为固定，因此并不适合直接覆盖大量彼此独立的校园、社区、园区等组织。

本平台不直接承担所有事件的统一管理，而是提供通用的事件汇聚与协作基础设施。不同区域组织可以管理自己的区域、人员、标签和工单模板，平台无需掌握每个地区的具体业务规则，从而具有更灵活的组织适配能力。

4. 普通社交平台和信息发布平台

朋友圈、社区论坛、校园墙等平台也常被用于发布问题反馈、失物招领等信息。这类方式传播范围较广，适合快速触达潜在知情者。

但相关信息通常以帖子或动态形式存在，后续用户提供的补充线索容易分散在评论、私信或新的帖子中，随着时间推移还可能被新的内容覆盖，信息发布者和区域管理方都需要自行整理大量零散内容，也无法持续维护事件的处理状态。

本平台将这类具有明确区域属性的信息纳入对应区域的统一事件管理，例如失物招领可以作为区域标签之一由区域组织承接，使补充信息围绕同一事件持续汇集，并保留状态记录。而对于完全不属于任何区域管理范围的个人生活事件，例如跨区域的宠物走失等，社交平台通常仍具有更强的传播优势，本平台当前不将其作为主要覆盖场景。

5. 本平台的差异化

与上述方案相比，本平台的核心差异并不在于单独提供“事件上报”功能，而在于建立一套围绕事件全过程的智能汇聚与协作机制。

主要差异包括：

1. 从信息发布转向事件管理：多个用户的信息不再只是独立消息，而可以在人工确认后围绕同一事件进行组织。
2. AI 辅助而非 AI 直接决策：AI 负责解析、标签推荐、检索、聚合建议和处理建议，最终聚合和处理决策仍由管理者完成。
3. 支持提交前相似事件检索：用户在正式上报前即可了解是否存在相似事件，减少明显的重复上报。
4. 区域组织自治：平台只提供基础设施，各区域组织负责自己的事件和管理员，降低统一管理带来的认知和责任压力。
5. 区域标签与工单模板可配置：不同组织可以根据自身实际需求配置事件标签，并为不同标签设置相应工单模板，而不需要平台统一规定复杂处理流程。
6. 多层信息补全机制：自由上报不会因信息不全而阻塞——提交时可跳过的 AI 缺失信息提示、聚合后的信息互补、管理员补充请求与“待补充信息”状态共同处理信息缺口，在保持低门槛的同时兼顾信息完整性。
7. 保留完整事件来源：聚合并不意味着删除重复信息，而是保留不同用户的描述、图片和时间等原始记录，以补充事件全貌。
8. 支持事件全过程跟踪：事件可以从上报、聚合、确认一直跟踪到处理和结束，而不是停留在单次信息发布阶段。

当然，本平台相比已经成熟的聊天软件和传统报修系统也存在劣势。用户需要额外进入平台进行上报，区域组织还需要主动申请并配置管理员；同时，语义匹配和 AI 分析存在误判可能，因此仍需要人工审核。对于事件数量很少、处理方式非常简单的小型组织，使用聊天群或普通表单可能已经能够满足需求。

因此，本平台更适合事件数量较多、存在重复上报、需要多人补充信息，并且希望对事件进行持续管理和协同处理的场景，其竞争优势主要体现在事件汇聚、人工可控的智能辅助以及灵活的组织管理模式上。

2.5 D（Delivery，推广与交付）

本平台采用“区域组织入驻 + 普通用户直接使用 + 场景化推广”的方式进行交付和推广。由于区域事件通常具有明确的管理边界，因此平台不直接面向所有地区统一管理，而是优先吸引校园、社区、园区、物业等具有实际管理需求的组织入驻，再由这些组织带动其覆盖范围内的普通用户使用。

对于区域事件场景，平台首先向具有明确管理范围的组织提供入驻入口。区域组织申请后，可以创建自己的管理区域、配置管理员和处理人员，并根据自身情况设置事件标签；对于需要安排人员处理的事件类型，还可以为对应标签配置工单模板。普通用户进入平台后，可以选择已经入驻的区域进行事件上报。如果某一区域尚未有组织入驻，则暂不提供正式的区域事件处理服务，避免出现事件有人上报但无人负责的情况。

在推广初期，可以优先选择校园、宿舍区、小型社区或园区等边界清晰、管理人员明确、事件规模适中的场景进行试用。例如通过校园物业、学生组织、社区管理人员等渠道邀请首批区域组织入驻，再通过公告、二维码、公众号或内部通知等方式向区域内用户提供统一的上报入口。通过较小范围的实际使用验证事件上报、相似事件检索、候选聚合、信息补充、人工确认、工单处理和状态跟踪等核心能力，再逐步扩大到更多区域。

对于普通用户，平台尽量降低首次使用成本。用户不需要了解后台管理方式，只需要选择对应区域，通过文字、图片等方式描述自己发现的问题即可。提交前的相似事件检索可以帮助用户快速了解当前问题是否已经有人反映，提交时的确认与信息提示也均可跳过，从而降低用户首次使用平台的门槛。

为了形成持续使用，平台还需要让事件处理结果对参与者可见。用户上报后能够查看事件是否被确认、是否已经安排处理以及当前状态，区域组织也可以通过事件列表、优先级、工单和处理记录管理自身事务。当用户发现通过平台提交的问题能够得到持续反馈，而不是“提交后没有下文”时，才更容易形成稳定的使用习惯。

在产品迭代过程中，平台可以根据区域组织和普通用户的实际反馈持续优化事件标签推荐、语义匹配、候选聚合、信息补全、标签配置和工单模板。对于具有相似管理需求的组织，可复用已有的基础能力，减少每个区域单独建设一套事件系统的成本。

因此，本平台的推广路径可以概括为：

小范围场景试用 → 区域组织申请入驻 → 配置管理员、处理人员、事件标签及工单模板 → 向区域用户开放统一上报入口 → 通过实际事件形成使用反馈 → 优化平台能力 → 逐步扩展到更多区域。

在这一过程中，平台不依赖一次性的大范围推广，而是通过具体组织和真实事件场景逐步积累用户和管理方，使平台从“可使用的事件工具”逐渐成为区域组织和普通用户之间稳定的协作入口。

---

三、团队绩效考核方案

3.1 考核原则

结合《构建之法》中团队成员投入程度与绩效管理相关内容，团队绩效考核初步遵循以下原则：

1. 公开透明
   所有任务、负责人、完成情况和贡献记录尽可能公开，成员可以了解自己的任务安排和绩效评价依据。

2. 过程与结果并重
   不仅关注最终成果，也关注成员在项目开发过程中的实际投入、任务推进情况和协作表现。

3. 不以单一指标评价成员
   不简单按照代码行数、Commit 数量等单一指标计算贡献，而是综合考虑任务完成情况、工作质量、投入程度和团队协作等因素。

4. 角色差异化评价
   前端、后端、测试、PM、UI、文档等不同岗位根据实际承担的工作内容进行评价，不以是否编写代码作为判断贡献大小的唯一依据。

5. 鼓励团队协作
   帮助其他成员解决问题、参与代码 Review、联调、测试、文档完善等均属于有效贡献。

6. 阶段性考核
   不在项目结束后一次性确定成员绩效，而是在各个主要开发阶段结束后分别进行考核，以减少最终一次性评价的主观性。

---

3.2 绩效考核指标

团队采用 阶段性基础分 + 浮动分 的绩效考核方式。

每个阶段绩效满分为 100 分，其中：

• 基础分：70 分
• 浮动分：30 分

基础分主要用于评价成员是否完成本阶段应承担的基本职责；浮动分主要用于体现不同成员在任务难度、成果质量、团队协作、主动性以及额外贡献等方面的差异。

基础分

考核指标	分值	说明
任务完成情况	30 分	是否完成本阶段分配并确认的任务
进度与及时性	15 分	是否按照计划推进并按时提交成果
成果基本质量	15 分	成果是否达到团队约定的基本交付要求
团队基本参与	10 分	是否正常参加会议、沟通、联调等团队活动
合计	70 分

其中，70 分基础分并不是无条件获得的固定分数。若成员存在任务未完成、严重延期、长期缺席团队活动等情况，则根据实际情况扣除相应分数。

浮动分

考核指标	分值	说明
任务难度与工作量	10 分	根据任务技术难度、业务复杂度和实际工作量评价
成果质量与实际价值	8 分	评价成果是否明显高于基本交付要求
团队协作贡献	5 分	是否主动帮助成员、参与联调、Review 等
主动性与责任承担	4 分	是否主动发现问题、承担任务和解决问题
额外贡献	3 分	是否承担额外任务或解决关键问题
合计	30 分

各指标具体评分参考如下：

基础分评分标准

指标	评分标准
任务完成情况（30 分）	全部完成：30 分；基本完成：25～29 分；部分完成：18～24 分；完成度较低：10～17 分；基本未完成：0～9 分
进度与及时性（15 分）	按时完成并主动同步：15 分；轻微延期但不影响整体：12～14 分；明显延期：8～11 分；多次催促：4～7 分；严重拖延：0～3 分
成果基本质量（15 分）	可直接使用：15 分；少量问题：12～14 分；需要一定返工：8～11 分；需要大量修改：4～7 分；基本不可用：0～3 分
团队基本参与（10 分）	正常参与并及时沟通：10 分；偶尔缺席：8～9 分；多次缺席或回复较慢：5～7 分；经常失联：1～4 分；基本不参与：0 分

浮动分评分标准

指标	评分标准
任务难度与工作量（10 分）	核心高难度任务：9～10 分；较复杂重要任务：7～8 分；正常任务：5～6 分；较简单任务：3～4 分；实际工作量较少：0～2 分
成果质量与实际价值（8 分）	明显高于预期：8 分；质量较高：6～7 分；正常达到预期：4～5 分；成果一般：2～3 分；无明显额外价值：0～1 分
团队协作贡献（5 分）	明显促进团队协作：5 分；多次主动协助：4 分；正常协作：3 分；较少协作：1～2 分；几乎无协作贡献：0 分
主动性与责任承担（4 分）	主动发现并解决问题：4 分；主动性较好：3 分；正常完成安排任务：2 分；较被动：1 分；明显逃避责任：0 分
额外贡献（3 分）	突出额外贡献：3 分；明显额外贡献：2 分；一定额外贡献：1 分；正常完成本职工作：0 分

---

3.3 任务管理方式

团队计划使用 GitHub / Gitee 等代码托管平台配合任务记录工具 管理项目任务，具体工具将在项目正式开发后根据团队实际情况确定。

每项任务至少记录：

• 任务名称
• 任务负责人
• 任务说明
• 任务难度或预计工作量
• 计划完成时间
• 实际完成时间
• 完成情况
• 对应成果
• 必要时记录协作者

任务开始前应尽可能明确负责人和交付目标，避免在阶段结束后因任务边界不清导致贡献难以判断。

对于较大的任务，可以拆分为多个子任务，使实际工作量和成员贡献更加容易记录。

---

3.4 贡献记录方式

团队成员贡献可以通过以下材料进行记录：

• Git Commit
• Pull Request / Merge Request
• Issue
• 前端页面
• 后端接口
• 数据库设计
• 测试用例
• Bug 修复记录
• UI / 原型设计
• 项目文档
• PPT
• 博客
• 项目管理工作
• 会议记录
• 前后端联调记录
• 部署及环境配置
• 其他可以证明实际贡献的材料

上述记录作为绩效评价的依据，但 不直接按照数量机械计算贡献。

例如，Commit 数量较多并不一定意味着贡献较大，一个复杂核心功能可能只对应少量提交，因此 Git 记录主要用于证明成员参与了哪些实际工作，而不是直接作为评分结果。

---

3.5 阶段性评价

团队不在整个项目结束后一次性确定最终贡献度，而是在每完成一个重要阶段后进行一次绩效评价和团队复盘。

主要阶段可以包括：

• 需求分析阶段
• 原型与系统设计阶段
• Alpha 冲刺阶段
• Beta 冲刺阶段
• 最终测试与发布阶段

每个阶段结束后，团队主要讨论：

• 本阶段完成了哪些任务
• 各成员承担了哪些工作
• 各成员任务完成情况如何
• 是否存在任务分配不均
• 是否存在任务延期
• 是否出现需要大量返工的成果
• 是否有成员主动承担额外工作
• 是否需要调整下一阶段的任务和人员安排

每个成员在当前阶段获得一个 0～100 分的阶段绩效分。

阶段绩效计算方式为：

阶段绩效
=
基础分（最高 70 分）
+
浮动分（最高 30 分）

通过阶段性评价，可以避免只根据项目最后阶段的表现判断成员整个学期的贡献。

---

3.6 组内互评

每个主要开发阶段结束后，由团队成员进行一次组内互评。

互评主要围绕以下方面进行：

• 任务是否正常完成
• 工作质量是否达到要求
• 是否按时推进任务
• 是否积极参与团队协作
• 是否主动帮助其他成员
• 是否存在明显额外贡献

成员评价其他成员时，应尽量结合任务记录、Git 记录、项目成果和会议记录等实际依据，避免单纯根据个人关系或主观印象进行评分。

互评结果作为阶段绩效的重要参考，但不直接作为唯一评分依据。

对于存在明显争议的评分，由团队成员根据实际任务和贡献记录共同讨论后确定。

原则上，成员不参与对自己的互评分数计算，避免自评分对结果产生影响。

---

3.7 特殊情况处理

任务延期

如果成员因个人原因未能按照计划完成任务，根据延期程度和对团队整体进度造成的影响，在“进度与及时性”项目中进行相应扣分。

若延期是由前置任务未完成、需求变化、方案调整、第三方服务异常等客观原因造成，经团队确认后原则上不作为个人绩效扣分依据。

因个人原因无法完成任务

成员因个人原因无法按计划完成任务时，应尽早向团队说明，并及时进行任务交接。

若能够提前说明情况且完成必要交接，可根据实际影响适当调整评分；若长期不反馈、不进行交接，并导致其他成员临时接手任务，则根据实际影响扣除任务完成情况、进度与及时性等相关分数。

主动帮助其他成员

成员在完成自身任务的基础上，主动帮助其他成员解决技术问题、参与联调、测试、代码 Review 或文档完善，可在“团队协作贡献”和“主动性与责任承担”中获得相应浮动分。

若帮助行为对团队整体进度产生明显积极作用，可以进一步获得额外贡献分。

承担关键或高难度任务

成员承担技术难度较高、工作量较大或对项目整体较为关键的任务时，在正常完成基础职责后，可在“任务难度与工作量”项目中获得较高浮动分。

若同时解决了关键技术问题或承担了明显超出原计划的工作，还可在“额外贡献”项目中获得相应加分。

长期低参与度

若成员长期存在以下情况：

• 多次无故缺席团队活动
• 长时间不回复团队消息
• 多次未完成已经领取的任务
• 需要其他成员反复催促
• 长期缺乏实际成果

则根据实际情况扣除任务完成情况、进度与及时性、团队基本参与等基础分。

若情况较为严重，由团队共同讨论后进一步降低该阶段绩效评价。

---

3.8 最终贡献度计算

每个阶段成员绩效均按照以下方式计算：

阶段绩效
=
任务完成情况（30 分）
+
进度与及时性（15 分）
+
成果基本质量（15 分）
+
团队基本参与（10 分）
+
任务难度与工作量（10 分）
+
成果质量与实际价值（8 分）
+
团队协作贡献（5 分）
+
主动性与责任承担（4 分）
+
额外贡献（3 分）

即：

阶段绩效
=
基础分（70 分）
+
浮动分（30 分）

成员最终贡献度由各阶段绩效综合确定。

初步采用各阶段绩效平均值：

最终贡献度
=
各阶段绩效总和
÷
参与考核的阶段数量

如果后续项目开发过程中发现不同阶段的工作量和重要程度存在明显差异，团队可以在保持考核指标不变的情况下，对不同阶段设置相应权重。

最终绩效结果应结合任务记录、代码记录、文档记录、会议记录以及组内互评结果共同确认。

团队将在实际项目开发过程中，根据任务复杂度、成员角色和项目推进情况继续完善绩效考核方案。

---

四、团队愿景

我们选择“智能事件汇聚与协作平台”，是希望解决校园、社区、园区、物业等场景中信息分散、重复上报、责任边界不清和处理进度难以追踪的问题。我们计划在本学期完成一个能够实际运行和完整演示的系统，实现事件上报、AI 信息解析、相似事件检索与聚合、区域管理、人工确认、工单处理和状态追踪等核心功能，并通过真实场景验证整个处理流程。未来，我们希望平台能够应用于校园物业、社区管理、园区运维等具有明确管理边界的场景，让零散的问题反馈能够被有效汇聚，让事件从发现、确认到处理都有迹可循、有处可管、有结果可查。

---

五、结语

这次团队展示对我们来说，不只是确定了一个项目题目，也算是正式迈出了团队合作的第一步。从组队、讨论选题，到梳理 NABCD、制定绩效考核方案，我们也逐渐发现，一个项目真正做起来，远不只是把代码写出来这么简单，还需要不断沟通、分工、协调和调整。

接下来，我们会围绕“智能事件汇聚与协作平台”继续完善需求、设计系统并推进开发。过程中肯定会遇到不少问题，方案也可能不断修改，但我们希望能把这次课程项目认真做下去，在一次次讨论、踩坑和解决问题的过程中，把最初的想法真正变成一个能够运行、能够展示，也经得起检验的作品。