狂想曲委员会——项目系统设计与数据库设计

• 华为云团队仓库
• 狂想曲委员会_系统设计说明书.pdf
• 狂想曲委员会_数据库设计说明书.pdf
• 系统设计和数据库设计答辩PPT.pdf

一、项目与本次设计范围

《福大秋日狂想曲》是一款校园题材的中文喜剧视觉小说。玩家在八周生活中安排学习、运动、打工与人物互动，通过属性、资源、关系和事件进度影响后续剧情。第六周进行考试，第七周最终选择，第八周进入相应章节。

正式目标为Ren’Py 8.5.3与内置Python的Windows单机版，网页版本用于流程原型验证。本文的对象、接口和流程为设计成果，不表示正式桌面程序已经实现或完成验收。系统不引入登录、支付、远程数据库或云存档。

二、体系结构与功能模块层次

2.1 架构选择

系统采用表现层、逻辑层、数据层、引擎层四层划分。

表现层通过应用门面调用领域服务，领域服务通过事务协调器与仓储完成状态更新。引擎作为支撑设施，不意味着所有调用都必须机械地逐层穿过四层。

2.2 功能模块

按职责和变更节奏切分模块，让界面调整、规则数值调整和剧情内容扩充尽量在各自范围内完成。结局目录中的预留分支不等于全部已开放；当前禁用的E04/E05不作为本阶段正常可选结果。

2.3 活动协作与结算

一次活动依次经过前置校验、玩法执行、结果计算、普通状态提交和日程推进。界面只传活动编号、选择和表现证据，奖励数值由服务根据规则计算。好感修改统一走受信逻辑入口，限制在0～100。

普通状态的结算应避免“已扣精力但未获得结果”。同一操作编号、相同载荷重复提交返回原结果；相同编号、不同载荷拒绝；过期状态版本要求刷新。包含等待玩家选择的流程分阶段提交，不将整段交互描述为一个不可中断的磁盘事务。

普通状态和跨周目档案属于不同存储边界，不能宣称天然具有跨存储原子性。跨周目效果使用稳定编号去重，写入失败明确提示并保留待重试项。

图片文件名为图3-1，在系统说明书中对应图2-3。

三、数据设计与持久化边界

正式单机版使用引擎序列化存档。系统说明书4.4节说明，独立《数据库设计说明书》提供关系化等价建模；不能据此声称正式游戏已部署关系数据库。系统说明书概念图展示11个核心实体，字段级设计由数据库说明书的29张逻辑表承接。B的署名为林宇杰（102400222）。关系参考模型采用SQLite STRICT表用于设计验证，正式运行仍采用Ren’Py原生存档与persistent。

“只增不减”指正常玩法操作的业务约束，不代表能抵抗本机文件删除或篡改。普通快照不保存界面、音频、计时器等运行句柄。周次和星期从日序派生；小游戏跳过资格从已去重的最高评级次数派生，避免同一事实重复存储。

3.1 三张分域ER图

图1：配置数据关系图（原数据库说明书第7页）。配置域组织活动、小游戏、奖励、课表、剧情事件和考试题目等相对稳定的内容，通过标识符连接，避免在普通状态中重复保存题干、名称和奖励规则。

图2：普通状态与存档槽关系图（原数据库说明书第8页）。本地档案关联多个周目，周目关联快照，快照再关联好感、事件、考试、订单及普通结算去重等子状态。存档槽是快照入口索引，空槽允许不指向快照；槽位指向的快照须属于同一本地档案。

图3：跨周目永久记录关系图（原数据库说明书第9页）。最高评级账本、CG解锁和结局解锁依附本地档案，不依附普通快照，因此读取旧档不会撤销永久记录。

3.2 完整字段表：save_slot 存档槽索引

以下完整转写自数据库说明书5.26节（第20页），共5个字段，保留原约束。PK表示主键，FK表示外键；这些是参考关系模型约束，运行时还需对应的引擎适配和业务校验。

