狂想曲委员会——软件工程实践团队作业第二次：原型设计 & 需求分析

项目	内容
这个作业属于哪个课程	2601_FZU_SE 软件工程实践社区
这个作业要求在哪里	软件工程实践团队作业第二次——原型设计&需求分析
团队名称	狂想曲委员会
这个作业的目标	完成《福大秋日狂想曲》的需求分析与界面原型设计，产出符合国标规范的《需求规格说明书》、可访问的界面原型与两份答辩 PPT，并通过博客如实记录项目计划、难点风险与团队协作过程
其他参考文献	[1] GB/T 9385-2008《计算机软件需求规格说明规范》 [2] 邹欣.《构建之法》（第 3 版）[M]. 人民邮电出版社 [3] Ren'Py 8.5.3 官方文档 [4] Ren'Py 画廊与结局收集 [5] Ren'Py 自动测试框架 [6] 团队选题报告《福大秋日狂想曲》

---

目录

目录

---

一、团队项目计划

1.1 项目概述

项目名称： 《福大秋日狂想曲》（Fuzhou University Autumn Rhapsody）

一句话描述： 一款以福州大学校园的秋天为舞台的中文原创喜剧视觉小说——主角在这个秋天同时遇上了两个让他心动的人，而那位一直陪他聊天的神秘网友"秋刀鱼"似乎也在这所学校里；玩家通过关键选择与双轨数值系统走出 5 种不同结局。

项目形式： 游戏（视觉小说 / Visual Novel）

目标用户： 16—24 岁的在校学生、喜欢校园题材与恋爱模拟的视觉小说玩家、乐于截图转发有趣台词的泛娱乐用户，以及对本校题材有天然兴趣的同校学生。

核心链路： 八周日程循环 → 时段活动（上课／自习／运动／打工／小游戏）→ 属性与好感度变化 → 触发代表事件 → 第六周考试 → 第七周最终选择 → 结局与图鉴回收。这条链路是本项目的验收底线，任何阶段都不能让它中断。

技术栈： Ren'Py 8.5.3（Python 3）作为引擎；Git + Git LFS 版本管理；实拍素材 + AI 风格化 + 统一调色作为美术路线；GitHub 仓库与 Projects 看板作为协作载体。

计划规模： 共通线 3 章 + 2 条可攻略线 + 1 条隐藏 IF 线，共 5 个结局，单周目 60—90 分钟。

本次作业的边界（重要）： 本次作业交付的是需求分析与界面原型，不是可运行的游戏。原型使用占位素材，考试、作弊与心情 CG 用占位画面表达功能后果，不要求用真实代码实现整套评分、存档与时间系统。凡属后续工作的内容，本文与需求文档中均如实标注，不写成已完成。

1.2 项目整体计划与阶段划分

项目自组队确定选题后分为五个阶段推进，每个阶段必须留下可演示、可评审的成果。

阶段	时间安排	主要任务	阶段成果与验收方式
第一阶段：组队与选题论证	9 月下旬	团队组建、选题论证、NABCD 分析、团队绩效考核方案	选题报告与团队展示帖，已通过课堂选题答辩
第二阶段：需求分析与原型设计	10 月上旬至 10 月 15 日	需求规则提炼、类图建模、用户访谈与场景、界面原型设计、四份交付物产出	本次作业：需求规格说明书、界面原型、两份答辩 PPT、博客
第三阶段：基本校园循环	10 月下旬至 11 月初	工程骨架、状态系统、分支路由、日程循环、属性变化、存档读取	一天的活动、吃饭、精力与保存读取可在本机运行
第四阶段：代表系统与关键事件	11 月	学习／运动／赚钱与小游戏评级、第二周 B 课堂事件、考试与作弊、外卖与心情、朋友圈	各代表流程可运行、可到达
第五阶段：内容整合与交付	11 月至期末	八周内容整合、结局与图鉴、测试修 bug、打包与发布	可访问、可复现、可讲解的完整成品；Windows 包在组外电脑可运行

flowchart LR
    A["阶段一：组队与选题论证<br/>9 月下旬 · 已完成"] --> B["阶段二：需求分析与原型设计<br/>10 月上旬 · 本次作业"]
    B --> C["阶段三：基本校园循环<br/>10 月下旬至 11 月初"]
    C --> D["阶段四：代表系统与关键事件<br/>11 月"]
    D --> E["阶段五：内容整合与交付<br/>11 月至期末"]

范围控制（Scope）： 本次作业同时明确了主动不做的内容——Live2D 全动态立绘、全语音配音、联网功能与云存档、移动端适配、3D 场景与粒子特效、多语言本地化。把"不做什么"写清楚，比把功能清单写长更能说明团队理解了"工程"的含义。

1.3 本次作业的里程碑安排

本次作业周期为 10 月 9 日至 10 月 15 日，10 月 16 日课堂原型答辩，因此采用倒排方式安排里程碑：先锁定交付时间，再倒推每个节点的产出，最后才分配任务。本次作业按四人并行、组长指挥检查的方式推进。

里程碑	时间节点	交付成果	负责人
M0 计划与骨架冻结	10-14	内部推进计划、博客骨架、Word 样式、两份评审表结构、四包认领完成	叶全祺、林宇杰
M1 规则与结构定稿	10-14	需求目录与规则清单、类图草稿、页面结构与原型骨架、访谈与场景目录	陈材臻、连伟成、彭杰
M2 第一轮可检查产物	10-14	类图草稿与核心验收、主页面与代表事件草稿、访谈记录与代表场景、博客计划与风险初稿	全体
M3 初稿完成	10-14 至 10-15 上午	需求正文初稿（含 C 的场景）、原型初稿与截图、场景完整稿、博客初稿与 Word 初次合稿	全体
M4 完整稿	10-15 12:00 前	需求内容与验收修正稿、原型与原型 PPT 完整稿、需求 PPT 完整稿、Word 与博客完整稿	全体
M5 上传与链接	10-15 16:00 前	两份 PPT／PDF、需求 Word／PDF 上传完毕，原型链接与评审表链接可用	叶全祺、连伟成、彭杰
M6 博客发布与正式提交	10-15 18:00 前	博客发布，班级作业页面正式提交，保存提交时间与仓库记录	叶全祺
M7 原型答辩与需求答辩	10-16	界面原型答辩 PPT 与需求分析 PPT 现场讲述	林宇杰汇报，连伟成配合演示
M8 后续开发节点	10-23 / 10-30 / 11-06 / 11-13 / 11-20	基本校园循环 / 代表系统 / 关键事件 / 八周内容整合 / 交付候选版本	全体

说明： 12:00、16:00、18:00 均为团队内部目标，不是课程另设的截止时间。正式截止为 2026 年 10 月 15 日 23:59，内部节点与正式节点冲突时一律优先保证正式节点。

1.4 关键路径

本次作业的关键路径是：规则表 → 类图 → 需求正文第 3 章，以及页面清单 → 界面原型 → 需求文档原型章节。两条路径的公共上游是"规则表"，因此规则提炼被安排在最早完成。

flowchart LR
    R["规则表与需求目录<br/>陈材臻"] --> CL["类图与关系说明<br/>陈材臻"]
    R --> SC["用户场景与事件<br/>彭杰"]
    CL --> DOC["需求规格说明书正文<br/>陈材臻"]
    SC --> DOC
    P["页面结构与原型骨架<br/>连伟成"] --> PROTO["界面原型与截图<br/>连伟成"]
    PROTO --> DOC
    DOC --> W["Word 合稿排版<br/>叶全祺"]
    DOC --> PPT1["需求分析 PPT<br/>彭杰"]
    PROTO --> PPT2["原型答辩 PPT<br/>连伟成"]
    W --> BLOG["博客发布与提交<br/>叶全祺"]
    PPT1 --> BLOG
    PPT2 --> BLOG

每日节奏： 每 3—4 小时同步一次进度，任何成员遇到阻塞立即在群内报出，不把问题拖到最终合稿阶段。提交前由非主责人按检查清单逐条核对。

---

二、项目关键点、难点与风险分析

2.1 三个关键点

关键点一：规则的可计算边界必须先于界面确定。

《福大秋日狂想曲》不是纯剧情的视觉小说，它有一套需要玩家真正做取舍的数值系统：精力固定 3 点且不参与配点、开局点数分配给体能／学识／心情与资金档位、一次活动扣 1 点精力并推进一个时段、好感度 100 才是攻略资格。这类系统的特点是任何一处数值边界没定，界面就无法设计——精力到底是 3 还是 4，直接决定主页面要不要显示"剩余次数"；吃饭扣不扣精力，直接决定日终结算画面的分支。

