软件工程实践团队作业

你不对我队 2026-10-01 18:04:21

项目	内容
这个作业属于哪个课程	202601福大-软件工程实践-W班社区
这个作业要求在哪里	软件工程实践团队作业——种子队选拔、团队展示及选题
这个作业的目标	完成团队展示与选题论证：运用 NABCD 模型说明项目价值，明确团队分工、绩效考核方案、团队愿景与风险控制办法
其他参考文献	《构建之法》第 17 章绩效管理；你参加团队有什么样的投入；绩效管理

「你对我不对」——团队展示与选题报告

队名：你对我不对
项目：《最后一班地铁：0017》——一款 27 分钟的本地 Web 2D 调度叙事游戏
团队规模：8 人　|　发布到班级社区的「软件工程实践团队作业」板块

一、选题摘要

拟作团队项目选题描述：

一款 27 分钟的 2D 调度叙事游戏——玩家在末班地铁的最后一刻反复重置时间，用有限次数的调度操作找出事故的真相。

One sentence (English)： A 27-minute 2D dispatch narrative: replay the last train's final minutes, spend your limited dispatches, and find out what really happened.

**选题 PDF 文档链接：https://pan.baidu.com/s/1ozEpBbHgRaUxBDArJxAnjw?pwd=1111

二、团队介绍

队名：你对我不对

「0017」代表 00:17，也代表这趟最后一班地铁背后的真相。

「你对我不对」是我们组在群里争论选题时冒出来的一句口头禅，后来发现它意外地贴合我们要做的游戏。每一次循环结束时，你都会觉得自己判断对了；而下一轮解锁的线索，往往会告诉你其实不对。对错与否，不取决于谁的声音大，而取决于你手里有多少信息。 我们希望这是一个靠证据说话、靠复盘推进的团队。

团队 slogan：最后一班车会到站，真相不会缺席。

队员风采

按学号排序。以下各项均为成员本人填报，其中「希望的软工角色」即其在团队中希望承担的方向。

1. chs

学号： 102400101
CSDN 主页： chs
成员性格： 文静，随和
擅长的技术： C、C++、Java、AIGC
兴趣爱好： 听歌、端游
希望的软工角色： 测试
一句 slogan： 生活的理想，就是为了理想的生活。

2. sleeplis

学号： 102400106
CSDN 主页： sleeplis
成员性格： 随和，直率
擅长的技术： 利用大模型、C、C++、Java
兴趣爱好： 游戏、小说、动漫
希望的软工角色： 测试
一句 slogan： 这个人很懒，什么也没留下。

3. yuesart

学号： 102400107
CSDN 主页： yuesart
成员性格： 热情、开朗
擅长的技术： 利用大模型、Java、SQL、C 语言
兴趣爱好： 阅读、打羽毛球
希望的软工角色： 测试
一句 slogan： 天道酬勤，厚德载物

4. 心境

学号： 102400114
CSDN 主页： 2601_96871760
成员性格： 沉稳耐心，做事细致
擅长的技术： MySQL 数据库、接口调试、YOLO 视觉模型训练、ROS2 建模
兴趣爱好： 打独立游戏、阅读科幻小说、慢跑
希望的软工角色： 后端开发
一句 slogan： 稳步编码，拒绝草率交付。

5. 飞哟飞

学号： 102400121
CSDN 主页： 飞哟飞
成员性格： 乐观
擅长的技术： 利用大模型、C++、Java
兴趣爱好： 听歌、看小说
希望的软工角色： 后端
一句 slogan： 好好学习，天天向上

6. 小千

学号： 102400126
CSDN 主页： 小千
成员性格： 开朗，活泼，幽默
擅长的技术： 利用大模型、Java、C++、C 语言
兴趣爱好： 打羽毛球、打游戏
希望的软工角色： 前端
一句 slogan： 步履不停，自有光芒

7. 。。

学号： 102400128
CSDN 主页： 。。
成员性格： 负责，直率
擅长的技术： 利用大模型、C++、Java
兴趣爱好： 打游戏、打羽毛球
希望的软工角色： 后端
一句 slogan： 成功者绝不放弃，放弃者绝不成功

8. 王嘉萍（Amy）

学号： 102400206
CSDN 主页： 2501_91297800
成员性格： 做事踏实有耐心，乐于沟通协作，学习态度积极，遇到问题愿意主动钻研
擅长的技术： Python 基础，了解前端基础标签，能够完成简单代码编写与调试
兴趣爱好： 美食探店、听歌、浏览技术博客
希望的软工角色： 前端开发
一句 slogan： 持续学习，用代码创造好看实用的界面。