联合主键为PRIMARY KEY(profile_id, slot_no)，保证同一档案下每个槽号只有一个入口。删除被引用快照时将state_id置空，不连带删除槽索引。档案外键采用RESTRICT，避免仍有索引时误删档案。仅有两个独立外键不能保证快照和槽位同属一个档案，因此参考模型还通过INSERT/UPDATE触发器检查所属关系。

3.3 完整字段表：minigame_award 永久最高评级去重账本

以下完整转写自数据库说明书5.27节（第20页），共4个字段。

联合主键为PRIMARY KEY(profile_id, attempt_id)。同一合法活动重试沿用原attempt_id，不重复增加最高评级次数；同键却对应不同小游戏应作为冲突拒绝。只有正式、手动、完成且达到最高评级的结果能够登记，不能仅凭界面提交任意值插入账本。次数按账本聚合，跳过资格由达到三次的门槛派生，跳过本身不新增最高评级记录。

3.4 主外键、完整性和范式设计

配置中的角色名、价格、题干等避免在状态中重复保存；多对多关系通过关联表表达。paid_amount、mood_delta、knowledge_snapshot、difficulty保留为历史结算事实，不能用后来修改的配置反推过去结果。周次、星期、最高次数和跳过资格可派生，减少重复真相。

补充边界：B稿把56天、部分0～100属性范围以及手动/自动槽位拆分保留为设计假设或候选，本文不将它们冒充新增团队决议。系统说明书和接口稿中采用的候选值需在实现前统一确认。

四、设计类图、安全与健壮性

4.1 从分析对象到设计职责

领域分析类用于表达业务概念，不要求在Ren’Py中逐一建立同名Python类。设计模型进一步明确应用门面、领域服务、普通状态、考试检查点、仓储及事务协调器的职责。

人物A、B和黄毛是人物对象的实例，关系数值由关系对象维护。跨周目档案与游戏进程使用独立关联，避免将其表达成随单局生命周期销毁的组成部分。运行时可按Ren’Py的default变量、字典和函数落地，但需验证嵌套可变数据的回退行为。

4.2 权限与数据安全

单机项目的权限重点是防止程序误写和跨模式污染。正式、演示和体验上下文绑定各自的数据访问能力，不能由界面传一个布尔值决定是否有正式档案写权。

服务复检活动资格、考试阶段和结局条件，隐藏按钮不代替服务校验。项目不采集真实姓名、学号、联系方式或上传存档；本地题库与资源不承诺对设备所有者保密。

4.3 故障与恢复

五、改进分析

5.1 评审反馈的处理

上次需求分析评审中，老师和同学均未提出具体问题（根据本轮团队成员补充）。因此本次没有需要逐条回应的外部评审问题，不虚构意见来源。

本阶段根据需求和设计材料进行内部复核，主要将需求进一步落实为接口、数据边界与异常处理。下表表示设计细化方向，不声称这是上次评审提出的缺陷，也不声称已有正式程序验收结果。

改进方法为：核对需求边界→定位图表及接口→细化方案→跨文档检查→在后续开发中执行验证。现阶段产出为设计稿，不将内部复核包装成已完成的用户测试。

5.2 驱动LLM协助完成设计的三个示例

以下采用“输入约束—提示词—方案—复核—落点”的统一格式。提示词为基于项目材料整理的可复用版本，方案为设计摘录和本次归纳，不是历史聊天原文。第三例依据C交付的案例；第一、二例为本次根据已交付设计整理的协作示例。均不将设计检查写成程序测试通过。

示例一：由玩法需求梳理四层架构和模块接口

设计任务。 将日程、活动、考试、人物事件、结局和存档需求转为模块边界，避免界面脚本直接修改业务状态。输入为A的架构与模块材料、系统说明书第2～3章及C的接口设计。

驱动提示词：