我们的对策是把"确定规则"和"待定方案"严格分开：从玩法文档 v0.5 中把已经确定的规则提炼成统一规则表，作为四份交付物的共同依据；把尚未确认的数值集中标注为候选方案与演示值，写明"本次补到什么程度、由谁负责、后续如何确定"。能确定的不含糊，不能确定的如实标注，不把候选写成决议。

关键点二：剧情优先的系统检查不能被绕过。

本游戏的日终流程里有一串"必须有"的检查：早上和下午结束后的必要吃饭、精力不足时结束当天、心情低于 20 的提示、午夜到 0 的触发流程。这些检查的意义在于它们是叙事的一部分——吃饭是校园生活感的来源，低心情 CG 是情绪反馈的落点。如果玩家能靠某种操作顺序跳过它们，玩法设计就出现了漏网。

因此我们在需求阶段就把这些检查点整理成"前置状态—操作—预期结果"形式的验收标准，而不是等实现完再测试。先写清楚"什么情况下必须发生什么"，再去做界面。

关键点三：四份材料的口径必须一致。

本次作业的四个交付物由四个人并行制作：需求文档（陈材臻）、界面原型（连伟成）、需求 PPT（彭杰）、博客与 Word 合稿（叶全祺）。最容易出的问题不是谁做得差，而是同一个概念在不同材料里叫法不同、同一个数值在不同材料里不一样。

我们的对策是建立三份"单一事实来源"——统一规则表、术语表、需求编号表。所有材料在写作前先查规则表，合稿时由排版负责人统一核查一次术语与数值。这样助教抽查任意一项时，四份材料指向的是同一个答案。

2.2 五个难点与应对思路

难点	为什么难	我们的应对
精力、吃饭与日终检查的衔接	一天四个时段、每时段一次活动扣 1 点精力，但必要吃饭不占活动也不扣精力，精力不足又要提前结束当天——三套规则交叉，边界情况多，很容易出现"这一天到底还能不能行动"的歧义	把一天的完整流程画成状态顺序图，逐个时段列出"可行动／已吃饭／精力归零"的组合，对每种组合写明预期结果，再据此写验收标准
资金不足与强制打工	玩家可能把钱花到买不起饭。如果系统不给出口，游戏就会卡死；如果强制打工，又要说清什么时候触发、是否占用时段	明确"预算不足时拒绝该操作并提示"，并把资金不足的应对路径写进需求，作为边界需求单独编号，而不是留给实现阶段临时决定
小游戏的持久化与回退	小游戏三档评级、累计三次最高评级后可跳过且收益相同；同时小游戏次数跨周目保留、不随读档回退减少。这与"普通数据随存档恢复"是两套不同的持久化规则，极易实现成"读档把次数也退回去了"	在类图和需求中把"存档内数据"与"存档外数据"显式分成两类：时间、属性、餐次、事件与提示随存档恢复，图鉴和每个小游戏的最高次数独立于存档保存。这条差异单独写验收用例
考试作弊演出与恢复顺序	作弊按钮随错题数变大、心跳强度递增、作弊 CG 在十题结束后才出现，CG 之后玩家可以结束游戏或回到考试前——"回到考试前"要恢复到哪个时间点、已解锁的 CG 是否保留，顺序错了就会丢进度或重复扣费	明确恢复发生在考试扣除成本之前，已解锁 CG 一律保留；把"结束游戏"与"回到考试前"两条分支分别写验收标准
结局选择与双攻略方式未定	第七周最后一天选择最终对象、好感度 100 是资格线，但"A＋B 双攻略"的路径与最终选择方式尚未设计完成	如实标注为待定项，在需求文档与 PPT 中统一说明其未定内容与后续安排，不在交付材料中宣称已经完整设计或已实现
待定项范围很广，容易被误写成已定	玩法 v0.5 第 16 节列出的待定项覆盖开局总点数、精力成长门槛、课表与收益、小游戏清单与评分边界、各事件好感变化、考试时限与通过标准、餐品价格、失窃触发方式、自动保存时机等 17 类；四份材料只要有一处把候选值写成既成事实，答辩时就会被抓住	建立标记体系（已确定／暂定／示例／待定），所有材料在引用数值时必须带标记；原型使用演示值时明确标注性质；答辩口径与文档一致

2.3 风险分析与应对措施

下表只写本项目真实存在的风险。已经发生并处理过的，写处理过程；尚未发生的，用"可能"与"计划"表述，不写成已解决。

风险	影响程度	应对措施	负责人
精力与必要吃饭的衔接规则出现歧义，导致原型与需求文档对同一天的可行动次数说法不一致	高	先出统一规则表，由组长集中确认关键方案；四份材料一律引用规则表，不接受各自解释	陈材臻、林宇杰
资金不足时无出口，玩家可能卡在无法吃饭又无法结束当天的状态	高	把资金边界写成独立需求并配验收用例；在原型中给出"预算不足拒绝并提示"的受限状态	陈材臻、连伟成
小游戏次数被读档回退，破坏"三次最高后跳过"的设计意图	中	明确区分存档内／存档外数据；写成独立验收项，由非主责人交叉验证	陈材臻、连伟成
剧情优先与午夜检查的冲突——心情归零的午夜流程可能打断正在进行的关键剧情	中	明确优先级与触发时机，把两者顺序写进需求；未定部分标注为待定，不擅自决定	陈材臻、彭杰
考试作弊演出与恢复节点实现顺序错误，造成进度丢失或重复扣成本	中	在需求中锁定恢复时机与 CG 保留规则，作为验收标准的一条硬性判断条件	陈材臻、连伟成
结局选择与双攻略方式未定，若在材料中写成已完成，答辩时会被直接质疑	中	统一标注为待定项，说明后续安排；答辩口径与文档一致，不夸大	彭杰、林宇杰
多人并行导致材料口径不一（同一概念多种叫法、同一数值多处不一致）	高	建立统一规则表、术语表、需求编号表三份单一事实来源；合稿时由排版负责人统一核查术语与数值	叶全祺
上传与审核风险：华为云链接权限设置错误导致组外打不开；博客发布后进入审核显示 404	高	每份文件上传后用无痕窗口逐个验证链接；博客提前发布，若审核中显示 404，按作业允许的方式在截止前提交真实链接，不发布未完成博客占位	叶全祺
内部节点与正式截止冲突，为了赶内部节点而错过正式提交	高	内部节点一律服从 10 月 15 日 23:59 的正式截止；提交动作与博客发布分离记录，避免"只发博客忘记班级页面提交"	林宇杰、叶全祺
原型组外访问权限未验证，课堂演示时打不开	中	答辩前准备本地截图与录屏备份；演示前用其他设备实测一次链接	连伟成
范围膨胀——临近期末仍想增加功能	中	每次例会追问："本周新增的需求，要砍掉哪个旧的？"；明确本次不做完整游戏	林宇杰
成员投入度差异，部分成员课业冲突导致任务延期	中	任务卡明确负责人与截止时间；阻塞超过 24 小时升级为全组讨论，由组长协调有限补位，原负责人保留产物完整性责任	林宇杰

---

三、项目分工

3.1 组员分工与工作量比例

本次作业的分工按"交付物主责制"划分。团队先在群内公布四个任务包（A 需求与类图、B 原型与原型 PPT、C 访谈场景与需求 PPT、D 博客与材料整合），由四位成员自由认领；组长不占四个制作名额，独立负责指挥、检查与汇报。这样安排的好处是：每份交付物有且只有一名主责人，避免了多人同时改一份文件导致的版本混乱，同时组长能站在检查者位置而不是"自己也有一份"的位置上看材料。

学号	工作内容	贡献度
102400222	组长：项目指挥与排期、关键规则集中确认、三轮检查与回退、答辩汇报；玩法与系统设计文档撰写、本周答辩	20%
022401402	任务 A：需求规格说明书内容主责（引言、总体描述、功能与质量要求）、类图建模与关系说明、关键数值与边界方案、验收标准表	21%
102400219	任务 B：界面原型设计主责（页面结构、统一配色与按钮、可串联原型）、编号截图与页面交互说明、界面原型答辩 PPT	20%
162304124	任务 C：真实用户访谈与需求依据、用户场景正文、三位人物简表与八周概要、代表事件后果说明、需求分析 PPT	19%
102400230	任务 D：博客主笔与整体计划、风险与协作章节、Word 合稿排版与 PDF 导出、两份腾讯评审表、上传链接表与正式提交	20%
合计	——	100%

需求文档任务比例（单独统计，同样合计 100%）：

这张表与上表的统计范围不同，请勿混读： 上表统计的是本次作业全部交付物（需求文档、界面原型、两份 PPT、博客与合稿）中的工作量占比；本表只统计《需求规格说明书》这一份文档内部的任务占比。因此同一成员在两表中的数值不同是正常的——例如任务 D 在需求文档中的工作以合稿排版为主，其博客撰写、原型包整理与上传提交等工作不计入本表。两张表分别合计 100%。