三、选题过程

1. 选题背景

在最终确定项目之前，团队收集并讨论了多个方向，包括云笔记与知识库、拼团搭子、考研学习打卡、FitLoop 健身饮食、校园失物匹配、智能提醒管家以及叙事游戏等。每个方案都从用户需求、技术难度、团队分工、演示效果和风险控制等方面进行了初步比较。

2. 讨论过程记录

9 月 28 日晚，团队召开约 39 分钟的线上会议，对候选方案进行集中讨论。随后在群聊中继续比较「寻物 AI 识图」「拼团搭子关键词匹配」「接入 API」等实现方式，并完成成员偏好反馈。

在这里插入图片描述

群聊中的讨论使团队进一步明确：

技术方案不能只看功能是否新鲜，还要考虑接口稳定性、测试成本和实现周期；
校园工具类方案需求真实，但可能依赖外部 API、用户数据和运营场景；
游戏类项目虽然需要内容制作，但《最后一班地铁：0017》的边界已经明确为 3 名乘客、4 轮循环和 2 个结局，反而更容易控制；
项目需要同时体现需求分析、系统设计、前端实现、内容制作、测试、构建和团队协作，不能只是简单页面。

3. 候选选题对比

候选选题	核心设想	主要优势	主要风险或限制
多端协同云笔记与知识库	支持 Markdown、多人实时协同、双链和多端同步	软件工程覆盖面完整	OT/CRDT、多端同步和权限系统难度较高，容易超出学期范围
校园/社区拼团搭子	按时间、地点、标签匹配吃饭、运动、自习等搭子	用户场景直接，交互完整	涉及聊天、匹配和安全治理，冷启动与运营成本较高
研途·考研学习打卡	任务、计时、打卡和学习统计	功能清晰，新手容易完成	功能较常见，技术深度和选题差异化不足
FitLoop·吃练闭环	训练记录、饮食推荐、体重趋势自动调参	功能丰富，具备算法和 AI 亮点	健康与营养建议存在合规风险，推荐模型与数据准备复杂
别忘 BuWang	自动识别班级群 DDL 并多通道提醒	校园需求真实，闭环清晰	依赖机器人、消息解析和外部通知渠道，接口与权限风险较高
寻物雷达	图片、文字、属性、时间地点联合匹配失物信息	需求真实，具有 AI 和匹配算法亮点	识别准确率、隐私保护和物品所有权确认需要额外设计
最后一班地铁：0017	时间循环、地铁调度与叙事推理	创意鲜明，离线可演示，范围明确，演出效果突出	需要稳定的核心系统，并控制剧情、美术和内容制作量

4. 评价标准

团队不只看「创意是否新鲜」，还重点考虑项目能否在课程周期内稳定交付。最终使用以下标准进行判断：

评价维度	权重	判断标准
需求与表达清晰度	20%	项目是否容易被理解，核心体验是否明确
技术可分工性	25%	能否合理拆给多名成员，避免关键任务集中于一人
演示稳定性	20%	能否在规定时间内完整演示，是否依赖外网
差异化	15%	与普通网页应用、视觉小说或现成游戏相比是否有特色
范围可控性	10%	是否能冻结 MVP，避免内容无限扩张
风险控制	10%	技术、版权、隐私和进度风险是否可管理

5. 最终选择

综合选题过程、团队兴趣、技术覆盖面和交付可行性，团队最终选择 《最后一班地铁：0017》。

主要原因有三点：

核心体验清楚。 玩家在固定时间窗内调度列车、广播和人员，通过多次循环寻找事故原因，项目目标一句话就能讲清楚。
范围已经被有效冻结。 首版只有 3 名乘客、4 轮循环、2 个结局，不做 3D、联网、后端和运行时 AI，能够把时间集中在最重要的事情上。
团队角色匹配度高。 叙事、程序、美术、动效和测试都有明确产出，可以覆盖软件工程实践中的需求、设计、开发、测试、部署和协作过程。

四、最终选题：最后一班地铁：0017

1. 项目定位

一款本地 Web 2D 调度叙事游戏。玩家扮演地铁调度员，在 23:50～00:17 之间调整列车、广播和人员安排，通过 4 轮循环拼合线索，阻止事故发生，并走向不同结局。

2. 核心用户体验

玩家每轮都会面对相同的时间窗口，但掌握的信息不同：