你是《福大秋日狂想曲》的概要设计助手。
项目为Ren’Py 8.5.3单机校园视觉小说，没有登录和远程数据库。
请根据以下约束整理架构与模块协作：
1. 区分表现、逻辑、数据和引擎支撑职责。
2. 玩法覆盖日程、属性资源、场景活动、小游戏与考试、剧情、结局、档案。
3. 界面只提交活动编号、选择和表现证据，不能直接指定奖励。
4. 普通状态随读档恢复，跨周目解锁和最高评级记录不随读档减少。
5. 一次实际活动只消耗一次精力和时段；附属玩法不能重复扣除。
请输出模块职责表、调用方向、一次活动的接口契约和异常返回。
最后审查：职责是否重叠、界面是否越权、重复提交是否重复结算。
不要添加账号系统，不要宣称已经编码或测试通过。

方案整理。 分离表现层与逻辑层，用应用门面承接操作；由活动服务计算结果，事务协调器提交普通候选状态，日程服务推进时段。七个一级模块分别承接玩法职责。接口返回业务结果及不能执行的原因，表现层据此更新页面。

复核重点与修正。 仅列出四个层名并不足以约束实现，必须写清“谁能修改什么”。本次整理将“界面负责奖励计算”列为应拒绝方案：界面提交的奖励值不可信，应由服务重算。同时补充重复提交语义，同编号同载荷返回原结果，异载荷返回冲突；过期revision要求刷新。

“一次活动就是一次事务”也需限定：普通状态计算与提交可形成一致性边界，等待玩家选择的完整流程应分阶段；普通状态与persistent不能直接承诺跨存储原子提交。

设计落点。 系统架构图、七模块层次图、C的分层协作图及接口表。可用“重复点活动”“活动执行时配置缺失”“旧页面提交”三个场景审查接口；这些仍是待正式程序执行的用例。

协作价值。 LLM帮助把分散功能整理为职责和接口清单，人依据玩法成本和引擎边界限定结算范围，防止将通用架构套成不符合单机项目的设计。

示例二：识别普通存档与跨周目档案的数据生命周期

设计任务。 玩家需要通过读档恢复当前进度，又需要保留已解锁图鉴。输入为系统说明书第4章、第5.6节、C04设计类图及存档接口；关系化逻辑设计由B的数据库说明书承接。

驱动提示词：

请审查本项目的数据分类与类图关系，不新增远程数据库。
已知：
- 普通状态包含时间、精力、属性、好感、餐次、事件、考试及结算凭据。
- CG、主结局解锁和小游戏最高评级记录独立于普通存档。
- 读旧档、回退和新周目均不能减少上述跨周目记录。
- 跳过资格由最高评级累计次数达到3次派生，跳过不增加最高次数。
请输出：数据生命周期表、进程与档案的关系、快照包含与排除字段、
最高评级去重方案，以及重复保存、读旧档、新周目和写盘失败用例。
请审查“将档案组合在单局进程内”和“只存一个can_skip布尔值”
能否满足需求。区分概念关系、逻辑表设计与实际引擎落盘。
不要把所有数据放入同一普通快照，也不要保证跨存储天然原子。

方案整理。 普通状态按完整值快照保存；跨周目档案由独立仓储维护；规则目录只读。进程与档案表达独立关联，而不是要求档案随单局销毁的生命周期组合。快照保存可恢复的业务数据，排除persistent及界面、音频、计时器句柄。

复核重点与修正。 将跨周目档案纳入普通快照，会让旧档覆盖新解锁记录，应拒绝。仅存can_skip布尔值也容易与次数矛盾，改为从已去重的最高评级记录派生资格。最高评级效果按稳定attempt_id或效果编号识别，重试沿用原编号，避免重放造成重复累计。

此外，“29张逻辑表”是关系化等价设计，不能据此生成“已部署MySQL”的描述；跨存储写入失败应报告并保留重试状态，不能吞异常后返回成功。

用于复核的场景：

设计落点。 数据分类与持久化边界、C04设计图、普通存档与档案接口，以及系统说明书4.4节的数据库设计衔接。上表为设计预期，不是引擎实测记录。

协作价值。 LLM协助整理字段与故障场景，人以“读档能恢复什么、不能撤销什么”作为判断依据，使类图、数据模型和恢复流程保持一致。