学号	在《需求规格说明书》中的任务	比例
102400222	玩法规则来源文档撰写；关键未定规则的集中确认与终审	18%
022401402	需求正文、类图与关联建模、关键数值与边界方案、功能编号与验收表	28%
102400219	界面原型章节素材：编号截图、页面交互说明、界面规范	18%
162304124	用户场景、目标用户与需求依据、代表事件后果说明	16%
102400230	Word 合稿排版（封面、目录、页码、字体行距统一）、图表编号与题注体系、标题层级修正、验收与追踪表并入、引用核对与 PDF 导出	20%
合计	——	100%

比例的形成方式： 本次作业的四个任务包在启动前由四人自由认领，各包的交付物清单与完成标准在认领时即为公开约定，工作量本身经过有意均衡。因此团队在评议时采用接近均分、按交付物体量做小幅梯度的方式确定比例：以任务看板的任务点数（认领时全员估算，完成度按点数而非条数计）为主要依据，参考交付物实测规模与 Git 提交记录，再由五人共同确认。这一做法与选题阶段公开的绩效考核方案一致——考核数据全部落在既有的看板与周报上，不额外增加填表负担，成员可在结果公布后 24 小时内提出异议并由团队复核。

比例的计算依据见 4.6 节。整体贡献比例与需求文档任务比例**分别统计、分别合计 100%**。

3.2 每位成员的具体工作内容

林宇杰（102400222）｜组长 · 指挥与检查

1. 撰写《福大秋日狂想曲》玩法与系统设计文档，作为全组唯一的规则依据，并维护其版本更新记录；
2. 在群内发布四个任务包并完成认领，确定内部节点时间表；
3. 对关键未定规则集中确认，明确本次范围，防止四个人各自补规则；
4. 每 3—4 小时检查一次交付，协调阻塞与补位，优先保证必交材料；
5. 三轮检查：首次检查类图与原型流程，第二次检查完整文档与两份 PPT，最终检查链接与提交；
6. 汇总四位成员的讲述要点，准备现场汇报并试讲、控制时间；
7. 核对实际贡献与文档比例、发布记录、班级页面提交时间与华为云文件版本；
8. 负责本周答辩汇报。

组长的检查原则： 检查意见必须说明"哪里不一致、应由谁改、何时回交"，而不是把所有问题留给自己最后重写。组长不承担原型主制作、需求全文、博客主笔和 PPT 排版。

陈材臻（022401402）｜任务 A · 需求规则、类图与验收

1. 阅读玩法文档 v0.5，把已确定的规则提炼成需求，并补齐关键数值与边界方案（开局与属性、精力与日程边界、学习运动与赚钱、考试与外卖、恢复与保存）；
2. 第一轮先交统一规则表、需求目录与类图草稿，不等全文写完；
3. 编写引言、总体描述、功能要求、输入输出、可用性与安全性等质量要求；
4. 绘制正式类图，配属性、职责、关联和必要的多重性说明；
5. 将玩法检查点整理成"前置状态—操作—预期结果"形式的验收标准；
6. 接收 C 的用户场景、访谈与事件说明，接收 B 的原型截图及交互说明，检查需求内容完整；
7. 提供类图及需求摘要给 C 用于 PPT，提供需求评审维度与风险摘要给 D。

连伟成（102400219）｜任务 B · 界面原型与原型答辩 PPT

1. 依据玩法 v0.5 和 A 的规则表，先定页面结构、统一颜色与按钮，再制作可串联的原型；
2. 覆盖开局配点、日常主页面、课表与活动、学习运动打工、小游戏与结算、朋友圈、考试、外卖、最终选择及恢复入口；
3. 重点展示五条核心演示流程，次要页面复用布局，使用占位素材；
4. 导出编号截图，写清页面用途与操作说明，供 A、C、D 共用；
5. 制作界面原型答辩 PPT，重点讲界面结构、操作流程与反馈，并导出 PDF；
6. 提供原型链接与原型评审维度，检查组外访问权限；
7. 提供逐页讲述要点与本地截图备份。

彭杰（162304124）｜任务 C · 用户访谈、用户场景与需求分析 PPT

1. 联系真实目标用户进行简短访谈，保存实际记录；
2. 询问校园生活取舍、重复小游戏、条件选项、朋友圈线索、考试与外卖是否易理解；
3. 整理"用户反馈—采纳或不采纳—对应需求变化"，写目标用户与需求依据；
4. 撰写用户场景、人物身份及八周概要，采用统一格式，不写全部故事台词；
5. 与 A 确认事件、考试、外卖、心情与攻略的规则后果，提供 B 的代表事件示例文案；
6. 结合 A 的类图与验收、B 的原型截图制作需求分析 PPT 并导出 PDF；
7. 提供访谈摘要、当前进度与博客用文字。

叶全祺（102400230）｜任务 D · 博客主笔、排版、评审表与提交

1. 建立博客骨架与 Word 样式，先写整体计划、风险、协作方式与分工框架；
2. 收集 A／B／C 的摘要、截图、链接及实际工作记录，完成整篇博客；
3. 接收 A 的内容完整稿，完成需求 Word 合稿：目录、字体、行距、标题、图表、分工比例与引用统一，并导出检查 PDF；
4. 建立两份腾讯共享评审表，分别采用 A、B 提供的评审维度；
5. 收集两份 PPT／PDF 与需求 Word／PDF，上传华为云仓库要求的文件，整理最终链接表；
6. 收集四位制作者及组长的实际贡献，五人确认后填写博客贡献表与需求文档任务比例；
7. 将完整博客与材料交组长检查，通过后完成博客发布与班级作业页面提交，保存时间与仓库记录；
8. 处理审核期间的链接检查，反馈修改由对应制作人解决，自己同步最终版本。

---

四、成员协作方式

本次作业由四名制作者并行产出四份不同的交付物，加上组长负责指挥与检查，协作本身就是这次作业的主要难点之一。因此我们把协作方式写成明确约定，而不是靠临时沟通。

4.1 沟通工具与沟通节奏

场景	工具	约定
日常异步沟通、问题求助、任务报备	QQ 群 / 微信群	工作时段内 24 小时内回复与自己相关的消息；紧急事项直接 @ 对应负责人
每周例会、交付前同步	线上会议	每周固定一晚 30 分钟；议题提前一天在群内征集；会议产出备忘录并归档
文档协作与评审	腾讯共享文档	内部推进计划、里程碑排期、剧本协同定稿、素材登记共用一份，链接统一放群公告
任务与进度	GitHub Projects 看板	任务卡的唯一来源，同时也是绩效考核的数据来源
代码与文档托管	GitHub 仓库（Git + Git LFS）	仓库为唯一事实来源；本地文件不作为交付依据
演示材料与源文件	华为云仓库	两份 PPT、需求文档按要求上传，作为课程提交依据

例会制度： 例会的第一项固定议程是**"上次承诺的任务，完成情况如何"**——先对账，再讨论新内容。这条规则的价值在于它把"我说了要做"变成"我上次说了要做，现在来核对"，避免了例会开成纯讨论会。

本次作业的加密节奏： 由于本次作业周期只有约一天半，我们把同步频率从每周提高到每 3—4 小时一次，任何成员遇到阻塞立即报出。项目阶段内的这个临时调整由组长在群里说明，正式阶段恢复每周例会。

4.2 版本仓库协作

仓库与分支。 代码与文档统一托管在 GitHub，采用 Git + Git LFS（用于管理立绘、背景等大体积素材）。main 分支只保留可交付版本，任何中间状态不直接提交到 main；成员从 main 拉出功能分支开展自己的工作，完成后提交 Pull Request 申请合并。

合并门禁。 每次 Pull Request 必须由至少一名非作者的成员评审后才能合并，避免自审自合。评审重点看三件事：内容是否与统一规则表和术语表口径一致、是否引入未定义缩写、是否与已有章节重复或冲突。

目录约定。

rhapsody/
├── docs/            # 需求规格说明书、内部计划、会议记录
├── diagrams/        # 类图、流程图源码与导出图
├── prototype/       # 原型源文件、编号截图与页面说明
├── slides/          # 两份答辩 PPT 及导出的 PDF
├── script/          # Ren'Py 剧本（一章一文件）
└── README.md        # 项目说明与交付物索引

提交信息规范。 统一采用「类型: 内容」格式，便于按提交追溯每个人的工作量。

docs: 完成需求规格说明书第3章类图与关系说明
design: 完成主页面与开局配点页原型
slides: 完成原型答辩PPT初稿
fix: 修正验收标准中精力恢复时机的描述