第 1 轮：认识车站、乘客和基本调度操作；
第 2 轮：发现异常事件，获得第一条关键线索；
第 3 轮：理解乘客动机和事故原因的部分真相；
第 4 轮：根据已掌握的信息作出最终调度，触发结局。

玩家通过失败和重来逐渐理解系统，而不是被直接告知答案。

3. MVP 功能范围

首个版本必须完成：

1 张车站地图，包含 2 个站台、控制室和候车区；
3 名关键乘客，每人至少关联 2 条线索和 1 个调度选择；
4 轮循环，从 23:50 推进到 00:17；
时间推进、暂停、加速和重新开始；
列车、广播、人员三种调度操作；
线索板，记录上一轮已经解锁的信息；
2 个有明确触发条件的结局；
本地存档和继续游戏；
可在普通笔记本上流畅运行的构建版本。

首版明确不做：

3D、自由行走、物理战斗和多张大地图；
联网、多人协作、账号系统和后端数据库；
游戏运行时使用大模型实时生成剧情、台词或结局；
真实语音克隆、未授权音乐和来源不明素材；
超过 3 名乘客、4 轮循环和 2 个结局的首版内容。

4. 成功标准

新玩家无需开发者解释，能独立完成从开始到结局的完整流程；
4 轮循环均能正确重置，线索只保留应当保留的内容；
两个结局都能通过不同条件触发；
存档后刷新页面可以继续游戏；
暂停、加速、重复点击和返回主菜单不会破坏状态；
演示版本不依赖网络，可在普通笔记本上运行；
20～30 分钟内可以完成一次标准演示。

五、NABCD 分析

N——Need：需求

玩家希望在较短时间内获得完整的推理体验，但很多叙事游戏需要长时间投入，很多小型学生项目又只有概念、没有真正闭环。团队也需要在时间、技术和经验有限的情况下，完成一款稳定可演示的原创作品。

因此，本项目的需求不是「做尽可能多的内容」，而是把时间循环、调度操作和事故推理压缩成一个 20～30 分钟即可体验的完整作品。

我们如何验证需求，而不是自说自话：

首版把「线索板」列为必须完成的 UI 组件——如果玩家在两轮之后仍然说不清自己在查什么，那就是设计失败，而不是玩家不会玩。
第 3～4 周的垂直切片会做一次真实新手测试：由非开发成员独立完成后两轮循环，记录卡点与原话反馈，作为内容调整依据。

A——Approach：方法

项目把 23:50～00:17 设置为固定时间窗口，并拆成 4 轮循环。玩家每轮通过调度列车、广播和人员来获取新线索，上一轮获得的有效信息会影响下一轮判断。

开发上采用数据驱动和离线优先的策略：

前端：Vue 3 + TypeScript；
地图：SVG / Canvas；
剧情与事件：JSON / Ink 数据文件；
存档：localStorage / IndexedDB；
运行方式：本地 Web 应用，不依赖服务器、数据库或联网大模型；
协作方式：Git feature 分支、每周可运行版本、AI 辅助但人工负责。

三条技术主张（也是我们和同类学生作品的主要差别）：

内容与程序解耦。 剧情、线索、事件全部放在数据文件里，不写死在页面代码中。主笔可以在不碰一行代码的前提下改剧情、加线索、验结局——这是 12 周内真的能把内容迭代出来的前提。
时间轴由单一时钟驱动 + 事件条件表。 不使用真实系统时间，因此可以暂停、加速、重置，也可以被自动化测试反复复现；4 轮循环 × 2 个结局 × 存档/重开，构成一个可枚举的测试矩阵，而不是「手点一遍看看」。
演示稳定性优先于技术炫技。 演示版本不依赖网络、不依赖账号、不依赖运行时大模型，在普通笔记本上可离线运行。

B——Benefit：价值

对玩家而言，游戏把叙事、推理和时间调度结合起来，让玩家通过试错和选择理解事故真相，而不是单纯点击剧情。对团队而言，项目覆盖需求分析、系统设计、前端实现、内容创作、测试和构建等完整流程，可以形成可展示、可复用的作品集。

对课程展示而言，它体量适中、离线可运行、操作直观，便于现场演示，也便于后期扩展为校园展览或游戏设计工作坊中的体验项目。

C——Competition：竞争

与纯视觉小说相比，本项目的调度操作、时间循环和线索推理具有更强的互动性；与 3D 动作游戏或大型商业叙事游戏相比，它开发成本较低，普通笔记本即可运行，更适合小团队和学生展示。