示例三：将“考试作弊后回到考前”转为完整恢复设计

设计任务。 “回到考前”不能只理解为补回一点精力，还需恢复时间、事件、餐次、考试资格及结算标志。本例依据C的《06_LLM辅助设计示例.md》整理，沿用其中候选规则的待确认属性。

驱动提示词：

请为本项目设计“正式考试→主动作弊→十题结束CG→回到考前”。
以下为A1.2候选规则，仍需团队确认：
1. 第6周周三早上首考，失败者第7周同节点仅补考一次。
2. 开考扣1精力并占一个时段；检查点必须建立在扣成本前。
3. 开考学识<30、30～59、>=60分别对应困难、中等、简单，整场固定。
4. 十题三选一，每题10秒；答案严格早于截止才有效，每题只受理一次。
5. 至少答对6题通过；普通失败心情和B好感各扣10，整场只扣一次。
6. 首次答错后才可主动选择作弊，十题结束后才播作弊CG。
   全错但未主动作弊仍是普通失败；作弊不叠加普通失败扣值。
7. 恢复全部普通状态，但保留当前分区的跨周目解锁。
8. 体验模式使用副本，不写正式成绩和永久档案。
9. 检查点仅当前会话内存有效，重启缺失时不能假装恢复成功。
请输出对象职责、开考/答题/作弊/结算/恢复接口、泳道流程和边界用例。
区分候选需求、设计方案及需Ren’Py验证的机制，不编造测试结论。

已有设计结果。 C的材料将职责划分为ExamAttempt、ExamCheckpoint和ClockPort：考试尝试记录题序、学识快照、答题与作弊状态；检查点保存扣成本前的完整普通状态；时间端口提供统一判时，不进入普通快照。PlayerProfile保存独立解锁，ModeContext限制正式、演示和体验模式的仓储访问。

规则复核与修正。 主动作弊仅设置本场标志，十题受理完成后统一分流；全错不能自动进入作弊CG。普通失败整场扣值一次，作弊分支优先处理，避免额外叠加普通失败处罚。恢复前停止本场计时与回调，再替换完整普通状态，保留persistent。体验退出丢弃副本，不能靠结束时手工加减属性“尽量还原”。

设计伪代码（不是可运行实现）：

恢复考前(ctx, checkpoint):
    若为体验模式：退出并丢弃体验副本
    若检查点缺失或不合法：提示失败，提供已有存档入口
    停止当前考试计时器和回调
    校验检查点字段与恢复阶段
    替换成本扣除前的完整普通状态
    保留当前分区跨周目档案
    返回考试前的合法操作入口

边界复核清单。 学识29/30/59/60的难度选择；9.9秒与10秒的受理边界；答案和超时同时到达；全错未作弊；首错后主动作弊；十题后仅进入作弊分支；完整恢复成本与资格；图鉴保留；体验无污染；重启检查点缺失；写盘失败。以上需在正式程序中执行，不能表述为已全部通过。

设计落点。 C03/C04设计对象、I11～I17接口、D3-S02考试作弊与恢复泳道图、ROB-08～11及相关恢复故障用例。

协作价值。 LLM帮助把一句自然语言需求展开成字段、阶段、接口和失败路径，人负责确认题库与业务规则，并验证引擎快照、回退及计时机制。

三个示例分别覆盖架构职责、数据生命周期和复杂业务恢复。共同方法是先提供项目约束，再要求结构化方案，最后按规则和故障场景复核；LLM输出不直接等于实现或验收结论。

六、团队流程、分工与贡献

每名成员均需在团队仓库提交本人负责的内容，真实commit记录不能由博客中的分工表代替。

七、预期开发计划

里程碑的标准是后续验收目标，不表示当前已经达成。关键路径为“状态骨架→日程与统一结算→考试及存储恢复→剧情结局联调→回归打包”。状态和仓储接口先稳定，界面与剧情可按契约并行接入。

7.1 每人预期开发分工