文件结构约定（消除冲突的根本办法）。 本次作业的四份材料按制作人分开存放，一人一份、一人一章，从源头消除版本冲突：需求文档按章节拆分，每人只修改自己负责的章节，最后由排版负责人统一合并为 Word 成稿；原型画板按页面编号划分责任人。

4.3 冲突处理

文档冲突。 由于需求文档按章节拆分，两人需要修改同一章节时，先在群里说明修改范围再动手；合并时由排版负责人统一核查术语与数值，发现不一致直接回退到统一规则表确认。

原型冲突。 原型页面按编号划分责任人，每人只改自己负责的页面。若某次改动会影响其他页面（例如统一调整按钮样式或主色），先改设计规范，再由各责任人同步到自己的页面。

需求分歧。 当成员对某条需求是否该做、该怎么做产生分歧时，处理顺序是：先回到玩法文档与统一规则表寻找判断依据；如果仍然无法一致，由该交付物的主责人拍板，并把决策原因记录到 docs/ 下，格式为"背景、可选方案、最终决定、理由"，供后续复盘与答辩使用。本次作业中，关键规则（精力与日程边界、考试与外卖数值、恢复与保存时序）统一由组长集中确认，防止四个人各自补规则。

进度冲突。 如果某位成员的任务阻塞影响到下游（例如类图未定稿导致需求正文无法推进），阻塞超过 24 小时即升级为全组讨论，由组长协调其他人有限补位；但原负责人保留产物完整性责任，补位不等于转交。

4.4 任务同步机制

任务卡四要素。 看板每张卡片必须包含任务描述、负责人、截止时间、验收标准四项信息，缺少任意一项的卡片不允许进入"进行中"。

任务点数。 每张任务卡在认领时由全员共同估算点数（1 / 2 / 3 / 5 / 8），完成度按点数而非任务条数计算，避免"挑简单任务刷数量"。跨岗位之间用换算基准保证可比，例如：一张符合规范的背景图（含风格化与调色）＝3 点，一章剧本（约 1500 字，含分支与演出说明）＝5 点，一个完整的 UI 界面＝3 点，一个独立小游戏模块＝8 点。这张表的意义是让"画图"和"写代码"在考核里真正等价。

交接方式。 每次交接必须发五项信息：文件或链接、版本、已完成内容、待解决问题、接收人。这条约定直接针对多人交接最常见的失败——收到一个文件却不知道它是不是最新版、不知道还差什么。

沟通公约。

1. 24 小时内回复与自己相关的消息；
2. 卡壳超过 2 小时必须主动求助，不允许默默拖延；
3. 只对事不对人，评审意见必须给出具体修改建议而非单纯否定；
4. 任何需求变更都在群里公示，不私下拉人改方案；
5. 检查意见必须说明"哪里不一致、应由谁改、何时回交"，不把所有问题留给自己最后重写。

4.5 AI 协作规范（本项目的特色实践）

本项目有意采用 AI Coding Agent 辅助开发，团队真实经历了"从踩坑到建立约定"的过程。为避免"AI 生成看起来很对但实际跑不通"的内容进入交付物，我们制定了五条规范：

1. 仓库根目录维护项目约定文件，明确引擎版本、代码规范、禁止事项与交付要求，所有 AI Agent 开工前必读；
2. 任务以"任务卡"形式下发，卡内必须写明目标、输入、产出、验收标准；
3. AI 生成的所有代码必须通过 renpy lint 检查并经人工评审才能合并，未跑检查的产出一律不合并；
4. 状态管理与分支路由等核心模块由人类编写，AI 负责实现重复度高的内容；
5. 记录并归档 AI 协作中的失败案例（如生成不存在的接口、写错存档逻辑），作为团队经验沉淀。

这套规范在本次作业中同样适用：需求文档、原型说明与 PPT 中的每一条数值和每一条规则，都必须能追溯到玩法文档或统一规则表，不能因为"表述通顺"就采信。

4.6 贡献度如何做到可追溯

博客中给出的工作量比例来源于三类客观记录：

1. 任务看板卡片的完成情况（按任务点数计）；
2. Git 提交与 Pull Request 记录；
3. 成员互评结果（每人给其余四人打 1—5 分，去掉一个最高分与一个最低分后取平均）。

三者出现不一致时，以任务看板与 Git 记录为准；成员可在结果公布后 24 小时内提出异议，由团队共同复核。贡献比例在提交前由五位成员共同确认，整体贡献与需求文档任务比例分别统计、分别合计 100%，不预填固定百分比。

关于流程轻量的说明： 我们讨论过"五人小团队是否需要这么多维度"，最终共识是维度保留，但记录尽量轻量——所有考核数据都落在既有的看板与周报上，不额外增加填表负担。

---

五、软件需求规格说明书

《需求规格说明书》链接： 华为云仓库 Word 版｜PDF 版

5.1 文档结构

文档参考 GB/T 9385—2008《计算机软件需求规格说明规范》 组织，同时参考 ISO/IEC/IEEE 29148:2018 的需求工程范围说明。两份规范均为公开可查版本（查询日期 2026 年 10 月 15 日），文档中记录了引用版本与适用限度——没有虚构条款编号，也没有在未获取标准全文的情况下声称逐条满足。

章节	内容
1 引言与依据	目的与范围、资料来源与版本关系、规范引用与适用限度、术语与编号
2 总体描述与需求范围	产品环境与参与者、本期与后续范围、核心循环与约束
3 用户场景候选稿	SC-01 至 SC-12 共 12 个场景
4 功能要求与编号目录	13 个特性分类、96 条功能需求（FR）
5 接口输入输出与质量要求	外部界面与接口、核心输入处理输出、数据与质量基线
6 分析类图与数据说明	建模边界、关联与多重性、保存与派生数据
7 原型接入与完整性检查	UI-01 至 UI-10 的接口映射与评审内容
8 验收与追踪	检查点版本区分、核心验收摘要、验收执行规则
9 统一规则候选方案	TBD-01 至 TBD-26
10 团队交接与进度	当前可交付内容、工作顺序与责任、合稿核对
11 访谈附录与未关闭事项	C 材料接入模板、关键未关闭事项、修订记录
附录	三张正式类图、需求追踪矩阵、待定清单、源文档差异

5.2 用户场景

需求文档整理了 SC-01 至 SC-12 共 12 个用户场景，全部采用统一格式书写六要素：用户目标、前置条件、触发方式、正常步骤、异常或分支、最终结果。场景覆盖开局选择、上课与自习、运动与跳过、赚钱与餐费、B 课堂事件、线索与错过、正式考试与补考、作弊与恢复、外卖与提示、低心情与午夜、最终选择、存读档与体验。

这里必须说明一点： 文档中明确标注这些场景是依据设计构造的候选用例，不冒充用户访谈结果。真实访谈由任务 C 完成并接入替换。我们认为把"构造的场景"和"访谈得到的场景"混为一谈是不诚实的，因此选择显式区分——在 C 的真实访谈接入前，这是我们能给出的最诚实的表述。

5.3 类图

模型规模：23 个分析类、27 条关联，分为时间活动、人物事件、考试外卖存档三个主题视图，避免把一张图塞到无法阅读。类图提供三种格式：.mmd 源文件（可粘贴到支持 Mermaid classDiagram 的编辑器继续编辑）、.svg 矢量图（可编辑）、.png 位图（可直接插入 Word 与博客）。

建模边界（这是类图设计最关键的几个决定）：

1. 类图只描述业务领域职责，不是技术架构图。 文档明确写明"不要求实现时创建与分析模型同名的 Python 类"——属性与方法代表领域职责，可映射成 Ren'Py 的 default 变量、字典、配置表和函数。
2. 角色 A、B、黄毛是「人物」的实例，而不是仅仅三个类。 这一条直接回应了"类图不能只画三个可攻略人物"的要求。
3. 「跨周目档案」不能被「游戏进程」组合拥有。 否则开始新周目时会错误清除图鉴与小游戏记录——这是从需求层面提前堵住的一个真实缺陷。
4. 「存档快照」保存的是普通状态的值快照，不是运行对象指针，也不包含跨周目记录的回滚副本。

23 个分析类（节选关键类与职责）：

分析类	主要职责
游戏进程	组织一局流程，统一结算与控制终止
主角状态	维护体能、学识、心情、生活费与精力，约束取值
游戏时间	推进八周日历并派生周次
课程安排 / 活动配置	定义课程、场景、开放时段与成本
活动尝试	记录一次活动，防止重复发奖
日内节点	记录必要吃饭、连续上课与精力成长
小游戏配置 / 小游戏累计记录	定义评级映射；按游戏累计最高次数并防重复登记
人物 / 人物关系	统一人物身份（合并 A 的网友与室友双重身份）；维护好感度
事件配置 / 事件进度 / 剧情选项	事件窗口与优先级、完成与错过状态、条件判定与分支影响
朋友圈动态 / 动态已读状态	线索发布与红点所需的已读记录
考试尝试 / 试题	限时答题、作弊标记与整场结算
外卖订单 / 失窃与提示进度	付费、备注关键词、餐次与配送结果；区分真实失窃与两类提示
最终选择	计算候选资格并确定结局
存档快照 / 跨周目档案	普通状态恢复；图鉴与小游戏记录跨周目保留