参照对象	它通常怎么做	我们的差异
商业剧情向 / 循环叙事大作	20 小时以上体量，需要较高配置与长时间投入	我们只做 20～30 分钟的垂直切片，本地 Web、普通笔记本可跑
网页小游戏、休闲 H5	单局几分钟，分数驱动，基本没有叙事纵深	我们不做分数竞技，做叙事结构与多结局，单局即一个完整故事
视觉小说 / Galgame	选择以对话分支为主，选错大多可以回头补	我们的选择带时间轴，有「来不及」的代价——错过的时间点就是真的错过，这要求玩家先做取舍
同类学生课程作品	剧情与界面逻辑往往写死在代码里，改内容必须改代码	我们采用数据驱动的事件表，剧情与程序解耦，内容可以独立迭代

我们的差异化不在于画面规模和内容数量，而在于「调度系统 + 时间循环 + 多结局叙事」的组合，以及 20～30 分钟即可完整体验的紧凑节奏。

D——Delivery：交付

项目计划用 12 周完成，每周至少产出一个可运行版本，并保留演示录屏和备用构建包。第 4 周设置硬门槛：如果「前两轮循环 + 2 名乘客 + 重开」无法完成，就立即停止扩展内容，优先保证核心闭环可运行。

演示当天使用本地构建且不联网，同时准备完整录屏作为故障回退。

六、技术方案与团队分工

1. 技术基线

层级	技术方案
前端	Vue 3 + TypeScript
地图与演出	SVG / Canvas + CSS 动画
剧情与事件	JSON / Ink 数据文件
存档	localStorage / IndexedDB
运行方式	本地 Web 应用
协作	Git Flow、周版本、测试清单和调试面板

内容、线索和事件都放在数据文件中，不写死在页面代码里。AI 可以协助生成代码骨架、剧情初稿和概念图，但最终内容、代码和素材必须由成员理解、测试和确认。

2. 团队分工

角色	主要职责
制作人 / 项目经理	维护范围、任务板、里程碑、版本号、风险清单、PPT 和最终提交
主笔 / 叙事策划	完成 3 名乘客小传、4 轮剧情变化、线索表、广播、对白和两个结局
核心系统程序员	实现游戏时钟、事件触发、状态机、循环重置、线索管理和存档
交互 / UI 程序员	实现车站地图、调度台、线索板、乘客详情和完整交互流程
场景与角色美术	制作地图、3 名乘客头像、功能图标、事故插画和结局配图
UI 动效 / 演出	统一字体、颜色、间距和控件规范，负责广播、预警、线索解锁和结局转场
测试 / 音频 / 构建	维护测试用例和 Bug 表，整理音效，构建、部署、备份和录屏

每个模块设置一名负责人和一名交叉评审人，所有人参与测试和代码评审。

3. 第一周交付

制作人：项目执行计划、任务板和第一次联调时间；
主笔：3 名乘客、事故主因、事件数据格式；
核心程序：30 秒可运行时间原型；
UI 程序：静态调度台页面；
美术：风格板和地图草稿；
动效：设计规范页和两个动效原型；
测试：最小测试清单和第一个广播音效方案。

七、12 周执行计划

周次	阶段目标	主要交付	主责
第 1 周	立项与原型	范围确认、角色认领、30 秒时间原型	制作人 / 核心程序
第 2 周	第一条循环	时间推进、一个广播事件、一个事故结局	核心程序 / UI 程序
第 3～4 周	垂直切片	前两轮循环、2 名乘客、线索板、重开	全体 / 核心程序
第 5～6 周	核心内容完成	3 名乘客、4 轮循环、2 个结局、存档	叙事 / 程序
第 7～8 周	美术和演出	地图、头像、图标、广播、转场、音效	美术 / 动效 / 音频
第 9～10 周	测试和优化	全流程回归、新手引导、性能与 Bug 修复	测试 / 全体
第 11～12 周	答辩交付	宣传视频、PPT、博客、现场演示和备用录屏	制作人 / 全体

第 4 周硬门槛：如果不能完成「前两轮循环 + 2 名乘客 + 重开」，立即停止扩展内容，优先保证核心闭环可运行。

八、团队愿景