关联与多重性（节选）：

起点类	多重性	关系	终点类	多重性	关联职责
游戏进程	1	组合	主角状态	1	包含
游戏进程	1	组合	活动尝试	0..*	记录
游戏进程	0..*	关联	活动配置	0..*	使用配置
游戏进程	1	组合	人物关系	0..*	包含
事件配置	1	组合	剧情选项	1..*	提供
考试尝试	0..*	关联	试题	10	选取题目
存档快照	0..*	关联	游戏进程	1	保存普通状态副本
游戏进程	0..*	关联	跨周目档案	1	共用玩家档案
跨周目档案	1	组合	小游戏累计记录	0..*	包含

保存与派生数据的建模处理： 小游戏最高次数、已提交最高记录的 attemptId 集合、CG 与结局解锁归「跨周目档案」，跨周目保留；attemptId 在活动开始时生成并随该活动普通状态保存，不因回退到同一结算点重新生成。跳过资格派生自最高次数 ≥ 3，不另存一个可能冲突的布尔值。周次与星期由 dayIndex 派生，不再维护单独的已行动时段统计栏。活动结算、扣费、发奖与日程推进以一次事务提交，失败则恢复进入前的普通状态。

三个主题视图：

图 5-1 时间活动类图：游戏进程、主角状态、游戏时间、课程安排、活动配置、活动尝试、日内节点。

图 5-2 人物事件类图：人物、人物关系、事件配置、事件进度、剧情选项、朋友圈动态、动态已读状态。

图 5-3 考试外卖存档类图：考试尝试、试题、外卖订单、失窃与提示进度、最终选择、存档快照、跨周目档案、小游戏累计记录。

5.4 功能需求与编号

功能需求采用唯一编号 + 属性的方式组织，编号规则为 FR / IR / PR / DR / CR / QR - 模块 - 序号（分别对应功能、接口、性能、数据、约束、质量属性），每条需求带四项属性：

属性	取值
优先级	高（原型版）· 中（正式版）· 低（增强版）
稳定性	稳定 · 可变（规则已定、数值待定）
验证方式	T 测试 · D 演示 · I 检查 · A 分析
来源	玩法与系统设计文档的章节号

规模： 共 163 条已编号需求，其中 96 条功能需求（FR） 分布在 13 个特性中，另有 67 条接口、性能、数据、约束与质量属性需求。

特性	条数	特性	条数
吃饭外卖	11	剧情事件	7
好感结局	11	考试补考	7
时间精力	10	开局配置	6
场景活动	8	心情检查	6
小游戏	8	朋友圈	5
存档图鉴	8	作弊支线	5
赚钱	4

按优先级分布：高 54 条（对应原型版）、中 40 条（对应正式版）、低 2 条（E04 双攻略与 E05 黄毛结局）。按稳定性分布：稳定 51 条、可变 45 条——"可变"表示规则已定但数值待定，这些待定数值集中放在配置模块，避免改动剧情脚本（对应设计约束 CR-10）。

5.5 输入输出与质量要求

核心功能的输入—处理—输出（以三条代表功能为例）：

功能	输入	处理	输出
开局配置（FR-INIT）	体能、学识、心情的分配点数；生活费档位选择	校验是否为负预算，二次确认剩余点数	初始属性、初始生活费、固定 3 点精力
活动与结算（FR-TIME / FR-ACT）	当前时段、所点活动入口	校验开放时段与精力成本 → 执行小游戏或剧情 → 单次事务结算	属性或资金变化、时间推进、统一结果反馈
考试（FR-EXAM）	开考学识快照、每题选项、作答时间	按快照锁定三档难度 → 逐题计时判定 → 整场统一结算	答对题数、通过与否、心情与 B 好感变化

性能指标（可度量、可测试）：

指标	目标值	编号
启动到主界面	≤ 10 s	PR-01
界面切换响应	≤ 1 s	PR-02
帧率（小游戏、考试）	≥ 30 帧/秒	PR-03
考试计时误差	≤ 0.1 s	PR-04
存档 / 读档	≤ 2 s	PR-05
网络请求	0（不访问互联网、不收集上传数据）	IR-COM-01

其余质量属性：可靠性（存读档后全部状态一致、所有分支可达）、可用性（首次引导、单行台词 ≤ 40 字、限制有提示）、安全合规（不收集数据、AI 素材标识、授权登记）、可维护性（需求编号进任务卡、状态代码人工评审）、可移植性（Win10/11、1920×1080 与 1366×768、Web 版）。

设计约束（节选）： CR-01 锁定 Ren'Py 8.5.3、不使用 nightly；CR-03 单个 .rpy ≤ 400 行、函数只放 game/logic/；CR-04 好感变更统一走 add_aff()、分支判定只在 route.rpy；CR-09 合并前 renpy lint 无 error 并试玩；CR-10 待定数值集中配置，剧情只引用常量。

一条容易踩的技术坑被写进了需求： Ren'Py 最经典的错误是把状态写在 init python 里，导致存档保存不住。因此数据需求 DR-13 明确规定所有普通存档变量必须用 default 声明。

5.6 验收验证标准

验收标准共 76 条，全部采用"前置状态 — 操作 — 预期结果"三段式书写，并保留需求编号与来源。文档明确声明：**产品尚未实际运行，因此全部验收的执行状态均为"未执行"**；基线验收用于核对已转述的规则，候选配置验收只有在候选数值获得团队确认后，才能作为正式判据。

检查点的版本区分（一个容易被忽略但很重要的处理）： 玩法文档 v0.4 有 16 个 CHECK，现有 SRS 转述的 v0.5 有 22 个 CHECK，两套编号含义不同，追踪时必须标明版本。文档统一采用 SRS V1.0 的 22 点，并声明"不声称已经看到 v0.5 原表"。

22 个检查点全部映射到需求编号，例如：CHECK-01 → FR-INIT-01~05、CHECK-07 → FR-MG-02/05/06、CHECK-18 → FR-MOOD。

验收摘要（节选）：

检查点	前置状态	操作	预期结果
CHECK-01	进入开局配置	尝试给精力加点	精力固定 3 点不可配；属性与资金档位共用同一预算，剩余点数为负时禁止确认
CHECK-02	处于某一时段	选择一次活动	消耗 1 点精力并推进时间；不能空过时段，不能在同一时段重复获益
CHECK-04	早上时段活动结束	进入下一时段	触发必要吃饭；不扣精力、不占时段；须支付生活费
CHECK-07	某小游戏最高评级累计不足三次	完成该小游戏	按正常流程游玩；累计达到三次后出现跳过选项，成本相同、收益为最高档
CHECK-08	已累计最高评级次数	读档或回退	次数不减少；右下角展示的次数信息与跳过资格保持
CHECK-14	考试中首次答错	观察界面	出现黑色作弊按钮；错题越多按钮越大并有心跳声；仅主动进入作弊支线才触发作弊 CG
CHECK-18	心情低于 20	推进到午夜	低于 20 时有提示；午夜为 0 才触发 CG；可读档或回退，CG 解锁保留在图鉴
CHECK-21	完成一天	查看存档	每天自动保存一次，总容量 36；普通状态随读档恢复，图鉴与小游戏记录不回退

5.7 需求管理与版本冲突处理

双向追踪矩阵。 所有 22 个检查点全部映射到需求编号，没有遗漏。向后：每条需求标注玩法设计文档的来源章节；向前：需求编号写入任务卡与提交说明。这样助教抽查任意一条需求，都能定位到它的来源与验收方式。

26 项待定事项（TBD）。 每个待定项登记影响的需求编号与关闭条件，而不是擅自补一个数字。分布为：考试与作弊 5 项，学习与场景 4 项，开局与精力、日程与事件、赚钱、结局与好感各 3 项，吃饭外卖 / 心情 / 朋友圈 / 小游戏 / 存档各 1 项。

源文档差异表（本次需求分析中最有价值的一节）。 团队早期技术稿与玩法文档存在实质冲突，需求文档逐条登记并以玩法文档为准：

项目	早期技术稿	需求文档采用
分支时机	第 3 章末分叉	第七周末最终选择
攻略阈值	好感 ≥ 60	好感达到 100
结局配对	未攻略者必归黄毛	不采用固定配对
黄毛线	隐藏 IF 线	E05 为主结局之一
小游戏记录	未提及	跨周目保留

处理原则写得很明确： 不擅自补数、冲突以玩法文档为准、建议同步修订技术设计稿，不得把两版规则拼在一起。

五种主结局与两个额外终止节点（编号体系）：

编号	结局	优先级
E01	全失败（独自生活）	高
E02	攻略 A	高
E03	攻略 B	高
E04	攻略 A、B（双攻略，规则待设计）	低
E05	攻略黄毛	低

此外 F-CHEAT（作弊失败） 与 F-MOOD（低心情终止） 是额外终止剧情节点，不纳入五种主结局的数量——这一点单独登记，正是为了避免"PPT 上写五种结局、图鉴里却有七个"这类口径混乱。好感达到 100 只是获得攻略资格，最终还要由第七周最后一天的显式选择决定；多人同时达标不自动合并结局。

5.8 需求分析过程中的设计思路、问题与解决方式

设计思路。 我们没有直接照抄设计稿，而是走了一条五步链路：源文档 → 规则抽取（区分已确定／暂定／示例／待定）→ 条目化（唯一编号、优先级、稳定性、验证方式）→ 追踪（检查点 ↔ 需求编号）→ 待定管理（影响范围与关闭条件）。目的是让每一条需求都能被第三方验证，而不是"读起来很完整但没法判断做没做完"。

问题一：设计稿有多个版本，且互相冲突。 玩法附件实际是 v0.4，而现有 SRS 声称引用 v0.5 却未提供原文；早期技术稿的分支时机、攻略阈值、结局配对与最新玩法完全不一致。解决办法： 建立"资料来源与版本关系"一节，逐份登记资料编号、版本、日期与冲突项，明确"团队确认的决议高于本稿候选数值；没有决议的项目保持候选状态"，并在附录单独列出源文档差异表。冲突登记而不静默覆盖，是这一节存在的意义。

问题二：需求描述过于模糊，无法验收。 初稿里出现过"系统要快速响应""精力不足时结束当天"这类无法判定的表述。解决办法： 把主观描述翻译成可测量的指标（响应时间、帧率、计时误差）或可判定的状态组合（前置状态—操作—预期结果），并给每条需求标注验证方式（测试／演示／检查／分析）。

问题三：待定数值散落各处，容易被当成已确定。 玩法文档本身有 17 类待定项，如果四个人各自补一个数字，材料立刻自相矛盾。解决办法： 集中建立 26 项 TBD 候选表，每项写明候选规则、影响需求、方案理由与边界、评审状态；并在需求属性里用"稳定性：可变"显式标记"规则已定、数值待定"。同时在设计约束里加一条 CR-10：待定数值集中配置，剧情只引用常量，让数值调整不波及剧情脚本。

问题四：类图容易画成技术架构图。 初稿类图里混入了与业务无关的技术组件，导致类图与需求对不上。解决办法： 先冻结术语与业务实体清单，明确类图只描述业务领域职责，并给出"属性与方法可映射成 Ren'Py default 变量、字典、配置表和函数"的说明；三个主题视图拆图保证可读性；对「跨周目档案」的归属单独论证。

问题五：构造的场景容易被误认为真实访谈。 解决办法： 在文档中显式声明场景为"依据设计构造的候选用例，不冒充用户访谈结果"，并预留 C 材料接入模板；同理，原型章节中 B 尚未提交的页面一律标注"待 B 提交"，不使用需求分析 PPT 中的示意图充当已完成的可操作原型。

---

六、界面原型设计

界面原型链接： 界面原型包（华为云仓库）

说明： 原型为单文件离线网页——下载解压后双击 prototype/index.html 即可运行，无需联网、不依赖服务器、不加载任何外部素材。包内另含 34 张编号截图、5 段流程录屏、界面规范与验证记录。公网在线地址尚未部署，因此本链接为可下载的原型包，下载与运行方式见包内《包说明.md》。

原型源文件与备份： 原型包（含可编辑源码 app.js、规则参数 rules.json 与编号截图）——单文件离线入口 prototype/index.html + 可编辑源码 app.js，另附 34 张编号截图与 5 段无配音录屏。

6.1 设计目标与设计原则

界面原型要回答一个问题：一个完全没参与过这个项目的人，能不能在不看说明书的情况下，理解"今天能做什么、为什么有些入口点不了、做完之后发生了什么"。

《福大秋日狂想曲》的界面难点不在视觉，而在规则表达：精力只有 3 点、一天四个时段、必要吃饭不占行动、有些入口只在特定时段开放、有些条件不足时允许尝试失败。因此原型确定了四条设计原则：

1. 一个循环，补齐每一个必要节点。 全站按"查看状态 → 选择行动 → 交互与反馈 → 返回日常"组织，自动剧情与必要吃饭不额外消耗精力，日终不能绕过餐次或心情检查。
2. 条件与反馈都能读懂。 硬性条件不足时入口灰显并说明原因；而"允许尝试"的分支（如 B 课堂事件的帮助选项）不禁用，因为失败本身就是设计的一部分。
3. 状态真实、口径标注。 界面严格按已确认规则表现状态，候选数值显式标注为提案，不做成既成事实。
4. 占位但可替换。 素材使用色块、图形与文字标识，人物与 CG 都可独立替换；不使用外部美术素材。

6.2 页面结构

模块	必须表达的内容
开局配置	总初始点数；体能、学识、心情的分配；生活费档位及点数成本；精力固定 3 点不可配
日常主页面	周次、四时段、精力与活动入口；角落朋友圈按钮及更新红点
教学楼 / 课表	有课上课、无课自习、周末无课；不同课程收益由玩家尝试发现
图书馆 / 球场 / 操场 / 宿舍	各自入口、1 点精力成本与结果；午夜不开放
打工	麦当劳仅早上／下午入口；家教学识门槛；资金不足时必须打工的反馈
小游戏	键鼠操作、三档评级、奖励、右下角次数、累计三次最高评级后的跳过
第二周代表事件	B 回答不出问题、学识门槛、帮助成功加好感、失败后黄毛解围
朋友圈与事件反馈	动态、红点、下一周室友口述错过的事件
第六周考试	十道题、每题三个选项、题旁闹钟、三档难度；主页面体验入口
作弊支线	错题出现并放大的黑色按钮、心跳音效、结束后 CG 与两个结果选项
必要吃饭 / 外卖	早上与下午结束后的食堂／外卖选择；多餐品、价格、自由备注、两个关键词、失窃电话与角色提示
心情	低于 20 提示、午夜为 0 的心情 CG、读档回退入口
最终选择与章节	第七周最后一天选择对象；第八周两种标题
主菜单、图鉴与存档	事件查看、图鉴、36 档容量、普通档与跨周目记录的区别
恢复页	集中读档、回退与体验入口

具体界面可合并，不要求每一行成为独立页面。原型共整理 UI-01 至 UI-17 加 IR-UI-01，对应 34 张编号截图。

6.3 五条核心演示流程

原型允许通过顶部演示状态入口切换快照，不要求现场从第一周连续玩到第八周。演示入口说明用途，不当作正式玩法入口；切换快照只重置演示区，正常存档与档案不受影响。

流程	演示步骤	核心反馈
① 日常与配点	开局 → 三属性各 4 点、1500 档 → 确认余 4 点 → 上课 → 继续 → 吃饭 → 下午活动 → 吃饭 → 晚上活动 → 继续	初始精力 3 不可配；两餐不扣精力；无空过；精力耗尽走完整日终
② 代表事件与条件	判定 29 快照 → 参加课 → 帮助；再切换判定 30 快照 → 参加课 → 帮助 / 拒绝	先结算课堂学识再判定；不足仍可尝试并失败，黄毛解围；成功 B 好感提升；只扣本课成本
③ 小游戏与打工	篮球 2/3 → 五次绿区点击 → 优秀 → 回退到普通状态 → 跳过；麦当劳五单按薯条／汉堡／饮料／薯条／汉堡	最高评级累计三次解锁跳过；回退次数不减；跳过拿最高收益、同成本、不增加实际次数；各项目独立计数
④ 考试与恢复	第六周快照 → 首考 → 首次错题 → 出现黑色作弊按钮 → 主动选择 → 完成十题 → CG 两种选择 → 回到考前；第七周补考快照	每题限时三选一、难度按开考快照锁定；主动作弊才触发 CG；正常失败按整场结算一次；恢复在扣成本之前且已解锁 CG 保留
⑤ 外卖、心情与结算	外卖初始 → 未入柜失窃两次 → 备注"多一点，放外卖柜" → 对比午夜心情 1 与 0 → 午夜前刷抖音恢复 → 最终多人达标的显式选择	初期不主动泄露解法；两次提示各执行一次；入柜安全、"多"成功额外收益；只有 0 才在午夜终止；好感达标才有资格、第八周两种标题