我们想把《最后一班地铁：0017》做成一款真正可玩、可展示、可复用的完整作品，而不是停留在策划书里的创意。玩家只有 27 分钟和有限次数的调度操作——你会做错，但每一轮留下的线索都会跟着你走进下一轮。我们希望人在二三十分钟里，完整经历一次「从不知道到终于看明白」的过程。它既能在课程展示和校园开放日被现场体验，也能作为后续游戏化教学的原型继续扩展。我们希望借此证明：小团队只要守住范围、尊重流程、善用 AI 并坚持测试，同样能交付有叙事温度、有思辨空间、有工程规范的原创作品。

九、团队绩效考核方案

团队绩效考核采用「证据导向、过程公开、角色公平」的原则。所有考核都以任务板、Git 提交、构建版本、测试结果和实际演示为依据，不以「看起来是否很忙」或个人口头陈述作为主要评价标准。

1. 每周过程考核：满分 100 分

考核维度	分值	主要判定标准
任务交付	35 分	是否完成本周承诺任务；延期是否提前说明；是否真正进入可运行版本
质量与测试	25 分	功能是否可用、是否有明显 Bug、是否完成自测和回归、是否可以稳定演示
协作与沟通	20 分	是否参加联调、及时汇报阻塞、回应他人、主动评审和协助解决问题
主动贡献	10 分	是否承担关键路径工作、帮助他人解决既定问题；不奖励擅自增加功能
规范与诚信	10 分	Git 使用、文件命名、数据驱动、AI 素材授权、内容可追溯和不弄虚作假

不同角色的「任务交付」按各自职责验收：制作人看计划和构建版本，主笔看人物、线索和结局是否落地，核心程序员看时间循环、事件、存档是否可靠，UI 程序员看主流程是否可操作，美术和动效看资源与视觉验收，测试人员看测试报告、Bug 回归和构建包是否可复现。

2. 个人最终绩效计算

个人最终绩效 = 每周过程考核平均分 × 70% + 同伴互评平均分 × 20% + 项目负责人评价 × 10%

同伴互评采用匿名方式，每名成员对其他人从「可靠性、沟通、贡献、责任感」四个方面打分，去掉一个最高分和一个最低分后取平均。互评必须附上具体事件或交付物作为依据。

3. 加分与扣分规则

在没有扩大项目范围的前提下，主动承担额外关键任务、帮助团队解除阻塞的，可加 1～5 分，最终不超过 100 分。
无故缺席、连续不响应、任务延期且未提前说明的，经全组确认后扣 5～15 分。
擅自修改范围、伪造测试结果、使用未授权素材、提交无法解释的 AI 代码，或导致主流程无法运行的，该周相关项目可记 0 分，并由全组复核处理。
遇到阻塞时，成员应在 30 分钟内记录报错、复现步骤和已尝试的方法。主动暴露问题是负责的表现，不因合理求助扣分。

4. 防内卷与防挂名

不计代码行数，不计提交次数本身。 格式化、自动生成、纯重命名等提交不计入贡献；只计被评审接受的成果。
挂名不产出会同时反映在「任务交付」「质量与测试」和同伴互评中，无法靠单项补救；连续多周零产出将触发全组约谈与角色重新分配。
组长不天然高分。 组长的得分与其他成员使用同一套规则，仅额外计入组织协调分；其在任务验收与互评中的表现同样接受全员评议。

5. 公开与申诉

考核结果每周日复盘时公布依据，成员可以在 24 小时内提出申诉。任务板、提交记录与测试结果只作为证据供复核参考，不自动处分任何成员；任何扣分结论必须由全组确认并留痕。本方案经全体成员讨论确认后执行，如需修改，必须在周会上说明理由并取得全组同意。

十、风险分析与应对措施

风险	可能影响	应对措施
剧情和线索拖延	主线无法闭环	第一周先确定事故主因和事件字段，先写第一轮与两个结局
核心系统不稳定	循环重置、事件和存档出错	第 1 周完成 30 秒原型，核心逻辑写测试，提供调试面板
美术工作量过大	延期且影响界面完成度	使用统一、简洁的 SVG/2D 资源，不追求大量高精度原画
项目范围膨胀	无法按期交付	冻结 3 名乘客、4 轮循环、2 个结局；新功能必须经过范围变更确认
演示依赖网络	现场无法演示	演示版本完全离线，准备备用构建包和录屏
AI 内容或素材侵权	无法提交或答辩受影响	保留授权说明，AI 内容人工审核，不使用未授权音乐、图片和声音
关键任务集中于一人	风险放大，进度受阻	每个模块设置负责人和交叉评审人，关键接口提前确认