6.4 界面规范

配色采用"校园手账"方向，全站统一：

用途	色值	约定
正文与主导航	#25283B	深墨色，高对比
主要操作	#ED7358	珊瑚色，用明确动词，不只写"确定"
阅读背景	#FBF6EA	暖米白
一般状态	#C7E5D9	鼠尾草色，标签须伴随文字
提示	#F3D879	暖黄，用于参数提案或评审提示
边框	#D7CCBB	卡片与次按钮

组件与排版约定： 主／次按钮、卡片、条件标签、结果提示、属性行与计数器全部复用；最高奖励次数固定在小游戏操作区右下角，按每个小游戏分别记录、结算时即时更新；不可用状态必须解释原因；中文标题采用宋体风格、正文采用清晰无衬线中文，使用本机已有字体以支持离线。原型截图约 1600×1000，答辩演示按 16:9、1920×1080 等比缩放。

6.5 原型界面展示

开局配点： 属性与资金在同一预算内取舍，精力固定 3 点不参与配点，余点需要二次确认。

日常主页面： 顶部为演示状态入口与快照信息，左侧为主要页面导航，中间是"今天去哪里"的行动枢纽，右侧显示人物关系与精力成长状态，角落为朋友圈入口（有更新时显示红点）。

课表、场景与赚钱： 课表决定入口，收益通过尝试发现；麦当劳仅早上／下午开放，家教需要学识门槛。

第二周 B 课堂事件（代表事件）： 先结算本课学识，再决定是否帮助 B。学识不足时选项不禁用——仍然可以尝试帮助，然后走失败分支由黄毛解围。

小游戏与结算： 五次操作决定评级，三档分别对应三档收益；右下角显示最高评级累计次数。

累计三次最高评级后的跳过： 跳过不省时间与精力，只省操作，但收益按最高档结算，且不增加最高次数。

朋友圈： 线索有时效，错过也有解释。动态与事件开放时间对应，红点表示未读，历史动态过期后标记为已结束；不做点赞、评论、私聊，朋友圈不是补做错过事件的入口。

第六周考试： 每题三个选项、题旁闹钟计时，难度按开考时的学识快照锁定，整场不再换档。

作弊支线： 首次答错后出现黑色作弊按钮，错得越多按钮越大、心跳声越响（可静音）；主动选择作弊后继续答完十题，结束时才进入 CG，并提供"结束游戏"与"回到考试前"两个明确选项。

外卖与失窃提示： 备注为自由文本，但系统只识别两个关键词；失窃提示逐步给出——第一次通过外卖电话，第二次通过角色剧情，初期不主动泄露"外卖柜"这个解法。

第八周与结局： 第七周最后一天作出最终选择，第八周按结果确定章节标题。

图鉴与存档： 图鉴与事件查看入口在开始游戏主界面；普通存档恢复数值与进度，图鉴解锁与小游戏次数作为两类存档外记录不回退。

6.6 状态与边界设计

原型的完整度主要体现在异常与边界状态上，这些是本轮重点补充的部分：

状态	界面表现
条件不足（硬性）	入口灰显并说明具体原因
条件不足但允许尝试（B 事件）	不禁用，允许失败并走对应分支
精力耗尽	走完整日终流程，按序补执行未完成的吃饭、到期剧情、午夜检查与保存，不提供空过按钮
资金不足	预留未完成餐费，消费前校验；不足时拒绝并提示，提供强制打工或恢复出口
安全结算	"继续"实际执行必要节点，不能绕过
存档中	活动动作帧与答题计时中禁止存档；正式考试不能暂停或跳过
损坏档	提示更换，不覆盖当前状态
终止型 CG	不自动推进次日，不覆盖安全自动档
体验模式	主页面考试体验进入状态副本，免费、不推进时间、不改动正式进度，入口显式标为"体验"
存档外记录	读档不回退图鉴与最高次数

6.7 原型的交付与交接

交付物	内容
原型本体	index.html 单文件离线入口 + 可编辑源码 app.js + 规则参数 rules.json
编号截图	34 张，与 UI 编号一一对应，含页面总览
流程录屏	5 段 WebM，分别对应五条核心流程，无配音
原型答辩 PPT	16 页，含每页备注与讲稿（8—10 分钟）
逐页讲述要点	16 页脚本，含每页建议秒数
页面交互说明	五条流程的演示步骤、UI 编号到截图编号的映射、恢复约定
评审维度	供 D 建立原型评审表的十个维度
验证记录	布局验证（1366×768 与 1920×1080）、本机访问验证、核心流程验证
追踪材料	需求到原型追踪表（FR → UI → 截图 → AC）

6.8 交付边界（如实说明）

为了保证材料诚实，以下内容我们明确声明尚未完成或尚未验证，不冒充已完成：

1. 全八周剧情事件与通用多事件优先级队列尚未完成；
2. 正常游玩路径下好感 100 的完整可达性尚未验证；
3. E04 双攻略与 E05 黄毛线的正式剧情未交付，页面中标为延期；
4. 真实用户访谈尚未接入（由任务 C 完成）；
5. Ren'Py 的历史记录 / 自动播放 / 跳过已读等引擎功能属实现阶段工作，原型不冒充已完成；
6. 真实 Windows 成品、性能指标与 0.1 秒计时误差尚未验证；
7. 公网发布与真实组外设备访问权限尚未验证——本地文件路径不等于公网分享链接。

此外需要说明一个材料层面的细节：原型答辩的 PDF 是纯位图导出（无文字层），因此阅读文字请以同名的 .pptx 为准，PDF 作为图片版备份使用。这一点我们也如实写在交付说明里，避免评审时误判为文件损坏。

原型自动检查覆盖的是本网页的候选行为（72 项原型检查），不等于需求文档中 76 条正式验收全部通过，实际数量以验证记录为准。

---

七、需求分析 PPT 链接

需求分析 PPT 链接： 华为云仓库 PPTX 版｜PDF 版

PPT 共 27 页，按"项目概述与方法 → 总体描述 → 功能需求 → 非功能需求与约束 → 需求管理"五部分组织：

页码	内容
1	封面：需求分析 · 软件需求规格说明书汇报 · 依据 GB/T 9385—2008
2	汇报提纲（五部分）
3	项目概述：八周校园生活养成式视觉小说；8 周 / 4 时段 / 3 对象 / 5 结局 / 36 存档 / 163 条已编号需求
4	编写依据与方法：从设计稿到可验证的需求（源文档 → 规则抽取 → 条目化 → 追踪 → 待定管理）
5	分节页：02 总体描述
6	系统环境：单机运行、不联网的独立产品；依赖 Ren'Py 8.5.3；两类本地数据
7	用户与用例：14 个用例、四类用户（普通玩家 / 多周目玩家 / 课程评审者 / 开发与 AI 代理）
8	分节页：03 功能需求
9	功能需求全景：13 个特性、96 条需求；高 54 / 中 40 / 低 2；稳定 51 / 可变 45
10	核心循环：一时段一次活动、精力决定一天能做多少、必要吃饭不占行动、午夜检查与自动保存
11	开局配置与五项属性：同一预算内权衡（精力固定 3 点不可配）
12	场景、活动与赚钱：同类活动收益一致，课程差异保留；资金不足必须打工
13	小游戏：三档评级、成本不重复扣、按游戏分别计数、三次最高后可跳过、跨周目保留
14	吃饭与外卖：备注只认两个关键词；失窃后的逐步提示三步
15	剧情事件与朋友圈：代表事件 EVT-W02-B-CLASS 的完整链路
16	期中考试与作弊支线：十题 / 三选项 / 三档难度；错得越多诱惑越大
17	心情与午夜检查：两条阈值（低于 20 提示、午夜为 0 触发）、一次检查
18	好感与结局：好感 100 获得资格，第七周末最终选择，五种主结局
19	存档与图鉴：哪些会回退、哪些永远保留（default 与 persistent）
20	分节页：04 非功能需求与约束
21	逻辑数据模型：15 个实体，按存档类别区分（普通存档 / persistent）
22	性能与质量属性：可度量、可测试
23	分层结构与设计约束
24	分节页：05 需求管理
25	需求追踪：22 个检查点全部映射到需求编号
26	待定事项与源文档差异：明确"不知道什么"（26 项 TBD 分布 + 早期技术稿与玩法文档的冲突对照）
27	下一步：认领 26 项 TBD、以高优先级 54 条交付原型版、按检查点走查并回写 SRS V1.1

本轮 PPT 的重点不在于"我们做了多少"，而在于"我们知道什么、不知道什么"。 第 26 页专门用来说明待定事项的分布和源文档之间的冲突，这在答辩中反而是最能体现工程素养的一页。

---

八、界面原型设计答辩 PPT 链接

界面原型设计答辩 PPT 链接： 华为云仓库 PPTX 版｜PDF 版（含文字层，可检索）

PPT 共 16 页，围绕"设计原则、页面结构、关键路径、状态与边界、交接评审"组织，每页均带备注讲稿，预计讲述 8—10 分钟：

页码	内容
1	封面：把秋天，写进每一次选择
2	页面结构：同一个循环，补齐每一个必要节点
3	需求来源与差异：按统一规则表修订，候选状态保留
4	视觉规范：颜色统一，条件和反馈都能读懂
5	开局配点：属性与资金一起取舍
6	日常与精力：日常不空过，精力成长次日生效
7	课程、宿舍与赚钱：课表决定入口，收益通过尝试发现
8	第二周 B 课堂事件：先结算课堂学识，再决定如何帮助
9	小游戏与打工：五次操作看评级，三次最高再减负
10	朋友圈与事件状态：线索有时效，错过也有解释
11	十题考试与补考：难度按开考快照锁定
12	作弊与考前恢复：作弊是主动选择，CG 在十题后出现
13	外卖、失窃与餐费：两种关键词，按字面各生效一次
14	心情、最终选择与标题：低于 20 提醒，午夜为 0 才终止
15	36 格存档与图鉴：恢复普通状态，保留跨周目成果
16	交接与评审：五条路径按快照顺序演示；72 项原型检查与 76 条正式验收的区别

答辩演示顺序： ① 日常与配点 → ② 课堂事件与条件 → ③ 小游戏与打工 → ④ 考试作弊与恢复 → ⑤ 外卖心情与结算。操作异常时切换到编号截图 / PDF / 录屏作为备份。

---

九、小组评审表

按照作业要求，每个小组需要提交本次作业的简易评审表，内容包括小组名称、项目名称、评审的内容、评审建议，以及各小组名称和排名，采用腾讯共享文档填写。

评审表	链接
界面原型设计评审表	腾讯共享文档 · 评审表_界面原型设计
需求分析评审表	腾讯共享文档 · 评审表_需求分析

9.1 评分维度

两份评审表在上一阶段《报告评审表》模板基础上调整评分维度，各维度均要求给出具体评审建议，不只给分数。

界面原型设计评审表按以下五个维度评分，每维度 20 分，合计 100 分：

维度	分值	评什么
信息架构	20	页面划分是否清晰、导航是否可预期、主链路是否顺畅
页面完整度	20	是否覆盖核心场景、状态（空/加载/错误/无权限）是否完整
交互设计	20	按钮去向是否明确、反馈是否及时、边界情况是否有出口
视觉规范	20	配色与字体是否统一、层级是否清楚、是否有统一组件
可落地性	20	能否据此实现、素材是否可替换、是否说明了未完成部分

需求分析评审表按以下五个维度评分，每维度 20 分，合计 100 分：

维度	分值	评什么
需求真实性	20	需求是否有真实来源（用户访谈／调研），是否如实标注未定内容
用户场景	20	场景是否具备用户目标、前置条件、触发、步骤、分支、结果六要素
类图	20	是否覆盖业务实体而非技术组件；属性、职责、关联与多重性是否清楚
功能描述与验收	20	功能是否有编号与明确输入输出；验收是否可判定
需求边界	20	是否说明"不做什么"；待定项是否登记影响范围与关闭条件

维度来源： 界面原型设计评审表的五个维度来自任务 B 的原型评审维度；需求分析评审表的五个维度来自任务 A 的需求评审维度。两份表均另附本组自评区，用于对照：原型侧按任务 B 提供的 10 个检查维度（规则一致性、成本与日程、分支可发现、持久化、考试边界、资金安全、版式、材料可追踪、范围真实、组外访问）逐条自评；需求侧按 GB/T 9385—2008 的文档结构逐项自查。

9.2 评分标准与排名

各维度统一采用五级判定，便于横向比较：

档次	分值区间	判定标准
优	17–20	该维度做得完整且超出预期，可作为范例
良	13–16	基本完整，个别细节不足但不影响使用
中	9–12	覆盖了主要部分，有明显缺口需要补
及格	5–8	只做了形式，关键内容缺失
差	0–4	基本未做或与要求不符

按总分对本次参评的全部小组排序，形成各小组名称与排名总表；同时逐条记录评审意见。

9.3 评审记录格式

每条评审记录包含：评审人、评审日期、被评审小组与项目名称、评审维度、关键检查项、实际观察到的内容、预期与实际、需求编号、证据（截图或链接）、严重性（阻断／严重／一般／建议）、具体评审建议、问题归属、复测结果。

说明： 对其他组的实际评审建议、小组名称与排名需按课堂真实评审情况填写，不能提前编造。因此表中当前只建立可协作的表结构与评分维度，具体评审内容在课堂评审环节填入。这一处理与本次作业"如实标注未完成内容"的一贯做法一致。

---

十、评分要点自检

为方便老师与助教核对，我们把本次作业的评分项与本文对应位置整理如下：

评分项	分值	本文对应位置
博客排版，采用 Markdown；正确给出需求规格说明书、界面原型设计、需求分析 PPT、界面原型答辩 PPT 四个链接	2	全文 Markdown 排版；四项链接分别见第五、六、七、八章
组队后项目整体计划安排，有明确的里程碑	6	第一章：五阶段计划 + M0 至 M8 里程碑表 + 关键路径
项目进行过程中可能遭遇的关键点、难点与风险分析	5	第二章：3 个关键点 + 5 个难点 + 11 项风险
组员分工、组员工作量比例	7	第三章：规定格式的贡献度表 + 每位成员的具体工作内容 + 4.6 节比例计算依据
加强团队成员分工协作，描述成员协作方式	16	第四章：沟通工具与节奏、版本仓库协作、冲突处理、任务同步机制、AI 协作规范、贡献度可追溯
需求规格说明书：引言、用户场景、类图、界面原型、功能描述、验收验证标准	32	第五章：5.1 文档结构、5.2 用户场景、5.3 类图、5.5 输入输出与质量、5.6 验收标准
参考国标规范撰写需求规格说明书	12	5.1 节：文档参照 GB/T 9385—2008 与 ISO/IEC/IEEE 29148:2018 组织，记录引用版本与适用限度

本次作业的七项交付物对照：

编号	必交成果	本文位置 / 状态
D1	博客随笔 1 篇（含目录、核对评分要点）	本文
D2	界面原型 1 份	第六章已给链接（华为云仓库原型包）
D3	界面原型答辩 PPT 1 份	第八章已给链接（PPTX + PDF）
D4	需求规格说明书 Word 1 份	第五章已给链接（Word + PDF）
D5	需求分析报告 PPT 1 份	第七章已给链接（PPTX + PDF）
D6	界面原型设计评审表 1 份	第九章已给链接（腾讯共享文档）
D7	需求分析评审表 1 份	第九章已给链接（腾讯共享文档）

---

十一、结语

本次作业最难的地方，不是把界面画出来，而是在一份自己还没完全定稿的设计稿上，写出可以被别人验证的需求。

我们真实经历的困难有三个。第一，设计稿本身在演进：玩法文档从 v0.2 更新到 v0.5，早期技术稿的分支时机、攻略阈值和结局配对与最新玩法完全冲突。我们没有偷偷把旧稿改写掉，而是建立版本关系与差异登记表，明确"冲突以玩法文档为准"，让每一处冲突都有据可查。第二，大量数值还没有确定：总初始点数、工资、餐品价格、小游戏评分边界、考试时限都还在评审中。我们没有为了让文档"看起来完整"而随手填数，而是集中登记 26 项待定事项，写明影响范围与关闭条件，并在需求属性里用"稳定性：可变"如实标注。第三，四个人的材料口径极易互相矛盾：因此我们建立统一规则表作为唯一依据，任何材料引用数值时都要带状态标记。

回头看，这些"不省事"的选择恰恰是这次作业最有价值的部分：一份诚实的、知道自己哪里不知道的需求文档，比一份看起来很完整但经不起追问的文档更有用。它也直接决定了我们后续开发的起点——26 项待定事项将在例会上逐项认领，高优先级的 54 条需求构成原型版的交付范围，而 22 个检查点会成为我们走查实现的清单。

下一步，我们会按计划把待定项变成数值、把需求变成可玩版本，并在每次走查后回写需求文档，而不是让它在提交之后就被束之高阁。

---

本轮材料版本说明： 本文依据《福大秋日狂想曲》玩法与系统设计 v0.5、任务 A 需求正文 A1.2 评审稿、任务 B 原型 A1.2 修订版、任务 C 需求分析 PPT 整理。文中所有候选数值均为待团队确认的设计提案，非最终规则；所有验收标准均为未执行状态；原型为界面原型，正式游戏仍使用 Ren'Py 实现。